Create Tasks

Creates well-formed tasks that provide large amounts of contexts so that engineers that weren't in conversations can implement the task without any prior knowledge and without asking questions.

Tasks should be created using the tools and documentation conventions in the project the skills is being applied to. If the conventions are not clear, ask the user to clarify and then document them.

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 Check

Before writing any task, mentally apply Example Mapping:

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

## Deliverable: [What user/stakeholder sees]

### Context
[Where this came from and why it matters. PRD reference, bug report, conversation summary—whatever helps engineer understand WHY. You MUST provide the specific file path or URL for any referenced files like a PRD of bug report - don't assume the engineer knows where things are stored]

### Key Decisions and principles
- [Decision/Principle] — [rationale]

### Delivers
[Specific outcome in user terms]

### Acceptance Criteria
- [Condition] → [expected result]

### Dependencies
- [What must exist first]

### Related Code
- `path/to/file` — [what pattern/code to use]

### Verification
[Specific commands/tests that prove it works]

Process

1. Slice first — Apply Example Mapping check. If task fails any splitting signal, use SPIDR to break it down before proceeding.
2. Name it — Write a specific, action-oriented title. If you can't, the task isn't clear enough.
3. Validate size — Must pass INVEST. Max 1 day. Must be vertical slice.
4. Gather context (from PRD, conversation, bug report, etc.)
5. Identify key decisions that affect implementation
6. Define clear acceptance criteria
7. Find related code/patterns in the codebase
8. Specify verification commands
9. Output task using template

Checkpoint

Before finalizing any task, verify ALL of these:

🚨 If the PRD says "full implementation" or similar, you MUST split it. Creating such a task is a critical failure.