board-spec

Use when a development board, SBC, MCU module, or board-level enclosure constraint must be resolved for hardware or CAD design.

Quality

73%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./reference/replicator-original/ee/board-spec/SKILL.md

Quality

Content

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

The body is an exemplary lean overview: a tight five-step workflow with built-in safety rules (exact-match only, no invented precision), and a single well-signaled one-level-deep reference that actually exists and carries the operational detail. The only gaps are minor: an abstract final step and the no-match failure branch living in the reference rather than the body.

Dimension	Reasoning	Score
Conciseness	The ~20-line body is lean with no padding or explanations of concepts Claude already knows. Every line is either workflow, a safety rule, or navigation; the only repetition (don't-infer rule, also in the reference) is a justified safety restatement.	5 / 5
Actionability	Concrete, specific guidance for an instruction-only skill: names the exact tool to query ('cad.board_model'), the exact-match confirmation requirement, the reference file to read, and the catalog-row source. Slightly below fully executable because step 5 ('pass returned mechanical and power constraints downstream') is abstract and call syntax/aliases live only in the reference file.	4 / 5
Workflow Clarity	A clear five-step sequence with real checkpoints: 'install only the confirmed source version' and 'report missing fields as assumptions or uncertainty' handle the no-match/missing-data edge cases. Not 5 because the explicit failure branch (report the model/source version gap, do not substitute variants) appears only in the reference file, not in the body's workflow.	4 / 5
Progressive Disclosure	Verified against the bundle: 'references/board-tool.md' exists, is referenced in workflow step 1, and is clearly signaled in a References section with a one-line content description ('inputs, lookup flow, and pass-through rules'). Exactly one level deep — the reference contains no further reference chains — and the split (overview in SKILL.md, details in the reference) is appropriate.	5 / 5
	Total	18 / 20 Passed

Description

47%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 has good natural trigger terms for a distinctive niche, but it is only a 'when' clause: it never states what the skill does or lists concrete capabilities, leaving a user unsure what invoking it will produce. Adding a 'what' half naming the concrete actions (board dimension lookup, mounting holes, connectors, keepouts, verified STEP models) would move it to the strong examples' level.

Suggestions

Add a 'what' clause with concrete capabilities before the 'Use when' clause, e.g. 'Retrieves board specifications — dimensions, mounting holes, connectors, keepouts, and verified STEP models — for enclosure and CAD work.'

Include natural synonyms and specifics users would say, such as example board names (Raspberry Pi, ESP32, Pico) or the STEP file format, to broaden trigger coverage.

Keep the existing trigger clause but make it parallel to good examples: concrete actions first, then 'Use when the user names a board or when enclosure/CAD work needs board dimensions...'"

Dimension	Reasoning	Score
Specificity	The description names the domain ('development board, SBC, MCU module, or board-level enclosure constraint') but contains no concrete capability actions — 'must be resolved' is passive and generic, with no verbs like retrieving dimensions, mounting holes, connectors, or STEP models.	2 / 5
Completeness	The description is solely a 'Use when...' trigger clause — only 'when' is present without any statement of what the skill actually does (board spec lookup, dimension/hole/connector retrieval, STEP model installation).	2 / 5
Trigger Term Quality	'development board', 'SBC', 'MCU module', 'enclosure constraint', and 'CAD design' are natural phrases users would say in this domain. Missing common synonyms and specifics like board names (Raspberry Pi, ESP32) or file types (STEP), so not comprehensive.	4 / 5
Distinctiveness Conflict Risk	The board-level hardware/enclosure niche is distinct with specific trigger terms, but the trailing 'for hardware or CAD design' is broad enough to risk minor overlap with general CAD or EDA skills.	4 / 5
	Total	12 / 20 Passed

Validation

100%

Warnings & errors only

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: JimmyPang02/open-replicator
Path: reference/replicator-original/ee/board-spec/SKILL.md
Commit: 18436cc

Reviewed: 18 hours ago

Table of Contents

Discovery Implementation Validation

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.