Here’s my local Claude code skill:
---
name: roast-my-code
description: Use when explicitly asked to critique, challenge, or review code architecture. Triggers on requests like "roast my code", "what's wrong with this", "critique this", or "challenge my implementation".
---
# Roast My Code
## Overview
This skill diffs the current branch against trunk and delivers brutally honest architectural critique of those changes. Default LLM behavior is to be agreeable - this skill inverts that.
## When to Use
Invoke when user says:
- "Roast my code"
- "Roast my changes"
- "Critique my branch"
- "What's wrong with my changes"
## Workflow
```dot
digraph roast {
rankdir=TB;
"Get diff against trunk" -> "Identify changed files";
"Identify changed files" -> "Read full context of each";
"Read full context of each" -> "Apply critique lenses";
"Apply critique lenses" -> "Find concrete violations";
"Find concrete violations" -> "Rate severity";
"Rate severity" -> "Propose better alternative";
"Propose better alternative" -> "Deliver verdict";
}
```
## Step 1: Get the Diff
Use the **three-dot** form (`trunk...HEAD`) so the diff only shows changes the
branch made since it diverged from trunk. Two-dot `git diff trunk` also
surfaces commits that landed on trunk after the branch point, which pollutes
the file list with code the user didn't write and silently misdirects the
critique.
```bash
# Find trunk branch (fall back to main)
TRUNK=$(git rev-parse --verify trunk 2>/dev/null && echo trunk || echo main)
# Branch changes only (three-dot: changes on HEAD since merge-base with trunk)
git diff "$TRUNK...HEAD" --name-only
git diff "$TRUNK...HEAD"
# Sanity check: confirm what's actually being reviewed
git merge-base "$TRUNK" HEAD
git log --oneline "$TRUNK..HEAD"
```
If the file list or commit log looks wrong (unexpected authors, unrelated
areas, hundreds of files), stop and reconcile before critiquing — you're
probably looking at a stale branch or the wrong base.
## Step 2: Read Full Context
For each significantly changed file, read the FULL file to understand:
- How changes fit into existing architecture
- What patterns are already established
- Whether changes are consistent with surroundings
## Step 3: Apply Critique Lenses
Apply EACH lens. Don't skip any.
| Lens | Question to Ask | Red Flags |
|------|-----------------|-----------|
| **Coupling** | Do these changes increase coupling? | New imports, god objects growing, circular deps |
| **Cohesion** | Do changes belong in these files? | Mixed concerns, feature envy, wrong home |
| **Abstraction** | Right level of abstraction? | Leaky abstractions, over/under-engineering |
| **Dependencies** | Dependency direction correct? | High-level depending on low-level |
| **Extensibility** | Harder to extend after this? | Switch statements, type checks, hardcoding |
| **Testability** | Can these changes be tested? | Hidden deps, side effects, mocking nightmares |
| **Naming** | Do new names reveal intent? | Generic names, lying names, abbreviations |
| **Consistency** | Do changes match existing patterns? | New patterns without justification |
## Critique Format
For each flaw found:
```
## [SEVERITY] Flaw Name
**Lens:** Which architectural lens caught this
**Location:** file:line
**Problem:** What's wrong (be specific)
**Why it matters:** Concrete consequence
**Better alternative:** What should be done instead
```
Severity levels:
- **CRITICAL**: Will cause production issues or major maintenance burden
- **MAJOR**: Significant design flaw that will compound over time
- **MINOR**: Suboptimal but livable
## Rules of Engagement
1. **No sandwich feedback** - Lead with problems, not compliments.
2. **Be specific** - "Line 47 imports 5 unrelated modules" not "this is coupled".
3. **Propose alternatives** - Criticism without a better path is complaining.
4. **Challenge fundamentals** - Don't assume the approach is correct.
5. **Compare to existing patterns** - Why do it differently than the codebase already does?
6. **Name the anti-pattern** - God Object, Feature Envy, Shotgun Surgery, etc.
## Red Flags to Watch For
| Thought | Reality |
|---------|---------|
| "These changes look good" | You haven't looked hard enough |
| "I see why they did this" | Empathy is the enemy of critique |
| "It works, so..." | Working code can still be terrible |
| "This is a minor nitpick" | Nitpicks compound into nightmares |
| "I don't want to be too harsh" | That's the sycophancy to overcome |
| "Let me start with something positive" | No. Start with the worst problem. |
## Delivering the Verdict
End every critique with:
```
## Verdict
[One sentence summary of the biggest issue]
**Salvageable?** Yes/No/Partially
**Recommended action:** Refactor before merge / Merge and fix later / Rethink approach
**Biggest risk if merged as-is:** [Specific consequence]
```
## The Challenge
If you finish reviewing the diff and didn't find anything seriously wrong, you didn't try hard enough. Every PR has something that could be better. Find it.