steelman-then-break
Skill5 starsChanged 3 months agoMITView on GitHub
Pressure-test a design proposal or technology choice in two separated passes: first the strongest possible case FOR it (steelman — argue the best version, even stronger than the author put it), then a rigorous case AGAINST it (red-team — name the anti-pattern, lead with what breaks first, cite the team''s prior scars), then finish with a calibrated verdict. Use this when the user asks to "review this proposal", "should we go with X", "steelman X", "challenge/red-team this design", or is choosing between an architecture, library, or framework. The value is the forced second pass that design discussions skip because nobody volunteers to be the contrarian. Do NOT use for: factual lookups, code review of existing code, requests for a single recommendation with no analysis wanted, or emotional venting. Critical calibration: if there is no substantive case against, say so plainly — manufactured objections destroy the skill''s signal.
In this repository8 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- adr-captureSkill
- article-translatorSkill
- learning-modeSkill
- onboard-our-stackSkill
- rubber-duckSkill
- toxic-senior-reviewerSkill
- my-skillSkill
The file
Files
steelman-then-break
Most design discussions die at "this seems good, ship it" because being the contrarian is socially expensive. This skill is a depersonalized contrarian: it makes the strongest case for the proposal, then the strongest case against, then calls it. The forced separation is the discipline — no on-the-other-hand hedging inside either pass.
Workflow
- Restate the target in one sentence so it's unambiguous what is being evaluated. If the proposal is too vague to break, ask for the one missing detail first.
- Pass 1 — Steelman. The strongest case for, including benefits the author may have missed. No "but", no caveats in this section. If the best version of the argument differs from what was written, argue the best version, not the literal one.
- Pass 2 — Break. The strongest case against. Lead with what breaks
first. Name the failure mode or anti-pattern explicitly. When the project
has a scars file (
.claude/scars.mdat the repo root — the team's catalogued past failures), cite the relevant precedent — arguing from the team's own evidence is the point. End each objection with the concrete signal that would tell you it's biting. - Verdict. Calibrated, not reflexively negative. State the single most important deciding factor, your actual call, and what new information would flip it. You must be willing to conclude "the steelman holds; proceed; here are the marginal risks to monitor."
Calibration
Reflexive contrarianism is the failure mode that kills this skill. If Pass 2 has no substantive content, write "I can't find a real case against this" rather than padding with weak objections. A skill that always finds something wrong gets ignored, and then it's worse than useless.
The scars file lives in the project repo at .claude/scars.md — NOT inside this
skill's folder, so the team can edit and version it without touching the
installed (checksummed) skill. It logs patterns that failed before, so the Break
pass argues from evidence instead of generic risk. references/scars.md in this
skill is the format template with a worked example: copy it to .claude/scars.md
when the team logs its first scar. No scars file just means the Break pass leans
on named anti-patterns instead.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

