Planning-Suite¶

Die Planning-Suite ist die Sammlung von Skills und einem Agent, mit der ein Repository die Specs mission, roadmap, sprint, feature und release-artifact operationalisiert. Diese Seite bündelt die Reihenfolge, in der die Skills typischerweise zum Einsatz kommen, plus eine Karte „welcher Skill schreibt welches Artefakt".

Adoption ist freiwillig — ein Repository ohne project/-Verzeichnis wird durch keinen dieser Skills gestört.

Lifecycle-Übersicht¶

flowchart TB
    subgraph foundation["Foundation (one-time)"]
        ai["audience-identify"] --> aud["AUDIENCES.md"]
        aud --> ri["roadmap-init"]
        ri --> goals["project/goals.md"]
        ri --> rmap["project/roadmap.md"]
    end

    subgraph mission["Mission (when an MVP is defined)"]
        md["mission-define"] --> mfile["project/mission.md"]
        mr["mission-revise"] -. lifecycle flips .-> mfile
    end

    subgraph cycle["Per-sprint cycle"]
        rp["roadmap-planner"]
        fd["feature-decompose"]
        fcr(["feature-consistency-reviewer"])
        sp["sprint-plan"]
        se["sprint-execute"]
        sr["sprint-review"]

        rp --> fd
        fd -. dispatches .-> fcr
        fd --> ffiles["project/features/"]
        ffiles --> sp
        sp --> sfiles["project/sprints/"]
        sfiles --> se
        se --> sr
    end

    aud --> md
    goals --> md
    rmap --> rp

Stadium-Form (feature-consistency-reviewer) markiert den einzigen Agent in der Suite; alle Rechtecke sind Skills oder On-disk-Artefakte. Gestrichelte Kanten markieren Dispatch- oder Lifecycle-Beziehungen, durchgezogene Kanten markieren Schreib-Operationen.

Skill-zu-Stage-Karte¶

Stage	Skill	Schreibt / liest	Govering Spec
Foundation	`audience-identify`	schreibt das Audience-Artefakt (typischerweise `AUDIENCES.md`)	`audience-identification`
Foundation	`roadmap-init`	schreibt `project/roadmap.md` und `project/goals.md`	`roadmap`
Mission	`mission-define`	schreibt erstmals `project/mission.md`, setzt `mvp_status: defining`	`mission`
Mission	`mission-revise`	editiert `project/mission.md`, flippt `mvp_status` (mit Stabilisierungs-Gate)	`mission`
Per-sprint cycle	`roadmap-refine`	enforced Detail-Level-Invariante; emittiert Violations	`roadmap`
Per-sprint cycle	`roadmap-planner`	fügt Items hinzu, promoviert Detail, flippt `mvp`	`roadmap`, `mission`
Per-sprint cycle	`feature-decompose`	schreibt `project/features/<slug>.md`; dispatcht `feature-consistency-reviewer`	`feature`
Per-sprint cycle	`sprint-plan`	schreibt `project/sprints/<NNNN>-<slug>.md` mit `status: planned`	`sprint`
Per-sprint cycle	`sprint-execute`	promoviert `planned → active`, treibt Feature-Übergänge, schreibt `last_commit`	`sprint`, `feature`
Per-sprint cycle	`sprint-review`	promoviert `active → review → closed` mit Artefakt-Validation	`sprint`, `release-artifact`

Der Agent: `feature-consistency-reviewer`¶

Wird ausschließlich von feature-decompose aufgerufen, niemals direkt vom Operator. Read-only-Tools (Read, Grep, Glob, Bash); produziert eine strukturierte Findings-Liste, die der Eltern-Skill in das consistency_check-Frontmatter und die ## Consistency notes-Section eines Features schreibt. Das draft → ready-Gate des Features bleibt zu, solange ein overlap- oder duplication-Finding ohne Resolution offen ist.

Optionale Release-Chain am Sprint-Ende¶

sprint-review kann am Sprint-Abschluss optional in zwei bestehende Skills chainen — operator-opt-in, niemals automatisch:

release-notes-curate — reichert den offenen release-drafter-Draft mit projekt-typ-spezifischen Sections an.
release-publish-trigger — validiert die Pre-Publish-Gates und löst release-publish.yml per gh workflow run aus.

Die Chain-Entscheidung (chained oder skipped) MUSS wortgetreu in ## Review notes festgehalten werden — egal in welche Richtung.

Wann Adoption sich lohnt¶

Die Suite zahlt sich aus, sobald ein Hobby-Projekt mehr als ein paar Releases ausliefert und der Bedarf entsteht, „warum bauen wir das eigentlich?" formell zu beantworten. Für ein Repository, das ausschließlich Bibliothek oder Tool ohne klare User-Audience ist, sind Audience-Identifikation und Mission Statement Overhead — die Specs erlauben Abwesenheit ausdrücklich.

Eine Adoption beginnt typischerweise so:

audience-identify ausführen, das Artefakt committen.
roadmap-init ausführen, goals.md und roadmap.md befüllen.
Erst wenn ein klarer Mehrwert für eine konkrete Audience entsteht: mission-define anstoßen.
Pro Sprint dann nur die drei Sprint-Skills (sprint-plan → sprint-execute → sprint-review) plus feature-decompose bei Bedarf.

roadmap-refine und roadmap-planner werden punktuell aufgerufen, nicht in jedem Sprint.