Agent skill

Openlark API

by foxzool in foxzool/openlark

OpenLark 项目 API 接口实现规范(速查)。用于添加/重构飞书开放平台 API:确定落盘路径、实现 Body/Response + Builder(Request)、对齐 endpoints 常量/enum、补齐 mod.rs 导出,并明确"调用服务端 API"的方法签名/RequestOption 传递约定。触发关键词:API 接口、API 文件、飞书 API、添加…

Apache-2.0Auto-check: notesProductivity & Automation

Install Openlark API

skills CLI
$ npx skills add foxzool/openlark --skill openlark-api -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install foxzool/openlark openlark-api --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/foxzool/openlark.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/openlark-api .claude/skills/openlark-api && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
openlark-api
GitHub stars
106
Token cost
~3k tokens
SKILL.md length
611 words
Files
6 (incl. scripts, references)
Skills in repo
8
Repo updated
First seen
Licence
Apache-2.0

At a glance

OpenLark 项目 API 接口实现规范(速查)。用于添加/重构飞书开放平台 API:确定落盘路径、实现 Body/Response + Builder(Request)、对齐 endpoints 常量/enum、补齐 mod.rs 导出,并明确"调用服务端 API"的方法签名/RequestOption 传递约定。触发关键词:API 接口、API 文件、飞书 API、添加…

  • Works in 7 steps: 快速工作流(新增一个 API) → Feature Crate ↔ bizTag → Service 链式调用(实现 + 调用约定) → …
  • Tasks that involve Messaging and chat bots
  • SKILL.md covers 🧭 技能路由指南, 🔒 核心契约(所有 crate 必须遵守,不可违反), 0. 快速工作流(新增一个 API) and 1. Feature Crate ↔ bizTag, plus 5 more sections
  • Runs Python scripts from its folder; calls just, python3 and node; reaches open.feishu.cn

What it does

Openlark API is an agent skill from foxzool/openlark. OpenLark 项目 API 接口实现规范(速查)。用于添加/重构飞书开放平台 API:确定落盘路径、实现 Body/Response + Builder(Request)、对齐 endpoints 常量/enum、补齐 mod.rs 导出,并明确"调用服务端 API"的方法签名/RequestOption 传递约定。触发关键词:API 接口、API 文件、飞书 API、添加 API、调用服务端 API

Its SKILL.md is about 3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 7 other files, including scripts and reference files (for example `references/README.md`, `references/csv-mapping.md` and `references/file-layout.md`).

It sits in Productivity & Automation, covering Messaging and chat bots. It works with Feishu (Lark). The repository describes itself as: 飞书开放平台的非官方 Rust SDK,支持自定义机器人、长连接机器人、云文档、飞书卡片、消息、群组等 API 调用。 The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve Messaging and chat bots

Example prompts

  • “调用服务端 API”
  • “/openlark-api”

Requirements

  • Python 3
  • Pre-approved tools (allowed-tools): Bash, Read, Grep, Glob, Edit

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. 快速工作流(新增一个 API)
  2. Feature Crate ↔ bizTag
  3. Service 链式调用(实现 + 调用约定)
  4. API 模板(以仓库现有风格为准)
  5. 提交前检查清单
  6. 官方文档读取(唯一入口)
  7. References

What it can do on your machine

Read from SKILL.md and the folder at commit 6128d6d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Bash
    • Read
    • Grep
    • Glob
    • Edit

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Python), which the agent can run.

    Shell commands in SKILL.md call:

    • just
    • python3
    • node

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • open.feishu.cn

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Openlark API loads about 3k tokens when it runs, and up to ~5.8k if it reads all its reference files. Until then it costs about 54 tokens; SKILL.md has 611 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~54
When it runs · the whole SKILL.md, loaded when a task matches
~3k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~5.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Bash, Read, Grep, Glob, Edit

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from foxzool/openlark at commit 6128d6d, republished under its Apache-2.0 licence (© foxzool). 611 words, ~3,047 tokens.

Download SKILL.mdSave it as .claude/skills/openlark-api/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
openlark-api
description
OpenLark 项目 API 接口实现规范(速查)。用于添加/重构飞书开放平台 API:确定落盘路径、实现 Body/Response + Builder(Request)、对齐 endpoints 常量/enum、补齐 mod.rs 导出,并明确"调用服务端 API"的方法签名/RequestOption 传递约定。触发关键词:API 接口、API 文件、飞书 API、添加 API、调用服务端 API
allowed-tools
Bash, Read, Grep, Glob, Edit
argument-hint
[api-id|path|bizTag]

OpenLark API 接口实现规范(速查)

🧭 技能路由指南

本技能适用场景:

  • 添加/重构单个飞书开放平台 API
  • 需要确定 API 落盘路径(bizTag → crate → 文件路径)
  • 需要参考代码模板(Body/Response + Builder)
  • 需要了解端点规范、RequestOption 约定、Service 链式调用

其他技能:

  • 字段核对 / 抓飞书文档(playwright)→ Skill(openlark-api-field-verify)(读文档唯一入口)
  • 项目级规范体检(架构/API/导出/校验一体)→ Skill(openlark-code-standards)
  • 审查整体设计规范 → Skill(openlark-design-review)
  • 统一 validate() 写法 → Skill(openlark-validation-style)
  • 覆盖率(文件在不在)→ Skill(openlark-api-validation)
关键词触发映射
  • 新增 API、重构 API、Builder、Request/Response、mod.rs 导出、RequestOption → openlark-api
  • 字段核对、文档抓取、playwright、飞书文档字段 → openlark-api-field-verify
  • 代码规范、规范检查、风格一致性、体检 → openlark-code-standards
  • 架构设计、public API、收敛方案、feature gating、兼容策略 → openlark-design-review
  • validate、必填校验、validate_required、空白字符串、校验聚合 → openlark-validation-style
  • 覆盖率、缺失 API、实现数量、CSV 对比、验证脚本 → openlark-api-validation
双向跳转规则
  • 读文档 / 字段核对:一律转 openlark-api-field-verify(勿用本技能下的 fetch_docpath.py 在线抓取)。
  • 实现完成后必须跑字段核对门禁(见 §0 步骤 8 / §4);差异修正仍在本技能落地。
  • 若实现问题本质是架构范式冲突(Request/Service 边界),转 openlark-design-review。
  • 若实现前需要先做全仓规范体检,先跑 openlark-code-standards。
  • 若实现完成后要核验覆盖率与缺失清单,转 openlark-api-validation。

本文件只保留"可执行的最小流程"。标准示例见 references/;官方文档抓取见 Skill(openlark-api-field-verify)。

🔒 核心契约(所有 crate 必须遵守,不可违反)

这些是仓库唯一规范,违反任何一条都会导致接口不统一/调用失败。完整正确模板见 references/standard-example.md。

  1. 新代码默认 config: Config(owned);现有 Arc<Config> 的 Service/Client 保持现状,勿为统一所有权单独重构。openlark_core::Config 内部已 Arc<ConfigInner>,clone 廉价。新 Request/Service 默认用 config: Config,构造用 Config::build()(直接返回 Config,不要 .unwrap())。但仓库现有 573+ 文件仍用 Arc<Config>(如 openlark-docs 的 DocsClient/BaseClient/CcmClient,见 crates/openlark-docs/src/common/chain.rs:611-629)——这些保持现状,不为统一所有权单独重构。两种形态都不持 HTTP client,"走 Transport"是硬约束。

  2. R(ApiRequest<R> 泛型)是响应 data 字段的内容类型,不是包装层。Transport::request 返回 ApiResponse<R> = {code,msg,data: R,...},resp.data: Option<R>。

    • 无 schema/透传:R = serde_json::Value,execute 返回 SDKResult<serde_json::Value>。
    • 有 schema:R 就是 data 内容的 typed struct,并 impl ApiResponseTrait { fn data_format() -> ResponseFormat::Data }。
    • ❌ 禁止写成 XxxResponse { data: Option<T> } 外面再包一层——core 已自动把 R 当作 data 内容解析,再包会双重嵌套(运行时才暴露,极难发现)。
  3. 禁止绕过 Transport:业务 crate(除 openlark-core)不得 reqwest::Client::new() 或自建 HTTP client、不得手工塞 Authorization 头、不得手工取 token。全部走 openlark_core::http::Transport::request。Service/Request 只持 Config,不持任何 HTTP client 字段。

  4. Token 类型按接口文档「请求头 → Authorization」逐接口选择:ApiRequest 默认 supported_access_token_types = [User, Tenant](覆盖飞书大多数接口)。仅当接口文档 Authorization 标注的凭证类型不在默认集内时,才用 .with_supported_access_token_types(...) 显式声明。判断方法:以每个接口官方文档「请求头 → Authorization」标注为准——要求 tenant_access_token → AccessTokenType::Tenant;要求 user_access_token → User;要求 app_access_token → App。不存在「应用级接口 → App」的通则(App = app_access_token,与 tenant_access_token 是不同凭证;把要求 tenant_access_token 的接口设成 App 会被飞书鉴权拒绝,证据见 #511)。

  5. 端点路径用常量/enum(禁止手写 "/open-apis/..." 字符串字面量散落),必填校验统一用 validate_required!/validate_required_list!,每个 Request 必须提供 execute_with_options(..., RequestOption) 并把 option 透传到 Transport::request(..., Some(option))。

0. 快速工作流(新增一个 API)

  1. 定位 API:在 ./api_list_export.csv 拿到 id、bizTag、meta.*、fullPath
    • URL 权威源是 fullPath(拼 https://open.feishu.cn + fullPath)。不要用手拼路径,也不要默认用 docPath(常与 fullPath 不一致)。
  2. 读文档(门禁):用 playwright 抓取(见 §5)。产出文件 <500 字符 = 失败,禁止继续实现或推断字段。
  3. 选 crate:根据 bizTag 选择 feature crate(见 §1)
  4. 定路径:crates/{crate}/src/{bizTag}/{project}/{version}/{resource...}/{name}.rs
  5. 写代码:按抓取到的真实字段写 Body/Response + Builder(execute/send)+ 端点常量/enum
    • 必须支持 RequestOption:用于 user_access_token / tenant_key / 自定义 header
  6. 补导出:在 mod.rs 中 pub mod ... / pub use ...
  7. 补链路:在约定入口补齐链式调用(默认 service.rs,但 openlark-docs 例外,见 §2)
  8. 验证(含字段核对门禁):
    • 新增 API 所属 crate feature 已在 Cargo.toml [features] 声明;
    • 涉及该 feature 的测试用 #[cfg(test)] 模块内 #![cfg(feature = "...")](或模块级 #[cfg(feature)])门控;
    • 若新增 examples/ 示例,须在 Cargo.toml [[example]] 声明 required-features;
    • 跑 just fmt && just lint && just test,其中 just lint 须含 --all-targets(覆盖 examples + tests);
    • 字段核对(必做):python3 tools/verify_api_fields.py --api-id <CSV的id> --fetch-docs;进程须以 0 退出(抓取失败 / error / warning 均非 0)。详细流程见 Skill(openlark-api-field-verify)。门禁通过不覆盖嵌套结构与响应体完整性,见 field-verify 技能「工具核对边界」。

1. Feature Crate ↔ bizTag

仓库以 tools/api_coverage.toml 作为 crate→bizTag 的唯一来源。

bash
# 查看所有映射
python3 tools/validate_apis.py --list-crates

# 验证特定 crate 的覆盖率
python3 tools/validate_apis.py --crate openlark-docs

反查技巧:落盘路径以"目标 crate 现有结构"为准,参考 references/file-layout.md

2. Service 链式调用(实现 + 调用约定)

本节提供"如何实现"的技术规范。若需要审查"是否应该统一范式"(Request 自持 Config vs Builder → Service),见 Skill(openlark-design-review) §1。

2.1 实现侧:service.rs

event/webhook 类 P2 模块不进统一 service.rs 链路:这类模块(如长连接回调、事件订阅)的入口形态与普通 CRUD API 不同,放在各自独立入口,不强行塞进 client.<biz>.service()... 链。

目标:让 openlark-client 能走 client.<biz>.service().<project>().<version>()...<api>()

  • 若 crate 已有 src/service.rs:在顶层 service 新增 pub fn {bizTag}(&self) -> ...
  • 若没有:创建 src/service.rs 并在 lib.rs 中 pub mod service;
  • openlark-docs 特例:为避免 strict API 校验脚本把"链式入口"计为 API 实现文件,链式入口放在 crates/openlark-docs/src/common/chain.rs,只做模块级入口与 Config 透传,不为 200+ API 手写方法。
Show full SKILL.md (224 more words)Show less
⚠️ Service 层标准模式

注:这是 openlark-docs crate 的真实写法(用 Arc<Config>,见 crates/openlark-docs/src/common/chain.rs:611-629 的 DocsClient)。 核心契约 1 已放宽:新代码默认 owned(config: Config),现有 Arc<Config> 的 Service/Client 保持现状、勿为统一所有权单独重构。两种形态都不持 HTTP client,这点是硬约束。

正确示例(参考 openlark-docs/src/common/chain.rs):

rust
use std::sync::Arc;
use openlark_core::config::Config;

/// DocClient 只持有 Arc<Config>
#[derive(Debug, Clone)]
pub struct DocClient {
    config: Arc<Config>,
}

impl DocClient {
    pub fn new(config: Config) -> Self {
        Self { config: Arc::new(config) }
    }

    /// 子 Service 只透传 Arc<Config>
    pub fn drive(&self) -> DriveService {
        DriveService::new(self.config.clone())
    }
}

/// Service 层只持有 Arc<Config>,不持有独立 HTTP client
#[derive(Debug, Clone)]
pub struct DriveService {
    config: Arc<Config>,
}

impl DriveService {
    pub fn new(config: Arc<Config>) -> Self {
        Self { config }
    }

    pub fn v1(&self) -> DriveV1 {
        DriveV1::new(self.config.clone())
    }
}

❌ 禁止模式:

  • ❌ reqwest::Client::new() 或任何自建 HTTP client(业务 crate 除 core 外全部禁止,见核心契约 3)
  • ❌ 手工塞 Authorization 头 / 手工取 token(由 Transport 自动注入)
  • ❌ Service/Request 持有独立的 HTTP client 字段(只持 Config)
  • ❌ 使用 LarkClient 作为具体类型(它是 trait)
  • ❌ 在测试中使用 .unwrap() 调用 Config::build()(build() 直接返回 Config)

✅ 正确模式:

  • ✅ Service 只持有 Arc<Config>
  • ✅ Config::build() 直接返回 Config,不需要 .unwrap()
  • ✅ HTTP 传输由 openlark_core::Transport 处理
2.2 调用侧:RequestOption 约定

必须提供 execute_with_options(..., RequestOption) 或等价签名,并将 option 透传到 Transport::request(..., Some(option))

使用场景:

  • 用户态 API → user_access_token
  • 商店应用 → tenant_key / app_ticket
  • 链路追踪 → request_id / 自定义 header

⚠️ 不要只调用 ApiRequest::request_option(...),它仅合并 header,token 推断需要走 Transport

详细示例见 references/standard-example.md

3. API 模板(以仓库现有风格为准)

以下提供两种仓库中真实存在的风格。实现时优先模仿目标 crate 的现有文件风格,避免在同一 project/version 内混用多种范式。

范式一致性审查见 Skill(openlark-design-review) §1。

3.1 Request / Response
rust
use openlark_core::{api::ApiRequest, config::Config, http::Transport, SDKResult};
use openlark_core::req_option::RequestOption;
use serde::{Deserialize, Serialize};

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct {Name}Body {
    // 字段按官方文档,用 serde rename 对齐
    // 可选:Option<T> + #[serde(skip_serializing_if = "Option::is_none")]
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct {Name}Response {
    // 字段按官方文档
}
3.2 Builder + execute/send

⚠️ 下面的模板是骨架,必须配合 §"🔒 核心契约" 理解。完整正确示例见 references/standard-example.md(以仓库现有风格为准)。

rust
use openlark_core::{
    api::ApiRequest, config::Config, http::Transport, validate_required, SDKResult,
};
use openlark_core::req_option::RequestOption;
use serde::{Deserialize, Serialize};

// R(ApiRequest<R> 泛型):无 schema 用 serde_json::Value;有 schema 用 typed struct
// (见 references/standard-example.md 的 B 范式 + impl ApiResponseTrait)。
// ❌ 不要在外面再包一层 XxxResponse { data: Option<...> }——会双重嵌套。

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct {Name}Body {
    // 字段按官方文档,用 serde rename 对齐
    // 可选:Option<T> + #[serde(skip_serializing_if = "Option::is_none")]
}

pub struct {Name}Request {
    config: Config,            // owned(见核心契约 1)
    // 路径/查询参数(按需)
}

impl {Name}Request {
    pub fn new(config: Config) -> Self { /* ... */ }

    pub async fn execute(self, body: {Name}Body) -> SDKResult<serde_json::Value> {
        self.execute_with_options(body, RequestOption::default()).await
    }

    pub async fn execute_with_options(
        self,
        body: {Name}Body,
        option: RequestOption,
    ) -> SDKResult<serde_json::Value> {
        validate_required!(body.<必填字段>, "<字段> 不能为空"); // 见核心契约 5
        // 端点必须复用 crate 的 endpoints 常量或 enum(禁止手写 "/open-apis/...")
        // 默认 [User, Tenant] 已覆盖大多数接口;仅当接口文档 Authorization 要求 app_access_token
        // 等非默认凭证时,才 .with_supported_access_token_types(vec![...]) 显式声明(见核心契约 4)。
        let req: ApiRequest<serde_json::Value> = ApiRequest::post({ENDPOINT_CONST_OR_ENUM});
        let resp = Transport::request(req, &self.config, Some(option)).await?; // 见核心契约 3
        // resp.data: Option<serde_json::Value>,R 是 data 内容(见核心契约 2)
        resp.data.ok_or_else(|| openlark_core::error::validation_error("响应数据为空", "服务器没有返回有效的数据"))
    }
}

4. 提交前检查清单

  • 落盘路径正确(与同模块现有结构一致)
  • 已用 playwright 按 fullPath 抓取文档(产出 ≥500 字符);字段来自真实文档,非同族推断
  • Request/Response 字段对齐官方文档(含 serde(rename))
  • 核心契约 1:config: Config(owned),未用 Arc<Config>
  • 核心契约 2:R 是响应 data 内容类型,未在外面再包 XxxResponse{data}
  • 核心契约 3:无 reqwest::Client::new() / 手工 token,全走 Transport::request
  • 核心契约 4:token 类型与接口文档「请求头 → Authorization」标注一致(默认 [User, Tenant];仅当文档要求 app_access_token 等非默认凭证时才 .with_supported_access_token_types([...]))
  • 核心契约 5:端点用常量/enum(禁手写 URL);必填字段用 validate_required!
  • execute_with_options(..., RequestOption) 已提供并透传到 Transport
  • mod.rs 已导出;service.rs/链式入口已补
  • 新增 feature 已在 Cargo.toml [features] 声明;测试/示例的 #[cfg(feature)] 与 [[example]] required-features 已补
  • just fmt && just lint --all-targets && just test 通过
  • 字段核对门禁:python3 tools/verify_api_fields.py --api-id <id> --fetch-docs 无未处理的 error/warning(门禁通过不覆盖嵌套结构与响应体完整性,见 field-verify 技能「工具核对边界」)

5. 官方文档读取(唯一入口)

飞书文档是 SPA,禁止用本目录 scripts/fetch_docpath.py 做在线抓取(常返回空壳)。统一走 field-verify 的 playwright 脚本,URL 只用 CSV fullPath:

bash
# 从 CSV 取 fullPath / id 后:
FULL_PATH="$(python3 -c "
import csv
with open('api_list_export.csv', encoding='utf-8-sig') as f:
    for row in csv.DictReader(f):
        if row['id'] == '<API_ID>':
            print(row['fullPath']); break
")"

node .agents/skills/openlark-api-field-verify/scripts/fetch_doc.js \
  "https://open.feishu.cn${FULL_PATH}" \
  "/tmp/doc_<API_ID>.txt"

# 或按 api-id 直接抓(脚本内读 CSV):
node .agents/skills/openlark-api-field-verify/scripts/fetch_doc.js \
  --from-csv <API_ID> --out /tmp/doc_<API_ID>.txt

抓取后按 Skill(openlark-api-field-verify) 解析 Request/Response 字段再写代码。离线已有 HTML 时,才可用 fetch_docpath.py --html-file 作解析兜底。

6. References

  • 目录规范与反查:references/file-layout.md
  • CSV 映射规则:references/csv-mapping.md
  • 标准示例(照抄结构):references/standard-example.md
  • 字段核对与文档抓取:Skill(openlark-api-field-verify)

© foxzool, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files (scripts, references) in .agents/skills/openlark-api of foxzool/openlark.

  • SKILL.md
  • references/README.md
  • references/csv-mapping.md
  • references/file-layout.md
  • references/standard-example.md
  • scripts/fetch_docpath.py

Open the folder on GitHubat commit 6128d6d

Compare with similar skills

Openlark API next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Openlark API compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Openlark API this skillfoxzool/openlark106—~3kAutomated safety check: NotesApache-2.0
Feishu Docraucvr/Group-Goki1123 repos~592Automated safety check: PassMIT
Feishu Driveraucvr/Group-Goki1123 repos~587Automated safety check: PassMIT
Feishu Permraucvr/Group-Goki1123 repos~630Automated safety check: PassMIT
Feishu Safety GuideSafeAI-Lab-X/ClawKeeper1k—~3.6kAutomated safety check: PassNone
Tlivey49/tlive214—~1.7kAutomated safety check: NotesMIT

Similar skills

  • Feishu Doc

    raucvr/Group-Goki

    Feishu document read/write operations. An agent skill from raucvr/Group-Goki.

    112 GitHub starsUsed in 3 repos~592 tokens
    Productivity & AutomationAuto-check passed
  • Feishu Drive

    raucvr/Group-Goki

    Feishu cloud storage file management. An agent skill from raucvr/Group-Goki.

    112 GitHub starsUsed in 3 repos~587 tokens
    Productivity & AutomationAuto-check passed
  • Feishu Perm

    raucvr/Group-Goki

    Feishu permission management for documents and files. An agent skill from raucvr/Group-Goki.

    112 GitHub starsUsed in 3 repos~630 tokens
    Productivity & AutomationAuto-check passed
  • Feishu Safety Guide

    SafeAI-Lab-X/ClawKeeper

    One-click deployment Skill for Feishu security governance and message anti-data-leakage guide, responsible for Feishu message security, credential protection, permission auditing, interaction…

    1k GitHub stars~3.6k tokensUpdated 1 mo ago
    Productivity & AutomationAuto-check passed
  • Tlive

    y49/tlive

    tlive — remote approvals (Telegram/Feishu/web), live web terminal, and session monitoring for Claude Code / Codex.

    214 GitHub stars~1.7k tokensUpdated 28 days ago
    Productivity & AutomationAuto-check: notes
  • Easy Openclaw

    daheiai/easy-openclaw

    OpenClaw 配置优化向导。采用“第 0 层测试观测(可选)+ 前 3 轮优化 + 第 4 轮接入扩展”流程:基础推荐层(含联网搜索与权限模式)、渠道增强层(Discord/Feishu/Telegram 分支优化)、Skills 推荐层(可执行可跳过)、新增渠道接入引导(可跳过)。用于帮助用户快速完成 OpenClaw 初始化或优化配置。用户说到“优化…

    112 GitHub stars~1.7k tokensUpdated 6 mo ago
    Productivity & AutomationAuto-check: notes

More from foxzool/openlark

All 8 skills in this repo
  • Verify Openlark

    foxzool/openlark

    Prove OpenLark (Feishu/Lark Rust SDK) changes the way a maintainer does — cargo build/test, public examples, API coverage and field-verify harnesses.

    106 GitHub stars~1.8k tokensUpdated 4 days ago
    Auto-check passed
  • OpenLark API 字段核对技能。用于新增/重构飞书 API 后,核对 Rust 实现的请求体/响应体字段是否与飞书官方文档一致。通过 playwright 渲染飞书 SPA 文档页面,提取真实的请求/响应字段定义,对比代码实现找出不符项。触发关键词:字段核对、字段验证、字段不符、文档核对、核对请求字段、核对响应字段、飞书文档字段、推断字段、user 级接口、用户级接口字段

    106 GitHub stars~2.3k tokensUpdated 4 days ago
    Auto-check: notes
  • Openlark Code Standards

    foxzool/openlark

    OpenLark 项目代码规范检查技能。用于快速审查仓库内的架构一致性、API 实现套路、参数校验、命名与导出规范,并输出可执行检查清单与证据路径。Triggers: code review / consistency check / architecture audit / 规范检查 / 风格一致性 / 体检 / 对齐约定。项目锚点见 AGENTS.mdCONVENTIONS 与…

    106 GitHub stars~1.8k tokensUpdated 4 days ago
    Auto-check: notes
  • Openlark Design Review

    foxzool/openlark

    OpenLark Rust SDK 的代码设计/公共 API 规范审查技能(面向 crate/模块)。用于系统化检查入口设计、feature gating、Request/Service/Builder 一致性、端点体系、Config/错误处理、导出与文档同步、测试与告警控制,并输出按优先级排序的整改清单与可落地改造方案。触发关键词:设计审查、crate 设计、API 设计、public…

    106 GitHub stars~2.1k tokensUpdated 4 days ago
    Auto-check: notes
  • Openlark API Validation

    foxzool/openlark

    OpenLark API 覆盖率验证技能。用于验证各 crate 的 API 实现数量与覆盖率,基于 tools/validateapis.py 脚本和 apilistexport.csv 对比实际代码实现。触发关键词:API 验证、API 覆盖率、验证 API 数量、检查 API 实现、API 统计

    106 GitHub stars~2k tokensUpdated 4 days ago
    Auto-check: notes
  • Openlark Naming

    foxzool/openlark

    OpenLark Rust SDK 命名与对外 API 表达规范(Client/Service/Resource/Request/Builder)。用于新增/重构公开类型、设计 meta 调用链、调整模块导出与 prelude、或排查 Service 同名/语义错配/V{N}Service 版本层错位、Resource 与 Service 同类型两名、以及…

    106 GitHub stars~2.1k tokensUpdated 4 days ago
    Auto-check: notes

Works with

Questions about Openlark API

What does Openlark API do?

OpenLark 项目 API 接口实现规范(速查)。用于添加/重构飞书开放平台 API:确定落盘路径、实现 Body/Response + Builder(Request)、对齐 endpoints 常量/enum、补齐 mod.rs 导出,并明确"调用服务端 API"的方法签名/RequestOption 传递约定。触发关键词:API 接口、API 文件、飞书 API、添加…. Openlark API is an agent skill from foxzool/openlark.

When should I use Openlark API?

Openlark API fits situations like: tasks that involve Messaging and chat bots.

How do I install Openlark API in Claude Code?

Run `npx skills add foxzool/openlark --skill openlark-api -a claude-code`. Or copy the skill folder (.agents/skills/openlark-api in foxzool/openlark) into .claude/skills/openlark-api in your project. Claude Code loads it when a task matches its description.

How do I install Openlark API in Codex?

Run `npx skills add foxzool/openlark --skill openlark-api -a codex`. Or copy the skill folder (.agents/skills/openlark-api in foxzool/openlark) into .agents/skills/openlark-api in your project. Codex loads it when a task matches its description.

Can I use Openlark API in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add foxzool/openlark --skill openlark-api -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/openlark-api, .gemini/skills/openlark-api, .github/skills/openlark-api and .opencode/skills/openlark-api in your project.

What does Openlark API need to run?

Going by SKILL.md and its folder, Openlark API needs Python for the scripts in its folder and the command-line tools its instructions call (just, python3 and node). Our summary lists: Python 3. Its frontmatter pre-approves these tools: Bash, Read, Grep, Glob, Edit.

Does Openlark API access the network?

SKILL.md names 1 domain. In commands or code: open.feishu.cn; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Openlark API safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Openlark API use?

Openlark API is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Openlark API use?

About 3k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.8k tokens, read only when the agent opens those files.

What are the alternatives to Openlark API?

Skills that share tags, products or a category with Openlark API: Feishu Doc (raucvr/Group-Goki, 112 stars), Feishu Drive (raucvr/Group-Goki, 112 stars), Feishu Perm (raucvr/Group-Goki, 112 stars) and Feishu Safety Guide (SafeAI-Lab-X/ClawKeeper, 1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Openlark API?

foxzool (a GitHub user) maintains it in foxzool/openlark, which has 106 GitHub stars. The repository holds 8 skills in this directory. The repository was last updated on October 3, 2026.

Source: foxzool/openlark on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.