CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

lark-event

Lark/Feishu real-time event listening / subscribing / consuming: stream events as NDJSON via `lark-cli event consume <EventKey>` (covers IM messages/reactions/chat changes, Approval status changes, Task updates, VC meeting started/joined/ended, Minutes generated, Whiteboard updated, etc.). Use for Lark bots, real-time message processing, long-running subscribers, streaming webhook/push handlers. Supports `--max-events` / `--timeout` bounded runs and a stderr ready-marker contract — designed for AI agents running as subprocesses.

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

High

Do not use without reviewing

SKILL.md
Quality
Evals
Security

Quality

Content

92%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A strong operational skill body: every command is executable, the workflow has explicit checkpoints and error-recovery guidance, and bundle structure is exemplary with a topic-indexed, one-level-deep reference set. The only weakness is minor — a few justification passages and a schema snippet that could be tightened for token efficiency.

Suggestions

Trim the rationale bullets under 'One consume, one EventKey' (fault isolation, per-key flags) to one line each — the design rule plus the bus-daemon note conveys the same information.

The schema 'Snippet' JSON block could be reduced to one representative field, since the reading instructions in (1)-(4) already tell the agent how to fetch the full property objects.

The 'authoritative, always-current catalog' note about `event list` appears in both the Examples section and the VC topic-index row — state it once.

DimensionReasoningScore

Conciseness

The body is dense and assumes Claude's competence — no space is spent explaining what events or NDJSON are, and nearly every line carries non-obvious operational detail (stdin EOF semantics, kill -9 subscription leaks, decoded-vs-raw field pitfalls). Minor trimming is possible: the schema snippet JSON block, the "this is intentional" rationale bullets in the multi-key section, and repeated statements that `event list` is the always-current catalog (it appears in both Examples and the VC topic-index row). This sits between the 4 anchor ('efficient; minor instances of over-explanation') and the 5 anchor — closer inspection keeps it at 4 because a few justification passages could be cut without losing information.

4 / 5

Actionability

Guidance is fully executable and copy-paste ready: a command table with exact flags, worked bash examples including a multi-key concurrent-consume pattern, an exit-code/reason table, and the structured error envelope with explicit parse instructions ('Parse `error.type` / `error.subtype` to branch'). Concrete examples cover the common cases (sample grab, bounded run, background consumers).

5 / 5

Workflow Clarity

The 'Call flow' section gives a clear 3-step sequence (list → schema → consume) with exact commands, and the subprocess contract supplies explicit validation checkpoints and feedback loops: block on the stderr ready marker ('Do not fall back to `sleep`'), treat exit-0 reasons as business completion, and branch on the JSON error envelope's type/subtype/hint for recovery. Not a 4 because checkpoints are explicit and error-recovery paths are enumerated, not implicit.

5 / 5

Progressive Disclosure

The 'Topic index' table cleanly splits catalogs per domain into one-level-deep references (all 7 listed files exist in references/ and each is topically scoped), each entry summarizing its coverage so the reader knows where to go. The body keeps only essentials (commands, flags, contract, jq method) inline and defers per-EventKey catalogs and recipes to the bundle, with cross-skill links clearly signaled as prerequisites.

5 / 5

Total

19

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An excellent description: concrete and executable in its 'what', explicit and natural in its 'when', scoped to a clear niche with dual platform naming, and written in third person with no fluff. Both what and when clauses are present with concrete trigger phrases.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — "stream events as NDJSON via `lark-cli event consume <EventKey>`" with enumerated domain coverage (IM messages/reactions/chat changes, Approval status changes, Task updates, VC meeting lifecycle, Minutes generated, Whiteboard updated) plus bounded-run flags and the stderr ready-marker contract. Coverage of what the command does is comprehensive and concrete, matching the anchor's 'lists multiple specific concrete actions'.

5 / 5

Completeness

Both 'what' (streams events as NDJSON via a named command, covering listed domains, with bounded-run support) and 'when' ("Use for Lark bots, real-time message processing, long-running subscribers, streaming webhook/push handlers") are explicitly stated with concrete trigger phrases, matching the top anchor exactly. Not a 4 because the 'when' clause is explicit and enumerates use cases rather than being generic.

5 / 5

Trigger Term Quality

It includes natural terms and their synonyms users would actually say: "Lark/Feishu", "real-time event listening / subscribing / consuming", "Lark bots", "real-time message processing", "long-running subscribers", "streaming webhook/push handlers". This mirrors the anchor's comprehensive synonym coverage (e.g. 'PDF files, PDFs, forms').

5 / 5

Distinctiveness Conflict Risk

It is tightly scoped to Lark/Feishu real-time event consumption, naming both platform synonyms and the specific CLI command, which sibling Lark skills (auth, messaging, docs) would not claim. Distinct triggers minimize overlap risk.

5 / 5

Total

20

/

20

Passed

Validation

75%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 12 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

relative_links

Relative link issues: 2 suspicious

Warning

Total

12

/

16

Passed

Repository

larksuite/cli

Path

skills/lark-event/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.