paca-doc
**paca-doc** writes or updates documentation in Paca Docs for completed features, guides, runbooks, specs, and BDD scenarios. Use it when asked to document a finished task, create architecture or design documents, or produce acceptance criteria. The skill loads project context from task details and related documentation, identifies the appropriate doc type, and saves the content directly to Paca rather than creating local files.
git clone --depth 1 https://github.com/Paca-AI/paca /tmp/paca-doc && cp -r /tmp/paca-doc/skills/paca-doc ~/.claude/skills/paca-docSKILL.md
You are writing or updating documentation in Paca Docs. Documentation lives in Paca — never create local files for docs.
**If no task or topic is specified**, call `list_tasks` for recently completed tasks that have no linked document, and ask the user which feature to document.
---
## Step 1 — Load project context
1. Resolve any reference from the user's message:
- `#42`, `ABC-42` → `get_task_by_number` to read the feature being documented
- Doc title or ID → `list_documents` → `get_document` to load the existing doc
- Free-text topic → `list_documents` first to verify no duplicate already exists; if a similar doc is found, offer to update it instead of creating a new one
2. Call `list_documents` and read related docs — architecture, existing guides, BDD scenarios, API references. Matching the existing tone, structure, and terminology matters more than any individual stylistic choice.
3. If documenting a task, call `get_task` + `list_task_activities` to read the implementation details and any design decisions recorded in comments — these are often the most valuable content to capture.
## Step 2 — Identify doc type and draft outline
Based on context, identify the type:
- **Guide / tutorial** — step-by-step, outcome-oriented, written for someone doing it for the first time
- **Reference** — exhaustive API, config, or CLI reference
- **Architecture / design doc** — decisions, tradeoffs, diagrams (as Markdown)
- **BDD / acceptance spec** — Gherkin-style scenarios
- **Runbook** — operational steps for a known procedure
If the type is obvious from the task or request, proceed directly. Only ask the user to confirm the outline when the type is genuinely unclear or the scope is large.
## Step 3 — Write the documentation
Write complete, clear Markdown:
- Active voice and present tense
- Code examples and command snippets where they aid understanding
- Link to related Paca docs by title or task number
- No "last updated" timestamps, no "Created by Claude" lines — Paca tracks history
- No placeholder sections ("TBD", "coming soon") — write real content or omit the section
## Step 4 — Save to Paca
- **New document**: call `create_document` with the title and full Markdown content. Call `list_doc_folders` first to find the right folder; use `create_doc_folder` if none fits.
- **Existing document**: call `update_document`. Integrate new content with the existing structure rather than appending everything at the end.
- If the doc is tied to a task, call `add_task_comment` on that task linking to the doc (e.g. "Documentation written: [link]").
Report back: document title, the folder it was saved in, and the document ID.
---
## If Paca MCP is not connected
> Paca MCP tools are not available. Run `/paca-setup` to configure the connection.
---
## Tool reference
**Documents:** `create_document` · `update_document` · `get_document` · `list_documents` · `list_doc_folders` · `create_doc_folder`
**Tasks:** `get_task` · `get_task_by_number` · `list_task_activities`
**Comments:** `add_task_comment`
**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.
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.
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.