Skip to main content

sdd-tasks

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.

Quellinformationen

Repository
Gentleman-Programming/agent-teams-lite
Letzte Quellaktivität
25. März 2026 um 15:14
Erkannte Sprache von SKILL.md
Englisch
Sterne
1.244
Forks
162

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
sdd-tasks
description
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.
license
MIT
metadata
{"author":"gentleman-programming","version":"2.0"}
## 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 > Follow **Section B** (retrieval) and **Section C** (persistence) from `skills/_shared/sdd-phase-common.md`. - **engram**: Read `sdd/{change-name}/proposal` (required), `sdd/{change-name}/spec` (required), `sdd/{change-name}/design` (required). Save as `sdd/{change-name}/tasks`. - **openspec**: Read and follow `skills/_shared/openspec-convention.md`. - **hybrid**: Follow BOTH conventions — persist to Engram AND write `tasks.md` to filesystem. Retrieve dependencies from Engram (primary) with filesystem fallback. - **none**: Return result only. Never create or modify project files. ## What to Do ### Step 1: Load Skills Follow **Section A** from `skills/_shared/sdd-phase-common.md`. ### 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 ```markdown # 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.** Follow **Section C** from `skills/_shared/sdd-phase-common.md`. - artifact: `tasks` - topic_key: `sdd/{change-name}/tasks` - type: `architecture` ### Step 5: Return Summary Return to the orchestrator: ```markdown ## 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.tasks` from `openspec/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 envelope per **Section D** from `skills/_shared/sdd-phase-common.md`.
Auf GitHub ansehen