engineering / Review & improve
verify
Proves that a code change meets its acceptance criteria.
Markdown workflowYou or your agent
Put it to work.
Ask your agent to use verify, or let it load the skill when your task matches the description.
Use the verify skill <task, acceptance criteria, diff, branch, PR, URL, or flow>Invocation syntax varies by agent. Use the skill name in your prompt, or your agent’s supported slash command.
About this skill
Prove that a code change meets its stated acceptance criteria — map every
AC-n/INV-n ID (or task criterion) to concrete evidence, add focused tests
where proof is missing, and require a real browser check for browser-facing
work.
- Read the task, source design, changed code, and existing tests; preserve
AC-n/INV-nIDs verbatim. - Map every criterion, invariant, and affected failure path to proof by ID.
- Add or update focused tests where proof is missing; assertions must fail if the behavior breaks.
- Run the narrowest checks that exercise the changed behavior, widening only when shared interfaces changed.
- For browser-rendered changes, check desktop/mobile, keyboard use, console errors, and failed requests in a real browser.
- Report each ID as pass, fail, or unverified with its evidence.
Flow
flowchart LR
A[Task / design / diff] --> B[Map AC-n / INV-n to proof]
B --> C{Proof missing?}
C -->|Yes| D[Add focused tests]
C -->|No| E[Run narrowest checks]
D --> E
E --> F{Browser-facing?}
F -->|Yes| G[Real browser check]
F -->|No| H[Report pass/fail/unverified per ID]
G --> HInstall
bash
npx skills@latest add smeltery/skillsUsage
text
/verify AC-3 and INV-1 from docs/webhook-delivery/design.md against the current branch
/verify https://github.com/owner/repo/pull/123Output
A per-ID report (AC-n, INV-n, or task criterion) marked pass, fail, or
unverified, each with the command, browser flow, or other evidence that
backs it.
When not to use this
- Building new behavior test-first — use
tdd; this skill verifies against stated criteria after the fact, on your own or someone else's change. - An independent read of the implementation itself — use
review.
Files
SKILL.md— canonical skill definition.
Attribution
Ported from owainlewis/blueprint under MIT, renamed from test to verify to avoid confusion with tdd. See THIRD_PARTY_LICENSES.md.
Read the full SKILL.md
Verify
Workflow
- Read the task, its source design when present, changed code, existing tests, and repository instructions. Acceptance criteria come from the task or approved design. Preserve their wording and
AC-norINV-nIDs. Never rewrite criteria to match the code. - Map every acceptance criterion, cited invariant, and affected failure path to proof by ID. Test changed behavior and behavior a refactor must preserve.
- If automated tests cannot exercise the affected behavior, explain why and give other evidence.
- Add or update focused tests where proof is missing. Assertions should fail when the changed behavior breaks.
- Assert behavior a user or caller can observe unless the test targets a documented internal contract. Keep setup and assertions no more complex than the scenario.
- Run the narrowest checks that exercise the changed behavior and affected interfaces. Run wider checks when shared behavior or interfaces changed.
- When browser-rendered behavior changes, start the documented app and check the required flows and affected failures in a real browser.
- Check desktop and mobile when layout or responsive styles changed.
- Check keyboard use when interactions changed.
- Check console errors and failed requests during every flow.
- Capture evidence. Reading source is not browser proof.
- Report each
AC-n,INV-n, or task criterion as pass, fail, or unverified. Include the command, browser flow, or other evidence.
Boundaries
- Do not weaken assertions to make a change pass.
- Do not fix unrelated failures.
- If required browser tooling is unavailable, report the check as blocked unless the user explicitly accepts a manual exception.
Related skills
- Use
tddto build new behavior test-first. Use this skill afterward, or on someone else's change, to prove specificAC-n/INV-nIDs against what already exists. - Use
designto produce the acceptance criteria and invariants this skill proves. - Use
reviewfor an independent read of the implementation itself; this skill only proves the stated criteria.