paca-clarify
GitHub通过识别模糊点并提问,澄清Paca中不明确的任务或规范。自动加载上下文,找出范围、边缘情况及验收标准缺失,引导用户补充后重写描述,确保具备可测试的完成条件。
Trigger Scenarios
Install
npx skills add Paca-AI/paca --skill paca-clarify -g -y
SKILL.md
Frontmatter
{
"name": "paca-clarify",
"description": "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.",
"compatibility": "Requires Paca MCP server. Run \/paca-setup if Paca tools are not available."
}
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
- Resolve the target from the user's message:
#42orABC-42→get_task_by_number- Paca URL → parse IDs →
get_taskorget_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.
- Call
list_documentsand 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. - If it's a task, call
list_task_activitiesto 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_taskwith an improved description including explicit acceptance criteria. Don't just append — rewrite the description so it stands alone without this conversation. - Document: call
update_documentwith 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-setupto 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
Version History
- 1a37f10 Current 2026-07-05 14:57


