Claude Code Custom Slash Commands: /review, /handoff und /release als Teamstandard

Du fügst dieselbe Review-Checkliste wieder ein. Vor einem Release rekonstruierst du die Schritte aus dem Gedächtnis. Nach einer langen Claude-Code-Session fehlt trotzdem noch eine saubere Übergabe. Je intensiver ein Team mit einem Coding-Agenten arbeitet, desto stärker fallen diese kleinen Wiederholungen ins Gewicht.

Custom Slash Commands machen aus wiederkehrenden Prompts kurze, teamweit bekannte Namen. Ein Befehl wie /review, /handoff oder /release ist nicht nur eine Abkürzung. Richtig eingesetzt wird er zu einem gemeinsamen Arbeitsstandard: wie Code geprüft wird, wie Kontext übergeben wird und wann ein Release wirklich bereit ist.

Dieser Artikel folgt der aktuellen Claude Code Skills-Dokumentation und der Commands-Referenz, geprüft am 3. Juni 2026. Wichtig ist: Custom Commands wurden in Skills integriert. Bestehende Dateien unter .claude/commands/*.md funktionieren weiterhin, neue Team-Workflows lassen sich aber meist besser als .claude/skills/<name>/SKILL.md modellieren.

Kurz gesagt: Ein Command ist ein wiederverwendbarer Arbeitsablauf

In Claude Code sind Commands Nachrichten, die innerhalb einer Session mit / beginnen. Laut offizieller Referenz wird ein Command nur am Anfang der Nachricht erkannt; Text hinter dem Command-Namen wird als Argument übergeben. /release 1.8.0 kann also 1.8.0 als Zielversion verwenden, während /handoff frontend reviewer sagt, für wen die Übergabe gedacht ist.

Ein Skill ist ein wiederverwendbares Anweisungspaket für Claude. Einfach gesagt: ein kleines Playbook, das beschreibt, wann es genutzt werden soll, welche Schritte gelten, welche Eingaben wichtig sind und welches Ausgabeformat erwartet wird. Die älteren Command-Dateien in .claude/commands/ bleiben nutzbar, aber Skills bringen Frontmatter, Hilfsdateien, benannte Argumente und eine klarere Struktur für Reviews mit.

Der wichtigste praktische Stolperstein ist die Namenswahl. Aktuelle Claude-Code-Umgebungen können bereits Befehle wie /review, /code-review oder /security-review anzeigen. Tippe zuerst / und prüfe das Menü. Wenn der Name belegt ist, nimm /team-review, /review-note oder einen anderen teaminternen Namen. In diesem Artikel geht es um das Review-Muster; der konkrete Name muss zu deiner Umgebung passen.

Dateiablage: Skills bevorzugen, Commands für Kompatibilität behalten

Für Teamregeln gehören die Dateien ins Projekt, nicht nur ins Home-Verzeichnis einer Person. Projekt-Skills lassen sich committen, in Pull Requests prüfen und mit der Anwendungsversion weiterentwickeln. Persönliche Skills sind nützlich, sollten aber keine Regeln enthalten, von denen alle abhängen.

Ort	Beispiel	Geeignet für
Projekt-Skill	`.claude/skills/team-review/SKILL.md`	Gemeinsame Reviews, Releases, Recherche, Onboarding
Projekt-Command	`.claude/commands/handoff.md`	Bestehende kleine Commands oder Übergang während der Migration
Persönlicher Skill	`~/.claude/skills/my-note/SKILL.md`	Private Notizen und tägliche Einzel-Workflows
Persönlicher Command	`~/.claude/commands/my-command.md`	Temporäre persönliche Kürzel

Eine übersichtliche Repository-Struktur sieht so aus:

.claude/
├── commands/
│   └── handoff.md
└── skills/
    ├── team-review/
    │   ├── SKILL.md
    │   └── checklists/
    │       └── review.md
    └── release-prep/
        ├── SKILL.md
        └── scripts/
            └── collect-release-notes.sh

Das Modell dahinter ist einfach: Das Repository enthält die Arbeitsanweisung, das Slash-Menü macht sie sichtbar, die Person übergibt Argumente, und Claude Code kombiniert die Anweisung mit dem aktuellen Kontext.

flowchart LR
  A[".claude/skills oder .claude/commands"] --> B["Command wie /team-review"]
  B --> C["Argumente: $ARGUMENTS oder $version"]
  C --> D["Claude Code lädt die Anleitung"]
  D --> E["Review, Handoff oder Release-Vorbereitung"]
  E --> F["Ein Mensch prüft und entscheidet über Merge oder Release"]

Nach dem Anlegen oder Ändern eines Skills prüfst du, ob er im /-Menü erscheint. Wenn die laufende Session ihn nicht erkennt, nutze /reload-skills oder starte Claude Code neu. Prüfe auch die Beschreibung, denn sie ist Teil der Auffindbarkeit.

Kopierbare Startvorlage

Starte klein. Das folgende Beispiel erstellt /team-review, damit es nicht mit einem möglichen eingebauten /review kollidiert.

mkdir -p .claude/skills/team-review
cat > .claude/skills/team-review/SKILL.md <<'EOF'
---
description: Review the current change with the team's checklist before a pull request or merge.
argument-hint: [target-branch-or-path]
disable-model-invocation: true
---

You are performing a read-only team review.

Target: $ARGUMENTS

If the target is empty, ask which diff, branch, or path to review before scanning broadly.
Do not edit files.
Do not run destructive commands.

Review from these perspectives:
1. Correctness bugs and edge cases
2. Security and privacy risks
3. Test coverage and missing verification
4. Consistency with existing code patterns
5. Documentation, migration notes, and user-facing copy

Output:
- Findings first, ordered by severity
- File path and line number when available
- One short suggestion for each issue
- "No blocking findings" only if you found none
EOF

Danach rufst du den Skill mit /team-review main, /team-review src/auth oder einem anderen engen Ziel auf. disable-model-invocation: true verhindert, dass Claude diesen Skill automatisch auswählt. Für Reviews und Releases ist das sinnvoll, weil solche Abläufe bewusst von einem Menschen gestartet werden sollten.

Use Case 1: /review als Team-Checkliste

Der Nutzen eines Review-Commands liegt in der Wiederholbarkeit. Ohne gemeinsame Checkliste achtet eine Person vor allem auf Namen, eine andere auf Security, eine dritte auf Tests. Der Command sollte Schweregrade, Scope und Ausgabeformat definieren, damit Claude und Menschen mit demselben Maßstab prüfen.

Wenn deine Umgebung bereits /review kennt, verwende team-review.md oder einen team-review-Skill. Wenn nicht, kann .claude/commands/review.md weiterhin einen /review-Befehl erzeugen.

---
description: Team review checklist for the current branch or specified path.
argument-hint: [branch-or-path]
disable-model-invocation: true
---

Review target: $ARGUMENTS

Read the diff or files related to the target and report only review findings.
Do not rewrite code unless the user asks for fixes after the review.

Severity:
- P0: data loss, auth bypass, secret leak, production outage
- P1: correctness bug, missing validation, broken user flow
- P2: maintainability, unclear naming, duplicated logic
- P3: optional cleanup

Required checks:
1. Is the change scoped to the request?
2. Are tests or manual verification enough for the risk?
3. Are error paths and empty states handled?
4. Does the code follow existing local patterns?
5. Could the change break monetization links, analytics, or release notes?

Return a short summary after the findings.

Die entscheidende Zeile ist “Do not rewrite code.” Ein Review, der still Dateien ändert, ist kein Review mehr, sondern eine Implementierungsaufgabe. Erst lesen, dann Findings akzeptieren, danach optional eine separate Fix-Aufgabe starten.

Use Case 2: /handoff für den nächsten Menschen oder Agenten

Lange Sessions verlieren Wert, wenn ihr Ende unklar ist. Ein Handoff-Command macht aus dem Ende einer Aufgabe eine strukturierte Notiz für dich morgen, für ein Teammitglied oder für einen anderen Agenten.

---
description: Create a concise handoff note for the current task.
argument-hint: [next-owner-or-audience]
disable-model-invocation: true
---

Create a handoff note for: $ARGUMENTS

Include these sections:
1. Goal: what the task was trying to achieve
2. Changed files: important files and why they changed
3. Decisions: tradeoffs or assumptions made during the work
4. Verification: commands run, screenshots checked, or checks not run
5. Risks: unresolved issues, fragile areas, or things needing human review
6. Next steps: the smallest useful next action

Keep it factual. Do not hide failed attempts. If something was not verified, say so clearly.

Das hilft besonders bei monetarisierten Content-Sites und Produktionsanwendungen. Interne Links, CTAs, Tracking-Events, Screenshots und manuelle Prüfungen verschwinden leicht aus dem Kopf, wenn eine Aufgabe mehrere Dateien berührt. Der Handoff hält sie sichtbar.

Use Case 3: /release für Vorbereitung, nicht Veröffentlichung

Release-Commands sollten konservativ sein. Das Ziel ist nicht, Claude veröffentlichen zu lassen. Das Ziel ist, Kontext zu sammeln, Release Notes vorzubereiten, Blocker zu listen und die endgültige Entscheidung beim Menschen zu lassen.

Diese Vorlage nutzt benannte Argumente. Die aktuelle Dokumentation beschreibt arguments als Zuordnung von Namen zu Positionsargumenten; das erste Argument wird hier also $version.

---
description: Prepare a release checklist and changelog draft without publishing.
argument-hint: [version]
arguments: [version]
disable-model-invocation: true
---

Prepare release $version.

Allowed work:
1. Inspect the current diff, package metadata, and changelog
2. Draft a changelog section for $version
3. Suggest verification commands
4. List release blockers and rollback notes
5. Propose a commit message

Safety rules:
- Do not run git push
- Do not publish packages
- Do not deploy to production
- Do not delete files
- Ask before changing version files

Output:
- Release summary
- Checklist
- Blockers
- Commands the user should run manually

Das ist ein Release-Prep-Command, kein Release-Knopf. Wenn dein Team Publishing automatisieren will, gehört das in CI/CD mit expliziten Freigaben, Logs und Rollback-Regeln.

Argumente: Mit $ARGUMENTS anfangen

Für die meisten eigenen Commands reicht $ARGUMENTS. /handoff backend reviewer setzt backend reviewer in $ARGUMENTS. Die aktuelle Doku unterstützt außerdem $ARGUMENTS[0], $0 sowie benannte Argumente wie $issue oder $branch, wenn du sie im Frontmatter deklarierst.

---
description: Prepare an issue-specific work plan.
argument-hint: [issue] [branch]
arguments: [issue, branch]
disable-model-invocation: true
---

Issue: $issue
Branch: $branch
All arguments: $ARGUMENTS

Create a plan that:
1. Restates the issue in plain language
2. Lists files to inspect first
3. Identifies likely tests
4. Names one thing that should not be changed

Mehrteilige Argumente bleiben zusammen, wenn du sie in Anführungszeichen setzt: /plan-issue "login redirect bug" fix-login. Sei vorsichtig mit alten Beispielen, die $1 als erstes Argument zeigen. Die aktuelle Dokumentation beschreibt $0 als Kurzform für das erste Positionsargument.

Versionierung und Review-Prozess

Behandle Projekt-Skills und Commands wie Code. Sie beeinflussen, was geprüft wird, was übersehen wird und was das Team als “fertig” akzeptiert. Eine Änderung an .claude/skills/release-prep/SKILL.md sollte in einem Pull Request sichtbar sein, nicht nebenbei in einem Feature-Diff verschwinden.

Regel	Zweck
`.claude/skills/` in Git verwalten	Änderungen am Workflow bleiben nachvollziehbar
Pull Requests nur für Commands erlauben	Prozessänderungen werden nicht mit App-Code vermischt
Commands in README oder `CLAUDE.md` listen	Neue Teammitglieder finden sie schneller
Destruktive Aktionen im Prompt verbieten	Push, Publish, Deploy und Löschung vermeiden
Command-Set monatlich ausmisten	Veraltete Abläufe verwirren das Team nicht

Für den Rollout passen der Claude Code Einstieg, die CLAUDE.md Best Practices und der Claude Code Hooks Guide gut dazu.

Stolperfallen und Sicherheit

Der größte Fehler ist, einen Custom Command für ungefährlich zu halten, nur weil er kurz ist. Er bleibt ein starker Prompt. Wenn du dynamische Kontext-Injektion mit !-Backticks nutzt, führt Claude Code den Shell-Befehl aus und fügt die Ausgabe ein, bevor Claude den Skill liest. Das ist nützlich, braucht aber klare Read-only-Grenzen.

---
description: Collect read-only git context for release notes.
disable-model-invocation: true
---

Current status:
!`git status --short`

Recent commits:
!`git log --oneline -20`

Summarize the release notes from the information above.
Do not run write operations.

Beschränke solche Befehle auf sichere Inspektion wie git status und git log. Verwende kein rm, git clean, git push, npm publish, curl ... | sh oder produktionsrelevante Skripte. Sei auch bei allowed-tools vorsichtig: Zu breiter Bash-Zugriff kann Rückfragen reduzieren, obwohl das Team sie erwartet. Starte mit Read-only-Werkzeugen und erweitere nur bei echtem Bedarf.

Konkrete Fehler passieren schnell: Ein eigener /review kollidiert mit einem eingebauten Command. Ein Skill liegt nur im Home-Verzeichnis einer Person. Der Skill-Text wächst so stark, dass er jedes Mal Kontext kostet. Ein leeres Argument lässt Claude das ganze Repository scannen. Ein Release-Command enthält Publishing. All diese Fehler entstehen aus gut gemeinter Bequemlichkeit. Beginne read-only, halte Ziele klein und plane menschliche Bestätigung ein.

CTA: Aus Vorlagen wird ein Betriebsstandard

Diese Vorlagen bringen erst dann echten Wert, wenn sie zu deinem Repository passen. Einzelne Entwickler starten mit der kostenlosen Claude Code Cheatsheet und übernehmen sichere Command-Muster. Für wiederverwendbare Review-, Release- und Handoff-Vorlagen nutze die ClaudeCodeLab Produkte. Wenn dein Team Berechtigungen, CLAUDE.md, Skill-Reviews, CI-Grenzen und Onboarding zusammen gestalten muss, ist Claude Code Training und Beratung der passende nächste Schritt.

Beim Ausprobieren in Masas Workflow zeigte sich ein klares Ergebnis: Drei Commands reichten. /team-review, /handoff und /release-prep deckten den Großteil der wiederkehrenden Arbeit ab, ohne Claude Code zu einem unsicheren Deployment-Werkzeug zu machen. Der größte Gewinn entstand dadurch, /release als Sammlung von Entscheidungsgrundlagen zu verstehen, nicht als Veröffentlichungsknopf. Custom Slash Commands sind am stärksten, wenn sie ein Team gemeinsam anhalten, prüfen und sauber übergeben lassen.