Snapshot aktualisiert: vor 11 Tagen
Globale Claude-Code-Subagents, Skills und Rules aus ~/.claude.
Use to design schema changes, plan migrations, optimize queries, and reason about the data model — Prisma/PostgreSQL today, Doctrine/MySQL likely for the coming PHP backend. Handles the DB layer so features are built on a sound model.
Beispiel: "Wie migriere ich `users.email` auf `citext` ohne Downtime?" → data-analyst plant die Migration (Doctrine/Prisma), inkl. Reihenfolge und Rollback-Pfad, schreibt aber keine Feature-Logik.
Use to write, update, or audit documentation — README, CHANGELOG, inline API docs, architecture notes — so docs stay in sync with the code after a change. Keeps the same voice and structure the project already uses.
Beispiel: Nach einem gemergten Feature: docs aktualisiert README/CHANGELOG und Docblocks, damit sie mit dem tatsächlichen Verhalten übereinstimmen — im bestehenden Ton/Struktur des Projekts.
Use to write or refactor production code once a plan exists. Implements layer by layer, matches surrounding code, keeps diffs small and focused, and runs the project's quality gates before declaring done.
Beispiel: Nimmt tester's roten Test für `POST /api/scores`, verifiziert den Fehlgrund, implementiert den Endpoint exakt gegen die Plan-Kontrakte, bis der Test grün ist, refactored danach.
Use for any non-trivial request that spans multiple layers (schema/DB + API + UI + tests + docs) or needs coordination across specialists. It decomposes the feature, decides which specialist handles each part, sequences the work, and integrates the results. Start here for multi-file features.
Beispiel: Konrad: "Baue ein Punkte-System für Waldbingo, mit DB-Schema, API und UI." → orchestrator zerlegt in Schema (data-analyst) → Tests (tester) → Implementierung (implementer) → Review (reviewer) → Docs (docs) und sequenziert die Übergaben.
Use before implementing any non-trivial feature or refactor. Produces a detailed, layer-by-layer implementation plan WITHOUT writing code — affected files, change order, risks, and a Definition of Done. The implementer executes what the planner designs.
Beispiel: Nach einer freigegebenen Spec (specs/punkte-system.md): planner liest sie und liefert Datei-für-Datei-Plan inkl. Interfaces & Contracts (z. B. `POST /api/scores` Request/Response-Shape), damit tester und implementer unabhängig voneinander daran arbeiten können.
Use to review a diff, PR, or set of changes for correctness, security, and convention adherence. Catches real defects — not style nitpicks. Read-only; it reports findings, it does not edit.
Beispiel: Vor dem Merge eines PR: reviewer liest den Diff gegen die Akzeptanzkriterien der Spec und meldet reale Defekte (z. B. fehlende Validierung, falsche Fehlerbehandlung) — schreibt selbst nichts um.
Use to audit API routes, auth flows, input handling, secrets, and data exposure for vulnerabilities. Especially before shipping backend endpoints or anything handling user data, payments, or receipts. Read-only; reports findings with severity and fix.
Beispiel: Vor dem Ausrollen eines neuen `/api/auth/login`-Endpoints: security prüft Auth-Flow, Input-Validierung, Secret-Handling und meldet Findings mit Schweregrad und Fix-Vorschlag.
Use to write tests BEFORE production code exists, from a spec's acceptance criteria and a planner's interface contracts. Confirms each test fails for the right reason (red), then hands off to the implementer to make it pass. Never writes production logic.
Beispiel: Aus dem Plan-Kontrakt `POST /api/scores → { points: number }` schreibt tester zuerst den fehlschlagenden Request-Test (Rot), ohne die Implementierung selbst zu schreiben — bestätigt, dass er aus dem richtigen Grund fehlschlägt (404, nicht Syntaxfehler).
Erstellt ein maßgeschneidertes Bewerbungsanschreiben als einseitiges DIN-A4-PDF — recherchiert Firma und Stellenanzeige, gleicht sie gegen Konrads belegte Fakten ab (Zwischenzeugnis, LinkedIn-Empfehlungen, Codebase-Analyse, eigene Projekte) und schreibt in seinem Ton. Nutzen bei "Bewerbung schreiben", "Anschreiben für <Firma>", "bewirb mich bei", "Anschreiben anpassen", "/bewerbung".
Erstellt einen Commit im Workspace-Standard — Conventional Commit (type(scope): summary) mit Goal/Why/How-Body und Co-Author-Zeile, als ein fokussierter logischer Schritt. Nutzen, wenn Konrad "commit", "commite das", "mach einen Commit" oder Ähnliches sagt.
Beispiel: Konrad: "commite das" → prüft git status/diff, teilt in logische Schritte, formatiert als `feat(scores): add points endpoint` mit Goal/Why/How-Body und Co-Author-Zeile.
Schreibt eine priorisierte Zusammenfassung von Konrads aktuellem E-Mail-Verkehr (Gmail) — Wichtiges/Handlungsbedarf, relevante Schul-Infos, Antworten auf Bewerbungen, Käufe/Signups eigener Produkte (auch nicht-live), Belege & Finanzen. Nutzen bei "E-Mail-Zusammenfassung", "fass meine Mails zusammen", "was ist in meinen Mails wichtig", "email brief", "Posteingang-Überblick" oder "/email-brief".
Beispiel: Konrad: "/email-brief" (oder "/email-brief 14d", "/email-brief bewerbungen") → liefert priorisierte Gmail-Zusammenfassung: Handlungsbedarf, Schule, Bewerbungen, Verkäufe/Signups, Belege — read-only, nichts wird gesendet oder gelöscht.
Verkettet den kompletten Feature-Ablauf — Spec, Plan, Tests (tester), Implementierung (implementer), Quality-Gates, Review, ggf. Docs — als ein wiederkehrender Fluss statt Einzelschritte manuell aufzurufen. Nutzen bei "/feature", "Feature implementieren", "neues Feature bauen", "baue X" für nicht-triviale Änderungen.
Beispiel: Konrad: "baue ein Login mit Magic-Link" → verkettet automatisch Spec → Plan → tester (Rot) → implementer (Grün) → Quality-Gates → Review → ggf. Docs, statt jeden Schritt einzeln anzustoßen.
Gerüst für ein neues App-/Projekt-Repo im Workspace-Standard — README, .gitignore, .env.example, CI, .claude/ (CLAUDE.md + Rules), Conventional-Commit-Setup. Nutzen bei "neue App", "neues Projekt anlegen", "scaffold", "neues Repo".
Beispiel: Konrad: "neues Projekt für einen Rezept-Planer" → legt `~/Softwareentwicklung/rezept-planer` an mit README, .gitignore, CLAUDE.md, CI-Workflow und GitHub-Repo — Setup wie bei bestehenden Apps.
Erstellt eine Spec (Problem/Ziel, User Stories, Akzeptanzkriterien, Out of Scope) für ein Feature, bevor geplant oder implementiert wird — der erste Schritt von Spec-Driven Development. Nutzen bei "spec", "Anforderungen aufschreiben", "spec-driven", "was soll das genau tun", "/spec".
Beispiel: Konrad: "/spec Punkte-System für Waldbingo" → fragt gezielt nach Zielgruppe/Randbedingungen, schreibt `specs/punkte-system.md` mit Akzeptanzkriterien, legt Konrad zur Freigabe vor, bevor geplant wird.
>
Legt einen git-Worktree für Parallelarbeit an (oder listet/entfernt sie), damit mehrere Aufgaben oder Agenten gleichzeitig an verschiedenen Branches laufen, ohne sich zu blockieren. Nutzen bei "worktree", "parallel arbeiten", "zweiter Branch gleichzeitig".
Beispiel: Konrad will parallel an Feature A und Bugfix B arbeiten → `worktree.sh new fix/scores-rounding` legt einen zweiten Arbeitsbaum unter `.worktrees/` an, ohne den Feature-A-Branch anzufassen.
Strukturierter Abschluss-Durchlauf für das Ende einer Arbeits-Session — Repo-Zustand prüfen und aufräumen, Doku/CLAUDE.md und Claude-Memory aktuell halten, offene Punkte sauber benennen, kompakte Zusammenfassung geben. Nutzen, wenn Konrad die Session bewusst beenden will: "wir sind durch", "das wars für heute", "Session beenden", "lass uns abschließen", "wrap up", "sind wir fertig" o. Ä. NICHT für Zwischenstände während der Arbeit — nur beim bewussten Abschluss.
Beispiel: Konrad: "das wars für heute" → prüft offene Änderungen/PRs je Repo, räumt Worktrees/Scratch-Dateien auf, zieht neue Erkenntnisse in CLAUDE.md/Memory nach und fasst zusammen, was als Nächstes ansteht.
Allgemeine, sprachübergreifende Code-Konventionen.
Git-Branch-, Commit- und PR-Konventionen für den Workspace.
Umgang mit Secrets, .env und öffentlichen Repos.
Bevor bei einem nicht-trivialen Feature geplant oder implementiert wird, wird zuerst spezifiziert was gebaut werden soll — getrennt von wie (das ist der Plan-Schritt, siehe CLAUDE.md → Plan-Mode).
Rot-Grün-Refactor ist Pflicht für neues Verhalten und Bugfixes — Tests kommen vor dem Implementierungscode, nicht danach.
Worktree-Workflow für parallele Arbeit.