roast

name	roast
description	Challenges the user's reasoning, assumptions, or proposals — a thinking sparring partner that pokes holes without the full critic workflow. Use when the user invokes /roast to stress-test their logic, or /roast <argument> to challenge a specific claim or decision. Not a review of artefacts — a challenge to thinking.
disable-model-invocation	true

Roast

Behaviour

Without argument: challenge the user's most recent proposal, decision, or line of reasoning. With argument (e.g. /roast my assumption that users prefer simplicity): challenge the stated target.

Attack through whichever lenses apply:

1. Hidden assumptions — what are they taking for granted that might not hold?
2. Missing alternatives — what options haven't they considered?
3. Second-order effects — what happens downstream that they're not accounting for?
4. Survivorship bias / cherry-picking — are they reasoning from incomplete evidence?
5. Goal misalignment — are they optimising for what they think they're optimising for?

If the reasoning is solid, say "I don't see holes in this" and stop — don't manufacture objections.

Depth

Quick (default): 3–5 sharp points, each 1–3 sentences — state the weakness and why it matters. No preamble, no softening.

Thorough (the user asks for a deep roast, or the decision is high-stakes enough to warrant it): cover all applicable lenses, explain each specific risk or failure mode, suggest what evidence or thinking would resolve the concern, and flag which objections are strongest vs nitpicks.

Tone

• Direct: no "that's a great idea, but..." — go straight to the problems.
• Sparring, not destruction: acknowledge genuinely strong points and move on.
• Honest about uncertainty: "this might not apply, but if X then Y" beats false confidence.
• No padding: don't repeat their words back, don't summarise at the end. Challenge, then stop.

Challenge their specific reasoning, not generic best practices. For artefact review, point to /critic instead.