# 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). ✓
