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`.
96
97%
Does it follow best practices?
Impact
92%
1.00xAverage 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 hits all the marks. It provides specific concrete actions, abundant natural trigger terms via an explicit 'Use when' clause, clear scope boundaries distinguishing it from adjacent skills ('review' and 'agent-readiness'), and a well-defined output (verdict types). The only minor note is slight verbosity in the trigger term list, but it serves the purpose of comprehensive coverage.
| 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 drawing boundaries: it's for self-checking your OWN changes (not others' — that's 'review'), it's a pre-review pass (not a ship decision), and it hands off to 'agent-readiness' if the repo can't boot. These explicit disambiguation clauses make conflict unlikely. | 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 with excellent workflow clarity, strong actionability through concrete commands and examples, and efficient use of tokens. The five-step verification workflow with explicit verdicts and handoff paths is well-designed. The only minor weakness is that referenced bundle files are not provided, making it impossible to fully evaluate the progressive disclosure structure, 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 bullet points, the workflow steps are direct, and the output format is tightly specified with a concrete example. | 3 / 3 |
Actionability | The skill provides concrete, specific guidance at every step: exact commands to run (`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), clear verdict categories, and a copy-paste-ready output template. The workflow is fully executable. | 3 / 3 |
Workflow Clarity | The five-step workflow is clearly sequenced (guardrails → real surface → self-correct → probe adjacent risk → synthesize verdict) with explicit validation checkpoints. Step 3 includes a feedback loop for self-correction, step 4 probes edge cases including failure paths, and the verdict step provides clear decision criteria with handoff paths for each outcome including the blocked/infrastructure-weak case. | 3 / 3 |
Progressive Disclosure | The skill references three supporting files (references/verification.md, references/evidence-rules.md, references/simplification.md) with clear one-level-deep links, which is good structure. However, no bundle files were provided, so we cannot confirm these references exist or are useful. The inline content is well-organized but the 'Before You Start' section and 'Handoffs' section add moderate length that could potentially be condensed or moved to a reference. | 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