paca-sprint
paca-sprint is a Claude Code skill for planning sprints within the Paca project management system. It loads project context and past sprint data, detects tasks carried over from previous sprints, calculates team velocity from completed work, ranks backlog tasks by priority and dependencies, and assigns selected tasks to an upcoming sprint while ensuring capacity alignment. Use it when starting a new sprint, reviewing sprint capacity, setting sprint goals, or filling an upcoming sprint with properly estimated work.
git clone --depth 1 https://github.com/Paca-AI/paca /tmp/paca-sprint && cp -r /tmp/paca-sprint/skills/paca-sprint ~/.claude/skills/paca-sprintSKILL.md
You are planning a sprint in Paca. Use Paca MCP tools throughout — never create local files. **If no sprint is specified**, default to planning the next upcoming sprint for the most active project. --- ## Step 1 — Load project context 1. Call `list_projects` and identify the relevant project. 2. Call `list_documents` and search for documents with keywords like "roadmap", "goals", "OKR", "retrospective", or "planning". Read the most relevant ones with `get_document`. What the last sprint achieved and what the project's current goals are will shape which tasks belong in this sprint. 3. Call `list_sprints` to see existing sprints (active, upcoming, completed). 4. Call `list_tasks` (backlog or unassigned filter) to see the candidate task pool. ## Step 2 — Detect carryover and infer velocity **Carryover:** Check the most recently completed sprint for tasks that were in it but are still open (status is not done). Flag these — carryover tasks typically get priority in the next sprint. **Velocity:** Look at the last 2–3 completed sprints. Sum the story point estimates of tasks that were marked done. Use the average as the default capacity if the user hasn't stated one. ## Step 3 — Determine sprint parameters From the user's message and context: - **Which sprint** — by number, name, or "next sprint" - **Capacity** — story points available; use inferred velocity as the default, ask to confirm - **Goal** — what outcome the sprint should deliver; infer from the roadmap or ask - **Duration** — start/end dates; infer from the cadence of past sprints or ask ## Step 4 — Select tasks Rank backlog tasks and recommend a set that fits within capacity: - **First**: carryover tasks from the previous sprint - **Then**: tasks ranked by explicit priority → unblocking dependencies → business value → estimate size - **Flag**: tasks missing estimates or acceptance criteria — offer to run `/paca-estimate` or `/paca-clarify` on them before committing Present the proposed list with a total estimated points and the sprint goal. Ask the user to confirm, swap, or adjust before applying. ## Step 5 — Apply the plan Once confirmed: 1. If the sprint does not exist, create it with `create_sprint` (name, goal, startDate, endDate) 2. Assign each task to the sprint with `update_task` (set `sprintId`) 3. Set or update the sprint goal with `update_sprint` Optionally create or update a sprint planning note in Paca Docs (`create_document` / `update_document`) with the sprint goal, task list, capacity, and velocity reference. Report back: sprint name, dates, task count, total estimate, capacity used, and sprint goal. --- ## If Paca MCP is not connected > Paca MCP tools are not available. Run `/paca-setup` to configure the connection. --- ## Tool reference **Sprints:** `list_sprints` · `get_sprint` · `create_sprint` · `update_sprint` · `complete_sprint` **Tasks:** `list_tasks` · `get_task` · `update_task` · `bulk_move_tasks` **Documents:** `list_documents` · `get_document` · `create_document` · `update_document` **Projects:** `list_projects`
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.
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.