speckit.tasks: Actionable, Parallelizable Task Breakdown for Go

speckit.tasks: Actionable and Parallel Task Breakdown

speckit tasks takes the validated plan.md and produces a speckit tasks golang breakdown — small tasks a single developer can finish in 15-90 minutes each. Every task has a concrete definition of done, specific files to create or modify, and clear dependencies.

This article covers the anatomy of tasks.md, how parallelization is computed, how to track progress, and how to coordinate two developers working the same feature at once.

09.1 Running specify tasks

The command reads the plan and emits a task list in one pass. The snippet below runs it on product-search.

1specify tasks product-search
2# Reads plan.md → generates tasks.md
3# Output: 16 tasks, 11.5h total, 4 phases, parallelization noted

Notice what the output reports up front: total task count, total time, phase count, and where work can run in parallel. The takeaway: before anyone writes code, you already have a sized, phased, parallelizable backlog derived from the plan.

09.2 Key Sections of tasks.md

A generated tasks.md is structured, not a flat to-do list. The four sections below make up every file:

1. Summary table — phases, task count, time estimates, dependencies
2. Per-phase tasks — each with a file target, code snippet, steps, and definition of done
3. Progress tracking table — assignee, status, dates
4. Parallelization notes — which phases can run concurrently

This fixed layout is what lets tasks.md serve as both a work queue and a status board — the same file drives implementation and reports progress.

09.3 Parallelization Notes

The most valuable part of the breakdown is the explicit call-out of what can happen simultaneously. The block below shows how Spec Kit describes it.

1After Phase 2 completes:
2- Developer A can start Phase 3 (UseCase tests)
3- Developer B can start Phase 4 (Handler implementation)
4- Both can work simultaneously without conflict
5
6Merge point: Phase 5 (Integration) requires both Phase 3 and 4 complete.

This is AI-computed from a dependency analysis of the plan, not a guess. The practical payoff is a shorter wall-clock timeline: once Phase 2 lands, two developers proceed in parallel and only re-converge at integration.

09.4 Task Duration Targets

Task sizing is deliberate — too small and you drown in context switches, too large and review becomes painful. The block below states the targets.

1Target: 30-90 minutes per task
2Minimum: 15 minutes (too small = too many context switches)
3Maximum: 120 minutes (too large = hard to review)
4
5Auto-split: Tasks > 90 min are automatically split into two tasks.

The auto-split rule is why every task stays reviewable: anything the AI estimates over 90 minutes is broken into two, so no single task ever becomes an unreviewable megachange.

09.5 Effective Definition of Done

A task is only actionable if “done” is measurable. The block below contrasts an effective definition of done with a vague one.

1✅ Effective DoD:
2- [ ] File compiles (go build ./...)
3- [ ] Specific test passes: TestSearchProducts_ValidKeyword
4- [ ] Manual curl test returns the expected response
5
6❌ Ineffective DoD:
7- [ ] Implementation complete (too vague)
8- [ ] Code reviewed (a PR requirement, not a task DoD)

The distinction is verifiability: an effective DoD is something you can run and observe, while “implementation complete” is an opinion. Keep task DoDs to checks a machine or a single command can confirm.

09.6 Task Progress Update Commands

Progress can be updated by command or by hand, and either way it belongs in version control. The commands below mark a task’s status.

1specify tasks product-search --task=2.2 --status=in-progress --assignee=andi
2specify tasks product-search --task=2.2 --status=done
3
4# Or edit directly
5vim .specify/features/product-search/tasks.md  # Update [ ] to [x]
6
7# Commit the update
8git commit -m "chore(product-search): tasks 1.1, 1.2, 2.1 done"

Committing every progress update is the habit that pays off later: the git history of tasks.md becomes an accurate development timeline you can mine during a retrospective.

09.7 Tasks as Daily Standup Reference

Because tasks.md already holds status and blockers, it doubles as a standup script. The block below shows a standup driven straight from the file.

1Monday standup:
2"Yesterday: Completed tasks 1.1 (migration) and 1.2 (DTOs).
3Today: Task 2.1 (interfaces) and starting 2.2 (repository).
4Blocker: No access to staging DB for migration verification."
5
6Clear progress, specific blocker, no elaborate explanation needed.

Standups reading from tasks.md stay short and concrete — progress maps to task IDs and blockers name a specific dependency, so there is nothing to improvise.

09.8 Tasks as PR Checklist

Tasks also give a pull request a precise, verifiable scope. The block below shows a PR description built from task IDs.

 1## PR Description
 2
 3Tasks completed in this PR:
 4- [x] Task 1.1: Database migration
 5- [x] Task 1.2: Search DTOs
 6- [x] Task 2.1: Interface updates + mock regeneration
 7
 8Tasks continuing in the next PR:
 9- [ ] Task 3.x: UseCase tests (@citra)
10- [ ] Task 4.x: Handler (@citra)

Listing completed task IDs tells the reviewer exactly what to expect and what is deferred — the diff and the checklist should line up one-to-one, which makes an out-of-scope change easy to spot.

09.9 Handling Unplanned Work

Implementation always surfaces work the plan missed, and tasks.md is where you capture it. The block below shows the response to a discovered dependency.

1@andi discovers that the 'indonesian' PostgreSQL dictionary isn't installed.
2Action:
31. Add Task 1.3 to tasks.md: "Configure Indonesian FTS dictionary [45 min]"
42. Update task 2.2 dependency: "now depends on Task 1.3"
53. Note in plan.md: "Indonesian FTS setup required (discovered during impl)"
64. Update the Jira estimate

The discipline here is to record the new task rather than absorb it silently: adding Task 1.3 and re-wiring the dependency keeps the estimate honest and stops the next developer from tripping over the same missing dictionary.

09.10 Task Health Check

The task file can report its own health, turning “how’s the feature going?” into numbers. The command below prints a status snapshot.

1specify tasks product-search --health
2
3# Task Health: product-search
4# Done: 4/12 (33%)
5# In Progress: 2/12 (17%)
6# Overdue tasks (> 2x estimate): Task 2.2 (180 min actual vs 90 min est.)
7# Projected completion: 2025-07-06

The overdue line is the early-warning signal — a task running at double its estimate flags a hidden difficulty worth investigating now, rather than discovering it as a missed deadline later.

09.11 Exporting Tasks

Tasks don’t have to live only in tasks.md; they can feed your existing trackers. The commands below export to Jira and CSV.

1specify tasks product-search --export=jira --parent=SHOP-123
2# Creates Jira sub-tasks: SHOP-123.1, SHOP-123.2, etc.
3
4specify tasks product-search --export=csv
5# For spreadsheet-based tracking

Export bridges the SDD workflow and the tools the rest of the organization already uses — engineers work from tasks.md while managers see the same tasks as Jira sub-tasks, with no double entry.

09.12 Parallel Development Workflow

With the breakdown in hand, two developers can split the feature cleanly. The block below shows a backend/testing split with branches.

1Dev A (Andi) — Backend Focus: Tasks 1.1, 1.2, 2.1, 2.2, 2.3, 2.4
2Branch: feat/SHOP-123-search-backend
3
4Dev B (Citra) — Testing Focus: Tasks 3.1, 4.1, 4.2, 4.3
5Branch: feat/SHOP-123-search-handler
6(Starts after Dev A completes Phase 2)
7
8Integration: Tasks 5.1, 5.2 — Pair programming

The branch-per-developer split works precisely because the tasks declare their dependencies: Dev B knows to wait for Phase 2, and the two streams only meet again at the integration tasks, avoiding merge chaos.

09.13 Estimate Buffer

The AI’s total is an estimate of the known work, so real budgets need padding. The block below shows how to buffer it.

1Spec Kit estimate: 11.5 hours
2Recommended actual budget: 14-15 hours (+20-30%)
3
4Buffer for:
5- Unknown unknowns (infrastructure issues, dependency surprises)
6- Code review iteration (not in the Spec Kit estimate)
7- Debugging unexpected test failures

Always add 20-30% to the AI’s number. The estimate covers the work it can see from the plan; the buffer covers the infrastructure snags, review rounds, and flaky failures it cannot.

09.14 Tasks for Rollback Planning

Safe features plan their exit before their entrance, and rollback belongs in the task list too. The block below shows two rollback-prep tasks.

1### Task 0.1: Verify Rollback SQL [10 min]
2DROP INDEX CONCURRENTLY IF EXISTS idx_products_fts;
3Verify: no queries fail after removal.
4
5### Task 0.2: Feature Flag [15 min]
6Add instant-disable capability without redeployment.

Treating rollback as real tasks — verified SQL plus a feature flag — means that if the feature misbehaves in production you can disable it in seconds, without an emergency deploy.

09.15 Transitioning from Tasks to Implementation

Once tasks.md is set, the final Spec Kit command executes the work task by task. The snippet below starts implementation.

 1# Start implementing the first task
 2specify implement product-search --phase=1
 3# or
 4specify implement product-search --task=1.1
 5
 6# Spec Kit will:
 7# 1. Load full context (constitution + spec + plan + tasks)
 8# 2. Focus on the requested task
 9# 3. Generate appropriate Go code
10# 4. Mark the task as "in progress" in tasks.md
11# 5. Run the post_implement hook after completion

Implement inherits the entire context chain — constitution, spec, plan, and tasks — so the generated Go code reflects every decision made in the earlier stages, and the task board updates itself as it goes.

09.16 Tips & Gotchas

The habits below keep a task breakdown accurate and the team coordinated:

💡 Tip 1: Update tasks.md in real time — stale progress tracking is worse than none.

💡 Tip 2: Use tasks.md as your daily standup reference — check it before each standup.

💡 Tip 3: Tasks under 15 minutes are better combined — too many context switches otherwise.

💡 Tip 4: Commit tasks.md on every progress update — the git log becomes a development timeline.

⚠️ Gotcha 1: AI estimates don’t account for unknown unknowns — always add a 20-30% buffer.

⚠️ Gotcha 2: Don’t skip tasks because they seem “obvious” — each DoD still needs checking.

⚠️ Gotcha 3: Regenerate tasks if the plan changes significantly — stale tasks lead to wrong implementation.

⚠️ Gotcha 4: Parallel tasks need explicit coordination — sync before starting to avoid conflicts.

09.17 Tasks vs Manual Task Breakdown

It helps to weigh the generated breakdown against doing it by hand. Manual breakdown for a moderate feature typically takes 30-60 minutes and produces 5-8 tasks. Spec Kit generates the breakdown in about 30 seconds and produces 12-20 tasks, each with its own definition of done.

The real difference is not speed but informedness: the Spec Kit breakdown is derived from the full plan, so it knows every dependency and attaches a DoD that references the relevant files. Manual breakdowns tend to miss the subtle dependencies that surface only during implementation.

09.18 Living Task Document

Unlike a Jira ticket that is created once and merely changes status, tasks.md is a living document. Over the life of the feature it is:

• Added to when unplanned work is discovered
• Updated with actual durations alongside the estimates
• Annotated with blockers and their resolutions
• Used in retrospectives to sharpen future estimation

Because it evolves with the work, tasks.md ends up being the most honest record of how the feature was actually built — estimates versus reality, blockers and all — which is exactly what makes the next estimate better.

09.19 Summary

specify tasks transforms plan.md into concrete work units — each task 15-90 minutes, with a measurable definition of done and clear dependencies.

Parallelization is the key benefit: tasks are designed knowing which can run concurrently, optimizing how the team’s time is used.

Built-in progress tracking: tasks.md is a living document updated during development, giving clear visibility into feature status.

Estimate buffer: always add 20-30% to Spec Kit’s total for the unknown unknowns that emerge during implementation.

In the next article, specify implement — the final execution stage that generates Go code from each task.