Implements approved specification proposals by working through tasks sequentially with testing and validation. Use when implementing changes, applying proposals, executing spec tasks, or building from approved plans. Triggers include "openspec implement", "implement", "apply change", "execute spec",

Specification Implementation Systematically implements approved spec proposals by executing tasks sequentially with proper testing and validation. Quick Start Implementation follows a read → execute → test → validate cycle for each task: 1. Read the full proposal and task list 2. Execute tasks one at a time, in order 3. Test each completed task 4. Mark complete only after verification Critical rule : Use TodoWrite to track progress. Never skip tasks or mark incomplete work as done. Workflow Copy this checklist and track progress: Step 1: Load and understand the proposal Before starting, read all context: Understand : Why this change is needed (from proposal.md) What the expected outcomes are Which specs will be affected What the acceptance criteria are (from scenarios) Step 2: Set up TodoWrite task tracking Load tasks from tasks.md into TodoWrite before starting work : Why this matters : TodoWrite gives the user visibility into progress and ensures nothing gets skipped. Step 3: Execute tasks sequentially Work through tasks one at a time, in order : Task execution pattern : Step 4: Test and validate each task After each task, verify it works: For code tasks : For database tasks : For API tasks : Only mark task complete after all verifications pass . Step 5: Update living specifications (if applicable) During implementation , if you discover the spec deltas need updates: 1. Document the discovery in proposal.md or a notes file 2. Do NOT modify spec deltas during implementation 3. After implementation completes , consider whether spec needs adjustment Note : Spec deltas are merged during archiving (Step 6), not during implementation. Step 6: Mark proposal as implementation complete After all tasks are complete: Tell the user : Best Practices Pattern 1: Blocked Tasks If a task cannot be completed: Pattern 2: Task Dependencies If tasks have dependencies, verify prerequisites before starting: Pattern 3: Incremental Testing Test incrementally, not at the end: Good : Bad : Pattern 4: Living Documentation Keep README, API docs, and comments up to date as you go : Advanced Topics Parallel work : If tasks are truly independent (e.g., separate modules), you can work on them in parallel, but each must be tested independently. Integration points : When task dependencies exist, use integration tests to verify the connection works. Rollback strategy : For risky changes, create rollback tasks before deploying. Common Patterns Pattern 1: Database + API + UI Typical order: 1. Database schema/migration 2. Data access layer (models) 3. Business logic layer (services) 4. API endpoints (controllers) 5. UI integration 6. End to end tests Pattern 2: Feature Flags For gradual rollouts: 1. Implement feature behind flag 2. Test with flag enabled 3. Deploy with flag disabled 4. Enable flag incrementally 5. Remove flag after full rollout Pattern 3: Breaking Changes For API breaking changes: 1. Implement new version (v2) 2. Keep old version (v1) working 3. Add deprecation warnings to v1 4. Migrate users to v2 5. Remove v1 (separate task/proposal) Anti Patterns to Avoid Don't : Skip testing individual tasks Mark tasks complete before verification Ignore failing tests ("I'll fix it later") Batch multiple tasks before testing Modify living specs during implementation Work out of order (dependencies break) Do : Test each task immediately Fix failing tests before proceeding Update TodoWrite in real time Document blockers clearly Communicate progress to user Keep commits atomic and descriptive Troubleshooting Issue: Tests failing after task completion Solution : Issue: Task is too large Solution : Issue: Dependency not met Solution : Reference Materials [TASK PATTERNS.md](reference/TASK PATTERNS.md) Common task execution patterns [TESTING STRATEGIES.md](reference/TESTING STRATEGIES.md) Testing approaches by task type Token budget : This SKILL.md is approximately 430 lines, under the 500 line recommended limit.

openspec-implementation