vs-roast-my-code
Roast My Code
Two-pass review. First pass cleans. Second pass roasts what's left.
Critical Rules
- Respect chat context — review ONLY files in scope. Never expand uninvited.
- Verify before roasting — only flag what you've confirmed. Being wrong kills comedy.
- Security first — secrets, keys, credentials = escalate at the top, before anything else.
- Punch up not down — mock patterns, not people.
- Be specific — cite
file:line, quote actual code. Generic roasts are lazy.
Tone: Senior dev who's seen too much + Gordon Ramsay energy. Not mean, not personal. "I'm roasting because I care."
Phase 0: Scope
Priority:
- Chat context (specific files under discussion)
- User-specified files/dirs
- Staged:
git diff --cached --name-only - Branch diff:
git diff main...HEAD --name-only - If none: ask
If empty: "Nothing to roast. Either your code is perfect (unlikely) or you forgot to stage."
Pass 1: Simplify (auto-fix)
Clean the code first. Run 3 agents in parallel, auto-apply fixes, no user interaction.
Get the full diff: git diff (or git diff HEAD for staged changes).
Agent 1: Code Reuse
- Search for existing utilities that could replace new code
- Flag functions duplicating existing functionality — suggest the existing one
- Flag inline logic where an existing utility applies
Agent 2: Code Quality
- Redundant state / derived values that should be computed
- Parameter sprawl instead of restructuring
- Copy-paste with variation that should be unified
- Leaky abstractions breaking encapsulation
- Stringly-typed code where constants/enums exist
- Unnecessary JSX nesting adding no layout value
- Comments explaining WHAT (delete; keep only non-obvious WHY)
- AI slop: hallucinated imports, verbose boilerplate, defensive nulls on non-null types, wrappers adding zero logic
Agent 3: Efficiency
- Redundant computations, repeated reads, duplicate API calls, N+1
- Independent operations that could run in parallel
- Blocking work on hot paths (startup, per-request, per-render)
- No-op state updates in loops/intervals — add change-detection guards
- TOCTOU existence checks — operate directly, handle error
- Unbounded data structures, missing cleanup, listener leaks
- Reading entire files when only a portion is needed
Auto-apply
Aggregate findings from all 3 agents. Fix each issue directly. Skip false positives — don't argue, just move on. Briefly summarize what was fixed.
Pass 2: Roast + Codex Review
Run on the cleaned code. Two agents in parallel: Roast (local) + Codex (cross-model).
Agent 4: Roast
Gather intel first: imports/exports, callers, tests. Then sweep all scan lenses — find what Pass 1 missed:
- Correctness — runtime breakage, logic errors, null access, off-by-one
- Security — injection, unsafe input, missing auth
- Architecture — god objects, circular deps, mixed concerns
- Error handling — swallowed exceptions, silent failures, empty catches
Rate each finding with confidence (0-100). Only report 80+.
Deliver 2-4 opening zingers based on worst patterns. Reference actual names, line counts. See comedy-techniques.md.
Agent 5: Codex Review
Cross-model second opinion from a different LLM.
In Claude Code: run the codex plugin's review command:
node "${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs" review --wait
If CLAUDE_PLUGIN_ROOT is not set or the script doesn't exist, fall back to:
codex review 2>/dev/null
If neither works, skip — log "Codex review unavailable" and continue with roast only.
In Codex: use the built-in /review slash command on the same diff scope.
Parse the JSON output (findings array with title, body, priority, code_location). Map Codex priorities to roast severity: P0/P1 = Critical, P2 = Serious, P3 = Minor.
Sin Inventory
Aggregate findings from Roast + Codex. Deduplicate — if both flag the same line, keep the more specific finding. Tag Codex-only findings so the user sees the cross-model signal.
Group by severity — invent fresh tier labels each time. Each sin: N. **[Sin Name]** — file:line + one-liner roast.
If 15+ sins, show top 10 by severity. Mention overflow count.
For tiers and categories, see sin-categories.md.
Worst offender spotlight: deep dive on the biggest sin — what it does, what it should be, blast radius.
Present fix options:
- a) Critical only
- b) Critical + serious [recommended]
- c) Everything
- d) Custom
Wait for user choice.
Fix
Process selected fixes. Show before/after for major changes. Run linter if available.
Pass 1: [N] issues auto-fixed
Pass 2: [N] sins found, [M] absolved
Files modified: N | Lines: -N / +N
Remaining: [count by tier]
Edge Cases
Good code: "I came here to roast, but... would merge without passive-aggressive comments."
Beyond saving: "This isn't technical debt, it's technical bankruptcy." Shift to triage plan.
Inherited code: "The original author is long gone. You're not on trial — the code is."
References
Workflow
Prev: /vs-autopilot (runs review internally) | /vs-tdd | /vs-qa | any implementation work
Next: /vs-ship-it (create PR — runs review automatically if skipped)
More from vltansky/vladstack
vs-fix
Autonomous bug fix pipeline. Investigates root cause, reproduces with a failing test, fixes, verifies, reviews, and hands back a clean branch. Use when the user says 'fix', 'fix this bug', 'fix this', 'something is broken', 'this doesn't work', or describes a bug to fix. Unlike /debug-mode (investigation only), /fix goes end-to-end: find it, prove it, fix it, verify it.
1vs-tdd
Test-driven development loop. Write failing test first, then implement to make it pass. Use when the user says 'tdd', 'test first', 'write the test first', 'failing test', 'red green refactor', or for any bug fix where the fix should be proven by a test. Also use when autopilot or other skills need test-first execution.
1vs-qa
Systematically QA test a web application and fix bugs found. Runs browser-based testing, iteratively fixes bugs in source code, commits each fix atomically, and re-verifies. Use when asked to 'qa', 'QA', 'test this site', 'find bugs', 'test and fix', or 'fix what's broken'. Three tiers: Quick (critical/high only), Standard (+medium, default), Exhaustive (+cosmetic). Produces before/after health scores, fix evidence, and a ship-readiness summary. For report-only mode, use /qa-only.
1vs-debug-mode
Systematic root-cause debugging with optional runtime log server for frontend/UI bugs. Hypothesis-driven investigation. Use when the user says 'debug', 'debug this', 'investigate', 'why is this broken', 'root cause', 'trace this bug', 'figure out why', 'this doesn't work', 'unexpected behavior', 'UI not updating', 'state is wrong', 'value is null/undefined', 'click doesn't work'. Also use instead of adding console.log — this skill collects logs automatically.
1vs-autopilot
Autonomous plan-to-code pipeline. If no plan is provided, auto-generates one via a plan-mode subagent. Stress-tests the plan (using grill-me), fixes issues found, creates a branch, executes step by step with guardrails, runs code review and QA, then hands back a shippable branch. Zero human interaction until the final handoff. Use when the user says 'autopilot', 'just build it', 'auto execute', 'implement this plan', 'take it from here', or wants to go from plan to working code without babysitting.
1vs-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").
1