CtrlK
BlogDocsLog inGet started
Tessl Logo

wasm-constraints

WASM build constraints for the crates/xberg-wasm crate — the wasm-target feature set, no-tokio sync-only internal APIs, the crate-private SyncExtractor trait, the 2 MB HTML size limit, size-optimized build config (opt-level="z"), and the async-wrapper/sync-internal API pattern. Load when building for wasm32, adding or modifying a WASM-compatible extractor, or debugging WASM build/runtime failures.

70

Quality

85%

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

78%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 tight, high-signal constraints skill: every section carries project-specific knowledge Claude could not infer, with concrete code and config. The main improvements are removing the Critical Rules recap duplication, showing the required cfg_attr async_trait form, and adding a quick build/size verification step.

Suggestions

Drop the verbatim restatement of constraints 1–4 in the Critical Rules section (or drop the detailed sections and keep only the checklist) to remove duplicated tokens.

Show the two-arm cfg_attr async_trait pattern in a short code snippet, since rule 5 requires it but never demonstrates it.

Add a one-line verification step (e.g., the wasm-pack/build command and a check that the resulting .wasm stays under the jsDelivr 50 MB cap) so changes can be validated.

DimensionReasoningScore

Conciseness

The body is lean and entirely project-specific (feature-flag sets, jsDelivr 50 MB cap rationale, the Alef-generated warning) with no concepts Claude already knows. It falls short of the top anchor only because rules 1–4 in "Critical Rules" restate constraints 1–4 already detailed above — a small but real token duplication.

4 / 5

Actionability

Concrete throughout: exact TOML feature lists, file paths, the MAX_HTML_SIZE_BYTES constant, profile config, and code snippets for the trait impl and wasm-bindgen surface. Not fully copy-paste ready at the 5 level — the SyncExtractor snippet is a signature skeleton and rule 5's "two-arm cfg_attr async_trait form" is required but never shown.

4 / 5

Workflow Clarity

As a constraint reference rather than a sequential skill, each rule is unambiguous and organized by topic. It sits below 5 because there is no verification guidance (e.g., a build command or .wasm size check to confirm the constraints hold after a change), though nothing is incoherent enough to drop to 3.

4 / 5

Progressive Disclosure

A single lean, well-sectioned file with no bundle files present and no content that warrants externalization — the appropriate structure for this scope, matching the well-organized single-file pattern.

5 / 5

Total

17

/

20

Passed

Description

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

A strong description: concrete, comprehensive, and explicit about both what it covers and when to load it, with a distinct niche. The only weakness is trigger-term coverage that leans technical rather than including natural user variations.

DimensionReasoningScore

Specificity

The description enumerates six concrete, named specifics ("wasm-target feature set", "no-tokio sync-only internal APIs", "crate-private SyncExtractor trait", "2 MB HTML size limit", "opt-level=\"z\"", "async-wrapper/sync-internal API pattern") — comprehensive coverage with no vague padding, matching the top anchor rather than the 'minor gaps' level below.

5 / 5

Completeness

Both halves are explicit: the 'what' is the enumerated constraint set, and the 'when' is a concrete "Load when..." clause with three specific trigger conditions — matching the clear-what-and-when-with-concrete-triggers anchor, above the level where 'when' is merely present but could be more specific.

5 / 5

Trigger Term Quality

The "Load when building for wasm32, adding or modifying a WASM-compatible extractor, or debugging WASM build/runtime failures" clause uses natural phrases users would say, but coverage relies on the crate's technical jargon and misses common variations like "WebAssembly" or tooling names (wasm-pack). Fits the 'good keyword coverage; a few natural terms missing' anchor, not the comprehensive-synonym level.

4 / 5

Distinctiveness Conflict Risk

Scoped entirely to WASM build constraints for one named crate (crates/xberg-wasm), forming a clear niche with triggers (wasm32, WASM extractor work) that no generic skill would claim — minimal conflict risk.

5 / 5

Total

19

/

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