# Feishu Report Delivery

> 当用户要求“发到飞书”“飞书发我”“飞书汇报我”“同步到飞书”“把文件发给我”“把交付件发我”时，使用这个 skill。它负责把本轮工作汇报和交付件按固定顺序发送到飞书：先发简洁汇报，再发最终文件，并在发送后向用户回报实际发送结果。即使用户只提到“发我”或“汇报一下”，只要上下文明确是在飞书里收消息或文件，也应优先触发本 skill。

- Skill: `josephcooperhc/feishu-report-delivery` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add josephcooperhc/feishu-report-delivery`
- Raw SKILL.md: https://api.skillmd.com/api/skills/josephcooperhc/feishu-report-delivery/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: JosephCooperHC (https://skillmd.com/u/josephcooperhc)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/josephcooperhc/feishu-report-delivery

---


# Feishu Report Delivery

这个 skill 用来把当前工作结果稳定地发到 Boss 的飞书，而不是每次临时拼命令。

## 开始前

先读取这两个技能：

1. [`../lark-shared/SKILL.md`](../lark-shared/SKILL.md)
2. [`../lark-im/SKILL.md`](../lark-im/SKILL.md)

原因：
- `lark-shared` 定义了身份、配置目录、授权与权限处理。
- `lark-im` 定义了消息和文件发送的正确方式。

## 默认约定

- 默认配置目录：`~/.lark-cli`
- 默认身份：`--as bot`
- 默认接收人 open_id：`ou_ed5490b8ab932ae9c8823199aeda1f6a`
- 默认发送顺序：`汇报消息 -> 主交付件 -> 补充交付件`

只有在用户明确指定别的聊天对象、群聊或发送顺序时，才覆盖这些默认值。

## 什么时候用

在这些场景直接用：

- 用户说“飞书发我”
- 用户说“把这个发到飞书”
- 用户说“飞书汇报我一下”
- 用户要求把 PDF、Markdown、截图、报告等交付件发给他
- 用户要求“重新发一次”“补发到飞书”

不要在这些场景触发：

- 用户只是让你本地生成文件，还没要求发送
- 用户是在讨论飞书文档内容编辑，这类优先用 `lark-doc`

## 目标

每次发送都完成这三件事：

1. 让 Boss 先看到一句能快速判断进展的汇报
2. 让 Boss 直接拿到最终交付件，而不是中间产物
3. 在对话里回报真实发送结果，而不是口头假设“已经发了”

## 工作流

### 1. 收敛本轮要发的内容

先从当前上下文提取：

- 本轮交付结论是什么
- 哪些文件是最终交付件
- 哪些只是中间文件，不该发

默认只发送最终产物。不要把临时预览、渲染中间件、调试截图一起塞给用户，除非用户明确要看。

### 2. 组织汇报文案

汇报文案保持短、可扫描、像工作汇报，不像日志。

优先包含：

- 这轮完成了什么
- 发了哪些文件
- 是否有风险或待确认点

推荐长度：

- 1 句总述
- 0-2 句补充

如果只是补发同一个文件，汇报可以更短，例如：

- `最新版 PDF 已补发，发的是修复分页后的版本。`

### 3. 发送

优先使用脚本：

```bash
python3 /Users/josephcooper/.codex/skills/feishu-report-delivery/scripts/send_delivery.py \
  --summary "最新版 PDF 已补发，发的是修复分页后的版本。" \
  /abs/path/to/final.pdf
```

如果脚本不适用，再回退到原生命令：

```bash
LARKSUITE_CLI_CONFIG_DIR=~/.lark-cli \
  lark-cli im +messages-send --as bot \
  --user-id ou_ed5490b8ab932ae9c8823199aeda1f6a \
  --text "汇报内容"
```

然后逐个发送文件：

```bash
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：补发

输入：
- “再发一次飞书”

动作：
- 不重新生成文件
- 直接补发最新最终版
- 说明这是补发