formal-you/agent-skills-suite

Dev — Task-Implementierung

Implementiere ein Task-Bündel und übergib es an QA. Dieses Skill definiert den Prozess und trägt eigene Rollengrenzen in references/role-boundaries.md. Wenn das aufnehmende Repository Agentenregeln definiert (AGENTS.md, ein Rollen-Regeln-Verzeichnis oder Äquivalent), lies und befolge sie, sofern vorhanden; das Skill gewährt niemals zusätzlichen Zugriff.

Verwenden, wenn

• Ein Task unter tasks/<task-id>/ einen abgeschlossenen 01-contract.md hat und du die Dev-Rolle bist.
• Du einen vertikalen Schnitt implementieren, seine DoD-Befehle ausführen, Nachweise aufzeichnen und übergeben musst.
• Du einen Task nach einem REWORK_REQUIRED von QA überarbeitest.

Nicht verwenden, wenn

• Der Vertrag fehlt, unvollständig oder angefochten ist – gib ihn an den Planner zurück.
• Du aufgefordert wirst, Aufgaben zu planen, aufzuteilen oder zu überprüfen, oder die Arbeit eines anderen Agenten zu verifizieren.
• Die angeforderte Änderung außerhalb des touch_files des Vertrags liegt – eskaliere oder teile den Task auf.

Eingaben

• tasks/<task-id>/01-contract.md — maßgebliches YAML-Frontmatter, touch_files, dod, Abschnitt 4 BDD-verhaltensorientierte Szenarien (Given-When-Then-Invarianten) und geerbte ADRs.
• Von dem Vertrag referenzierte Spezifikationsanker.
• Projektbefehle für Typprüfung und Lint, die bestehende Testsuite und das QA-eigene Akzeptanzziel, das in dod.test_file deklariert ist.
• tasks/<task-id>/02-dev-workspace.md — das leere Formular, das du ausfüllst.

Ausgaben

• Code-Änderungen nur für Pfade, die in touch_files aufgeführt sind.
• Code, der BDD-Invarianten und zyklomatische Komplexitätsgrenzen einhält ($V(G) \le 10$ Standard, Warnung $11-15$ begründet in 02, kritisch $> 15$ verboten).
• Eine ausgefüllte 02-dev-workspace.md mit Metadaten, tatsächlichen Änderungen, Selbstverifizierung und der Tabelle Implementierungsabweichungen (Zeilen DEV-001, DEV-002, ... oder eine explizite None-Zeile).
• Genau ein Übergabemarker: - [x] WAITING_FOR_QA, nur gesetzt, wenn jeder DoD-Punkt bestanden ist.
• Keine Bearbeitungen an 01-contract.md, 03-qa-verification.md, 04-process.md oder tests/acceptance/**.

Arbeitsablauf

1. Umfang und BDD-Vertrag bestätigen. Lese 01-contract.md Frontmatter und Abschnitt 4 BDD-Szenarien. Prüfe, dass task_id dem Verzeichnisnamen entspricht und dass touch_files, dod, adherence_adrs sowie Given-When-Then-Invarianten definiert sind. Melde fehlende oder widersprüchliche Elemente dem Planner.
2. Arbeit vorbereiten. Notiere den Basis-Commit und halte die Projekt-Branch/Commit-Konventionen ein. Öffne keinen bereits akzeptierten Task erneut, es sei denn, ein Reviewer öffnet ihn wieder.
3. Vertikalen Schnitt unter BDD und Komplexitätsgrenzen implementieren. Ändere nur Dateien in touch_files. Implementiere Logik, die die in Abschnitt 4 und dod.edge_cases deklarierten Given-When-Then-Invarianten erfüllt. Kontrolliere die zyklomatische Komplexität einzelner Funktionen ($V(G) \le 10$ Standard). Nähert sich die Komplexität der Warngrenze ($11-15$), wende Refactoring-Muster an (Extract Method, Strategy / Lookup Table, Guard Clauses). Falls $V(G) > 15$, refactoriere vor dem Fortfahren. Bearbeite oder erstelle keine tests/acceptance/**.
4. Maschinell prüfbaren DoD und Selbstverifizierung ausführen. Führe dod.type_check und dod.lint aus, dann führe die vorhandenen Tests des Projekts durch; berücksichtige jeden Punkt von dod.edge_cases. Prüfe die zyklomatische Komplexität aller berührten Funktionen selbst. Das Akzeptanzziel (dod.test_file) gehört QA: führe es nur aus, wenn es bereits existiert, erstelle oder bearbeite es niemals. Wenn es noch nicht existiert, vermerke dies in 02 und lass QA es während der Verifikation ausführen. Halte Befehle/Ergebnisse fest.
5. Fülle 02-dev-workspace.md aus. Notiere Branch, Basis-/Übergabe-Commit, Designnotizen, eine Zeile pro tatsächlich geänderter Datei, Netto-Zeilenzahlen und setze jedes Selbstverifizierungselement, das zutrifft. Füge eine explizite architektonische Begründung für jede Funktion mit Warnkomplexität ($11 \le V(G) \le 15$) hinzu. Lasse Elemente unmarkiert, wenn sie nicht bestanden wurden. Vervollständige die Tabelle Implementierungsabweichungen: eine Zeile pro Stelle, an der der Code vom Vertrag oder der Spezifikation abweicht (DEV-001, DEV-002, ...; Operation add | modify | remove; ein #sec-*-Anker), oder schreibe None in jede Zelle, wenn nichts abweicht.
6. Übergabe an QA. Nur wenn jedes Selbstverifizierungselement bestanden wurde und die Komplexitätsgrenzen eingehalten sind, ändere - [ ] WAITING_FOR_QA zu - [x] WAITING_FOR_QA. Dieses einzelne gesetzte Kästchen ist der Auslöser für die Übergabe. Bearbeite 03 oder 04 nicht.
7. Bei Überarbeitung. Lese die Fehlerhinweise von QA in 03-qa-verification.md, korrigiere nur innerhalb des Vertrags, führe den DoD erneut aus, aktualisiere 02 für den neuen Versuch und übergib erneut. Eskaliere wiederholte Fehler, anstatt den Vertrag zu umgehen.

Qualitätstor (vor dem Erklären als fertig)

• Jeder geänderte Pfad ist in 01-contract.md → touch_files aufgeführt.
• Es wurde keine Datei außerhalb des Auswirkungsbereichs erstellt oder geändert.
• Die Implementierung respektiert alle Given-When-Then BDD-Szenarien und Verhaltensinvarianten.
• Typprüfung und Lint beenden erfolgreich; die vorhandenen Tests des Projekts bestehen.
• Die Selbstprüfung der zyklomatischen Komplexität besteht: alle Funktionen erfüllen $V(G) \le 10$ (oder $11-15$ mit Begründung in 02); keine überschreitet $V(G) > 15$.
• Das QA-eigene Akzeptanzziel (dod.test_file) ist deklariert; falls es noch nicht erstellt wurde, ist dies für QA vermerkt.
• Jeder Punkt von dod.edge_cases hat eine Implementierungs-/Testbegründung.
• 02-dev-workspace.md ist für diesen Versuch vollständig, einschließlich der Tabelle Implementierungsabweichungen (explizite None-Zeile, wenn nichts abweicht).
• Nur WAITING_FOR_QA ist gesetzt; 03 und 04 sind unberührt.

Fehlerbehandlung

• Fehlender oder widersprüchlicher Vertrag: anhalten; das Feld melden und den Planner bitten, es zu korrigieren.
• Außerhalb des Rahmens liegende Änderung erforderlich: Task aufteilen oder eskalieren; niemals außerhalb von touch_files bearbeiten.
• DoD-Befehl fehlt oder nicht ausführbar: mit dem Befehl und Fehler melden; die Prüfung nicht beschönigen.
• DoD schlägt fehl: Implementierung korrigieren und erneut ausführen. Das Übergabekästchen nicht setzen, während eine Prüfung fehlschlägt.
• Komplexität überschreitet Grenzwert ($V(G) > 15$): Vor der Übergabe mit Extract Method, Strategy / Lookup Table, Guard Clauses oder State-Mustern refaktorieren; niemals kritische Komplexität übergeben.
• Werkzeuge nicht verfügbar: Die manuellen Befehle des Projekts verwenden und Nachweise in 02 festhalten; der Arbeitsablauf darf nicht von optionalen Werkzeugen abhängen.

04-process.md und Werkzeuge

04-process.md ist eine abgeleitete Ausgabe. Nachdem das Übergabekästchen gesetzt ist, hängt optionales Repository-Tooling HANDOFF_QA_REQUESTED an und aktualisiert macro_status/current_lock_holder. Bearbeite 04 niemals von Hand; ohne Tooling verlasse dich auf git/CI und das gesetzte Kästchen.

Nach QA_PASSED: Spezifikations-Rückschreibungs-Eigentum

Die Tabelle Implementierungsabweichungen ist die letzte Lieferung von Dev für den Task. Nachdem QA QA_PASSED aufgezeichnet hat, besitzt das converge-Skill die Spezifikations-Rückschreibung: es fügt die bestätigten Abweichungen in .specs/02-tech-spec.md ein, archiviert das Task-Bündel und schließt den Änderungsvorschlag.

• Dev bearbeitet niemals .specs/02-tech-spec.md und archiviert niemals das Bündel.
• Eine strukturelle Abweichung (neue Komponente, geänderte Grenze, neue ADR-Entscheidung) wird an den Planner/spec-generator eskaliert, anstatt stillschweigend übernommen zu werden.
• Falls QA eine Überarbeitung anfordert, aktualisiere die Abweichungstabelle für den neuen Versuch; schreibe keine Spezifikationstexte vorab.

Referenzen

• references/dev-protocol.md — detaillierte Checklisten, Umfangsprüfung, McCabe zyklomatische Komplexitätsgrenzen, Refactoring-Muster, Übergabe- und Überarbeitungsverfahren.
• Rollengrenzen: references/role-boundaries.md — Schreibumfang, Nur-Lese-Umfang, Invarianten und das ehrliche Durchsetzungsmodell (gebündelt; keine externen Dateien erforderlich).
• Repository-Regeln: lies AGENTS.md und alle Rollen-Regeln-Dateien, wenn das aufnehmende Projekt sie definiert; sie können Anforderungen hinzufügen, sind aber für dieses Skill nicht erforderlich.
• Task-Bündel-Format: task-decomposition Skill (optionales Geschwister-Skill; dieses Skill konsumiert nur seine Artefakte).

Ehrliche Grenzen

Dieses Skill gewährt keinen Schreibzugriff und kann die Rollenisolation nicht erzwingen. Wenn das Repository CI hat (z. B. eine git-basierte Rollenprüfung) oder Branch-Schutz, ist dies die maßgebliche Ebene. Der Vertrag, nicht dieses Dokument, definiert den erlaubten Auswirkungsbereich.