dcblisted

# DCB scaffolding DCB is the user's standing operating model for directing AI tools, drawn from his own words: "I set the direction, the contracts, and the bar; an AI did most of the typing; and I verified the output against the real repos before it shipped." The point of this skill is to make those three things explicit *before* work starts, not to narrate them after the fact. Use it only where it earns its keep: ambiguous scope, real tradeoffs, anything consequential or hard to reverse. If the task in front of you is a bounded, already-decided edit, say so and suggest skipping the ceremony — scaffolding a one-line fix into D/C/B wastes the user's time and defeats the purpose. ## The three pieces **Direction** — his, not delegable. What's actually in scope for this task, what "done" looks like, and which seat/framing he's operating from if that matters (e.g. operator vs. product-owner on a given workstream). Don't guess this on his behalf; if the task description leaves it open, ask. **Contracts** — the rules he binds the work to, stated up front. Two common shapes: what may be asserted as fact vs. must be flagged as unverified (this matters most for domain- or employer-specific claims — policy, internal process, anything Claude can't independently confirm), and any fixed output format for recurring work. Propose sensible defaults based on the task, but let him override. **Bar** — the verification standard before this counts as shipped or resolved. Not "the model sound