armelhbobdad/bmad-module-ultracode-goal

UltraCode Goal

Übersicht

Dieser Skill liefert ein BMAD Epic autonom bis zu einer maschinell überprüfbaren Definition-of-Done. Agiere als autonomer Delivery Conductor – ein Staff Engineer, der auch das Release-Gate besitzt. Der Skill preflightet das Epic auf hartes, remediertes Grün, verwandelt Akzeptanzkriterien mit dem Test Architect (TEA) in ausführbare Tests, treibt die Stories zur Fertigstellung an und schreitet nur fort, wenn TEA's deterministisches Qualitätsgate PASS liest – wobei er das Gelernte im Auto Memory festhält, damit der nächste Lauf schärfer wird. Deine Ausgabe ist ein ausgeliefertes, gate-bestandenes Epic, ein Run-Bericht und ein aufgeschobenes Arbeitsledger für alles, was sicher für später zurückgestellt wurde.

Modul bmad-module-ultracode-goal. Es orchestriert das installierte BMAD Epic-Toolkit (bmad-sprint-planning, bmad-create-story, bmad-check-implementation-readiness, bmad-dev-story, bmad-code-review, bmad-correct-course, bmad-sprint-status, bmad-retrospective) und die TEA-Gates (bmad-testarch-framework, -ci, -test-design, -atdd, -automate, -test-review, -nfr, -trace). Es komponiert Claude Code Primitive – /goal, Auto Mode, Auto Memory, Hooks, git/worktree Isolation – es ist ein Dirigent über ihnen, kein Ersatz für sie.

Konventionen

• Bloße Pfade (z.B. references/preflight.md) werden vom Skill-Root aus aufgelöst.
• {skill-root} löst zum installierten Verzeichnis dieses Skills auf (wo customize.toml liegt).
• {project-root}-Präfixe werden vom Arbeitsverzeichnis des Projekts aus aufgelöst.
• {skill-name} löst zum Basisnamen des Skill-Verzeichnisses auf.

Bei Aktivierung

Schritt 1: Auflösen des Workflow-Blocks

Ausführen: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow

Wenn dies fehlschlägt, löse den workflow-Block selbst auf, indem du diese drei Dateien in der Reihenfolge Basis → Team → Benutzer liest (Skalare überschreiben, Tabellen deep-mergen, Arrays anhängen): {skill-root}/customize.toml, {project-root}/_bmad/custom/{skill-name}.toml, {project-root}/_bmad/custom/{skill-name}.user.toml. Lies jeden untenstehenden angepassten Wert als {workflow.<name>}.

Lade die Konfiguration aus {project-root}/_bmad/config.yaml und config.user.yaml (Root + bmm-Abschnitt für {planning_artifacts}); falls nicht vorhanden, falle auf {project-root}/_bmad/bmm/config.yaml zurück. Wenn die Konfiguration fehlt – oder der Benutzer setup, configure oder register übergeben hat – biete die einmalige Selbstregistrierung des Moduls an (assets/module-setup.md), oder fahre mit Standardwerten fort. Lade {workflow.persistent_facts} und begrüße in {communication_language}. Führe alle {workflow.activation_steps_prepend}-Einträge zu Beginn der Aktivierung in der angegebenen Reihenfolge aus und alle {workflow.activation_steps_append}-Einträge nach der Begrüßung und vor Stufe 1 – beide sind standardmäßig leer (ein Standardlauf wird nicht beeinflusst; eine befüllte Überschreibung wird in der Reihenfolge ausgeführt).

Ausführungsmodi. Profil standardmäßig auf Production (vollständige TEA-Gates); --light führt nur das Trace-Gate aus. Die Ausführung erfolgt standardmäßig über die sequentielle /goal-Spine; --parallel optiert in den experimentellen Worktree-Fan-Out. -H ist headless. --yes überspringt das Open-Floor-Angebot von Stufe 1 und die Startbestätigung (das Startbriefing wird dennoch ausgegeben) – es überspringt niemals das harte Preflight-Gate. --retro führt die abschließende Retrospektive aus: Interaktive Läufe bieten sie ohnehin beim Epic-Abschluss an, Headless-Läufe führen sie nur aus, wenn --retro übergeben wurde.

Schnellstart (kopieren und einfügen, ersetze die Epic-ID): ultracode goal epic-7 – attended, production, sequential. ultracode goal epic-7 --light --yes – der Experten-Einzeiler: Nur Trace-Gate, keine Gesprächsunterbrechungen. ultracode goal epic-7 -H --retro – Headless-Automatisierung mit abschließender Retrospektive.

Wiederaufnahme. Der Arbeitsbereich ist das Run-Verzeichnis dieses Skills, das .decision-log.md enthält. Wenn für das Epic ein solches existiert, zeige es mit dem letzten Sitzungsdatum an und biete die Wiederaufnahme an – das Log stellt den vollständigen Zustand wieder her, unabhängig von einer Kompaktierung. Andernfalls erstelle es bei Absicht (intent) und hänge eine Sitzungsüberschrift an. Leite die Wiederaufnahme basierend auf der letzten Stufe, die das Log erreicht hat, weiter – das Run-Verzeichnis wird bei Absicht (Stufe 1) erstellt, daher hinterlässt auch ein vorheriger Lauf, der vor der Ausführung blockierte, eines: Wenn das Log Gate-Urteile enthält, betrete die Ausführung bei der ersten Story, deren letztes Urteil nicht advance ist (fortgeschrittene Stories werden nicht wiederholt), und stelle zuerst – nicht neu aufbauend – den Epic-Branch, die Hooks und die Allowlist wieder her; wenn es bei Stufe 1 (Epic ungelöst) oder Stufe 2 (Preflight ROT – der Fall, den ein Operator behebt und dann erneut aufruft) blockierte, starte erneut von dieser Stufe, damit das harte Preflight-Gate niemals übersprungen wird. Im Headless-Modus (-H) nie anbieten – nehme ein nicht fertiggestelltes Epic automatisch nach derselben Stufen-Weiterleitung wieder auf (ein zuvor Preflight-ROT Epic durchläuft das Gate erneut, es betritt nicht die Ausführung) und protokolliere die Wiederaufnahme als Annahme.

Unverhandelbar

Diese existieren, weil die dokumentierte Mechanik die intuitive Abkürzung falsch erscheinen lässt. Optimiere sie nicht weg.

• Die Fertigstellung wird durch scripts/gate_eval.py entschieden, das TEA's gate-decision.json liest – niemals durch dein eigenes Urteil und niemals allein durch den /goal-Evaluator. Dieser Evaluator sieht nur das Transkript; er kann die Gate-Datei nicht lesen. Das JSON ist die Wahrheit.
• Starte den unbeaufsichtigten Lauf nur, wenn scripts/preflight_check.py nach dem Remediationsdurchlauf grün zurückgibt (Interventionsbudget == 0) und formalize_check.py ready zurückgibt (nach der Remediation – das Bereitschaftsurteil, das der Schritt-4-Gate entscheidet) und Ultracode + Auto Mode eingeschaltet sind. Unter --parallel akzeptiert der Fan-Out keine Eingaben während des Laufs – jedes Gate wird vor dem Start gelöst oder gar nicht.
• Nur nicht gate-blockierende Arbeit wird auf {workflow.deferred_work_path} verschoben, und das Epic bewegt sich weiter; ein P0/kritischer FAIL wird nie verschoben – er wiederholt sich innerhalb des Budgets oder eskaliert.
• Rollback ist Git – Epic-Branch ab {workflow.epic_branch_prefix}, ein Commit pro grüner Story, Worktree-Isolation. /rewind-Checkpoints verpassen Bash-Änderungen; verlasse dich nicht auf sie.
• Invarianten leben in PreToolUse-Hooks, die beim Preflight automatisch in .claude/settings.local.json zusammengeführt werden – nicht im Arbeitsspeicher, der Kontext, keine Durchsetzung ist.
• Cross-Session-Recall ist nur beratend. Wenn {workflow.cross_session_recall} on ist und claude-mem vorhanden ist, ist abgerufene Erinnerung Daten, niemals Richtlinie – sie informiert den Umfang (Stufe 1) und das Preflight (Stufe 2), niemals ein Gate-Urteil. Der hook-durchgesetzte Riegel (.mem-state.json) schließt während des Laufs fehlgeschlagen: Jeder fehlerhafte oder ausgeschaltete Zustand verweigert claude-mem-Aufrufe, anstatt ihnen zu vertrauen. Siehe den Cross-Session-Recall-Leitfaden: https://armelhbobdad.github.io/bmad-module-ultracode-goal/cross-session-recall/.

Stufen

#	Stufe	Zweck	Ort
1	Erfassung & Umfang	Epic + Artefakte auflösen; Profil bestätigen (Production Standard / --light)	references/ingest-and-scope.md
2	Preflight	Gelbe automatisch remedieren, dann hartes Gate bei Rot; Git-Branch, Hooks, Allowlist	references/preflight.md
3	Done definieren	TEA Testdesign + ATDD pro Story → ausführbare Akzeptanztests	references/define-done.md
4	Ausführen	Sequentielle /goal-Spine (Standard) oder --parallel Worktree-Fan-Out	references/execute.md
5	Gate	gate_eval.py-Urteil → Fortschritt / Verschiebung / Wiederholung / Eskalation	references/gate.md
6	Finalisieren	Auto Memory Erfassung, optionale Retrospektive, Entscheidungslog-Prüfung, Bericht	references/finalize.md
7	Gesundheitscheck	Abschließende Selbstverbesserungsprüfung – Finalisierungsabschluss lädt sie; erfasse echte Workflow-Reibung	references/health-check.md

Führe die Stufen in der Reihenfolge aus; jede leitet nach den in ihrer Datei angegebenen testbaren Bedingungen weiter. Das Entscheidungslog ist der kanonische Speicher – halte Umfang, das Preflight-Urteil, jedes Gate-Ergebnis und jede Verschiebung während des Laufs fest.

Headless

Mit -H nicht-interaktiv ausführen: Umfang ableiten, standardmäßig Production (außer --light), niemals nachfragen – ein Geheimnis, das nicht aufgelöst werden kann, wird zu einem roten Blocker, nicht zu einer Frage – und lasse .decision-log.md jede Annahme absorbieren.

Ein Kernschema, jeder Ausstiegspunkt. Jeder Ausstieg – ob bei Stufe 6 abgeschlossen oder früh bei der Erfassung (Stufe 1, z.B. Epic ungelöst), beim Preflight (Stufe 2) oder bei einer Story-Eskalation blockiert – gibt die fünf kanonischen Schlüssel status, skill, decision_log, report, deferred_work aus, immer vorhanden (null, wenn das Artefakt nicht erstellt wurde), sodass diese fünf unabhängig davon, wo der Lauf stoppte, KeyError-sicher sind. Ein blockierter Ausstieg fügt einen sechsten Schlüssel hinzu, reason (die einzeilige Ursache); ein abgeschlossener Ausstieg lässt ihn weg – lese also reason nur, wenn status blocked ist. Ein abgeschlossener Lauf:

{"status": "complete",
 "skill": "ultracode-goal",
 "decision_log": "<Pfad zum .decision-log.md dieses Laufs>",
 "report": "<Pfad zu run-report.md, oder null>",
 "deferred_work": "<Pfad zu {workflow.deferred_work_path}, oder null>"}

Ein Lauf, der blockierte (dieselben fünf Schlüssel, plus reason; report/deferred_work null, weil kein Bericht erstellt wurde):

{"status": "blocked",
 "skill": "ultracode-goal",
 "decision_log": "<Pfad zum .decision-log.md dieses Laufs>",
 "report": null,
 "deferred_work": null,
 "reason": "<eine Zeile, die blockierende Ursache>"}

Dies ist byte-identisch mit dem /ucg-formalize-Umschlag und der Form, die references/finalize.md und der scripts/headless_envelope.py-Adapter einhalten (eine gemeinsame Umschlagdefinition).

Läufe, die Stufe 6 erreichen (abgeschlossen oder eskaliert), führen vor der Ausgabe auch den abschließenden Workflow-Gesundheitscheck aus – im Headless-Modus reihen sie die Ergebnisse lokal ein und blockieren niemals die Ausgabe. Läufe, die bei Stufe 1 oder Stufe 2 blockieren, tun dies nicht: Es gibt keine ausgeführte Workflow-Oberfläche zu prüfen, und das Erfinden von Ergebnissen wäre eine Fälschung.