spec-driven-development

Use the gated workflow: first write a spec covering objective, commands, project structure, code style, testing strategy, and boundaries. Get human approval, then generate a plan, break it into tasks with acceptance criteria, and only then implement.

A spec should cover six core areas: objective with success criteria, executable commands, project structure, code style with a real snippet, testing strategy, and boundaries split into Always do, Ask first, and Never do tiers.

Skip the full spec for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. Even simple tasks benefit from a two-line spec with acceptance criteria.

Reframe each vague requirement as concrete success criteria with measurable thresholds. For example, 'make the dashboard faster' becomes LCP under 2.5s on 4G and initial data load under 500ms, then confirm targets with the human.

Without a spec, implicit assumptions about platforms, data models, and scope go unchecked until code review or production. A short spec surfaces misunderstandings before implementation, when correcting them costs minutes instead of hours.