magnus919/agent-skills

BMad: Absicht-zu-Auslieferungs Steuerungsebenen-Protokoll

BMad ist eine Software-Auslieferungsmethode, die auf einer Idee basiert: Menschliche Absicht sollte zunehmend geklärt, aufgezeichnet, überprüft und Agenten als dauerhafter Kontext übergeben werden, anstatt in Chat improvisiert zu werden. Dieser Skill verwandelt diese Methode in ein Protokoll, dem jeder Agent-Harness folgen kann – kein offizieller BMad-Installer erforderlich.

Der Kreislauf: Klassifizieren der Anfrage → Komprimieren der Absicht in einen Vertrag → Routen zum kleinsten sicheren Pfad → Implementieren einer begrenzten Einheit → Überprüfen als Triage → Weiterleiten von Fehlern an die Ebene, auf der die Mehrdeutigkeit entstanden ist → Begrenzen der Autonomie auf beobachtbare Akzeptanz → Lernen aus abgeschlossener Arbeit.

Wann dieser Skill verwendet werden sollte

Laden, wenn ein Change Request, Feature, Fehlerbericht, delegierter Build oder ein Multi-Agent-Epic Folgendes benötigt:

• Absichtserfassung vor der Implementierung – ein Vertrag, keine Stimmung;
• eine Entscheidung darüber, wie viel Zeremonie die Arbeit verdient;
• dauerhafte Artefakte, damit die Arbeit über Sitzungen oder Agenten hinweg fortsetzbar ist;
• eine Überprüfung, die Ergebnisse triagiert, anstatt Rauschen aufzuzählen;
• Autonomie, die sicher anhält, wenn die Grenze unsicher ist.

Arbeitsklassifikation (kleinster sicherer Pfad)

Klasse	Form	Prozess
Direkt	klares Ziel, lokale Änderung, etablierte Muster, kleiner Wirkungsbereich	sofort nach minimaler Klärung implementieren
Begrenzt	kohärente Änderung, die einen kurzen Vertrag und Plan benötigt	Absichtsvertrag → Plan → Implementieren → Überprüfen
Initiative	komponentenübergreifend, mehrere Stories, hohes Risiko oder strategisch unsicher	Analyse → Planung → Lösungserstellung → Implementierung → Lernen

Lade references/classification.md für die Entscheidungstabelle, die Ein-Fragen-Regel und Abbruchbedingungen.

Der Absichtsvertrag (fünf Felder)

Für begrenzte oder initiative Arbeit vor der Implementierung einen Vertrag aufsetzen:

1. Warum – das Ergebnis und warum es wichtig ist.
2. Fähigkeiten – was das System können muss.
3. Einschränkungen – technische, operative, rechtliche, sicherheitsrelevante, datenschutzbezogene, zeitliche, kostenbezogene, organisatorische Grenzen.
4. Nicht-Ziele – was explizit nicht im Umfang enthalten ist.
5. Erfolgssignal – wie wir wissen, dass das Ergebnis funktioniert und akzeptabel ist.

Wenn ein Feld materiell mehrdeutig ist, stelle eine hochwirksame Frage, schlage eine empfohlene Antwort vor und warte auf die Entscheidung. Für triviale Änderungen kann der Vertrag fünf Stichpunkte im Gespräch sein; für größere Arbeiten wird es eine versionierte Spezifikationsdatei.

Lade references/spec.md für die SPEC-Erstellung und das Statusvokabular. Vorlagen: templates/SPEC.md und templates/INTENT.md.

Der kanonische Kreislauf

1. Untersuche das Repository und den verfügbaren Kontext, bevor du etwas fragst.
2. Klassifiziere die Arbeit; gib den vorgeschlagenen Weg an.
3. Erstelle oder setze den Absichtsvertrag fort; stelle höchstens eine materielle Frage.
4. Präsentiere einen Plan für nicht-triviale Arbeit; warte am Genehmigungs-Checkpoint.
5. Implementiere die kleinste kohärente Änderung; führe zuerst gezielte Tests durch, dann breitere Prüfungen.
6. Überprüfe auf Korrektheit, Umfang, Sicherheit, Regressionen, Wartbarkeit.
7. Behebe Befunde, die zu dieser Änderung gehören; verschiebe nicht zusammenhängende Befunde explizit.
8. Berichte über Absicht, Verhalten, Dateien, Risiko, Verifikation, Befundbehandlung und eine Auswahl zwischen Akzeptieren / Überarbeiten / Untersuchen.

SPEC-Statusvokabular

Maschinenlesbarer Status für fortsetzbare Arbeit:

Status	Bedeutung
draft	Spezifikation existiert, ist aber nicht bereit
ready-for-dev	Bereitschaft bestanden; bereit zur Implementierung
in-progress	Implementierung läuft
in-review	Überprüfung oder Triage läuft
done	Workflow erfolgreich abgeschlossen
blocked	Kann nicht sicher unbeaufsichtigt fortgesetzt werden

blocked ist ein Routing-Signal, kein Fehler: Ein Orchestrator auf höherer Ebene, ein anderer Workflow oder ein Mensch übernimmt. Validiere eine Spezifikation deterministisch mit scripts/check-spec.py.

Fehler-Routing

Wenn etwas falsch ist, diagnostiziere die Ebene, auf der der Fehler eingetreten ist:

Fehler	Route
Falsches Ergebnis oder falsches Problem	Absicht / Analyse
Fehlende oder widersprüchliche Anforderung	Vertrag / Planung
Konfliktreicher technischer Ansatz	Architektur
Falscher lokaler Code	Implementierung
Unzureichender Test oder Bewertung	Verifikation
Nicht zusammenhängendes, bereits bestehendes Problem	Explizit verschieben
Unsichere Mehrdeutigkeit	Blockieren und fragen

Patche nicht weiter am Code, wenn die Spezifikation das eigentliche Problem ist.

Autonomie-Gate

Autonome Ausführung ist nur erlaubt, wenn all dies zutrifft: Absichtsvertrag kohärent, Akzeptanz beobachtbar, Grenze explizit, Repository sicher zu ändern, Tests oder Bewertungen ausführbar, dauerhafter Status beschreibbar, Eskalation definiert. Während autonomer Arbeit: eine kohärente Änderung nach der anderen; niemals den Umfang auf nicht zusammenhängende Verbesserungen erweitern; niemals zusammenführen, bereitstellen oder externe Systeme ohne Autorisierung ändern; anhalten bei Absichtslücken, fehlender Fähigkeit, destruktiver Mehrdeutigkeit, fehlgeschlagener Verifikation oder nicht konvergenter Reparatur.

Referenzdateien

Referenz	Laden, wenn
references/protocol.md	Du das vollständige, einfügebereite Betriebsprotokoll für einen Agenten benötigst
references/classification.md	Du eine Anfrage klassifizierst oder die Zeremonientiefe wählst
references/spec.md	Du eine SPEC / einen Absichtsvertrag schreibst oder fortsetzt
references/lifecycle.md	Du eine Initiative durch alle vier Phasen führst
references/project-context.md	Du Repository-Regeln (AGENTS.md) einrichtest oder überprüfst
references/review-and-failure-routing.md	Du eine Überprüfung durchführst oder einen Fehler diagnostizierst
references/autonomy.md	Du autonome (Build Auto) Arbeit konfigurierst oder ausführst
references/party-mode.md	Du Diskussionen, Abwägungen, Design-Debatten, Post-Mortems benötigst
references/adoption.md	Du das Protokoll inkrementell einführst oder einer Dark Factory zuordnest

Vorlagen

Vorlage	Zweck
templates/SPEC.md	Versionierter Maschinenvertrag für begrenzte/initiative Arbeit
templates/INTENT.md	Leichter Fünf-Felder-Vertrag für begrenzte Arbeit
templates/STORY.md	Eine begrenzte, dispatchbare Arbeitseinheit
templates/REVIEW.md	Finaler menschlicher Checkpoint: Absicht → Verhalten → Risiko → Verifikation

Skripte

Skript	Ausführen, wenn
scripts/check-spec.py	Nach dem Schreiben oder Bearbeiten einer Spezifikation: Validiere fünf Felder + Statusvokabular (nur stdlib, --json Ausgabe)

Routing zu angrenzenden Skills

• Upstream (vor BMad): product-discovery validiert, ob ein Problem real ist; product-shaping setzt einen Appetit und erzeugt ein Pitch; product-strategy und product-roadmapping-and-portfolio geben den strategischen Kontext.
• Downstream (während BMad): spec-driven-development für formale Spezifikations-/Gate-Pipelines; implementation-planning für einen abhängigkeitsbewussten Auslieferungsplan; adr-authoring für Architekturentscheidungen; software-architecture-analysis für Reverse-Engineering einer bestehenden Codebasis.
• Ausführung und Gates: neckbeard für den Issue-to-PR-Auslieferungsablauf; verification-methodology für Akzeptanznachweise; qa-methodology für Teststrategie; agent-evals-and-observability für unabhängige Evaluatoren; agent-council für Party-Mode-artige Multi-Agenten-Diskussion; release-engineering für Bereitstellungs-Gates; kanban-guru für Backlog- und Dispatch-Richtlinien.

Wann nicht verwenden

• Das Problem selbst ist nicht validiert → product-discovery. BMad komprimiert Absicht; es stellt nicht fest, ob das Problem real ist.
• Noch keine Entscheidung, wie viel die Arbeit wert ist → zuerst product-shaping (Appetit, Pitch, Wette). BMad beginnt mit einer platzierten Absicht.
• Du benötigst ein formales Spezifikationsformat plus Phasen-Gates als Fabrik-Pipeline → spec-driven-development besitzt das SPEC-Format und die Gate-Mechanik; BMad stellt das Steuerungsebenen-Protokoll darum herum bereit.
• Du führst einen Issue-to-PR-Auslieferungsablauf mit eigenen Gates aus → neckbeard. BMad ergänzt ihn; führe nicht zwei konkurrierende Auslieferungslebenszyklen.
• Du benötigst eine unabhängige Überprüfung → Rollenspiel ist keine Unabhängigkeit. Verwende agent-council, separate Evaluatoren oder agent-evals-and-observability; behaupte niemals, dass Persona-Trennung eine unabhängige Überprüfung sei.
• Betrieb des offiziellen BMad-Installers/Toolings → dieser Skill emuliert die Methode; er installiert oder betreibt keine bmad-method npm-Pakete.

Versionsdrift und Zuordnung

BMad entwickelt sich aktiv weiter (offizielles Repository: bmadcode/bmad-method; BMAD™ und BMAD-METHOD™ sind Marken von BMad Code, LLC). Ältere Artikel unterscheiden sich in Namen, Agenten, Dateinamen und Befehlen. Bei der Installation des offiziellen Toolings betrachte die offizielle Dokumentation und die installierte Quelle als maßgeblich. Dieser Skill ist eine originäre Destillation der Methode als harness-agnostisches Protokoll; er reproduziert keine offiziellen Installationsinhalte.