# 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: []`. - 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: []` - **Agentur:** `cAccount1Id = ` („Über Agentur"); `account` bleibt **leer**. - **Direktauftrag:** `accountId = `; `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: "; 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). ✓