pm-needs-analysis

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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） |

From edonyzpc/personal-assistant, AGPL-3.0.

More from edonyzpc/personal-assistant