CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

openspec-verify-change

Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/openspec-verify-change/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

75%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 tight, highly actionable instruction-only workflow: concrete CLI commands, exact parsing rules, explicit issue severities with message templates, and well-defined degradation and output behavior. The gaps are modest — a few heuristic steps lack concrete commands, command-failure recovery is unspecified, and the severity taxonomy is stated twice.

DimensionReasoningScore

Conciseness

The body is almost entirely operational: concrete CLI commands, exact checkbox formats, and issue-message templates with no explanations of concepts Claude already knows. Minor trimming is possible (the CRITICAL/WARNING/SUGGESTION taxonomy is defined in step 4 and re-explained in step 8), so it sits at anchor 4 rather than the fully lean anchor 5.

4 / 5

Actionability

Copy-paste-ready commands are given (`openspec list --json`, `openspec status --change "<name>" --json`, `openspec instructions apply --change "<name>" --json`) alongside exact output formats and a report template. Minor gaps keep it below anchor 5: steps like 'Search codebase for keywords related to the requirement' provide no concrete search command or example.

4 / 5

Workflow Clarity

A clearly sequenced 8-step workflow with explicit conditionals, severity heuristics, graceful degradation paths, and a defined output format. It misses anchor 5 because there are no error-recovery checkpoints for command or JSON-parse failures (e.g., what to do if `openspec status` fails or the change name is invalid).

4 / 5

Progressive Disclosure

Single-file skill with no bundle files (references/, scripts/, assets/ are absent) and no external references; all content is appropriately inline at this size. Sections (Steps, Verification Heuristics, Graceful Degradation, Output Format) are well-organized with no orphaned references, matching anchor 4's good structure with minor gaps (the report template could arguably live in a reference file).

4 / 5

Total

16

/

20

Passed

Description

70%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 follows the strong what+when pattern with an explicit trigger clause and a reasonably distinct niche. Its main weakness is specificity: it states one action rather than the concrete verification dimensions it performs, and it omits tool/domain trigger terms like 'openspec' that users would naturally say.

Suggestions

Enumerate the concrete verification actions in the description, e.g., 'Check task completion, spec coverage, and design adherence against change artifacts' to lift specificity from one action to several.

Add natural trigger variations and domain terms users would actually say, such as 'openspec change', 'ready to archive', or 'check the change is done', to improve trigger-term coverage and distinctiveness.

Clarify the target domain upfront (e.g., 'Verify openspec change implementations match their specs, tasks, and design') to reduce overlap risk with generic code-review skills.

DimensionReasoningScore

Specificity

"Verify implementation matches change artifacts" names the domain and one concrete action, but does not enumerate the actual checks performed (task completion, spec coverage, design adherence). This matches anchor 3 ('1-2 concrete actions, not comprehensive') rather than 4, which requires several specific listed actions.

3 / 5

Completeness

Both parts are explicit: the what ("Verify implementation matches change artifacts") and an explicit "Use when the user wants to validate that implementation is complete, correct, and coherent before archiving" clause. The when is concrete but stops short of anchor 5's comprehensive domain-specific trigger phrases (e.g., 'openspec change', 'ready to archive').

4 / 5

Trigger Term Quality

Natural user phrases like "validate that implementation is complete", "before archiving", and "verify implementation" are present, but common variations ("check the change", "review tasks", or the tool name "openspec") are missing. Good coverage with a few natural terms absent, matching anchor 4.

4 / 5

Distinctiveness Conflict Risk

The change-artifact/archiving verification niche is mostly distinct, but the generic opening "Verify implementation matches" could overlap with general code-review or PR-verification skills. Mostly distinct with minor overlap risk, matching anchor 4.

4 / 5

Total

15

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

PBH-BTN/PeerBanHelper

Path

.claude/skills/openspec-verify-change/SKILL.md

Revision

a1b1216

Reviewed

Table of Contents

DiscoveryImplementationValidation

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.

Claim skill