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-apply is the implementation skill. It reads tasks.md, loads your project’s steering files, then implements each pending task using a dedicated subagent — one agent per task, one commit per task. After each task, the orchestrator marks it complete, reports progress, and asks before starting the next one. Nothing is implemented outside of tasks.md: unexpected work is registered as a tracked item before any code is written. Use /sdd-apply after tasks.md is approved.

​
Usage

/sdd-apply                 # Start from the first pending task
/sdd-apply {change-name}   # Implement a specific change
/sdd-apply T03             # Resume from a specific task
/sdd-apply --auto          # Skip per-task confirmation prompts

​
Prerequisites

  • openspec/changes/{change-name}/tasks.md approved with a task list
  • Correct git branch created (done by /sdd-tasks)
  • openspec/steering/conventions.md must exist
openspec/steering/conventions.md is a hard requirement. If it does not exist, /sdd-apply stops immediately and will not proceed. Run /sdd-init to generate steering files before applying any change.

​
Architecture: orchestrator + subagents

/sdd-apply uses a two-level architecture:
  • The orchestrator (haiku) manages task sequencing, loads steering files, updates tasks.md, and reports progress.
  • One subagent (sonnet) is launched per task. Each agent receives its task, the steering content inline, and spec context. Implementation details — code read, test output, attempts — stay inside the agent and do not accumulate in the main conversation.
Steering content is passed inline to every subagent so the LLM can cache it across sequential agents, reducing token usage.

​
What it does

1

Verify bootstrap and load steering

Checks that openspec/steering/conventions.md exists. Stops with an error if it does not.Then loads steering files silently (no output unless something relevant is found):
  • If openspec/steering/project-skill.md exists → reads it as the index, which references the rest
  • Otherwise → reads conventions.md, project-rules.md, and tech.md in parallel
Selective specialist loading: only loads specialist files (conventions-testing.md, conventions-security.md, etc.) when the current task’s file matches the specialist’s domain. Base conventions.md is always sufficient; specialists are loaded only when relevant.
2

Load current state

Reads tasks.md and identifies:
  • Tasks already completed ([x])
  • The next pending task
  • Dependencies between tasks
If /sdd-apply T03 was used, starts from that specific task.
3

Verify git state

Confirms the working tree is clean and the correct branch is active:
git status
git branch --show-current
4

Implement task by task

For each pending task, launches a subagent with:
  • The full task line from tasks.md (file path + description)
  • Dependency task IDs
  • Steering content (inline, for prompt caching)
  • Spec and design context file paths
The subagent:
  1. Reads similar existing code to follow established patterns
  2. Implements the change
  3. Runs tests and lint on the changed file
  4. Commits atomically: [{change-name}] Description
  5. Returns a short summary: what was done, files touched, commit hash, test result
After each agent returns, the orchestrator marks the task [x] in tasks.md, reports progress, and asks before launching the next agent:
T02 completed ✓  ({one-line summary from agent})
Commits: 2/5
Continue with T03?
With --auto, confirmation is skipped and the next agent starts immediately after a successful task. If an agent reports an unexpected situation, the orchestrator always pauses regardless of mode.

​
Commit format

Every commit follows a consistent format: 
[{change-name}] {Description in English, imperative mood}
  • Maximum 70 characters on the first line
  • Imperative mood: “Add”, “Fix”, “Update” (not “Added”, “Fixes”)
  • Only the file(s) for the current task are staged (atomic commit)

​
Handling unplanned work

If the user requests a change not already in tasks.md, or if unexpected code appears during implementation:
1

Register before implementing

Add the item to tasks.md under a dedicated section before writing any code:
## Bugs found during apply

- [ ] **BUG01** `path/file` — short symptom description
  - Fix: {description}
  - Commit: `[{change-name}] Fix {description}`
2

Implement and commit atomically

Implement the fix as a separate commit following the same task rules.
3

Mark complete

Mark [x] in tasks.md after the commit.

​
Unexpected situations

When a subagent encounters something not covered by its task, it does not make a unilateral decision. It returns the situation description to the orchestrator, which presents options to the user: 
During T03 I found {situation}.
The tasks don't cover this case. How should I proceed?
1. {Option A}
2. {Option B}
3. Stop and update design/tasks

​
Completion summary

When all tasks are done: 
APPLY COMPLETE: {change-name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Tasks completed: N/N
Commits: N
Files created: [list]
Files modified: [list]

Next: /sdd-verify

​
Skill metadata

PropertyValue
model_hinthaiku (orchestrator)
model_hint_subagentssonnet (per-task agents)
requiresopenspec/changes/{change}/tasks.md, openspec/steering/conventions.md
producescode commits (no new OpenSpec artifacts)

​
Next steps

After all tasks complete, run /sdd-verify to run the full test suite, quality checks, self-review checklist, and spec compliance check before creating the PR.

Build docs developers (and LLMs) love

Get started for freeTalk to us