Use this skill when creating tasks for implementer agents. Trigger on: - Task creation: "break into tasks", "task list", "what are the steps" - Sizing concerns: "task too big", "how many files", "is this too much", "too complex" - Implementer workflow: "for implementer", "implementer agent", "subagent tasks" - Verification: "how to verify", "testing strategy", "validation" Provides hard limits and patterns for sizing tasks that implementers can execute in fresh context.
This skill inherits all available tools. When active, it can use any tool Claude has access to.
Guidance for breaking milestones into tasks that implementer agents can execute successfully.
Implementers work in fresh context with no accumulated knowledge. They need:
Too large: Context bloat, errors, incomplete work Too small: Excessive overhead Just right: Focused change, clear verification, clean commit
Each task must respect these constraints:
| Dimension | Limit | Rationale |
|---|---|---|
| Files modified | 5 max | More = context overload |
| Logical changes | ~15 | More = hard to verify |
| New abstractions | 1 | More = architectural complexity |
| Lines of code | ~500 | More = review fatigue |
If a task exceeds limits: Split it.
### Task N: [Descriptive Name]
**Files to modify:**
- `path/to/file1.ext` - [what changes]
- `path/to/file2.ext` - [what changes]
**Changes:**
1. [Specific change with file/location]
2. [Specific change with file/location]
**Verification:**
- `npm test path/to/test`
- `npm run lint`
**Exit criteria:**
- [ ] All changes made
- [ ] Tests pass
- [ ] Lint passes
**Commit message:**
type(scope): brief description
Critical: Every task includes its commit message.
Why: Forces clarity about single responsibility, helps implementer understand intent.
Good: feat(auth): add JWT token validation middleware
Bad: fix stuff, WIP, update files
Too many files (12 → 3 tasks):
Too many changes (40 → 3 tasks):
Too many abstractions (3 → 3 tasks):
Order tasks within a milestone by:
Dependency order: Interfaces → implementations, models → controllers Risk order: Experimental work first (fail fast) Verification order: Test infrastructure before features
Every task specifies both automated and manual verification:
Automated: npm test, npm run lint, npm run build
Manual: "Load /path and verify X", "Call endpoint, expect Y"
Right-sized:
Too large:
Too small:
/milestone-planning - Breaking work into milestones/agile-workflow - Overall methodology/context-health - Why fresh context matters