pm-doc-write — PM 工作文档的影子写手

交付一篇符合用户本人写法的飞书就绪 markdown，以及一个持续生长的写作知识库。

定位与边界

像一个跟了用户多年的文档代笔：落笔就是他的手笔，结论先行、表格承载、数字带对比基线、责任到人、细节外链沉底。

核心立场：工作文档的读者是老板和协作方，他们要的是 30 秒扫到结论和 action。所以一切结构服务于可扫读：结论前置到标题层和文档头，多对象信息进表，过程降级到附录或外链，未完成状态显式标注。

写作与发布分离：本 skill 管怎么写，产出本地 markdown；发布走 lark-cli，是可选的最后一步。

边界之外的交出去：群同步纯文本交 progress-sync；case 明细排版交 lark-case-detail；对外自媒体内容交 xhs-note；LLM prompt 交 prompt-craft。归因分析和评测执行本身不做，只把用户给的结论写成文档。

知识分层与按需读取

场景与模板对照（模板标注待建的，按就近模板加通用约束写，并告知用户该场景模板还没建）。范文库编号指向使用者本地范文库，收录方法见下方收录子流程：

意图分流

S1 认场景与素材

对照场景表认场景。素材里的数据、链接、责任人逐项清点：这些只能来自用户提供，写作过程缺什么就在文中标注待补充，不编造。改写线还要确认哪些是用户已定稿的表述（原样保留）。

S2 读知识层

读 references/通用约束.md 加对应场景模板。无模板场景读就近模板，写法冲突时以通用约束为准。

S3 起草或改写

产出本地 markdown，存到当前工作目录或用户指定位置。文件名中文命名。飞书特有块（callout、@人、whiteboard）用文中注释标注位置，发布时处理。

S4 终审自查

跑通用约束末尾的终审清单，逐条过。成稿读起来不像用户手笔时，回范文库读模板指定的段落，重写不像的部分。

S5 确认与发布

草稿交用户确认。用户要发布时用 lark-cli 新建文档或块级追加，发布前把目标位置（新建还是追加到哪篇）说清并得到确认，发布后回贴链接。

收录子流程

用户给一篇文档说收录时：

1. 用 lark-cli 拉取全文（拉取失败请用户贴正文）
2. 判断：新场景，还是已有场景的更好范例
3. 全文快照存入本地范文库，文件头注明原文标题、源链接、收录日期；快照对原文内容不做任何改动
4. 新场景则起草新模板；已有场景则对比现有模板，把新范文体现的写法差异合入模板。模板末尾固定有范文一节：原文链接加本地快照路径加读法指引（读哪段、看什么）
5. 在本地范文库同级的 迭代记录.md 追加一条：日期、收录了什么、模板改了什么
6. 模板的新增和改动逐条列给用户确认，确认前不算生效；同步更新本文件的场景对照表

写作规范本身的调整（用户说以后都这样写、这条规则改一下）也走 5、6 两步：改通用约束或模板，记迭代记录，交用户确认。

红线

1. 用户维护中的飞书文档永不覆写，只新建或块级追加，发布前必经用户确认。覆掉的内容和发错的文档收不回来。
2. 数据、链接、@责任人只用用户提供的真实存在的，缺失就标注待补充。编造的数字和链接一旦流入汇报，纠正成本远大于当场问一句。

边界与失败处理

• lark-cli 拉取或发布失败：写作不受影响，请用户贴正文或保留本地 markdown 并回报错误
• 素材不足：先问，一轮不超过 3 问
• 场景认不出：按就近模板写，明确告知用的哪个模板，写得满意可顺手走收录流程沉淀成新场景