source-to-spec

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 <文件路径或粘贴的内容>

流程

1. 读源:
   • PDF / 图片 / Word → 直接读(读不到的扫描件如实标"待补",不臆造)。
   • 飞书 doc → 有飞书 MCP 就用工具读正文;否则请用户导出/粘贴。
   • 纯文本 / 会议纪要 → 直接处理。
   • 多个来源 → 合并,并在 §来源 标清每条出处。
2. 抽取:需求点、决策(谁拍的板/依据/有没有反转)、待定问题、隐藏需求(一句"目前没有,需后续做"要升级成 AC)。
3. 合成 spec:按下面模板产出。
4. 落盘 + 报告:写到 <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. 来源(可回溯)
- <出处:文件名 + 页码/章节;读不到的标"待补">

硬规则

1. 决策日志必须有"被撤销/取代的方案"——上午定下午改的要留痕 + 注明时间。
2. 区分可读 vs 不可读来源:读不到的(扫描件/加密 PDF)如实标缺口,绝不编。
3. 不臆断:拿不准标"待确认/待补"。
4. 拎隐藏需求:埋在长文里的"需后续开发"升级成明确 AC。
5. 划开工红线:未拍板的(端选型/合规/金额/命名)进 §5,标"别开工对应模块"。
6. 产出中文 + 英文,不引入其他自然语言。
7. 只读 + 只产出本地文档,不碰任何线上系统。

衔接

spec 出来后,可直接喂 writing-plans skill 出开发计划 → TDD 执行。 与 slack-to-spec 共用模板;来源是 Slack 频道时用那个。