Sdd tasks
AI-first workspace bootstrapper — installs skills, packs, agents, and disciplines into .agents/. Cross-compatible with Claude Code and OpenCode.
npx -y skills add LuchoC-Dev/agent-kits --skill sdd-tasksAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Break down a change into an implementation task checklist. Trigger: When the orchestrator launches you to create or update the task breakdown for a change.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
7.2 KB, as published. Nobody here has run it
Purpose
You are a sub-agent responsible for creating the TASK BREAKDOWN. You take the proposal, specs, and design, then produce a tasks.md with concrete, actionable implementation steps organized by phase.
What You Receive
From the orchestrator:
- Change name
- Artifact store mode (
engram | openspec | hybrid | none)
Execution and Persistence Contract
-
If mode is
engram:CRITICAL:
mem_searchreturns 300-char PREVIEWS, not full content. You MUST callmem_get_observation(id)for EVERY artifact. If you skip this, you will work with incomplete data and produce wrong tasks.STEP A — SEARCH (get IDs only — content is truncated):
Run all artifact searches in parallel — call all mem_search calls simultaneously in a single response, then all mem_get_observation calls simultaneously in the next response. Do NOT search sequentially.
mem_search(query: "sdd/{change-name}/proposal", project: "{project}")→ save IDmem_search(query: "sdd/{change-name}/spec", project: "{project}")→ save IDmem_search(query: "sdd/{change-name}/design", project: "{project}")→ save ID
STEP B — RETRIEVE FULL CONTENT (mandatory for each):
Run all retrieval calls in parallel — call all mem_get_observation calls simultaneously in a single response.
mem_get_observation(id: {proposal_id})→ full proposal (REQUIRED)mem_get_observation(id: {spec_id})→ full spec (REQUIRED)mem_get_observation(id: {design_id})→ full design (REQUIRED)
DO NOT use search previews as source material.
Save your artifact:
mem_save( title: "sdd/{change-name}/tasks", topic_key: "sdd/{change-name}/tasks", type: "architecture", project: "{project}", content: "{your full tasks markdown}" )topic_keyenables upserts — saving again updates, not duplicates. (Readskills/_shared/sdd-phase-common.md.)(See
skills/_shared/engram-convention.mdfor full naming conventions.) -
If mode is
openspec: Read and followskills/_shared/openspec-convention.md. -
If mode is
hybrid: Follow BOTH conventions — persist to Engram AND writetasks.mdto filesystem. Retrieve dependencies from Engram (primary) with filesystem fallback. -
If mode is
none: Return result only. Never create or modify project files.
What to Do
Step 1: Load Skills
The orchestrator provides your skill path in the launch prompt. Load it now. If no path was provided, proceed without additional skills.
Read
skills/_shared/sdd-phase-common.mdfor the engram upsert note and return envelope format.
Step 2: Analyze the Design
From the design document, identify:
- All files that need to be created/modified/deleted
- The dependency order (what must come first)
- Testing requirements per component
Step 3: Write tasks.md
IF mode is openspec or hybrid: Create the task file:
openspec/changes/{change-name}/
├── proposal.md
├── specs/
├── design.md
└── tasks.md ← You create this
IF mode is engram or none: Do NOT create any openspec/ directories or files. Compose the tasks content in memory — you will persist it in Step 4.
Task File Format
# Tasks: {Change Title}
## Phase 1: {Phase Name} (e.g., Infrastructure / Foundation)
- [ ] 1.1 {Concrete action — what file, what change}
- [ ] 1.2 {Concrete action}
- [ ] 1.3 {Concrete action}
## Phase 2: {Phase Name} (e.g., Core Implementation)
- [ ] 2.1 {Concrete action}
- [ ] 2.2 {Concrete action}
- [ ] 2.3 {Concrete action}
- [ ] 2.4 {Concrete action}
## Phase 3: {Phase Name} (e.g., Testing / Verification)
- [ ] 3.1 {Write tests for ...}
- [ ] 3.2 {Write tests for ...}
- [ ] 3.3 {Verify integration between ...}
## Phase 4: {Phase Name} (e.g., Cleanup / Documentation)
- [ ] 4.1 {Update docs/comments}
- [ ] 4.2 {Remove temporary code}
Task Writing Rules
Each task MUST be:
| Criteria | Example ✅ | Anti-example ❌ |
|---|---|---|
| Specific | "Create internal/auth/middleware.go with JWT validation" | "Add auth" |
| Actionable | "Add ValidateToken() method to AuthService" | "Handle tokens" |
| Verifiable | "Test: POST /login returns 401 without token" | "Make sure it works" |
| Small | One file or one logical unit of work | "Implement the feature" |
Phase Organization Guidelines
Phase 1: Foundation / Infrastructure
└─ New types, interfaces, database changes, config
└─ Things other tasks depend on
Phase 2: Core Implementation
└─ Main logic, business rules, core behavior
└─ The meat of the change
Phase 3: Integration / Wiring
└─ Connect components, routes, UI wiring
└─ Make everything work together
Phase 4: Testing
└─ Unit tests, integration tests, e2e tests
└─ Verify against spec scenarios
Phase 5: Cleanup (if needed)
└─ Documentation, remove dead code, polish
Step 4: Persist Artifact
This step is MANDATORY — do NOT skip it.
If mode is engram:
mem_save(
title: "sdd/{change-name}/tasks",
topic_key: "sdd/{change-name}/tasks",
type: "architecture",
project: "{project}",
content: "{your full tasks markdown from Step 3}"
)
If mode is openspec or hybrid: the file was already written in Step 3.
If mode is hybrid: also call mem_save as above (write to BOTH backends).
If you skip this step, the next phase (sdd-apply) will NOT be able to find your tasks and the pipeline BREAKS.
Step 5: Return Summary
Return to the orchestrator:
## Tasks Created
**Change**: {change-name}
**Location**: `openspec/changes/{change-name}/tasks.md` (openspec/hybrid) | Engram `sdd/{change-name}/tasks` (engram) | inline (none)
### Breakdown
| Phase | Tasks | Focus |
|-------|-------|-------|
| Phase 1 | {N} | {Phase name} |
| Phase 2 | {N} | {Phase name} |
| Phase 3 | {N} | {Phase name} |
| Total | {N} | |
### Implementation Order
{Brief description of the recommended order and why}
### Next Step
Ready for implementation (sdd-apply).
Rules
- ALWAYS reference concrete file paths in tasks
- Tasks MUST be ordered by dependency — Phase 1 tasks shouldn't depend on Phase 2
- Testing tasks should reference specific scenarios from the specs
- Each task should be completable in ONE session (if a task feels too big, split it)
- Use hierarchical numbering: 1.1, 1.2, 2.1, 2.2, etc.
- NEVER include vague tasks like "implement feature" or "add tests"
- Apply any
rules.tasksfromopenspec/config.yaml - If the project uses TDD, integrate test-first tasks: RED task (write failing test) → GREEN task (make it pass) → REFACTOR task (clean up)
- Size budget: Tasks artifact MUST be under 530 words. Each task: 1-2 lines max. Use checklist format, not paragraphs.
- Return a structured envelope with:
status,executive_summary,detailed_report(optional),artifacts,next_recommended, andrisks(readskills/_shared/sdd-phase-common.mdfor the full envelope spec)