paca-breakdown
GitHub将大型Paca任务或史诗分解为可执行、有依赖顺序的子任务。通过分析技术背景和验收标准,优先推荐垂直切片,确保每个子任务可在1-2天内完成,并在创建前征求用户确认,最终在Paca系统中生成结构化子任务。
Trigger Scenarios
Install
npx skills add Paca-AI/paca --skill paca-breakdown -g -y
SKILL.md
Frontmatter
{
"name": "paca-breakdown",
"description": "Break a large Paca task or epic into smaller, actionable sub-tasks with dependency ordering. Use when decomposing work that is too large to estimate or execute in a single session, when creating an implementation plan, or when a task needs to be split into vertical slices before sprint planning.",
"compatibility": "Requires Paca MCP server. Run \/paca-setup if Paca tools are not available."
}
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
- Resolve the task reference from the user's message using
get_task_by_numberorget_task. - Call
list_documentsand 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. - Call
list_task_typesandlist_task_statusesto know available types and statuses. - Call
list_tasksto 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-setupto 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
Version History
- 1a37f10 Current 2026-07-05 14:57


