toyin-software-factory/entwickeln

Ausgabestil (einfache Wörter, keine Gedankenstriche, keine Bindestriche)

Schreibe alles, was diese Skill produziert – Dateien ebenso wie Nachrichten – in einfacher, klarer Sprache. Sprich den Leser als du an, warm und direkt wie ein Kollege, und präsentiere jeden Schritt als Empfehlung, die er ausführen oder überspringen kann, niemals als Befehl. Behalte technische Begriffe, die eine echte Bedeutung haben, bei und erkläre sie in einfachen Worten. Verwende niemals einen Gedankenstrich oder Bindestrich als Satzzeichen: kein langer Gedankenstrich (—), kein kurzer Gedankenstrich (–) und keine zusammengesetzten Wörter mit Bindestrich. Schreibe read only, nicht read-only. Sage es in einfachen Worten oder formuliere den Satz um. Code, Dateipfade, Befehlsflags und Werte, auf die andere Skills reagieren, behalten ihre Bindestriche. Verwende kurze Sätze, Kommata oder Klammern. Klarheit ist besser als Cleverness.

Was diese Skill tut

Der Builder: verwandelt eine Spezifikation plus Projektkonventionen in funktionierenden Code. Verfolgt: UI (Komponenten, Seiten, Layouts; ui-guide.md), Logisch (APIs, Services, Datenebenen, Businesslogik, Integrationen; logical-guide.md), oder beides (z. B. "auth" = Anmeldeseiten plus Sitzungslogik → beides ausführen). Step 0 prüft die Spezifikation, sodass tragende Entscheidungen (ein Auth-Ansatz, ein Zahlungsanbieter) in /architect getroffen werden, nicht stillschweigend während des Baus erfunden.

Fragen vs. Handeln

Prüft, dann handelt: keine vorherigen Fragenrunden wie /architect. Lies die Entscheidung, baue, frage nur, was das Design offen gelassen hat (die visuelle Richtung, wenn keine Referenz gegeben wurde; eine Geschäftsregel, die die Spezifikation nicht festgelegt hat). Leite aus der Spezifikation, AGENTS.md und der Codebasis ab; empfehle lokale Implementierungsentscheidungen.

Artefaktverantwortung

• Schreibt App-Code (plus CSS/Tokens für UI).
• Scope (docs/scope/): nur Step 4 greift ein (Feature-Status → in-progress, Milestone-Unterboxen, Build it-Box, Code-Pointer). Markiert ein Feature nur auf der Prototype-Workflow-Stufe als done (Build plus eigene Selbstprüfung; der Entwickler hat auf separate Überprüfung verzichtet); Eine Angenommene Spezifikation blockiert dies nicht, sie bleibt als schuldige Ratifizierung gekennzeichnet. Auf Alpha/Beta/GA belässt es das Feature im Status in-progress zur Überprüfung durch /check verify und /test und setzt niemals Verify it oder Test it. Erstellt niemals Dateien in docs/scope/ (nur Scopes; Analyse/Recherche ist Aufgabe von /architect, in der rationale.md der Spezifikation).
• Schreibt niemals Spezifikationsinhalte oder berät über eine Entscheidung (signalisiert den Bedarf, delegiert an /architect); restrukturiert niemals die root AGENTS.md (das macht /audit); neue Bereichskonventionen erfolgen anschließend über /sync. Eine enge Ausnahme: bei Jetzt bauen, als angenommene Spezifikation aufzeichnen (Step 0) darf /entwickeln eine Spezifikation erstellen, aber nur im Status Angenommen und nur die Felder für die Annahmenaufzeichnung (geschuldete Entscheidung, getroffene Annahme, autorisiert von, Codebereich, Anforderungssamen). Es schreibt niemals eine Begründung und bringt eine Angenommene Spezifikation nie über diesen Zustand hinaus; die Bereinigung obliegt /architect. Dies ist die einzige Spezifikation, die /entwickeln erstellt.
• Ein Spezifikationsberührungspunkt bei einer bestehenden Spezifikation: die Zeile **Status**: (Dach-Entscheidung → die des index.md, niemals die eines Kindes), plus das Ausfüllen der Zeile für den Spezifikations-Pointer des Features. Baubeginn: Vorgeschlagen → In Bearbeitung; Bau abgeschlossen (Feature → done): In Bearbeitung → Akzeptiert (eine Spezifikation ist nicht Akzeptiert, bis ihr Feature ausgeliefert ist). Bearbeite niemals den Spezifikationsinhalt, nur diese Zeile, chirurgisch: lies sie direkt vor dem Schreiben erneut; unerwarteter Zustand (bereits Akzeptiert, Ersetzt) → signalisieren, nicht überschreiben. Verschiebe eine Spezifikation niemals aus dem Status Angenommen (das ist Ratifizierung, Aufgabe von /architect): eine Angenommene Spezifikation bleibt während des Baus Angenommen, selbst wenn das Feature in-progress ist, sodass sie nie Akzeptiert erreichen kann, bis /architect sie ratifiziert. Das Feature selbst kann dennoch als done markiert werden (Entscheidung des Entwicklers); die Angenommene Spezifikation bleibt als schuldige Ratifizierung gekennzeichnet, sie blockiert done nicht.
• Artefaktbasis: standardmäßig docs/, .workflow/, wenn docs/ eine veröffentlichte Dokumentationsseite ist. Lies von dem, was existiert (Pfade hier gehen von docs/ aus).
• Gemeinsamer Scope: lies ihn direkt vor dem Setzen erneut, bearbeite nur das spezifische Kontrollkästchen, den Status oder die Zeile des Pointers (schreibe die Datei nie neu); Feature nicht wie erwartet (bereits done, überarbeitet) → signalisieren, nicht überschreiben.

---

Portabilität (jedes Betriebssystem, jeder Agent)

Jeder Agent Skills Client, macOS/Linux/Windows. Erkennungsausschnitte sind POSIX-Referenz; verwende die plattformunabhängigen Dateiwerkzeuge deines eigenen Agenten. Baut Inline auf dem Hauptthread (Step 3); die einzigen Subagenten sind ein schreibgeschützter scout, der Code erkundet (Step 2.5) und ein schreibgeschützter researcher für eine Dokumentenprüfung (Step 2.6, zurückfallend auf das Bauen aus Wissen ohne Web-Fähigkeit), beide auf dem günstigsten Modell. Gebündelte Anleitungen (ui-guide.md, logical-guide.md, checklist.md) und der Bauablauf nach der Prüfung (flow/build.md) sind Pfade relativ zum Ordner dieser Skill; der Hauptthread liest sie. Keine interaktive Fragenauswahl → stelle die Fragen als Klartext mit denselben Optionen.

Ausführung

Bevor du baust: das Projekt muss bereits existieren (außer der Scaffold-Aufgabe)

Ausnahme: Wenn dies die Scaffold-Unteraufgabe des Features Stack- und Architekturgrundlage ist (die Eingabeaufforderung sagt scaffold, oder der Schritt initialisiert das Projekt aus der Stack-Spezifikation), IST das Erstellen des Projekts die Aufgabe. Lies die ARCHITEKTUR-Spezifikation (## Vorgeschlagener Stack); führe den eigenen Projektinitialisierer des Frameworks für den in der Spezifikation genannten Stack aus; installiere die grundlegenden Abhängigkeiten (Framework, Core-Laufzeit, nur das, was der erste Slice benötigt); lege Verzeichnisse an; bestätige, dass ein Dev-Server oder Build läuft. Behalte das Repository, das der Initialisierer erstellt (verwerfe es niemals beim Verschieben des Projekts); wenn es keines erstellt hat und die Git-Integration aktiviert ist, git init. Scaffold-Schritte leiten sich aus der Stack-Entscheidung ab (eine Entscheidungsspezifikation hat keinen Bauplan). Installiere Just-in-Time: NICHT jede in der Spezifikation genannte Bibliothek (E-Mail, Überwachung usw.); jedes spätere Feature installiert seine eigenen beim Bau; nur übergreifende Werkzeuge (Lint, Format, Typsicherheit) kommen früh, über /audit + die Tooling-Aufgabe. Dann fahre fort.

Andernfalls baut /entwickeln in ein bestehendes Projekt. Kein Skelett (kein package.json/pyproject.toml/go.mod/Manifest, kein Quellbaum) und nicht die Scaffold-Aufgabe → stoppe:

Kein Projekt zum Bauen gefunden. Führe zuerst den Scaffold-Schritt aus (die Scaffold-Unteraufgabe des Stack- und Architekturfeatures, gemäß deiner Architekturspezifikation), dann führe /entwickeln erneut aus.

Ein Projekt existiert (selbst ein leeres Scaffold) → fahre fort.

Bevor du baust: Aktualität & Zusammenarbeit (nicht auf veraltetem Stand oder über einen Kollegen hinweg bauen)

Bevor du etwas veränderst (stillschweigend überspringen, wenn allein, offline oder Git nicht verwendet): git fetch leise ausführen; Basis = main, sonst master; Anzahl der Rückstände (git rev-list --count HEAD..origin/<basis>); nicht committede Arbeit (git status --short).

• Im Rückstand (Anzahl > 0) → stoppe und warne: "Du bist N Commits hinter origin/$BASIS. Ein Kollege könnte dies bereits geändert oder ausgeliefert haben. Ziehe zuerst (pull), dann führe erneut aus."
• Nicht committede Arbeit im Bereich, den du berühren wirst → warne: "Du hast hier nicht committede Änderungen. Committe oder stashe zuerst, damit dieser Build sich nicht damit überschneidet." Lasse sie fortfahren, wenn sie darauf bestehen.
• Feature in-progress im Scope UND sein Codebereich (Pfad der Zeile des Pointers) hat aktuelle Commits von einem anderen Autor (git log --format='%an' -- <bereich>) → warne: " sieht so aus, als wäre es bereits von jemand anderem teilweise gebaut. Koordiniere, bevor du es fortsetzt." Bestätige vor dem Fortfahren.

Warnungen, keine harten Blockaden, aber zeige sie an.

Git-Integration: wenn das nächstgelegene AGENTS.md ## Git sagt integration: on, lies flow/git.md und befolge es (Branch vor dem Bauen, Commits, wenn Meilensteine erreicht sind); abwesend oder off → keine aktive Git-Tätigkeit.

Step 0: Die Spezifikationsprüfung (immer zuerst)

Ist eine Entscheidung geschuldet und nicht dokumentiert? Beurteile dies NICHT durch Selbstreflexion ("habe ich das Gefühl, etwas zu erfinden?"), das Baumodell rationalisiert eine echte Entscheidung als "nur Verdrahtung" und lässt sie durch. Verwende einen positiven Input-Abdeckungstest, der mechanisch ist und schwieriger zu umgehen:

Zähle jeden Wert auf, den dieser Build produzieren, berechnen oder anzeigen muss (aus den Akzeptanzkriterien und dem Design der Spezifikation). Gib für jeden an, ob die Spezifikation benennt, woher er kommt (eine Eingabe, eine DB-Spalte, eine Ableitung aus einem benannten Wert, eine vorherige Entscheidung). Jeder erforderliche Wert ohne benannte Quelle ist eine geschuldete Entscheidung.

Wenn eine Quelle nicht benannt ist, stoppe und leite zur Prüfung weiter (/architect, oder zeichne eine Angenommene Spezifikation auf; /entwickeln implementiert Entscheidungen, es trifft sie nicht). Eine Entscheidung ist auch dann geschuldet, wenn du erfinden müsstest:

• Einen Anbieter, eine Bibliothek, eine Integration, ein Datenmodell oder ein bereichsübergreifendes Muster (z. B. Auth-Anbieter, DB/ORM, Caching-Strategie).
• Eine ganze UI-Seite oder einen Bildschirm: ihr Designsystem (gibt es dort design.md? Wenn nicht, welche Richtung?), Abschnitte/Zusammensetzung, Komponenteninventar, Asset-Strategie (kein Screenshot, keine Repo-Bilder → z. B. eine Online-Quelle). Geschuldet, es sei denn, ein design.md UND eine Spezifikation auf Seitenebene legen diese fest.
• Das Verhalten eines Features (Suche, ein Assistent: "Was genau soll es tun?" ist offen; /architect stellt diese Fragen). Geschuldet, es sei denn, eine Spezifikation definiert es.

Was "lokales Implementierungsdetail" wirklich bedeutet (die enge Ausnahme): NUR eine Wahl zwischen Optionen, die die benannten Quellen der Spezifikation bereits zulassen, eine Schleifenart, ein Variablenname, welcher Helfer aufgerufen werden soll. Sobald eine Wahl eine Quelle eines Wertes oder ein Verhalten, das ein Akzeptanzkriterium einschränkt, bestimmt, ist sie per Definition tragend, egal wie klein sie aussieht. "Das Heute des Benutzers aus der Zeitzone seiner letzten gelesenen Zeile ableiten" ist kein lokales Detail: Es wählt die Quelle eines Wertes, den ein Akzeptanzkriterium einschränkt, also ist es geschuldet. NICHT geschuldet für echte reine Implementierung: eine kleine Fehlerbehebung, eine Komponente, die einem bestehenden design.md entspricht, Verdrahtung von Teilen, deren Quellen die Spezifikation bereits nennt, eine Textanpassung, alles, was eine bestehende Spezifikation/design.md/AGENTS.md vollständig regelt.

Härte nicht auf Seitennamen oder auf ein einzelnes Beispiel fest (Zeitzone ist eine Veranschaulichung des Musters, keine Regel); wende den Input-Abdeckungstest auf das an, was gefragt wurde. Falschnegative sind die Fehlerart, eine echte Entscheidung zu bauen, ohne es zu merken: wenn die Quelle eines erforderlichen Werts nicht benannt ist oder du unsicher bist, behandle es als geschuldet und frage (Panel unten).

Lies nur das, was dieses Feature benötigt, niemals den gesamten docs/-Baum: seine eine Scope-Datei und seine eine maßgebliche Spezifikation (eine Datei oder ein übergeordnetes index.md plus die eine untergeordnete, die diese Unteraufgabe spezifiziert). Keine Zeilen anderer Features, Scope-Dateien, Workspaces oder nicht zusammenhängender Spezifikationen.

Prüfe, in dieser Reihenfolge:

1. Finde die Scope-Datei dieses Features (nur diese eine). Monorepo → docs/scope/<workspace>/ für das Paket der Aufgabe. Wähle die Datei (scope.md oder die passende <epic>.md in einer Aufteilung) ausschließlich aus der Tabelle "Auf einen Blick"; lies nur den Abschnitt dieses Features. benötigt eine Entscheidung ohne Spezifikations-Pointer → Entscheidung geschuldet und fehlend. Fehlerhaft → signalisiere und frage, rate nicht.
2. Öffne die maßgebliche Spezifikation über den spec-Pointer des Features, lies nur ihre Build-Spezifikationsabschnitte, wie im Bauablauf (flow/build.md) definiert, Step 2, Punkt 1. Gefunden → es ist die Spezifikation; fahre fort. Kein Pointer und keine verlinkte Spezifikation → gezielte Suche in docs/specs/<workspace>/ nach einer, die zum Scope dieses Features passt, niemals eine pauschale Lektüre.
3. Das nächstgelegene AGENTS.md (Workspace/Bereich) kann die Entscheidung bereits enthalten, synchronisiert von einem früheren Feature (z. B. "der Auth-Anbieter ist bereits gewählt") → fahre ohne neue Spezifikation fort.

Entscheidung geschuldet und nicht dokumentiert → rate nicht, stoppe nicht stillschweigend. Frage (Einzelauswahl; AskUserQuestion auf Claude Code):

• frage: "Dies scheint zunächst eine Architekturentscheidung zu erfordern: <nenne die spezifische tragende Wahl, z. B. 'welcher Auth-Anbieter + Sitzungsmodell'>. Wie möchtest du damit umgehen?"
• kopfzeile: "erst Spezifikation?"
• optionen:
  1. Architekt es zuerst: "Empfohlen. Halte die Entscheidung in einer Spezifikation fest, bevor du baust, damit der Build eine Spezifikation hat." → hier enden mit der folgenden Übergabe. Baue nicht.
  2. Nein, nicht nötig: "Ich habe entschieden, dass es hier keine echte Entscheidung gibt; baue direkt." → fahre mit dem Bauablauf fort (flow/build.md).
  3. Jetzt bauen, als angenommene Spezifikation aufzeichnen: "Baue es, aber schreibe zuerst die Annahme auf, damit die Entscheidung im Repository lebt, nicht nur in diesem Chat. Die Angenommene Spezifikation bleibt als schuldige Ratifizierung gekennzeichnet (/architect), aber das blockiert niemals die Markierung des Features als done." → schreibe eine Angenommene Spezifikation (siehe unten), dann fahre mit dem Bauablauf (flow/build.md) fort und hinterlasse einen angenommene Entscheidung (Spezifikation NNNN)-Hinweis im Scope (docs/scope/).

Das Tool fügt "Andere" automatisch als Freitext-Option hinzu.

Bei Jetzt bauen, als angenommene Spezifikation aufzeichnen schreibe eine minimale Angenommene Spezifikation vor dem Bauen (dies ist der eine enge Spezifikations-Schreibvorgang, der /entwickeln gehört; siehe Artefaktverantwortung). Löse $SPEC_DIR so auf, wie /architect es tut (Einzel-Repository → docs/specs/; Monorepo-Workspace → docs/specs/<workspace>/), nimm die nächste freie NNNN und schreibe $SPEC_DIR/NNNN-<slug>.md:

# NNNN · <feature>

**Status**: Angenommen
**Datum**: <heute>
**Autorisiert durch**: <entwickler>, während /entwickeln

## Geschuldete Entscheidung
<die spezifische tragende Wahl, die nicht getroffen wurde>

## Getroffene Annahme
<die konkrete Annahme, die dieser Build verwenden wird>

## Codebereich
<die Pfade, die dieser Build berühren wird>

## Anforderungen
<Akzeptanzkriterien-Samen, die aus dem Scope "Erledigt, wenn" übernommen wurden, falls vorhanden>

## Ratifizieren
Diese Entscheidung wurde von /entwickeln aufgezeichnet, nicht beraten. Führe `/architect <feature>`
aus, um sie zu beraten und zu ratifizieren. Bis dahin bleibt sie als geschuldete Entscheidung gekennzeichnet; sie blockiert nicht die Markierung des Features als `done`.

Setze die Zeile spec des Feature-Scopes auf diese Datei. Die Annahme ist jetzt dauerhaft: sie überlebt /clear, Teamkollegen lesen sie, und ein späteres /entwickeln baut darauf auf, anstatt erneut zu raten. Die Angenommene Spezifikation bleibt als schuldige Ratifizierung gekennzeichnet; sie blockiert nicht die Markierung des Features als done (siehe flow/build.md, Step 4).

Bei Architekt es zuerst beende mit:

Führe dies als nächstes aus und kehre dann zu /entwickeln zurück:

/architect <feature>: <die spezifische zu klärende Entscheidung>

Sobald die Spezifikation existiert, führe /entwickeln <aufgabe> erneut aus und ich werde danach bauen.

Keine Entscheidung geschuldet (reine Implementierung) → überspringe die Frage, fahre fort.

Bauablauf (Steps 1-4)

Einmal

…

[abgeschnitten für Übersetzung]