fs
545bcc789b
Most German docs were written with `ue`/`ae`/`oe`/`ss` ASCII fallbacks (`fuer`, `aenderung`, `koennen`, `gemaess`) — relic from older toolchain constraints. Replaced 237 occurrences across 38 .md files with proper umlauts and ß so the docs read naturally. Substitutions are constrained to plain prose: fenced code blocks (```...```), inline code spans (`...`), markdown link targets `[..](..)`, and HTML comments are preserved verbatim. Path references like `docs/howto-erste-aenderung.md` keep their original (umlaut-replaced) filenames — only the surrounding prose is normalised. Tool: bin/fix-md-umlauts.py (idempotent — no-op on already-clean files). Re-runnable if ASCII fallbacks creep back in via copy-paste. Doc-link-check + doc-drift-check stay green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
59 lines
2.1 KiB
Markdown
59 lines
2.1 KiB
Markdown
---
|
|
name: starterkit-planner
|
|
description: Planungs-Skill für Architektur-, Rollout-, Refactor- und Standardisierungsaufgaben im Starterkit. Verwenden, wenn ein decision-complete Plan mit klaren Interfaces, Tests, Risiken und Annahmen benötigt wird.
|
|
---
|
|
|
|
# Starterkit Planner
|
|
|
|
## Ziel
|
|
|
|
Planungen so strukturieren, dass Implementierung ohne offene Entscheidungen möglich ist.
|
|
Bei Agent-Workflows muss der Plan maschinenlesbar in die Projekt-Contracts passen.
|
|
|
|
## Verbindliches Ausgabeformat
|
|
|
|
1. Ziel + Success Criteria
|
|
2. In/Out-of-Scope
|
|
3. Entscheidungsmatrix (Optionen + Gruende)
|
|
4. Decision-complete Implementierungsplan
|
|
5. Tests/Abnahme
|
|
6. Risiken/Migrationshinweise
|
|
7. Annahmen/Defaults
|
|
|
|
Wenn `.agents/` verwendet wird:
|
|
|
|
1. Plan muss dem Schema `.agents/contracts/planner.schema.json` entsprechen.
|
|
2. Success Criteria müssen stabile IDs tragen (`SC-001`, `SC-002`, ...).
|
|
3. Success Criteria müssen so formuliert sein, dass Reviewer Acceptance sie direkt gegen `criterion_id` prüfen kann.
|
|
4. Guard- und Quality-Gate-IDs müssen aus den Katalogen kommen (`GR-*`, `QG-*`).
|
|
|
|
## Vorgehen
|
|
|
|
1. Ist-Zustand kurz aus Repo-Fakten ableiten.
|
|
2. Entscheidungen mit Tradeoffs transparent machen.
|
|
3. Oeffentliche Contracts explizit benennen.
|
|
4. Success Criteria frueh mit stabilen IDs (`SC-*`) definieren.
|
|
5. Reihenfolge und Rollout so planen, dass Rueckbau möglich bleibt.
|
|
6. Teststrategie nach Risiko priorisieren.
|
|
|
|
## Qualitaetskriterien
|
|
|
|
1. Keine vagen TODO-Entscheidungen im Plan.
|
|
2. Jeder betroffene Bereich hat klare Akzeptanzkriterien mit stabiler ID (`SC-*`).
|
|
3. Risiken sind priorisiert und beobachtbar.
|
|
4. Ungeklaerte Themen stehen explizit unter Annahmen.
|
|
5. Guard-/Gate-Referenzen sind vollstaendig und prüfbar (`GR-*`, `QG-*`).
|
|
|
|
## Out of Scope
|
|
|
|
- Extension-Mechanik ist aktuell nicht standardisiert.
|
|
- Keine impliziten Extension-Regeln definieren.
|
|
|
|
## Referenzen
|
|
|
|
- Plan-Grundgeruest: `references/plan-template.md`
|
|
- Entscheidungsraster: `references/tradeoff-matrix.md`
|
|
- Agent Planner Contract: `.agents/contracts/planner.schema.json`
|
|
- Guard Catalog: `.agents/checks/guard-catalog.json`
|
|
- Quality Gates: `.agents/checks/quality-gates.json`
|