CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

plant-store-api-custom-commands

How to author custom commands for the plant-store-api CLI using the co-generated SDK.

Quality

73%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

—

The risk profile of this skill

Fix and improve this skill with Tessl

tessl review fix ./seed/cli/openapi-subtitle/.agents/skills/custom-commands/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

75%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 well-structured, actionable skill body: complete executable Rust examples, an accurate regeneration-safety table, and concrete build/run commands. Its main weaknesses are a contentless 'Available SDK Clients' section and repetition of the .fernignore protection three times.

Suggestions

Fill or remove the empty '### 2. Available SDK Clients' section — either list a few example sub-clients or point readers to the generated plant-store-api-sdk crate to inspect them.

State the .fernignore protection once (e.g., in the Regeneration Safety table) and drop the repeated mentions in section 1 and the follow-up paragraph.

Add a quick verification step after building, such as checking the command appears in plant-store-api --help.

DimensionReasoningScore

Conciseness

The body is lean — compact architecture diagram, a table for regeneration safety, and a single complete code example — but the '.fernignore' protection is stated three times ("This file is protected by .fernignore — fern generate will never overwrite it", "Protected by .fernignore", "your custom.rs is preserved"), which is redundant padding.

4 / 5

Actionability

Concrete, executable Rust code covers registration ("app.command(clap::Command::new(\"my-command\")...)"), client access ("super::sdk::client(ctx)"), and async bridging ("super::sdk::block_on(...)") plus build/run commands. Minor gap: the "Available SDK Clients" section is an empty placeholder stating only "(Sub-clients are derived from the API spec at generation time.)" with no actual listing or pointer.

4 / 5

Workflow Clarity

The edit → build → run sequence is clear with commands ("cargo build", "plant-store-api <your-command> [args]") and a debug checkpoint ("RUST_LOG=debug"). Minor validation gap: no step to verify the command registered (e.g., checking --help), and recovery guidance after regeneration is advisory rather than a checkpoint.

4 / 5

Progressive Disclosure

No bundle files exist and the ~100-line single file with well-labeled sections (Architecture, Adding a Custom Command, Regeneration Safety, Build & Test) is an appropriate structure at this size. The empty "### 2. Available SDK Clients" section is a minor organization gap that should either list examples or point to the generated SDK crate.

4 / 5

Total

16

/

20

Passed

Description

57%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.

The description is specific and highly distinctive thanks to naming the exact project, and it clearly states what the skill does. Its main weakness is the complete absence of 'when to use' trigger guidance, and its keyword coverage is narrow beyond the project name.

Suggestions

Add an explicit trigger clause, e.g., 'Use when adding or modifying commands in the plant-store-api CLI, or when editing cli/plant-store-api/custom.rs.'

Broaden natural trigger terms with variations users would actually say, such as 'extend the CLI', 'add a command', or 'custom.rs'.

Mention 1-2 more concrete capabilities (e.g., calling the typed SDK with shared auth/retries) to lift specificity beyond a single action.

DimensionReasoningScore

Specificity

It names a concrete domain ("plant-store-api CLI") and one concrete action ("author custom commands") with a specific mechanism ("co-generated SDK"), matching the anchor for 1-2 concrete actions without comprehensive coverage. It is well above generic ('Names the domain but actions are minimal') but does not list several specific actions.

3 / 5

Completeness

The 'what' is clear ("author custom commands for the plant-store-api CLI using the co-generated SDK"), but there is no 'Use when...' clause or equivalent trigger guidance — 'when' is entirely missing, which per the judging guidelines caps completeness at 3.

3 / 5

Trigger Term Quality

Relevant keywords like "custom commands", "CLI", and "plant-store-api" are natural phrases a project user would say, but coverage stops there — no variations or synonyms (e.g., 'add a command', 'extend the CLI'), and "co-generated SDK" is technical jargon rather than a user-said term.

3 / 5

Distinctiveness Conflict Risk

Naming a specific project CLI ("plant-store-api") gives this skill a clear niche with minimal conflict risk — it is essentially impossible to confuse with generic CLI or SDK skills, matching the 'clear niche with distinct triggers' anchor.

5 / 5

Total

14

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

fern-api/fern

Path

seed/cli/openapi-subtitle/.agents/skills/custom-commands/SKILL.md

Revision

014b566

Reviewed

Table of Contents

DiscoveryImplementationValidation

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.

Claim skill