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, interactive tutorial with concrete CLI commands, explicit pause points, and thoughtful edge-case handling (scope guardrail, graceful exits). Its weaknesses are redundancy (duplicated command tables, padded display blocks), inlined templates and reference material that belong in separate bundle files, and a missing verification step before archiving.

Suggestions

Deduplicate the command reference: keep one table (in a references/ file or a single section) instead of two near-identical tables in Phase 11 and the exit-handling section.

Move the artifact templates (proposal, spec, design, tasks formats) into references/ files (e.g. references/templates.md) and link to them, reducing SKILL.md to the workflow overview.

Add a verification checkpoint before Phase 10 archive — e.g. confirm all tasks are checked off and run /opsx:verify — since archiving relocates the change directory after real codebase edits.

DimensionReasoningScore

Conciseness

Mostly efficient procedural scripting rather than explanation of concepts Claude already knows, but there is real redundancy: the command reference table appears twice nearly verbatim (Phase 11 and the 'user just wants command reference' section), and the welcome/recap blocks are padded. Fits 'Mostly efficient but includes some unnecessary explanation or could be tightened'; not 4 because the duplication and boilerplate display text are noticeable.

3 / 5

Actionability

Concrete executable commands are provided throughout ('openspec status --json 2>&1 || echo NOT_INITIALIZED', 'openspec new change "<name>"', 'openspec archive "<name>"', git log, mkdir -p), plus fill-in templates for proposal, spec, design, and tasks artifacts. The placeholders are justified because content depends on the user's chosen task. Minor gaps (e.g., the 'openspec instructions proposal --change ... --json' step is invoked after drafting with unclear output handling) keep it at 'Mostly executable guidance' rather than fully copy-paste ready.

4 / 5

Workflow Clarity

An 11-phase sequence with explicit PAUSE checkpoints, a preflight initialization check, graceful exit handling, and a guardrails section — clear sequence with most checkpoints present. Not 5 because there is no verification step before the archive operation (moving the change directory) even though the workflow itself creates real codebase changes; not 3 because checkpoints are explicit, not missing or implicit.

4 / 5

Progressive Disclosure

The single 500+ line SKILL.md inlines content that clearly belongs in separate files: full artifact templates (proposal/design/specs/tasks formats), two copies of the command reference table, and exit-handling scripts. Section headers give reasonable structure, but nothing is split out or referenced externally. Matches 'Some structure but could be better organized; content that should be separate is 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 identifies its domain and purpose, but lacks any 'when to use' trigger guidance and doesn't enumerate the concrete workflow capabilities the skill actually delivers. It is serviceable but below the standard of the reference good examples.

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.'

Name the concrete workflow stages covered (create a change, draft proposal/specs/design/tasks, implement, archive) so the capability list is comprehensive rather than a single generic 'workflow cycle'.

Include natural synonyms such as 'getting started', 'tutorial', and 'first change' to improve trigger term coverage.

DimensionReasoningScore

Specificity

The description names the domain ("Guided onboarding for OpenSpec") and one concrete action pattern ("walk through a complete workflow cycle with narration and real codebase work"), but doesn't enumerate the specific capabilities it covers (proposal, specs, design, tasks, apply, archive). It matches the anchor 'Names domain and 1-2 concrete actions, but not comprehensive' rather than 4, which requires several listed specific actions.

3 / 5

Completeness

The 'what' is reasonably clear (guided onboarding, walking through a full workflow cycle in the real codebase), but there is no 'Use when...' clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. It does not reach 4 because 'when' is entirely absent rather than just under-specified.

3 / 5

Trigger Term Quality

Relevant keywords like "onboarding", "OpenSpec", and "workflow cycle" are present, but common natural variations users would say are missing: "getting started", "tutorial", "learn OpenSpec", "first change". This fits 'Some relevant keywords but missing common variations or synonyms', not 4, which expects good coverage with only a few terms missing.

3 / 5

Distinctiveness Conflict Risk

The OpenSpec-specific framing ("Guided onboarding for OpenSpec") gives it a clear niche that wouldn't trigger for unrelated skills, though it overlaps with the other OpenSpec family commands it references (/opsx:new, /opsx:ff). Mostly distinct with minor overlap risk against closely related skills — anchor 4, not 5, since sibling OpenSpec skills could compete for similar phrasings.

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 (530 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository

dwmkerr/git-workforest

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.