| name | clean-room-planning |
|---|---|
| description | Break anchoring on a proposed approach before planning. Use whenever the user proposes a solution, architecture, or plan and asks you to plan, design, or build around it - even if they don't ask for alternatives. Also use when they ask to think outside the box or for a second opinion on a direction, or when you notice every option you're generating lives inside the user's framing. |
A proposal in context anchors everything generated after it — the plan gets drafted inside the proposal instead of against the problem. This skill breaks the anchor with a clean room: alternatives generated by agents that have never seen the proposal, the way clean-room engineering rebuilds from a spec without seeing the original code.
If the user marked the approach as decided ("execute this", "the approach is settled"), stop here and execute their spec — challenging a decided approach is noise. If the mode is ambiguous and the decision is hard to reverse (architecture, schema, pricing, public API), ask: "Is this direction decided, or open to challenge?" Otherwise treat it as open and continue.
Done when: mode is known — decided (skill ends) or open.
Restate the problem the proposal solves: goal and constraints. No solution vocabulary — if a noun or verb exists only because of the user's chosen mechanism, it doesn't belong in the spec. If the spec can't be written without that vocabulary, the problem statement is missing; ask the user what the proposal is for before continuing.
Then elicit the success criteria by grilling (per the grilling skill): one question at a time, recommended answer attached, until a tiered list is settled — Must have, Should have, Good to have. Scope the grill to the criteria; the rest of the design tree comes after the verdict. When an answer arrives in solution vocabulary ("must use Redis"), push one level down — what does the mechanism buy? — and record that ("sub-millisecond reads"). A criterion that stays mechanism-shaped is a decided constraint; it belongs in the gate, not the list.
Done when: the spec and tiered criteria would make sense to someone who never saw the proposal.
Start two background subagents. Give each only the clean spec and criteria — not the proposal, not your reaction to it. A clean room is only clean while it's blind; showing the proposal "for critique" re-anchors it.
- Generative agent — returns 2–4 approaches that differ in mechanism (not parameter tweaks of one idea), each with tradeoffs against the criteria tiers.
- Research agent (per the research skill) — surveys how existing systems solve this problem against the must-haves: primary sources, findings in a cited Markdown file. It also reports considerations prior art handles that the criteria don't mention. Build its question from the spec, never as "alternatives to [the proposal]" — results framed around the proposal re-anchor it.
While they run, analyze the proposal yourself part-wise: which of its parts satisfy which criteria.
No subagent tool available? Generate approaches and survey prior art from the clean spec alone, before re-reading the proposal. Weaker — you have seen the proposal — but it keeps the plan from being drafted inside it.
Done when: at least 2 candidate approaches exist that differ from the proposal in mechanism, and the prior-art survey is in.
First, close the criteria: every consideration the research agent flagged goes to the user as a grilling question — must, should, good to have, or irrelevant. Scoring against an incomplete list wastes the verdict.
Score part-wise: for the proposal and each candidate — invented or prior art — which mechanism satisfies which criterion, tier by tier. Then issue one verdict on the proposal: keep, merge, or scrap.
- Keep must win on merits, not incumbency. On a genuine tie, present the choice — don't default to the user's side of it.
- Merge is assembly, not blending: name which part came from which approach and which criterion it wins on.
- Everything discarded — the proposal, a candidate, or a part — is named, with the reason it lost. Silent disposal is how anchoring hides.
- A "however…" paragraph followed by adopting the proposal unchanged is decoration, not a verdict.
Done when: the response states the verdict word, every discarded approach is named with its losing reason, and every merged part is attributed.
The winning approach enters the plan with kill criteria: observable conditions under which it gets abandoned mid-execution, and the checkpoint where they are evaluated. This makes scrapping later a planned branch instead of an admission of failure.
A must-have the winner doesn't yet satisfy is both a kill criterion and a work item: spawn a scoped clean room on that gap, with the winning approach stated as a constraint. After the verdict the winner is decided — patching its gap is execution, not anchoring.
Done when: the plan has a "Kill criteria" section with at least one observable condition and a named checkpoint, and every unmet must-have has a gap clean room spawned or explicitly deferred.