source-to-speclisted

# 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 模板 ```markdown # <需求名> — 可落地需求 (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-to-spec) 共用模板;来源是 Slack 频道时用那个。