Paca-AI/paca

You are breaking a task or epic into smaller, actionable sub-tasks in Paca. Use Paca MCP tools throughout — never create local files.

If no task is specified, call list_tasks filtered to the current sprint or backlog and show the user the largest or most complex unbroken tasks as candidates.

Step 1 — Load project context

1. Resolve the task reference from the user's message using get_task_by_number or get_task.
2. Call list_documents and read documents that explain the technical landscape — architecture, design decisions, BDD scenarios, API specs. Understanding the tech stack and boundaries is essential to find the right split points.
3. Call list_task_types and list_task_statuses to know available types and statuses.
4. Call list_tasks to see what already exists, so you don't propose sub-tasks that duplicate open work.

Step 2 — Analyse the task

Read the task title, description, and acceptance criteria. Identify:

• Technical layers involved (frontend, backend, database, infra, tests, docs)
• External dependencies or blockers to flag
• Natural vertical slices (end-to-end thin features) vs. horizontal layers — prefer vertical slices
• Any parts that are risky or uncertain and should be isolated as their own sub-task (unknown = own task)

Step 3 — Propose the breakdown

Present a numbered list of proposed sub-tasks. For each:

• Title — clear, imperative ("Add rate-limiting middleware", not "Rate limiting")
• Size — fits in 1–2 days
• Done condition — one sentence on what "done" looks like
• Depends on — note any sub-tasks that must be completed first (e.g. "Depends on #3 above")

Ask the user to confirm, adjust, or remove items before creating anything. This is especially important if the list has more than 6 items.

Step 4 — Create sub-tasks

For each confirmed sub-task, call create_task:

• Reference the parent in the description: Part of #<parent-number>
• Include the done condition as the acceptance criteria
• Note any dependencies: Blocked by #<sibling-number> if one sub-task must precede another
• Assign to the same sprint as the parent if one exists (check with list_sprints)

What's next: Consider running /paca-estimate on the newly created sub-tasks to add story points.

Report back: parent task number, list of created sub-task numbers, titles, and any dependency chain noted.

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 · create_task · update_task · list_task_types · list_task_statuses
Documents: list_documents · get_document
Sprints: list_sprints
Projects: list_projects

You are clarifying a task or specification in Paca. Use Paca MCP tools throughout — never create local files.

If no task is specified, call list_tasks and surface tasks that have no acceptance criteria or have a very short description — those are the best candidates for clarification. Present them and ask which to work on.

Step 1 — Load project context

1. Resolve the target from the user's message:
   • #42 or ABC-42 → get_task_by_number
   • Paca URL → parse IDs → get_task or get_document
   • Doc title / keyword → list_documents → get_document
   • If the task or document is not found, tell the user clearly ("Task #99 was not found in project X") and ask them to verify the reference.
2. Call list_documents and read documents that provide context for this task — requirements, architecture, BDD scenarios, prior decisions. Reading broadly here means you won't ask questions the docs already answer.
3. If it's a task, call list_task_activities to read prior comments, decisions, and any clarifications already given.

Step 2 — Identify ambiguities

Read the task description or document carefully and find:

• Scope gaps — what is in vs. out is not stated
• Missing edge cases — error states, empty states, permission boundaries, concurrency
• Undefined terms — domain words that could mean different things in this codebase
• Unstated assumptions — things the author assumed but did not write down
• Acceptance criteria gaps — no measurable, testable "done" condition

Only surface real ambiguities. Skip things that are clearly inferable from context or docs you just read.

Step 3 — Ask clarifying questions

Present a numbered list of at most 6 questions, grouped by theme (scope / edge cases / definitions). Err on the side of fewer, better questions over many shallow ones. Wait for the user's answers before writing anything back.

Example format:

**Scope**
1. Should this cover X, or is X a separate initiative?
2. Does this apply to guest users, or only authenticated users?

**Edge cases**
3. What should happen when Y is empty?

**Acceptance criteria**
4. What does "success" look like — a UI state, an API response, something else?

Step 4 — Update the spec in Paca

Once the user answers:

• Task: call update_task with an improved description including explicit acceptance criteria. Don't just append — rewrite the description so it stands alone without this conversation.
• Document: call update_document with the resolved content and any new decisions recorded as a "Decisions" section.

Do not create a new document — update the existing one.

Report back: what was clarified and the task/doc number and title that was 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 · update_task · list_tasks
Comments: list_task_activities
Documents: get_document · update_document · list_documents
Projects: list_projects

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

1. Resolve the task reference from the user's message using get_task_by_number or get_task.
2. 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.
3. 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.
4. Call list_task_activities to read prior comments and implementation notes — someone may have already investigated this.
5. Note the acceptance criteria from the task description. These are your exit criteria.

Step 2 — Mark in progress

1. Call list_task_statuses to find the "in progress" status.
2. Call update_task to set the status. (No confirmation needed — this is a lightweight, reversible status change.)
3. 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

1. Call add_task_comment with a completion summary: what was done, what changed, any known caveats or follow-up needed.
2. 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.
3. 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

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

You are turning requirements into a structured epic in Paca. Use Paca MCP tools throughout — never create local files.

If no requirement is specified, ask: "What requirement or feature do you want to turn into an epic? Describe it in a sentence or two."

Step 1 — Load project context

1. Call list_projects to identify the relevant project (infer from the user's message, or ask if ambiguous).
2. Call list_documents and search for documents whose titles or descriptions suggest requirements, roadmap, architecture, or BDD scenarios. Read the most relevant ones with get_document. Understand the domain and existing feature landscape before writing anything.
3. Call list_task_types to check whether an "Epic" type exists.
4. Call list_task_statuses to know available statuses.
5. Call list_tasks to scan for existing epics so you avoid duplicating scope.

Step 2 — Parse the requirements

Extract from the user's message:

• Goal — what user or business outcome this achieves
• Scope — what is in / out of scope
• Stakeholders — who benefits, who owns
• Constraints — tech, time, dependencies

If requirements are vague, ask at most 3 targeted questions before proceeding. Focus on what you genuinely cannot infer. Good question templates:

• "Who is the primary user of this feature, and what problem does it solve for them?"
• "Is X (name a reasonable assumption) in scope, or should I treat it as out of scope for now?"
• "Are there existing systems or services this needs to integrate with?"

Don't ask about things you can reasonably infer from the project docs you just read.

Step 3 — Create the epic task

Call create_task:

• Type: "Epic" if available from list_task_types; otherwise a standard task clearly titled as an epic
• Title: concise, outcome-oriented (e.g. Epic: User Authentication)
• Description (Markdown):

  ## Goal
  <one paragraph>
  
  ## Scope
  **In:** ...
  **Out:** ...
  
  ## Acceptance Criteria
  - [ ] ...
  
  ## Open Questions
  - ...
  

Step 4 — Break into stories

Derive child tasks from the requirements. Aim for 3–8 stories for a typical epic; go higher if the scope is large, but confirm with the user before creating more than 10. For each story:

• Call create_task with a clear title, brief description, and 2–3 acceptance criteria
• Reference the parent epic in the description: Part of #<epic-number>
• Prefer vertical slices (end-to-end thin features) over horizontal layers (all-backend, all-frontend)

Step 5 — Create a spec document

Call create_document:

• Title: Epic: <name> — Specification
• Content: Goal · Background · User Stories (linked by #number) · Acceptance Criteria · Out of Scope · Open Questions

What's next: After this, consider running /paca-estimate #<epic-number> to add story point estimates to the new tasks, and /paca-sprint to plan them into a sprint.

Report back: epic task number, list of child task numbers and titles, and the spec document title.

If Paca MCP is not connected

Paca MCP tools are not available. Run /paca-setup to configure the connection.

Tool reference

Tasks: create_task · update_task · list_tasks · get_task_by_number · list_task_types · list_task_statuses
Documents: create_document · list_documents · get_document
Projects: list_projects · get_project

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

You are setting priorities for tasks in Paca. Use Paca MCP tools throughout — never create local files.

If no task is specified, operate on the full backlog of the most active project.

Step 1 — Load project context

1. Resolve task references from the user's message if given (#42, ABC-42 → get_task_by_number). If no references, operate on the full backlog.
2. Call list_documents and search for documents titled "roadmap", "goals", "OKR", "strategy", or "release plan". Read the most relevant ones with get_document. Priority without a goal to align to is just opinion — the docs anchor your reasoning.
   • If no strategy docs exist, ask the user: "What are the top 3 outcomes you're trying to achieve this quarter?" Use their answer as the alignment anchor.
3. Call list_tasks to load the full task set.
4. Call list_sprints to know which tasks are already committed vs. unscheduled.

Step 2 — Score and rank

For each task, assess four dimensions:

Assign one of these labels:

• Critical — blocks a release, breaks production, or is a contractual obligation
• High — directly advances the top roadmap goal; would be missed by users if delayed
• Medium — valuable but not time-sensitive; no clear near-term cost to waiting
• Low — nice-to-have, cleanup, or exploratory; can be deprioritized indefinitely without user impact

Present the ranked list with one-line reasoning per task. Ask the user to confirm or adjust before writing.

Step 3 — Apply priorities

For each confirmed priority, call update_task:

• Set the priority field to the agreed value
• Optionally append a one-line rationale to the description so the reasoning is preserved and reviewable

Report back: full updated priority list as a table (task number · title · priority).

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
Documents: list_documents · get_document
Sprints: list_sprints
Projects: list_projects

You are helping the user configure the Paca MCP server for their Claude Code environment.

Walk the user through the setup interactively, step by step. Do not dump all instructions at once — confirm each step before proceeding.

Setup flow

Step 1 — Check prerequisites

Ask the user to confirm:

• Paca is running (local: http://localhost:8080, or their hosted URL)
• Node.js 18+ is installed (node --version)
• They have a Paca API key (Settings → API Keys inside Paca UI)

If any prerequisite is missing, guide the user to resolve it before continuing.

Step 2 — Identify the Claude Code config file

Ask which environment they want to configure:

A. Claude Code (CLI) — project-level (recommended for team projects) → Create or edit .claude/mcp.json in the project root.

B. Claude Code (CLI) — global → Run: claude mcp add paca --env PACA_API_KEY=<key> --env PACA_API_URL=<url> -- npx -y @paca-ai/paca-mcp

C. Claude Desktop → Edit the config file for your OS:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json
• Linux: ~/.config/Claude/claude_desktop_config.json

Step 3 — Generate the config snippet

Based on their choice, generate the exact config block. Example for option A (.claude/mcp.json):

{
  "mcpServers": {
    "paca": {
      "command": "npx",
      "args": ["-y", "@paca-ai/paca-mcp"],
      "env": {
        "PACA_API_KEY": "<their-api-key>",
        "PACA_API_URL": "<their-paca-url>"
      }
    }
  }
}

Substitute the actual values the user provides. Remind them:

• Never commit API keys to git. Add .claude/mcp.json to .gitignore if it contains a key, or use environment variable substitution.

Step 4 — Apply the config

For option A, write the .claude/mcp.json file directly (ask permission first).
For options B and C, show the command/snippet and ask the user to apply it.

Step 5 — Verify

Once configured, ask the user to restart Claude Code / Claude Desktop, then test with:

"List my Paca projects"

If Paca tools appear and return results, setup is complete. If not, check:

1. JSON syntax is valid
2. API key is correct (no extra spaces)
3. Paca API URL is reachable (curl <PACA_API_URL>/api/v1/health)
4. Node.js / npx is in PATH

Step 6 — Install the Paca skill globally (optional)

Offer to run the global skill installer so /paca and related skills are always available:

curl -fsSL https://raw.githubusercontent.com/Paca-AI/paca/master/scripts/install-claude-skill.sh | bash

Review the script before running it — curl | bash executes remote code directly.

Environment variables reference

You are planning a sprint in Paca. Use Paca MCP tools throughout — never create local files.

If no sprint is specified, default to planning the next upcoming sprint for the most active project.

Step 1 — Load project context

1. Call list_projects and identify the relevant project.
2. Call list_documents and search for documents with keywords like "roadmap", "goals", "OKR", "retrospective", or "planning". Read the most relevant ones with get_document. What the last sprint achieved and what the project's current goals are will shape which tasks belong in this sprint.
3. Call list_sprints to see existing sprints (active, upcoming, completed).
4. Call list_tasks (backlog or unassigned filter) to see the candidate task pool.

Step 2 — Detect carryover and infer velocity

Carryover: Check the most recently completed sprint for tasks that were in it but are still open (status is not done). Flag these — carryover tasks typically get priority in the next sprint.

Velocity: Look at the last 2–3 completed sprints. Sum the story point estimates of tasks that were marked done. Use the average as the default capacity if the user hasn't stated one.

Step 3 — Determine sprint parameters

From the user's message and context:

• Which sprint — by number, name, or "next sprint"
• Capacity — story points available; use inferred velocity as the default, ask to confirm
• Goal — what outcome the sprint should deliver; infer from the roadmap or ask
• Duration — start/end dates; infer from the cadence of past sprints or ask

Step 4 — Select tasks

Rank backlog tasks and recommend a set that fits within capacity:

• First: carryover tasks from the previous sprint
• Then: tasks ranked by explicit priority → unblocking dependencies → business value → estimate size
• Flag: tasks missing estimates or acceptance criteria — offer to run /paca-estimate or /paca-clarify on them before committing

Present the proposed list with a total estimated points and the sprint goal. Ask the user to confirm, swap, or adjust before applying.

Step 5 — Apply the plan

Once confirmed:

1. If the sprint does not exist, create it with create_sprint (name, goal, startDate, endDate)
2. Assign each task to the sprint with update_task (set sprintId)
3. Set or update the sprint goal with update_sprint

Optionally create or update a sprint planning note in Paca Docs (create_document / update_document) with the sprint goal, task list, capacity, and velocity reference.

Report back: sprint name, dates, task count, total estimate, capacity used, and sprint goal.

If Paca MCP is not connected

Paca MCP tools are not available. Run /paca-setup to configure the connection.

Tool reference

Sprints: list_sprints · get_sprint · create_sprint · update_sprint · complete_sprint
Tasks: list_tasks · get_task · update_task · bulk_move_tasks
Documents: list_documents · get_document · create_document · update_document
Projects: list_projects

You are testing or verifying a task — checking acceptance criteria, deriving test cases, running or describing tests, and recording results. Use Paca MCP tools throughout — never create local files for test records.

If no task is specified, call list_tasks filtered to tasks in a "review" or "in review" status — those are the most likely candidates awaiting testing.

Step 1 — Load task and project context

1. Resolve the task reference from the user's message using get_task_by_number or get_task.
2. Call list_documents and search for documents titled or tagged with "BDD", "acceptance criteria", "test plan", "QA", or the feature name. Read the most relevant ones with get_document. What "done" looks like needs to be established from the spec, not invented.
3. Call list_task_activities to read implementation notes, prior test runs, and edge cases already flagged.

Step 2 — Derive test cases

From the task's acceptance criteria and related docs, derive test cases covering:

• Happy path — the primary flow works as specified
• Edge cases — boundary values, empty inputs, maximum sizes, off-by-one
• Error cases — invalid input, missing permissions, external failures, timeouts
• Regression — adjacent functionality that must not be broken

If the acceptance criteria are clear and cover these categories, proceed directly. Only ask the user to confirm the test plan when the scope is large or genuinely ambiguous.

Step 3 — Execute tests

Choose the approach based on what's available:

• Automated (code): run the test suite or exercise the feature with Bash; report exact output
• Document / content: verify structure, completeness, and accuracy against the spec
• API / integration: describe the request, expected response, and actual response
• Manual QA required: if the feature requires a browser or UI interaction you cannot perform, describe the manual test steps clearly in the comment so a human can execute them. Mark the task status as "awaiting QA" rather than done.

Record pass / fail for each test case with a brief note.

Step 4 — Record results and update status

1. Call add_task_comment with a markdown table of results:

   | Test case | Result | Notes |
   |---|---|---|
   | Happy path: ... | ✅ Pass | |
   | Edge case: empty list | ❌ Fail | Returns 500, expected empty array |
   

2. All pass: call update_task to advance the status to the next stage (e.g. "review", "done")
3. Any fail: call update_task to set status back to "in progress"; include what needs fixing in the comment
4. If these test cases represent a repeatable procedure (e.g. release checklist, integration test steps), preserve them in a Paca document with create_document / update_document

What's next: If the task passes and there's no existing documentation for this feature, consider running /paca-doc #<number> to write it.

Report back: task number, total tests run, pass/fail count, and the status after testing.

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 · list_task_statuses
Comments: add_task_comment · list_task_activities
Documents: list_documents · get_document · create_document · update_document
Projects: list_projects

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 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:

If a reference is found, fetch that task first, then apply the action the user is asking for.

Step 2 — Infer the action

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

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