CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

68

Quality

60%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/sdd-tasks/SKILL.md
SKILL.md
Quality
Evals
Security

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

# 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:

CriteriaExample ✅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"
SmallOne 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:

## 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.
Repository
Gentleman-Programming/agent-teams-lite
Last updated
Created

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.