59 lines
2.1 KiB
Markdown
59 lines
2.1 KiB
Markdown
|
---
|
||
|
|
name: starterkit-planner
|
||
|
|
description: Planungs-Skill fuer Architektur-, Rollout-, Refactor- und Standardisierungsaufgaben im Starterkit. Verwenden, wenn ein decision-complete Plan mit klaren Interfaces, Tests, Risiken und Annahmen benoetigt wird.
|
||
|
|
---
|
||
|
|
|
||
|
|
# Starterkit Planner
|
||
|
|
|
||
|
|
## Ziel
|
||
|
|
|
||
|
|
Planungen so strukturieren, dass Implementierung ohne offene Entscheidungen moeglich 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 muessen stabile IDs tragen (`SC-001`, `SC-002`, ...).
|
||
|
|
3. Success Criteria muessen so formuliert sein, dass Reviewer Acceptance sie direkt gegen `criterion_id` pruefen kann.
|
||
|
|
4. Guard- und Quality-Gate-IDs muessen 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 moeglich 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 pruefbar (`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`
|