Subagents statt Monster-Prompt
Datum: 2026-03-15
Der Generalist-Prompt skaliert nicht
„Prüf mal das ganze Projekt“ klingt effizient – liefert aber oberfläche Fixes, übersieht Schichtenregeln und meldet „fertig“, während curl und PHPUnit rot sind. Das Modell breitet sich aus, statt tiefe Qualität in einem Fachgebiet zu liefern.
Subagents sind das Gegenmittel: spezialisierte Agenten mit festem Scope, eigenem Briefing, Skills und Ralph-Loop bis Konvergenz.
Das Problem
| Monster-Prompt | Ergebnis |
|---|---|
| Alles auf einmal | Nichts richtig |
| Kein klarer Scope | Wichtige Schicht übersprungen |
| Keine Marker | Subjektives „ok“ |
| Nicht wiederholbar | Jeder Lauf anders |
Ein Generalist-Prompt ist ein Notnagel – keine Infrastruktur.
Das Pattern
Spezialisierte Subagents unter `cursor-rules/agents/`:
| Subagent | Scope |
|---|---|
| `subagent-check-repos` | SQL, Indizes, PHPDoc, UI-Nutzung |
| `subagent-check-translations` | Keys, Twig, DE/EN |
| `subagent-check-screens` | PHP, Twig, CSS, JS je Route |
| `subagent-check-orchestrator` | Steps, Briefing-Sync |
| `subagent-check-services` | Service-Regeln, Naming |
| `subagent-check-vendor-duplicates` | Keine Host-Kopien |
| `subagent-fix-fehler-und-test` | Reparieren bis grün |
Jeder Agent:
001. Lädt definierte `@skill-*` Referenzen.
002. Arbeitet nur im dokumentierten Scope.
003. Endet mit Ralph-Markern (`@skill-subagent-build`).
So sieht es bei uns aus
php start-vendor-subagent-ralph-loop.php subagent-check-translations
Der Agent kennt nur Translations – nicht Repositories, nicht SEO-Dashboards. Das reduziert Fehlfixes und beschleunigt Konvergenz.
Agent-Katalog statt Einzel-Prompt
Statt jedes Mal neu zu prompten, wächst ein Katalog:
| Kategorie | Beispiele |
|---|---|
| Prüfen | `check-screens`, `check-repos`, `check-js` |
| Bauen | `create-screen`, `create-cli-script` |
| Fixen | `fix-screen`, `fix-fehler-und-test` |
| Workflow | `feature-workflow-briefing`, `briefing-first` |
Neue wiederkehrende Aufgabe → neuer Subagent (mit Skill + Briefing), nicht neuer 300-Zeilen-Prompt.
Subagent vs. Skill vs. Rule
| Artefakt | Rolle |
|---|---|
| <strong>Rule</strong> | Grenze („niemals X“) |
| <strong>Skill</strong> | Handbuch („so prüfst du Y“) |
| <strong>Subagent</strong> | Ausführer („prüfe jetzt Y bis grün“) |
Subagents referenzieren Rules und Skills – sie ersetzen sie nicht.
Anti-Patterns
001. Ein Agent für alles – Wieder Monster-Prompt mit Markdown-Header.
002. Subagent ohne Ralph-Marker – Kein objektives Ende.
003. Scope im Chat erweitern – „Übrigens noch Repos…“ → neuen Agent starten.
004. Subagent ohne Briefing-Pfade – KI rät Dateilisten.
005. Fix-Agent vor Check-Agent – Erst Scope verstehen, dann reparieren (oft Check → Fix).
Workflow-Kette Beispiel
Neuer Screen `/cv`:
001. `subagent-create-screen` oder manuell mit Briefing-First
002. `subagent-check-screens` im Ralph-Loop
003. `subagent-check-translations`
004. `subagent-check-orchestrator`
005. `start-vendor-phpunit-tests.php`
006. curl alle Routes
Jeder Schritt ein Subagent – nicht einer für alles.
Häufige Fragen
Wie viele Subagents brauche ich?
Start mit 2–3 Prüf-Agenten + 1 Fix-Agent; erweitern bei wiederkehrenden Fehlertypen.
Duplikat zu Cursor Rules?
Nein – Rules sind statisch geladen; Subagents sind Aufträge mit Loop.
Kann ich Subagents kombinieren?
Sequenziell in Pipelines (`development-workflow`), nicht in einem Prompt vermischen.
Verwandte Beiträge
| Beitrag | Thema |
|---|---|
| Rules, Skills, Subagents | Drei Ebenen |
| Ralph-Loop | Konvergenz |
| Deep-Check | Batch-Subagent |
| Feature-Workflow | Checkpoints |
Takeaway
Ein Generalist-Prompt skaliert nicht; ein Agent-Katalog schon. Subagents machen Spezialisierung zur wiederholbaren Infrastruktur – mit Logs, Markern und klarem Scope. Wer „prüf mal alles“ durch „starte den richtigen Agenten“ ersetzt, gewinnt Tiefe statt Theater.
Vertiefung: Subagents statt Monster-Prompt im Projektalltag
In unserem Repository ist agentic subagents kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic subagents 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?
| Situation | Empfohlener Hebel | Erwartetes Ergebnis |
|---|---|---|
| Wiederholter Architekturfehler | Rule in `cursor-rules/rules/` | Modell hält Grenze dauerhaft ein |
| Komplexer mehrstufiger Ablauf | Skill `@skill-*` + Subagent | Checkliste statt Einmal-Prompt |
| Großes Feature mit mehreren Screens | `features/` + `start-vendor-feature.php` | Checkpoints bis deploybar |
| Einzelner Screen rot (curl 500) | `subagent-fix-fehler-und-test` | HTTP 200 + grüne Tests |
| Unklare Spec | Briefing-First in `briefing/` | Keine erfundenen Defaults im Code |
Architektur- und Review-Perspektive (Teil 2)
Teams, die agentic subagents 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.
| Review-Fokus | Prüffrage | Typischer Subagent |
|---|---|---|
| Screen-Schicht | Ruft PHP nur den Orchestrator auf? | `subagent-check-screens` |
| Orchestrator | Steps nummeriert, Briefing-Sync? | `subagent-check-orchestrator` |
| Services | Kein try-catch, keine array-Returns? | `subagent-check-services` |
| Repositories | SQL-Logging, Indizes, PHPDoc UI-Nutzung? | `subagent-check-repos` |
| Translations | Keys in Twig korrekt? | `subagent-check-translations` |
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-subagents` 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-03-15-agentic-subagents/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-03-15-agentic-subagents/` vorhanden.
003. Route `/blog/agentic-subagents` 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-subagents` 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.
| Merksatz | Bedeutung für agentic subagents |
|---|---|
| Briefing-First | Spec vor Code, immer |
| Ralph-Loop | Konvergenz statt „fertig“-Behauptung |
| curl + PHPUnit | Beweis statt Chat-Grün |
| Keine Emojis | Professioneller Ton in Code und UI |
agentic subagents 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-subagents` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung (Teil 5): Subagents statt Monster-Prompt im Projektalltag
In unserem Repository ist agentic subagents kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic subagents 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?
| Situation | Empfohlener Hebel | Erwartetes Ergebnis |
|---|---|---|
| Wiederholter Architekturfehler | Rule in `cursor-rules/rules/` | Modell hält Grenze dauerhaft ein |
| Komplexer mehrstufiger Ablauf | Skill `@skill-*` + Subagent | Checkliste statt Einmal-Prompt |
| Großes Feature mit mehreren Screens | `features/` + `start-vendor-feature.php` | Checkpoints bis deploybar |
| Einzelner Screen rot (curl 500) | `subagent-fix-fehler-und-test` | HTTP 200 + grüne Tests |
| Unklare Spec | Briefing-First in `briefing/` | Keine erfundenen Defaults im Code |
Architektur- und Review-Perspektive (Teil 6)
Teams, die agentic subagents 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.
| Review-Fokus | Prüffrage | Typischer Subagent |
|---|---|---|
| Screen-Schicht | Ruft PHP nur den Orchestrator auf? | `subagent-check-screens` |
| Orchestrator | Steps nummeriert, Briefing-Sync? | `subagent-check-orchestrator` |
| Services | Kein try-catch, keine array-Returns? | `subagent-check-services` |
| Repositories | SQL-Logging, Indizes, PHPDoc UI-Nutzung? | `subagent-check-repos` |
| Translations | Keys in Twig korrekt? | `subagent-check-translations` |
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-subagents` 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-03-15-agentic-subagents/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-03-15-agentic-subagents/` vorhanden.
003. Route `/blog/agentic-subagents` 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-subagents` 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.
| Merksatz | Bedeutung für agentic subagents |
|---|---|
| Briefing-First | Spec vor Code, immer |
| Ralph-Loop | Konvergenz statt „fertig“-Behauptung |
| curl + PHPUnit | Beweis statt Chat-Grün |
| Keine Emojis | Professioneller Ton in Code und UI |
agentic subagents 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-subagents` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung: Subagents statt Monster-Prompt im Projektalltag
In unserem Repository ist agentic subagents kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic subagents 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?
| Situation | Empfohlener Hebel | Erwartetes Ergebnis |
|---|---|---|
| Wiederholter Architekturfehler | Rule in `cursor-rules/rules/` | Modell hält Grenze dauerhaft ein |
| Komplexer mehrstufiger Ablauf | Skill `@skill-*` + Subagent | Checkliste statt Einmal-Prompt |
| Großes Feature mit mehreren Screens | `features/` + `start-vendor-feature.php` | Checkpoints bis deploybar |
| Einzelner Screen rot (curl 500) | `subagent-fix-fehler-und-test` | HTTP 200 + grüne Tests |
| Unklare Spec | Briefing-First in `briefing/` | Keine erfundenen Defaults im Code |
Architektur- und Review-Perspektive (Teil 2)
Teams, die agentic subagents 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.
| Review-Fokus | Prüffrage | Typischer Subagent |
|---|---|---|
| Screen-Schicht | Ruft PHP nur den Orchestrator auf? | `subagent-check-screens` |
| Orchestrator | Steps nummeriert, Briefing-Sync? | `subagent-check-orchestrator` |
| Services | Kein try-catch, keine array-Returns? | `subagent-check-services` |
| Repositories | SQL-Logging, Indizes, PHPDoc UI-Nutzung? | `subagent-check-repos` |
| Translations | Keys in Twig korrekt? | `subagent-check-translations` |
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-subagents` 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-03-15-agentic-subagents/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-03-15-agentic-subagents/` vorhanden.
003. Route `/blog/agentic-subagents` 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-subagents` 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.
| Merksatz | Bedeutung für agentic subagents |
|---|---|
| Briefing-First | Spec vor Code, immer |
| Ralph-Loop | Konvergenz statt „fertig“-Behauptung |
| curl + PHPUnit | Beweis statt Chat-Grün |
| Keine Emojis | Professioneller Ton in Code und UI |
agentic subagents 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-subagents` 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}/`.
| Komponente | Pfad | Verantwortung |
|---|---|---|
| Markdown-Quelle | `briefing/blog/blogposts/{slug}/{slug}.md` | Inhalt, Tabellen, Bild-Referenzen |
| Screen-PHP | `htdocs/scripts/app/blog/{slug}.php` | Orchestrator-Call, Twig-Render |
| Template | `templates/app/theme1/blog/{route-thema}.html` | SEO-Blöcke, Hero, Body |
| Translations | `translation/de/blog/{date}-{thema}-de.php` | seo_title, seo_description |
| CSS | `htdocs/css/app/blog/blogpost.css` | Typografie, Tabellen, Code-Blöcke |
Ä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 subagents bedeutet das: nicht nur Inhalt erweitern, sondern sicherstellen, dass der gerenderte Screen stabil bleibt.
001. Routing: Public-Route `/blog/agentic-subagents` 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.