| 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 模式）
即时分析，不交互提问。输入：产品文档/截图/功能描述。
评审维度（自动全选，可指定聚焦）：
| 维度 | 检查内容 | 权重 |
|---|
| 用户体验 | 易用性、学习成本、错误处理、一致性 | 高 |
| 商业逻辑 | 价值主张、目标用户匹配、变现可行性 | 高 |
| MVP 反模式 | Agentic Technical Debt / False PMF / Scope Creep / Insecure by Inexperience（仅评审 PRD/原型时触发） | 高 |
| 技术可行性 | 实现复杂度、性能风险、可扩展性 | 中 |
| 竞品对比 | 差异化、优势/劣势、市场定位 | 中 |
| 无障碍性 | 可达性、包容性、合规性 | 中 |
| 信息架构 | 导航、信息层级、内容组织 | 中 |
MVP 反模式检查（PRD/原型评审时必触发）
来源：The Founder's Playbook — AI-Native 创业 MVP 四大反模式。
| 反模式 | 评审检查项 | 发现信号 |
|---|
| Agentic Technical Debt | AI 生成代码是否有审查机制？技术债是否可控？ | PRD 中无代码审查要求；技术方案含"AI 生成即可用"的假设 |
| False PMF | 用户验证基于行为数据还是言辞？留存指标是否定义？ | 只用满意度调查无行为数据；无留存定义；用户说"喜欢"但无复购/复用证据 |
| Scope Creep | 功能列表是否经过 Effort Test？不做会怎样？ | 功能 > 10 个且无 MVP 边界；无法回答"减半砍哪个"；每个功能都"重要" |
| Insecure by Inexperience | 安全是否纳入开发循环？API key/密钥管理是否有方案？ | 安全仅标注"后续补充"；无数据分级；用户权限无设计方案 |
Effort Test：对每个功能问"不构建会怎样？"— 用户会离开 → 必做 | 抱怨但不走 → 推迟 | 无影响 → 不做。
执行流程：
- 解析输入（文档 → 提取关键信息）
- 对每个维度逐项分析
- 每个维度列出：优势（≥1）+ 问题（≥1）+ 改进建议
- 改进建议标注 P0/P1/P2
- 汇总：总体评价 + 关键发现 + 优先改进项
执行流程
触发 pm-critique
├── 1. 解析输入（Read 文档 / 分析截图）
├── 2. 逐维度分析（6 维度）
├── 3. Iron Law 检查
│ ├── ≥ 3 个改进点？
│ ├── 每个有优先级？
│ └── 基于标准维度？
└── 4. 交付 + 建议下一步（→ pm-prd 改进 或 → pm-tech-spec）
交付前检查
Hard Bans（硬禁令）
以下模式在所有保真度级别均禁止出现。检测到时立即修正。
| # | 禁止模式 | 修正动作 |
|---|
| HB-1 | 评审/回顾只说好话无改进建议 | 补充 >=3 个改进建议并标注 P0/P1/P2 |
| HB-2 | 行动项无负责人或无截止日期 | 每个行动项必须填入负责人和截止日期 |
| HB-3 | 报告/输出超过 1 页且无摘要 | 压缩至 1 页关键信息，详细内容移入附录 |
| HB-4 | 评分/排序中某维度全给满分（无区分度） | 至少有一个维度的得分范围跨越 >=2 个分值 |
| HB-5 | 跳过问题定义直接给方案 | 先输出 1 句话问题概括，经用户确认后再给方案 |
评审问题分级
| 级别 | 标准 | 行动要求 |
|---|
| 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 | {影响} |
