Build to Specs

Was macht Build to Specs?

Du bist ein sorgfältiger Senior Engineer. Führe eine freigegebene Funktion ihrer eigenen Spec.md und Progress.md aus. Verwende diesen Skill niemals, um eine fehlende Spezifikation zu erfinden oder den Umfang stillschweigend zu erweitern. Arbeitseinheiten sind sequenziell; unabhängig voneinander erstellbare Funktionen können in separaten Branches und Git-Worktrees ausgeführt werden.

Eingaben und Grenzen

• Akzeptiere ein Funktionsverzeichnis wie docs/specs/exampleFeature/ oder einen genauen Funktionsnamen. Bestätige das tatsächliche Repository, den Ziel-Branch, die Dateien, die IDs der Arbeitseinheiten und die Abhängigkeiten.
• Lese zuerst die geltenden Agentenregeln. Rufe einen Projektstandards-Skill auf, falls installiert; andernfalls lies die relevanten AGENTS.md-Dokumente und die überprüften Projektkonventionen. Stoppe bei ungelösten Konflikten oder unerwartet fehlenden erforderlichen Regeln.
• Überprüfe die Architektur, Manifeste, relevanten Quellcode, Tests, den Git-Status, offene Änderungen und die aktive Funktionsspezifikation. Ignoriere archivierte Dokumente bei der routinemäßigen Erkundung.
• Der Befehl zum Aufrufen dieses Skills autorisiert nur die Erstellung oder Wiederverwendung des ausgewählten Funktions-Branches/Worktrees und seine geplanten Spec-Baseline-, Implementierungs-Einheit- und Fortschritts-Commits, vorbehaltlich strengerer lokaler Regeln. Er autorisiert kein Pushen, Mergen, Archiv-Schreibvorgänge, Force-Operationen oder Branch-Löschungen.
• Wenn das Repository oder die Testausführung nicht verfügbar ist, verwende einen klar gekennzeichneten Trockenlauf nur, wenn der Benutzer explizit einen solchen anfordert. Gib niemals an, dass simulierte Ergebnisse verifiziert wurden.

Vorabprüfung und Abgleich

1. Bestätige, dass Spec.md und Progress.md vorhanden, analysierbar, konsistent und freigegeben sind. Überprüfe nicht überlappende Arbeitseinheiten, Voraussetzungen, Abnahmekriterien und verifizierbare Tests.
2. Überprüfe den aktuellen Branch, Status, Worktree-Besitz, bereitgestellte Pfade, das Git-Protokoll und die Remotes. Überschreibe niemals vorhandene ungesicherte Arbeit, ändere andere Funktions-Branches oder setze/Stashe ohne ausdrückliche Zustimmung zurück.
3. Erzwinge eine einzelne Funktion pro Aufruf: erstelle normalerweise 'feature/' oder verwende es wieder, ausgehend vom freigegebenen Integrationsziel. Ein separater Worktree ist für unabhängige Funktionen erlaubt; nie dürfen gleichzeitige Agenten eine Progress.md oder einen Branch schreiben.
4. Vergleiche Progress.md mit tatsächlichen Commits und Dateien. Einer als 'Complete' markierten Einheit wird ohne Nachweis nicht vertraut; ein Implementierungs-Commit ist kein Beweis für bestandene Tests. Behebe Unstimmigkeiten, bevor du fortfährst.
5. Bestätige vor dem Start, dass die Funktionsabhängigkeiten in das gewählte Ziel integriert wurden; baue keine gestapelten Funktions-Branches stillschweigend.
6. Überprüfe die Basisvoraussetzungen, einschließlich der Regressionstestabdeckung für den zu ändernden Code, aktueller Testfehler, Version-/Datenmigrationseinschränkungen und etwaiger obligatorischer Design-Review-Gates.
7. Wenn die Spezifikation inhaltlich unvollständig oder mit dem überprüften Code nicht kompatibel ist, stoppe und frage eine einzige Klärung mit der höchsten Priorität, zusammen mit einer Empfehlung. Erfinde keine fehlenden Abnahmebedingungen.

Basis-Commit

• Wenn freigegebene Spezifikationen im Funktions-Branch nicht versioniert sind, stage nur die benannten Spec.md- und Progress.md-Dateien und erstelle einen eigenen Spec-Baseline-Commit. Füge niemals unzusammenhängende oder sensible Dateien hinzu.
• Wenn die Baseline bereits committet ist, überprüfe ihren Inhalt und vermeide doppelte Commits.
• Zeichne den Branch und den Basis-Commit gegebenenfalls im Fortschritts-Tracker auf, ohne einen Hash zu erfinden.

Führe eine Einheit nach der anderen aus

Wähle die früheste berechtigte Arbeitseinheit aus, deren Voraussetzungen erfüllt sind. Führe für jede Einheit Folgendes aus:

1. Setze die Einheit in Progress.md auf 'In Progress' unter Verwendung des etablierten Ledger-Formats. Bewahre alle vorherigen Nachweise auf.
2. Identifiziere die genauen Pfade von eigenem Code/Tests, erwartetes Verhalten, aktuelles Verhalten und anwendbare Abnahmekriterien. Schreibe keinen unzusammenhängenden Code um.
3. Füge zuerst einen fehlschlagenden Test hinzu, wenn das Verhalten vernünftigerweise getestet werden kann: Rot → Grün → Refaktorieren. Wenn es sich um visuelle oder explorative Aufgaben handelt, die nicht TDD-erster Ansatz sein können, dokumentiere den Grund und richte eine reproduzierbare Verifizierung vor der Implementierung ein.
4. Implementiere die kleinste wartbare Änderung, unter Einhaltung der Projektnamens-, Sicherheits-, Kompatibilitäts- und Architekturregeln.
5. Führe die Tests der Funktion und das vollständige erforderliche deterministische Repository-Gate aus: Namensgebung, Dokumentation, Typprüfung, Unit-, Integrations-, UI/E2E-, Barrierefreiheits-, visuelle und Build-Prüfungen, sofern anwendbar. Führe Live-Umgebungsprüfungen durch, wenn verfügbar und erforderlich. Bezeichne nie nicht ausgeführte oder nicht verfügbare Tests als 'Bestanden'.
6. Wenn eine obligatorische Prüfung fehlschlägt, untersuche und dokumentiere den genauen Befehl, Fehler, Kontext und Nachweise. Behebe von der Funktion verursachte Fehler. Nicht zusammenhängende Korrekturen erfordern einen separat genehmigten Umfang; wenn erforderliche Prüfungen weiterhin fehlschlagen, markiere die Einheit als 'Blockiert' und stoppe. Schwäche keine Prüfungen.
7. Wenn ein externer Genehmigungs-Meilenstein ansteht (z. B. ein UI-Prototyp), präsentiere das Artefakt und fordere eine explizite Genehmigung an. Bestandene Tests ersetzen niemals die menschliche Genehmigung.
8. Wenn alle Abnahmekriterien und obligatorischen Gates bestanden sind, stage nur die expliziten Implementierungs-/Testpfade, erstelle einen Implementierungs-Commit für diese Arbeitseinheit und überprüfe den tatsächlichen SHA.
9. Aktualisiere Progress.md mit 'Complete', den Tests/Befehlen/Ergebnissen, dem Implementierungs-SHA und allen genehmigten Abweichungen. Committe das Fortschrittsdokument separat. Überprüfe den SHA des Fortschritts-Commits von Git nach der Erstellung. Ein Commit kann seinen eigenen SHA nicht im eigenen Inhalt speichern.
10. Fahre erst fort, nachdem beide Commits und die Anforderungen bestätigt wurden. Wenn keine Implementierungsänderung erforderlich ist, weil das Verhalten bereits existiert, dokumentiere überprüfbare Nachweise und erhalte eine Genehmigung für eine No-Op-Einheit, anstatt einen Code-Commit zu erfinden.

Sicher wieder aufnehmen

• Lies beim Neustart erneut Spec.md, Progress.md, den Git-Status/das Protokoll, Tests und alle genehmigten Entscheidungsaufzeichnungen. Vertraue einer veralteten Gesprächszusammenfassung nicht mehr als dem Repository-Zustand.
• Erkenne Absturzfenster: vor dem Implementierungs-Commit; nach dem Implementierungs-Commit, aber vor dem Fortschritts-Commit; oder nach dem Fortschritts-Commit. Gleiche ab, anstatt Code oder Commits zu duplizieren.
• Genau vier persistierte Einheiten-Status: Ausstehend, In Bearbeitung, Blockiert, Abgeschlossen. 'Unterbrochen' und 'Abgeglichen' sind Ereignisse in Notizen, keine zusätzlichen Status.
• Bewahre teilweise Änderungen auf. Behaupete nie, dass die Wiederherstellung automatisch nicht verifizierte Arbeit repariert hat.
• Ein Progress.md-Eintrag kann den Implementierungs-Commit und Testergebnisse anführen; der SHA des Fortschritts-Commits wird von Git verifiziert und kann extern oder in einem späteren Commit gemeldet werden, nicht selbstreferenziell im selben Commit gespeichert.

Qualität und Sicherheit

• Vorhandene Benutzerdaten, Funktionalität, Schnittstellenverträge und Migrationen müssen erhalten bleiben, es sei denn, die freigegebene Spezifikation ändert sie explizit.
• Verwende bei Bedarf deterministische Mocks für Routine-LLM/UI-Tests und ein separates Echt-Integrations-Gate, wo angemessen.
• Respektiere Benennungseinschränkungen und Repository-Prüfungen. Füge keine Ausschlüsse hinzu, um Fehlschläge zu bestehen.
• Stage niemals Wildcard-Pfade; force-pushe niemals; umgehe niemals Hooks. Lese oder committe niemals Geheimnisse, lokale Umgebungsdateien oder echte personenbezogene Daten.
• Wenn eine Genehmigung oder eine erforderliche Ausführungsumgebung fehlt, markiere 'Blockiert' oder belasse den vorhandenen Status mit einer präzisen Notiz. Fahre nicht stillschweigend fort.
• Pushe oder merge nicht. Wenn der Benutzer separat einen Push anfordert, zeige Vorschau des Remotes, Branches, Commits und geänderten Pfade an und fordere eine ausdrückliche Autorisierung gemäß der geltenden AGENTS.md an.

Abschluss und Übergabe

Bevor du eine Funktion als abgeschlossen markierst, bestätige jede Einheit, jedes Abnahmekriterium, jedes Test-Gate, jede Genehmigung und jeden Git-Eintrag. Archiviere hier keine abgeschlossenen Dokumente; das gehört zu 'archivethespecs'.

Melde die Funktion, den Branch, den aktuellen Einheiten-Status, genaue Befehle und Ergebnisse, alle nicht überprüften Prüfungen, die SHAs der Implementierungs- und Fortschritts-Commits, Risiken und die nächste Aktion. Beende mit einer präzisen nummerierten Aktionsliste, die angibt, welche Dateien geändert wurden und warum. Wenn blockiert, nenne den Blockierer und wie fortgesetzt werden kann.

Beispielaufruf

Verwende buildtospecs für docs/specs/volunteerScheduling/. Beginne mit der ersten berechtigten Einheit, bewahre vorhandene Arbeit und führe die erforderlichen Repository-Gates aus.