sdd-execute-task
Skill3 starsChanged 35 days agoMITView on GitHub
Execution of one exact SDD task in the current session, standalone or as a step of sdd-orchestrate-tasks; does not plan or approve its own work.
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- ai-ready-fixSkill
- ai-ready-scoreSkill
- architectural-analysisSkill
- commitSkill
- deep-reviewSkill
- domain-modelingSkill
- dotnet-efficient-validationSkill
- herdr-orchestrationSkill
- no-workaroundsSkill
- repository-cli-efficiencySkill
- sdd-create-prdSkill
- sdd-create-techspecSkill
- sdd-execute-correctionsSkill
- sdd-orchestrate-flowSkill
- sdd-orchestrate-prdsSkill
- sdd-orchestrate-tasksSkill
- sdd-plan-auditSkill
- sdd-plan-correctionsSkill
- sdd-plan-refactoringSkill
- sdd-plan-tasksSkill
- sdd-review-codeSkill
- sdd-snapshotSkill
- sdd-triageSkill
- update-nuget-packagesSkill
- writing-agents-mdSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Read local instructions and only skills relevant to the change.
- Distinctive: line 16
Run checks required by the diff.
- Distinctive: line 18
Output: every acceptance item has evidence or a reproducible block.
- Very specific: line 19
Update one ## Handoff: result, files, commands, results, validated version, quality profile reservation hits, and pending items.
≈ “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
Execute an SDD task
- Resolve one
tasks/prd-[slug]/task_[num].md. Require the PRD, TechSpec, and feature manifest. Read stable sources once per version in PRD, TechSpec, task order; consult state afterward. Confirm completed dependencies and a pending task. A task indone/is only reported. Output: exact contract, satisfied dependencies, and identified write scope. - Read local instructions and only skills relevant to the change. Inspect worktree, callers, and affected tests; preserve pre-existing changes. Map every acceptance item to implementation and evidence. Output: known change points; source or write conflicts returned to the caller before mutation.
- Implement the smallest coherent change and behavior tests proportional to risk. Mark subtasks only with evidence. Edit only assigned files and the task itself; other features' artifacts stay as they are, even when the code comes to contradict them; reserve manifest and moves for the caller. Output: implementation limited to the contract, with no global state changed.
- Apply the TechSpec profile. In desktop C#/.NET, omit E2E even when legacy commands include it: select projects/filters without E2E and record the divergence. Preserve acceptance with relevant unit, integration, and manual scripts; unexecuted manual work remains pending. When available, use
dotnet-efficient-validationfor runner and build reuse. Run checks required by the diff; reuse evidence only from the same code, configuration, and environment. Zero tests or listing are not success. Record pre-existing failures separately. Also run the TechSpec quality profile commands, scoped to the files you touched. Empty output settles the matter. Check every hit against the Terrain baseline: a hit already listed there is prior debt and not yours, unless your change aggravated it. A new blocking hit without aDEC-NNcovering it is your defect: fix it before the handoff; do not report it as a pending item. A new reservation hit remains and goes to the handoff with file and line. A profile or baseline missing from the TechSpec is recorded as a gap, not filled in on your own. Output: every acceptance item has evidence or a reproducible block; no unjustified blocking hit survives in the diff. - Update one
## Handoff: result, files, commands, results, validated version, quality profile reservation hits, and pending items. Return a short summary and path for independent review; on retry, change the same section and preserve valid evidence. Output: handoff sufficient for the caller to review diff, tests, and acceptance; task remains at root until approval.
Decisions and failures
- Record an ADR candidate only for a durable decision with alternatives and trade-offs governing contracts, boundaries, or quality attributes. Use
TXX-ADR-NN, title, context, decision, alternatives, consequences, evidence, and TechSpec relationship; otherwise useNone. Promotion occurs after HIL 3 acceptance. - Architectural or scope deviation requires a human decision unless existing authorization covers it. Record the conflict and return it to the caller; do not invent approval.
- An unavailable environment or pending dependency keeps affected acceptance unmarked; return command/error/impact. Retry fixes only the failure; after two attempts without new evidence, return a block for a decision.
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.

