| name | paca-do |
| description | 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. |
| compatibility | Requires Paca MCP server. Run /paca-setup if Paca tools are not available. |
You are executing a task from Paca — reading it, understanding context, doing the work, and updating the record. Use Paca MCP tools throughout — never create local files for task records or documentation.
If no task is specified, call list_tasks filtered to in-progress tasks in the current sprint. Show them and ask which to work on.
Step 1 — Load task and project context
- Resolve the task reference from the user's message using
get_task_by_number or get_task.
- If the task has no acceptance criteria, stop and ask the user to clarify before starting — or offer to run
/paca-clarify first. Starting work without a clear "done" condition wastes effort.
- Call
list_documents and search for documents relevant to this task — architecture, design specs, BDD scenarios, API references, integration guides. Read before writing any code or content; what's already decided shapes every implementation choice.
- Call
list_task_activities to read prior comments and implementation notes — someone may have already investigated this.
- Note the acceptance criteria from the task description. These are your exit criteria.
Step 2 — Mark in progress
- Call
list_task_statuses to find the "in progress" status.
- Call
update_task to set the status. (No confirmation needed — this is a lightweight, reversible status change.)
- Call
add_task_comment: "Starting work on this task."
Step 3 — Do the work
Execute based on the task type:
- Code task: find the relevant source files, read existing tests to understand the expected behavior, implement the change, run the test suite. If you need to understand what "in scope" looks like, the BDD scenarios you read in Step 1 are authoritative.
- Writing task: draft the content in the response, or create/update a Paca document via
create_document / update_document. Never write to a local file.
- Research / investigation task: investigate, write findings as a comment via
add_task_comment or as a Paca doc, then update the task description with the conclusions.
- Review task: analyse the artifact (PR, document, design), post a structured review as
add_task_comment.
If you discover a blocker or a genuine sub-task that wasn't anticipated, create it in Paca with create_task (reference the parent: Blocked by #<parent>). Don't silently skip or work around it.
Step 4 — Update and close
- Call
add_task_comment with a completion summary: what was done, what changed, any known caveats or follow-up needed.
- If any project documentation was affected (README, architecture doc, API reference), update the relevant Paca document with
update_document. Never write new docs as local files.
- Call
update_task to set the status to done (or the next stage — e.g. "review" — if your workflow has one).
What's next: Consider running /paca-test #<number> to verify the implementation against acceptance criteria.
Report back: task number, title, summary of what was done, and any new tasks or docs created.
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 · update_task · create_task · list_task_statuses
Comments: add_task_comment · list_task_activities
Documents: list_documents · get_document · update_document · create_document
Projects: list_projects
