给 Coding Agent 接飞书：一个 Skill，按需加载
Lark CLI Progressive Skill 把飞书能力收成一个入口，任务来了再加载对应领域指南
如果你想让 Coding Agent 帮你查飞书日程、找文档、发消息，最容易踩的坑不是配置 OAuth。
是上下文。
官方 Lark CLI 把能力拆成很多领域 Skill：日历、IM、文档、云盘、Base、审批、任务、邮件、知识库，甚至会议纪要和实时事件。它们当然都很有用。但绝大多数请求只会碰其中一两个。
于是有个很朴素的问题：
我只是想问“今天有什么会”，为什么 Agent 要先背完云盘权限、审批流和多维表格的说明？
Lark CLI Progressive Skill 的答案很直接：只让 Agent 发现一个 lark Skill，其余二十多个领域指南留在包里，等任务真的命中时再读。
这不是阉割版 CLI。能力还在，只是不在启动时挤进上下文。
安装方式
推荐直接把这段 Prompt 交给 Coding Agent。它会完成单一 lark Skill 的全局安装；若机器上已有旧版 lark-* Skills，只迁移来源可验证的官方项。
请阅读 https://github.com/OiAnthony/lark-cli-progressive-skill 的 README，并按其中推荐流程为我完成全局安装。使用单一的 lark Skill；如发现旧版 lark-* Skills，先检查并只迁移来源可验证的官方项，保留未知或第三方项。不要安装上游完整 Skill bundle。想手动安装时，仍按这个顺序执行：
npm install -g @larksuite/cli@latest
npx skills add OiAnthony/lark-cli-progressive-skill --skill lark -g -y不要运行 lark-cli update，也不要和官方完整 Skill bundle 混装。前者会重新装回完整 bundle，后者会把按需加载省下来的上下文又占回来。
用起来是什么感觉
你不需要先研究飞书 API，也不用记住是 lark-calendar 还是 lark-vc。
直接说人话：
列出我今天的日程，找出空闲的 30 分钟，并约一个产品评审会。Agent 会先读日历领域的指南，再按当前 lark-cli --help 和命令 schema 执行。需要创建会议室时，还是日历。需要查已经结束的会议纪要，才转到会议领域。
再比如：
在项目群里找上周提到过的发布计划，把相关文件下载到当前目录。这里才会依次用到 IM 和 Drive。不是一上来把它们和 Base、Mail、OKR 一起装进脑子里。
这种路由看起来小，实际决定了 Agent 接下来会不会稳定。领域边界被写清楚后，它知道“待办”该去 Task，“审批待办”该去 Approval，“下周会议”该去 Calendar，“会议产物”该去 VC。少靠猜，少走错服务。
它解决的不是安装，而是默认成本
很多工具的安装说明会把“功能完整”当成“默认全加载”。对人类 IDE 这没有太大问题，对 Context 有上限的 Coding Agent 却是持续税。
这个项目把结构反过来：
用户请求
↓
lark Skill 判断领域
↓
只读取当前任务需要的 GUIDE.md
↓
根据实时 CLI help 和 schema 执行有两个细节很对味。
第一，领域指南是内置快照，不需要每次需求来了再联网安装一个 Skill。第二，执行时仍要求先看当前 CLI 的 --help 和 schema，不把文档里的历史参数当事实。
前者减少装配摩擦，后者避免 Agent 一本正经地调用过期参数。
该装给谁
如果你已经把 Coding Agent 当成飞书里的操作员，这个包很合适：查日程、搜群消息、整理文档、上传文件、维护 Base、创建任务，都是它的日常工作。
如果你只是偶尔打开飞书网页，或者不使用支持 Skills 的 Agent，就没必要为了这个再加一层工具。
它也不适合和官方完整 Skill bundle 混装。两套同时存在，按需加载的意义就没了。
账号和副作用，还是人说了算
首次连接账号时仍需要完成应用配置和授权。这是正常的。Skill 解决的是 Agent 如何理解和调用飞书，不会绕过你对账号、scope 和外部操作的控制。
项目对发送消息、删除资源、改权限、审批等有副作用的动作保留确认边界，也明确不让 Agent 从聊天内容或 CLI 输出里“捡”到授权。
我喜欢这种收敛：一个入口，按需拿说明，实时确认命令，再把副作用留给人确认。
如果你正在给 Coding Agent 接飞书，先试试这个。别让它为了查一场会，先把整个飞书都背下来。