verify-changes

Prove code works by running it, not just checking it exists. Verification through execution rather than inspection. Use after writing or modifying code to ensure it actually functions correctly.

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/verify-changes/SKILL.md

Quality

Content

67%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 well-structured and highly actionable, with a clear verification protocol, concrete commands, and useful checklists. Its main weaknesses are mild redundancy in the framing/anti-patterns sections and a missing explicit retry loop for failed verifications.

Suggestions

Add an explicit feedback loop to the protocol (e.g., "If verification fails: fix the issue, then re-run the verification before reporting") to close the workflow-clarity gap.

Trim the redundant inspection-vs-execution framing: the "Core Principle" block and the "Anti-Patterns" table convey the same idea — consolidate to one.

Consider moving the per-project-type checklists into a references file so the main SKILL.md stays a lean overview, improving progressive disclosure.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient, but the "Core Principle" block and the "Anti-Patterns" table both restate the same inspection-vs-execution distinction already covered in the description, adding redundancy that could be tightened.	3 / 5
Actionability	It provides concrete, copy-paste-ready commands (npm run build/test/dev, node -e require, curl, python script.py) plus a change-type mapping table and checklists, though a few rows like UI/config changes stay high-level.	4 / 5
Workflow Clarity	The 4-step Verification Protocol (Identify → Determine Method → Execute → Report) is clearly sequenced with execution itself as the validation checkpoint, but it lacks an explicit failure/retry feedback loop for when verification fails.	4 / 5
Progressive Disclosure	Content is organized into clear, navigable sections with no nested references, and the absence of bundle files keeps it self-contained; it is not a 5 because everything is inline at over 50 lines with no one-level-deep split for the project-type checklists.	4 / 5
	Total	15 / 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 clearly conveys its purpose (prove code works by running it) and when to use it, with decent natural trigger language and a distinct niche. It is held back from the top band by a single-trigger 'when' clause and a lack of multiple specific concrete actions.

Suggestions

Add more concrete trigger phrases to the 'when' clause (e.g., "Use when the user asks 'does this work?', 'test this', or 'verify'"), since those natural phrases currently live only in when_to_use.

Enumerate 1-2 more specific verification actions in the description (e.g., "run builds, tests, or reproduce the bug scenario") to lift specificity above a single abstract action.

Include a synonym like 'test' or 'debug' in the description itself to broaden natural keyword coverage.

Dimension	Reasoning	Score
Specificity	Names the domain (code verification) and 1-2 concrete actions ("running it", "Verification through execution") but does not enumerate several specific actions like build/test/reproduce, so it is not comprehensive.	3 / 5
Completeness	It clearly answers both what ("Prove code works by running it...") and when ("Use after writing or modifying code"), but the 'when' offers a single trigger context rather than multiple concrete trigger phrases, so it is not a 5.	4 / 5
Trigger Term Quality	Natural terms like "code works", "running it", "verification", and "writing or modifying code" are present, but common variations such as "test this" or "does this work?" are absent from the description field.	4 / 5
Distinctiveness Conflict Risk	The execution-versus-inspection framing carves a distinct niche, but "verify code works" has minor overlap risk with general testing skills rather than being fully conflict-free.	4 / 5
	Total	15 / 20 Passed

Validation

87%

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 — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
allowed_tools_field	'allowed-tools' contains unusual tool name(s)	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	14 / 16 Passed

Repository: vudovn/ag-kit
Path: .agents/skills/verify-changes/SKILL.md
Commit: 211561c

Reviewed: 8 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.