| name | pm-critique |
| displayName | 产品评审 |
| displayDescription | 对产品/设计/PRD 进行批判性评审 |
| description | Critically review products, designs, PRDs, or features to find blind spots and improvement opportunities. Use this skill whenever the user wants to evaluate product work, says 'product critique', '设计评审', '产品评审', 'review', 'critique', '找出问题', '有什么问题', '帮我看看', or needs an objective assessment. Also trigger when the user shares a PRD, wireframe, or feature doc and asks 'what do you think', 'any issues?', or 'review this'. Converts 'looks good to me' into structured, multi-dimensional feedback with prioritized improvements. |
| user-invocable | true |
| argument-hint | [待评审的产品/文档/截图] |
产品评审
如果是子代理派发执行此 Skill，直接按下方指令执行，不重新加载入口 Skill。
对产品/设计/功能进行批判性评审——从"看起来不错"到"发现 X 个问题和 Y 个改进机会"。
核心原则：好的评审不是挑毛病，是让产品更好。评审的价值在于发现盲点。
Iron Law（铁律）
| 铁律 | 违反后果 |
|---|
| 只说好话的评审不是评审 | 立即停止——补充 ≥ 3 个改进点后继续 |
| 没有优先级的改进建议无法执行 | 立即停止——每个改进点标注 P0/P1/P2 后继续 |
| 评审必须基于标准维度 | 立即停止——使用定义的评审维度重新分析 |
反合理化
| 你可能在想的 | 真相 |
|---|
| "产品做得很好，没什么好说的" | 没有完美的产品。好产品也有改进空间 |
| "评审就是挑毛病" | 评审 = 发现盲点 + 确认优势。缺一不可 |
| "我不是设计师，没法评审 UX" | 你是用户代言人。站在用户角度就能评审 |
| "评审太主观了" | 用标准维度评审，比凭感觉更客观 |
| "改进建议太多，做不到" | 那正是优先级标注的价值——P0 先做 |
双模式：Review vs Coaching
pm-critique 支持两种模式，根据用户意图自动选择：
| 模式 | 触发信号 | 行为 |
|---|
| Review | "审查"、"评审"、"打分"、"review" | 结构化评审，给出评分和改进建议 |
| Coaching | "帮我看看"、"有什么问题"、"觉得怎么样"、"挑战一下" | 以问题引导思考，不直接给答案 |
Coaching 模式的 5 种挑战原型
Coaching 不是给答案，是用问题帮 PM 发现自己的盲点：
| 挑战类型 | 核心问题 | 适用场景 |
|---|
| 假设挑战 | "如果 [假设] 不成立会怎样？" | PRD 中隐含假设多时 |
| 盲点发现 | "你考虑了 [用户群体/场景] 吗？" | 目标用户定义狭窄时 |
| 二阶效应 | "做了 X 之后，Y 会发生什么？" | 功能间有关联影响时 |
| 干系人视角 | "如果 [角色] 看到这个，他们会说什么？" | 利益相关者复杂时 |
| 机会成本 | "不做这个，做 [替代] 会更好吗？" | 资源有限需要取舍时 |
Coaching 执行流程
触发 Coaching 模式
├── 1. 读取输入（文档/截图）
├── 2. 识别关键假设和决策点
├── 3. 对每个决策点选择 1-2 个挑战原型
├── 4. 输出：3-5 个引导性问题（非答案）
└── 5. 等待用户回应后，进入深度讨论或切换到 Review
Coaching 产出格式
# Devil's Advocate — [产品/功能名]
> 🎯 我不会直接给答案。我会用问题帮你发现盲点。
## 关键假设
1. **{假设 1}** — 如果不成立？
2. **{假设 2}** — 证据是什么？
## 挑战问题
### 假设挑战
> 如果 {假设} 不成立，你的方案会怎么变？
### 盲点发现
> 你考虑了 {场景/用户} 的情况吗？他们会有什么不同反应？
### 二阶效应
> 做了 {功能} 后，{关联系统/用户行为} 会发生什么变化？
### 干系人视角
> 如果 {角色} 看到这个方案，他们最关心什么？会反对什么？
### 机会成本
> 不做这个，而是做 {替代方案}，会不会投入产出比更高？
---
💡 回答这些问题后，我可以用 Review 模式给出结构化评审。
Entry Mode — Quick（默认 Review 模式）
即时分析，不交互提问。输入：产品文档/截图/功能描述。
评审维度（自动全选，可指定聚焦）：
| 维度 | 检查内容 | 权重 |
|---|
| 用户体验 | 易用性、学习成本、错误处理、一致性 | 高 |
| 商业逻辑 | 价值主张、目标用户匹配、变现可行性 | 高 |
| 技术可行性 | 实现复杂度、性能风险、可扩展性 | 中 |
| 竞品对比 | 差异化、优势/劣势、市场定位 | 中 |
| 无障碍性 | 可达性、包容性、合规性 | 中 |
| 信息架构 | 导航、信息层级、内容组织 | 中 |
执行流程：
- 解析输入（文档 → 提取关键信息）
- 对每个维度逐项分析
- 每个维度列出：优势（≥1）+ 问题（≥1）+ 改进建议
- 改进建议标注 P0/P1/P2
- 汇总：总体评价 + 关键发现 + 优先改进项
执行流程
触发 pm-critique
├── 1. 解析输入（Read 文档 / 分析截图）
├── 2. 逐维度分析（6 维度）
├── 3. Iron Law 检查
│ ├── ≥ 3 个改进点？
│ ├── 每个有优先级？
│ └── 基于标准维度？
└── 4. 交付 + 建议下一步（→ pm-prd 改进 或 → pm-tech-spec）
交付前检查
评审问题分级
| 级别 | 标准 | 行动要求 |
|---|
| P0 严重 | 阻塞性问题，用户无法完成目标 | 必须修复才能发布 |
| P1 中等 | 重要问题，影响用户体验 | 应在发布前修复 |
| P2 轻微 | 改进建议，可以后续优化 | 加入 backlog |
详细输出模板见 references/output-template.md。
质量检查清单见 references/quality-checklist.md。
产出格式
# 产品评审: [产品/功能名]
> **评审日期**: YYYY-MM-DD
> **评审对象**: [文档/截图/功能描述]
> **总体评分**: [A/B/C/D]
## 评审总结
[2-3 句总体评价]
## 各维度分析
### 用户体验 [X/5]
**优势**: ...
**问题**: ...
**建议**: ...
### 商业逻辑 [X/5]
[同上结构]
## 优先改进项
| # | 改进建议 | 优先级 | 预期影响 |
|---|----------|--------|----------|
| 1 | {具体改进} | P0 | {影响} |
