feat(start-work): add a spec-prerequisite check to the Approach gate

The Approach gate planned tests, migration, and commits but never asked whether the work needs a design spec it does not yet have. Added item 5: a spec is warranted for large or wide-surface work, unresolved design questions, or a new interface others build on. For a big task it is never a silent skip — the approach summary must state why no spec is needed, so the call is visible and challengeable at the gate. Small contained tasks pass without comment.

2 files changed, 9 insertions, 7 deletions

diff --git a/.claude/commands/start-work.md b/.claude/commands/start-work.md
index 0143a1f..923e981 100644
--- a/.claude/commands/start-work.md
+++ b/.claude/commands/start-work.md
@@ -189,16 +189,17 @@ Then produce an approach that covers:
 2. **Code that changes.** Files and functions, with a rough line-count estimate.
 3. **Risk.** Who and what does this affect? Local (one file) or does it ripple? Flag anything that touches shared state, public APIs, or core data flow.
 4. **Refactor prerequisites.** Does the codebase need restructuring before this fix is easy? If yes, that is a separate ticket and should be done first.
-5. **Characterization tests.** If modifying existing untested code, write characterization tests first to lock behavior before changing it (see `testing.md`).
-6. **Test strategy decomposition.** Which of these are needed, and roughly how many of each:
+5. **Spec prerequisite.** Does this work need a design spec it does not already have? A spec is warranted when the work is large, has wide surface area, carries unresolved design questions, or commits to an interface others will build on. If one is needed and absent, that is a `/brainstorm` or spec step first. Flag it rather than coding ahead. For a big task this is never a silent skip: the approach summary must state explicitly why no spec is needed (e.g. scope is contained, the design is forced by the existing structure, nothing else depends on the interface), so the call is visible and challengeable at the gate. A small, contained task can pass without comment.
+6. **Characterization tests.** If modifying existing untested code, write characterization tests first to lock behavior before changing it (see `testing.md`).
+7. **Test strategy decomposition.** Which of these are needed, and roughly how many of each:
    - Unit tests.
    - Integration tests.
    - E2E tests.
    - Pairwise or combinatorial tests, if parameter-heavy (see `/pairwise-tests`).
-7. **Migration and backwards-compat surface.** DB migration? API contract change? Frontend consumer impact? Config shape change? Flag if yes and describe the scope.
-8. **Feature flag.** Does this ship behind a flag or direct? Always worth asking once.
-9. **Commit decomposition.** One commit, or N commits? Each commit should be one logical change per `commits.md`. Default to bundling tests + the feature they cover into a single `feat(scope): X with tests` (or `fix(scope): X with tests`) commit — the test and the code under test belong together for review. Split into separate `test:` + `feat:` commits only when the test work is its own substantial review surface (characterization tests, fixture infrastructure, a new test harness) or when the failing test serves as a deliberate bug-report artifact in a `fix:` narrative. Size the Review-and-Publish ceremony ahead of time.
-10. **Branch name.** Following the project convention: `fix/<ID>-slug`, `feature/<ID>-slug`, `chore/<ID>-slug`, or `test/<ID>-slug`. Unticketed work uses a short descriptive slug.
+8. **Migration and backwards-compat surface.** DB migration? API contract change? Frontend consumer impact? Config shape change? Flag if yes and describe the scope.
+9. **Feature flag.** Does this ship behind a flag or direct? Always worth asking once.
+10. **Commit decomposition.** One commit, or N commits? Each commit should be one logical change per `commits.md`. Default to bundling tests + the feature they cover into a single `feat(scope): X with tests` (or `fix(scope): X with tests`) commit — the test and the code under test belong together for review. Split into separate `test:` + `feat:` commits only when the test work is its own substantial review surface (characterization tests, fixture infrastructure, a new test harness) or when the failing test serves as a deliberate bug-report artifact in a `fix:` narrative. Size the Review-and-Publish ceremony ahead of time.
+11. **Branch name.** Following the project convention: `fix/<ID>-slug`, `feature/<ID>-slug`, `chore/<ID>-slug`, or `test/<ID>-slug`. Unticketed work uses a short descriptive slug.
 
 ### Gate
 
diff --git a/todo.org b/todo.org
index f08fff8..3b25a31 100644
--- a/todo.org
+++ b/todo.org
@@ -56,7 +56,8 @@ CLOSED: [2026-06-02 Tue]
 :END:
 From a work handoff (2026-06-02, surfaced running /start-work on a clean low-risk refactor). The Phase 2 Justify gate has "Downsides" and "Alternatives considered" but no forced devil's-advocate verdict on "should we even do this?" Add a "top reasons not to do this" item: surface the top three objections if any exist; when none rise to a real objection, state one line instead of manufacturing three (e.g. "Nothing material argues against this; no reason to defer or drop it"). Building the case against the work before committing is cheapest exactly at this gate, which is its purpose. Edit the start-work skill's Justify-gate phase.
 
-** TODO [#C] start-work Approach gate: spec-needed check :feature:quick:solo:
+** DONE [#C] start-work Approach gate: spec-needed check :feature:quick:solo:
+CLOSED: [2026-06-02 Tue]
 :PROPERTIES:
 :LAST_REVIEWED: 2026-06-02
 :END: