speckit.implement: Execute Code from Tasks in Sequence

speckit implement golang code generation is where every prior stage finally pays off. specify implement is the most “magical” command in Spec Kit — but also the one you need to understand most deeply, so it doesn’t turn into “more expensive vibe coding.” This is the execution stage where all the context you’ve built up (constitution, spec, plan, tasks) is handed to Claude to generate the actual Go code.

In this article we cover how to run it correctly, how to review its output, and what to do when the output doesn’t match expectations — the three skills that separate reliable AI code generation from a slot machine.

10.1 Philosophy: Directed Execution

Before touching a single flag, internalize the core distinction: specify implement is not “AI generates the whole codebase at once.” It is directed execution — the AI is pointed at one specific task from tasks.md with complete context from constitution, spec, plan, and existing code. The contrast below shows exactly why that framing matters.

1Vibe Coding: "Claude, build me a product search feature"
2→ AI interprets freely, results unpredictable
3
4specify implement: "Claude, implement Task 2.2 from product-search tasks.md"
5→ AI knows exactly: target file, interface to follow, SQL from plan,
6  error handling from constitution, tests needed
7→ Results predictable and consistent

The takeaway: predictability comes from constraint, not from a smarter prompt. Every piece of context you supplied earlier narrows the AI’s decision space until only the intended implementation remains.

10.2 Running Modes

specify implement exposes four execution modes, each trading control for speed. The commands below map to the four situations you’ll hit in practice.

 1# Per-phase (most recommended)
 2specify implement product-search --phase=1
 3
 4# Per-task (maximum control)
 5specify implement product-search --task=2.2
 6
 7# Continue from last incomplete task
 8specify implement product-search --continue
 9
10# All phases (risky for large projects)
11specify implement product-search --all

The takeaway: default to --phase for a review checkpoint after each batch, reach for --task when debugging a single unit, and avoid --all on anything larger than a toy project because it removes every human gate.

10.3 What Happens Under the Hood

It helps to see the loop the tool runs for every task — this demystifies the “magic” and tells you where a run can fail. The eight steps below repeat for each task in the selected scope.

1Step 1: Load context (constitution + spec + clarifications + plan + tasks + existing code)
2Step 2: Build focused prompt for specific task
3Step 3: Call Claude API with full context
4Step 4: Write generated files
5Step 5: Run post_implement hook (go build ./... && go vet ./...)
6Step 6: Update tasks.md (status → done)
7Step 7: Auto-commit if enabled
8Step 8: Move to next task

The takeaway: the build/vet hook in Step 5 is the safety valve — a failing hook stops the loop before a broken task cascades into the next one.

10.4 Reviewing Implementation Output

Generated code is a starting point, not a finished product, so every task output must pass a review before you proceed. Use the four-lens checklist below as a fast, repeatable pass.

1Architecture: correct layer? interface used? no direct DB from usecase?
2Convention: fmt.Errorf wrapping? context.Context first? uuid.UUID for IDs?
3Logic: spec ACs handled? clarifications reflected? error mapping correct?
4Quality: go vet passes? go build passes? relevant tests pass?

The takeaway: review in this order — architecture first, because a wrong-layer decision is far more expensive to unwind than a naming or error-wrapping fix.

10.5 Handling Imperfect Output

Not every task lands at 100% correct on the first try, and that’s normal. You have two levers — regenerate with a sharper instruction, or fix by hand and continue — shown below.

1# Regenerate with additional instruction
2specify implement product-search --task=2.2 \
3  --add-instruction "SQL must use plainto_tsquery with 'indonesian' dictionary, NOT LIKE"
4
5# Or fix manually and continue
6vim internal/product/repository/postgres_repository.go
7# Fix, then:
8specify implement product-search --task=2.3  # continue to next task

The takeaway: prefer --add-instruction when the whole approach is wrong and a manual edit when a single line is wrong — don’t regenerate an entire task to fix one statement.

10.6 The Post-implement Hook

The go build ./... && go vet ./... hook configured in specify.config.json runs after every task, and its most valuable job is catching dependency-order mistakes. The message below is what a failure looks like.

1Spec Kit detected build failure!
2ERROR: SearchProducts references usecase.SortByRelevance which doesn't exist yet.
3Suggestion: Task 1.2 (Add Search DTOs) must run before Task 2.2.
4Action: Run 'specify implement product-search --task=1.2' first.

The takeaway: a failing hook is not a blocker to work around — it’s Spec Kit telling you a task ran out of order, and it even names the prerequisite.

10.7 Dry Run Before Long Implementations

Before you commit hours to a large feature, preview the plan with --dry-run. The command below reports what would change without writing a single file.

1specify implement product-search --all --dry-run
2
3# Shows: files to create, files to modify, estimated time
4# All phases visible without executing anything
5# Run without --dry-run to execute

The takeaway: a dry run is your cheapest sanity check — it surfaces surprising file targets or an unrealistic time estimate before any code is generated.

10.8 Auto-commit vs Manual Commit

Spec Kit can commit after each task automatically, or leave it to you. The configuration snippet below enables auto-commit.

1{ "implement": { "auto_commit": true, "commit_after_task": true } }

With auto-commit on, each task produces a message like feat(product-search): implement SearchProducts repository [task 2.2]. Manual commit, by contrast, lets you review first and write a richer message with spec references.

The takeaway: auto-commit is convenient but creates very granular history; the recommended middle ground is one commit per phase — enough granularity to trace work, few enough commits to keep the PR readable.

10.9 Quality Report After Implementation

Once a feature is implemented, --report rolls up build status, convention compliance, and spec coverage into one view. The output below is what a healthy-but-imperfect run looks like.

 1specify implement product-search --report
 2
 3# Code Quality:
 4# - go build: PASS ✓
 5# - go vet: PASS ✓
 6# - Tests: 11/12 pass (1 failing — detailed below)
 7#
 8# Constitution Compliance:
 9# - Error wrapping: 12/12 correct ✓
10# - No ORM detected ✓
11#
12# Spec Coverage:
13# - ACs covered: 8/8 ✓
14# - Error codes: 5/5 correct ✓

The takeaway: the report is your merge gate — a single failing test or an uncovered AC is a concrete, addressable gap, not a vague “looks fine.”

10.10 When to Use specify implement vs Manual Claude Code

specify implement is not the only way to write code with AI, and knowing when to reach for a manual Claude Code session keeps you productive.

Use specify implement:

• Well-defined tasks in tasks.md
• Straightforward implementation from plan
• Batch implementation (multiple tasks)

Use a manual Claude Code session:

• Complex tasks needing back-and-forth iteration
• Architectural exploration not yet planned
• Rapid debugging iteration

The optimal mix in practice is roughly specify implement for 80% of tasks and a manual session for the 20% that are genuinely exploratory.

10.11 Rate Limiting Handling

Large features with many tasks can hit API rate limits, so tune retries and pick cheaper models for simple work. The config controls retry behavior.

1// specify.config.json
2{
3  "ai": {
4    "max_retries": 5,
5    "retry_delay_seconds": 30
6  }
7}

You can also assign a lighter model to trivial tasks and reserve the stronger model for complex logic, as shown below.

1specify implement product-search --phase=1 --model=claude-haiku-4-5-20251001  # simple DTOs
2specify implement product-search --phase=2 --model=claude-sonnet-4-20250514   # complex SQL

The takeaway: match model to task difficulty — cheap models for boilerplate reduce both cost and rate-limit pressure without hurting quality where it matters.

10.12 The Generated Code Contract

The code specify implement produces isn’t anonymous — it carries explicit spec references in its comments. The Go signature below shows the traceability convention.

1// SearchProducts retrieves products matching the search query with pagination.
2// Implements: product-search spec.md v1.3 AC1-AC8
3// Note: stock=0 products included per clarification Q1 (shows is_available=false)
4func (r *postgresProductRepository) SearchProducts(
5	ctx context.Context,
6	filter usecase.SearchQuery,
7) ([]usecase.ProductSearchItem, int, error) {
8	// ... implementation
9}

The takeaway: these comments create a traceable link from every function back to the spec that defines its behavior, which is what makes future maintenance and drift detection straightforward.

10.13 Custom Context Injection

Sometimes a task needs runtime knowledge that lives in no spec file — an environment quirk, a missing dependency. The --context flag injects it into the prompt.

1# Add runtime context not in any spec file
2specify implement product-search --task=2.2 \
3  --context="Our PostgreSQL doesn't have 'indonesian' dictionary. Use 'simple' as fallback."

The takeaway: use --context for one-off, environment-specific facts; if the fact is permanent, put it in the constitution or plan instead so it survives beyond a single run.

10.14 Scope Limiting for Large Codebases

On a big codebase, scanning all of internal/ can blow past the context window. The --scope flag focuses the scan on the directory that actually matters.

1# Limit codebase scan to relevant directories
2specify implement product-search --phase=2 --scope=internal/product/
3
4# Reduces context size, focuses AI on relevant patterns

The takeaway: narrowing scope not only fits the context budget but also improves output quality, because the AI copies patterns from the relevant package rather than an unrelated one.

10.15 In CI Pipeline

Implementation completeness can be enforced in CI, so a PR can’t merge with failing tests or thin coverage. The workflow step below wires up the check.

1- name: Spec Compliance Check
2  run: |
3    go test ./...
4    specify validate --feature=product-search
5    coverage=$(go test -cover ./internal/product/... | grep -oP '\d+\.\d+(?=%)')
6    [ $(echo "$coverage >= 85" | bc) -eq 1 ] || (echo "Coverage below 85%"; exit 1)

The takeaway: CI turns “we should review this” into “this cannot merge unless it complies,” which is exactly the guarantee SDD is built to provide.

10.16 Tips & Gotchas

A few hard-won habits separate a smooth specify implement run from a frustrating one:

💡 Tip 1: Always start with --dry-run for large features — preview before committing hours.

💡 Tip 2: Review each phase before proceeding — Phase 1 bugs cost roughly 10x less to fix than Phase 4 bugs.

💡 Tip 3: Use --verbose for troubleshooting — it shows tokens, timing, and the full context sent to the AI.

💡 Tip 4: Don’t skip failing tests — they directly indicate spec-implementation gaps.

⚠️ Gotcha 1: specify implement overwrites files without confirmation — back up manual edits before re-running a task.

⚠️ Gotcha 2: Large codebases may hit context limits — use --scope to limit scanning.

⚠️ Gotcha 3: Auto-commit creates very granular git history — consider squashing before merge.

⚠️ Gotcha 4: Never implement without an approved spec and plan — all of Spec Kit’s value comes from the context chain.

10.17 The Complete Spec Kit Cycle

After all six commands, a single feature leaves behind a complete, traceable trail — from principles down to migrations. The tree below shows the full output of one cycle.

 1.specify/constitution.md     ← Project principles (permanent)
 2.specify/features/product-search/
 3  spec.md                    ← Business requirements (approved)
 4  clarifications.md          ← Q&A decisions (permanent record)
 5  plan.md                    ← Technical blueprint (versioned)
 6  tasks.md                   ← Progress tracker (all done ✓)
 7
 8internal/product/
 9  usecase/search_usecase.go  ← Business logic (from task 2.4)
10  repository/postgres...     ← Data layer (from task 2.2)
11  handler/search_handler.go  ← HTTP layer (from task 4.1)
12
13migrations/
14  20250702001_...sql         ← Database change (from task 1.1)
15
16Coverage: 91% (usecase layer)
17All ACs traced to tests. All tests green.

The takeaway: this artifact set — spec through code, every function traceable — is the durable asset SDD produces, and it’s what makes the feature maintainable long after the AI session ends.

10.18 Summary

specify implement is the execution stage of the Spec Kit cycle. With complete context from all previous stages, the AI generates Go code consistent with the architecture, conventions, and business logic you specified.

Use per-phase: --phase=N is the most recommended mode — it provides a review checkpoint after each phase.

Review every output: AI implementation is an excellent starting point, not a final product. Constitution compliance, SQL optimization, and test coverage all need manual verification.

Iteration is normal: when output is imperfect, fix it manually and continue. Don’t regenerate everything for one imperfect section.

With this article we’ve covered all six core Spec Kit commands. Next, we see how they work together in a real end-to-end case study — from a ticket to a merged PR.