Write validated specs before coding to align requirements

A gated four-phase workflow - Specify, Plan, Tasks, Implement, each requiring human review before advancing - built on the premise that code without a spec is guessing. Phase 1 (Specify) starts by surfacing assumptions explicitly before writing any spec content (e.g. "this is a web app, not native mobile; auth is session-cookie-based; Postgres per the existing Prisma schema") rather than silently filling ambiguous requirements, since assumptions are the most dangerous form of misunderstanding. The spec document covers six core areas: Objective (what's being built, why, who the user is, what success looks like); Commands (full executable commands with flags - build/test/lint/dev - not just tool names); Project Structure (where source, tests, and docs live); Code Style (one real code snippet beats three paragraphs of description); Testing Strategy (framework, test locations, coverage expectations, which test levels cover which concerns); and Boundaries as a three-tier system - Always do (run tests before commits, follow naming conventions, validate inputs), Ask first (schema changes, adding dependencies, CI config changes), Never do (commit secrets, edit vendor directories, remove failing tests without approval). A fixed spec template also captures success criteria and open questions needing human input. Vague requirements get reframed as concrete, testable success criteria - "make the dashboard faster" becomes specific LCP/load-time/CLS targets to confirm with the human - so implementation can loop toward a clear goal instead of guessing at what "faster" means. Phase 2 (Plan) takes the validated spec and generates a reviewable technical plan: major components and dependencies, implementation order, risks and mitigations, what can run in parallel versus must be sequential, and verification checkpoints between phases - explicitly deferring to the planning-and-task-breakdown skill as the canonical source for the dependency-graph and vertical-slicing mechanics behind these steps. Phase 3 (Tasks) breaks the plan into discrete units, each completable in one focused session, each with explicit acceptance criteria and a verification step, ordered by dependency rather than perceived importance, and none touching more than roughly 5 files - again deferring to planning-and-task-breakdown as canonical for sizing and ordering, with a lightweight inline task template (description, acceptance, verify, files touched). Phase 4 (Implement) executes tasks one at a time via the incremental-implementation and test-driven-development skills, using context-engineering to load only the relevant spec sections and source files at each step rather than flooding the agent with the entire spec. The spec stays a living document rather than a one-time artifact: updated first when a decision or scope changes (spec before implementation, not after), committed to version control alongside the code, and referenced by section in PRs that implement it.

Use it when starting a new project or feature, requirements are ambiguous or incomplete, the change touches multiple files or modules, an architectural decision is coming up, or the task would take more than 30 minutes to implement. Do NOT use it for single-line fixes, typo corrections, or changes with unambiguous, self-contained requirements - simple tasks still need acceptance criteria, but not a long spec.

Input is a vague or high-level feature request. Output is a human-reviewed spec document (six core areas plus success criteria), a reviewable technical plan, a dependency-ordered task list with acceptance criteria, and finally the implementation itself, executed task by task.

Defers to planning-and-task-breakdown as the canonical source for plan and task mechanics, and to incremental-implementation, test-driven-development, and context-engineering skills for the implementation phase itself.

Developers and agents starting non-trivial work who want requirements clarified and assumptions surfaced before any code is written, with a human review gate at each phase rather than discovering misunderstandings mid-implementation.