Cursor Agent per CLI – der Agent wird zum Job
Datum: 2026-01-15
Chat ist Werkstatt – CLI ist Fabrik
In der IDE fühlt sich KI-Arbeit natürlich an: Frage stellen, Diff annehmen, weiter. Für Teams, Nachtjobs und CI reicht das nicht. Was im Chat passiert, ist schwer zu automatisieren: kein stabiler Exit-Code, kein Cron, kein Watchdog, keine reproduzierbaren Logs auf der Festplatte.
Cursor Agent per CLI (`cursor agent`) schließt diese Lücke: derselbe Agent-Kern wie im Editor, aber als Shell-Job mit klarem Anfang und Ende.
Das Problem
| IDE-Chat | Fehlende Eigenschaft |
|---|---|
| Session endet subjektiv | Kein verlässlicher Exit-Code |
| Verlauf in der UI | Kein zentrales Logfile fürs Team |
| Manuell gestartet | Kein Cron/systemd |
| Schwer skriptbar | Kein `&&` in Pipelines |
Wer nur tippt, hat einen Assistenten. Wer Jobs definiert, hat eine Fabrik.
Das Pattern
`cursor agent` läuft headless in der Shell – mit Prompt, Projektkontext und definiertem Ende. Du erhältst:
| Eigenschaft | Nutzen |
|---|---|
| Reproduzierbare Runs | Gleicher Befehl ≈ gleicher Ablauf |
| Logs auf Festplatte | Review, Audit, Debugging |
| Exit-Code | CI/CD kann rot/grün entscheiden |
| Anbindung an Cron | Nacht-Checks, Scheduled Quality |
Merksatz: Chat = explorativ. CLI = produktiv.
So sieht es bei uns aus
Unsere `start-vendor-*`-Scripts kapseln den CLI-Agent-Aufruf:
| Script | Aufgabe |
|---|---|
| `start-vendor-subagent-ralph-loop.php` | Subagent bis Konvergenz |
| `start-vendor-development-workflow.php` | Checks + Tests |
| `start-vendor-feature.php` | Feature aus `features/` |
| `start-vendor-deep-check.php` | PHP in 10er-Batches |
| `start-vendor-git-push.php` | Commit-Message + Push |
Der Entwickler startet ein Script – nicht einen 500-Zeilen-Prompt. Intern: Orchestrator → Steps → `cursor agent` mit Subagent-Prompt aus `cursor-rules/agents/`.
Architektur: Script → Orchestrator → Agent
start-vendor-*.php
↓
CLIOrchestrator (Steps 001…00N)
↓
Step-Services (Logs, Validierung, Agent-Aufruf)
↓
cursor agent (headless)
↓
Subagent + Skills + Rules
Jedes `start-vendor-*.php` hat ein Briefing unter `briefing/CLIOrchestrator/…` – Briefing-First gilt auch für CLI.
Exit-Code und Logs
001. Exit 0 – Workflow/Loop konvergent oder erfolgreich abgeschlossen.
002. Exit ≠ 0 – Fehler, Abbruch, offene Failures (je nach Script dokumentiert).
003. Logs unter `logs-start-vendor-*` – ein Ordner pro Lauf, nachvollziehbar im Team.
Ohne Exit-Code ist Automatisierung Glücksspiel. Ohne Logs ist Post-Mortem unmöglich.
Andere CLIs – gleiches Prinzip
Nicht nur Cursor: Claude Code, Aider, OpenCode und vergleichbare Tools folgen demselben Muster:
- stdin/stdout
- Exit-Code
- Logfile
- Anbindung an Shell-Pipelines
Agentic Engineering ist tool-agnostisch an der Grenze zur Shell – die Projekt-Steuerung (Rules, Skills, Subagents) bleibt im Repo.
Anti-Patterns
001. Alles im Chat – Nacht-Qualität hängt von Motivation ab.
002. CLI ohne Orchestrator – Ein Riesen-Prompt in `cursor agent` ohne Steps → nicht wartbar.
003. Keine Logs – „Hat letzte Nacht was gemacht?“ → unbekannt.
004. Exit-Code ignorieren – CI grün obwohl Agent FAILED meldete.
005. Secrets im Prompt – API-Keys in Shell-History; nutze `config.env` und Rules.
Workflow-Beispiel
# Einmaliger Subagent bis konvergent
php start-vendor-subagent-ralph-loop.php subagent-check-translations
# Kompletter Development-Workflow
php start-vendor-development-workflow.php
Lokal interaktiv starten, in Produktion per Cron mit gleichen Befehlen – dieselbe Fabrik.
Häufige Fragen
Brauche ich dafür Cursor Pro?
Details zum Lizenzmodell auf der Cursor-Website; für Automatisierung brauchst du einen Weg, `cursor agent` non-interactive zu betreiben.
Ersetzt CLI den IDE-Chat?
Nein – Exploration bleibt im Chat. Wiederholbare Qualität läuft über CLI.
Wie verbinde ich das mit Ralph-Loop?
`start-vendor-subagent-ralph-loop.php` ist genau diese Kombination: CLI + Subagent + Marker.
Verwandte Beiträge
| Beitrag | Fokus |
|---|---|
| Prompt vs. Pipeline | Steps statt Monster-Prompt |
| Ralph-Loop | Konvergenz |
| Von der IDE zum Nachtjob | Cron/systemd |
| Feature-Workflow | `features/` als Pipeline |
Takeaway
Was im Prompt passiert, ist schwer steuerbar – was in der Shell läuft, schon. Cursor Agent per CLI macht aus der KI einen Job: reproduzierbar, loggbar, CI-fähig. Wer Agentic Engineering ernst meint, verlagert Wiederholbares aus dem Chat in `start-vendor-*.php`.
Vertiefung: Cursor Agent per CLI – der Agent wird zum Job im Projektalltag
In unserem Repository ist agentic cursor agent cli kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic cursor agent cli 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 cursor agent cli 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-cursor-agent-cli` 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-01-15-agentic-cursor-agent-cli/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-01-15-agentic-cursor-agent-cli/` vorhanden.
003. Route `/blog/agentic-cursor-agent-cli` 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-cursor-agent-cli` 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 cursor agent cli |
|---|---|
| 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 cursor agent cli 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-cursor-agent-cli` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung (Teil 5): Cursor Agent per CLI – der Agent wird zum Job im Projektalltag
In unserem Repository ist agentic cursor agent cli kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic cursor agent cli 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 cursor agent cli 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-cursor-agent-cli` 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-01-15-agentic-cursor-agent-cli/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-01-15-agentic-cursor-agent-cli/` vorhanden.
003. Route `/blog/agentic-cursor-agent-cli` 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-cursor-agent-cli` 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 cursor agent cli |
|---|---|
| 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 cursor agent cli 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-cursor-agent-cli` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung: Cursor Agent per CLI – der Agent wird zum Job im Projektalltag
In unserem Repository ist agentic cursor agent cli kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic cursor agent cli 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 cursor agent cli 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-cursor-agent-cli` 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-01-15-agentic-cursor-agent-cli/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-01-15-agentic-cursor-agent-cli/` vorhanden.
003. Route `/blog/agentic-cursor-agent-cli` 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-cursor-agent-cli` 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 cursor agent cli |
|---|---|
| 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 cursor agent cli 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-cursor-agent-cli` 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.