Communitygithub.com

usibuilds/feature-builder

Erstelle Software oder Automatisierungen mit dem Ansatz 'Top-down planen, Bottom-up bauen' – zuerst eine kurze PLAN.md-Spezifikation, dann ein getestetes Feature pro Chat, abgeschlossen mit einer FEATURE COMPLETE-Meldung und einer Übergabe für den nächsten Chat.

Was ist feature-builder?

Feature Builder ist ein Skill für KI-Assistenten (wie Claude Code, Cursor oder Codex), der einen strukturierten, zweistufigen Entwicklungsprozess ermöglicht. Im ersten Schritt (Top-down) wird eine kompakte `PLAN.md` erstellt, die das Produkt, den Tech-Stack, Kernentitäten, Feature-Checklisten und Entscheidungen festhält. Im zweiten Schritt (Bottom-up) wird genau ein Feature pro Chat implementiert und getestet, bevor eine klare FEATURE COMPLETE-Meldung und eine HANDOFF-Übergabe ausgegeben werden. Der Skill hilft, Chat-Historien kurz zu halten (Plan statt 100K Tokens), reduziert Kontextüberlastung und stellt sicher, dass jedes Feature vollständig getestet ist, bevor das nächste begonnen wird. Unterstützt wird er durch die Trennung von Planungs- und Bauphasen, automatische Testanleitungen und eine klare Checkliste für den Fortschritt.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/usibuilds/claude-context-zones/tree/main/skills/feature-builder

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Feature Builder — Top-down planen, Bottom-up bauen

Antworte in der Sprache des Nutzers. Behalte Code, Befehle, Dateinamen und die PLAN-/HANDOFF-Blöcke auf Englisch.

Idee: Ein Architekt zeichnet zuerst das ganze Haus (Top-down), dann setzen die Bauarbeiter einen getesteten Ziegelstein nach dem anderen (Bottom-up). Der Plan bleibt klein und lebt in einer Datei, sodass jeder neue Chat einen Plan mit 2–5.000 Tokens statt einer 100.000-Tokens-Chat-Historie liest.

Modus A — Top-down: Plan erstellen oder aktualisieren

Wenn noch kein Plan existiert oder der Nutzer um eine Planung bittet:

  1. Stelle höchstens 3 Fragen (Ziel, Nutzer, Muss-Features), es sei denn, die Antworten sind bereits bekannt.
  2. Schreibe einen PLAN.md-Block (max. ~120 Zeilen):
    • Produkt in einem Satz
    • Tech-Stack (festgelegt)
    • Kerndaten / Entitäten (Stichpunkte, kein Code)
    • Features als Checkliste in Bau-Reihenfolge: - [ ] **F1 Name** — einzeiliger Umfang
    • Akzeptanzregel (was „fertig“ bedeutet)
    • Entscheidungslog
    • Später / Ideen (Dinge, die wir JETZT NICHT bauen)
  3. Sage dem Nutzer, er solle es als PLAN.md im Projektwissen (Chat-Apps) oder docs/PLAN.md im Repository (Codierungstools) speichern.

Modus B — Bottom-up: EIN Feature bauen

Wenn der Nutzer sagt „baue F3“ oder „nächstes Feature“:

  1. Arbeite nur an diesem Feature. Lese nur das, was es braucht.
  2. Gib zuerst einen Minipian: Dateien/Knoten zum Erstellen oder Ändern sowie Akzeptanztests – 3–6 Prüfungen im QA-Stil: Eingabe → erwartetes Ergebnis. Warte auf die Zustimmung des Nutzers.
  3. Baue in kleinen Schritten. Gib nach jedem Schritt den genauen Test zum Ausführen oder den Klickpfad an.
  4. Alles, was zu einem anderen Feature gehört → füge es zu „Später / Ideen“ hinzu; baue es jetzt nicht.

Wenn alle Akzeptanztests bestanden sind — FEATURE COMPLETE

Gib genau diese Meldung aus:

✅ FEATURE ABGESCHLOSSEN: <F-Nummer + Name>
Bestandene Tests: <Liste>
PLAN.md-Update: markiere <F-Nummer> als [x]
Nächstes Feature: <nächste unmarkierte F-Nummer + Name>
→ Kopiere die Übergabe unten → neuer Chat → einfügen → "nächstes Feature"

Gib dann einen Handoff-Block aus: Ziel, Entscheidungen, Status, Dateien, offene Fehler, nächste 3 Schritte.

Wenn ein Test fehlschlägt oder der Nutzer noch nicht getestet hat

Gib keine FEATURE COMPLETE-Meldung aus. Behebe den Fehler, teste erneut und gib sie dann aus.

Verwandte Skills