Plan Tasks Skill

Goal: Create tasks.md with granular, checkable steps for implementing a story.

Use this skill after write-specs has produced a spec pack.

Inputs (files)

• spec.md (required)
• design.md (required)
• planning/context-brief.md (required)
  • Paths are relative to the story working folder.

Output

• tasks.md (in the same story folder)

Template (authoritative)

• Template filename is defined in config.json under templates.tasks (default: tasks.template.md in this folder).

Configuration

• Defaults live in config.json. Adjust maxTaskDays, groupOrder, required inputs, and template filename to port this skill to other repositories.

Workflow

Read the Design and Spec, then break down the implementation into organized phases:

1. 🏗️ Scaffolding & Setup: Creating files/projects, registering dependencies in DI container (see host-plugin-bootstrap skill)
2. 💾 Data & Schema: Database/Schema changes, document models (see marten-document-modeling skill)
3. 🧠 Core Logic: Domain implementation, interface contracts, validation rules
4. 🧪 Testing: Integration and Unit tests (see integration-test-harness skill)
5. 🏁 Verification: Manual verification steps

Rules

• No vague tasks: "Implement logic" is bad. "Implement CalculateTax method in PayrollEngine" is good.
• Test-First: Include a task to "Create Integration Test Scaffolding" before the logic implementation.
• Specific and verifiable: Each task must have clear, checkable steps.
• Use Context Brief: Refer to planning/context-brief.md to ensure tasks follow the correct patterns from existing implementations.
• Reference skills: Point to relevant skills (like integration-test-harness, host-plugin-bootstrap) in task descriptions.
• Tasks should be scoped to finish within <= 5 days (aim for less when possible).

Tracer Bullet Principles

While tasks are organized by phase for clarity, strive to create working, testable slices:

• Each task in Core Logic should touch necessary Data and Scaffolding elements
• Validate assumptions early with tests
• Tasks should be completable in one context session by an AI agent
• Avoid building all models first, then all services — integrate as you go

Task Structure Best Practices

Each checkbox task should be:

• Specific: Include concrete class/method/file names (e.g., "Implement CalculateTax method in PayrollEngine.cs")
• Actionable: Clear what to do ("Create", "Implement", "Add", "Register")
• Verifiable: Can be checked off unambiguously
• Referenced: Include inline references to instruction files (e.g., "→ Ref: host-plugin-bootstrap")

Example Tasks

🏗️ Scaffolding & Setup
[ ] Create `Lista.Engine.Payroll.Service` project
[ ] Register `PayrollEngine` in `Program.cs` DI container → Ref: host-plugin-bootstrap
[ ] Add project reference from `Lista.Manager.Process` to `Lista.Engine.Payroll.Interfaces`

🧠 Core Logic
[ ] Implement `IPayrollEngine` interface in `PayrollEngine.cs`
[ ] Implement `CalculateTax` method with rate validation
[ ] Add validation rules for negative amounts

🧪 Testing
[ ] Create Integration Test Scaffolding → Ref: integration-test-harness
[ ] Write Happy Path Test: Calculate tax for valid payroll amount
[ ] Write Edge Case Test: Handle zero and negative amounts

Testing Guidelines

• Create Integration Test Scaffolding before implementing core logic (Test-First approach)
• Reference the integration-test-harness skill for container setup and test patterns
• Write focused tests in the 🧪 Testing phase:
  • Happy Path tests (normal, expected scenarios)
  • Edge Case tests (from edge-cases.md)
  • Integration tests that validate end-to-end flows
• Keep tests close to changed code
• Use descriptive test names that explain what's being validated

Azure DevOps Integration (Optional)

After generating tasks.md, offer to create the tasks in Azure DevOps:

1. Prompt the user: "Would you like me to create these tasks in Azure DevOps under Story #[storyId]?"

   • Extract storyId from story.md YAML frontmatter (workItemId field)
   • If no workItemId found, ask the user for the parent Story ID

2. On approval, use the sync-to-ado skill (or the lista-story formula's sync step) to:

   • Create each task as a Task work item in ADO
   • Use the task title only (no "ET1:" prefixes — clean titles like "Create accessor interface for Company")
   • Link each created task to the parent Story using Parent relation

3. Update tasks.md with the returned work item IDs:

   • Add <!-- adoTaskId: 701234 --> comment after each task header
   • This enables future sync operations

4. Report results:

   • List each task created with its ADO ID
   • If any tasks fail to create, continue with remaining tasks and report failures at the end

Example Prompt Flow

Agent: I've generated tasks.md with 8 tasks. Would you like me to create these 
       tasks in Azure DevOps under Story #669335?

User: Yes

Agent: Creating tasks in Azure DevOps...
       ✓ Created Task #701234: Create accessor interface for Company
       ✓ Created Task #701235: Implement CompanyAccessor service
       ✓ Created Task #701236: Add Marten document configuration
       ... (etc)
       
       Updated tasks.md with ADO work item IDs.