paca-estimate
paca-estimate sizes Paca tasks using the Fibonacci scale (1, 2, 3, 5, 8, 13 points) by analyzing implementation complexity, uncertainty, test surface, and integration points against recently completed reference tasks and project documentation. Use it before sprint planning, when tasks lack estimates, or when the team needs sizing for backlog prioritization.
git clone --depth 1 https://github.com/Paca-AI/paca /tmp/paca-estimate && cp -r /tmp/paca-estimate/skills/paca-estimate ~/.claude/skills/paca-estimateSKILL.md
You are estimating effort for tasks in Paca. Use Paca MCP tools throughout — never create local files. **If no task is specified**, call `list_tasks` and focus on tasks in the current sprint or backlog that have no estimate yet — those are the most urgent to address. --- ## Step 1 — Load project context 1. Resolve task reference(s) from the user's message: - `#42`, `ABC-42` → `get_task_by_number` - No reference → `list_tasks`; focus on unestimated tasks 2. Call `list_documents` and search for documents titled or tagged with "estimation", "velocity", "definition of ready", "tech stack", or "architecture". Read the most relevant ones with `get_document`. Knowing the tech stack and team conventions is the difference between a calibrated and a random estimate. 3. Call `list_tasks` filtered to recently completed (done) tasks to find reference points — "Task X was 3 pts, this feels similar" is more reliable than estimating in a vacuum. ## Step 2 — Estimate each task For each task, call `get_task` and reason through four dimensions: - **Implementation complexity** — number of layers touched, algorithmic difficulty - **Uncertainty** — how well-understood the work is; unknown → estimate higher - **Test surface** — unit tests, integration tests, edge cases to cover - **Integration points** — external APIs, databases, other services, third-party SDKs **Scale (Fibonacci):** 1 · 2 · 3 · 5 · 8 · 13 - **1–2 pts**: simple, well-understood, < 1 day - **3–5 pts**: moderate complexity or some unknowns, 1–3 days - **8 pts**: complex or high uncertainty — consider whether `/paca-breakdown` would reduce risk - **13 pts**: too large to estimate reliably — strongly recommend breaking down first Calibrate against the reference tasks you found: if a reference task was 3 pts and this one feels about twice as hard, say 5–8 pts. Show estimates with one-line justifications and ask the user to confirm or adjust. ## Step 3 — Write estimates back For each confirmed estimate, call `update_task`: - Prepend `**Estimate:** N pts` as the first line of the description (or update the custom field if the project has one — check `list_custom_fields` to see) - Include a one-line rationale so the reasoning is preserved Report back: table of task number, title, and estimate for each task updated. --- ## 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` · `update_task` · `list_task_statuses` · `list_custom_fields` **Documents:** `list_documents` · `get_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.
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.