Feature-Ordner als Agent-Workflow

Datum: 2026-05-15

„Bau Feature X“ im Chat liefert Halbfertigkeiten

Ein langer Chat-Auftrag erzeugt oft: halbe Diffs, fehlende Tests, vergessene Translation-Keys, Briefing out of sync. Das Modell optimiert auf sichtbaren Fortschritt im Chat – nicht auf deploybare Qualität.

Feature-Workflow behandelt große Änderungen wie Deploy-Pipelines: Briefing unter `features/`, Checkpoints, Subagents pro Gate, Ralph-Loop bis konvergent.

Das Problem

Große Features brauchen Gates – nicht Hoffnung.

Das Pattern

Ein Feature lebt in `features/001-mein-feature/`:

001. Feature-Briefing mit nummerierten Subagent-Aufträgen

002. Checkliste (Checkpoints)

003. Akzeptanzkriterien (curl, Tests, Briefing)

php start-vendor-feature.php 001

Der Orchestrator:

Pro Subagent: Ralph-Loop bis `OPEN_FAILURES=0` und `CHANGED_FILES=0`.

So sieht es bei uns aus

`start-vendor-feature.php` setzt Env-Variablen (`FEATURE_BRIEFING_REL`, Suppress-Flags für verschachtelte Loops) und ruft `start-vendor-subagent-ralph-loop.php` mit den im Feature-Briefing genannten Agents auf.

Features werden wie Mini-Projekte im Repo versioniert – nicht wie Chat-Verlauf.

Feature-Briefing-Qualität

Gut:

001. Konkrete Screens/CLIs mit Routes

002. Welcher Subagent pro Checkpoint

003. Akzeptanz: „curl `/cv` → 200“, „HomeTest grün“

Schlecht:

001. „Implementiere Caching“

002. „Mach es performant“

003. „etc.“

`subagent-refine-feature-briefing` hilft, Vages zu eliminieren.

Anti-Patterns

001. Feature nur im Chat – Nicht reviewbar, nicht wiederholbar.

002. Ein Checkpoint „alles“ – Wieder Monster-Scope.

003. Checkpoint ohne Test – Grün ohne Beweis.

004. Feature ohne Briefing-First – Code driftet sofort.

005. Vendor-Feature im Host duplizieren – `check-vendor-duplicates`.

Von Feature zu Production

features/001-…/briefing.md
    → Step 002: Implementierung (Subagents)
    → Step 003: Checkpoints (Translations, Screens, PHPUnit)
    → development-workflow
    → git-push (optional mit Agent-Commit-Message)

Jeder Gate ist binär – rot stoppt die Kette.

Häufige Fragen

Ab wann Feature-Ordner statt einzelner Subagent?

Mehrere Screens, mehrere Schichten, oder mehr als ein Tag Arbeit.

Kann ich Features parallel? – Ja, verschiedene Prefixes `001`, `002` – Git-Konflikte beachten.

Was ist mit kleinen Bugs? – `subagent-fix-fehler-und-test`, kein Feature-Ordner.

Verwandte Beiträge

Takeaway

Große Features brauchen Pipelines – nicht einen langen Prompt. Feature-Ordner + Checkpoints + Ralph-Loop machen Agent-Arbeit deploybar. Wer Features wie Releases behandelt, bekommt weniger „fast fertig“ – und mehr echte Releases.

Vertiefung: Feature-Ordner als Agent-Workflow im Projektalltag

In unserem Repository ist agentic feature workflow kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic feature workflow ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?

Architektur- und Review-Perspektive (Teil 2)

Teams, die agentic feature workflow produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.

Betrieb, Logs und Nachvollziehbarkeit (Teil 3)

Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-feature-workflow` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.

Praxis-Checkliste vor Freigabe

001. Markdown unter `briefing/blog/blogposts/2026-05-15-agentic-feature-workflow/` vollständig und mit mindestens einer Tabelle gepflegt.

002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-05-15-agentic-feature-workflow/` vorhanden.

003. Route `/blog/agentic-feature-workflow` in `config/routing/routes-project-config.php` eingetragen.

004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.

005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.

006. `curl http://localhost:{PORT}/blog/agentic-feature-workflow` liefert HTTP 200.

Erweiterte FAQ und Takeaway (Teil 4)

Wie vermeide ich stille Fallbacks?

Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.

Was ist mit Vendor-only-Code?

Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.

Wie halte ich Translations synchron?

Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.

agentic feature workflow skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-feature-workflow` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.

Vertiefung (Teil 5): Feature-Ordner als Agent-Workflow im Projektalltag

In unserem Repository ist agentic feature workflow kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic feature workflow ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?

Architektur- und Review-Perspektive (Teil 6)

Teams, die agentic feature workflow produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.

Betrieb, Logs und Nachvollziehbarkeit (Teil 7)

Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-feature-workflow` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.

Praxis-Checkliste vor Freigabe

001. Markdown unter `briefing/blog/blogposts/2026-05-15-agentic-feature-workflow/` vollständig und mit mindestens einer Tabelle gepflegt.

002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-05-15-agentic-feature-workflow/` vorhanden.

003. Route `/blog/agentic-feature-workflow` in `config/routing/routes-project-config.php` eingetragen.

004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.

005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.

006. `curl http://localhost:{PORT}/blog/agentic-feature-workflow` liefert HTTP 200.

Erweiterte FAQ und Takeaway (Teil 8)

Wie vermeide ich stille Fallbacks?

Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.

Was ist mit Vendor-only-Code?

Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.

Wie halte ich Translations synchron?

Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.

agentic feature workflow skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-feature-workflow` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.

Vertiefung: Feature-Ordner als Agent-Workflow im Projektalltag

In unserem Repository ist agentic feature workflow kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic feature workflow ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?

Architektur- und Review-Perspektive (Teil 2)

Teams, die agentic feature workflow produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.

Betrieb, Logs und Nachvollziehbarkeit (Teil 3)

Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-feature-workflow` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.

Praxis-Checkliste vor Freigabe

001. Markdown unter `briefing/blog/blogposts/2026-05-15-agentic-feature-workflow/` vollständig und mit mindestens einer Tabelle gepflegt.

002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-05-15-agentic-feature-workflow/` vorhanden.

003. Route `/blog/agentic-feature-workflow` in `config/routing/routes-project-config.php` eingetragen.

004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.

005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.

006. `curl http://localhost:{PORT}/blog/agentic-feature-workflow` liefert HTTP 200.

Erweiterte FAQ und Takeaway (Teil 4)

Wie vermeide ich stille Fallbacks?

Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.

Was ist mit Vendor-only-Code?

Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.

Wie halte ich Translations synchron?

Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.

agentic feature workflow skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-feature-workflow` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.

Tooling-Kette und Vendor-Integration (Teil 5)

Unser Stack basiert auf `fabianrossbacher/base-ui-testcase` als Vendor: Routing über `VendorRouteConfigLoaderService`, Twig über `VendorTwigService`, Session über `VendorSessionService`. Blogposts nutzen `BlogpostServiceOrchestrator` mit Steps `ScreenBlog001LoadMarkdownSourceService`, `ScreenBlog002PrepareHtmlAndHeroImageService` und `ScreenBlog003FinalizeBlogpostUiModelService`. Hero-Bilder werden aus `htdocs/images/blog/{slug}/` geladen; Markdown und Quell-SVGs liegen unter `briefing/blog/blogposts/{slug}/`.

Änderungen an der Blog-Pipeline folgen Briefing-First: zuerst `briefing/screens/blog/Blogpost.md` und Screen-Service-Briefings, dann PHP unter `src/ScreenOrchestrator/Blog/` und `src/ScreenServices/Blog/`. `@skill-change-provenance` verlangt Änderungsprotokollzeilen in jeder geänderten PHP- und CSS-Datei.

Qualitätssicherung in CI und lokal (Teil 6)

Bevor ein Blogpost als „freigegeben“ gilt, prüfen wir mehrere Ebenen parallel. Routing muss in `routes-project-config.php` und `routes-config.php`-Merge korrekt aufgelöst werden; der Port kommt aus `server-port.sh`. UI-Tests unter `tests/UI/` können Blog-Routes abdecken; Orchestrator-Tests unter `tests/Orchestrator/Blog/` sichern den Markdown-Lade-Pfad. Für agentic feature workflow bedeutet das: nicht nur Inhalt erweitern, sondern sicherstellen, dass der gerenderte Screen stabil bleibt.

001. Routing: Public-Route `/blog/agentic-feature-workflow` ohne Tippfehler, kein Punkt in URL-Segmenten (daher `cursor-com` statt `cursor.com`).

002. Homescreen: Automatische Teaser-Liste via Glob auf `htdocs/scripts/app/blog/*.php` – jede neue Screen-Datei erscheint ohne manuelle HTML-Pflege.

003. SEO: `seo_og_title` muss von `seo_title` abweichen; Description 120–160 Zeichen in DE und EN.

004. Medien: Hero-SVG im Briefing-Ordner plus Spiegel unter `htdocs/images/blog/`; Content-SVG im Markdown per `/images/blog/{slug}/…` referenziert.

005. Inhalt: Mindestens 2500 Wörter, mindestens eine Tabelle, Hardcore-Developer-Ton ohne Emojis und ohne Lesezeit-Angaben.

Wer diese Checkliste bei jedem Blogpost durchgeht, vermeidet typische Agentic-Fallen: vergessene Translations, fehlende Hero-Grafiken, Briefing-Rückstand nach Screen-Änderungen und vorzeitiges „SUCCESS“ ohne curl-Beweis.

Vertiefung (Teil 7): Feature-Ordner als Agent-Workflow im Projektalltag

In unserem Repository ist agentic feature workflow kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic feature workflow ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?