Software-Factory

Beseitigen Sie zunächst alle Unklarheiten zum Umfang. Frieren Sie die Verpflichtungen ein. Delegieren Sie jede schwere Phase an einen neuen Subagenten. Weisen Sie die Fertigstellung mit einem unabhängigen Prüfer nach, der den Code nicht geschrieben hat.

┌──────────┐   ┌──────┐   ┌────────┐   ┌───────┐   ┌────────┐
│ ENTDECKEN │ → │ PLANEN │ → │ CHECKS │ → │ BAUEN │ → │ PRÜFEN │
└──────────┘   └──────┘   └────────┘   └───────┘   └────────┘
 0 Zweifel       bestätigen  Verpfl.    Batches    Autor != Prüfer

Fünf Schritte, drei beständige Artefakte unter .specs/features/<feature>/ und ein schlanker Orchestrator im Hauptchat, der seinen Kontextfenster nie aufbläht.

ENTDECKEN: Ein schreibgeschützter scout-Subagent scannt die Codebasis und gibt eine kompakte (~30-zeilige) Zusammenfassung der Unklarheiten zurück. Der Hauptchat befragt den Nutzer mit konkreten Optionen und empfohlenen Standardeinstellungen, bis keine unbestätigten Annahmen mehr vorhanden sind (Bestätigt? j für jede Zeile). Siehe discovery.md.
PLANEN: Ein planner-Subagent schreibt .specs/features/<feature>/plan.md (Problem, Ablauf, Auswirkung, Beziehungen, Oberfläche, Landung, Kriterien, Nicht im Umfang, Annahmen, Beobachtbar, Quellen) und führt validate_plan.py aus. Der Nutzer gibt eine kurze Freigabe für plan.md. Siehe plan.md.
CHECKS: Nach der Freigabe von plan.md beginnt die automatisierte Post-Plan-Schleife. Ein specifier-Subagent leitet .specs/features/<feature>/checks.md ab (Behauptungen + Beweise, Coverage-Join, Testrichtlinie, Abgedeckt, Übergabearithmetik) und führt validate_checks.py aus. Siehe checks.md.
BAUEN: Ein builder-Subagent pro Slice/Batch schreibt Tests streng nach den Checks, implementiert den Code, führt Beweise aus, aktualisiert checks.md und committed mit check_commit.py. Siehe build.md.
PRÜFEN (und KORREKTUR-Schleife): Ein unabhängiger verifier-Subagent (niemals der Builder) prüft <feature-Basis>..HEAD gegen jeden Check, schreibt .specs/features/<feature>/verification.md und führt validate_verification.py aus. Wenn ein Check fehlschlägt, behebt ein fixer-Subagent die priorisierten Lücken und ein neuer verifier überprüft erneut (bis zu 3 Runden). Siehe verify.md und orchestration.md.

Warum diese Form

Codierungsagenten scheitern an komplexen Funktionen aus zwei vorhersehbaren Gründen:

Kontextfenster-Aufblähung: Wenn eine einzelne Chat-Sitzung das Repository durchsucht, den Benutzer befragt, den Plan schreibt, die Checks ableitet, Tests und Code schreibt und ihre eigene Arbeit verifiziert, füllt sich das Kontextfenster und löst verlustbehaftete Komprimierung aus.
Unbestätigte Anforderungen & blinde Flecken bei der Selbstprüfung: Stillschweigendes Raten des Produktverhaltens (Bestätigt? n) oder das Selbstzertifizieren der Fertigstellung durch den Autor führt dazu, dass die eigenen blinden Flecken des Autors ausgeliefert werden.

software-factory löst beides:

Schlanker Orchestrator (<15k Token im Hauptchat): Der Hauptchat fungiert strikt als Koordinator und Benutzer-Interviewer. Das gesamte Lesen der Codebasis, das Erstellen von Artefakten, das Coden, Testen und Verifizieren laufen in isolierten, ephemeren Subagenten (scout, planner, specifier, builder, verifier, fixer), die ausschließlich über .specs/features/<feature>/-Dateien auf der Festplatte und Git-Commits kommunizieren. Vollständiges Dispatch-Protokoll: orchestration.md.
Kleiner, eingefrorener Verpflichtungssatz + unabhängiger Prüfer: Es gibt keine granulare Aufgabencheckliste oder Komponentenkatalog (Zweck/Ort/Schnittstellen pro Klasse), die veralten könnte. Einweg-Türen erhalten eine wörtliche Form in Landung; umkehrbare Platzierung wird im Diff entschieden.

Kritische Regeln

Der festgelegte Satz. Diese gelten für jedes Profil:

Keine unbestätigten Annahmen (Bestätigt? j). Niemals Produkt- oder Umfangsverhalten stillschweigend erraten. Jeder Graubereich, der während ENTDECKEN auftaucht, muss mit konkreten Optionen und einer empfohlenen Standardeinstellung gefragt oder explizit vom Benutzer delegiert werden (Bestätigt? j). validate_plan.py lehnt jede Zeile ab, in der Bestätigt? n oder leer ist.
Schlanker Orchestrator & strenge 1-Subagent-pro-Phase-Grenze (scout != planner != specifier != builder != verifier). Halten Sie den Hauptchat unter ~15k Token. Verschmelzen Sie niemals zwei Phasen in einem einzigen Subagentenaufruf:
- scout ERKUNDET NUR und gibt die ~30-zeilige Zusammenfassung der Unklarheiten zurück.
- planner SCHREIBT NUR plan.md + führt validate_plan.py aus, dann stoppt und beendet.
- specifier SCHREIBT NUR checks.md + führt validate_checks.py aus, dann stoppt und beendet (es DARF NIEMALS Testdateien oder Implementierungscode schreiben oder mit BAUEN fortfahren).
- builder LÄUFT NUR, nachdem specifier zurückgekehrt ist. Für Funktionen mit mehreren Slices (S1, S2, ...) senden Sie einen separaten builder-Subagenten nacheinander pro Slice, sodass jeder Slice in einem frischen Kontextfenster ausgeführt wird und dem Benutzer den Fortschritt meldet.
- verifier LÄUFT NUR in einem neuen Subagenten, nachdem der letzte builder committed hat.
Jeder Check ist eine beobachtbare Behauptung mit einem konkreten Wert plus dem Beweis – der genaue Test-Selektor oder Befehl, dessen Exit-Code ihn entscheidet. Kein Beweis, kein Check.
Tests behaupten, was die Checks sagen, niemals, was der Code zufällig tut. Schreiben Sie niemals einen Test, indem Sie die Implementierung lesen.
Schwächen Sie niemals eine Behauptung ab, löschen Sie einen Test oder überspringen Sie einen, um eine Suite zum Bestehen zu bringen. Ein wirklich falscher Check ist ein Stopp-und-Fragen, keine Bearbeitung.
Checks und Testrichtlinie-Zeilen sind nach der Genehmigung fixiert. In plan.md sind Landung, Beziehungen und Oberfläche additiv – eine beim Bauen entdeckte Tür erhält eine Zeile, bevor der Code sie schließt, und eine vom Benutzer genehmigte Zeile wird nie neu geschrieben. Ablauf und Auswirkung werden in dem Commit, der den Pfad ändert, wahrheitsgemäß gehalten.
Der Prüfer ist ein neuer Subagent, niemals der Autor, niemals optional, niemals wartend, bis er gefragt wird. Der Orchestrator sendet ihn sofort, nachdem der letzte Commit der Funktion über <feature-Basis>..HEAD mit jedem Check gelandet ist.
Das Profil ist eine Mindestanforderung und wird von validate_verification.py durchgesetzt.
Das Fertigstellungs-Gate ist ein Skript, kein Gefühl: validate_verification.py muss mit Exit-Code 0 beenden.
Schlagkreis: Ein genehmigtes Pflichtenheft autorisiert lokale Änderungen und lokale Commits. git push, Deployment und Produktionsdatenänderungen benötigen eine explizite Genehmigung für diese Aktion.

Profil

Das Projekt deklariert, wie viel läuft, in AGENTS.md oder einem Äquivalent. Fehlt eine Deklaration: light.

## software-factory

profile: light
budget: 150k

Profil	Fügt hinzu	Kann nicht abfangen
`light` (Standard)	Beweise werden bei `HEAD` ausgeführt, wobei jeder benannte Test als existent und ausgeführt gezeigt wird, eine lokalisierte Behauptung pro Check, Level- und Stichprobenlücken, `Bestehende überprüft`	ein Mengenelement ohne Beweis; ein Test, der unter einer falschen Implementierung bestehen würde
`standard`	der `Coverage`-Join neu berechnet, `Testrichtlinie`-Zeilen mit einem Urteil, ein Fehler pro Behauptungsoberfläche	ein Check, der einer bindenden Quelle widerspricht; ein Bildschirm, den niemand gebaut hat
`ui`	bindende Quellen werden geöffnet und verglichen, pro Bildschirm Aufzählung von Kopie und Anordnung	nur Abstand, Farbe und Schriftstärke, pro Bildschirm aufgezählt

validate_verification.py lehnt einen Bericht ab, dessen Profil sich von dem unterscheidet, unter dem checks.md genehmigt wurde, lehnt einen standard-Bericht ohne Fehlerzeilen oder neu berechnete Abdeckung ab und lehnt einen ui-Bericht ohne Abschnitt zu bindenden Quellen ab.

Artefakte

.specs/
├── STATE.md                    # Entscheidungsprotokoll (AD-NNN) + Übergabe-Snapshot
├── LESSONS.md                  # gerendert von scripts/lessons.py - niemals von Hand bearbeiten
├── lessons.json                # maschineneigen
└── features/<feature>/
    ├── plan.md                 # Problem, Ablauf, Auswirkung, Beziehungen, Oberfläche, Landung, Kriterien, Annahmen (alle j), beobachtbar
    ├── checks.md               # Behauptungen + Beweise, Coverage-Join, Testrichtlinie, Abgedeckt, Übergabe-Batches
    └── verification.md         # Der Bericht des unabhängigen Prüfers

Erstellen Sie jede Datei, wenn ihre Phase Inhalt produziert. Für eine Änderung unter ungefähr drei Dateien ohne Einweg-Tür und keinerlei Umfangsunklarheit schreiben Sie nur checks.md mit einem ## Absicht-Absatz und überspringen Sie plan.md.

Fünf begrenzte Entwurfsabschnitte in `plan.md`

Abschnitt	Überprüft	Ausgeschlossen
`Ablauf`	der Pfad, eine Zeile pro Sprung	jedes Modul, das weder existiert noch durch eine Tür erstellt wird – das ist Platzierung
`Auswirkung`	was sich darunter ändert: Begriffe und vorhandene Daten	Risikoregister
`Beziehungen`	Entitäten, Kardinalität, Einweg-Einschränkungen	Spalten und Typen
`Oberfläche`	Route, rein, raus, Status	Spezifikation des Anfragekörpers und Check-IDs – diese existieren noch nicht
`Landung`	die Einweg-Türen, mit der wörtlichen Form und der abgelehnten Alternative	alles, was ein Refactoring rückgängig macht

Ablauf

Entdecken — Senden Sie den schreibgeschützten scout-Subagenten, um das Repo, .specs/STATE.md und .specs/LESSONS.md zu inspizieren und eine ~30-zeilige Zusammenfassung der Unklarheiten zurückzugeben. Führen Sie den Benutzer durch echte Produkt- und Umfangsgrauzonen (höchstens 2 Fragen pro Zug, konkrete Optionen mit empfohlener Standardeinstellung) über Beobachtbare Oberflächen und die 9 impliziten Dimensionen, bis 0 Zweifel bestehen: discovery.md.
Planen — Senden Sie den planner-Subagenten mit den bestätigten Entdeckungsentscheidungen, um .specs/features/<feature>/plan.md zu schreiben und validate_plan.py zu bestehen. Präsentieren Sie plan.md dem Benutzer zur kurzen Freigabe: plan.md.
Checks — Sobald plan.md genehmigt ist, läuft es automatisiert ab. Senden Sie einen dedizierten specifier-Subagenten, um .specs/features/<feature>/checks.md abzuleiten (Behauptungen + Beweise, Coverage-Join, Abgedeckt und ## Übergabe-Batch-Größenbestimmung) und validate_checks.py zu bestehen, dann beenden Sie diesen Subagenten, bevor Code oder Tests geschrieben werden: checks.md.
Bauen — Nachdem specifier fertig ist, senden Sie einen frischen builder-Subagenten pro Slice (S1, S2, ...) nacheinander. Jeder Builder schreibt Tests aus den Checks für seinen zugewiesenen Slice, implementiert, führt Beweise aus, zeichnet Grenze in checks.md auf, committed mit check_commit.py und beendet: build.md.
Prüfen & Korrigieren — Senden Sie einen frischen verifier-Subagenten über <feature-Basis>..HEAD, um verification.md zu schreiben und validate_verification.py auszuführen. Bei FEHLER senden Sie einen fixer-Subagenten und prüfen erneut (bis zu 3 Runden): verify.md.
Orchestrierung & Subagenten-Dispatch — Schlanke Orchestrator-Regeln, Kontextfenster-Budgets und Multi-Agenten-Zuordnungen (antigravity, claude, codex): orchestration.md.
Dauerhafter Speicher — Projektentscheidungen (STATE.md), Sitzungsübergabe und verifikationsgestützte Lektionen (lessons.py): memory.md.

Skripte

Lösen Sie <skill-dir> als das Verzeichnis auf, das diese SKILL.md enthält, und rufen Sie python3 <skill-dir>/scripts/<name>.py auf. Übergeben Sie --root, wenn sich das aktuelle Arbeitsverzeichnis vom Projektstammverzeichnis unterscheidet. Ein Exit-Code ungleich Null bedeutet STOPPEN und beheben.

Wann	Befehl
Pipeline-Phase und nächste Subagenten-Rolle inspizieren	`orchestrate.py status <feature> --root <dir>`
Isolierten Subagenten-Prompt generieren	`orchestrate.py prompt --role <scout
Phasen-Gate über Orchestrator ausführen	`orchestrate.py gate --phase <plan
Subagenten über CLI senden (oder `--dry-run`)	`orchestrate.py dispatch --role --agent <antigravity
Vor dem Präsentieren von `plan.md`	`validate_plan.py <feature>`
Vor dem Start von `BAUEN`	`validate_checks.py <feature>`
Vor jedem Commit	`check_commit.py --message "<msg>"`
Vor dem Fertigmelden	`validate_verification.py <feature>`
Bei der Destillation	`lessons.py add ...`
Nach dem Bearbeiten eines Validators, Skripts oder Templates	`selftest.py`

Subagenten und Übergabe

Jede Phase ist streng isoliert in ihrem eigenen Subagentenaufruf (scout -> planner -> specifier -> builder [S1] -> builder [S2] -> ... -> verifier -> fixer). Kombinieren Sie niemals specifier (CHECKS) und builder (BAUEN) im selben Subagenten. Während BAUEN, wenn eine Funktion mehrere Slices hat (S1, S2, ...), senden Sie einen separaten builder-Subagenten nacheinander pro Slice, sodass jeder Builder mit einem sauberen Kontextfenster beginnt, schnell fertig wird, seinen Slice auf Grün committed und einen Fortschrittsbericht an den schlanken Orchestrator zurückgibt.

Wenn der letzte Builder-Slice auf Grün zurückkommt, sendet der Orchestrator sofort den unabhängigen verifier-Subagenten im selben Zug, ohne den Benutzer zu fragen.

Wissenskette

In strenger Reihenfolge: vorhandener Code und Konventionen, Projektdokumentation, Bibliotheksdokumentation (Context7, falls verfügbar), Websuche, dann als unsicher markieren. Erfinden Sie niemals eine API, ein Flag, einen Befehl oder ein Verhalten.

Ausgabeverhalten

Produzieren Sie das Artefakt; erzählen Sie nicht die Phase. Beginnen Sie mit dem Urteil. Geben Sie Entscheidungen definitiv an. Entfernen Sie Füllwörter und mechanische Absicherungen. Behalten Sie Abschnittsüberschriften auf Englisch bei (sie sind ein Schema, das von den Gates überprüft wird).

brenoacker/agent-skills

Was ist agent-skills?

In Ihrer bevorzugten KI fragen

Dokumentation