JosephCooperHC Feishu Report Delivery
这个 skill 用来把当前工作结果稳定地发到 Boss 的飞书，而不是每次临时拼命令。
开始前
先读取这两个技能：
原因：
lark-shared定义了身份、配置目录、授权与权限处理。lark-im定义了消息和文件发送的正确方式。
默认约定
- 默认配置目录：
~/.lark-cli - 默认身份：
--as bot - 默认接收人 open_id：
ou_ed5490b8ab932ae9c8823199aeda1f6a - 默认发送顺序：
汇报消息 -> 主交付件 -> 补充交付件
只有在用户明确指定别的聊天对象、群聊或发送顺序时，才覆盖这些默认值。
什么时候用
在这些场景直接用：
- 用户说“飞书发我”
- 用户说“把这个发到飞书”
- 用户说“飞书汇报我一下”
- 用户要求把 PDF、Markdown、截图、报告等交付件发给他
- 用户要求“重新发一次”“补发到飞书”
不要在这些场景触发：
- 用户只是让你本地生成文件，还没要求发送
- 用户是在讨论飞书文档内容编辑，这类优先用
lark-doc
目标
每次发送都完成这三件事：
- 让 Boss 先看到一句能快速判断进展的汇报
- 让 Boss 直接拿到最终交付件，而不是中间产物
- 在对话里回报真实发送结果，而不是口头假设“已经发了”
工作流
1. 收敛本轮要发的内容
先从当前上下文提取：
- 本轮交付结论是什么
- 哪些文件是最终交付件
- 哪些只是中间文件，不该发
默认只发送最终产物。不要把临时预览、渲染中间件、调试截图一起塞给用户，除非用户明确要看。
2. 组织汇报文案
汇报文案保持短、可扫描、像工作汇报，不像日志。
优先包含：
- 这轮完成了什么
- 发了哪些文件
- 是否有风险或待确认点
推荐长度：
- 1 句总述
- 0-2 句补充
如果只是补发同一个文件，汇报可以更短，例如：
最新版 PDF 已补发，发的是修复分页后的版本。
3. 发送
优先使用脚本：
python3 /Users/josephcooper/.codex/skills/feishu-report-delivery/scripts/send_delivery.py \
--summary "最新版 PDF 已补发，发的是修复分页后的版本。" \
/abs/path/to/final.pdf
如果脚本不适用，再回退到原生命令：
LARKSUITE_CLI_CONFIG_DIR=~/.lark-cli \
lark-cli im +messages-send --as bot \
--user-id ou_ed5490b8ab932ae9c8823199aeda1f6a \
--text "汇报内容"
然后逐个发送文件：
LARKSUITE_CLI_CONFIG_DIR=~/.lark-cli \
lark-cli im +messages-send --as bot \
--user-id ou_ed5490b8ab932ae9c8823199aeda1f6a \
--file ./artifact.pdf
发送规则
- 永远先发汇报消息，再发文件
- 文件按用户最关心的优先级排序，通常
PDF > Markdown > 其他 - 如果同一文件刚发过，而用户没有要求重发，不要重复刷屏
- 如果文件不存在、不是最终版、或你还没核对过，不要发送
- 不要谎报“已经发到飞书”；只有命令成功后才能这么说
发送后回报
发完后，向用户回报：
- 发了哪些东西
- 对应文件路径
- 发送结果来自真实命令执行，而不是推测
如果脚本返回了本地时间戳，也可以一并汇报。
失败处理
如果失败，优先判断是哪一类：
- 授权 / scope / 可见范围问题
- bot 不在目标会话
- 文件路径不存在
- 文件还没生成好
处理原则：
- 不要静默失败
- 不要把失败伪装成成功
- 明确告诉用户卡在哪一层
输出风格
对用户的汇报要像工作交付，不要像调试日志。
好例子：
已经发到飞书了，包含说明消息和最终 PDF。这次补发的是修复分页后的版本。
差例子：
执行了 lark-cli 命令，返回 code 0。我调用了 messages-send。
典型示例
示例 1：发一份 PDF
输入：
- “通过飞书发我”
动作：
- 组织一句简报
- 发送说明消息
- 发送 PDF
- 在对话里回报发送结果
示例 2：发一份汇报和多份交付件
输入：
- “改完飞书发我，PDF 和 markdown 都发”
动作：
- 发送汇报
- 发送 PDF
- 发送 Markdown
- 回报实际发送结果
示例 3：补发
输入：
- “再发一次飞书”
动作：
- 不重新生成文件
- 直接补发最新最终版
- 说明这是补发