Eigene Commands in Claude Code — /roast zum Nachmachen
Skills sind eigene Slash-Commands für Claude Code. Hier ist einer, der sofort nützlich ist: /roast — komplett zum Kopieren.
Claude Code hat ein Feature, das die meisten übersehen: Skills. Eigene Slash-Commands, die du selbst schreibst. Klingt technisch, ist es aber nicht. Es ist im Grunde eine Textdatei, die Claude sagt, was er tun soll — und die du dann mit einem kurzen Befehl aufrufst.
Was ist ein Skill?
Ein Skill ist eine Markdown-Datei. Du legst sie an einem bestimmten Ort ab, und Claude Code macht daraus automatisch einen Slash-Command.
$ /dein-command-nameFertig. Kein Code, kein Setup, kein Build-Step.
Die Datei enthält einfach Anweisungen — so detailliert oder so kurz wie nötig. Was Claude tun soll, in welcher Reihenfolge, wie die Ausgabe aussehen soll. Alles auf einmal, einmal geschrieben.
Zwei Orte, zwei Zwecke
Es gibt zwei Stellen, wo Skills landen können:
Projekt-Skills liegen in .claude/commands/ im Root deines Repos. Sie gelten nur für dieses Projekt. Du kannst sie ins Git einchecken — dann haben alle Mitentwickler die gleichen Commands.
Globale Skills liegen in ~/.claude/commands/ auf deinem Rechner. Die funktionieren in jedem Projekt, egal wo du bist.
Eine Frage reicht für die Entscheidung: Würde dieser Skill auch in einem Repo funktionieren, das du noch nie gesehen hast?
Ja → ~/.claude/commands/ — er braucht nur Git, nichts Projektspezifisches.
Nein → .claude/commands/ — er kennt deinen Stack, deine Dateien, deine Conventions.
Ein Projekt-Skill: /audit
Für diesen Blog gibt es einen /audit-Command. Er prüft bei jedem Aufruf dieselben Dinge: Build, TypeScript, Übersetzungen (der Blog ist zweisprachig), Bilder, Komponenten, Sicherheit — und committed am Ende, wenn nötig.
Der Skill kennt den Stack: Next.js, next-intl, pnpm. Er weiß, dass messages/de.json und messages/en.json synchron sein müssen. Er weiß, welche Image-Attribute Pflicht sind.
Dieses Wissen steckt alles in der Datei. Wenn ich /audit tippe, läuft das komplett durch — ohne dass ich irgendetwas erklären muss.
Das wäre ohne Skill nicht möglich, weil zu viel Kontext nötig ist. Und ohne Projekt-Skill würde der Command nicht ins Repo kommen, wo er für alle gilt.
Die audit.md ist hier bewusst nicht zum Kopieren — sie ist zu sehr auf diesen Stack zugeschnitten: Next.js, pnpm, next-intl, spezifische Bildpfade. Das ist genau der Punkt. Ein Projekt-Skill soll das wissen, was nur du weißt. Den globalen Skills kannst du 1:1 folgen; den Projekt-Skill schreibst du selbst.
Ein globaler Skill: /roast — der ehrlichste Code-Review, den du je bekommen wirst
Technische Schulden wirklich sehen: jemanden bitten, den Code anzuschauen — ohne Rücksicht auf Gefühle.
/roast sammelt zuerst Material: die letzten zwanzig Commit-Messages, TODOs und FIXMEs im Code, die größten Dateien, README-Qualität, CI-Pipelines und Test-Abdeckung. Dann schreibt Claude einen zusammenhängenden, präzise-sarkastischen — aber fairen — Kommentar über das, was er vorfindet.
Saubere Repos sind dabei kein Problem: Wenn es nichts offensichtliches zu kritisieren gibt, sucht der Skill nach dem einen Ding, das trotzdem nicht stimmt — oder kommentiert, was auffällig fehlt.
Hier ist die komplette Datei — ablegen unter ~/.claude/commands/roast.md:
---
description: Delivers a personalised, funny but accurate roast of your codebase — git history, code quality signals, and project structure distilled into sharp prose.
argument-hint: [de]
---
# /roast — Codebase Roast
You are a sarcastic but warm code critic. Your goal: roast this codebase so accurately and entertainingly that the developer laughs and immediately wants to open a refactor branch.
## Step 1 — Gather material
Run these commands and note what you find:
1. `git log --format="%ar: %s" --no-merges -20` — last 20 commits with relative age and message
2. `git log --since="30 days ago" --no-merges --oneline | wc -l` — commit frequency over the last 30 days
3. `git stash list --format="%gd (%cr): %gs"` — stash entries with age
4. `grep -rE "TODO|FIXME|HACK|XXX" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" --include="*.py" --include="*.go" --include="*.rb" . 2>/dev/null | grep -v "/node_modules/" | grep -v "/.next/" | grep -v "/dist/" | wc -l` — total technical debt comments
5. `grep -rlE "TODO|FIXME|HACK|XXX|console\.log|@ts-ignore|eslint-disable" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" --include="*.py" --include="*.go" --include="*.rb" . 2>/dev/null | grep -v "/node_modules/" | grep -v "/.next/" | grep -v "/dist/" | head -10` — files with technical debt markers
6. `find . \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.py" -o -name "*.go" \) -not -path "*/node_modules/*" -not -path "*/.next/*" -not -path "*/dist/*" -exec wc -l {} + 2>/dev/null | sort -rn | head -6` — largest source files
7. `cat README.md 2>/dev/null || echo "[No README found]"` — README quality
8. `ls -1 && echo "---" && ls -1 | wc -l` — root directory contents and count
9. `ls .github/workflows/ 2>/dev/null && echo "[CI found]" || echo "[No CI found]"` — CI pipelines
10. `cat package.json 2>/dev/null | grep -A5 '"scripts"' | grep -iE "test|spec|jest|vitest|playwright" || echo "[No test scripts found]"` — test setup
11. `find . \( -name "*.test.*" -o -name "*.spec.*" -o -name "__tests__" \) -not -path "*/node_modules/*" -not -path "*/.next/*" | wc -l` — test file count
## Step 2 — Calibrate the roast
Before writing, assess the overall state:
**If the repo has obvious problems** (bad commit messages, high TODO count, giant files, no README, no CI, no tests): roast those directly. Be specific.
**If the repo looks clean** (good commits, low debt, reasonable file sizes): don't manufacture problems that aren't there. Instead:
- Find the one thing that IS off — there's always something
- Note what's conspicuously absent: tests exist but no CI, CI exists but no tests, README exists but hasn't been touched in years
- Observe the gap between ambition and reality: what does the commit history suggest this project wants to be, and how close is it?
- A suspiciously clean repo is itself worth commenting on
## Step 3 — Write the roast
Deliver the roast as flowing prose — no bullet points, no headers. One to three paragraphs.
Draw from your findings specifically:
- Quote bad commit messages verbatim. `fix`, `fix2`, `wip`, `asdf` are fair game.
- If there are 50 TODOs, calculate what percentage will realistically ever be addressed. Round down aggressively.
- If a file exceeds 600 lines, name it. Ask what it is doing with its life.
- If the last commit was weeks ago, enquire about the developer's wellbeing.
- If there is no README, or it is three lines long, have an opinion about this.
- Stash entries older than a month deserve a mention.
- Root clutter: judge relative to repo type — 15 config files in a small project is a lifestyle choice.
- No CI: note it. CI exists but no tests: note the theatrical commitment to automation.
- Many test files but `console.log` and `@ts-ignore` everywhere: observe the contradiction.
Tone: sarcastic, precise, fond. The goal is "okay, that's fair" — not "this is personal".
Output language: if `$ARGUMENTS` is `de`, write in German. Otherwise match the language of the README or the most common code comments — default to English if unclear.
Length: 150–250 words. Brevity sharpens the wit.
## Step 4 — The Quick Fix
Close with a single "Quick Fix": the most embarrassing thing that could be addressed in under ten minutes. Name it exactly — file name, commit message, count, whatever is most specific. If the repo is genuinely clean, the Quick Fix should be the one thing that would make it undeniably better.Datei anlegen — in einem Terminal:
mkdir -p ~/.claude/commands
nano ~/.claude/commands/roast.mdDann in einem beliebigen Git-Repo:
/roast # Englisch (Standard)
/roast de # Deutsch
Was Skills wirklich sparen
Was Skills wirklich sparen, ist das Erklären. Ohne Skill tippt man jedes Mal etwas wie: „Schau in den Git-Log, schau auf TODOs, schreib einen sarkastischen Kommentar — aber fair." Claude fragt nach, du antwortest, er verfeinert. Drei, vier Nachrichten für etwas, das immer gleich ist.
Der Skill speichert diesen Prompt dauerhaft. Eine Zeile statt vier Nachrichten — und das Ergebnis ist konsistenter, weil die Anweisungen sich nicht von Tag zu Tag unterscheiden.
Skills anlegen — die zwei Befehle
Global:
mkdir -p ~/.claude/commands
# Skill schreiben, z.B. roast.mdProjekt:
mkdir -p .claude/commands
# Skill schreiben, z.B. audit.md
# git add .claude/commands/audit.mdDer Dateiname wird der Command-Name. roast.md → /roast. code-review.md → /code-review.
Was sich lohnt zu bauen
Ein paar Ideen, die sofort Sinn ergeben:
Global:
/roast— wie oben. Einmal ablegen, in jedem Repo nutzbar./commit— kein „fix" mehr als Commit-Message. Claude liest die Diff und schreibt Conventional Commits./explain— markierten Code erklären lassen, in Worten die man direkt ins Dokument kopieren kann.
Projekt:
/audit— Build, Tests, Typen, Konventionen in einem Aufruf. Nicht in zehn Nachrichten./review— Code Review nach den Regeln, die nur du kennst. Kein Stack-Erklären beim nächsten Mal./deploy-check— Checkliste vor Produktion, die nie vergessen wird, weil sie im Repo liegt.
Den Anfang macht /roast: Einmal ablegen, in jedem Git-Repo nutzbar. Was beim ersten Aufruf auffällt, hat man vorher einfach nicht gesehen — weil man zu nah dran war.
