feishu-im-send

Files (7)

• SKILL.md
• gitea-pr-review.md · references/
• identities.md · references/
• message-shapes.md · references/
• troubleshooting.md · references/
• urgent-messages.md · references/
• feishu-send · scripts/

SKILL.md (first lines)

# 用最短安全路径发送飞书群消息

## 目标

把一次飞书消息发送收敛成不可变计划：

`接收方(群 oc_ 或人 ou_) + identity + content flag + 完整正文 + idempotency key`

先用该计划 dry-run，用户确认后只移除 `--dry-run` 执行。不要在确认后重新拼正文、换身份或重新选接收方。

所有命令都带下面两个环境变量，避免 notifier 污染 JSON：

```bash
LARKSUITE_CLI_NO_UPDATE_NOTIFIER=1 LARKSUITE_CLI_NO_SKILLS_NOTIFIER=1
```

已验证命令：

- 群名查找：`lark-cli im +chat-search`
- 已知 ID 校验：`lark-cli im chats get`
- 浏览已加入群：`lark-cli im +chat-list`
- 发送：`lark-cli im +messages-send`（不是 `+messages-create`）

不要为发现命令而运行 `--help`、`schema`、`whoami` 或 `profile list`。认证或权限失败时才读 [references/troubleshooting.md](references/troubleshooting.md)。

## 先确定这条消息要完成什么（动笔前必做）

**这是本 skill 的第一步。** 安全流程只解决"怎么发"，本节解决"发什么"。跳过本节，消息必然滑向全面汇报。

发送前在内部确定四项，能从上下文推断时**不得额外追问**；只有目标动作会因歧义而改变时才问：

1. **主读者**：这条消息给谁看？他带着什么背景，最想得到什么？
2. **消息类型**：结果通知 / 状态同步 / 决策请求 / 行动指派 / 纠错 / 邀请提醒。用户说"结论""结果""评审完了"时默认按**结果通知**处理，不按过程汇报处理。
3. **一句话核心**：读者看完能复述的那一句。必须能放在第一行；若第一行仍是"审查了/验证了/我们做了"，说明写成了过程，重写。
4. **读者下一步动作**：读完要他去做什么（合/不合/改哪里/等谁）。

判断消息类型与正文形态：见 [references/message-shapes.md](references/message-shapes.md)。

## 正文契约：发结果，不发生产结果的过程

默认正文顺序：**结论/变化 → 影响对象 → 需要谁做什么 → 必要链接。**

- 只保留足以支持行动的关键理由。**工具名、模型名、审查方法、运行过的命令、测试数量、已排除的误报、完整验证清单、审查者自评，默认不发**。用户明确要求报告过程时才加入。
- 测试失败若直接构成阻断，可作为一句证据；"所有测试都跑过"的过程清单不占消息主体。
- 内部代号、选项编号（A/B）、严重度（P0/P1）只有在接收者已共享该上下文且需要据此决策时才保留；否则展开成直接动作。
- 默认不用 emoji、连续粗体小标题、水平分隔线、"总评/验证/已核实为误报"专段和礼貌性夸奖。格式服务扫描，不替代判断。
- 不设僵硬字数门槛，以"删掉后是否影响读者行动"为取舍标准。复杂细节放 PR 评论或文档，群消息给链接。

## 内容闸门（prepare 之前必过）

正文未过以下检查，不得 `prepare`。这里是**语义检查**；脚本的 `dry-run` 仍只负责请求形状和安全，两件事互不替代。

- 第一行是结论吗？（不是"我审查了/验证了"）
- 明确说了能合 / 不能合 / 需谁处理吗？
- 混入生产过程的工具名、模型名、测试清单、误报澄清了吗？
- 出现接收者不懂的编号或术语了吗？（有就展开）
- 有无关的总评/自评/升华吗？
- 删掉一半，读者的行动会损失吗？不会就删。

## 改稿与确认

- 首次生成后先过内容闸门，再 `prepare`。
- 用户拒绝已 `prepare` 的正文并进入连续改稿时，旧计划**永不 commit**；先在草稿阶段完成措辞迭代，**不要每改一个词就 prepare 一次**。用户表示正文定稿后，才创建一个新计划。
- 新计划 dry-run 后仍需给一次最终确认——不能把定稿前的"就这样发"当作最终确认，这是保留安全边界所需的一次重复。
- 最终确认只重复**目标名称 + 完整正文**，不重复技术元数据（见下节确认模板）。

## 先收齐输入

开始任何 CLI 调用前，确定：

- 目标群名或 `oc_xxx`；
- 完整消息正文（已过内容闸门）；
- 身份（两层决策，详见 [references/identities.md](references/identities.md)）：
  - **profile**：由操作者明确选择，并在每次调用中显式传入 `--profile`；绝不按项目名、当前 active profile 或本地记录猜测。
  - **bot/user 类型**：由用户要求和当前 profile 的已验证权限决定；不试探性切换身份。
  - 人格：只有操作者已配置某个可公开的 persona skill 时才加载；人格不能覆盖结论、授权或确认门槛。
- 若为 Gitea PR review：PR URL 或 `owner/repo#N`，以及用户要求的 review 重点。

缺多项时一次问齐，不逐项追问。用户已经给出的 review 重点直接使用，不重复询问，不编造缺失重点。

## skill 路径约定

本文中的 `scripts/...`、`references/...` 均以当前 `SKILL.md` 所在目录为 skill 根目录。调用脚本前，用 `skill://feishu-im-send/scripts/feishu-send` 内部 URL 解析为实际文件路径（宿主自动解析到 FS 路径），再通过工具 env 传为 `SCRIPT`。`SCRIPT` 不是预置 shell 变量，也不得从 `$PWD`、HOME 扫描或固定安装目录猜测。

## 接收方定位：一次调用后必须停止或继续，禁止搜索循环

搜索和发送必须使用同一个 `--as user|bot`。不要为 user 发送去搜 bot 的接收方，反之亦然。

### 发给个人（`ou_xxx` 或姓名）

用户明确要发私聊，或给了 `ou_xxx`：
- 给了 `ou_xxx`：用 `+get-user` 校验并取得姓名（`USER` 走环境变量）。
- 只给姓名：用 `lark-cli contact +search-user --query "<姓名>" --as user` 搜出 `ou_xxx`，列出候选让用户选（可能同名）。

### 用户给了 `oc_xxx`（群）

用 `feishu-send prepare` 内部校验（脚本用 argv 传参，用户输入不进 shell 源码），无需手写 `chats get`：

```bash
SCRIPT=$(readlink -f "skill://feishu-im-send/scripts/feishu-send")
printf '%s' "$MSG" | "$SCRIPT" prepare --chat-id '<oc_xxx>' --identity user --profile '<explicit-profile>' --content-format markdown
```

`prepare` 内部会 `chats get` 校验 `chat_status == "normal"` 并捕获群名；失败原样报错，不猜群。

### 用户给了群名

只按群名搜索发送身份已经加入、因而可能发送的群。**搜索关键词走环境变量，禁止用文本替换拼进命令**：

```bash
# 群名经 bash 工具的 env 参数传入（如 env: {GROUP: "..."}），命令只引用 "$GROUP"；
# 不要用文本替换拼进 --query 源码
lark-cli im +chat-search --query "$GROUP" \
  --disable-search-by-user \
  --search-types private,public_joined,external \
  --page-size 100 \
  --as '<user|bot>' \
  --format json
```

From stofancy/agent-skills, MIT.

More from stofancy/agent-skills