| name | review_product_design_from_rd |
| description | RD 从'技术可行性 + 实现成本'视角评审 PM 的 product_spec.md。当 RD 收到 type=review_request 且 subject 含'产品设计'的邮件时**一定**加载本 skill。评估功能是否 FastAPI+SQLite 栈内实现、给估时、标黑洞、建议砍/延后 → reviews/product_design/rd_feasibility.md + review_done。所有'RD 看产品设计'的时刻走此 skill。 |
| type | reference |
review_product_design_from_rd — RD 视角评审产品设计
🚨 Critical Rules
- 估时要具体：以小时为单位；"有难度"不是估时。
- 黑洞显性化：批量导入、全文搜索、WebSocket、第三方 OAuth 等需明确点名。
- 建议砍/延后要给出 MVP 能否成立的判断：不能只说"建议延后"。
步骤
Step 1 — 读文件
read_shared(pid, "needs/requirements.md")read_shared(pid, "design/product_spec.md")
Step 2 — 逐条 MVP 功能评估
按下面矩阵打分：
| 指标 | 评估方式 |
|---|
| 可行性（1-5） | 栈内可直接实现 → 5；需新库 → 3；需基础设施 → 1 |
| 实现估时（h） | 以"一个熟悉该栈的中级 RD 独立完成"为基准 |
| 风险（L/M/H） | 性能、数据一致性、外部依赖 |
Step 3 — 识别黑洞
关键词清单：
- 批量导入/导出 / 大文件处理
- 全文搜索 / 模糊匹配
- 实时推送 / WebSocket
- 第三方 OAuth / 支付接入
- 多端协同编辑
命中 → 写到 Issues。
Step 4 — 写评审报告
# 产品设计评审（RD 视角）
## Verdict: pass | revise
## 总估时：X 人时
## 逐条评估
| 功能 | 可行性 | 估时(h) | 风险 | 备注 |
|------|--------|---------|------|------|
## 技术黑洞
- ...
## 建议（砍 / 延后 / 改方案）
- ...
write_shared(pid, "reviews/product_design/rd_feasibility.md", report)
Step 5 — review_done + self_score
同其他 review skill。
输出
{
"status": "success",
"artifacts": [{"path": "reviews/product_design/rd_feasibility.md"}],
"metrics": {"verdict": "revise", "total_estimate_hours": 24, "blackholes": 2, "suggestions": 3},
"self_score": 0.82,
"breakdown": {...}
}
