joris887/exosuit

---

build

Baue ein Projekt aus einer natürlichsprachlichen Beschreibung. Orchestriert Setup, Planung und Implementierung automatisch.

Die gesamte Benutzerausgabe MUSS in einfachem Deutsch erfolgen. Kein Fachjargon: kein „TDD“, „Sprint“, „PR“, „Squash Merge“, „CI/CD“, „ORM“, „Middleware“. Falls ein Fachbegriff unvermeidbar ist, erkläre ihn in Klammern.

Argumente

$ARGUMENTS – eine Beschreibung in einfachem Deutsch, was gebaut werden soll (z. B. „eine Aufgabenverwaltungs-App mit Benutzerkonten und Fälligkeitsdaten“).

Phase 0: Setup prüfen

Lies das aktuelle Profil aus der CLAUDE.md. Wenn nicht lean, notiere das Profil, aber fahre fort – /build verwendet unabhängig vom Projektprofil intern immer die lean-Ausführung.

Phase 1: Zerlegen

Zeige: „Plane, was gebaut werden muss …“

Zerlege intern die Beschreibung mittels /ideate-Logik in geordnete Stories:

1. Identifiziere die beschriebenen Kernentitäten und Funktionen
2. Zerlege in abhängigkeitsgeordnete Implementierungsschritte
3. Klassifiziere jeden Schritt als Feature, Infrastruktur oder Test
4. Schätze die Größe jedes Schrittes (anstreben: Schritte, die ≤5 Dateien betreffen)

Zeige dem Benutzer NICHTS davon. Keine Story-Typen, kein SPIDR, keine Prioritätskennzeichnungen, keine Methodik-Begriffe. Behalte die Zerlegung intern.

Erstelle einen internen Plan (nicht für den Benutzer sichtbar):

steps:
  - summary: "Lege die Datenbanktabellen an"
    type: infrastructure
    files: [...]
  - summary: "Baue die API-Endpunkte"
    type: feature
    files: [...]
  - summary: "Füge Benutzerauthentifizierung hinzu"
    type: feature
    files: [...]
  - summary: "Schreibe Tests"
    type: testing
    files: [...]

Entdeckungs-Capture (rückwirkend)

Erfasse still den Entdeckungskontext für zukünftige Phasenüberprüfungen – der Benutzer sieht dies NICHT:

1. Leite den Archetyp aus der Beschreibung ab (Klassifiziere anhand der 10 Archetypen in .claude/skills/discover/references/scale-guide.md)
2. Setze Skalierung auf Quick Build
3. Erstelle automatisch ein minimales docs/reference/DECISION_LOG.md (kopiere Vorlage aus .claude/skills/discover/assets/decision-log.md) und protokolliere alle technischen Entscheidungen mit Konfidenz: ASSUMED
4. Füge Phasenübergangs-Stories (E0N-REVIEW: 3-Story-Kurzvariante – E0N-001, E0N-004, E0N-006) als letzten internen Schritt hinzu
5. Speichere Klassifikation in vision/classification.md

Dadurch erhalten /build-Benutzer den Überprüfungszyklus ohne anfängliche Reibung.

Phase 2: Ausführen

Für jeden Schritt in Abhängigkeitsreihenfolge:

1. Zeige Fortschritt in einfachem Deutsch:

   • „Richte die Datenbank ein …“ / „Baue die API …“ / „Füge Benutzeranmeldung hinzu …“ / „Schreibe Tests, um sicherzustellen, dass alles funktioniert …“
   • Verwende Sprache, die der Benutzer versteht. Niemals: „Führe Story E01-003 aus (Typ: feature, Größe: STANDARD)"

2. Führe die Story-Cycle-Lean-Verhalten aus:

   • Planen (leichtgewichtig – keine Konfidenzbewertung)
   • Bauen mit TDD (Testgetriebene Entwicklung) bei nicht-trivialen Teilen (führe Tests aus, erkläre TDD-Methodik nicht)
   • Überprüfe, ob Tests bestehen
   • Committe mit konventionellem Format (erkläre Commit-Konventionen nicht)

3. Triff alle technischen Entscheidungen still:

   • Framework-/Bibliothekswahl: Wähle die beste Passung, dokumentiere in einem abschließenden Bericht
   • Architektur: Folge Standardmustern für den erkannten Stack
   • Dateistruktur: Folge bestehenden Projektkonventionen oder erkannten Stack-Standards
   • Stoppe nur bei echter Produkt-Unklarheit: „Das Design könnte in zwei Richtungen gehen: [A] oder [B]. Welche bevorzugst du?“
   • Stoppe niemals wegen: Datenbankwahl, API-Stil, Dateibenennung, Test-Framework, Ordnerstruktur

4. Behandle Fehler elegant:

   • Wenn ein Schritt nach 2 Versuchen fehlschlägt, überspringe ihn mit einem Hinweis: „Ich konnte [X] nicht automatisch zum Laufen bringen. Folgendes muss manuell erledigt werden: [Beschreibung]“
   • Fahre mit den restlichen Schritten fort – blockiere nicht den gesamten Build

Phase 3: Abschluss

3A. Starten & Verifizieren (falls zutreffend)

Überprüfe in den CLAUDE.md-Befehlen einen dev:-Befehl. Falls einer konfiguriert ist:

1. Zeige: „Starte dein Projekt …“
2. Führe den Dev-Befehl im Hintergrund mit Bash aus und run_in_background: true
3. Warte einige Sekunden. Lies die Ausgabe – suche nach URLs, Ports, Dateipfaden oder Statusmeldungen.
4. Zeige, was der Befehl produziert. Wenn er eine URL ausgibt, hebe sie hervor. Wenn es ein CLI ist, zeige die Hilfeausgabe. Wenn ein Server gestartet wird, zeige die Adresse.
5. Frage: „Schau es dir an und sag mir, was du denkst!“
6. Warte auf Rückmeldung. Positiv → fahre mit dem Abschlussbericht fort. Probleme → beheben und neu starten.

Wenn kein dev-Befehl konfiguriert ist (Bibliotheken, Pakete, Pipelines usw.) → überspringe diesen Schritt. Tests haben den Build bereits verifiziert.

Nimm nicht localhost oder eine bestimmte URL an. Lies die tatsächliche Befehlsausgabe. Verschiedene Projekte liefern unterschiedliche Ergebnisse.

3B. Abschlussbericht

Zeige einen Abschlussbericht in einfachem Deutsch:

## Fertig!

### Was gebaut wurde
- [Funktion 1]: [Beschreibung in einfachem Deutsch, was sie tut]
- [Funktion 2]: [Beschreibung]
- ...

### Erstellte/Geänderte Dateien
- `src/models/user.ts` – Benutzer-Datenmodell
- `src/api/auth.ts` – Anmelde- und Registrierungsendpunkte
- ...

### Tests
- [N] Tests geschrieben, alle bestanden

### Technische Entscheidungen
- **Datenbank:** PostgreSQL (zuverlässig, kostenlos, funktioniert gut mit [Framework])
- **Auth:** [gewählter Ansatz] – [einsätzige Begründung]
- ...

### Probiere es aus
[Wenn Dev-Befehl ausgeführt wurde: „Dein Projekt läuft – siehe oben“]
[Wenn Dev-Befehl existiert, aber nicht gestartet wurde: „Führe `[dev-Befehl]` aus, um zu starten“]
[Wenn kein Dev-Befehl: diesen Abschnitt weglassen]

### Nächste Schritte
- [Vorschlag 1, z. B. „Füge ein Zahlungssystem mit /build 'Stripe-Zahlungsintegration' hinzu“]
- [Vorschlag 2]

Regeln

• Nur einfaches Deutsch – jede Benutzernachricht muss für jemanden verständlich sein, der noch nie programmiert hat
• Stille technische Entscheidungen – wähle gute Standardwerte, dokumentiere sie im Abschlussbericht, frage nie
• Stoppe nur bei Produktfragen – „Sollen Benutzer ihr Konto löschen können?“ ist gültig. „REST oder GraphQL?“ nicht.
• Sicherheits-Hooks laufen weiter – Geheimnis-Erkennung, Git-Schutz und Testausführung erfolgen unsichtbar
• Lean-Ausführung – kein Qualitäts-Agent-Einsatz, keine Sprint-Spezifikationen, keine Retrospektiven, keine Dokumentationsgenerierung über das Nötigste hinaus
• Graceful Skippen – fehlgeschlagene Schritte werden notiert, sind nicht fatal. Der Build wird fortgesetzt.
• Eine Sitzung – die erste Version von /build wird in einer einzigen Sitzung abgeschlossen. Mehr-Sitzungs-Builds sind zukünftige Arbeit.