Create Tasks

File naming: NNNN-short-title.md - zero-padded number, lowercase, hyphenated.

To find the next number, check across all subdirectories for the highest NNNN prefix and increment by 1.

When creating tasks, use .tasks/_template.md as the base and save them to .tasks/backlog/.

What Engineers Need

Every task must provide:

• What they're building (deliverable)
• Why it matters (context)
• Key decisions and principles they must follow
• Acceptance criteria
• Dependencies
• Related code/patterns
• How to verify it works

Before Creating Tasks: Slice First

🚨 NEVER create a task without validating its size first. A PRD deliverable is NOT automatically a task—it may be an epic that needs splitting.

Example Mapping Discovery

🚨 Never copy PRD bullets verbatim. Use Example Mapping to transform them into executable specifications.

The Examples (🟢) ARE your acceptance criteria. Write them in Given-When-Then format:

Given [context/precondition]
When [action/trigger]
Then [expected outcome]

Edge case checklist - for each rule, systematically consider:

Example: PRD says "User can search products"

Rules identified: (1) Search by title, (2) Pagination, (3) Empty state

For Rule 1 alone, edge case thinking yields:

• Given products exist → When search → Then results (happy path)
• Given no matches → When search → Then empty set
• Given empty search term → When submit → Then validation error OR all products? (🔴 Question!)
• Given special chars in search → When search → Then handled safely

Splitting Signals (Task Too Big)

If ANY of these are true, STOP and split:

• ❌ Can't describe in a specific, action-oriented title
• ❌ Would take more than 1 day
• ❌ Title requires "and" or lists multiple things
• ❌ Has multiple clusters of acceptance criteria
• ❌ Cuts horizontally (all DB, then all API, then all UI)
• ❌ PRD calls it "full implementation" or "complete system"

SPIDR Splitting Techniques

When you need to split, use these techniques:

Vertical Slices Only

Every task must be a vertical slice—cutting through all layers needed for ONE specific thing:

✅ VERTICAL (correct):
"Add search by title" → touches UI + API + DB for ONE search type

❌ HORIZONTAL (wrong):
"Build search UI" → "Build search API" → "Build search DB"

Task Naming

Formula

[Action verb] [specific object] [outcome/constraint]

Good Names

• "Add price range filter to product search"
• "Implement POST /api/users endpoint with email validation"
• "Display product recommendations on home page"
• "Enable CSV export for transaction history"
• "Validate required fields on checkout form"

Rejected Patterns

🚨 NEVER use these—they signal an epic, not a task:

If you catch yourself writing one of these, STOP and apply SPIDR.

Task Size Validation (INVEST)

Every task MUST pass INVEST before creation:

Hard Limits

• Max 1 day of work - if longer, split it
• Must be vertical - touches all layers for ONE thing
• Must be demoable - when done, you can show it working

Task Template

See .tasks/_template.md for the full template. Key sections:

---