SuperAPI AI Directory
Partner中文AI newsFavorites
Skillscx-prd

cx-prd

Design & creation

View repository

Updated 10-15 23:41

About this skill

cx-prd: Requirement Gathering and Scope Assessment

Converge vague ideas into executable requirements and decide whether to proceed to the design phase.

Read first:

  • ${CLAUDE_PLUGIN_ROOT}/core/workflow/README.md
  • ${CLAUDE_PLUGIN_ROOT}/core/workflow/protocols/prd.md
  • ${CLAUDE_PLUGIN_ROOT}/references/templates/prd.md

Usage

/cx:cx-prd {功能名}
/cx:cx-prd

Mandatory Rules

All file reads and writes must use absolute paths. Prohibited to use ../ relative paths to operate on files. First use git rev-parse --show-toplevel to obtain the absolute path; all Read/Write/Edit operations are based on that path.

Prohibited to skip the Q&A and directly generate the document. No matter how clear or complete the user's requirement description is, you MUST:

  1. First analyze the code and context
  2. Proactively propose solution options (AskUserQuestion)
  3. Complete at least 2 rounds of structured Q&A and obtain explicit user confirmation
  4. Only after confirmation is complete may you generate 需求.md

Behaviors that violate this rule:

  • ❌ User finishes describing the requirement → directly write 需求.md
  • ❌ Only do one round of Q&A and then persist to disk
  • ❌ Mix Q&A content and document generation into the same step

Correct behavior:

  • ✅ User finishes describing the requirement → analyze code → Round 1 option selection → Round 2 detailed confirmation → user confirms "it's fine" → generate document

Anti-Rationalization

Excuse Reality
"The user's requirement is already very clear" No matter how clear, it still needs option comparison and confirmation
"This feature is simple and doesn't need Q&A" Simple features are more likely to miss boundary conditions
"Writing the document first and then asking is the same" Writing the document first creates preconceptions that anchor thinking
"Multiple rounds of Q&A are too slow" 2 rounds of Q&A take 5 minutes, rework takes 2 hours
"I've already analyzed the code and know what to do" Analyzing code ≠ understanding user intent

Runtime Boundaries

  • Project-level 开发文档/CX工作流/配置.json is the runtime configuration source of truth
  • Feature status is in each worktree's 开发文档/CX工作流/功能/{title}/状态.json in
  • Global current_feature pointer is deprecated; worktree CWD is the context
  • Visible directories and document names use Chinese; internal state references always use stable slug
  • cx-prd is responsible for requirement convergence, not for making the process heavy
  • On the Claude Code side, write shared state with the runner cc identity; if the feature is already held by codex , first prompt handoff
  • Do not wait until after long analysis to persist to disk; the minimal PRD scaffold should first be created by the shared runner

Worktree Isolation (Mandatory)

Step -1: Create or enter Feature Worktree

Execute before Step 0 (scaffold):

PROJECT_ROOT=$(git rev-parse --show-toplevel)
check_output=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/cx-worktree.sh check --project-root "$PROJECT_ROOT" 2>&1) || true

If on_main=true(on the main branch):

Use AskUserQuestion to ask:

{
  "questions": [{
    "question": "当前在主分支上，需要为这个功能创建隔离工作区",
    "header": "工作区选择",
    "multiSelect": false,
    "options": [
      { "label": "创建 Feature Worktree（推荐）", "description": "自动创建隔离分支和工作目录" },
      { "label": "在当前分支直接开始（--inline）", "description": "不隔离，适合极小改动" }
    ]
  }]
}

When the user chooses to create a worktree:

bash ${CLAUDE_PLUGIN_ROOT}/scripts/cx-worktree.sh create \
  --feature "{feature-slug}" \
  --runner cc \
  --project-root "$PROJECT_ROOT"

Then cd to the new worktree path to continue the subsequent steps.

When the user selects inline, continue executing on the current branch.

Core Steps

Step 0: First establish the feature scaffold according to the shared workflow core

PROJECT_ROOT=$(git rev-parse --show-toplevel)
bash ${CLAUDE_PLUGIN_ROOT}/scripts/cx-workflow-prd.sh \
  --project-root "$PROJECT_ROOT" \
  --title "{功能标题}" \
  --slug "{feature-slug}" \
  --runner cc \
  --session-id "{session-id}" \
  --size "{S|M|L}" \
  --needs-design "{true|false}" \
  --question-mode checklist

This shared runner is responsible for deterministic persistence:

  • 开发文档/CX工作流/功能/{功能标题}/需求.md
  • 开发文档/CX工作流/功能/{功能标题}/状态.json
  • .cx/core/features/{feature-slug}.json
  • .cx/core/projects/project.json

Step 0.5: Dashboard automatic keep-alive and project registration

Execute every time PRD is entered to ensure the dashboard service is always available:

PROJECT_ROOT=$(git rev-parse --show-toplevel)
bash ${CLAUDE_PLUGIN_ROOT}/scripts/cx-dashboard-ensure.sh
bridge_output=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/cx-dashboard-bridge.sh \
  --project-root “$PROJECT_ROOT” \
  --display-name “$(basename “$PROJECT_ROOT”)”)

Behavior rules:

prompt_state=accepted(already enabled):

  • Check the service health status every time; if the service is down, automatically restart it (cx-dashboard-ensure.sh）
  • Automatically register the current project without asking again
  • Inform the user of the panel address (if the service is running normally)

prompt_state=pending(never asked before):

  • Use AskUserQuestion to ask whether to enable the global panel
  • User accepts → execute --decision accept, start the service
  • User skips → execute --decision decline, skip this time
  • Does not block the PRD process

prompt_state=declined(previously skipped):

  • It is not a permanent refusal. Check runtime.json in last_checked_at：
    • If more than 24 hours have passed since the last check (indicating the computer may have restarted) → ask again once
    • If less than 24 hours → silently skip, do not disturb

Behavior after service restart:

  • cx-dashboard-ensure.sh will detect whether the PID is alive
  • Process is not present → automatically clean up the old PID → relaunch backend + frontend
  • Automatically scan ~/.cx/dashboard/registry.json for registered projects

Step 1: Read existing context

  • Scan the project tech stack and existing modules
  • Find the pages, interfaces, and data structures closest to this feature
  • If the project already has related 需求.md / 设计.md / 修复记录.md, extract only the parts relevant to this requirement

Step 2: Converge requirements through multiple rounds of structured Q&A

All user interactions in the PRD phase must (MUST) use the AskUserQuestion tool. It is forbidden to replace it with plain-text option lists or open-ended questioning. Each round, first restate the current understanding, then use structured questions to probe the gaps.

Round 1: Scenario and scope

First, based on the user's description and code analysis, proactively propose 2-3 feasible implementation directions for the user to choose from or supplement:

{
  “questions”: [
    {
      “question”: “基于你的描述和项目现状，我分析了几个可行方向，哪个最接近你的预期？”,
      “header”: “实现方向”,
      “multiSelect”: false,
      “options”: [
        {
          “label”: “方案 A: {简要描述} (Recommended)”,
          “description”: “{优势、适用场景、预估工作量}”
        },
        {
          “label”: “方案 B: {简要描述}”,
          “description”: “{优势、适用场景、预估工作量}”
        },
        {
          “label”: “方案 C: {简要描述}”,
          “description”: “{优势、适用场景、预估工作量}”
        }
      ]
    },
    {
      “question”: “这个功能会影响哪些层级？”,
      “header”: “影响范围”,
      “multiSelect”: true,
      “options”: [
        { “label”: “前端 UI/交互”, “description”: “页面、组件、样式、路由” },
        { “label”: “后端 API/逻辑”, “description”: “接口、服务、中间件” },
        { “label”: “数据库/状态”, “description”: “表结构、状态机、缓存” },
        { “label”: “基础设施/部署”, “description”: “配置、CI/CD、环境变量” }
      ]
    }
  ]
}

Solution recommendation rules:

  • MUST Proactively analyze and propose solutions based on the current state of the project code; do not just ask "how do you want to do it"
  • Put the recommended solution first and mark it (Recommended), with reasons attached
  • Each solution explains its advantages, risks, and estimated workload
  • Users can select "Other" to add their own input

Round 2: Requirement refinement

Continue deeper based on the choices from Round 1. You may ask 1-4 questions at the same time:

{
  “questions”: [
    {
      “question”: “需要支持哪些核心功能？”,
      “header”: “核心功能”,
      “multiSelect”: true,
      “options”: [
        { “label”: “{功能点 A}”, “description”: “{说明}” },
        { “label”: “{功能点 B}”, “description”: “{说明}” },
        { “label”: “{功能点 C}”, “description”: “{说明}” },
        { “label”: “{功能点 D}”, “description”: “{说明}” }
      ]
    },
    {
      “question”: “以下哪些属于本次范围外？”,
      “header”: “Out of Scope”,
      “multiSelect”: true,
      “options”: [
        { “label”: “{排除项 A}”, “description”: “{为什么建议排除}” },
        { “label”: “{排除项 B}”, “description”: “{为什么建议排除}” }
      ]
    }
  ]
}

Round 3: Acceptance and risks

{
  “questions”: [
    {
      “question”: “以下验收标准是否完整？”,
      “header”: “验收标准”,
      “multiSelect”: true,
      “options”: [
        { “label”: “{标准 1}”, “description”: “{可测试的具体条件}” },
        { “label”: “{标准 2}”, “description”: “{可测试的具体条件}” },
        { “label”: “{标准 3}”, “description”: “{可测试的具体条件}” }
      ]
    },
    {
      “question”: “识别到以下潜在风险，需要特别关注哪些？”,
      “header”: “风险”,
      “multiSelect”: true,
      “options”: [
        { “label”: “{风险 A}”, “description”: “{影响和缓解方案}” },
        { “label”: “{风险 B}”, “description”: “{影响和缓解方案}” }
      ]
    }
  ]
}

Multi-round pacing control

  • At most 4 questions per round, and at most 4 options per question
  • If one round can cover multiple dimensions, merge them; there is no need for a separate round for each dimension
  • Usually 2-3 rounds are enough to converge; complex features should not exceed 4 rounds
  • When you find that the user selected "Other" and added new information, the next round must reflect an understanding of that information

Step 3: Generate the project-level requirements document

After the shared runner first completes the minimal persistence, then fill in the requirements content completely, rather than stopping at verbal Q&A.

The document must contain at least:

  • Feature title
  • Stable slug
  • Background and goals
  • Selected solution (including comparative analysis)
  • User scenarios
  • Feature requirements (from Round 2 multi-select results)
  • Acceptance criteria (from Round 3 confirmation results)
  • Explicit Out-of-Scope
  • Risks and open issues

Step 4: Scale assessment and routing confirmation

Provide recommendations based on the analysis results,MUST use AskUserQuestion to let the user give final confirmation:

{
  “questions”: [
    {
      “question”: “需求已收敛完成。根据分析建议规模为 {S/M/L}，接下来？”,
      “header”: “下一步”,
      “multiSelect”: false,
      “options”: [
        {
          “label”: “{推荐路由} (Recommended)”,
          “description”: “{推荐理由}”
        },
        {
          “label”: “走完整流程（PRD → Design → Plan）”,
          “description”: “即使是小功能也做完整设计，适合不确定性较高的场景”
        },
        {
          “label”: “直接进入规划（PRD → Plan）”,
          “description”: “跳过设计阶段，适合需求已经非常清晰的场景”
        }
      ]
    }
  ]
}

Routing rules:

  • S: default recommendation /cx:cx-plan
  • M: default recommendation /cx:cx-design
  • L: default recommendation /cx:cx-design, and supplement with /cx:cx-adr

Only after the requirements are truly mature, advance the feature status from drafting to the next stage.

Deliverables

  • Document:开发文档/CX工作流/功能/{功能标题}/需求.md
  • Status: project-level 状态.json update current_feature、features[slug]
  • shared core：.cx/core/features/{slug}.json and project.json
  • Follow-up routing: automatically suggest /cx:cx-plan or /cx:cx-design