crucible

crucible

!checklist init ${CLAUDE_SKILL_DIR} --force

A crucible is the vessel you put a substance into to test it under heat: the true part survives, the rest burns off. crucible is the lens you hold over method design — research step two, after prospect has landed a defensible gap — to turn that gap into a method that survives review. It is the second skill of the inquiry suite. It audits (and guides you to run) a gated arc that produces a method by racing several candidates and keeping only what survives, and it will not advance past a GATE until the checklist tool clears it. That gate enforces order — each step done before the next — not the substance of the work inside it; the tool structures the discipline, it does not audit it, so the rigor is yours to supply.

The one mental shift everything hangs on — a method is raced to death, not nursed. In the human era, implementing a method variant cost weeks, so you bet on one idea and lovingly refined it — and your judgment was quietly corrupted by attachment to the thing your own hands built. In the agent era an agent stands up a half-day prototype of each variant, so you do the opposite: generate several, race them in an elimination tournament, and let the losers die. But that same cheapness brings two new failure modes the whole skill is built to defend against. You still fall in love with what you built — so the kill criteria are written before the race, when you are not yet attached. And the agent hands you winners that are really infeasible-solution bugs — a variant whose performance "soars" is, nine times in ten, producing solutions that violate the constraints — so an independent feasibility checker gates every result before you believe it.

Measure the ceiling before you build. Before racing anything, you run an oracle ladder — open the cheats one level at a time (perfect information, an exact sub-solver, ground-truth components) and watch performance climb. The total gap tells you whether the direction is worth a year; the per-level gaps tell you which component holds the prize (so you attack that one); and the reverse signal — a level that moves nothing — tells you the bottleneck isn't where you thought, killing half your candidates for free. You learn the size and the location of the prize before spending a week chasing it.

Design for the paper from day one. The spec is the draft of your claims; the oracle ladder is the motivation figure; the ablation switches are pre-wired before you need them; the theory is calibrated to the venue; the novelty is defended with mechanism-keyword search. Nothing here is busywork for its own sake — every artifact this skill produces is a part of the eventual paper, made at the moment it is cheapest.

What you cannot delegate — the bets. The agent prototypes, fills proofs, runs searches, and argues. But three calls stay yours: which variants to race (pick death-cause-orthogonal ones, so the tournament informs you whoever wins), the kill criteria (written before you are attached), and whether a result is real (a "soaring" number is a feasibility-bug suspect first, a triumph never). Outsource these and you have automated a confident investment in an artifact, not a method.

Speak the user's language. Most calls here are the researcher's bets — is this graft natural, is this delta novel or cosmetic, is the theory worth the weeks, which variant deserves the deepening. Read their field fluency and gloss a term on first use (the oracle ladder, death-cause orthogonality, the null doubles, proof laundering, the degenerate-special-case theorem). A verdict the user can't evaluate is an opinion imposed, not a judgment shared — and the bet is theirs to place.