Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jorgeferrando/sdd-skills/llms.txt

Use this file to discover all available pages before exploring further.

/sdd-tasks converts the approved design into a sequenced list of atomic implementation tasks. Each task targets exactly one file and produces exactly one commit. The ordering follows strict dependency rules so that interfaces are built before their consumers and tests land alongside or after their implementation. The result is tasks.md — the document that /sdd-apply follows to implement the change. Use /sdd-tasks after design.md is approved.

​
Usage

/sdd-tasks                 # Generate tasks for the active change
/sdd-tasks {change-name}   # Tasks for a specific change

​
Prerequisites

  • openspec/changes/{change-name}/design.md approved

​
What it does

1

Review design

Reads openspec/changes/{change-name}/design.md to extract:
  • The complete list of files to create or modify
  • Dependencies between files
  • Planned tests
2

Order by dependencies

Applies four ordering rules:
  1. Interfaces and contracts first — anything others depend on comes before its dependants
  2. Base files before files that use them — foundational modules before consumers
  3. Tests after (or interleaved with) implementation — test files follow their subject file
  4. One file per task, one commit per task — no batching
The ordering produces the minimum number of conflicts during sequential implementation.
3

Check git state and create branch

Checks the current branch and git status:
git status
git branch --show-current
Creates a feature branch if the project uses branching (checks conventions.md or tech.md for the branching strategy). If already on a feature branch or the project commits directly to main, branch creation is skipped:
# Only if not already on a feature branch:
git checkout -b {ticket-or-change-name}
4

Create tasks.md

Writes the ordered task list to openspec/changes/{change-name}/tasks.md. Includes a Quality Gate task at the end.
5

Confirm with user

Presents the task list and asks:
  • Is the order correct?
  • Is any task too large for a single commit?
  • Anything missing?
Adjusts based on feedback before finalizing.

​
Output

openspec/changes/{change-name}/tasks.md 
# Tasks: {Change Title}

## Metadata
- **Change:** {change-name}
- **Ticket:** {TICKET-ID or N/A}
- **Branch:** {branch-name}
- **Date:** {YYYY-MM-DD}

## Implementation Tasks

- [ ] **T01** Create `{path/to/file}` — {one-line description}
  - Commit: `[{change-name}] Add {description}`

- [ ] **T02** Modify `{path/to/file}` — {what changes}
  - Commit: `[{change-name}] Update {description}`
  - Depends on: T01

- [ ] **T03** Create `{path/to/test-file}` — {test description}
  - Commit: `[{change-name}] Add tests for {subject}`
  - Depends on: T02

## Quality Gate

- [ ] **QG** Run tests and quality checks
  - {test command}
  - {lint command if applicable}

## Notes

- {Ordering constraint if any}
- {Known gotcha}

​
Task identifier conventions

PrefixMeaning
T01, T02, …Planned implementation tasks
BUG01, BUG02, …Bugs discovered during apply
IMP01, IMP02, …Improvements registered during apply
QGQuality gate (run at end of all tasks)
During /sdd-apply, any work not already in tasks.md must be registered as BUGxx or IMPxx before implementation. The task list is the project timeline — nothing is implemented without being tracked.

​
Skill metadata

PropertyValue
model_hinthaiku
requiresopenspec/changes/{change}/design.md
producesopenspec/changes/{change}/tasks.md

​
Next steps

With tasks.md approved, run /sdd-apply to implement the change task by task. You can start from the beginning with /sdd-apply, or resume from a specific task with /sdd-apply T03.

Build docs developers (and LLMs) love

Get started for freeTalk to us