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.
45
47%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./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.