openspec-onboard

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

Quality

63%

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 ./skills/openspec-onboard/SKILL.md

Quality

Content

77%

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

The content is a highly actionable, clearly sequenced onboarding workflow with strong checkpoints and graceful handling. Its main weaknesses are verbosity (duplicated command tables, heavy template scaffolding) and the absence of any progressive disclosure—everything lives in one monolithic file with no reference files.

Suggestions

De-duplicate the command reference table (it appears in both Phase 11 and the 'User just wants command reference' branch) and trim placeholder-heavy artifact templates to tighten conciseness.

Move stable detail into reference files (e.g. references/command-reference.md for the command tables, references/artifact-templates.md for proposal/spec/design/tasks scaffolding) and link to them from the main body to improve progressive disclosure.

Add a brief inline validation/verification beat (e.g. run `openspec validate` or `openspec status` after artifact creation) to make the workflow's feedback loops explicit.

Dimension	Reasoning	Score
Conciseness	The body is mostly actionable workflow scripting without explaining concepts Claude already knows, but it is padded: the command reference table is duplicated (Phase 11 and the 'just wants command reference' branch), artifact templates carry verbose placeholder scaffolding, and ASCII art adds tokens that could be trimmed.	2 / 3
Actionability	It provides concrete, executable commands (e.g. `openspec new change "<derived-name>"`, `openspec instructions proposal --change "<name>" --json`, `openspec archive "<name>"`) plus specific codebase-scan patterns and copy-paste-ready templates, matching the fully-executable anchor.	3 / 3
Workflow Clarity	Eleven phases are clearly sequenced with the EXPLAIN→DO→SHOW→PAUSE pattern, explicit PAUSE acknowledgment checkpoints, a preflight CLI validation check, scope guardrails, and graceful-exit branches, giving clear sequencing with feedback loops.	3 / 3
Progressive Disclosure	The file is well-organized into phases, but it is a single ~545-line monolithic SKILL.md with no bundle files or external references, and content that could be split (command reference, artifact templates, exit handling) is inline, matching the 'some structure but content that should be separate is inline' anchor.	2 / 3
	Total	10 / 12 Passed

Description

50%

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 clearly states what the skill does but omits any explicit 'Use when...' trigger guidance, leaving the when only implied. It is specific to the OpenSpec niche yet thin on natural trigger terms and could overlap with sibling OpenSpec skills.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user is new to OpenSpec or asks to be onboarded/walked through an OpenSpec workflow.'

List a couple more concrete actions (e.g. 'create a change, draft proposal/specs/design/tasks, implement, and archive') to lift specificity from 2 to 3.

Include natural trigger variations such as 'learn OpenSpec', 'OpenSpec tutorial', or 'first OpenSpec change' to broaden trigger-term coverage.

Dimension	Reasoning	Score
Specificity	It names the domain ("onboarding for OpenSpec") and one concrete action ("walk through a complete workflow cycle ... with real codebase work"), but does not enumerate multiple specific concrete actions, so it sits between the vague and the comprehensive anchors.	2 / 3
Completeness	The what is stated (guided onboarding, walk a workflow cycle with real codebase work), but there is no explicit when/trigger clause, which per the judging guidelines caps completeness at 2.	2 / 3
Trigger Term Quality	"onboarding" and "OpenSpec" are plausible natural terms, but coverage is thin with no common variations and no "Use when..." trigger phrase, so it matches the 'some relevant keywords but missing variations' anchor.	2 / 3
Distinctiveness Conflict Risk	The OpenSpec-onboarding niche is somewhat specific and distinct from generic skills, but it overlaps with the broader openspec-* command family and lacks an explicit trigger to disambiguate, matching the 'somewhat specific but could overlap' anchor.	2 / 3
	Total	8 / 12 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (555 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: Fission-AI/OpenSpec
Path: skills/openspec-onboard/SKILL.md
Commit: 6a5171e

Reviewed: 5 days 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.