ki-grok/15-reale-workflows-und-use-cases.md

Kapitel 15

Reale Workflows und Use-Cases

Kern in einem Satz: Hier greifen die Hebel aus Kapitel 2–14 in durchgängigen Produktions-Szenarien – von Plan bis PR, von Bugfix bis CI-Bot – zum Nachbauen, nicht zum Anstaunen.

Dieses Kapitel ist das längste im Buch und bewusst usage-lastig. Jeder Use-Case folgt demselben Raster:

1. Situation – Alltagsschmerz
2. Ziel – messbar
3. Hebel – welche Grok-Features
4. Ablauf – Prompts, Commands, Checks
5. Definition of Done
6. Fallstricke

Du brauchst nicht alle Szenarien linear. Nimm das, was diese Woche brennt.

---

15.1 Karte: welcher Use-Case wann?

#	Use-Case	Primär-Hebel
1	Feature von Plan bis PR; Übungsvariante todo-cli	Plan Mode, AGENTS.md, Verify-Skill
2	Bugfix mit Repro	Explore, enger Scope, Tests
3	Review-only (kein Edit)	read-only Tools/Sandbox
4	Refactor / Migration	Plan, Worktree, Subagents
5	Fremdes Repo onboarding	Explore, AGENTS.md bootstrap
6	CI flaky / rot	Headless, Logs, minimal fix
7	PR-Review-Bot	-p, Deny, JSON-Output
8	Parallel zwei Tracks	Worktrees, Subagents
9	Security-pass vor Release	Deny, Sandbox, checklists
10	Doku + Changelog	Skills, @-Files
11	Hotfix Produktion	Scope, kein YOLO, human gate
12	Monorepo Package-Arbeit	Nested AGENTS.md, CWD

---

15.2 Use-Case 1 – Feature von Plan bis PR

Situation: Ticket „CSV-Export für Invoices“. Mehrere sinnvolle API-Shapes.
Ziel: Ein PR mit Tests, ohne Event-Sourcing-Nebenkrieg.

Hebel: /plan → Approve → Implementierung → /verify-Skill → Commit/PR.

cd ~/projects/billing-api
grok

/plan CSV export for invoices.
Constraints: reuse existing streaming helpers in pkg/export;
no new framework; auth same as GET /invoices; tests required.
Out of scope: PDF, email delivery.

Review im Plan-Preview: Dateiliste, Verify (pytest tests/export -q), kein Redis „nice to have“. Inline-Kommentar falls nötig → a.

Implement the approved plan. Small commits mentally: handler, service, tests.
Stop after tests green. Do not push.

/verify

Draft a PR title and body from the diff. No git push unless I say so.

DoD: Plan freigegeben, Tests grün, PR-Text reviewt, menschlicher Push.
Fallen: Approve ohne Verify; Scope-Creep „gleich noch Excel“.

Buch-Variante: todo-cli (atomare Writes)

Wenn du das Standard-Übungsrepo aus Kapitel 2–4 nutzt, ist derselbe Bogen ohne Billing-API trainierbar. Pfad vom Buch-Repo-Root (PDF-only / CWD: siehe Kapitel 2.8):

cd beispiele/todo-cli
grok

/plan Atomare Writes in store.save (temp-Datei, dann replace).
Constraints: JSON-Form behalten; pytest -q grün; kein neues Framework.
Out of scope: neues CLI-Subcommand, Netzwerk.

Nach Approve: implementieren → /verify (bzw. Skill im Repo) → Diff lesen → Commit-Text skizzieren, kein Push ohne dich.
DoD: Plan freigegeben, pytest -q grün, diff reviewt. Ideal als erste End-to-End-Übung vor echten Prod-Repos.

---

15.3 Use-Case 2 – Bugfix mit Repro

Situation: test_retry_timeout flaky in CI, lokal selten.
Ziel: Root cause + minimaler Fix + stabiler Test.

Explore only first: find all call sites and timing assumptions for retryPayment.
Change nothing. Return path:line list and 2 hypotheses.

Optional: explore-Subagent (Kapitel 5).

Reproduce flaky test_retry_timeout: run it 20 times or with --count if supported.
Report failure rate and stack.
Still no product code fix.

Minimal fix for the root cause you confirmed. Only files listed. Keep public API.
Then run tests/payments until green twice.

DoD: Repro dokumentiert, Fix ≤ geplanter Blast Radius, Test grün ≥2×.
Fallen: „Rewrite retry framework“; Fix ohne Repro.

---

15.4 Use-Case 3 – Review-only Session

Situation: Fremder PR, du willst Findings, keine Edits.
Ziel: Severity-liste mit file:line.

# --tools: interne Tool-IDs (Shell oft run_terminal_cmd).
# --deny: Permission-Prefix Bash(...), siehe Kap. 10 und 13.
grok -p "Review git diff origin/main...HEAD for bugs and security issues.
Read-only. No edits, no commits, no network installs.
Output: severity-ordered findings with file:line and short fix hint." \
  --tools "read_file,grep,list_dir,run_terminal_cmd" \
  --deny 'Bash(git commit *)' \
  --deny 'Bash(git push *)' \
  --deny 'Bash(rm *)' \
  --sandbox read-only \
  --always-approve \
  --output-format json \
  --max-turns 25

Oder interaktiv mit Mode ask und explizitem „change nothing“.

DoD: JSON/Markdown Findings; Working Tree clean.
Fallen: Always-approve ohne Deny; Agent „hilft“ mit Auto-Fix.

---

15.5 Use-Case 4 – Refactor / Migration

Situation: Legacy payments/v1 → v2 Client. Hoher Blast Radius.
Ziel: Plan + isolierte Implementierung + grüne Suite.

/plan Migrate internal callers from payments/v1 to v2 client.
Keep v1 facade deprecated for one release. List all call sites.
Verification: unit + one integration test path.

Nach Approve:

Spawn general-purpose subagent with isolation=worktree to implement phase 1
(facade + 3 highest-traffic callers). Parent tree clean.
Report worktree path, diffstat, test results. No apply until I review.

DoD: Phasen im Plan; Worktree grün; Apply/PR bewusst.
Fallen: Big-bang ohne Facade; shared Tree + Parallel-Writer.

---

15.6 Use-Case 5 – Fremdes Repo onboarding

Situation: Neues Team-Repo, null Kontext.
Ziel: Mentales Modell + Minimal-AGENTS.md.

cd /path/to/new-repo && grok

Onboarding explore only. Map: stack, entrypoints, how to test/lint,
where config lives, obvious dangers (scripts, secrets paths).
Change nothing. Then draft a minimal AGENTS.md content in chat (do not write yet).

Write AGENTS.md with only: stack bullets, exact test/lint commands, 4 don'ts.
No essay.

grok inspect

DoD: Du kannst Tests starten; AGENTS.md committed oder PR.
Fallen: Agent „modernisiert“ Build-System beim Onboarding.

---

15.7 Use-Case 6 – CI rot / flaky Pipeline

Situation: main rot nach Merge. Log ist 2000 Zeilen.
Ziel: Erste Ursache + Fix-PR oder Revert-Empfehlung.

# Log extrahieren
gh run view --log-failed > /tmp/ci-fail.log   # oder Artefakt speichern

grok -p "CI failed. Log file: /tmp/ci-fail.log
Find root cause. Quote the first real error, not only the last exit code.
Propose minimal fix OR revert recommendation. Do not push." \
  --always-approve \
  --cwd "$(pwd)" \
  --deny 'Bash(git push *)' \
  --deny 'Bash(git push --force *)' \
  --max-turns 30 \
  --output-format json | jq -r '.text'

Policy dieses Jobs: Writes und Commits sind erlaubt (minimaler Fix im Tree); Push/Deploy bleiben blockiert. Für Review-only siehe UC7 / Kap. 10 (Tool-Allowlist ohne Shell-Write).

Interaktiv: @/tmp/ci-fail.log anhängen statt riesigem Paste (Kontext!).

DoD: Eine Hypothese mit Evidenz; nächster Schritt klar.
Fallen: Ganzes Log in den Prompt; YOLO ohne Deny; unbemerktes Force-Push-Pattern.

---

15.8 Use-Case 7 – PR-Review-Bot (Headless)

Situation: Jeder PR soll automatische Erst-Findings bekommen.
Ziel: Comment/Summary ohne Write auf main.

Siehe auch Kapitel 10 (GHA-Gerüst). Kernprompt:

You are a PR review bot. Diff range: origin/main...HEAD.
Focus: correctness, security, missing tests. Ignore style nits.
Output markdown for PR comment. Read-only. No git write.

Policy-Bundle:

• XAI_API_KEY Secret
• --always-approve + Deny push/rm
• --sandbox read-only wo möglich
• --max-turns
• GitHub token: pull-requests: write nur wenn Comment gewollt, sonst summary artifact

DoD: Job grün/rot nach eurer Policy; keine Secrets im Log.
Fallen: Bot mit Write-Permissions auf Default-Branch.

---

15.9 Use-Case 8 – Zwei parallele Tracks

Situation: Feature-Flag-Doku und Bugfix gleichzeitig, Deadline.
Ziel: Keine Diff-Vermischung.

Track A worktree: docs-only feature flag documentation + sample config.
Track B worktree: fix formatDate timezone + unit test.
Disjoint files. No apply until both summaries reviewed.

Oder zwei Terminals:

grok --worktree=docs-flag "…"
grok --worktree=fix-date "…"

DoD: Zwei Branches/PRs oder zwei clean applies.
Fallen: Beide Tracks an package.json.

---

15.10 Use-Case 9 – Security-Pass vor Release

Situation: Release-Kandidat, Security-Checkliste.
Ziel: Findings + bestätigte Non-Findings.

Security pass, read-only:
1) secret patterns (.env committed?, hardcoded keys)
2) authz on new endpoints
3) dependency scripts / postinstall risks
4) dangerous shell in CI configs
Do not fix yet. Severity table.

# optional hardening
grok -p "…" --sandbox strict --always-approve \
  --disallowed-tools "search_replace,web_fetch"

Danach separate Session für Fixes mit Plan Mode bei API-Änderungen.

DoD: Tabelle; Owner pro Finding; kein „sieht gut aus“ ohne Scan.
Fallen: Nur Dependency-CVE-Scan, kein Authz.

---

15.11 Use-Case 10 – Changelog und Release Notes

Situation: Tag steht bevor, Commits unruhig.
Ziel: Nutzer-verständliche Notes.

/create-skill   # optional: release-notes skill mit disable-model-invocation

Draft release notes from commits since v1.4.0.
Group: Features, Fixes, Breaking. Audience: API consumers.
No internal ticket IDs. Output markdown only. Change no code.

git log v1.4.0..HEAD --oneline

DoD: Notes reviewt; Breaking klar markiert.
Fallen: Agent erfindet Features, die nicht im Diff sind – gegen git log halten.

---

15.12 Use-Case 11 – Hotfix Produktion

Situation: Sev-2, fehlerhafte Null-Check in Parser, Fix muss raus.
Ziel: Minimaler Patch, maximale Kontrolle.

Regeln (hart):

• Kein Always-approve
• Kein MCP mit Prod-Credentials
• Ein File wenn möglich
• Mensch merged

HOTFIX only: Null check in parseInvoiceLine for empty description.
Reproduce with a unit test first (failing), then fix, then test green.
Do not refactor neighbors. Do not touch deploy scripts.
Show diff and test output. Wait for my explicit ok before any git commit.

DoD: Test + Fix; menschlicher Commit/Deploy-Runbook.
Fallen: „Solange wir schon da sind…“; YOLO in Prod-Checkout.

---

15.13 Use-Case 12 – Monorepo Package-Fokus

Situation: packages/frontend und packages/backend mit anderen Konventionen.
Ziel: Agent hält Package-Grenzen ein.

cd packages/backend && grok

You are in backend package. Respect nested AGENTS.md.
Add endpoint GET /healthz following existing handlers.
No React, no frontend package edits. Tests for backend only.

Root-AGENTS.md: Workspace-Commands. Nested: Stack-spezifisch (Kapitel 7).

DoD: Diff nur unter packages/backend.
Fallen: grok im Monorepo-Root ohne Scope → Cross-Package-Edits.

---

15.14 Meta-Workflow: Explore → Plan → Code → Verify → PR

Zusammensetzung aus den Use-Cases:

1 Explore   „Ändere nichts“ / explore-Subagent
2 Plan      /plan + Constraints + Verify
3 Approve   Preview a/s/c/q
4 Code      eng, ideal Worktree bei Risiko
5 Verify    Skill oder exakte Commands aus AGENTS.md
6 Review    frische Session oder zweiter Mensch
7 PR        Text vom Agent, Push vom Menschen (Default)

Persistenz: Entscheidungen in Ticket/PR/AGENTS.md – nicht nur im Chat (Kapitel 12).

---

15.15 Jetzt selbst machen: Ein Use-Case end-to-end

Jetzt selbst machen

1. Wähle Use-Case 1 oder 2 an einem echten Side-Projekt.
2. Schreibe den Prompt vor dem Start auf (Ziel, Nicht-Ziel, Verify).
3. Fahre den Ablauf inkl. Diff-Review.
4. Notiere: Welcher Hebel hat am meisten Rework verhindert?
5. Übernimm eine Lücke in AGENTS.md oder einen Skill.

---

15.16 Checkliste vor dem nächsten Agent-Tag

• AGENTS.md mit echten Commands
• Deny-Minimum committed
• Plan Mode bei Ambiguität
• Verify vor „fertig“
• Diff gelesen
• Session nicht als Müllhalde missbraucht
• Secrets raus aus Prompt und Memory

---

Was du jetzt kannst

• Zwölf Produktions-Szenarien auf Grok-Hebel abbilden
• Einen Feature- und einen Fix-Flow ohne Scope-Chaos fahren
• CI/Bot- und Review-only-Muster absichern
• Monorepo- und Hotfix-Disziplin anwenden

Nächste Schritte

→ Kapitel 16 – Best Practices, Tipps und Troubleshooting: Prompt-Engineering, Symptom→Fix und Team-Rituale.