tim
44d1207b8d
Drei Skill-Manifeste angelegt — Rezepte die der mcp-gitea-Service (Phase
M5) auslesen wird um System-Prompts zu komponieren:
- composite/main-voice.md
Default-Skill beim Voice-Entry. Kein Trigger — wird direkt geladen.
17 Tools (volles Brick-Set + Sub-Agent-Dispatcher + Trace-Reducer).
required_prompt_modules: 6 (base/* + workflows/plan-before-action +
workflows/error-recovery + tools-context/brick-creation + persona).
- composite/kreuzwort-builder.md
Sub-Agent, Trigger ["kreuzwort", "kreuzwortraetsel", "crossword"].
5 atomic_* Tools. atomic_set_kreuzwort_solution bewusst NICHT exponiert
(nur via atomic_finalize_kreuzwort_layer erlaubt — verhindert
erfundene layerIds).
hop_budget: 12 (Self-Correction-Loop braucht mehrere Iterationen).
required_prompt_modules: 8 (inkl. workflows/self-correction +
tools-context/atomic-finalize).
- composite/lueckentext-builder.md
Sub-Agent, Trigger ["lueckentext", "vokabel-drill", "cloze"].
4 atomic_* Tools, strikt linear a→b→c→d.
hop_budget: 8 (kein Self-Correction).
required_prompt_modules: 8 (inkl. workflows/error-recovery +
tools-context/atomic-chain).
Plus README.md komplett umgeschrieben — erklaert was ein Skill ist,
die Ordner-Topologie (composite/ vs zukuenftiges atomic/), die
Compose-Order und den Cross-Repo-Bezug zu parsecapere-prompts +
parsecapere-knowledge.
Reference notes:
arch-flow/brainstorm/Sprache/
2026-06-02 — Master-Synthese — Prompt-Migration-Reihenfolge.md
2026-06-02 — Prompt-Modularisierung — Architektur und Composition.md
2026-06-02 — Skill-Discovery und Chain-of-Thought im Trace.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
94 lines
3.5 KiB
Markdown
94 lines
3.5 KiB
Markdown
# 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.
|