uinaf/verify
Verify your own completed code changes using the repo's existing infrastructure and an independent evaluator context. Use after implementing a change when you need to run unit or integration tests, check build or lint gates, prove the real surface works with evidence, and challenge the changed code for clarity, deduplication, and maintainability. If the repo is not verifiable yet, hand off to `agent-readiness`; if you are reviewing someone else's code, use `review`.
97
98%
Does it follow best practices?
Impact
94%
1.02xAverage score across 3 eval scenarios
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly defines its purpose, provides abundant natural trigger terms, and explicitly delineates its boundaries against related skills like 'review' and 'agent-readiness'. The description is comprehensive without being padded, and the explicit verdict outputs (ready for review / needs more work / blocked) make the skill's function unambiguous. Minor note: the description uses second person ('your own') but this is contextually appropriate for describing when to invoke the skill rather than describing the skill's capabilities.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: run repo guardrails (lint, typecheck, tests, build), exercise the real surface with evidence, catch self-correctable issues, and produces a specific verdict (ready for review / needs more work / blocked). | 3 / 3 |
Completeness | Clearly answers both 'what' (pre-review sanity pass that runs guardrails, exercises the surface, catches issues, produces a verdict) and 'when' (explicit 'Use when...' clause with multiple trigger scenarios). Also includes helpful boundary conditions for when NOT to use it (use 'review' for others' diffs, 'agent-readiness' if repo can't boot). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'check your work', 'run checks', 'validate changes', 'make sure a change is ready', 'test it end-to-end', 'lint', 'typecheck', 'tests', 'build'. These are highly natural phrases a user would use. | 3 / 3 |
Distinctiveness Conflict Risk | Very clearly distinguished from related skills by explicitly naming boundaries: it's for self-checking your OWN changes before review, not for reviewing others' work ('review') or for repo setup issues ('agent-readiness'). The 'never a ship decision' constraint further narrows its niche. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
92%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality skill that provides a clear, actionable, and well-structured verification workflow. It excels at conciseness (no wasted tokens), actionability (concrete commands and examples throughout), and workflow clarity (explicit 5-step sequence with validation checkpoints and clear verdicts). The only minor weakness is that the referenced bundle files are not available to confirm progressive disclosure works end-to-end, though the references themselves are well-signaled and appropriately scoped.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient throughout. It assumes Claude's competence, avoids explaining basic concepts, and every section earns its place. The principles are crisp, the workflow steps are direct, and the output format is tightly specified with a concrete example. | 3 / 3 |
Actionability | The skill provides concrete, executable guidance at every step: specific commands like `make verify`, `curl http://127.0.0.1:3000/health`, `node dist/cli.js --help`; specific examples of self-corrections (typos, `any` types, swallowed errors); and a precise output template with labeled fields and an example. | 3 / 3 |
Workflow Clarity | The 5-step workflow is clearly sequenced with explicit ordering (guardrails first, then real surface, then self-correct, then probe adjacent risk, then synthesize). Validation is built into the structure itself — step 1 runs guardrails, step 2 exercises the real surface, step 4 probes edge cases, and step 5 produces a verdict with explicit feedback loops (needs more work → fix → re-verify, blocked → hand off to agent-readiness). | 3 / 3 |
Progressive Disclosure | The skill references three supporting files (references/verification.md, references/evidence-rules.md, references/simplification.md) which are well-signaled and one level deep. However, no bundle files were provided, so we cannot confirm these references resolve to real content. The inline reference in step 2 to evidence-rules.md and step 3 to simplification.md is well-placed, but the references section at the bottom could benefit from clearer descriptions of when to consult each file. | 2 / 3 |
Total | 11 / 12 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents