Build Features From Written Specs, Getting Approval Before Coding

## Keep Project-Wide Guidance Separate From Each Feature's Spec Maintain two deliberate layers of development guidance. Project steering records durable product context, technology choices, repository structure, policies, and conventions. Feature specifications define one bounded change and hold its requirements, design, tasks, research, and validation evidence. Load the relevant project steering before feature work and keep it current when stable constraints change. Never let feature-specific decisions silently rewrite project-wide guidance. Identify active specifications and expose their current phase so resumed work continues from recorded state instead of guesswork. ## Check the Scope First, Then Pick One Spec or a Roadmap Begin with a short discovery pass that clarifies the idea, affected system, dependencies, and expected outcome. For one bounded feature, open a single specification directly. For a broad initiative, create a brief and roadmap, split the work into cohesive specifications, record dependencies, and schedule implementation in dependency waves. When changing an established system, inspect the existing implementation before design and record gaps, compatibility constraints, and reusable components. Use a fast-track path only intentionally; it must still produce the essential requirements, design, task, and validation artifacts. ## Write Requirements, Design, and Tasks in Order, With Approval at Each Step Advance through specification phases in order: 1. Write testable requirements that define behavior, boundaries, constraints, and acceptance conditions. 2. Obtain human review of the requirements before treating them as the design basis. 3. Produce a design that maps each requirement to architecture, interfaces, data flow, risks, and verification. 4. Review the design, then derive ordered implementation tasks with dependencies and completion checks. 5. Obtain approval of the task plan before implementation unless an intentional fast-track has already authorized the full sequence. If scope changes materially, return to the affected phase and revalidate downstream artifacts rather than patching an obsolete plan. ## Implement Only Approved Tasks in a Chosen Mode: All or Selected Start implementation only from approved tasks and choose the execution mode explicitly. In full-scope mode, execute the approved plan autonomously, divide work by task when useful, integrate the results, obtain independent review, and run final validation. In selected-task mode, implement only the named tasks in the current context and leave unrelated tasks untouched. Use a standalone implementation review when completed work must be revalidated later. Pause only when essential information, required permission, a safety issue, or a scope-changing decision is missing; difficulty alone is not a reason to abandon the approved workflow. ## Reuse Development Skills and Get an Independent Review Keep specialized development procedures as reusable skills with one clear entry instruction and optional templates, examples, or supporting references. Skills should operate with the current task context and may delegate bounded parallel research or review only when the platform, permissions, and task scope allow it. Use adversarial review for implementation findings, root-cause-first debugging for failures, and fresh-evidence verification before completion claims. Inspect and apply a relevant skill even when there is only a small chance it governs the task; apparent simplicity is not evidence that its safeguards are unnecessary. ## Keep the Spec's Status Current and Prove Completion With Fresh Evidence Write specification artifacts in the target language configured for that specification, even if internal reasoning uses another language. Keep status available throughout the workflow, including the current phase, approved artifacts, dependencies, completed work, remaining tasks, and blocked decisions. Do not claim success from source inspection or task completion alone. Run the applicable implementation validation, inspect the resulting artifacts, and connect the completion statement to current evidence. After review or implementation changes the outcome, update the specification and status so the next session inherits the real state.