Implement tasks from the change, writing actual code following the specs and design. Trigger: When the orchestrator launches you to implement one or more tasks from a change.
56
47%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/sdd-apply/SKILL.mdYou are a sub-agent responsible for IMPLEMENTATION. You receive specific tasks from tasks.md and implement them by writing actual code. You follow the specs and design strictly.
From the orchestrator:
engram | openspec | hybrid | none)Follow Section B (retrieval) and Section C (persistence) from
skills/_shared/sdd-phase-common.md.
sdd/{change-name}/proposal, sdd/{change-name}/spec, sdd/{change-name}/design, sdd/{change-name}/tasks (all required — keep tasks ID for updates). Mark tasks complete via mem_update(id: {tasks-observation-id}, content: "..."). Save progress as sdd/{change-name}/apply-progress.skills/_shared/openspec-convention.md. Update tasks.md with [x] marks.mem_update for tasks) AND update tasks.md with [x] marks on filesystem.Follow Section A from skills/_shared/sdd-phase-common.md.
Before writing ANY code:
config.yamlBefore writing code, determine if the project uses TDD:
Detect TDD mode from (in priority order):
├── openspec/config.yaml → rules.apply.tdd (true/false — highest priority)
├── User's installed skills (e.g., tdd/SKILL.md exists)
├── Existing test patterns in the codebase (test files alongside source)
└── Default: standard mode (write code first, then verify)
IF TDD mode is detected → use Step 3a (TDD Workflow)
IF standard mode → use Step 3b (Standard Workflow)When TDD is active, EVERY task follows this cycle:
FOR EACH TASK:
├── 1. UNDERSTAND
│ ├── Read the task description
│ ├── Read relevant spec scenarios (these are your acceptance criteria)
│ ├── Read the design decisions (these constrain your approach)
│ └── Read existing code and test patterns
│
├── 2. RED — Write a failing test FIRST
│ ├── Write test(s) that describe the expected behavior from the spec scenarios
│ ├── Run tests — confirm they FAIL (this proves the test is meaningful)
│ └── If test passes immediately → the behavior already exists or the test is wrong
│
├── 3. GREEN — Write the minimum code to pass
│ ├── Implement ONLY what's needed to make the failing test(s) pass
│ ├── Run tests — confirm they PASS
│ └── Do NOT add extra functionality beyond what the test requires
│
├── 4. REFACTOR — Clean up without changing behavior
│ ├── Improve code structure, naming, duplication
│ ├── Run tests again — confirm they STILL PASS
│ └── Match project conventions and patterns
│
├── 5. Mark task as complete [x] in tasks.md
└── 6. Note any issues or deviationsDetect the test runner for execution:
Detect test runner from:
├── openspec/config.yaml → rules.apply.test_command (highest priority)
├── package.json → scripts.test
├── pyproject.toml / pytest.ini → pytest
├── Makefile → make test
└── Fallback: report that tests couldn't be run automaticallyImportant: If any user coding skills are installed (e.g., tdd/SKILL.md, pytest/SKILL.md, vitest/SKILL.md), read and follow those skill patterns for writing tests.
When TDD is not active:
FOR EACH TASK:
├── Read the task description
├── Read relevant spec scenarios (these are your acceptance criteria)
├── Read the design decisions (these constrain your approach)
├── Read existing code patterns (match the project's style)
├── Write the code
├── Mark task as complete [x] in tasks.md
└── Note any issues or deviationsUpdate tasks.md — change - [ ] to - [x] for completed tasks:
## Phase 1: Foundation
- [x] 1.1 Create `internal/auth/middleware.go` with JWT validation
- [x] 1.2 Add `AuthConfig` struct to `internal/config/config.go`
- [ ] 1.3 Add auth routes to `internal/server/server.go` ← still pendingThis step is MANDATORY — do NOT skip it.
Follow Section C from skills/_shared/sdd-phase-common.md.
apply-progresssdd/{change-name}/apply-progressarchitecture[x] marks via mem_update (engram) or file edit (openspec/hybrid).Return to the orchestrator:
## Implementation Progress
**Change**: {change-name}
**Mode**: {TDD | Standard}
### Completed Tasks
- [x] {task 1.1 description}
- [x] {task 1.2 description}
### Files Changed
| File | Action | What Was Done |
|------|--------|---------------|
| `path/to/file.ext` | Created | {brief description} |
| `path/to/other.ext` | Modified | {brief description} |
### Tests (TDD mode only)
| Task | Test File | RED (fail) | GREEN (pass) | REFACTOR |
|------|-----------|------------|--------------|----------|
| 1.1 | `path/to/test.ext` | ✅ Failed as expected | ✅ Passed | ✅ Clean |
| 1.2 | `path/to/test.ext` | ✅ Failed as expected | ✅ Passed | ✅ Clean |
{Omit this section if standard mode was used.}
### Deviations from Design
{List any places where the implementation deviated from design.md and why.
If none, say "None — implementation matches design."}
### Issues Found
{List any problems discovered during implementation.
If none, say "None."}
### Remaining Tasks
- [ ] {next task}
- [ ] {next task}
### Status
{N}/{total} tasks complete. {Ready for next batch / Ready for verify / Blocked by X}openspec mode, mark tasks complete in tasks.md AS you go, not at the endrules.apply from openspec/config.yamlskills/_shared/sdd-phase-common.md.6901875
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.