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

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./eval/local/skills/benchmarks/dependency/openspec/openspec-verify-change/SKILL.md

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, executable verification procedure with concrete CLI commands, exact parsing markers, and a well-sequenced workflow including graceful degradation and a clear report format. Minor improvements are possible: deduplicate the heuristics section, specify the codebase-search strategy, and add error handling for failed CLI calls.

Dimension	Reasoning	Score
Conciseness	The body is imperative and free of explanations of concepts Claude already knows, with concrete commands and exact markers ("- [ ]", "### Requirement:", "#### Scenario:"). The "Verification Heuristics" section partly restates guidance already embedded in steps 5-7, which keeps it below anchor 5.	4 / 5
Actionability	Gives executable commands ("openspec list --json", "openspec status --change \"<name>\" --json", "openspec instructions apply --change \"<name>\" --json"), exact parsing rules, and exact issue-message formats with recommendations. Vague spots like "Search codebase for keywords related to the requirement" lack specific search strategy, preventing a 5.	4 / 5
Workflow Clarity	A clearly sequenced 1-8 numbered workflow with explicit branching ("If incomplete tasks exist"), graceful degradation for partial artifacts, and a final assessment gate before archiving. It is read-only so the destructive-operation cap does not apply, but there is no error-recovery guidance if the openspec commands fail or return unexpected output, keeping it below anchor 5.	4 / 5
Progressive Disclosure	Well-organized with clear sections, headers, and a self-contained single-file structure (no bundle files exist to reference). At ~150 lines the content is cohesive and appropriately placed, though the report template and issue-format details could arguably live in a separate reference file, which is the minor gap versus anchor 5.	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 efficiently covers both what the skill does and when to use it, with a well-scoped openspec niche and natural trigger phrasing. Its main weakness is thin capability detail in the 'what' clause — a single action where enumerating the verification dimensions would improve specificity and completeness.

Suggestions

Expand the 'what' clause to name the concrete verification dimensions, e.g., "Verify implementation matches change artifacts by checking task completion, spec requirement coverage, and design adherence."

Add natural trigger variations users might say, such as "Use when the user asks to check a change, validate tasks/specs are done, or confirm a change is ready to archive."

Dimension	Reasoning	Score
Specificity	"Verify implementation matches change artifacts" names the domain and one concrete action, but does not enumerate the concrete checks it performs (task completion, spec coverage, design adherence). It is above anchor 2 because the action is concrete rather than generic, but below anchor 4 which expects several specific actions listed.	3 / 5
Completeness	Both "what" ("Verify implementation matches change artifacts") and an explicit "Use when..." clause are present. Not 5 because the 'what' is a single terse clause without the concrete multi-action detail of the anchor-5 example; not 3 because the 'when' is explicit, not merely implied.	4 / 5
Trigger Term Quality	"validate that implementation is complete, correct, and coherent before archiving" supplies natural phrases a user would say (validate, complete, archiving). Missing common variations such as "check my change", "review tasks", or "is the change done", so it falls short of anchor 5's comprehensive synonym coverage.	4 / 5
Distinctiveness Conflict Risk	"change artifacts" and "before archiving" establish a clear openspec-specific niche with minimal conflict risk. Minor overlap remains with generic implementation-review or code-review skills, keeping it below the anchor-5 clear-niche bar.	4 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

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: rpamis/comet
Path: eval/local/skills/benchmarks/dependency/openspec/openspec-verify-change/SKILL.md
Commit: 899d1fb

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

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.