# Tear Down

> Tear down the plan, design, or conclusion on the table instead of defending or polishing it — a blank-slate red-team pass that discards every premise surviving only because "that's what we already decided." Use when a proposal needs to be ruthlessly stress-tested for fatal flaws or gaps in the reasoning, not merely cleaned up. Not for business-strategy Why interrogation (why-man) or completeness review of an already-written Design Doc/ADR/RFC (pr-doc-review-pe).

- Skill: `maro114510/tear-down` (Agent Skill)
- Install (CLI): `npx skillmds@latest add maro114510/tear-down`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maro114510/tear-down/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: maro114510 (https://skillmd.com/u/maro114510)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/maro114510/tear-down

---


Tear down the design, plan, or conclusion just proposed instead of defending or polishing it. The only question that matters: would you arrive at this if you built it up again from scratch, using only what's actually true and actually required? Anything standing only because "that's what we already decided" gets discarded, not cleaned up.

If `$ARGUMENTS` points to a file, PR, or issue, read or `gh` it and tear that down instead of the live conversation; otherwise the target is whatever's currently on the table.

You reasoned your way to the current design, so you're anchored on it. A real blank slate can't come from inside your own context. Spawn a fresh general-purpose Agent that has never seen this conversation, hand it only the requirements and constraints, and let it derive an answer independently. Never use subagent_type: fork here — it inherits your conclusions and defeats the whole point of starting blank. Instruct it to justify every element of its answer against a requirement or constraint you gave it, and to name anything it can't justify that way as an assumption instead of building it in silently — that's how it surfaces rules the current design follows without anyone having stated them.

Before sending anything to that agent, separate fact from conclusion. A requirement only counts if you can point to where it actually came from: the user's own words, a file:line, a ticket. Anything you can't source is not ground truth, it's a premise the design is resting on — including a rationale stated in the design's own voice, like "because GDPR requires it." That phrasing explains why the design believes itself justified; it isn't evidence the claim is true. Treat unsourced items as suspect rather than handing them to the blank-slate agent as fact.

Compare what comes back against the current design. Sort every divergence into exactly one of three buckets, once: assumed but not actually required, required but dropped, or a tradeoff nobody checked. Verify each against real evidence — read the code, grep for it, pull the PR or issue — rather than taking either side's word for it or asking the user something you could have checked yourself, then decide falls or stands and move on. Once a divergence is classified, don't reopen it — re-arguing a point you already settled in this same pass is not new scrutiny, it's stalling. What holds up under that scrutiny stands; what only survived because of inertia or an unverified premise falls, even if the rest of the design still leans on it.

If something that falls looks fatal — breaks correctness, is irreversible once shipped, contradicts a constraint someone stated earlier, or rests on a legal, security, or compliance claim nobody actually checked — stop and put it to the user directly with AskUserQuestion right then, not buried in a wall of text they might skim past.

Done when nothing is left standing only because no one re-checked it: every premise of the current design either holds up on its own, or has been named as one that doesn't. Say what falls and why; leave rebuilding the design to the user.