aTeering/skills

Engineer

Synthesieren Sie die Erkundung in zwei dauerhafte Artefakte: eine Spezifikation, die /implement ausführen kann, und ADRs für Entscheidungen, die es wert sind, festgehalten zu werden.

Eingabe: $ARGUMENTS.

Keine stillschweigenden Annahmen. Jede Designentscheidung wird entweder vom Benutzer getroffen oder als Annahme aufgeführt. Dies schließt Entscheidungen ein, die sich zu klein anfühlen, um danach zu fragen (Bibliothek, Fehlerformat, Benennung, Standardwerte, Grenzen), sowie das, was Sie aus der Codebasis ableiten, und Ihre eigenen Empfehlungen. Führen Sie ein Annahmen-Ledger (✅ vom Benutzer bestätigt · ❓ unbestätigt · ❌ abgelehnt) durch den gesamten Prozess und schreiben Sie niemals eine unbestätigte Entscheidung als Entscheidung in eine Spezifikation oder ADR.

Prozess

1. Verfeinern. Wenn es in dieser Sitzung noch keine verfeinerte Aufgabenbeschreibung gibt, führen Sie zuerst den /refine-Prozess durch (grillen → Akzeptanzkriterien). Fahren Sie nicht mit offenen Fragen fort, die das Design blockieren. Wenn eine Aufgabenbeschreibung vorhanden ist, übernehmen Sie deren ❓-Annahmen in Ihr Ledger; lösen Sie sie auf, bevor Sie etwas entwerfen, das von ihnen abhängt.
2. Modellieren. Führen Sie den /domain-modelling-Prozess für alle neuen oder geänderten Konzepte durch und aktualisieren Sie das Domänendokument. Die Spezifikation muss diese kanonischen Begriffe verwenden.
3. Erkunden Sie die Codebasis. Identifizieren Sie die Module, Schnittstellen, Datenspeicher und Tests, die von der Änderung betroffen sind. Notieren Sie vorhandene Muster, die befolgt werden sollen. Verweisen Sie auf echte Pfade. Was der Code heute tut, ist Beweis, nicht Absicht: „Dem bestehenden Muster in src/x.ts folgen“ ist selbst eine Entscheidung, die mit dem Benutzer bestätigt werden muss, protokolliert mit ihrer Quelle.
4. Entwerfen. Legen Sie für jede bedeutende Entscheidung 2-3 Optionen mit Vor- und Nachteilen und einer Empfehlung dar; der Benutzer entscheidet, und eine Empfehlung zählt nur, wenn er sie explizit auswählt. Für kleinere Entscheidungen bündeln Sie sie in einer Bestätigungsliste, anstatt sie selbst zu treffen. Berücksichtigen Sie Datenmodell & Migrationen, API-/Vertragsänderungen, Fehlerbehandlung, Sicherheit, Leistung, Observability, Rollout & Rollback und Rückwärtskompatibilität.
5. ADRs aufzeichnen. Eine Entscheidung verdient eine ADR, wenn sie schwer rückgängig zu machen ist, mehrere Module betrifft oder ein zukünftiger Ingenieur fragen würde: „Warum haben wir das so gemacht?“. Schreiben Sie jede in docs/adr/NNNN-kebab-titel.md (nächste freie Nummer, 4-stellig) unter Verwendung von adr-template.md. Wenn eine ADR eine andere außer Kraft setzt, aktualisieren Sie den Status der alten. Markieren Sie eine ADR nur dann als Accepted, wenn der Benutzer die Entscheidung bestätigt hat; andernfalls bleibt sie Proposed.
6. Schreiben Sie die Spezifikation nach docs/specs/<kebab-titel>.md unter Verwendung von spec-template.md. Unterteilen Sie die Arbeit in kleine, geordnete, unabhängig testbare Aufgaben – jede mit dem/dem Test(s), die sie beweisen. Füllen Sie den Abschnitt Annahmen der Spezifikation aus dem Ledger; jede Designaussage muss auf eine Benutzerentscheidung zurückzuführen sein oder dort als ❓ erscheinen.
7. Überprüfen Sie mit dem Benutzer. Fassen Sie die Spezifikation und die ADRs zusammen, zeigen Sie die offenen ❓-Elemente, bitten Sie um Freigabe und passen Sie an. Setzen Sie die Spezifikation nicht auf Approved, solange eine ❓ eine Aufgabe, ein Akzeptanzkriterium oder eine ADR betrifft.

Regeln

• Respektieren Sie die bestehenden Konventionen des Projekts, wenn es bereits Spec-/ADR-Ordner oder Vorlagen hat – verwenden Sie diese stattdessen.
• Die Spezifikation beschreibt das Was und Wie zu verifizieren, mit genug Wie, um Mehrdeutigkeiten zu beseitigen – keine zeilenweise Implementierung.
• Jedes Akzeptanzkriterium muss mindestens einer Aufgabe und einem Test zugeordnet sein.
• Halten Sie es so kurz, wie es die Änderung erlaubt.

Nächster Schritt

Empfehlen Sie /handoff (um die Implementierung in einer neuen Sitzung zu starten) oder direkt /implement docs/specs/<datei>.md.