sdd-implement
Skill0 starsChanged 29 days agoApache-2.0View on GitHub
Use when tasks.md exists with unchecked tasks. Implements exactly one task at a time - test first where the check is a test - runs its check, and only then ticks it. Sends any new or changed requirement back to the spec before coding it.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- ad1code/sdd-harnesstheir own version, first seen Nov 1, 2026
- pchemguy/Skill-SDD-Managertheir own version, first seen Oct 6, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- ad1code/sdd-harness★ 4same name
- pchemguy/Skill-SDD-Manager★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- AGENTS.mdAGENTS.md
- sdd-constitutionSkill
- sdd-planSkill
- sddSkill
- sdd-specifySkill
- sdd-tasksSkill
- sdd-verifySkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Before anything else, read these if they exist.
- Very specific: line 22
Write every artifact in language.
- Distinctive: line 31
Test first: If the task's check is a test, write that test now and run it.
- Very specific: line 38
Tick it: only on a passing check: - [x] T-n — … — done YYYY-MM-DD.
- Very specific: line 46
If the work reveals a requirement the spec does not have — a missing case, a changed behavior, a constraint nobody wrote down — stop coding.
- Very specific: line 60
When every task is ticked, say so and hand over to sdd-verify.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
SDD — Implement
Implementation follows tasks.md one task at a time. A task is done when its check passed
in this session — not when the code looks right.
Step 0 — Load project settings
Before anything else, read these if they exist. Missing files are normal; use the defaults.
.sdd/config.yamlin the project, else~/.sdd/config.yaml. Defaults:specs_dir: specs,language: en,ids: {requirement: REQ, task: T},gates: [specify, plan, tasks],verify_command: "",phases: [constitution, specify, plan, tasks, implement, verify].- Extra rules:
.sdd/rules/all.mdand.sdd/rules/implement.md(project, then global). They add to this skill; when they conflict with it, they win.
Write every artifact in language. Use the configured ID prefixes everywhere this skill
says REQ or T.
The loop
For each task:
- Pick the first unticked task whose
dependsare all ticked, or the one the user names. Read the requirements it cites inspec.mdand the matching plan steps. - Test first. If the task's check is a test, write that test now and run it. It must fail, and fail because the behavior is missing (not because of a typo or an import error). A test that passes before the code exists is not testing the task.
- Implement the minimum that makes the check pass. Do not build ahead of the tasks.
- Run the task's
checkand read the output. Compare it with the expected result intasks.md. Also run the project's test suite (verify_command, else the constitution's test command) — a green task with a red suite is not done. - Tick it only on a passing check:
- [x] T-n — … — done YYYY-MM-DD. Never tick a task whose check you did not run. - Commit that task alone, citing it:
feat: <title> (T-n, REQ-a). - Report
k/N tasks donein one line and continue with the next task, unless the user asked to pause or a gate applies.
Spec first
If the work reveals a requirement the spec does not have — a missing case, a changed
behavior, a constraint nobody wrote down — stop coding. Add it to spec.md following
the "Changing a spec" rules of sdd-specify (the next free ID; IDs never renumber), get
the user's approval if specify is gated, add the plan step and the task, then continue.
Code that implements a requirement the spec does not contain is invisible to verification.
When a check fails
Find the cause before changing anything. If the code is wrong, fix the code. If the task
or the plan is wrong (impossible check, wrong file, missing dependency), fix tasks.md or
plan.md first and say so — do not quietly change what "done" means.
Finishing
When every task is ticked, say so and hand over to sdd-verify.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.