snuffish/plan

Skill: /plan — Verwaltung von Implementierungsplänen

Verwaltet den aktiven Implementierungsplan (<prefix>-implementation_plan-<suffix>.md) für die Sitzung. Dieses Skill besitzt das Skelett des Plans, seine Statuswerte, seinen Link-Block und seine Überprüfung (--review). Jeder andere Befehl, der einen Plan schreibt oder liest (/implement-feature, /problem, /refine, /pr-fix-pipeline, /proceed), verwendet die hier definierten Elemente.

---

Module

Die Pfade sind relativ zum tatsächlichen Ordner dieses Skills. Führe realpath auf dem Basisverzeichnis des Skills einmal aus (es kann ein Symlink sein) und löse dann jeden Pfad von dort aus auf. Wenn ein Modul nicht gelesen werden kann, stoppe und melde den Pfad. Fahre nicht ohne es fort.

Vor Schritt 1 lesen:

• ../_modules/core.md
• ../_modules/artifact-protocol.md: schreibt <prefix>-implementation_plan-<suffix>.md im Artefaktverzeichnis (artifact-protocol)
• ../_modules/project-profile.md: nur Basisprofil (kein Befehlsprofil), für die Überprüfung (Fall D); liest References per layer, Contract touchpoints, Sibling chain und ein optionales Plan-review checks-Feld

Ad-hoc-Referenzen (references/):

• references/review.md — fünf Überprüfungssäulen (Fall D Schritt 3) und Berichtsvorlage für --review (Fall D) und Selbstüberprüfung (Fall B Schritt 4)

---

1. Der Planvertrag

Statuswerte

Die zweite Zeile eines Plans trägt **Status:** <Wert>, mit einem der folgenden:

Wert	Bedeutung	Gesetzt durch
Draft	Wird geschrieben; noch nicht zur Überprüfung bereit	Der Schreiber, während des Entwurfs
Awaiting User Review	Vollständig und wartet auf Freigabe	Der Schreiber, beim Präsentieren
Approved	Der Benutzer hat das Tor geöffnet; Implementierung läuft	core › Das /proceed-Tor
Completed	Jede Phase im Umfang ist abgeschlossen und verifiziert	core › Das /proceed-Tor

Ein kurzer Hinweis kann dem Wert folgen (Approved — Phase 2 von 3 abgeschlossen). Leser gleichen nur den führenden Wert ab.

Skelett

<!-- artifact-owner: … -->                 <!-- artifact-protocol › Claim -->

# Implementierungsplan: <Titel>

**Status:** Awaiting User Review
**Suffix:** `<suffix>`
**Inputs:** <Untersuchungs-/Überprüfungs-/Ticketlinks oder „none“>
**Review:** <_Fall D_-Urteil nach Integration> · <n> integrierte Befunde <!-- Fall B Schritt 4 -->

## 1. Kontext & Ziel

## 2. Entscheidungen <!-- Tabelle: Entscheidung · Grund -->

## 3. Vorgeschlagene Änderungen <!-- pro Phase oder pro Repository: [NEW|MODIFY|DELETE] <Pfad> — was und warum -->

## 4. Verifikationsplan <!-- genaue Befehle, plus manuelle Schritte -->

## 5. Risiken <!-- Tabelle: Risiko · Maßnahme -->

## 6. Aufgabenliste <!-- die Live-Checkliste: [ ] / [/] / [x] -->

## 7. Offene Fragen <!-- unbeantwortete Fragen; immer zuletzt, falls vorhanden; jede mit einer Empfehlung -->

Ein Befehl kann eigene Abschnitte hinzufügen (/implement-feature fügt User Review Required, Blind-spot Pass und Cross-repo order hinzu). Er behält diese sieben Abschnitte in dieser Reihenfolge, damit /plan, /plan --review und /proceed sie finden können. Open Questions (unbeantwortete Fragen) ist immer der letzte Abschnitt; ein hinzugefügter Abschnitt kommt davor.

Stil

Die Benutzerregel (~/.claude/CLAUDE.md › Plan Mode) gilt: äußerst prägnant, Grammatik geopfert; endet mit Schritten, dann Unbeantworteten Fragen (jeweils mit einer Empfehlung, weggelassen wenn keine vorhanden).

Jeder Planersteller wendet sie auf die gesamte Datei und auf die Chat-Antwort an, die den Plan präsentiert:

• Fragmente, keine Prosa: keine Absätze, keine vollständigen Satzerklärungen.
• Eine Idee pro Aufzählungspunkt; teile einen längeren in Unterpunkte auf.
• Entscheidungen und Risiken als Tabellen.
• Jede offene Frage trägt Empf.: mit der empfohlenen Antwort.
• Nichts nach Offene Fragen. Wenn es keine unbeantworteten Fragen gibt, notiere „Keine“ (oder lasse es weg).

Link-Block

Jede Chat-Antwort, die einen Plan präsentiert, beginnt mit dem artifact-protocol › Chat Link-Block (echte Zeilennummern aus grep -n '^#{1,3} ' <Datei> nach dem Schreiben), der auf Context & Goal, Proposed Changes, Verification Plan und Open Questions verweist, gefolgt von **Status:** <Wert>. Ein Befehl kann nach jedem Abschnittslink eine einzeilige Zusammenfassung anhängen (/plan --review tut das).

---

2. Kernverhalten

Wähle den Fall anhand der Argumente aus, erster Treffer gewinnt:

Argumente	Fall
Enthalten --review	D: Plan überprüfen
Beginnen mit preview	C: Vorschau
Keine	A: bloß
Alles andere	B: Entwurf oder Aktualisierung

Fall A: Bloßer Befehl (/plan ohne Argumente oder Nachricht)

1. Plan lokalisieren: Scanne nach <prefix>-implementation_plan-*.md im Artefaktverzeichnis (artifact-protocol) und wähle die Familie gemäß artifact-protocol › Claim › Readers & family selection aus (teile dem Benutzer mit, dass er die Eingabeaufforderung beim nächsten Mal mit /plan <Suffix> überspringen kann). Wenn keiner existiert, sage dies und biete an, einen aus der nächsten Benutzereingabe zu erstellen.
2. Link-Block rendern (§1 Link-Block) für den gewählten Plan, mit seinem aktuellen Status. Bearbeite nichts und führe keine Hintergrundbefehle aus.

Fall B: Befehl mit Anweisungen (/plan <Anweisungen>)

1. Kontextuelles Suffix auflösen gemäß artifact-protocol › Regel 2.
2. Planen, ohne Code zu ändern:
   • Überprüfe zuerst auf eine bestehende Untersuchung. Wenn <prefix>-investigation-<suffix>.md im Artefaktverzeichnis (artifact-protocol) existiert und dieses Thema abdeckt, baue darauf auf: seinen Plan Seed, Options & Trade-offs und Confidence Ledger. Führe keine Recherche erneut durch, die es bereits dokumentiert; löse alle ❓ Unknown auf, von denen der Plan abhängt.
   • Andernfalls recherchiere den relevanten Code schreibgeschützt. Wenn das Thema umfangreich ist oder die Unbekannten erheblich sind, führe zuerst /investigate aus.
   • Entwerfe gemäß den eigenen Konventionen des Projekts: seinen Arbeitsbereichsregelwerken, projektspezifischen Referenzen und Profil (core › Precedence).
3. Plan schreiben im §1 Skelett, im Artefaktverzeichnis (artifact-protocol):
   • Neuer Plan: Entwurf in einem sitzungsprivaten Pfad, dann veröffentliche ihn mit Claim (artifact-protocol › Regel 4). Wenn der Basisname bereits vergeben ist, schreibt Claim …-2.md; verwende den Pfad, den es ausgegeben hat, und teile dies im Chat mit.
   • Bestehender Plan: Aktualisiere ihn nur, wenn sein Eigentümermarker auf diese Sitzung verweist, oder wenn der Benutzer diese Datei genannt und um ihre Aktualisierung gebeten hat (artifact-protocol › Regel 3). Andernfalls schreibe eine neue Revision über Claim und verlinke die ersetzte in Inputs.
   • Setze Status auf Awaiting User Review, wenn er vollständig ist. Unter Antigravity, wenn eine gespiegelte Artefaktkopie innerhalb <appDataDir>/brain/<conversation-id>/ geschrieben wird, setze UserFacing = true und RequestFeedback = true in ArtifactMetadata (lasse ArtifactMetadata bei der Artefaktverzeichnisdatei weg).
4. Selbstüberprüfung vor der Präsentation: Lese references/review.md und führe Fall D Schritte 2–3 für den gerade geschriebenen Plan im Hauptkontext aus. Verwende seine Säulen und Schweregrade. Drucke seinen Bericht oder sein Tor nicht: dies ist Teil des Entwurfs, und der Benutzer überprüft den integrierten Plan.

   • Integriere jeden Befund vor der Präsentation in den Plan:

     Befund	Geht ein in
     🔴 / 🟡, verifiziert (path:line erneut geöffnet)	Proposed Changes, Task Checklist und eine Verification Plan-Prüfung, die ohne die Korrektur fehlschlägt
     🔴 / 🟡, die eine Benutzerentscheidung benötigt	Open Questions, mit Empf.:
     🟢	Anwenden, wenn eine Zeile; sonst verwerfen
     Abgewiesener Befund	Risks, eine Zeile mit dem Grund

   • Lies den Plan einmal auf alles, was eine Korrektur widerspricht (einen früheren Schritt, einen Test, eine Entscheidungszeile), und korrigiere es.

   • Führe die Überprüfung einmal durch. Fülle die Review:-Kopfzeile mit dem Urteil, das der integrierte Plan erhalten würde.

   • Führe sie bei jedem neuen Plan und bei jeder Aktualisierung durch, die Vorgeschlagene Änderungen oder den Verifikationsplan ändert. Überspringe sie bei einer Aktualisierung, die nur die Checkliste abhakt oder den Status ändert.

5. Plan präsentieren: den Link-Block (§1 Link-Block), das Überprüfungsurteil und die Befunde, die das Design geändert haben (jeweils ein Aufzählungspunkt), die wichtigsten Entscheidungen als Fragment-Aufzählungspunkte, dann die offenen Fragen zuletzt, jede mit ihrer Empf.: (§1 Stil gilt auch für diesen Chat-Text: keine Absätze, keine vollständigen Sätze). Warte darauf, dass der Benutzer das Tor öffnet (core › Das /proceed-Tor), bevor du eine Codeänderung vornimmst.

Fall C: Vorschau-Befehl (/plan preview [Ziel])

Zeigt einen vorhandenen Plan im Planungsvorschau-Panel des Hosts (mit ExitPlanMode, wenn verfügbar), damit der Benutzer ihn interaktiv lesen, kommentieren und genehmigen kann.

1. Plan auflösen: Verwende Argument (Pfad oder Suffix), die aktive Plan-Datei der Sitzung oder die neueste Plan-Familie im Artefaktverzeichnis (Fall A).
2. Host-Fähigkeitsprüfung: Wenn dem Host ExitPlanMode fehlt (z. B. Antigravity IDE), gib den Link-Block des Plans aus (Fall A) und erkläre, dass der Host Pläne direkt über Markdown-Links rendert.
3. Plan-Modus betreten & kopieren: Rufe EnterPlanMode auf, lies den Host-Plan-Dateipfad aus der Systemnachricht und kopiere den Quellplan hinein (ohne den führenden <!-- artifact-owner: … -->-Kommentar).
4. Vorschau öffnen: Rufe ExitPlanMode auf.
5. Entscheidung behandeln:
   • Genehmigen: Benutzer hat die Implementierung autorisiert (core › Das /proceed-Tor). Beginne mit der Ausführung.
   • Weiter planen / Feedback: Bleibe im Plan-Modus, leite Feedback an Fall B weiter, um den Plan zu aktualisieren, und öffne die Vorschau erneut.
   • Geschlossen / Fehler: Melde den Status und gib den Dateilink an.

Fall D: Überprüfungsbefehl (/plan --review [Ziel])

Strenge, schreibgeschützte Überprüfung eines Implementierungsplans, Architekturvorschlags oder Änderungsentwurfs, bevor Code geschrieben wird. Schreibgeschützt bis /proceed (core › Das /proceed-Tor):

• Bearbeite niemals Dateien, führe keine modifizierenden Befehle aus (Migrationen, Commits, Gerüstbau) und beginne nicht mit der Implementierung, selbst wenn der Plan einwandfrei ist.
• Jede Antwort unter --review, einschließlich Folgeantworten, beginnt mit dem Link-Block: Der Benutzer schließt oft den Plan-Tab und öffnet ihn erneut aus dem Chat.

Falsches Werkzeug:

Situation	Stattdessen verwenden
Ein Code-Diff, Branch oder PR anstelle eines Plans	/code-review
Review-Kommentare und -Stimmen zu einem PR	/pr-feedback-review
Recherche, bevor ein Plan existiert	/investigate
Versteckte Annahmen und Fehlermodi eines Designs	/what-am-I-missing

Lies references/review.md und führe Fall D Schritte 1–4 aus (Schritt 1: Plan lokalisieren; Schritt 2: Projektregeln lesen; Fall D Schritt 3: anhand der fünf Säulen + Profil Plan-review checks bewerten; Schritt 4: Link-Block und Überprüfungsbericht rendern), warte dann am core › Das /proceed-Tor.