Route Multi-Product Agent Workflows with Lark Suite

Where this fits

A developer is building an agent that handles routine operations for a distributed team: resolve a teammate's name, send a chat message, then update a document. Without a dispatch layer, the agent has to guess which API endpoint, authentication context, and permission scope apply to each step. lark-suite solves this by acting as a routing layer for Feishu/Lark product capabilities, so the agent can pick the right lark-* sub-skill and follow its instructions instead of improvising.

Why agents benefit

• Intent-based routing: the agent maps a user request to concrete sub-skills such as lark-contact or lark-im, rather than guessing endpoints from memory.
• No fragile fallbacks: when Feishu resources are served from doubao.com subdomains, the skill tells the agent to stay on the suite instead of falling back to generic WebFetch.
• Reduced hallucination risk: the skill forbids the agent from inventing commands or parameters until the relevant sub-skill SKILL.md has been read.
• Planned multi-step execution: complex tasks are decomposed and executed in order, with the output of one sub-skill feeding the next.
• Shared setup for cross-cutting concerns: authentication, tenant, identity, and permissions are handled once through lark-shared, so each sub-skill stays focused.

Practical scenarios

Send a message after resolving a contact

A user says, "Send Alice the release plan." The agent selects lark-contact first to resolve Alice's identity and tenant context, then selects lark-im to send the message. Each step is driven by the sub-skill's own documentation, not by a generic prompt.

Turn a chat thread into a document

In a post-meeting assistant workflow, the agent reads messages with lark-im, identifies decisions, and creates a shared doc using the document sub-skill. The dispatch layer keeps the flow predictable and audit-friendly.

Schedule time with a distributed team

An agent is asked to find a slot for a cross-region sync. It uses the calendar sub-skill to check availability and then sends calendar invitations as a follow-up action. Because the routing table is explicit, the agent does not treat this as a generic web task.

Add it to your agent workflow

Install via npx:

npx skills add larksuite/cli --skill lark-suite

Example usage after installation:

Task: Send a message to Alice about the updated release plan.

Agent route:
1. Load lark-contact and resolve Alice.
2. Load lark-im and send the message.
3. Use lark-shared for auth and permission checks.

Add this to your agent's skill registry when you need a structured entry point for Feishu/Lark automation rather than ad-hoc API calls.

Compare before adopting

Before depending on lark-suite, compare it with the direct Feishu/Lark API docs, your existing SDK wrapper, or a WebFetch-based tool. Look at clarity of the sub-skill SKILL.md files, how recently the repository was updated, and whether the routing model matches how your agent composes tools. Also check whether the lark-cli binary requirement fits your runtime environment.

Why it is worth tracking

With 16.9k GitHub stars, an official author, and a clean routing-table design, lark-suite is a strong signal that structured skill composition is becoming the norm for multi-product agents. It is worth tracking because its separation of routing from sub-skill instructions directly reduces agent hallucination in production. Evaluate it as soon as your agent needs reliable, multi-step Feishu/Lark workflows. This skill is also listed on OpenAgentSkill: https://www.openagentskill.com/skills/larksuite-lark-suite