# parsecapere-skills

> Skill-Manifeste fuer die parsecapere.de Voice-LLM-Plattform.
> Bauplaene — welche Prompt-Module + welche Tools zu welchem Skill zusammenkommen.

---

## Was ein Skill ist

Ein **Skill** ist ein wiederverwendbares Multi-Tool-Workflow-Paket. Konkret:
eine `.md`-Datei mit Frontmatter die beantwortet:

- **Wer bin ich?** (`skill_id`, `description`)
- **Wann werde ich aktiviert?** (`trigger_keywords`)
- **Welche Tools brauche ich?** (`required_tools`)
- **Aus welchen Prompt-Modulen wird mein System-Prompt komponiert?** (`required_prompt_modules`)
- **Wieviele Hops darf ich maximal nutzen?** (`hop_budget`)

Das Skill-Manifest **fuehrt nichts aus**. Es ist ein Bauplan. Der `mcp-gitea`-Service
(kommt in Phase M5) liest das Manifest, holt die Module aus
[`parsecapere-prompts`](../parsecapere-prompts), komponiert sie in der richtigen
Reihenfolge und liefert den fertigen System-Prompt + Tool-Schemas an den Aufrufer.

---

## Ordner-Struktur

```
parsecapere-skills/
├── composite/             # Multi-Tool-Workflow-Skills
│   ├── main-voice.md      # User-Facing Default-Skill (kein Trigger noetig)
│   ├── kreuzwort-builder.md
│   ├── lueckentext-builder.md
│   └── (kuenftige: sentence-shuffle-builder, ...)
└── atomic/                # (zukuenftig) Single-Tool-Skills
```

---

## Compose-Order beim Laden

Wenn der `mcp-gitea`-Service einen Skill laed, baut er den finalen
System-Prompt in dieser Reihenfolge:

```
1. base/identity.md
2. base/style.md
3. base/constraints.md
4. workflows/*    (in der im Manifest deklarierten Reihenfolge)
5. tools-context/* (abgeleitet aus required_tools, oder explizit deklariert)
6. personas/<persona>.md  ← LETZTER, Tie-Breaker
```

Persona kommt zuletzt damit sie alles davor ueberschreiben darf (siehe
Stolperstein 3 in `2026-06-02 — Prompt-Modularisierung — Architektur und Composition.md`).

---

## Status-Stand

### Phase M4 — DONE (2026-06-02)
- Drei initiale Skill-Manifeste angelegt:
  - `composite/main-voice.md`
  - `composite/kreuzwort-builder.md`
  - `composite/lueckentext-builder.md`
- `skill-index.md` im Schwester-Repo `parsecapere-prompts` mit echten Eintraegen befuellt.

### Phase M5 — NEXT
- `mcp-gitea`-Service auf LLM-VPS implementieren
- Tools: `load_skill(skill_id)`, `list_skills(trigger?)`, `load_prompt_module(path)`
- STDB-Cache `gitea_section_cache` mit Webhook-Invalidation

---

## Cross-Repo

| Repo                    | Inhalt                                                              |
|-------------------------|---------------------------------------------------------------------|
| [`parsecapere-prompts`](https://gitea.parsecapere.de/tim/parsecapere-prompts) | Prompt-Bausteine (base/, workflows/, tools-context/, personas/) |
| `parsecapere-skills` (hier) | Skill-Manifeste — welche Bausteine wann zusammenkommen          |
| [`parsecapere-knowledge`](https://gitea.parsecapere.de/tim/parsecapere-knowledge) | Lang-laufendes Wissen (Vokabel-Listen, Wortpool-Snapshots, ...) |

---

## Architektur-DNA-Bezug

- **Server denkt, Frontend rendert** — Skill-Composition passiert serverseitig im `mcp-gitea`.
- **Skills sind versioniert** — Frontmatter `version: 0.1.0`, plus `required_prompt_modules`
  koennen gepinnte Modul-Versionen referenzieren (z.B. `workflows/error-recovery@v2`),
  damit ein Production-Skill bei Modul-Bump nicht ploetzlich anders denkt.
- **Hot-Reload faehig** — wenn jemand ein Modul oder ein Skill editiert und pushed,
  invalidiert der `mcp-gitea`-Webhook den Cache pro Pfad — naechster `load_skill`-Call
  liefert frisch.