paca
Paca integrates Anthropic's Model Context Protocol to enable direct task and project management within Paca, a work-tracking system. Use this skill for creating, updating, viewing, and completing tasks, managing sprints, writing documentation, and handling work-item operations. For complex workflows like epic creation, sprint planning, task clarification, or end-to-end execution, the interface routes users to specialized `/paca-` commands that provide structured assistance beyond basic CRUD operations.
git clone --depth 1 https://github.com/Paca-AI/paca /tmp/paca && cp -r /tmp/paca/skills/paca ~/.claude/skills/pacaSKILL.md
You have Paca MCP tools. Handle the request by using those tools directly — never create local files for tasks, docs, or to-do lists.
---
## Step 0 — Route to a specialized skill if appropriate
If the request clearly matches one of these, let the user know — they'll get a better result with the specialized skill:
| If the user wants to... | Suggest |
|---|---|
| Turn requirements into a full epic with child stories | `/paca-epic <requirements>` |
| Clarify or improve a vague task or spec | `/paca-clarify #<number>` |
| Break a task into smaller sub-tasks | `/paca-breakdown #<number>` |
| Plan a sprint from the backlog | `/paca-sprint` |
| Estimate story points for tasks | `/paca-estimate #<number>` |
| Set priorities across the backlog | `/paca-prioritize` |
| Execute a task end-to-end | `/paca-do #<number>` |
| Test or verify a task | `/paca-test #<number>` |
| Write or update documentation | `/paca-doc #<number>` |
If it's a simple or mixed request (e.g. "create a task for X", "what's in the sprint", "mark #7 done"), just handle it directly below.
---
## Step 1 — Scan for a task reference
Scan the user's message for any of these patterns, wherever they appear:
| Pattern | Example | How to resolve |
|---|---|---|
| `#<number>` or number in task context | `#42`, `close #7`, `task 42 is done` | `get_task_by_number(projectId, 42)` |
| `PREFIX-<number>` | `ABC-42`, `PAC-7` | `list_projects` → match `task_id_prefix` → `get_task_by_number` |
| Paca URL | `http://…/projects/{id}/tasks/{id}` | parse both IDs → `get_task(projectId, taskId)` |
| UUID | `550e8400-e29b-41d4-a716-446655440000` | `get_task(projectId, uuid)` |
If a reference is found, fetch that task first, then apply the action the user is asking for.
## Step 2 — Infer the action
| What the user wants | Tools to use |
|---|---|
| Track work — bug, feature, to-do, ticket, chore | `create_task` / `update_task` / `list_tasks` |
| Write content — guide, spec, design, BDD, SDD, notes | `create_document` / `update_document` |
| See status — board, sprint, what's in progress | `list_sprints` + `list_tasks` |
| Plan an iteration — sprint, milestone | `create_sprint` / `update_sprint` |
| Comment or annotate an existing task | `add_task_comment` |
| Close / complete work | `update_task` (set to done status) |
| Break work into pieces | `create_task` × N, each referencing the parent |
| Write or update documentation | `create_document` / `update_document` |
## Step 3 — Get the project if needed
If no project is in context, call `list_projects` and pick the most relevant one based on the message. Only ask the user if it is genuinely ambiguous between two equally plausible candidates.
## Step 4 — Act and confirm
Execute the tool call(s), then report back: task/doc number, title, and any relevant ID or link.
---
## Examples
| User message | What you do |
|---|---|
| `fix login redirect bug` | `create_task` titled "Fix login redirect bug" |
| `write the API authentication design doc` | `create_document` with a structured draft |
| `do this task ABC-123` | find project "ABC" → `get_task_by_number(123)` → start/act on task |
| `close #42` | `get_task_by_number(42)` → `update_task` status: done |
| `I finished PAC-99, mark it done` | `update_task` #99 → status: done |
| `http://…/tasks/uuid — add comment: blocked` | `get_task` from URL → `add_task_comment` "blocked" |
| `what's in the current sprint?` | `list_sprints` → `list_tasks` filtered to active sprint |
| `review PR, update staging, write release notes` | `create_task` × 3, one per item |
---
## If Paca MCP is not connected
> Paca MCP tools are not available. Run `/paca-setup` to configure the connection.
Do not create local files as a fallback.
---
## Tool reference
**Tasks:** `create_task` · `list_tasks` · `get_task` · `get_task_by_number` · `update_task` · `delete_task`
**Documents:** `create_document` · `list_documents` · `get_document` · `update_document` · `delete_document`
**Sprints:** `create_sprint` · `list_sprints` · `get_sprint` · `update_sprint` · `complete_sprint`
**Projects:** `list_projects` · `get_project` · `create_project` · `update_project`
**Comments:** `add_task_comment` · `update_task_comment` · `list_task_activities`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.