| name | source-to-spec |
| description | 把 PDF / 飞书文档 / 会议纪要 / 长文本收敛成"可落地需求"spec(与 slack-to-spec 同一套模板)。当用户说"把这份文档/纪要/PDF 整理成需求 / 出个 spec"时触发。抽取需求点、决策(含被推翻方案)、待定问题,产出结构化、可追溯、能直接喂开发的 markdown。 |
source-to-spec — 文档/纪要 → 可落地需求
slack-to-spec 的姊妹篇:输入从 Slack 换成 PDF / 飞书 doc / 会议纪要 / 任意长文本,产出同一套 spec。
核心同样不是"总结",而是 抓决策(尤其被推翻/取代的方案)+ 拎隐藏的开发需求 + 划开工红线。
何时触发
用户说"把这份文档/纪要/PDF 整理成需求 / 出个 spec / 这个会议纪要拆成开发任务"。
用法
/source-to-spec <文件路径或粘贴的内容>
流程
- 读源:
- PDF / 图片 / Word → 直接读(读不到的扫描件如实标"待补",不臆造)。
- 飞书 doc → 有飞书 MCP 就用工具读正文;否则请用户导出/粘贴。
- 纯文本 / 会议纪要 → 直接处理。
- 多个来源 → 合并,并在 §来源 标清每条出处。
- 抽取:需求点、决策(谁拍的板/依据/有没有反转)、待定问题、隐藏需求(一句"目前没有,需后续做"要升级成 AC)。
- 合成 spec:按下面模板产出。
- 落盘 + 报告:写到
<topic-slug>-spec.md(或问用户放 docs/prd//docs/plans/);报告读了什么、明确列出"读不到、需人补"的缺口。
Spec 模板
# <需求名> — 可落地需求 (Spec)
> 来源:<文件名/会议名/日期>
> 状态:草稿 V0.1(待 <对齐节点> 拍板)
## 1. 背景 / 要解决什么
## 2. 决策日志 ★最容易丢 / 核心
| # | 决策 | 结论 | 拍板人 | 依据/时间 | 被撤销/取代的方案 |
|---|---|---|---|---|---|
> 反转/撤销单独标出(删除线 + 取代时间)——回溯"为啥这么定"的关键。
## 3. 需求点(可验收)
### 3.x <模块> — P0/P1,<负责人>
- [ ] ACn: <可测的描述>
## 4. 影响面 / Blast radius
## 5. 开放问题(未拍板,别开工对应模块)
## 6. 时间线
## 7. 来源(可回溯)
- <出处:文件名 + 页码/章节;读不到的标"待补">
硬规则
- 决策日志必须有"被撤销/取代的方案"——上午定下午改的要留痕 + 注明时间。
- 区分可读 vs 不可读来源:读不到的(扫描件/加密 PDF)如实标缺口,绝不编。
- 不臆断:拿不准标"待确认/待补"。
- 拎隐藏需求:埋在长文里的"需后续开发"升级成明确 AC。
- 划开工红线:未拍板的(端选型/合规/金额/命名)进 §5,标"别开工对应模块"。
- 产出中文 + 英文,不引入其他自然语言。
- 只读 + 只产出本地文档,不碰任何线上系统。
衔接
spec 出来后,可直接喂 writing-plans skill 出开发计划 → TDD 执行。
与 slack-to-spec 共用模板;来源是 Slack 频道时用那个。
