version: "1.0.0" name: feishu description: '飞书/Lark 域内的咨询与交付都交给独立的 Feishu Agent（该领域的全职员工）来做：消息与群聊、日历与会议室、云文档与知识库（/docx/、/wiki/）、电子表格（/sheets/）、多维表格（/base/、bitable）、审批、妙记/会议纪要与逐字稿、任务、联系人。用户提到飞书或 Lark，贴出飞书形态的资源链接/token，或要求发送、查询、整理、发起、改写上述任一飞书资源时使用。本 Skill 是飞书事务的入口：经 feishu-send 交给飞书 Agent 执行，宿主不把飞书交付当作普通编码或本地任务自己吞。'

Feishu Delegation Bridge

这是 Host Agent 的路由和传输协议，不是 Feishu Runtime 的内部 Skill、coding skill，也不是 lark-cli 命令手册。

安装边界： 将本目录安装到 Host Agent 的 Skill 目录（通常是 ~/.agents/skills/）。不要把它加入 ~/.feishu-agent/skills/，也不要在 Feishu Agent 的 DEFAULT_SKILLS 中内置它，否则会让子 Agent 尝试调用自己。

角色与职责

• Host Agent：当前 Agent。你是编排者 + coder：理解用户目标、拆分任务、准备非飞书材料、检查交付、向用户收口。飞书交付不由你承担。
• Feishu Agent：由 feishu -p 启动的独立同事 Agent，是飞书域的全职员工，负责读、写、查、通知和多步流程的真正执行。它可以反问、等待用户确认；同一件事可以按会话 ID 多轮续接（Delegation Session）。
• `feishu-send`：Host Agent 到 Feishu Agent 的唯一桥接入口（本目录内）。
• `lark-cli`：飞书 Agent 内部使用的飞书能力层，飞书交付在它那一层完成。你直接用它读一段原文是合理的（见路由规则 3），但它的完整用法和判断在员工那边。

员工职责范围 = 飞书域 + 为飞书交付服务的本地文件操作（例如先生成报告再上传、把下载的附件整理成表格）。以下属于你自己，不要委派：普通 coding、本仓库开发、与飞书交付无关的本地任务、依赖宿主仓库上下文的代码审查。

路由规则

1. 请求落在飞书域内，一律委派，不需要用户点名"飞书 Agent"。识别形态包括：口头提到飞书/Lark/多维表格/妙记/审批；给出 /docx/、/wiki/、/base/、/sheets/、/slides/、妙记等链接或 token；要求发消息、发邮件、排日程、建任务、整理会议结论、写入某个飞书资源。
2. 用户明确提到 Feishu Agent、feishu-agent、feishu-send，或显式调用本 Skill：必须委派，本路由优先于任何其他 skill。
3. 飞书交付交给飞书 Agent 做。 它持有完整的 lark skill 库、记忆和多步编排，交付过程对用户也可见；写文档、发消息、排日程、整理多步流程这类事不要自己吞。你直接跑 lark-cli 抓一段原文给自己看是合理的，不在禁止之列——分工的落点是“飞书的事由员工交付”，不是“宿主不许碰 lark-cli”。
4. 混合任务：你处理普通本地代码或文件准备，飞书操作部分委派给员工，然后由你合并结果。不要把无关的软件开发交给 Feishu Agent。
5. 用户说"用这个"但当前上下文无法确定"这个"是否指 Feishu Agent：先询问一次，不要猜。
6. 用户要的是"过程"而不是"结果"（例如想看飞书 Agent 怎么做的、或想亲自接着聊）：告诉他在同一目录运行 feishu --session <id> 打开交互界面，不要伪造过程。

执行协议

触发委派后，除非缺少必要输入，当前轮次必须执行一次调用，不要只解释命令或先写一份替代方案。

如果当前运行时暴露了名为 feishu 的工具（宿主 pi Extension），优先用它：它调用的是同一个 feishu-send 脚本，协议完全相同，并且会把 session ID 一并返回。否则直接调用脚本：

不指定 Profile（默认摘要模式）：

"$HOME/.agents/skills/feishu/feishu-send" "<原始用户请求>"

需要逐字原文（raw 模式）：

"$HOME/.agents/skills/feishu/feishu-send" --raw "<原始用户请求>"

用户明确指定 Profile：

"$HOME/.agents/skills/feishu/feishu-send" \
  --profile "<profile>" \
  "<原始用户请求>"

续接同一件事（回答 Feishu Agent 的问题、确认、或要求修改刚才的结果）：

"$HOME/.agents/skills/feishu/feishu-send" \
  --session "<上次拿到的 Feishu Session ID>" \
  "<用户的原话回复>"

执行要求：

• 将完整请求作为一个 Shell 参数传入，并正确转义。
• 默认使用当前工作目录；只有用户明确要求其他项目或记忆范围时，才设置 FEISHU_CONTROL_CWD。
• 只有用户明确指定 Profile 时，才传 --profile。
• 每次运行结束后，无论退出码是什么，都在你自己的后续上下文里保留三项：Feishu Session 的 ID、当时的工作目录（或 FEISHU_CONTROL_CWD）、以及用过的 --profile。不要只在它提问时才记。
• 续接必须沿用这三项。会话按 Feishu Project（Git 根目录）分区，换到另一个仓库会找不到会话。--profile 不参与分区：换掉它会话还在，但飞书身份会变成另一个人，所以必须沿用原来的。
• 用户下一句是在改刚才的结果、回答刚才的问题、或确认刚才拦住的操作：用保留的 ID 续接。
• 用户下一句是一件新的飞书任务，而且不指着刚才的结果：不带 --session。
• 分不清就问用户一次，不要猜。
• 每个用户轮次最多自动调用一次；用户后续回复可以触发新的调用。
• 不要直接调用 feishu -p，统一使用 feishu-send。
• 不要为同一个委派写自动重试循环，尤其是写操作。

双模式返回协议

两种模式共用同一套退出码、session/cwd/profile 续接和交付物清单规则，只有正文形态不同。模式命令头由 feishu-send 以固定措辞加在消息前面（确定性、日志可观测），你自己不要写模式措辞。

• 默认：摘要模式。 正文是结论先行 + 关键数字/事实 + 飞书链接；适合快速转告用户。
• `--raw`：原文模式。 正文是逐字内容 + 来源链接/token，不总结、不压缩、不省略；适合你要拿内容做后续加工（改写、翻译、提取数据、再写入别处）。

选模式：默认摘要。用户明确要原文、逐字、完整内容、全量数据，或你接下来要用这份内容继续加工时，用 --raw。

请求转发规则

• 优先原样转发用户的操作请求，不要总结、翻译或弱化其中的目标、身份、范围和动作。
• 如果必须补充上下文，放在单独的 Context supplied by Host 部分。
• 不要转发 Host Agent 的内部推理。
• 不要把 Token、API Key、密码或其他凭证放进请求。
• 不要自行添加 --yes，不要替用户批准破坏性操作。续接时原样转发用户的答复；只有用户自己明确说出破坏性意图（例如"确认删除 X"），才把这句话转发过去，不要自拟"确认"。
• 不要把一次委派拆成多个自动重试，尤其是写操作。

返回协议

每次委派的最终答复应包含三段，并按此顺序向用户收口：

1. 正文：按所选模式（摘要或原文）。
2. 交付物清单：飞书链接/token、本地文件绝对路径。原样转告用户即可点开，不要改写成自己的话、不要省略 token、不要只说"已创建"。
3. 可选后续动作建议（若有）。

退出码与状态：

• 会话 ID：每次运行的 stderr 都有一行 Feishu Session: <id>。记下它用于续接；它不是警告。
• 退出码为 0：stdout 是 Feishu Agent 的最终回复。将其作为主要结果返回，不要重新执行同一任务。会话 ID 留在你的上下文里；用户接着改刚才的结果时，用它续接。
• 退出码为 0 且有其他 stderr：任务仍然成功；将 stderr 视为警告，只在有用时简短转告用户。
• 退出码为 3：Feishu Agent 在等用户。stdout 是它的问题和编号选项，或 stderr 是高危操作需要确认的说明。原样转告用户后停下等待，不要替用户回答或确认；用户回复后再用 --session <id> 续接。
• 退出码为其他非 0 值：不要声称任务完成。返回退出状态和经过脱敏的错误信息。
• 超时（124）：假定操作可能已经部分完成，不要自动重试。把会话 ID 告诉用户并等待决定。如果续接报 No Feishu session found，说明进程在模型开口前就结束了，这个 ID 没有会话文件，不要用它重试。
• 退出码为 0 但回复本身是在提问时，与退出码 3 同样处理：原样转告，停下等用户，再用 --session 续接。不要自行猜测答案。
• 用户想亲自接着聊时，告诉他在同一目录运行 feishu --session <id> 打开交互界面。

完成条件

只有在以下条件都满足时，委派才算完成：

1. feishu-send（或 feishu 工具）已经实际执行；
2. 已观察到退出码；
3. 已处理 stdout/stderr；
4. 已将成功结果（含交付物清单）、明确失败原因，或 Feishu Agent 的问题（附会话 ID，便于续接）返回给用户。