paca-breakdown
The paca-breakdown skill decomposes large tasks or epics in Paca into smaller, ordered sub-tasks by analyzing technical layers, identifying vertical slices, and proposing dependencies. Use it when a task is too large to estimate or complete in one session, when planning implementation strategy, or when splitting work into sprintable pieces before development begins.
git clone --depth 1 https://github.com/Paca-AI/paca /tmp/paca-breakdown && cp -r /tmp/paca-breakdown/skills/paca-breakdown ~/.claude/skills/paca-breakdownSKILL.md
You are breaking a task or epic into smaller, actionable sub-tasks in Paca. Use Paca MCP tools throughout — never create local files.
**If no task is specified**, call `list_tasks` filtered to the current sprint or backlog and show the user the largest or most complex unbroken tasks as candidates.
---
## Step 1 — Load project context
1. Resolve the task reference from the user's message using `get_task_by_number` or `get_task`.
2. Call `list_documents` and read documents that explain the technical landscape — architecture, design decisions, BDD scenarios, API specs. Understanding the tech stack and boundaries is essential to find the right split points.
3. Call `list_task_types` and `list_task_statuses` to know available types and statuses.
4. Call `list_tasks` to see what already exists, so you don't propose sub-tasks that duplicate open work.
## Step 2 — Analyse the task
Read the task title, description, and acceptance criteria. Identify:
- Technical layers involved (frontend, backend, database, infra, tests, docs)
- External dependencies or blockers to flag
- Natural vertical slices (end-to-end thin features) vs. horizontal layers — **prefer vertical slices**
- Any parts that are risky or uncertain and should be isolated as their own sub-task (unknown = own task)
## Step 3 — Propose the breakdown
Present a numbered list of proposed sub-tasks. For each:
- **Title** — clear, imperative ("Add rate-limiting middleware", not "Rate limiting")
- **Size** — fits in 1–2 days
- **Done condition** — one sentence on what "done" looks like
- **Depends on** — note any sub-tasks that must be completed first (e.g. "Depends on #3 above")
Ask the user to confirm, adjust, or remove items before creating anything. This is especially important if the list has more than 6 items.
## Step 4 — Create sub-tasks
For each confirmed sub-task, call `create_task`:
- Reference the parent in the description: `Part of #<parent-number>`
- Include the done condition as the acceptance criteria
- Note any dependencies: `Blocked by #<sibling-number>` if one sub-task must precede another
- Assign to the same sprint as the parent if one exists (check with `list_sprints`)
**What's next:** Consider running `/paca-estimate` on the newly created sub-tasks to add story points.
Report back: parent task number, list of created sub-task numbers, titles, and any dependency chain noted.
---
## If Paca MCP is not connected
> Paca MCP tools are not available. Run `/paca-setup` to configure the connection.
---
## Tool reference
**Tasks:** `get_task` · `get_task_by_number` · `list_tasks` · `create_task` · `update_task` · `list_task_types` · `list_task_statuses`
**Documents:** `list_documents` · `get_document`
**Sprints:** `list_sprints`
**Projects:** `list_projects`Clarify a vague or incomplete Paca task or specification by identifying ambiguities, asking targeted questions, and rewriting the description with explicit acceptance criteria. Use when a task is unclear, missing edge cases, lacks a testable done condition, or when someone asks to improve or flesh out a spec.
Execute a Paca task end-to-end — reading context and acceptance criteria, doing the work (code, writing, research, review), updating task status, and commenting results. Use when asked to start, implement, complete, or work on a specific Paca task. Reads project docs first to understand the codebase and tech stack before acting.
Write or update documentation for a feature, task, or topic in Paca Docs. Use when asked to document a completed feature, write a guide or runbook, update existing docs, create a spec or architecture document, or produce BDD scenarios. Documentation is saved in Paca — never created as local files.
Turn a product requirement or feature description into a structured epic in Paca, with child user stories and a spec document. Use when asked to plan a new feature, break down a high-level requirement into stories, create an epic, or go from "we need X" to a fully structured backlog ready for sprint planning.
Estimate story points for Paca tasks using the Fibonacci scale, calibrated against recently completed reference tasks and project tech stack. Use when tasks are missing estimates, before sprint planning, when the team needs sizing for prioritization, or when asked to size a backlog.
Set or adjust priorities across the Paca backlog, aligned to roadmap goals and business value. Use when the backlog needs sorting, before sprint planning, when tasks need explicit Critical/High/Medium/Low priority labels, or when asked to rank work by importance or urgency.
Configure the Paca MCP server for use with Claude Code or Claude Desktop. Use when setting up Paca for the first time, adding or editing the MCP server config, troubleshooting connectivity, or installing the Paca skills globally. Walks the user through prerequisites, config file generation, verification, and optional global skill install.