做竞品情报分析时：用真实网络数据产出战卡、定价全景与功能矩阵

当需要摸清某个市场的竞争格局、竞品定价、客户口碑与增长信号时，用分阶段调研流程做出可落地的情报交付物。

适用场景

解决思路

1. 先做续跑检查：在开始任何动作前，查看工作目录或项目子目录中是否存在本技能创建的 PROGRESS.md；若存在则读取它，从最后一个未完成阶段继续，并告知用户“我发现了上次会话的进度，你已完成 [阶段]，从 [下一阶段] 接着做”。若不存在或属于其他技能，从 Phase 1 开始。
2. 检查是否有前置的 startup-design 成果：在工作目录或子目录中查找 01-discovery/competitor-landscape.md、01-discovery/market-analysis.md、01-discovery/target-audience.md、00-intake/brief.md；若存在则读取并作为起点——提取产品描述、目标市场与已知竞品；用 competitor-landscape.md 的竞品列表作为深挖起点；用 market-analysis.md 的市场规模与趋势做背景；用 target-audience.md 的客户痛点聚焦情感挖掘。告诉用户将以此为基础做更深的竞争分析，并完全跳过访谈直接进入研究。
3. 若无前置数据，第 1 轮只问基础问题：产品/想法是什么（一句话即可）、解决什么问题给谁、处于什么市场/品类、是否已知道某些竞品（名称、URL）。
4. 第 2 轮仅按需追问：目标地理/市场、定价模式或区间、自认的关键差异化点。
5. 不要过度访谈：若用户一开始就给出清晰描述，直接进入研究，剩下的交给分析本身去浮现。
6. 把产品、市场、已知竞品的简要总结保存到 {project-name}/intake.md；若基于 startup-design 数据，注明用到的来源文件；项目名由产品/市场推导（kebab-case，如 ai-email-assistant）。
7. 创建 {project-name}/PROGRESS.md，记录项目名、技能名（startup-competitors）、开始日期、语言、研究模式（Live / Knowledge-Based）和阶段清单；每完成一个阶段就更新它；若已存在则从最后未完成阶段恢复。
8. 做研究深度评估：从 intake 信息给三个因素打分——市场广度（1-3）、已知竞品数量（1-3）、地理范围（1-3）。
9. 把三项得分求和（范围 3-9）并映射到层级：Light（3-4）、Standard（5-7）、Deep（8-9）。
10. 向用户展示 Research Depth 表格（模板见 references/research-scaling.md）。
11. 等待用户回复：light、deep 或 ok（接受推荐）。
12. 把选定层级记录进 PROGRESS.md；该层级决定 Phase 2 中每波 agent 的数量和每个 agent 的搜索轮数。
13. 做环境检测：若 Agent 工具可用（Claude Code），在同一波内并行 spawn 所有 agent 以提速；若不可用（Claude.ai、web），按同样模板顺序执行，深度相同只是更慢。
14. 若 WebSearch 不可用或被拒，回退到 Knowledge-Based Mode：使用训练数据，所有结论标注 [Knowledge-Based — verify independently]，并把置信度整体下调一级。
15. 开始任何研究波之前，先读 references/research-principles.md，其中定义来源质量分层、交叉引用规则和数据缺口处理方式。
16. Wave 1 的 A1（竞品深挖）：识别并剖析 5-8 个直接竞品，外加 2-3 个相邻方案（更广的平台、手工替代方案、来自相邻品类但争夺同一预算的工具）；每个竞品记录产品、功能、团队规模、融资、牵引信号、优势、劣势；不要只看它们的营销页——去查评价、招聘信息和融资数据。
17. Wave 1 的 A2（定价情报）：对每个竞品逆向拆解定价模型——不只是“$49/月”，而是价值度量是什么（按席位？按用量？一口价？）、各档位如何区分、用了什么定价心理学（锚定、诱饵、尾数定价）、转换成本如何（技术、合同、情感）；建立逐档对比。
18. Wave 2 的 B1（评价挖掘）：挖掘 G2、Capterra、TrustRadius、Product Hunt 和 App Store 上每个竞品的评价；提取模式——用户称赞什么、抱怨什么、请求什么功能；按竞品和痛点主题两个维度组织；保留原文引用。
19. Wave 2 的 B2（论坛与社区挖掘）：挖掘 Reddit、Indie Hackers、Hacker News、Quora 及垂直社区；找出对现有工具的抱怨、“X 你们用什么”的帖子、迁移故事、变通方案讨论；建立语言地图（客户描述其问题和愿望时用的原话）；识别 churn signals（用户为什么离开每个竞品）。
20. Wave 3 的 C1（Go-to-Market 分析）：对每个竞品梳理主要获客渠道、销售动作（自助 vs 销售驱动）、内容策略（博客频率、主题、质量）、社交存在、付费广告信号、合作打法；建立渠道机会地图，展示每个渠道上竞品的饱和程度 vs 机会大小。
21. Wave 3 的 C2（战略与增长信号）：看融资轨迹（轮次、投资方、时间）、招聘模式（工程岗多=在造东西、销售岗多=在扩张、支持岗多=在挣扎）、内容/SEO 足迹（排名哪些关键词、缺口在哪）、从 changelog 和公开声明中读产品路线信号；识别每个竞品占据的内容支柱，以及哪些主题无人做好。
22. 研究后设置检查点：三波全部完成后、进入综合之前，用一条消息简要向用户展示研究发现了什么——剖析了多少竞品、最主要的客户痛点主题、最值得注意的战略信号（融资、招聘、GTM 模式）；然后问“这是否符合你的预期？综合之前要增删哪些竞品？”保持一条消息，只做快速对齐，不要写成完整报告。
23. 综合阶段先读 references/research-synthesis.md，然后动手前先读完全部原始文件。
24. 跨波连接发现：定价缺口 + 客户抱怨 + 招聘信号 = 战略机会。
25. 识别来源之间的矛盾，并说明应该采信哪一个。
26. 对每条主要论断标注置信度（High / Medium / Low）。
27. 不止罗列事实，要挖出战略含义——这些事实意味着什么。
28. 把所有原始文件中的数据缺口汇总到 competitors-report 中专设的 “Data Gaps & Research Limitations” 章节；任何分析都有盲区，明确写出可防止虚假自信。
29. 把相邻方案也纳入分析——客户不只在直接竞品之间选，还在相邻领域的“够用”方案之间选。
30. 每个交付文件都以标准头部开头：`# {Title}: {product}`，紧跟 `*Skill: startup-competitors | Generated: {date}*`；每个交付物结尾都必须有 Red Flags、Yellow Flags 和 Sources 章节。
31. 产出 {project-name}/competitors-report.md（主交付物），包含：执行摘要（5 句话概述竞争格局）、市场集中度评估（分散/整合中/被主导）、各研究维度的关键发现、战略机会（在哪里竞争）、战略风险（避开哪里）、竞争护城河评估（网络效应、转换成本、数据护城河、品牌、规模）、数据缺口与研究局限（必填）、红旗与黄旗。
32. 产出 {project-name}/competitive-matrix.md：功能为行、竞品为列；评级用 strong / adequate / weak / missing；高亮没有任何竞品服务好的功能缺口；把自家产品也放进去（未上线则用占位）。
33. 产出 {project-name}/pricing-landscape.md：跨所有竞品的逐档对比、价值度量分析（各收什么费以及为什么）、定价心理学拆解（锚定、诱饵、freemium 策略）、价格定位图（横轴价格、纵轴功能深度）、定价空白区（哪里还有定位空间）、转换成本矩阵（每个竞品：技术、合同、情感）。
34. 为每个竞品产出一份 {project-name}/battle-cards/{competitor-name}.md：一页格式，包含他们是谁、优势、劣势、如何战胜他们（具体话术）、他们什么时候会赢过你（要诚实）、客户异议与回应、可攻击的关键弱点、churn signals（他们的客户为什么离开）。
35. 把原始研究文件保留在 {project-name}/raw/ 供查阅：competitor-profiles.md、pricing-intelligence.md、review-mining.md、forum-mining.md、gtm-analysis.md、strategic-signals.md。
36. 综合完成且所有交付文件写完后跑验证：读 references/verification-agent.md，spawn 验证 agent V1，由它读取所有交付文件并检查未标注的论断、内部矛盾、置信度评级一致性、缺失的数据缺口、缺失的 flags、过时数据、以及重复来源造成的假互证。
37. V1 还要跑本技能专属检查：battle card 与 report 的一致性、matrix 与 profiles 的对齐、pricing landscape 与 profiles 的一致性、跨交付物的整体连贯性。
38. V1 产出 {project-name}/verification-report.md。
39. 若发现 Critical 问题：暂停并向用户展示问题，问是先修还是照常推进；若只有 Warnings/Info：展示一行摘要即可。
40. 在 Claude.ai 或 Agent 工具不可用时，在主对话中按同一验证协议自行执行这些检查。
41. 遵守诚实协议（完整内容见 references/honesty-protocol.md）：不吹捧——竞品某方面客观更强就直说，忽略竞品优势的战卡在真实销售对话里毫无用处。
42. 标注论断：使用 [Data]、[Estimate]、[Assumption]、[Opinion] 标签，绝不把猜测当事实陈述。
43. 量化：写“$12M ARR，同比增 40%”，而不是“他们增长很快”。
44. 给所有数据标日期；对超过 12 个月的数据打上标记。
45. 声明缺口：写“DATA GAP: 找不到关于 [X] 的可靠数据”永远好过编造。
46. 暴露红旗：如果竞争格局看起来非常残酷，就直接说。
47. 挑战确认偏误：当研究结果正好印证创始人的既有信念时，要挖得更深，去找反证。
48. 语言规则：默认输出英文；若用户用其他语言书写或明确要求某种语言，则所有输出改用该语言。
49. 按阶段按需阅读 reference 文件，不要一次全读：honesty-protocol.md（会话开始时）、research-principles.md（Phase 2 前）、research-wave-1-profiles-pricing.md / research-wave-2-sentiment-mining.md / research-wave-3-gtm-signals.md（各自波次运行时）、research-synthesis.md（所有波次完成后）、research-scaling.md（intake 后、Phase 2 前）、verification-agent.md（综合后）。

适用边界 · 注意事项

• 没有 WebSearch 时拿不到实时数据，只能退回 Knowledge-Based Mode，所有结论需标注 [Knowledge-Based — verify independently] 并整体降一级置信度，不适合依赖最新融资/定价情报的决策。
• 流程耗时较长（Claude Code 并行约 15-25 分钟，顺序执行约 30-45 分钟），需要几分钟内出结论的轻量场景不适用，此时应直接选 Light 层级或跳过。
• 没有 Agent 工具的环境只能顺序执行，虽然深度相同但明显更慢，不适合强时效的临场需求。