Verify change
A collection of Agent Skills — self-contained folders that teach AI agents to perform specialized tasks. Includes a production-readiness harness-audit skill, a plugin marketplace, a SKILL.md spec, and CI validation.
npx -y skills add contextosai/skills --skill verify-changeAssembled 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
Design and execute a risk-based verification strategy for a software change, bug fix, refactor, migration, configuration update, or release candidate. Use when Codex needs to prove that a change works, choose proportional tests, investigate whether validation is sufficient, or report what remains unverified. Trace claims to evidence across static checks, focused tests, integration boundaries, and runtime behavior instead of merely running the entire test suite.
SKILL.md
3.2 KB, as published. Nobody here has run it
Change Verification
Produce the smallest evidence set that convincingly supports the change's claims and protects its highest-risk invariants.
Protocol
- Identify the exact change range and read applicable repository instructions. Preserve unrelated user changes.
- Write a claim ledger: each intended behavior, preserved invariant, affected
boundary, likely failure mode, and the evidence that could falsify it. Use
references/verification-matrix.md. - Classify risk by consequence, reachability, novelty, and reversibility. Raise rigor for authorization, money, destructive writes, migrations, concurrency, public APIs, and silent corruption.
- Inspect existing test/build commands and CI configuration. Do not guess a command when the repository declares one.
- Order checks for fast information:
- syntax/type/static validation;
- focused tests for changed logic and regression input;
- integration tests across affected boundaries;
- broader suite/build/package checks;
- runtime smoke, migration, compatibility, performance, or security checks only when the risk model calls for them.
- Before each expensive check, state which claim it tests. Do not run broad suites merely to create confidence theater.
- Interpret results, not exit codes alone. Confirm tests were discovered, assertions exercised the changed path, expected failures did not get swallowed, snapshots/artifacts are meaningful, and warnings are relevant.
- For a bug fix, demonstrate the regression test targets the original failure. Prefer fail-before/pass-after evidence when safely obtainable without discarding work; otherwise explain the causal link.
- For migrations or irreversible operations, verify on disposable data and inspect forward, backward/rollback, partial-failure, and repeated-run paths.
- Stop when every material claim has evidence or an explicit gap. Never claim "fully verified" from a partial environment.
Guardrails
- Do not mutate production, publish, deploy, or exercise real side effects without explicit authority.
- Do not weaken assertions, delete failing tests, or regenerate snapshots solely to obtain green output.
- Distinguish product failures, test defects, environmental failures, and checks that never ran.
- Treat flaky success as inconclusive until the nondeterminism is bounded.
- Report skipped, inaccessible, or environment-dependent checks as gaps with their risk—not as passes.
Output
Lead with the verification verdict: supported, partially supported, or not supported. Summarize evidence by claim, then failures and residual risk. Include exact commands and concise results so another engineer can reproduce the proof.