菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | paca-estimate |
| description | 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. |
| compatibility | Requires Paca MCP server. Run /paca-setup if Paca tools are not available. |
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.
#42, ABC-42 → get_task_by_numberlist_tasks; focus on unestimated taskslist_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.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.For each task, call get_task and reason through four dimensions:
Scale (Fibonacci): 1 · 2 · 3 · 5 · 8 · 13
/paca-breakdown would reduce riskCalibrate 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.
For each confirmed estimate, call update_task:
**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)Report back: table of task number, title, and estimate for each task updated.
Paca MCP tools are not available. Run
/paca-setupto configure the connection.
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.