// the find
larksuite/cli
The official Lark/飞书 CLI tool, maintained by the larksuite team — built for humans and AI Agents. Covers core business domains including Messenger, Docs, Base, Sheets, Calendar, Mail, Tasks, Meetings, and more, with 200+ commands and 20+ AI Agent Skills.
The official CLI for Lark/Feishu's Open Platform, covering calendar, docs, base, sheets, mail, meetings and more through 200+ commands, built explicitly to be driven by AI agents (via bundled Skills) as much as by humans typing commands. It's useful if your org runs on Lark/Feishu and you want to script it or wire an agent into it; irrelevant otherwise.
The three-layer command system (shortcuts -> generated API commands -> raw API) is a real design decision, not marketing fluff — you get ergonomic defaults for common tasks but can drop to any of 2500+ raw endpoints without switching tools. The JSON output contract explicitly separates its own success/error envelope from the upstream OpenAPI response codes, with a documented error taxonomy (ERROR_CONTRACT.md) instead of the usual 'figure it out from the response shape' approach. Auth handling goes further than most API wrappers: OS-native keychain storage, DPoP token binding as an option, and device-code flows for non-interactive agent use. The test tree shows architectural enforcement (arch_test.go, lint_test.go, golden-file tests for event schemas) rather than tests that only check happy paths.
It only has value inside the Lark/Feishu ecosystem — zero crossover utility for Slack, Teams, or anything else, so the audience is narrow by definition. By default it sends OS type and device hardware model to Feishu's domains for 'risk control'; there's an opt-out flag but it's telemetry enabled out of the box, worth flagging before anyone wires this into an automated pipeline. The README's own security section admits an agent given OAuth scope here can send mail, post messages, and touch calendars under your identity, and the stated mitigation ('don't add it to group chats') is thin given how directly it invites prompt-injection risk. Building from source needs Go 1.23+ and Python 3 even though the primary distribution path is npm, so the two install stories diverge more than the README implies.