Figure it out

Before delegating or using optional capabilities, read the runtime contract. It owns eligibility, model selection, limits, and fallback.

When the task matches no playbook, design one. The deliverable before any code is the workflow itself: a sequence of phases that scales rigor to the task, runs the scientific method, and leaves a decision trail a human can audit after stepping away. Bias toward more rigor. The cost of building the wrong thing dwarfs the cost of being careful.

Don't reinvent a playbook you already have. A focused single-unit task that matches Bug fix, Perf, Feature, Visual parity, Eval, or Multi-phase plan routes there. But a large or cross-cutting version of one (a migration across many call sites, an ambitious multi-part change), or work the user reviews after stepping away, belongs here even though a single-unit version would be a Feature. The rigor and the audit trail are the point.

Start

Open a todolist whose first item is to read the Principles section of the david-mode skill. Then add the phases below as todos.

Phase A: Frame

Ground first, then commit. Don't start the run until you can state:

• The definition of done as a falsifiable predicate (the prove-it-works principle skill). "Done well" has to be checkable.
• Scope, quantified: rough units and effort, plus the blockers grounding surfaced. Raise them before spending hours, not after fifty doomed commits.
• The rigor level, biased high. One-way doors and high blast radius get more; reversible low-stakes steps get less. Rigor is gates and artifacts, not "try harder".