roast-my-code
Brutally honest code review with comedic flair. Roasts the sins, then redeems the sinner. Use when the user says "roast my code", "roast this", "tear this apart", "be brutal", "savage review", "destroy my code", "flame this", or wants entertaining but actionable code feedback. Also triggers on "what's wrong with this code" with a casual tone, "how bad is this", or "rate my code".
Best use case
roast-my-code is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Brutally honest code review with comedic flair. Roasts the sins, then redeems the sinner. Use when the user says "roast my code", "roast this", "tear this apart", "be brutal", "savage review", "destroy my code", "flame this", or wants entertaining but actionable code feedback. Also triggers on "what's wrong with this code" with a casual tone, "how bad is this", or "rate my code".
Teams using roast-my-code should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/roast-my-code/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How roast-my-code Compares
| Feature / Agent | roast-my-code | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Brutally honest code review with comedic flair. Roasts the sins, then redeems the sinner. Use when the user says "roast my code", "roast this", "tear this apart", "be brutal", "savage review", "destroy my code", "flame this", or wants entertaining but actionable code feedback. Also triggers on "what's wrong with this code" with a casual tone, "how bad is this", or "rate my code".
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Roast My Code Mock the sins, then redeem the sinner. Entertainment first, value second — but always deliver value. ## Critical Rules 1. **Respect chat context** — if chat is about specific files, roast ONLY those. Never expand scope uninvited. 2. **Fresh every time** — never reuse the same jokes, labels, or openers. Generate new material from the actual code. 3. **Roast then fix** — entertainment first, value second (but always deliver value). 4. **Punch up not down** — mock patterns, not people. Never blame, always improve. 5. **Wait before fixing** — present sins, let user pick what to redeem. 6. **Be specific** — generic roasts are lazy. Cite `file:line` and quote actual code. 7. **Verify before roasting** — only roast what you've confirmed. If unsure, investigate or skip. Nothing kills comedy faster than being wrong about the code. 8. **Security first** — hardcoded secrets, API keys, credentials = escalate immediately. Flag at the top, not buried in the sin list. **Tone:** Senior dev who's seen too much + tech Twitter snark + Gordon Ramsay energy. Not mean-spirited, not personal, not discouraging. "I'm roasting because I care. Also because this is objectively terrible." ## Step 0: Determine Scope **Priority order:** 1. **Chat context** — if chat is about specific files, roast ONLY those 2. User-specified files/dirs 3. Staged files: `git diff --cached --name-only` 4. Branch diff: `git diff main...HEAD --name-only` 5. If none: ask user what to roast **If empty:** "Nothing to roast. Either your code is perfect (unlikely) or you forgot to stage." ## Step 0.5: Gather Intel Better intel = sharper roasts. Before judging, understand the code's role. - **Imports/exports** — what depends on this? What does it depend on? - **Callers** — how many consumers? Hot path or dead corner? - **Tests** — exist? Cover the right things? Build a mental map of what the code does and who cares about it. Search for references, trace callers, read connected files. Focus roast on target files — connected files are context only. ## Step 1: The Opening Roast **Severity mode:** `--gentle` | `--medium` (default) | `--savage` — or auto-detect from sin count (0-3 gentle, 4-8 medium, 9+ savage). Read code, deliver 2-4 personalized zingers based on the worst patterns found. Reference actual function names, variable names, line counts. Pick a random roast style — see [references/comedy-techniques.md](references/comedy-techniques.md). ## Step 2: Sin Inventory Rate each finding with confidence (0-100). Only include findings rated 80+. Group by severity tier — invent fresh labels each time (never reuse "FELONIES" and "CRIMES"). If 15+ sins found, show top 10 by severity. Mention overflow count. Each sin: `N. **[Sin Name]** — file:line` + one-liner roast with specific detail. For severity tiers, sin categories, and scan lenses, see [references/sin-categories.md](references/sin-categories.md). ## Step 3: Worst Offender Spotlight Deep dive on the biggest sin: - What it does (too much) - What it should be (broken down) - **Blast radius** — how many files/callers depend on this? Hot path or forgotten corner? What breaks if unfixed? ## Step 4: Redemption Arc Present fix options: - a) Critical only - b) Critical + serious **[recommended]** - c) Everything - d) Custom selection Include effort estimates per fix. **STOP. Wait for user choice.** ## Step 5: Execute Fixes After user selects: 1. Process fixes in order 2. Show before/after for major changes 3. Run linter if available 4. Post-fix summary: ``` Sins absolved: N Files modified: N Lines deleted: N (good riddance) Lines added: N (quality > quantity) Before: [one-line vibe] After: [one-line vibe] Remaining sins: [count by tier, if any] ``` ## Edge Cases **Actually good code:** "I came here to roast, but... this is actually decent. Proper types, reasonable function sizes. Either you've been burned before or you read the manual. Minor nitpicks: [1-2 if any]. Would merge without passive-aggressive comments." **Beyond saving:** Shift from sin-by-sin fixes to a triage plan: what's salvageable, what needs rewriting, what order. "This isn't technical debt, it's technical bankruptcy." **Inherited code:** Tone shifts from "you did this" to "let's deal with this together." Focus on highest-impact fixes within realistic scope. "I see you've inherited a war crime. The original author is long gone. You're not on trial — the code is." ## References - [references/sin-categories.md](references/sin-categories.md) — severity tiers, common sins, scan lenses - [references/comedy-techniques.md](references/comedy-techniques.md) — roast styles, joke structures, fresh material
Related Skills
roast-my-agents-md
Brutally honest AGENTS.md/CLAUDE.md review backed by real A/B test evidence. Not just opinions — actual proof that your rules are dead weight. Roasts instruction files for bloat, slop, and redundancy, then proves it by running evals. Use when user says "roast my agents.md", "roast my CLAUDE.md", "prove my rules are useless", "eval roast", or wants entertaining evidence-based feedback on their AI config files. Also triggers on "audit my instructions" or "are my rules helping".
ship-it
Create a GitHub PR with conventional format and AI session context. Use when user says 'create PR', 'open PR', 'submit changes', 'send to dev', 'ship it', or is done with their task.
rfc-research
Research a technical topic and produce an RFC document backed by real code evidence from GitHub. Use when user says 'write an RFC', 'RFC research', 'create RFC for', 'technical proposal', 'design doc', 'investigate X', 'research X and write a proposal', 'architecture decision record', 'ADR', or needs a structured technical decision document with prior art analysis.
retro
Weekly engineering retrospective. Analyzes commit history, work patterns, and code quality metrics with persistent trend tracking. Team-aware: per-person contributions with praise and growth areas. Use when asked to 'weekly retro', 'what did we ship', 'engineering retrospective', 'how was this week', or 'show me the commit stats'. Proactively suggest at the end of a work week or sprint.
hetzner-codex-remote
Prepare a Hetzner Cloud VPS for secure Codex remote SSH access. Use when the user wants to create or configure a Hetzner server for Codex remote control, fix "No codex found in PATH" on a remote machine, install agent development tooling on a VPS, harden SSH access to a Hetzner server, or connect the server through Codex Settings, Connections, Add SSH.
grill-me
Structured adversarial review that pushes back on a plan, challenges the premise, compares alternatives, and stress-tests the design until the main risks are explicit. Use when the user asks to "grill me", stress-test a plan, poke holes in an approach, challenge assumptions, pressure-test a design, or validate an early-stage idea before building ("I have an idea", "is this worth building", "grill me on this idea").
fix-pr-comments
Handle feedback from PR reviewers. For each inline thread: reply on-thread and resolve after user approves. Use when developers left comments on your PR and you need to address them. Triggers on 'address comments', 'fix PR feedback', 'what did the reviewer say', 'handle review', 'resolve comments', 'comments from dev', 'dev feedback'.
design-review
Designer's eye visual audit of a live site — finds typography issues, spacing violations, AI slop patterns, hierarchy problems, interaction state gaps — then fixes them with atomic commits and before/after screenshots. Use when asked to 'audit the design', 'visual QA', 'design polish', 'does this look good', 'check the UI', or 'fix the design'. Proactively suggest when the user mentions visual inconsistencies or wants to polish a live site before shipping.
debug
Systematic root-cause debugging for any bug — backend, frontend, logic, integration. Hypothesis-driven investigation with evidence collection. Use when the user says 'debug', 'investigate', 'why is this broken', 'root cause', 'trace this bug', 'figure out why', 'this doesn't work', or 'unexpected behavior'. For frontend-specific runtime debugging with a log server, use /debug-mode instead.
debug-mode
This skill should be used when debugging frontend/UI bugs that need runtime evidence. USE THIS SKILL (instead of adding console.log) when you're about to say "add console.log and ask user to check", "open DevTools and tell me what you see", "reproduce the bug and share the output", "check the browser console". Triggers: "debug this", "fix this bug", "why isn't this working", "investigate this issue", "trace the problem", "figure out why X happens", "UI not updating", "state is wrong", "value is null/undefined", "click doesn't work", "modal not showing". Automates log collection server-side - you read logs directly, no user copy-paste needed.
chat-history
Search previous AI chat conversations from Cursor IDE and Claude Code by content, affected file, or project. Use when the user asks about previous conversations, wants to find how they solved something before, or needs to recall past AI interactions.
batch
Parallel work orchestration — decompose large changes into 5-30 worktree agents that each open a PR. Use when the user says 'batch', 'do this in parallel', 'split into PRs', 'bulk change', 'mass refactor', or wants a sweeping mechanical change across many files.