CtrlK
BlogDocsLog inGet started
Tessl Logo

crate-structure

The Xberg workspace layout — the version source of truth (root Cargo.toml [workspace.package] version), the crates/ workspace members (core lib, CLI, FFI, per-language binding crates, OCR crates), the out-of-workspace binding packages under packages/ (PyPI, RubyGems, Composer, Go, Maven, NuGet, Hex), and the tools/ directory. Load when navigating the repo, deciding where code belongs, or wiring a new crate or binding package.

75

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

85%

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

An exceptionally lean, well-organized structural map that assumes Claude's competence and wastes no tokens. Its one gap is actionability: the description promises guidance for wiring new crates/bindings, but the body only inventories existing ones without explicit steps or executable examples.

Suggestions

Add a short 'Wiring a new binding' subsection with concrete steps (e.g., add a workspace crate, expose symbols via xberg-ffi, choose the language binding mechanism) — the description promises this but the body only catalogs existing crates.

Include one copy-paste example such as a canonical Cargo.toml workspace-member entry or a cbindgen invocation to make the reference directly executable.

Note the convention for where a new out-of-workspace package should live (packages/<lang>/) and which existing package is the closest template to copy.

DimensionReasoningScore

Conciseness

Terse one-line entries with concrete specifics and no padding; it assumes Claude knows the Rust ecosystem terms (PyO3, NAPI-RS, Magnus, Rustler, cbindgen) and every token earns its place.

3 / 3

Actionability

Concrete, specific descriptions of each crate and binding mechanism are present, but the body catalogs existing structure rather than providing executable commands or explicit steps for the description's 'wiring a new crate or binding package' trigger — a key detail for that use case is only implied by example.

2 / 3

Workflow Clarity

This is a simple single-purpose reference (under 50 lines, no multi-step process), and the content is clear and well-organized, so workflow clarity scores 3 per the simple-skills note; no risky/destructive operations require validation checkpoints.

3 / 3

Progressive Disclosure

Under 50 lines with no need for external references, organized into clear sections (Workspace crates, Out-of-workspace bindings, Tools) — meeting the simple-skills criterion for a top progressive-disclosure score with well-organized sections.

3 / 3

Total

11

/

12

Passed

Description

100%

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

A precise, well-triggered description that clearly states both the workspace layout it documents and the navigation/wiring situations that should load it. It is concrete and niche-specific with no vague fluff.

DimensionReasoningScore

Specificity

Names many concrete entities (core lib, CLI, FFI, per-language binding crates, OCR crates, PyPI, RubyGems, Composer, Go, Maven, NuGet, Hex, tools/) rather than vague abstractions — closest to the 'lists multiple specific concrete items' anchor.

3 / 3

Completeness

Explicitly states both what (the workspace layout, version source of truth, crates/, packages/, tools/) and when ('Load when navigating the repo, deciding where code belongs, or wiring a new crate or binding package').

3 / 3

Trigger Term Quality

The 'Load when navigating the repo, deciding where code belongs, or wiring a new crate or binding package' clause uses natural developer phrasing a user would actually say, with good coverage of trigger variations.

3 / 3

Distinctiveness Conflict Risk

Scoped to the specific Xberg repo structure with distinct triggers, making it unlikely to fire for unrelated skills.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
xberg-io/xberg
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.