Von der Anforderung zur Auslieferung
Zunächst klarstellen, was der Benutzer ändern möchte und was „Fertig“ bedeutet, dann ausführen. Die autorisierte Arbeit kontinuierlich zu Ende bringen; wenn eine Entscheidung nötig ist, zuerst die Teile erledigen, die nicht von dieser Entscheidung abhängen. „Einen Plan geschrieben“, „Der Code kompiliert“ oder „Automatisches Mergen aktiviert“ nicht als endgültige Lieferung betrachten.
Arbeitsvereinbarungen
- Die Entwicklungsmethode nach Ziel, Risiko und Feedbackkosten wählen. Zuerst eine Spezifikation schreiben, testgetrieben auf einer klaren öffentlichen Schnittstelle vorgehen oder direkt implementieren und dann validieren; Methoden können kombiniert werden. Stets beobachtbare Fertigstellungsbedingungen festlegen, echte Verhaltensbelege einholen und nicht einen bestimmten Prozess für alle Aufgaben erzwingen.
- „Was ist“ mit aktuellem Code, Ausführungsergebnissen und tatsächlichen Release-Artefakten beschreiben; „Was werden soll“ mit den vom Benutzer bestätigten Zielen. Bei Abweichungen die Implementierung oder veraltete Aufzeichnungen korrigieren, nicht alte Dokumentation über die Benutzerziele stülpen.
- Den Prozess nach dem Umfang wählen. Kleine Änderungen: Spezifikation in wenigen Sätzen. Nur modulübergreifende Anforderungen in Scheiben schneiden, entwerfen und dokumentieren. Nicht für jede Bearbeitung das gesamte Wissen laden, feste Genehmigungsketten einrichten oder leere Vorlagen ausfüllen.
- Der bereits autorisierte Umfang bleibt gültig. Recherche, Implementierung und reversible Verifizierung nicht erneut bestätigen; externe Veröffentlichungen nach den vom Benutzer festgelegten Zielen ausführen. Fehlen noch Produktionsziele oder Autorisierung, zuerst Artefakte, Abweichungen, Rollback-Möglichkeiten und Checklisten vorbereiten, dann die fehlenden Punkte benennen.
- Dieser Skill kann eigenständig verwendet werden. Wenn die in der folgenden Tabelle genannten Skills installiert sind, werden sie bei Bedarf aufgerufen; sind sie nicht installiert, wird das Ergebnis der Phase direkt erbracht, ohne dass der Benutzer den gesamten Satz von Skills installieren muss.
- Eine Aufgabe wird vom aktuell Verantwortlichen kontinuierlich vorangetrieben. Spezialmethoden ergänzen Belege und Ergebnisse der aktuellen Phase; dabei werden bereits bestätigte Entscheidungen und dieselben Aufzeichnungen weiterverwendet, kein separater konkurrierender Prozess gestartet.
Nächsten Schritt wählen
| Aktuelle Situation | Vorgehensweise | Aufrufbarer Skill |
|---|---|---|
| Unklar, welche Fähigkeit verwendet werden soll, oder nur die Verwendung verstehen wollen | Nach Aufgabe den minimalen Einstiegspunkt wählen; zuerst die Verwendung erklären, eine Beratung nicht als Implementierungsautorisierung missverstehen | dev-help |
| Erstmalige Konfiguration der Umgebung, des Rollenmodells oder des Reasoning-Budgets | Tatsächlich verfügbare Werkzeuge und Modelle prüfen, kurze Präferenzen speichern; keinen festen Anbieter oder Hintergrundfähigkeiten annehmen | dev-setup |
| Wiederkehrende Arbeiten schrittweise an die eigenen Gewohnheiten anpassen | Stabile Muster aus lesbaren Historien extrahieren und als kurze, wartbare Projekt-Skills formulieren | dev-personalize |
| Benutzer fragt nach Fortschritt oder benötigt eine Übergabe-Zusammenfassung | Abgeschlossenes, aktuelle Belege und ausstehende Punkte zusammenfassen; antworten und dann die ursprüngliche Aufgabe fortsetzen, es sei denn, eine explizite Pause wird angefordert | dev-status |
| Eingabe stammt aus Chat, Issue, Screenshot, Log oder mehreren Rückmeldungen | Ursprungsbelege, tatsächliches Verhalten, Ziele und Umfang finden, doppelte Anliegen zusammenführen | dev-intake |
| Berichtskanäle einrichten oder Anforderungen quellenbasiert überwachen | Quellen, Tracker, Repository-Routen, Steuerungsmodi und tatsächliche Trigger getrennt auswählen, Initialisierung im autorisierten Rahmen abschließen | dev-issue-setup |
| Berichte aus bereits konfigurierten Quelladaptern müssen klassifiziert, dedupliziert oder weitergeleitet werden | Belege nach nativen Berichten, Identität und Tracker-Verträgen verarbeiten; Quellen können Chat, Tickets, E-Mails, Alarme oder manuelle Eingaben sein; in dieser Phase nicht reproduzieren oder reparieren | dev-issue-triage |
| Berichtspipeline eingerichtet, vertrauenswürdiges Triage und echte UI-Steuerungsbedingungen sind vorhanden | Zugehörigkeit prüfen, nach vollständigem Protokoll reproduzieren oder vorhandenen Patch verifizieren; bei Bedarf und Autorisierung reparieren und PR-Entwurf ausliefern | dev-issue-fix |
| Produktregeln haben entscheidende Mehrdeutigkeiten | Zuerst faktische Antworten aus dem Code geben, dann um die Fragen klären, die die Lösung beeinflussen | dev-grill |
| Anforderung ist klar, aber noch nicht direkt abnahmefähig | Benutzerverhalten, Grenzen, Nicht-Ziele und Erfolgsbedingungen schreiben | dev-spec |
| Benutzer möchte eine ausstehende Anfrage vertiefen oder umschreiben | Mit vier Fragen auf fachliche Lücken, Ausgangsmaterialien, konkrete Methode und unabhängige Belege prüfen, verwendbare Prompt-Vorlage ausliefern | dev-sharpen |
| Ein unbekanntes Modul übernehmen | Entlang eines echten Anwendungsfalls den Einstieg, die Geschäftslogik, die Speicherung, das Feedback und die Fehlerpfade durchgehen | dev-learn |
| Verstehen, warum ein historisches Design existiert | Aktuelles Verhalten, damalige Beweggründe und Vermutungen unterscheiden, den Quellcode und verfügbare Entscheidungsbelege zurückverfolgen | dev-why |
| Wesentliche Kompromisse bei Schnittstellen oder Grenzen | Verschiedene Strukturen vergleichen; aus Sicht der Aufruferfahrung, des Zustandsbesitzes und der fachlichen Terminologie beurteilen | dev-architecture |
| TLA+-Modell vorhanden oder soll erstellt werden, Zustandsdiagramm mit Prüfergebnissen benötigt | TLC ausführen, Regelmarkierungen und kürzeste Gegenbeispiele generieren, schrittweise mit echtem Code abgleichen | dev-statechart |
| Kritische Eigenschaften prüfen, formales Werkzeug auswählen oder Modell pflegen | Eigenschaften, Annahmen und Grenzen klären, Prüfung ausführen und Modell-Drift identifizieren; normale Erklärungsdiagramme starten diesen Prozess nicht automatisch | dev-formal-verify |
| Seiten, Interaktionen, Designsystem oder visuelle Abnahme betreffend | Komponenten und Tokens aus dem tatsächlichen Code verwenden; Designspezifikationen nach Produkt- oder Marketingszenario lesen, kein Design-Tool-Konto erforderlich | dev-ui-design |
| Anforderung kann nicht zuverlässig auf einmal ausgeliefert werden | In abnahmefähige vertikale Funktionsscheiben zerlegen, explizite Abhängigkeiten angeben, zuerst den minimalen vollständigen Pfad durchlaufen | dev-plan |
| Es gibt sich nicht widersprechende Arbeiten oder verschiedene Lösungsansätze, die verglichen werden sollten | Schreibumfang und Abnahmeregeln zuweisen, dann integrieren und endgültiges Ergebnis verifizieren | dev-parallel |
| Spezifikation oder Scheiben sind bereit zur Implementierung | Nach bestehenden Engineering-Standards implementieren, echtes Verhalten anschließen, aktuelle Artefakte verifizieren | dev-build |
| Normales Issue, CLI-/API-/UI-Funktionsfehler oder Abnahmefehler | Entlang des tatsächlichen Einstiegspunkts reproduzieren und Root Cause lokalisieren; nur wenn Leistungskennzahlen das Ziel sind, in den Messprozess eintreten | dev-debug |
| Benutzer fordert Test-first an, oder die aktuelle Implementierung hat TDD gewählt | Einen fehlgeschlagenen Test nach dem anderen an der öffentlichen Schnittstelle abschließen und minimal implementieren; nachträgliche Tests für korrektes Verhalten starten nicht automatisch den Rot-Grün-Zyklus | dev-tdd |
| Gleiche Fehler treten wiederholt auf oder kritische Einschränkungen werden leicht umgangen | Vorrangig Typen, Schnittstellen und Zustandsbesitz verbessern; bei echtem Wert ausführbare Regeln hinzufügen | dev-guardrails |
| Implementierung abgeschlossen | Spezifikationskonformität und Codequalität getrennt prüfen; echte Probleme beheben | dev-review |
| Nachweis erforderlich, dass ein echter Benutzerpfad funktioniert | Echte Anwendung treiben, Ergebnisse und Nebenwirkungen prüfen, reproduzierbare Verifikationsmethode pflegen | dev-verify |
| Ziel ist die Verbesserung von Latenz, Durchsatz, Ressourcen oder anderen Messwerten | Arbeitslast und Messmethode fixieren, Beweissicherung, Optimierung oder fairen Vergleich durchführen, dieselbe Baseline wiederverwenden | dev-benchmark |
| Ziel enthält ein Deployment | Umgebung und Version bestätigen, autorisiertes Deployment ausführen, tatsächlichen Dienst verifizieren und protokollieren | dev-deploy |
| Klare Dokumentation, Commit-Nachricht oder PR-Zusammenfassung erforderlich | Informationen nach den Fragen der Leser organisieren, konkretes Verhalten, Belege und notwendige Kompromisse angeben | dev-writing |
| Eine Anforderung wurde ausgeliefert oder explizit gestoppt | Neues Wissen aufräumen, Konflikte beheben, wertvolle Begründungen aufbewahren und den Prozess archivieren | dev-archive |
Vorhandene Spezifikationen direkt umsetzen; nur Design anfordern, Design ausliefern; nur Erklärung anfordern, bei der Erklärung bleiben. Lies Fortführung und Wiederaufnahme für parallele Arbeiten und Unterbrechungen. Um die Anforderung zu verfeinern, lies Phasenübergang zwischen Anforderung und Implementierung; um die ausgewählte Aufgabe auszuführen, lies Ingenieurmethoden; diese ergänzen die aktuelle Phase, wählen keine bereits abgeschlossene Phase erneut aus.
Wenn für eine komplexe Aufgabe kein geeigneter Standardprozess existiert, verwende Benutzerdefinierte Ausführungsmethode, um überprüfbare Einheiten zu bilden und die autorisierte Arbeit fortzusetzen. Für die Aufzeichnung und nachträgliche Überprüfung langer Aufgaben verwende Entscheidungsbeleg-Methode, um Entscheidungen, Alternativen und echte Belege abzugleichen; nur wenn eine Überprüfung angefordert ist, wird ein Audit-Ergebnis ausgeliefert, ohne automatisch die Migration oder Implementierung fortzusetzen. Die Rückverfolgung, warum ein Design damals gewählt wurde, ist Aufgabe von dev-why. Wenn der Benutzer ausdrücklich ein funktionsfähiges Status-Dashboard erstellen möchte, wird dies als Implementierungsaufgabe behandelt; reine Fortschrittsabfragen verwendet dev-status.
Arbeit fortsetzbar machen
Dieser Skill und die dazugehörigen neuen Projektunterlagen verwenden einheitlich .agents/wtadev/ als Stammverzeichnis, mit folgenden Unterteilungen nach Bedarf. Vorhandene Unterlagen werden am tatsächlichen Ort eingesehen und notwendige Verweise beibehalten; nur auf ausdrückliche Anforderung migrieren, dabei Inhalt, Kennzeichnung und gültige Links erhalten. Wenn der Benutzer für diesen Durchlauf explizit einen anderen Ort angibt, wird dessen Anweisung befolgt:
.agents/wtadev/changes/<Datum-Thema>/: Brief, Spec, Plan, Fortschritt, Belege für die aktuelle Anforderung, nach Bedarf erstellt..agents/wtadev/notes/: Verifizierte Begriffe, Kontext, Entscheidungen, Fehlererfahrungen und Modulverständnis; dieindex.mddient nur als Wegweiser..agents/wtadev/deploy/<Umgebung>/: Deployment-Handbuch und historische Release-Aufzeichnungen unterreleases/..agents/wtadev/archive/changes/,.agents/wtadev/archive/notes/: Abgeschlossene Arbeiten und historisches Wissen; explizit nicht repräsentativ für das aktuelle Verhalten.
Diese Unterlagen gehören zum Zielprojekt und dürfen nicht in das Installationspaket .agents/skills/ geschrieben werden. Bei Wiederaufnahme die Übergabe-Vorlage verwenden, nur aktuelle Ergebnisse, Belege, offene Fragen und nächste Schritte hinterlassen.
Abschluss
Gegenüber den ursprünglichen Lieferzielen die tatsächlichen Änderungen, Verifikationsbelege der aktuellen Version, Lieferadresse oder Commit sowie die tatsächlich unerledigten Teile angeben. Wenn ein Deployment ansteht, aber noch nicht durchgeführt wurde, explizit „Implementierung abgeschlossen, Deployment nicht abgeschlossen“ schreiben. Nach erfolgreichem Deployment wiederverwendbares Wissen und aktuelle Codeverweise in das Projekt einpflegen, nicht den gesamten Chatverlauf in die AGENTS.md stopfen.
Vollständige lokale Dokumentation
Über den Dokumentationsindex die vollständigen Prozesse, Prüfregeln, Beispiele und Vorlagen innerhalb dieses Skills auswählen. Alle für die Ausführung notwendigen Ressourcen befinden sich in diesem Paket; es wird keine Installation anderer Skills vorausgesetzt. Es wird nur der für die aktuelle Task-Branch benötigte Inhalt gelesen.