Review 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 review-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
Review a code change for concrete correctness, security, data-integrity, compatibility, concurrency, and operability regressions by reconstructing intent and checking affected invariants and boundary paths. Use for local diffs, commits, branches, patches, or pull requests when the user wants actionable review findings. Report only defects introduced or exposed by the change with precise evidence; do not modify code unless asked to address findings.
SKILL.md
2.8 KB, as published. Nobody here has run it
Change Review
Review the behavioral delta, not the typography of the diff.
Protocol
- Determine the review range and read applicable
AGENTS.md. Inspect status so uncommitted user work is not mistaken for the target change. - Reconstruct intent from the request, commits, tests, and changed call sites. State ambiguity when intent affects whether behavior is defective.
- Inventory changed surfaces: API/schema, state, authorization, side effects, concurrency, errors/retries, configuration, observability, and release.
- For each surface, state the invariant before and after the change. Trace the changed value/control flow beyond edited lines into callers and consumers.
- Inspect the risky counter-paths: absent/empty/malformed input, denied access, duplicate/retry, partial failure, timeout/cancellation, stale state, concurrent execution, upgrade/downgrade, and rollback. Use only relevant paths.
- Read tests as executable claims. Check whether assertions would fail for the suspected regression; test presence alone is not coverage.
- Validate each finding against the actual diff and surrounding code. A finding must identify a reachable trigger, violated invariant, user impact, and a bounded location introduced or exposed by the change.
- Rank by impact and likelihood using
references/finding-rubric.md. Omit speculative concerns, pre-existing unrelated issues, and style preferences.
Finding bar
Emit a finding only when all are true:
- The reviewed change introduces or exposes it.
- A realistic execution path reaches it.
- The consequence is incorrect behavior, vulnerability, data loss, meaningful degradation, or an operational failure.
- The developer can act on it locally.
- The evidence is specific enough to falsify.
If a concern is plausible but unproven, perform another read-only check. If it remains uncertain, describe it as an open question outside the findings and state what evidence is missing.
Output
Lead with findings ordered by priority. For each, use one concise paragraph:
[P#] imperative title, reachable scenario, consequence, and why current code
does not prevent it. Cite the smallest useful changed-line range.
Then give a short review summary and testing gaps. If no findings meet the bar, say so explicitly and name residual risks or unverified surfaces.