/roast

name: roast
promoted_to: multi-persona-critique
description: "Constructive critique via 5 HackerNews personas with claim validation."
user-invocable: false
argument-hint: "<target to critique>"
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash
  - Task
  - Skill
context: fork
routing:
  triggers:
    - "roast code"
    - "devil's advocate"
    - "stress test idea"
    - "roast this"
    - "stress test this idea"
    - "poke holes in this"
  category: analysis
  pairs_with:
    - multi-persona-critique
    - systematic-code-review

Roast: Devil's Advocate Analysis

Overview

This skill produces evidence-based constructive critique through 5 specialized HackerNews commenter personas: Skeptical Senior, Well-Actually Pedant, Enthusiastic Newcomer, Contrarian Provocateur, and Pragmatic Builder. The workflow spawns these personas in parallel, validates all claims against actual files and lines, and synthesizes findings into an improvement-focused report.

**Key constraints baked into the workflow:**

• CLAUDE.md must be read and followed before analysis begins
• Read-only mode (no Write, Edit, destructive Bash) is mandatory — enforced via `read-only-ops` skill invocation
• Every claim must reference specific file:line locations and be validated against actual evidence before appearing in the final report
• All 5 personas must complete before validation begins — no partial analysis
• Final report must include both validated strengths and problems, prioritized by impact
• Unvalidated claims are dismissed; unfounded critiques are shown with evidence explaining why
• Analysis must be direct and focused — no elaborate frameworks beyond the 5-persona + validation pattern
• Sarcasm and mockery are stripped during synthesis; technical accuracy and file references are preserved

---

Reference Loading Table

| Signal | Load These Files | Why | |---|---|---| | dispatching roast personas; claim format and validation verdicts | `personas.md` | Loads detailed guidance from `personas.md`. | | writing the synthesized roast report | `report-template.md` | Loads detailed guidance from `report-template.md`. |

Instructions

Phase 1: ACTIVATE READ-ONLY MODE

**Goal**: Establish guardrails before any analysis begins.

Call the Skill tool with `read-only-ops`.

skill: read-only-ops

This ensures no modifications can occur during the analysis workflow.

**Allowed operations:**

• `Read` tool for file contents
• `Glob` tool for file patterns
• `Grep` tool for content search
• Bash: `ls`, `wc`, `du`, `git status`, `git log`, `git diff`

**Forbidden operations:**

• `Write` tool -- no file creation
• `Edit` tool -- no file modification
• Bash: `rm`, `mv`, `cp`, `mkdir`, `touch`, `git add`, `git commit`, `git push`

If read-only mode cannot be activated, stop immediately. Never proceed with unguarded analysis.

**Gate**: Read-only mode active. Proceed only when gate passes.

Phase 2: GATHER CONTEXT

**Goal**: Understand the target thoroughly before spawning critical perspectives.

**Step 1: Identify target type**

| Input | Target | Action | |-------|--------|--------| | No argument | README.md + repo structure | Read README, survey project layout | | `@file.md` | Specific file | Read that file, identify related files | | Description | Described concept | Search repo for related implementation |

**Step 2: Read key files**

Use Read tool to examine: README.md, main documentation, key implementation files relevant to the target.

**Step 3: Survey structure**

Use Glob to map the landscape:

• `**/*.md` for documentation coverage
• Source code organization and entry points
• Configuration files and dependency declarations

**Step 4: Search for patterns**

Use Grep to find: specific claims to verify, usage patterns, dependency references, related test files.

**Step 5: Ground verbal descriptions**

If user describes a concept rather than pointing to a file, search the repo for existing implementation. Critique grounded in actual code beats critique of a strawman every time. Never analyze a verbal description without confirming the code exists.

**Gate**: Target identified and sufficient context gathered. Proceed only when gate passes.

Phase 3: SPAWN ROASTER AGENTS (Parallel)

**Goal**: Launch 5 agents in parallel, each embodying a roaster persona, analyzing the target with full evidence-gathering discipline.

Launch 5 general-purpose agents in parallel via Task tool. Load the full persona specification from the corresponding agent file into each prompt.

**The 5 parallel tasks:**

1. **Skeptical Senior** (`agents/reviewer-code.md`, senior lens) Focus: Sustainability, maintenance burden, long-term viability

2. **Well-Actually Pedant** (`agents/reviewer-code.md`, pedant lens) Focus: Precision, intellectual honesty, terminological accuracy

3. **Enthusiastic Newcomer** (`agents/reviewer-perspectives.md`, newcomer lens) Focus: Onboarding experience, documentation clarity, accessibility

4. **Contrarian Provocateur** (`agents/reviewer-perspectives.md`, contrarian lens) Focus: Fundamental assumptions, alternative approaches

5. **Pragmatic Builder** (`agents/reviewer-domain.md`, pragmatic-builder lens) Focus: Production readiness, operational concerns

**Each agent must:**

• Call the Skill tool with `read-only-ops`. Do this first to enforce no-modification guardrails.
• Follow their systematic 5-step review process
• Tag ALL claims as `[CLAIM-N]` with specific `file:line` references
• Provide concrete evidence for every claim — vague critiques are worthless and must be rejected during validation
• Search for actual implementation details rather than analyzing verbal descriptions

See `references/personas.md` for full prompt template and claim format.

**CRITICAL**: Wait for all 5 agents to complete before proceeding to Phase 4. Do not begin validation on partial results. Every persona must contribute before synthesis can happen.

**Gate**: All 5 agents complete with tagged cl