hackycy/goal-loop

Goal Loop

Übersetzt Entscheidungsdokumente in drei Schicht-Artefakte:

• implementation-plan.md: Stabiler Gate-Vertrag, der beantwortet, was zu tun ist, wo die Grenzen liegen, wie verifiziert wird und wann gestoppt wird.
• goal-runbook.md: Einzigartiges Ausführungsstatus- und Beweis-Ledger, das nur beantwortet, wo die Ausführung gerade steht und welche Beweise bereits vorliegen.
• goal-prompt.md: Ein für manuelles Kopieren geeigneter fixierter Einstiegspunkt, der nur auf die beiden ersten Dokumente verweist; er bindet kein Gate und wiederholt keine Verträge.

Dieser Skill erstellt oder validiert ausschließlich die Ausführungskontrollebene, führt keine Gates aus und wiederholt keine bereits genehmigten Entscheidungen.

Eingabe lokalisieren

Der Benutzer stellt ein Effort-Verzeichnis, map.md, ADR/Spec oder einen bereits existierenden implementation-plan.md bereit. Das Git-Repository-Wurzelverzeichnis wird geparst und das Effort lokalisiert; kann es nicht eindeutig lokalisiert werden, wird abgebrochen und die geprüften Pfade werden aufgelistet.

Die relevanten CLAUDE.md, AGENTS.md, CONTEXT.md / CONTEXT-MAP.md sowie die Map, die Spec, der Implementierungsplan und die darin verlinkten lokalen ADRs, Decisions, Issues und Abnahme-Abhängigkeiten werden gelesen. CONTEXT.md liefert nur Terminologie und Bereichsfakten, generiert aber kein eigenes Gate.

Es werden zwei konvergierte Einstiege unterstützt:

• Decision-only: Gate, Umfang, Verifikation und Exit können aus akzeptierten ADRs, Spezifikationen oder gelösten Issues abgeleitet werden.
• Wayfinder: Das Feld Not yet specified der Map ist leer oder explizit „keine“, und alle an der Ausführungsreihenfolge und Abnahme beteiligten Decisions sind gelöst.

Fehlen lokale Decision-Links, sind ADRs nicht akzeptiert, Decisions nicht gelöst, oder Dokumente enthalten noch TBD, TODO, offene Fragen, ungeklärte Decisions, wird abgebrochen und jede Lücke einzeln gemeldet. Es ist nicht erlaubt, Produktentscheidungen, Abnahmerichtlinien oder Rückfallgrenzen durch Erfahrung zu ergänzen.

Plan kompilieren

Existiert implementation-plan.md nicht, wird references/implementation-plan-schema.md vollständig gelesen und aus den konvergierten Entscheidungen ein Plan erstellt. Existiert er bereits, wird er nur gelesen und validiert, nicht überschrieben.

Der Plan enthält exklusiv alle stabilen Gate-Verträge: Zielsetzung, Eingaben, Umfangsgrenzen, Einschränkungen, Slice-Richtlinie, Verifikation, Beweisregel, Abbruchbedingungen, Rollback- und Exit-Bedingungen. Projektbefehle und technische Einschränkungen werden nur in den Plan geschrieben, nicht in den fixierten Prompt.

Enthält der alte Plan einen Current Execution State, kann dieser beim Initialisieren des Runbooks einmal importiert werden; Gate-Namen, Reihenfolge und Status müssen übereinstimmen, und passed/blocked müssen bereits entsprechende Beweise enthalten. Nach dem Import wird der Plan nicht mehr aktualisiert.

Runbook kompilieren oder validieren

references/runbook-schema.md wird vollständig gelesen.

Wenn goal-runbook.md nicht existiert:

1. Gate-Nummern, Namen, Abhängigkeiten und Vertragspositionen aus dem Plan lesen.
2. Quellcode-Baseline, eindeutiges Goal-Ledger und für jedes Gate ein Fortschritts-Log schreiben.
3. Wenn kein importierbarer Status vorliegt, nur G0 als active markieren, die übrigen als planned.
4. Zielsetzung, Einschränkungen, Verifikation oder andere Gate-Verträge aus dem Plan nicht kopieren.

Wenn goal-runbook.md bereits existiert:

1. Quellcode-Pfadmenge und SHA-256 vergleichen; bei Drift des Plans oder der Entscheidungen wird das Runbook unverändert gelassen und abgebrochen.
2. Gate-Reihenfolge, Planverweise, strikt lineare Abhängigkeiten, Zustandsmaschine und Fortschritts-Log-Beweise validieren.
3. Das Ledger darf nur die Formen passed* active planned*, passed* blocked planned* oder passed+ annehmen.

Der Plan ist die alleinige Quelle für Verträge; das Runbook ist die alleinige Quelle für Status und Beweise. Beide dürfen keine Felder gegenseitig duplizieren oder Status doppelt schreiben.

Fixierten Prompt schreiben

references/goal-prompt-template.md wird vollständig gelesen, nur {{EFFORT_PATH}} wird ersetzt, und goal-prompt.md wird geschrieben oder ersetzt.

Der fixierte Prompt muss:

• innerhalb desselben Effort für alle Gates exakt identisch sein;
• keine konkreten Gates wie G0/G1, Gate-Namen oder Zielsetzungen enthalten;
• keine Eingaben, Einschränkungen, Verifikationen, Abbruch-, Rollback- oder Exit-Bedingungen ausführen;
• projektübergreifend stabile Ausführungsschleifen und Verhaltensbindungen bewahren: minimale Slice, Umfangskontrolle, Closed-Loop bei fehlgeschlagener Verifikation, Rollenaufteilung, Beibehalten nicht relevanter Implementierungen, keine Abschwächung von Tests, Abbruch bei manueller Abnahmeübergabe und Verbot von Push;
• verlangen, dass beim Start eines Goals das aktuell einzige aktive Gate gesperrt und nur dieses Gate ausgeführt wird; bei manueller Abnahme nur einmal um Bestätigung bitten, zuerst den Übergabebeweis aufzeichnen, dann mit dem vom Host-Agenten bereitgestellten Erfolgs-Endzustand das aktuelle Goal beenden (nicht als blocked, paused oder weiterlaufend markieren); schließlich ein Übergabeergebnis ausgeben, das Gate, Automatisierungsergebnis, Abnahmeeinstieg, minimale Checkliste, explizites Antwortformat und die Angabe „Goal beendet, Gate noch active“ enthält, und die normale Sitzung beenden. Dabei muss das Gate active bleiben; Folgeschritte können nur durch den Benutzer mit explizitem Abnahmeergebnis manuell ein neues Goal auslösen; wenn kein Goal-Statusmechanismus vorhanden ist, wird die aktuelle Aufgabe direkt beendet, ohne eine Warteschleife zu erzeugen. Nach dem Passieren eines Gates wird das aktuelle Gate als passed markiert, der direkte Nachfolger als active, die Beweise zusammengefasst und das gesamte Goal explizit beendet; der Nachfolger darf nicht in dasselbe Goal aufgenommen werden.

goal-prompt.md ist eine löschbare, neu erstellbare Kopierhilfsdatei. Sie gehört nicht zur Quellcode-Baseline, wird weder vom Plan noch vom Runbook referenziert und nimmt nicht an der Statusvalidierung teil.

Die abschließende Antwort teilt mit, ob kompiliert oder validiert wurde, gibt die Pfade von Plan, Runbook und fixiertem Prompt aus und gibt den Inhalt des Prompts wieder. Wenn nur Artefakte optimiert werden, darf kein Gate ausgeführt werden.