Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From loaf
Decomposes specifications into atomic tasks with dependencies and priorities. Use when the user asks "break this down" or "create tasks for this spec." Produces task files with estimates, dependencies, and acceptance criteria. Not for shaping idea...
npx claudepluginhub levifig/loafHow this skill is triggered — by the user, by Claude, or both
Slash command
/loaf:breakdownThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Decompose specifications into atomic, implementable tasks.
Decomposes specs into ordered, verifiable tasks with acceptance criteria using vertical slicing and dependency graphs. Use for large tasks, scope estimation, or parallel agent work.
Convert technical designs into actionable, tracked task hierarchies with sizing, dependencies, and acceptance criteria. Invoke whenever task involves any interaction with work decomposition — breaking down features into subtasks, slicing work items, creating task lists, or writing decomposition documents.
Extracts lightweight milestones from spec.md into a separate tasks.md for complex dependency management, parallel work lines, and cross-agent tasking. Only activates after spec is confirmed and execution needs coordination beyond simple sprints.
Share bugs, ideas, or general feedback.
Decompose specifications into atomic, implementable tasks.
Input: $ARGUMENTS
implementing after tasks are createdimplementing| Priority | Meaning |
|---|---|
| P0 | Urgent/blocking -- drop everything |
| P1 | High -- work next |
| P2 | Normal -- scheduled work (default) |
| P3 | Low -- when time permits |
| Rule | Guideline |
|---|---|
| One agent type | Completable by a single implementer (after skills narrowing) |
| One concern | Touches one layer, service, or component |
| Context-appropriate | Fits in model context with room for exploration |
| Not over-fragmented | Don't split what naturally belongs together |
Primary principle: separation of concerns.
| Don't | Do Instead |
|---|---|
| Split backend + tests into separate tasks | Keep tests with the code they test |
| Create a task per file | Group files by concern |
| Separate "implement" and "verify" tasks | Every task includes its own verification |
Check .agents/loaf.yaml:
task_management:
backend: linear # or "local"
If no config exists, ask user.
$ARGUMENTS should reference a spec (e.g., "SPEC-001"). If unclear, list available specs.
Extract: test conditions, scope, implementation notes, appetite.
Break down by concern (data layer, backend, frontend, infrastructure, etc.). One concern per task. Explicit dependencies for sequential tasks.
Own the granularity and priority decisions. Apply the Right Size Test, assign priorities based on dependencies and circuit breaker alignment, and do a self-review pass. Do not defer these decisions to the user — they trust agent judgment here.
If genuinely uncertain (e.g., two equally valid orderings with different trade-offs), ask. Otherwise, decide and move on.
Create tasks following task template. Each task needs: clear title, priority, file hints, verification command, observable done condition.
Show the dependency graph and task summary for awareness, then create the tasks. Present it as "here's what I'm creating" not "which option do you prefer?" The user can still adjust after creation, but the default is to proceed.
If integrations.linear.enabled is true in .agents/loaf.json: create Linear issues with title, description, labels, priority (Linear MCP).
Otherwise: use loaf task create --spec SPEC-XXX --title "Task title" --priority P1 for each task. The CLI creates the TASKS.json entry and .md skeleton file. Then edit the .md body content (description, acceptance criteria) directly.
Set spec status to implementing. Announce created tasks with next steps.