Input and prerequisite checks
First understand the scope of this session: a full research report or only discussing one demand?When only discussing, do not write files, do not automatically create docs/. If a relevant and valid demand report already exists, read and reuse it,no need to ask again; a file with only the same name but unrelated to the current product cannot be reused.
For a complete new product chain, the default recommendation is to first /pm-brainstorm. When the user explicitly requests partial demand validation, explicitly skips brainstorm, or already has relevant creative materials, validate the demand directly and do not force the full chain; when the target user or problem definition is missing, only ask for the missing key information. Do not interpret a recommendation to skip as "brainstorming has been completed".
Output requirements: distinguish verified evidence (source, date), hypotheses pending validation, and user decisions; do not fabricate interviews or market data as facts. Subsequent prioritization and the PRD should be able to cite the demands and evidence in this report.
Cross-Agent interaction rules
When the process requires interaction with the user:
- If the current environment supports AskUserQuestion, use AskUserQuestion (best experience).
- If the current environment does not support AskUserQuestion, you must ask the same question via a normal chat message.
- Ask only one question at a time.
- After asking, you must stop the current turn and wait for the user's answer (STOP and WAIT).
- When only discussing, do not write files; formal deliverables are generated only after the user requests them and confirms the target.
- Relevant and valid existing docs can be reused without asking again; irrelevant documents cannot replace evidence.
Execution flow
The following arefull research report mode's detailed steps. Lightweight discussion only executes the steps needed for the current question; when information has already been provided, cite it directly instead of asking again. Any skipped validation must be marked as pending validation, and must not be falsely claimed as completed.
Step 1: Fill in the necessary basic product information
Key principles：
- Only ask for missing key information; no need to ask again for information already provided
- Each question is clear and focused
- Wait for the user's answer before asking the next one
Question 1: Product name
Use AskUserQuestion to ask:
What is your product name?
💡 Tip: for example "MissFresh", "Xiaohongshu", "WeChat"
After the user inputs, record it in the variable PRODUCT_NAME
Question 2: Target users
Who are the target users?
A) C-end users (individual consumers) B) B-end users (enterprise customers) C) Two-sided market (platform model) D) Other (please enter manually)
💡 Tip: after choosing, please refine further, such as "women aged 25-35 in first-tier cities", "small and medium-sized restaurant owners"
After the user answers, record it in the variable TARGET_USER
Question 3: Core business goal
What core business goal do you hope to achieve?
A) Increase revenue (e.g., GMV, paid conversion) B) Increase user scale (e.g., DAU, MAU) C) Improve user retention (e.g., repurchase rate, daily active users) D) Reduce costs (e.g., labor, operating costs) E) Other (please enter manually)
💡 Tip: Goals should be quantifiable, e.g., "Reach 1 million GMV within 3 months"
After the user answers, record to variable BUSINESS_GOAL
Question 4: Core pain points (key validation)
Key question: What is the biggest pain point users currently face?
A) Low efficiency (takes too long, too many steps) B) Poor experience (hard to use, unfriendly) C) Too costly (too expensive, heavy burden) D) Cannot be solved (existing solutions cannot meet the need) E) Other (please enter manually)
💡 Tip: Think about "Why do users need this product instead of using a competitor or maintaining the status quo?"
After the user answers, the AI immediately assesses pain point intensity:
Pain point validation logic：
If the user selects A/B/C/D:
✅ 痛点强度：⭐⭐⭐⭐⭐（强痛点）
💡 理由：用户有明确的痛点，愿意为解决方案付费/花时间
继续收集更多信息...
If the user selects E (Other) and the description is vague:
⚠️ 痛点强度：⭐⭐（弱痛点）
💡 建议：痛点不够清晰，可能是伪需求
您可以选择：
A) 继续调研（我需要更深入挖掘痛点）
B) 重新思考产品定位
C) 暂停，我需要更多信息
是否继续？
Record to variable USER_PAIN_POINT and PAIN_INTENSITY
Question 5: Industry track
Which industry track does your product belong to?
A) E-commerce retail (fresh groceries, apparel, general e-commerce, etc.) B) Social entertainment (social, gaming, content communities, etc.) C) Enterprise services (SaaS, tools, B2B services, etc.) D) Fintech (payments, wealth management, insurance, etc.) E) Other (please enter manually)
💡 Tip: A clear track helps with subsequent market analysis
Record to variable INDUSTRY
Step 2: Collect a preliminary requirements list
Use AskUserQuestion to ask:
Now please list the core requirements you have in mind (one requirement per line)
For example:
- Quick ordering
- Order tracking
- Membership system
💡 Tip: Enter "done" to finish entering requirements
The user enters requirements line by line, and the AI collects them into the list REQUIREMENT_LIST
Step 3: Requirement authenticity validation (quick mode)
Quickly validate each requirement (only validate obvious issues):
The AI asks about each requirement:
Is the requirement "{requirement name}" a real requirement?
Judgment criteria:
- Are users willing to pay for it or spend time on it?
- Does this requirement solve an actual pain point?
A) It is a real requirement ✅ B) It may be a false requirement ⚠️ (please explain why) C) Not sure, needs further validation
Record the validation results to VERIFIED_REQUIREMENTS
Step 3.5: Subagent parallel market validation (new in v2.0)
Only consider parallel validation when the user requests internet/market validation, the current environment supports it, and there are clearly verifiable questions. Skip this section for lightweight discussions, when internet access is prohibited, or when the materials are already sufficient, and note that no external validation was performed; do not unconditionally dispatch an agent for every requirement.
Use the Agent tool to dispatch in parallel:
Subagent 1 - Competitor validation：
{
"type": "general-purpose",
"prompt": "你是一个市场调研专家。请验证以下产品需求的竞品情况。\n\n产品名称: {PRODUCT_NAME}\n行业赛道: {INDUSTRY}\n核心痛点: {USER_PAIN_POINT}\n需求清单: {VERIFIED_REQUIREMENTS}\n\n搜索工具优先级（必须遵守）：\n1. 首选 AnySearch：先定位 anysearch_cli.py（检查 ~/.claude/skills/anysearch/scripts/ ~/.opencode/skills/anysearch/scripts/ ~/.openclaw/skills/anysearch/scripts/ ~/.cursor/skills/anysearch/scripts/ ~/.anysearch/scripts/ 或 which anysearch_cli.py），找到后 Bash 调用 python3 <路径> search \"查询词\" --max_results 5\n2. AnySearch 不可用 → 降级到 mcp__exa__web_search_exa\n3. Exa 不可用 → 降级到 WebSearch，并在输出中标注「⚠️ 降级模式」\n4. 使用 WebSearch 时在报告中标注「⚠️ 降级模式」\n\n搜索要求：\n1. 搜索该产品领域的竞品信息\n2. 搜索哪些竞品已经解决了类似痛点\n3. 提取竞品关键功能、用户规模、市场表现\n\n输出 JSON 格式：\n{\"dimension\":\"竞品验证\",\"findings\":[{\"competitor\":\"竞品名\",\"features\":\"功能描述\",\"market_position\":\"市场表现\"}]}"
}
Subagent 2 - User voice validation：
{
"type": "general-purpose",
"prompt": "你是一个用户研究员。请验证以下产品需求在用户侧的真实性。\n\n产品名称: {PRODUCT_NAME}\n目标用户: {TARGET_USER}\n核心痛点: {USER_PAIN_POINT}\n\n搜索工具优先级（必须遵守）：\n1. 首选 AnySearch：先定位 anysearch_cli.py（检查 ~/.claude/skills/anysearch/scripts/ ~/.opencode/skills/anysearch/scripts/ ~/.openclaw/skills/anysearch/scripts/ ~/.cursor/skills/anysearch/scripts/ ~/.anysearch/scripts/ 或 which anysearch_cli.py），找到后 Bash 调用 python3 <路径> search \"查询词\" --max_results 5\n2. AnySearch 不可用 → 降级到 mcp__exa__web_search_exa\n3. Exa 不可用 → 降级到 WebSearch，并在输出中标注「⚠️ 降级模式」\n4. 使用 WebSearch 时在报告中标注「⚠️ 降级模式」\n\n搜索要求：\n1. 搜索目标用户群体对相关痛点的讨论\n2. 搜索：site:zhihu.com OR site:xiaohongshu.com {核心痛点}\n3. 分析用户真实反馈，验证痛点真实性\n\n输出 JSON 格式：\n{\"dimension\":\"用户声音\",\"findings\":[{\"source\":\"来源\",\"quote\":\"用户原话\",\"pain_point\":\"对应痛点\"}]}"
}
Subagent 3 - Market size validation：
{
"type": "general-purpose",
"prompt": "你是一个行业分析师。请评估以下产品的市场机会。\n\n产品名称: {PRODUCT_NAME}\n行业赛道: {INDUSTRY}\n\n搜索工具优先级（必须遵守）：\n1. 首选 AnySearch：先定位 anysearch_cli.py（检查 ~/.claude/skills/anysearch/scripts/ ~/.opencode/skills/anysearch/scripts/ ~/.openclaw/skills/anysearch/scripts/ ~/.cursor/skills/anysearch/scripts/ ~/.anysearch/scripts/ 或 which anysearch_cli.py），找到后 Bash 调用 python3 <路径> search \"查询词\" --max_results 5 --domain finance --sub_domain finance.cn_stock\n2. AnySearch 不可用 → 降级到 mcp__exa__web_search_exa\n3. Exa 不可用 → 降级到 WebSearch，并在输出中标注「⚠️ 降级模式」\n4. 使用 WebSearch 时在报告中标注「⚠️ 降级模式」\n\n搜索要求：\n1. 搜索该行业市场规模数据\n2. 搜索：{INDUSTRY} 市场规模 2026\n3. 分析市场增长潜力\n\n输出 JSON 格式：\n{\"dimension\":\"市场规模\",\"findings\":[{\"metric\":\"指标\",\"value\":\"数据值\",\"source\":\"来源\"}]}"
}
Wait for all subagents to complete, and integrate the structured results into the requirement research report.
Optimization notes：
- Before optimization (v1): the main agent searches serially, and search results occupy context
- After optimization (v2): subagents search in parallel, the main agent only processes structured results
- Efficiency improvement: search time reduced from ~3 minutes to ~1 minute, saving about 70% of tokens
Step 4: Generate a requirements research report as requested by the user
When the user only wants discussion, state the conclusions and unverified assumptions in the chat and skip writing. A formal report requires confirming the output path; if a file already exists, first confirm overwrite/append. Only after confirmation, create docs/01-需求调研/, use the Write tool to create docs/01-需求调研/需求调研报告.md：
# 需求调研报告
## 一、产品基础信息
- **产品名称**: {PRODUCT_NAME}
- **目标用户**: {TARGET_USER}
- **核心目标**: {BUSINESS_GOAL}
- **行业赛道**: {INDUSTRY}
- **生成时间**: {当前时间}
- **调研工具**: super-pm
---
## 二、核心痛点
**用户痛点**: {USER_PAIN_POINT}
**痛点强度**: {PAIN_INTENSITY} 星级
**验证状态**: ✅ 已验证真实需求
**验证理由**: 用户有明确痛点，愿意为解决方案付费/花时间
---
## 三、初步需求清单
| 序号 | 需求名称 | 验证状态 | 备注 |
|------|----------|----------|------|
| 1 | {需求1} | ✅ 真需求 | - |
| 2 | {需求2} | ✅ 真需求 | - |
| 3 | {需求3} | ⚠️ 需验证 | {原因} |
| ... | ... | ... | ... |
---
## 四、下一步建议
建议执行：
1. **/pm-brainstorm** - 头脑风暴，探索更多可能性（推荐）
2. **/pm-clarify** - 需求细化，明确每个需求的细节
3. **/pm-market** - 市场分析，了解行业与竞品
---
**项目状态**: 需求调研完成
**生成时间**: {时间戳}
**生成工具**: super-pm
Step 5: Output completion prompt
Use AskUserQuestion to provide next-step options:
✅ Requirements research complete!
📄 If a report was actually generated:
docs/01-需求调研/需求调研报告.md; otherwise only report the conclusions from the chat and do not claim the file exists.🎯 Suggested next steps:
A) Run /pm-brainstorm - Brainstorm, explore more possibilities (recommended) B) Run /pm-clarify - Requirements refinement, clarify details C) Run /pm-market - Market analysis, understand the industry and competitors D) View the requirements research report
Fallback mechanisms
Scenario 1: User cancels midway
If the user cancels midway, stop and briefly explain what has been confirmed and what has not.Do not automatically save drafts or create directories; only write when the user explicitly requests saving, after confirming the location and overwrite risk.
Scenario 2: A requirements research report already exists
If an existing report is detected:
if [ -f "docs/01-需求调研/需求调研报告.md" ]; then
echo "⚠️ 检测到已有需求调研报告"
fi
Provide options:
- View the existing report
- Re-research (overwrite)
- Supplementary research (append)
Notes
- Risk first: Question 4 (pain point validation) is the core and must be taken seriously
- One question at a time: Use AskUserQuestion to ask one by one, avoiding overburdening the user
- Pain point intensity judgment: The AI needs to judge the intensity of the pain point based on the user's answers
- Markdown storage: The generated report is human-readable and editable
- Recommended next steps: After completion, recommend 2-3 related skills
Output quality comparison
✅ Good example：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad example：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
Common pitfalls / Red Flags — STOP
Stop immediately and backtrack if any of the following occur:
| Pitfall | Correct approach |
|---|---|
| Drawing conclusions using "should", "probably", "seems" | Must be based on actual data and verification |
| Claiming completion without running checks | Verify first, then state |
| User requests a lightweight approach or skipping | Respect the scope, mark unverified parts, and do not falsely claim completion |
| The thought "it should be fine this time" | Re-verify every time |
Output quality check / Verification Checklist
- Prerequisite dependencies are satisfied (input documents/data have been collected)
- All core steps have been executed
- The output document has been generated to the
docs/directory - Every judgment is supported by data/evidence
- 2-3 follow-up skills have been recommended
⚠️ If any item fails → complete it before marking as done.