CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

openspec-onboard

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

52

Quality

66%

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 ./.claude/skills/openspec-onboard/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%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 delivers a highly actionable, clearly sequenced 11-phase tutorial with explicit pause checkpoints and robust fallback handling. Its main weaknesses are duplicated command-reference content and the absence of any verification step before archiving, plus no use of separate reference files for the template/command material.

Suggestions

Deduplicate the command reference tables (Phase 11 and Graceful Exit) into a single section, or move them to a references/commands.md file.

Insert a verification step between implementation and archive, e.g. running "openspec verify" or /opsx:verify, to close the feedback loop.

Tighten the display templates by trimming placeholder prose, and consider moving the artifact templates (proposal/spec/design/tasks) into a references/ file for progressive disclosure.

DimensionReasoningScore

Conciseness

The body is mostly purposeful (scripted display templates are the product of this teaching skill), but the command reference tables are duplicated verbatim in Phase 11 and the Graceful Exit section, and several templates carry placeholder padding that could be tightened.

3 / 5

Actionability

Concrete executable commands are given throughout ("openspec new change \"<derived-name>\"", "openspec archive \"<name>\"", preflight check with fallback output) alongside exact display templates and file paths. Minor gap: artifact saves are described ("Then write the content to openspec/changes/<name>/proposal.md") rather than given as fully copy-paste-ready steps.

4 / 5

Workflow Clarity

Eleven clearly numbered phases with explicit PAUSE checkpoints, a preflight CLI validation, fallbacks (no suggestions found, scope guardrail, graceful exit) form a strong sequence. Minor validation gap: there is no verification step between implementation (Phase 9) and archive (Phase 10), e.g. invoking the documented /opsx:verify, which keeps it below the anchor-5 feedback-loop standard.

4 / 5

Progressive Disclosure

The skill is a single well-sectioned SKILL.md with no bundle files. Content such as the command reference tables (duplicated twice) and the artifact templates could live in a references/ file to keep SKILL.md a lean overview, so structure is present but organization could be improved.

3 / 5

Total

14

/

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 is reasonably specific and sits in a distinct niche, but it lacks any explicit "when to use" trigger guidance and misses natural synonym terms. Adding a Use-when clause and enumerating the concrete workflow steps would lift it substantially.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user wants to get started with OpenSpec, learn the OpenSpec workflow, or asks for an OpenSpec tutorial/onboarding."

Enumerate the concrete actions of the cycle (create a change, draft proposal/specs/design/tasks, implement, archive) to improve specificity.

Include natural synonym keywords such as "getting started", "tutorial", and "first change" to broaden trigger coverage.

DimensionReasoningScore

Specificity

"Guided onboarding for OpenSpec" names the domain and "walk through a complete workflow cycle with narration and real codebase work" gives 1-2 concrete actions, but the individual workflow steps (create change, proposal, specs, tasks, archive) are not enumerated, so coverage is not comprehensive.

3 / 5

Completeness

The description clearly answers "what" (guided onboarding, walking through a complete workflow cycle) but contains no "Use when..." clause or equivalent trigger guidance, which per the judging guidelines caps completeness at 3.

3 / 5

Trigger Term Quality

"onboarding" is a natural keyword a user might say, but common variations and synonyms such as "getting started", "tutorial", or "learn OpenSpec" are missing.

3 / 5

Distinctiveness Conflict Risk

The OpenSpec-specific niche ("onboarding for OpenSpec") is mostly distinct with clear triggers, though it could mildly overlap with other OpenSpec workflow skills (propose/apply/archive) whose descriptions share the domain vocabulary.

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.

Validation — 15 / 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

dwmkerr/openspec-flow

Path

.claude/skills/openspec-onboard/SKILL.md

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.