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 is a well-sequenced, highly actionable tutorial script with clear phase structure, explicit pauses, and thoughtful edge-case handling (preflight failure, oversized tasks, mid-way exits). Its weaknesses are redundancy (duplicated command tables, restated guardrails), a missing verify-before-archive checkpoint, and everything inlined in a single long file rather than split into references.

Suggestions

Add a verification step between implementation and archive (e.g. run /opsx:verify or the project's tests, fix and re-run if failing) so the workflow has a feedback loop before the destructive archive move.

Deduplicate the command reference: it appears nearly verbatim in both Phase 11's recap and the graceful-exit section — keep one canonical table and point to it from the other.

Move the artifact format templates (proposal/spec/design/tasks skeletons) and the command reference into a references/ file (e.g. references/artifact-templates.md), keeping SKILL.md as a lean walkthrough script.

DimensionReasoningScore

Conciseness

The body is mostly purposeful since a scripted tutorial legitimately needs its display templates, but it could be tightened: the command reference table appears twice nearly verbatim (Phase 11 recap and the graceful-exit command-reference section), and the Guardrails section restates rules already embedded in the phases. This matches the anchor for mostly efficient content with some unnecessary explanation or tightening opportunities.

3 / 5

Actionability

Guidance is highly concrete — exact commands ("openspec new change \"<derived-name>\"", "openspec archive \"<name>\"", preflight with CLI_NOT_INSTALLED fallback), full display templates, and per-phase EXPLAIN/DO/SHOW/PAUSE instructions. Minor gaps remain: "openspec instructions proposal --change \"<name>\" --json" is given without explaining how to consume its JSON output, and file writes are described but not scripted, so it does not reach fully copy-paste-ready anchor 5.

4 / 5

Workflow Clarity

Excellent sequencing: Preflight validates the CLI and stops if missing, phases 1-11 follow a consistent EXPLAIN/DO/SHOW/PAUSE pattern with marked PAUSE checkpoints, a scope guardrail, and graceful exit handling. The gap is that Phase 9 implementation proceeds directly to Phase 10 archive with no verification step (/opsx:verify is only mentioned in a table, never invoked in the flow), matching the anchor for a clear sequence with minor validation gaps.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent) and no external files are referenced; all ~555 lines live inline in SKILL.md. Phase-based section structure makes it navigable, but content that belongs in separate reference files — the artifact format templates (proposal/spec/design/tasks) and the duplicated command reference tables — is inlined, matching the anchor for some structure with content that should be separate kept inline.

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 clearly communicates what the skill does within a distinct niche, but it lacks any explicit 'when to use' trigger guidance and natural trigger terms users would say when they need onboarding. Adding a 'Use when...' clause with natural phrases would address the main weaknesses.

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 a walkthrough/tutorial of their first change."

Include natural user phrasings as trigger terms such as "get started", "learn OpenSpec", "first change", or "walk me through" so the skill surfaces when users ask in their own words.

Sharpen the capability statement into concrete actions (e.g. "scans the codebase for starter tasks, creates a change, drafts proposal/specs/design/tasks artifacts, implements, and archives it") to lift specificity.

DimensionReasoningScore

Specificity

The description names the domain ("Guided onboarding for OpenSpec") and one concrete action ("walk through a complete workflow cycle with narration and real codebase work"), matching the anchor for domain plus 1-2 concrete actions without comprehensive coverage. It does not list several distinct specific actions, so it falls short of anchor 4.

3 / 5

Completeness

The 'what' is clear (guided walkthrough of a complete workflow cycle with narration and real codebase work), but there is no 'Use when...' clause or equivalent explicit trigger guidance; the 'when' is only weakly implied by the word "onboarding". Per the judging guidelines, a missing 'Use when...' clause caps completeness at 3.

3 / 5

Trigger Term Quality

Relevant keywords like "onboarding", "OpenSpec", and "workflow cycle" are present, but natural phrases users would actually say ("get started with OpenSpec", "learn OpenSpec", "tutorial", "first change") are missing, matching the anchor for some relevant keywords without common variations or synonyms.

3 / 5

Distinctiveness Conflict Risk

"Guided onboarding for OpenSpec" is a clear niche tied to a specific tool and purpose, making it mostly distinct. However, the skill performs the same propose/specify/design/tasks/apply/archive operations as the sibling OpenSpec commands it documents (/opsx:propose, /opsx:apply), creating minor overlap risk with closely related skills, which matches anchor 4 rather than 5.

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/livedown

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.