tlg
9c557be5e8
- Einsatzort-Distanz wird geocodiert (Nominatim, nur DE) statt LLM-geschätzt; Bänder ≤50/50-60/>60 km bleiben, Fallback bei unbekanntem Ort → ❔. - 6.2: Verknüpfung des neuen Kontakts zur Firma (accountId) explizit gefordert. - Feasibility verifiziert (München 19, Rosenheim 38, Augsburg 71, Nürnberg 170 km). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
134 lines
8.4 KiB
Markdown
134 lines
8.4 KiB
Markdown
# Design: Erweiterung des Skills `projekt-anlegen`
|
||
|
||
**Datum:** 2026-06-12
|
||
**Status:** Freigegeben (Brainstorming abgeschlossen)
|
||
**Sprache:** Deutsch
|
||
**Basis:** Die unveränderte Ausgangsfassung ist als inaktiver Skill `cowork-projekt-match` archiviert. Aktiv erweitert wird `.claude/skills/projekt-anlegen/SKILL.md`.
|
||
|
||
## 1. Zweck
|
||
|
||
Den aus Claude Cowork übernommenen und an diese Umgebung angepassten Skill `projekt-anlegen` zum gewünschten Zielzustand erweitern:
|
||
|
||
1. Rahmenbedingungen (Verfügbarkeit, Auslastung, Laufzeit, Einsatzort) **automatisch** aus einer festen Vorgaben-Datei bewerten — damit Thomas sie nicht in jedem Review manuell setzen muss.
|
||
2. Aus der Ausschreibung zusätzlich **Käufer-Typ**, **Ansprechperson** und **Firmenname** extrahieren.
|
||
3. Beim CRM-Eintrag zuerst **Firma**, dann **Kontakt**, dann **Verkaufschance** anlegen (mit Dedup-Prüfung) und korrekt verknüpfen.
|
||
|
||
### Erfolgskriterien
|
||
- Misc-Anforderungen werden ohne Rückfrage mit ✅/❌/❔ bewertet, sofern die Regeln greifen.
|
||
- Firma und Kontakt werden vor der Verkaufschance angelegt oder wiederverwendet; keine ungewollten Dubletten.
|
||
- Agenturen erhalten `type = Reseller` und landen im Feld „Über Agentur" (`cAccount1`); der Endkunde landet bei Direktaufträgen im Feld `account`.
|
||
|
||
## 2. Verifizierte CRM-Fakten (EspoCRM)
|
||
|
||
- **`Account.type`** ist ein Enum mit den API-Werten `Customer`, `Investor`, `Partner`, `Reseller`. „Wiederverkäufer" (Oberfläche) = API-Wert **`Reseller`**.
|
||
- **`Contact`** verknüpft die Firma über `accountId`/`accountName`; Personenname über `firstName`/`lastName` (+ optional `salutationName`, `emailAddress`).
|
||
- **`Opportunity`**-Verknüpfungen: `account` (Hauptfirma, link), `cAccount1` (= „Über Agentur", link), `contacts` (linkMultiple). Setzen beim Anlegen über `accountId`, `cAccount1Id`, `contactsIds: [<id>]`.
|
||
- Zugriff direkt per `curl` (Key/Base aus `.secrets/espocrm-api.md`), wie in der aktuellen Skill-Fassung etabliert.
|
||
|
||
## 3. Neue Vorgaben-Datei `vorgaben/rahmenbedingungen.md`
|
||
|
||
Genau dieser Inhalt wird angelegt:
|
||
|
||
```markdown
|
||
# Rahmenbedingungen (Misc-Bewertung)
|
||
|
||
Feste Kriterien für die automatische Bewertung von Rahmenbedingungen (Kategorie Misc)
|
||
durch den Skill `projekt-anlegen`. Ändern sich selten.
|
||
|
||
## Kriterien
|
||
|
||
| Dimension | Vorgabe | Bewertung |
|
||
|---|---|---|
|
||
| Verfügbar ab | sofort | Projektstart ≤ 8 Wochen ab heute → ✅; > 8 Wochen → ❌; nicht genannt → ❔ |
|
||
| Auslastung | 100 % (Vollzeit) | 75–100 % → ✅; < 75 % → ❔; nicht genannt → ❔ |
|
||
| Laufzeit | keine Einschränkung | jede Laufzeit → ✅ |
|
||
| Einsatzort / Remote | 100 % Remote oder Onsite ≤ 50 km um Sauerlach | siehe Einsatzort-Regel |
|
||
|
||
## Einsatzort-Regel
|
||
- 100 % Remote → ✅ (Ort egal).
|
||
- Onsite/Hybrid, Ort ≤ 50 km Luftlinie um Sauerlach → ✅.
|
||
- Onsite/Hybrid, Ort 50–60 km (grenzwertig) → ❔.
|
||
- Onsite/Hybrid, Ort > 60 km → ❌.
|
||
- Einsatzort/Remote-Anteil unklar oder nicht genannt → ❌.
|
||
|
||
Distanz = Luftlinie zwischen Onsite-Ort und Sauerlach (47,9721 N / 11,6528 O),
|
||
bestimmt per Geokodierung (Nominatim/OpenStreetMap, nur Deutschland) und Haversine.
|
||
Unbekannter/mehrdeutiger Ort → ❔.
|
||
|
||
Hinweis: „heute" = aktuelles Datum der Session. „8 Wochen" = 56 Tage.
|
||
```
|
||
|
||
## 4. Extraktion erweitern (Skill-Schritt 1)
|
||
|
||
Zusätzlich zu Projektname/URL/Anforderungen aus der Ausschreibung ziehen:
|
||
|
||
- **Käufer-Typ:** Agentur (Wiederverkäufer) **oder** Endkunde (Direktauftrag).
|
||
- Signale für Agentur: bekannte Personaldienstleister/Vermittler (z. B. Hays, GULP/Randstad, SThree/Computer Futures, Aristo), Formulierungen wie „im Auftrag unseres Kunden", „für unseren Kunden", Vermittler-Kontext des Portals.
|
||
- Ist der Typ nicht eindeutig bestimmbar, im Review nachfragen.
|
||
- **Ansprechperson:** vollständiger Name (für Aufteilung in Vor-/Nachname siehe §6).
|
||
- **Firmenname:** Name der Agentur bzw. des Endkunden.
|
||
|
||
## 5. Rahmenbedingungen automatisch bewerten (Skill-Schritt 3/4)
|
||
|
||
Misc-Anforderungen zu Verfügbarkeit/Auslastung/Laufzeit/Einsatzort werden gegen `vorgaben/rahmenbedingungen.md` bewertet und erhalten direkt ✅/❌/❔ gemäß den Regeln in §3 — **statt** des bisherigen pauschalen ❔. Greift eine Regel nicht eindeutig (Auslastung/Start nicht genannt, Ort grenzwertig), bleibt es ❔.
|
||
|
||
- Distanzbeurteilung per **Geokodierung**: Onsite-Ort über Nominatim (OpenStreetMap; `format=json`, `countrycodes=de`, `limit=1`, eigener `User-Agent`; max. 1 Request/s) auflösen, Luftlinie zu Sauerlach (47,9721 N / 11,6528 O) per Haversine berechnen, gegen die Bänder ≤ 50 / 50–60 / > 60 km prüfen. Geokodierung gescheitert oder Ort mehrdeutig → ❔. (Feasibility verifiziert: München 19 km, Rosenheim 38 km, Augsburg 71 km, Nürnberg 170 km.)
|
||
- Startdatum: „heute + 8 Wochen" (56 Tage) gegen den genannten Projektstart prüfen.
|
||
- Misc-Zeilen gehen weiterhin **nicht** in die Match-Prozente ein; die automatische Bewertung ist informativ und spart das manuelle Setzen.
|
||
|
||
## 6. CRM-Schreibablauf (Skill-Schritt 7) — Reihenfolge Firma → Kontakt → Verkaufschance
|
||
|
||
Alle Schreibvorgänge erst **nach** der Review-Freigabe (§7).
|
||
|
||
### 6.1 Firma (`Account`)
|
||
1. Dedup-Suche per Name (Kern-Token), inkl. naher Varianten (z. B. „Aristo Recruitment" vs. „Aristo Recruitment GmbH").
|
||
2. Exakter/eindeutiger Treffer → bestehenden Datensatz wiederverwenden (im Review als „bestehend" ausweisen).
|
||
3. Ähnlich-aber-nicht-identisch → Kandidaten im Review auflisten; Thomas entscheidet „wiederverwenden" oder „neu anlegen". Nie still anlegen oder zusammenführen.
|
||
4. Kein Treffer → neu anlegen: `POST /Account` mit `{name, type}`.
|
||
- Agentur → `type = "Reseller"`.
|
||
- Endkunde (Direktauftrag) → `type = "Customer"`.
|
||
|
||
### 6.2 Kontakt (`Contact`)
|
||
1. Dedup-Suche per Name analog zu 6.1.
|
||
2. Kein/zu bestätigender Treffer → nach Freigabe neu anlegen: `POST /Contact` mit `{firstName, lastName, accountId}`.
|
||
- **Die Verknüpfung zur Firma aus 6.1 wird beim Neu-Anlegen zwingend mitgesetzt** (`accountId`), sodass der neue Kontakt der Firma zugeordnet ist.
|
||
- Namensaufteilung: letztes Token = `lastName`, der Rest = `firstName`. Ungewöhnliche Fälle im Review klären.
|
||
|
||
### 6.3 Verkaufschance (`Opportunity`)
|
||
`POST /Opportunity` wie bisher (`name`, `description` = Match-Tabelle, `cProjektlink`) **plus** Verknüpfungen:
|
||
- `contactsIds: [<contactId>]`
|
||
- **Agentur:** `cAccount1Id = <agenturAccountId>` („Über Agentur"); `account` bleibt **leer**.
|
||
- **Direktauftrag:** `accountId = <endkundeAccountId>`; `cAccount1` bleibt leer.
|
||
|
||
Duplikat-Regel für den Opportunity-Namen (Suffix „ (2)", „ (3)", …) bleibt wie in der aktuellen Fassung.
|
||
|
||
## 7. Review erweitern (Skill-Schritt 6)
|
||
|
||
Vor jedem Schreibvorgang zeigt das Review zusätzlich zur bestehenden Match-Tabelle und den ❌/❔-Begründungen:
|
||
- **Käufer-Typ** (Agentur/Direktauftrag) mit Kurzbegründung.
|
||
- **Firma:** Name und `type`; „neu anlegen" oder „bestehende nutzen: <Name/ID>"; bei Mehrdeutigkeit die Kandidatenliste.
|
||
- **Kontakt:** Name; „neu" oder „bestehend".
|
||
- **Verknüpfungs-Zuordnung** der Verkaufschance (account vs. cAccount1, Kontakt).
|
||
|
||
Erst nach Freigabe werden Firma, Kontakt und Verkaufschance in dieser Reihenfolge geschrieben (§6).
|
||
|
||
## 8. Geänderte/neue Dateien
|
||
- Neu: `vorgaben/rahmenbedingungen.md` (§3).
|
||
- Geändert: `.claude/skills/projekt-anlegen/SKILL.md` (Schritte 1, 3/4, 6, 7; Voraussetzungen um `rahmenbedingungen.md` ergänzt).
|
||
- Ggf. ergänzt: `CLAUDE.md` (Hinweis auf `vorgaben/rahmenbedingungen.md`).
|
||
- Unberührt: `cowork-projekt-match` (Archiv).
|
||
|
||
## 9. Bewusst NICHT enthalten (YAGNI)
|
||
- Keine Fahrstrecken-/Routing-Berechnung — für das 50-km-Kriterium genügt die Luftlinie (Haversine) auf Basis der Nominatim-Geokodierung.
|
||
- Keine automatische Zusammenführung bestehender CRM-Dubletten.
|
||
- Keine Änderung der Must/Nice-Bewertungslogik oder der Match-Berechnung.
|
||
|
||
## 10. Offene Annahme (im Spec-Review zu bestätigen)
|
||
- **Projektstart „nicht genannt" → ❔** (Review entscheidet). Alle anderen „nicht genannt"-Fälle sind oben explizit geregelt.
|
||
|
||
## Selbstreview
|
||
- Alle vier Rahmen-Dimensionen haben eindeutige ✅/❌/❔-Regeln inkl. „nicht genannt"-Fall (Start = ❔, Auslastung = ❔, Einsatzort = ❌, Laufzeit n/a). ✓
|
||
- CRM-Feldnamen gegen die API verifiziert (`type=Reseller/Customer`, `account`/`cAccount1`/`contacts`). ✓
|
||
- Schreibreihenfolge und Verknüpfungen für beide Käufer-Typen konsistent. ✓
|
||
- Keine Platzhalter; Dedup-Verhalten entspricht der getroffenen Entscheidung (Kandidaten im Review). ✓
|