CtrlK
BlogDocsLog inGet started
Tessl Logo

openspec-onboard

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

52

Quality

58%

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 ./.agent/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: concrete CLI commands, complete artifact templates, explicit pause points, and thoughtful fallbacks for scope and early exits. Its weaknesses are duplication (the command reference table appears twice), the absence of an explicit verification phase before archiving, and a monolithic ~550-line structure with no progressive disclosure into reference files despite sizable inline reference material.

Suggestions

Deduplicate the command reference table — keep it in one place (or move it to references/commands.md) and reference it from both the recap and the graceful-exit section.

Add an explicit verification checkpoint between Phase 9 (Apply) and Phase 10 (Archive), e.g., running '/opsx:verify <name>' or re-reading specs to confirm the implementation matches before archiving.

Move the stable artifact format templates (proposal, spec WHEN/THEN format, design, tasks) into a references/ file (e.g., references/artifact-templates.md) and keep only one inline example each, shrinking SKILL.md to the workflow itself.

DimensionReasoningScore

Conciseness

The body is mostly efficient — the scripted dialog templates are load-bearing for a teaching skill and it doesn't explain concepts Claude already knows — but it could be tightened: the command reference table appears verbatim twice (Phase 11 recap and the 'Graceful Exit' section), and the ASCII diagram placeholder box plus long verbatim display blocks add padding. Fits 'mostly efficient but includes some unnecessary explanation or could be tightened'; not a 2 because there is no generic-concept explanation, not a 4 because the duplication and dialog bulk exceed minor.

3 / 5

Actionability

Concrete, runnable commands appear throughout ('openspec status --json 2>&1 || echo "NOT_INITIALIZED"', 'openspec new change "<derived-name>"', 'mkdir -p openspec/changes/<name>/specs/<capability-name>', 'git log --oneline -10'), and the artifact templates (WHEN/THEN/AND spec format, checkbox tasks format) are complete. Minor gaps remain — artifact saves are described as 'write the content to openspec/changes/<name>/proposal.md' rather than given as a command, and names must be derived — so it fits 'mostly executable guidance; concrete code or commands with minor gaps' rather than the fully copy-paste-ready 5.

4 / 5

Workflow Clarity

Eleven phases are explicitly sequenced with a preflight check and fallback, PAUSE checkpoints at key transitions, a scope guardrail with user-override, and graceful exit paths; verification is embedded via the '## 2. Verify' task category and the command table. It is not a 5 because there is no explicit verify step between implementation (Phase 9) and archive (Phase 10) — '/opsx:verify' is only mentioned in a table — and not a 3 because checkpoints and fallbacks are largely explicit rather than implicit.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are all absent) and the body contains no references — a ~550-line monolith with the command table, artifact format templates, and exit-handling dialog all inline, and the command table duplicated. Section structure per phase is good, but content that clearly belongs in separate files (command reference, artifact templates) is inlined, fitting 'some structure but could be better organized; content that should be separate is inline'; not a 2 because headers and navigation within the file are strong, not a 4 because there are no references at all and the simple-skill exception (<50 lines) does not apply.

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 states what the skill does at a high level and is well-anchored to the OpenSpec domain, but it lacks any 'Use when...' trigger guidance and misses natural trigger phrasings users would say. Specificity is moderate — the workflow cycle's constituent actions are never named. Adding an explicit trigger clause and naming the concrete steps (create change, proposal, specs, tasks, implement, archive) would lift it substantially.

Suggestions

Add an explicit trigger clause, e.g., 'Use when the user is new to OpenSpec, wants to learn the workflow, or asks to get started / onboard with OpenSpec.'

Name the concrete actions of the cycle in the description (create a change, draft proposal/specs/design/tasks, implement, archive) instead of the abstract 'complete workflow cycle'.

Include natural trigger synonyms such as 'getting started', 'first change', or 'tutorial' so the description matches how users would actually phrase the request.

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'), but does not enumerate what the cycle involves, matching the anchor for 1-2 concrete actions without comprehensive coverage. It is not a 4 because it lists no several specific actions (e.g., create a change, write proposal/specs/tasks, implement, archive), and not a 2 because the action given is concrete rather than generic.

3 / 5

Completeness

It has a clear 'what' (guided onboarding that walks through a complete workflow cycle) but no 'Use when...' clause or any equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. Not a 4 because 'when' is entirely absent rather than merely imprecise; not a 2 because the 'what' is clear.

3 / 5

Trigger Term Quality

Relevant keywords like 'onboarding', 'OpenSpec', and 'workflow cycle' are present, but common natural variations a user would say ('getting started', 'learn OpenSpec', 'first change', 'tutorial') are missing. This fits the 'some relevant keywords but missing common variations' anchor; it is not a 4 because keyword coverage is thin and not a 2 because the terms are domain-specific rather than generic.

3 / 5

Distinctiveness Conflict Risk

'Guided onboarding for OpenSpec' carves a mostly distinct niche with the product name anchoring it, but it overlaps minorly with closely related OpenSpec skills (e.g., '/opsx:new' or '/opsx:ff' which also run the change cycle) and offers no trigger to disambiguate. Fits the 'mostly distinct; minor overlap risk' anchor; not a 5 due to that sibling-command overlap, not a 3 since the niche is genuinely specific.

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

Warning

Total

15

/

16

Passed

Repository
Draculabo/AntigravityManager
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.