Rules, Skills, Subagents – drei Ebenen der KI-Steuerung
Datum: 2026-05-01
Warum drei Ebenen – und nicht einfach „guter Prompt“?
Wer mit Cursor, Claude oder vergleichbaren Agenten produktiv arbeiten will, stößt schnell an eine Grenze: Ein einzelner Chat-Prompt ist flüchtig. Er wird nicht versioniert, nicht im Team geteilt, nicht in CI geprüft und verliert sich im Verlauf. Nach drei Tagen weiß niemand mehr, warum die KI plötzlich `try-catch` einbaut oder Orchestrator in den falschen Ordner legt.
Agentic Engineering löst das, indem Steuerung Infrastruktur wird – nicht Gespräch. Dafür nutzen wir drei klar getrennte Ebenen:
| Ebene | Frage | Artefakt | Wirkung |
|---|---|---|---|
| <strong>Rules</strong> | Was ist verboten / verbindlich? | `cursor-rules/rules/*.mdc` | Harte Grenzen, immer geladen |
| <strong>Skills</strong> | Wie wird etwas korrekt gemacht? | `cursor-rules/skills/*/SKILL.md` | Verfahren, Checklisten, Tiefe |
| <strong>Subagents</strong> | Wer führt es aus? | `cursor-rules/agents/*.md` | Spezialisierte Ausführung, Ralph-Loop |
Prompts bleiben für Ad-hoc-Aufgaben („erkläre diese Funktion“). Alles, was wiederkehrend, teamrelevant oder prüfbar sein soll, gehört ins Repository.
Das Problem im Alltag
Ohne diese Trennung passiert in fast jedem KI-Projekt dasselbe:
001. Inkonsistenz: Montags schreibt die KI Repositories ohne Logging, dienstags mit anderem PHPDoc-Stil.
002. Oberfläche statt Tiefe: „Prüf mal das Projekt“ liefert fünf kosmetische Fixes, übersieht aber fehlende Translation-Keys oder falsche Orchestrator-Pfade.
003. Kein maschinelles Grün: Der Chat sagt „fertig“, PHPUnit ist rot, curl liefert 500.
004. Wissensverlust: Der erfahrenere Entwickler hat Regeln nur im Kopf – neue Teammitglieder und neue Modelle starten bei null.
Ein Prompt kann eine Session retten. Rules, Skills und Subagents retten ein Projekt über Monate.
Ebene 1: Rules – die nicht verhandelbaren Grenzen
Rules sind kurze, harte Regeln. Sie werden bei relevanten Dateitypen oder global geladen und sagen der KI vor allem: Was niemals passieren darf und welche Architektur verbindlich ist.
Typische Inhalte
| Kategorie | Beispiel aus der Praxis | Warum als Rule? |
|---|---|---|
| Architektur | Briefing-First: zuerst `briefing/`, dann Code | Verhindert Halluzination von Klassennamen |
| PHP-Verbote | Kein `try-catch`, kein `die()`, keine `array`-Returns in Services | Ein Verstoß = sofort erkennbar im Review |
| UI/i18n | Translations nur über `translations.{ScreenKey}.*` | Verhindert hardcodierte Strings in Twig |
| Orchestrator | Kein `src/Orchestrator/` ohne Freigabe in `briefing.md` | Schichten bleiben sauber |
| Ralph-Loop | Pflicht-Marker am Ende jeder Subagent-Runde | Maschinenlesbares Grün/Rot |
Was Rules nicht leisten sollen
Rules sind kein Tutorial. Eine Rule mit 200 Zeilen Fließtext wird ignoriert. Regeln gehören knapp, testbar und priorisiert an den Anfang – ähnlich wie bei `.cursorrules`, nur feiner aufgeteilt nach Thema (`005-php-repositories.mdc`, `011-ui-i18n.mdc` usw.).
Faustregel: Wenn die KI denselben Fehler zum dritten Mal macht, gehört eine Rule dazu – nicht noch ein Skill-Absatz.
Ebene 2: Skills – das „Wie“ mit Tiefe
Skills beantworten: Wenn ich diese Aufgabe habe – welche Schritte, welche Reihenfolge, welche Prüfpunkte? Sie sind länger als Rules, dürfen Tabellen, Checklisten und Verweise auf Briefings enthalten.
Struktur eines Skills
Jeder Skill liegt unter `cursor-rules/skills/skill-{name}/SKILL.md` und wird über `@skill-{name}` referenziert – von Rules, Subagents oder anderen Skills.
Ein guter Skill enthält typischerweise:
001. Trigger: Wann muss dieser Skill geladen werden?
002. Verboten / Pflicht: Kurz, verweisend auf Rules wo möglich.
003. ABLauf in nummerierten Steps – oft 001, 002, 003 …
004. Checkliste zum Abhaken (für Mensch und Agent).
005. Verweise auf Briefings (`briefing/services/...`) und PHPUnit-Pfade.
Beispiele aus unserem Katalog
| Skill | Aufgabe | Typischer Aufruf |
|---|---|---|
| `skill-orchestrators` | Orchestrator-Briefing, Steps, Naming | Screen-/CLI-Orchestrator anlegen |
| `skill-translations` | Keys, Twig-Pfade, DE/EN | Nach Template-Änderung |
| `skill-subagent-build` | Ralph-Marker, Konvergenz | Subagent erstellen oder prüfen |
| `skill-php-comments` | PHPDoc auf Deutsch, jede Methode | Deep-Check, Repositories |
| `skill-change-provenance` | Änderungsprotokoll in Kommentaren | Jede Code-Änderung |
Skills skalieren Wissen: Ein neues Teammitglied muss nicht drei Stunden Architektur erklärt bekommen – der Agent lädt `@skill-screen-php-layer` und arbeitet nach derselben Checkliste wie der Rest.
Ebene 3: Subagents – spezialisierte Ausführer
Subagents sind vordefinierte Agenten-Prompts mit festem Scope. Statt „mach mal alles“ heißt es: „Du bist `subagent-check-translations` – prüfe nur Translations für alle Screens aus dem Routing.“
Warum Spezialisierung?
| Generalist-Prompt | Spezialisierter Subagent |
|---|---|
| Oberflächliche Fixes | Tiefe Prüfung einer Schicht |
| Vermischte Verantwortung | Klare Briefing-Referenz |
| Schwer wiederholbar | Ralph-Loop bis Konvergenz |
| Kein klares „grün“ | `OPEN_FAILURES=0`, `CHANGED_FILES=0` |
Beispiele aus unserem Agent-Katalog
| Subagent | Scope |
|---|---|
| `subagent-check-screens` | PHP, Twig, CSS, JS je Screen |
| `subagent-check-orchestrator` | Orchestrator, Steps, Briefing-Sync |
| `subagent-check-repos` | SQL, Indizes, PHPDoc, Live-Nutzung |
| `subagent-check-vendor-duplicates` | Keine Host-Kopien von Vendor-Code |
| `subagent-deep-check-src-php` | 10 PHP-Dateien pro Batch |
| `subagent-fix-fehler-und-test` | Reparieren bis curl/PHPUnit grün |
Jeder Subagent verweist auf Skills (`@skill-…`) und Rules. Er ist die Ausführungsebene – nicht die Spezifikation.
Wie die drei Ebenen zusammenspielen
Stell dir einen typischen Fix vor: *„Neuer CV-Screen liefert 500.“*
User-Auftrag
↓
Rule: 010-php-ui.mdc → Screen nur Orchestrator + Twig
↓
Subagent: subagent-fix-fehler-und-test
↓ lädt
Skills: @skill-screen-php-layer, @skill-translations, @skill-orchestrators
↓ prüft gegen
Rules: Briefing-First, keine try-catch, Translation-Keys
↓
Ralph-Loop: Runde 1 … n bis OPEN_FAILURES=0
↓
curl http://localhost:8071/cv → 200
Rules begrenzen den Lösungsraum. Skills beschreiben den Weg. Subagents laufen den Weg wiederholt bis objektiv grün.
So sieht es bei uns im Repository aus
Alle drei Ebenen liegen versioniert unter `cursor-rules/` (bzw. gespiegelt unter `.cursor/` je nach Setup):
cursor-rules/
├── rules/
│ ├── 001-ki-behavior.mdc
│ ├── 005-php-repositories.mdc
│ ├── 006-php-services.mdc
│ └── …
├── skills/
│ ├── skill-orchestrators/SKILL.md
│ ├── skill-translations/SKILL.md
│ ├── skill-subagent-build/SKILL.md
│ └── …
└── agents/
├── subagent-check-screens.md
├── subagent-check-orchestrator.md
└── …
Start eines Ralph-Loops (Subagent mit Konvergenz):
php start-vendor-subagent-ralph-loop.php subagent-check-vendor-duplicates
Der CLI-Orchestrator parst den Aufruf, bereitet Logs vor und startet den Cursor-Agent in Runden – bis keine offenen Failures und keine unerwarteten Änderungen mehr übrig sind.
Rules vs. Skills vs. Subagents – Entscheidungshilfe
| Situation | Ebene | Begründung |
|---|---|---|
| „Niemals `array` als Return in Services“ | <strong>Rule</strong> | Binär, immer gültig |
| „So prüfst du alle Screens im Routing“ | <strong>Skill</strong> | Viele Steps, Kontext |
| „Führe diese Prüfung jetzt aus“ | <strong>Subagent</strong> | Ausführung + Loop |
| „Erkläre mir diese Funktion“ | <strong>Prompt</strong> | Einmalig, kein Repo |
| „Nach jedem Feature: Translations prüfen“ | <strong>Skill</strong> + <strong>Subagent</strong> | Skill = Wissen, Subagent = Job |
Merksatz: Rule = Grenze. Skill = Handbuch. Subagent = Arbeiter mit festem Auftrag.
Anti-Patterns – was wir bewusst vermeiden
001. Der Monster-Prompt
„Lies das ganze Repo, fix alles, schreib Tests, update Briefings.“ – Skaliert nicht, liefert Theater-Produktivität.
Stattdessen: Subagent-Kette oder Ralph-Loop pro Schicht (`check-screens` → `check-orchestrator` → PHPUnit).
002. Rules als Romane
50 Regeln à 300 Zeilen – das Modell priorisiert willkürlich.
Stattdessen: Wenige harte Rules oben, Details in Skills mit `@skill-` Verweis.
003. Skills ohne Checkliste
Fließtext ohne 001/002/003 und ohne „VERBOTEN/PFLICHT“ – der Agent interpretiert frei.
Stattdessen: Nummerierte Steps wie in Briefings und Orchestratoren.
004. Subagents ohne Ralph-Marker
Der Agent sagt „alles ok“, aber nichts ist maschinenlesbar prüfbar.
Stattdessen: `@skill-subagent-build` und `RALPH_LOOP_OPEN_FAILURES` / `CHANGED_FILES` am Ende jeder Runde.
005. Prompts statt Repo-Steuerung
„Vergiss nicht, Briefing-First“ in jedem Chat – vergeht mit dem Kontextfenster.
Stattdessen: Rule `Briefing-First` + Subagent `subagent-briefing-first`.
Konkrete Verzahnung: Orchestrator-Beispiel
Angenommen, ein neuer Screen `cv` wird angelegt. Die Steuerung sieht so aus:
| Phase | Ebene | Was passiert |
|---|---|---|
| Planung | <strong>Rules</strong> | Briefing-First, Screen-Prefix, keine Legacy-Pfade |
| Umsetzung | <strong>Skills</strong> | `@skill-orchestrators`, `@skill-screen-php-layer`, `@skill-translations` |
| Prüfung | <strong>Subagents</strong> | `subagent-check-screens`, `subagent-check-orchestrator` |
| Abschluss | <strong>Ralph-Loop</strong> | curl alle Routes, `OPEN_FAILURES=0` |
Ohne Rules würde der Agent vielleicht `App\Orchestrator\Cv\` statt `ScreenOrchestrator` wählen. Ohne Skills würde er PHPDoc auf Englisch schreiben. Ohne Subagent würde niemand systematisch alle Blog-Routes mit curl testen.
Team-Skalierung: Warum das im Repo liegt
| Ohne Repo-Steuerung | Mit Rules/Skills/Subagents |
|---|---|
| Wissen in Köpfen | Wissen in Git |
| Jeder promptet anders | Gleiche Subagent-Aufrufe |
| Review ohne Checkliste | Skill-Checkliste = Review-Grundlage |
| Onboarding: Wochen | Onboarding: „Lies Skills X, starte Subagent Y“ |
| Modell-Wechsel = Reset | Modell-Wechsel = gleiche Rules |
Pull Requests können sogar verlangen: *„Welcher Subagent wurde bis Konvergenz gefahren?“* – die Log-Ordner unter `logs-start-vendor-subagent-ralph-loop/` liefern Nachweis.
Priorisierung: Was zuerst anlegen?
Wenn du bei null startest, empfehlen wir diese Reihenfolge:
001. 5–10 harte Rules – Sprache, Architektur-Verbote, Briefing-First, keine Secrets im Repo.
002. 3 Skills für eure häufigsten Tasks – z. B. Screen anlegen, Translations, Orchestrator.
003. 2 Subagents – einer für Prüfen (`check-screens`), einer für Reparieren (`fix-fehler-und-test`).
004. Ralph-Loop anbinden – `start-vendor-subagent-ralph-loop.php` mit `@skill-subagent-build`.
005. Erweitern – jeder wiederkehrende Fehler → Rule oder Skill-Step; jeder wiederkehrende Job → Subagent.
Nicht alles am ersten Tag. Aber jede Ebene einmal bewusst nutzen, sonst landet alles wieder im Chat.
Häufige Fragen
Reichen nicht Cursor Rules (.cursorrules)?
Für kleine Projekte oft ja. Sobald ihr thematische Trennung (PHP vs. UI vs. CLI), Skills mit Tiefe und spezialisierte Agenten braucht, skaliert die `cursor-rules/`-Struktur besser.
Skills und Rules – wo ist die Grenze?
Rule: „Du darfst X nicht.“ Skill: „So machst du Y in 12 Steps.“ Wenn es mehr als fünf Sätze und Checklisten braucht → Skill.
Muss jeder Subagent einen Ralph-Loop haben?
Für Prüf- und Fix-Agenten in Produktions-Workflows: ja. Für einmalige Exploration: optional.
Was ist mit Vendor-Code?
Rules und Subagents gelten auch für die Nutzung von Vendor-Paketen (`fabianrossbacher/base-ui-testcase`). `subagent-check-vendor-duplicates` verhindert, dass ihr Vendor-Funktionalität im Host dupliziert.
Wer pflegt das?
Wie Code: Review, Briefing-First, bei wiederkehrenden Fehlern Rule/Skill nachziehen. `@skill-change-provenance` dokumentiert Änderungen in PHPDoc.
Verwandte Beiträge in der Agentic-Serie
Wenn du die Ebenen im Zusammenspiel verstehen willst, lohnen sich diese Quickies:
| Beitrag | Fokus |
|---|---|
| Briefing-First | Spezifikation vor Code |
| Subagents statt Monster-Prompt | Spezialisierung |
| Ralph-Loop | Maschinenlesbare Konvergenz |
| Deep-Check | PHP in 10er-Batches |
| Feature-Workflow | Features aus `features/` end-to-end |
Gemeinsam ergeben sie eine Pipeline: spezifizieren (Briefing) → steuern (Rules/Skills) → ausführen (Subagents) → prüfen (Ralph-Loop).
Takeaway
Steuerung gehört ins Repository – nicht in den Chat-Verlauf.
| Ebene | Merksatz |
|---|---|
| <strong>Rules</strong> | Was niemals passieren darf |
| <strong>Skills</strong> | Wie es korrekt gemacht wird |
| <strong>Subagents</strong> | Wer es ausführt – bis objektiv grün |
Prompts sind flüchtig. Rules, Skills und Subagents sind Infrastruktur – versioniert, teamfähig und an Ralph-Loops anschlussfähig. Wer Agentic Engineering ernst meint, baut keine besseren Prompts, sondern bessere Systeme um die Prompts herum.
Vertiefung: Rules, Skills, Subagents – drei Ebenen der KI-Steuerung im Projektalltag
In unserem Repository ist agentic rules skills subagents kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic rules skills 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 rules skills 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-rules-skills-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-05-01-agentic-rules-skills-subagents/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-05-01-agentic-rules-skills-subagents/` vorhanden.
003. Route `/blog/agentic-rules-skills-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-rules-skills-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 rules skills 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 rules skills 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-rules-skills-subagents` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung (Teil 5): Rules, Skills, Subagents – drei Ebenen der KI-Steuerung im Projektalltag
In unserem Repository ist agentic rules skills subagents kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic rules skills 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 rules skills 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-rules-skills-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-05-01-agentic-rules-skills-subagents/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-05-01-agentic-rules-skills-subagents/` vorhanden.
003. Route `/blog/agentic-rules-skills-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-rules-skills-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 rules skills 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 rules skills 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-rules-skills-subagents` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.