sdd-workflow
Skill19 starsChanged 37 days agoMITView on GitHub
Run the Spec Driven Development workflow (any coding-agent harness). Use when starting, specifying, implementing or reviewing a feature through requirements, design, tasks, human approval, implementation and review.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- uprinter/ai-agents-teamtheir own version, first seen Nov 8, 2026
- LuisSambrano/antigravity-configtheir own version, first seen Nov 8, 2026
- luanmorenommaciel/agentspectheir own version, first seen Oct 8, 2026
- theinterneti/TTA.devtheir own version, first seen Apr 4, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- luanmorenommaciel/agentspec★ 256same name
- LuisSambrano/antigravity-config★ 8same name
- uprinter/ai-agents-team★ 1same name
- theinterneti/TTA.dev★ 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 repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- broSkill
- closingSkill
- context-auditSkill
- decision-logSkill
- dependency-freshnessSkill
- documentation-updateSkill
- failure-learningSkill
- git-disciplineSkill
- goblin-modeSkill
- project-mapSkill
- run-and-verifySkill
- spec-from-screenshotSkill
- ui-qaSkill
- sdd-updateSkill
The file
We split this skill into the rules it gives an agent
12 rules. 0 are common, 9 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Use this skill when the developer asks to work through Spec Driven Development or when the project instruction file (AGENTS.md) says that a …
- Distinctive: line 13
Read the relevant file before acting:
- Distinctive: line 23
Do not write implementation code for an SDD task until the spec is approved according to the project approval policy.
- Distinctive: line 28
Check the task status.
- Distinctive: line 30
If the task needs a spec, create/update the spec.
- Very specific: line 31
If the spec is ready but not approved, render it and stop.
- Distinctive: line 32
If approved, implement from the spec.
- Very specific: line 38
Use $ARGUMENTS as the task ID, issue reference, feature slug or feature description supplied by the developer.
- Very specific: line 40
If $ARGUMENTS is empty, select the next eligible task from the configured task store.
- Distinctive: line 44
When the developer provides a functional document or asks to generate specs from a product/functional description, read:
- Distinctive: line 59
Do not implement code directly from a functional document.
- Distinctive: line 60
Stop after creating the spec unless the developer explicitly approves implementation.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
SDD Workflow Skill
Use this skill when the developer asks to work through Spec Driven Development or when the project instruction file (AGENTS.md) says that a task requires SDD.
Required supporting files
Read the relevant file before acting:
workflow.mdfor the full procedure.task-state-machine.mdfor status transitions.spec-format.mdwhen creating or editing specs.review-checklist.mdwhen reviewing implementation.examples.mdwhen an output example is needed.
Core rule
Do not write implementation code for an SDD task until the spec is approved according to the project approval policy.
Standard execution
- Identify the task.
- Check the task status.
- Route according to
task-state-machine.md. - If the task needs a spec, create/update the spec.
- If the spec is ready but not approved, render it and stop. If the developer left a feedback file (
specs/<feature-slug>/feedback.md, a downloaded<feature-slug>.feedback.md, or pasted text), apply it first (spec-format.md§ Feedback file). - If approved, implement from the spec.
- Validate and review.
- Record completion.
Argument
Use $ARGUMENTS as the task ID, issue reference, feature slug or feature description supplied by the developer.
If $ARGUMENTS is empty, select the next eligible task from the configured task store.
Functional document intake
When the developer provides a functional document or asks to generate specs from a product/functional description, read:
intake-from-functional-doc.mdassumptions-policy.mdopen-questions-policy.md
Then generate or update:
requirements.mddesign.mdtasks.mdassumptions.mdopen-questions.mdacceptance-tests.md
Do not implement code directly from a functional document. Stop after creating the spec unless the developer explicitly approves implementation.
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.