Verification as context

Skill zoidbergclawd/coherence/skills/verification-as-context

Five portable Agent Skills for Claude Code that keep humans and coding agents aligned at high velocity.

Install

npx -y skills add zoidbergclawd/coherence --skill verification-as-context

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when implementing or changing behavior, adding tests, choosing test level, or deciding what proof must ride with a change, to treat tests, docs, and CI as executable context that preserves product intent across fast agentic changes.

SKILL.md

5.4 KB, as published. Nobody here has run it

Verification as Context

When to use this skill

Adding new behavior
Modifying existing behavior
Refactoring code that already has callers
Writing or updating tests
Choosing between unit, behavioral, and integration tests
Deciding whether a change is "done"
Reviewing a diff for completeness before commit or merge

This skill composes with multi-pass-planning (run during the Plan pass) and boundary-definition (the spec defines what behavioral tests must prove).

Core principle

Tests, docs, and CI are not overhead. They are the executable record of what the product is supposed to do. When code changes faster than humans can read, verification artifacts carry the intent forward. A change that ships without matching verification erases context for the next session — including the next session with the same agent.

Test taxonomy

Unit tests preserve small contracts. They protect a single function's input/output behavior.
Behavioral tests preserve product promises. They describe what the system does for a user, not how it does it.
Integration tests preserve system wiring. They protect that components actually connect, communicate, and degrade as expected.

Behavioral vs integration rule of thumb

If a test would still be valid after a major internal refactor because it only cares about outcomes, it is behavioral.
If a refactor would force the test to be rewritten because it asserts on internal collaboration, it is integration.

A test that mocks every collaborator and asserts on call order is integration in disguise — it will rot the moment the structure changes. A test that drives the public API and asserts on observable results is behavioral and survives refactors.

Procedure

Identify the change type: new behavior, behavior change, refactor, bug fix, helper, or wiring change.
Pick the verification level using the table below. Write down the chosen level before coding.
Write the verification first when possible:
- New behavior: write the behavioral test first; let it fail; then implement.
- Bug fix: write a failing test that reproduces the bug; then fix.
- Refactor: confirm an existing behavioral test already covers the contract; if not, add one before refactoring.
Update any docs that describe the changed behavior. Treat doc changes as part of the diff, not a follow-up.
Run the verification locally. The change is not done until type checks, lints, and the relevant tests pass.
If CI exists, ensure the new verification runs there. Local-only proof rots silently.

Verification level table

Change type	Minimum verification
New public behavior	Behavioral test plus doc update
Behavior change	Updated behavioral test plus doc update
Internal refactor	Existing behavioral test still passes, unchanged
Bug fix	Failing reproducer test, then passing after fix
Cross-module wiring	Integration test
Pure helper function	Unit test

Required output format

Before coding, a Verification plan block:

Verification plan
- Change type: <one of: new behavior | behavior change | refactor | bug fix | wiring | helper>
- Test level: <unit | behavioral | integration>
- Tests to add or update: <file::name, ...>
- Docs to update: <paths>
- Local commands: <e.g. pnpm test path/to/spec, pnpm typecheck>

After coding, a Verification result log:

Verification result
- <command>: pass/fail, key output
- <command>: pass/fail, key output
- CI status: <queued | passing | failing>

Stop conditions / escalation triggers

Change ships with no test at the chosen level
Tests assert on internal collaboration when the change is meant to be behavioral
Docs describe behavior that no longer matches the code
Local verification passes but CI does not run the new test
A bug fix has no test that would have caught the original bug
Behavioral test had to be rewritten after a refactor — it was integration in disguise; rewrite it to assert on outcomes

Short examples

Behavioral test (good):

When the user submits an empty form, the response status is 400 and the body contains an errors array with at least one entry whose field is email.

Integration test pretending to be behavioral (bad):

FormController.validate() is called with an empty body and returns the result of Validator.run().

The second test asserts that FormController calls Validator — a structural claim. Any refactor that inlines validation or moves it to middleware will break this test even though the product still behaves correctly. Rewrite to assert on the HTTP outcome.

Bug fix verification (good):

Test auth.refresh returns 401 when the refresh token is expired was added before the fix. It failed against main (returned 500). It passes on the fix branch. CI runs it under pnpm test:auth.