Spec Implement

Spec Implement

Execute the approved Spec-backed Plan. Track progress when it uses tracked tasks. Report. Stop when blocked.

Announce at start: "I'm using the spec-implement skill to execute this plan."

This skill does not make design decisions or change approved content. It may persist approved content from the conversation when Plan Mode could not write the required artifact. If the plan is wrong, go back to spec-plan. If the design is wrong, go back to spec-brainstorm.

Prerequisites

Resolve required artifacts in order before starting product implementation:

1. If docs/specs/YYYY-MM-DD-<feature>/design.md is missing, write it from the approved design in the current conversation. Validate the file, report its path, and stop. Do not create plan.json or start implementation in the same invocation.
2. Otherwise, if docs/specs/YYYY-MM-DD-<feature>/plan.json is missing, write it from the approved plan in the current conversation. Validate it against the schema in spec-plan, report its path, and stop. Do not start implementation in the same invocation.
3. If the approved content needed for the next missing artifact is not available in the current conversation, stop and tell the human what content is unavailable. Do not ask the human to create the file.
4. When both artifacts exist, verify that any tracker entries selected during planning are available, along with docs/agents/issue-tracker.md when tracking is configured.
5. Verify that you are not on main/master without explicit user consent. Create a branch or use a git worktree first.

Each invocation creates at most one missing artifact. Only proceed to product implementation when both approved artifacts existed at the start of the invocation.

Step 1: Load and Review the Plan

Read plan.json critically before writing code. Look for:

• Unclear or ambiguous tasks
• Missing file paths or incomplete validation criteria
• Tasks that conflict with each other
• Dependencies that don't match what you see in the codebase
• Existing code or platform behavior that already satisfies a planned capability
• Duplicate IDs, parsers, errors, schemas, lifecycle handling, or test utilities
• Shared abstractions with fewer than two current consumers
• Tests whose only purpose is validating a new wrapper

If planned machinery fails these checks, stop before implementing it and return to spec-plan with a smaller revision for human review. Preserve the approved behavior and scope; do not force an unsupported structure through implementation.

For other concerns, raise them with the human before starting. Don't guess. Don't assume. Don't force through blockers.

If no concerns, proceed. Use existing tracker entries when present.

Step 2: Choose Execution Style

If the human has not specified an execution style, ask.

Autonomous Mode

"Implement it all. Don't stop until you're done."

• Execute all tasks in dependency order
• Track progress when the Spec-backed Plan has tracker entries
• Run type checking / linting continuously
• Only stop if blocked

Batched Mode (default)

"Do a few tasks at a time."

• Execute 3-5 tasks
• Stop and report: what was done, test output, anything unexpected
• Wait for human feedback before continuing

Subagent Mode

"Use subagents."

• Invoke code-subagents for dispatch patterns and review cycle
• Fresh subagent per task — no context pollution
• One combined plan and code-quality review per completed batch
• Independent tasks dispatch in parallel, dependent tasks run sequentially

Default to batched if the human hasn't expressed a preference.

Step 3: Execute the Plan

Preserve the approved behavior and scope. Treat the plan's proposed structure as a hypothesis that must remain supported by repository evidence.

For each task, find the next unblocked task directly from plan.json. When tracker entries exist, use docs/agents/issue-tracker.md to keep their execution state in sync; tracker state never overrides the plan's dependency graph.

When a tracker exists, mark it in progress according to docs/agents/issue-tracker.md.

For each task

Read the task's inputs and description first.

For behavior-changing code tasks, write tests that cover the validation criteria before writing implementation. For documentation, configuration, migration, or verification-only tasks, use the task's stated validation instead. Invoke an installed language-specific testing skill when needed.

1. Read task inputs and description
2. Write failing tests (cover validation criteria)
3. Run them — verify they fail for the RIGHT reason
4. Implement minimal code to make tests pass
5. Refactor if needed (tests stay green)

For behavior-changing code, do NOT write implementation before tests. Do NOT skip "verify it fails." Do NOT write more code than needed to pass the test.

Verify the task against its validation and acceptance criteria.

After each batch: Validate and commit

Run the task's focused validation and inspect the local diff for accidental or out-of-scope changes. Report deviations and unexpected findings. Use code-commit for any commit; plan approval does not bypass its approval gate. Comprehensive code-review happens in spec-finish.

On completion

When a tracker exists, mark the task complete according to docs/agents/issue-tracker.md.

Referencing existing code

When the plan or human references existing implementations ("make it look like the users table"), read the referenced code before making changes. A reference communicates all implicit requirements without spelling them out.

Step 4: Report (Batched Mode)

After each batch:

Completed: [tasks]
- [completed work]

Test output: 6 passed, 0 failed
Type check: clean

Ready for feedback.

Wait. Don't continue until the human responds.

Step 5: Handle Feedback

Expect short, terse corrections:

• "You didn't implement deduplicateByTitle."
• "This should be in the admin app. Move it."
• "wider" / "still cropped"

Don't ask for elaboration unless genuinely needed.

Steering patterns

On revert

If the human reverts git changes and re-scopes, respect the narrowed scope completely. Don't salvage the previous approach. Don't ask "are you sure?"

When to Stop and Ask

STOP immediately when:

• A test fails and you can't fix it within 2 attempts
• You hit a dependency not covered in the plan
• An instruction is unclear or ambiguous
• The plan conflicts with the actual codebase
• The design needs to change, not just the implementation
• Verification fails repeatedly

When you stop:

1. Explain the blocker clearly
2. Show what you tried
3. Ask for direction

Do not guess. Do not work around it. Stop and ask. Ask for clarification rather than guessing.

If the plan needs to change:

"This needs a plan revision. Want me to go back to spec-plan?"

If the design was wrong:

"This changes design assumptions. Want me to go back to spec-brainstorm?"

When to Revisit Earlier Steps

Return to spec-plan when:

• A material change affects approved behavior, scope, architecture, public contracts, or major dependencies
• Tasks cannot be completed without one of those material changes

Minor deviations may be recorded inline and reflected in plan.json when useful. Report them in the next progress update.

Return to spec-brainstorm when:

• The fundamental approach needs rethinking
• Implementation reveals the design is wrong

Completion

When all planned work is done, verify and present it.

Verification checklist

1. Run full test suite — all tests must pass, not just the new ones
2. Run type check / lint — clean output, no new warnings
3. Verify completion — close every tracker entry when tracking is used
4. Diff review — review the full diff against the intended base branch. Look for:
   • Files that changed but shouldn't have
   • Debug code or temporary hacks left behind
   • Inconsistencies between what was planned and what was built

Summary report

Present to the human:

## Feature Complete: {feature name}

**Plan:** Spec-backed Plan
**Tasks:** {completed} / {total}
**Tests:** {new tests added}, {total passing}
**Files:** {created}, {modified}

### What was built
- [concise list of what was implemented]

### Verification
- Test suite: ✓ all passing
- Type check: ✓ clean
- Lint: ✓ clean
- Comprehensive code review: pending spec-finish

### Ready for review

Next steps

After all planned work is complete and verified, the next step is spec-finish.

"Implementation complete. Ready to validate, review, and prepare for PR?"

Offer the human their options:

Finish — invoke spec-finish to validate, review, stack commits Keep — leave the branch for now, come back later Discard — delete the branch, start over

Don't choose for them. Present options and wait.

If validation finds bugs, loop back to implement. See atelier-orchestrator for iteration patterns.