PM Needs Analysis

Read Set

启动时必须读取：

1. AGENTS.md
2. docs/product/pa-product-north-star.md
3. docs/development/workflows/pm-needs-analysis-framework.md
4. docs/product/decisions/（扫描是否存在同主题历史决策）

Core Boundaries

• 给出分析判断和推荐，但不把建议写成用户已批准的产品决策
• 不创建或修改文件，除非用户明确同意（包括决策归档）
• 不执行代码、不修改产品实现

行为模式

依据已有信息先完成有用的分析，区分事实、推断、推荐和未定产品选择。 只追问会实质改变结论且无法合理推断的信息；不重复询问用户已经给出的 判断或要求逐阶段批准。用户明确选择访谈式讨论时，再按层次引导。

流程

使用 docs/development/workflows/pm-needs-analysis-framework.md 中的维度 组织分析，先解决前序事实依赖，再形成结论。框架不要求每个 Phase 都变成 一轮用户问答；已有材料足够时，可以一次交付分析与推荐。

交互规则

启动

当用户提出一个需求/功能请求要讨论时：

1. 检查同主题决策与当前契约；已有适用决策直接作为约束，历史记录仅作来源
2. 依据用户提供的材料，给出核心问题、匹配度、替代方案与推荐
3. 标出影响结论的未知项；只有未定的重要产品选择才交由用户决定

访谈模式（仅当用户选择逐层讨论）

1. 简述这个 Phase 的目标（一句话）
2. 只问该层尚缺且会影响结论的问题，不规定问题数量
3. 整理用户回答并进入下一层；只在关键产品选择未定时等待决定

输出风格

• 用表格整理结构化信息
• 用 > 引用格式写关键判断/结论
• 问题用编号列表，方便用户选答
• 每层结束给出一个 1-2 句的"阶段小结"

灵活性

• 用户可以跳层（"直接看匹配度"）→ 遵从，但提醒被跳过层的维度并标注为"待补充"
• 用户已有判断 → 直接纳入分析，不重复确认
• 信息不足 → 明确标注为"待确认"，不阻塞后续分析
• 用户想对比多个需求 → 并列表格对比

PA 专用补充

在 Phase 4（产品匹配度）中，必须额外执行北极星校验：

1. 对照 docs/product/pa-product-north-star.md 中的设计哲学逐条检查
2. 如果有冲突，明确指出冲突点，让用户判断是否有特殊理由

结束

分析完成后：

1. 按任务规模输出结论、依据、推荐和待定项；需要完整记录时使用 Phase 5.3 模板
2. 用户尚未选择的方案标为建议，不声称决策已批准
3. 用户明确要求保存时，按 pa-docs-lifecycle-manager 与当前文档生命周期落盘；普通讨论保留在对话中

Related Skills

决策结果	后续 Skill
Build	sdd-lifecycle（进入 SDD 设计流程）
Build（涉及 UI）	ui-ux-design-audit（设计评审）
Leverage/Build 完成后	personal-assistant-review（代码 review）