CtrlK
BlogDocsLog inGet started
Tessl Logo

openspec-onboard

Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.

53

Quality

60%

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

Fix and improve this skill with Tessl

tessl review fix ./eval/local/skills/benchmarks/dependency/openspec/openspec-onboard/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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 a well-sequenced, mostly actionable guided-teaching skill with clear phase markers and a preflight validation checkpoint, but it runs long with some restated conceptual explanation and omits an implementation-to-archive verification feedback loop. Progressive disclosure is good for a single-file teaching skill, though the monolithic length leaves room to split out reference material.

Suggestions

Add an explicit verify checkpoint between implementation and archive (e.g., run '/opsx:verify <name>' and only archive when it passes) to close the validation gap before the destructive archive step.

Trim conceptual restatements of what proposals/specs/design are, since Claude already knows these concepts, to lift conciseness from 3 toward 4.

Consider moving the Command Reference tables and artifact templates into a referenced file to reduce the 555-line monolith and improve progressive disclosure.

DimensionReasoningScore

Conciseness

The 555-line body includes verbatim 'Display:' template blocks and conceptual explanations (e.g., 'The proposal captures why we're making this change') that partly restate what Claude already knows; not a 4 because several padded explanation passages could be trimmed, not a 2 because most content is functional scripting rather than pure fluff.

3 / 5

Actionability

Concrete executable commands ('openspec new change "<derived-name>"', 'openspec archive "<name>"', 'openspec instructions proposal --change "<name>" --json') plus specific file paths and templates give mostly executable guidance; not a 5 because placeholder templates and the omitted verify step leave minor gaps.

4 / 5

Workflow Clarity

An 11-phase sequence with explicit EXPLAIN/DO/SHOW/PAUSE markers and a preflight CLI-install validation checkpoint is clearly sequenced; not a 5 because implementation lacks a validate-then-archive feedback loop — the '/opsx:verify' command is listed but never wired into the cycle, leaving a checkpoint gap before the destructive archive step.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ all absent) and the body is a single well-organized file with clear per-phase sections and no nested references; not a 5 because the monolithic 555-line file could offload the command reference and templates into referenced files, though for a guided-teaching skill the inlined structure is reasonable.

4 / 5

Total

15

/

20

Passed

Description

53%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 names the domain and a couple of concrete actions but stops short of comprehensive action coverage and omits an explicit 'Use when...' trigger clause, leaving the 'when' only weakly implied. It is clearly distinct within the OpenSpec niche yet relies on generic onboarding language rather than the actual slash-command triggers.

Suggestions

Add an explicit 'Use when...' trigger clause (e.g., 'Use when onboarding to OpenSpec or running /opsx:onboard for the first time').

Include the actual slash-command trigger '/opsx:onboard' and synonyms like 'tutorial' or 'get started' to improve trigger-term coverage.

Enumerate more concrete actions (e.g., 'create proposals, write specs, draft designs, implement tasks, and archive changes') to lift specificity from 3 toward 4-5.

DimensionReasoningScore

Specificity

Quotes 'Guided onboarding for OpenSpec' and 'walk through a complete workflow cycle with narration and real codebase work' — it names the domain plus two concrete actions but stops short of comprehensive coverage; not a 4 because the actions are generic rather than enumerated.

3 / 5

Completeness

It clearly answers 'what' (guided onboarding walking through a complete workflow cycle) but lacks an explicit 'Use when...' trigger clause, which per rubric guidance caps completeness at 3; not a 4 because the 'when' is only weakly implied by 'onboarding'.

3 / 5

Trigger Term Quality

Natural terms 'OpenSpec', 'onboarding', 'workflow cycle', and 'codebase' are present, but it omits the actual slash-command trigger '/opsx:onboard' and common synonyms like 'tutorial', 'learn', or 'get started'; not a 4 due to missing common variations.

3 / 5

Distinctiveness Conflict Risk

The OpenSpec niche is clearly scoped and unlikely to trigger for unrelated skills, with only minor overlap risk from the generic word 'onboarding'; not a 5 because the phrasing leans on the generic 'onboarding' rather than distinct trigger phrases.

4 / 5

Total

13

/

20

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (555 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository
rpamis/comet
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.