feature-speclisted

# Feature Spec — Design Before Code Rework is the most expensive bug. This skill spends 5 minutes of spec to save hours of wrong implementation. ## Workflow 1. **Restate the ask in one sentence**: who does what, and what changes for them. If you can't, list your questions NOW and stop. 2. **Locate the boundaries** (read the actual code, don't assume): - What modules/files will this touch? Name them. - Existing patterns for the same kind of feature (find a sibling feature and mirror it — consistency beats creativity inside a codebase) - What must NOT change (invariants, public contracts, performance budgets) 3. **Write the one-page spec**: - **Goal & non-goals** (explicitly listing what we are NOT doing this round) - **Interface**: function signatures / API routes+payloads / DB schema deltas / CLI flags — the contract other code depends on - **Behavior table**: input → outcome, including at least 5 edge cases (empty, huge, malformed, unauthorized, concurrent) - **Error model**: what can fail and what the user/system sees for each - **Test scenarios**: 3–8, derived from the behavior table - **Rollout**: feature flag? migration order? backfill needed? rollback path? 4. **Surface the decisions**, don't bury them: list each place you had 2+ reasonable options, your pick, and why (one line each). The user overrules cheaply at spec time, expensively after implementation. 5. **Confirm the spec with the user** when: behavior is user-visible, contracts cha