AI Coding Workflow, Rules & Skills erklärt (mit Beispielen)

1. Warum AI-Coding Workflow, Rules und Skills als Schichten braucht

AI-Coding-Assistenten sind Agents mit Tool-Zugriff: Sie lesen Repos, ändern Dateien, führen Terminals aus. Ihre Schwäche ist offensichtlich—jeder neue Chat startet mit Amnesie, solange Teamnormen nicht erneut in den Prompt injiziert werden. Schlimmer: Manche packen Code-Stil, Git-Policy, Release-Checklisten und Incident-Runbooks in eine einzige User Rule. Jede Nachricht trägt dann Tausende Tokens Policy und verdrängt Diffs, Logs und Stacktraces.

Best Practice 2026: Constraints und Abläufe in drei Schichten teilen:

• Workflow: Wie Sie eine AI-Aufgabe starten—Slash-Befehle, Plan/Agent-Modus, CI-Trigger, Remote-Agent-Orchestrierung.
• Rules: Was immer gilt—Sprachstil, verbotene Verzeichnisse, Testpflicht, Security-Red-Lines.
• Skills: Was bei Bedarf läuft—Review-Checklisten, Xcode-Release, Migrations-Runbooks, meist in SKILL.md.

Das folgt derselben Logik wie unser Agent-Entwicklungsmodi-Leitfaden: Einstiegspunkte definieren Verhaltensgrenzen, nicht Modellparameter. Offener Standard für Skills: Agent Skills Specification; Cursor Rules: Dokumentation.

Schichten verbessern auch die Reviewbarkeit: Eine geänderte Rule-Zeile wirkt auf jede künftige Unterhaltung—das verdient einen sorgfältigen PR. Skill-Updates kosten Kontext nur bei Aufruf. Workflow-Änderungen betreffen Befehlsdocs oder CI-Jobs, nicht globales Verhalten.

2. Workflow, Rules und Skills einordnen

2.1 Workflow — Start und Orchestrierung

Workflow beantwortet wer den Agent wann zieht. Typisch: Cursor-Befehle wie /generate-blog, Plan/Agent-Modus, Claude Code /loop, GitHub Actions mit AI-CI-Fix, OpenClaw-Gateways zu Remote-Macs. Workflow kümmert sich um Trigger, Zustandsmaschinen, Artefaktpfade—nicht um Zeilenformatierung.

2.2 Rules — ständig aktive Constraints

Rules sind resident context: .cursor/rules/*.mdc, User Settings, AGENTS.md. Inhalt: minimaler Diff, Tabu-Verzeichnisse, Commit-Konventionen, Antwortsprache, Testpflicht. Rules: kurz, hart, ausführbar. Keine 30-Schritte-Release-Prozedur in einer Rule—that ist Skill-Arbeit.

2.3 Skills — On-Demand-Runbooks

Skills sind bei Bedarf ladende Workflow-Pakete: .claude/skills/<name>/SKILL.md oder .cursor/skills/<name>/SKILL.md. Der Agent liest zuerst description im Frontmatter. Vertiefung: Claude Code Skills: 10-Skill-Framework.

3. Kernvergleichstabelle

3.1 Rules vs Skills

4. Szenario-Matrix

5. Empfohlene Stacks

Stack A — Minimum (halber Tag)

• 3 User Rules: minimaler Diff, kein Commit ohne Aufforderung, Lint nach Edits
• .cursor/rules/blog-writing.mdc nur repo-spezifisch
• Skill commit für Conventional Commits

Stack B — Team

• testing.mdc + security.mdc (< 80 Zeilen)
• Skills code-review, security-review
• PR: /security-review vor Merge

Stack C — iOS

• xcode-release mit disable-model-invocation: true
• Kein *.xcodeproj ohne explizite Anfrage
• M4 lokal oder Hashvps Cloud Mac; GitHub Actions macOS-Trends

Stack D — Content/Docs

• /generate-blog (brief → zh → i18n)
• blog-standard-spec-v1.mdc
• Skills translate-to, seo-optimize

6. Häufige Fehler

• „Alles in User Rules“ → Prompt bläht sich auf; Runbooks in Skills.
• „Mehr Skills = besser“ → description-Konflikte; unter ~10, klare Grenzen.
• „Workflow ersetzt CI“ → Gates in GitHub Actions / Xcode Cloud.
• „Rules und Skills zusammen“ → Unterschiedliche Review-Logik.
• „xcode-release ohne Mac“ → codesign braucht macOS.
• „Plan Mode = Workflow“ → Plan ist Interaktion; Workflow ist wiederholbar und scriptbar.

7. Sieben Schritte mit Beispielen

1. Wiederholte Prompts prüfen: Dreimal dieselbe Checkliste? → Skill.
2. 3 Rules schreiben: Nur „immer wahr“-Red-Lines.
3. Skill-Verzeichnis: mkdir -p .cursor/skills/code-review oder .claude/skills/code-review.
4. SKILL.md Frontmatter: Verb + Szenario; Risiko: disable-model-invocation: true.
5. Workflow definieren: Gates in .cursor/commands/*.md.
6. Git committen: Rules und Skills mit Code.
7. Ausführungsknoten: shell/Xcode → macOS (lokal oder Cloud Mac).

# .cursor/rules/core.mdc
---
description: Core engineering constraints for this repo
globs: "**/*"
---
- Minimize diff scope; do not refactor unrelated code.
- Never commit unless the user explicitly asks.
- Run tests for touched packages before claiming done.

# .cursor/skills/code-review/SKILL.md
---
name: code-review
description: Review staged git diff for bugs, security, and test gaps. Use when user asks for review or before PR.
---
1. Run `git diff --staged` (or compare branch to main).
2. Output: Critical / Warning / Suggestion in three sections.
3. Do not auto-fix unless user asks.

# .cursor/commands/release-ios.md
## Workflow
1. User confirms brief / scope on main branch.
2. Agent runs /test-runner Skill on changed targets.
3. Manual /xcode-release only after CI green.
4. Post changelog; never skip codesign on shared runner.

8. Zusammenfassung

2026 hängt AI-Coding-Wettbewerbsfähigkeit an Workflow-Engineering, nicht an einem Modellscore. Workflow startet Aufgaben; Rules halten die Linie; Skills machen Senior-Checklisten zu versionierten Runbooks. Erst schichten—dann teureres Abo.

Modellfähigkeit ist nicht der Wendepunkt; Einstiegspunkte und Ausführungsgrenzen sind es. Cursor Rules · Claude Code Skills · Agent Skills