Review change
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.From its SKILL.md
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.
SKILL.md
2.8 KB, 489 tokens by cl100k_base, 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.
What ships with it: 2 files
1.8 KB alongside SKILL.md
agents/
- openai.yaml215 B
references/
- finding-rubric.md1.6 KB
Gives 0 of the 12 instructions most review quality skills give in 489 tokens
Counted across 1,273 of the 2,403 authors here whose files we hold, read 2026-09-06
- Ask one question at a timein 63 of 1273, across 62 files
- Provide a recommended answer for each questionin 47 of 1273, across 45 files
- Rank findings by severityin 44 of 1273
- Use parameterized queries for database accessin 38 of 1273, across 20 files
- Validate all user input with schemasin 33 of 1273, across 15 files
- Store secrets in environment variablesin 32 of 1273, across 14 files
- Explore the codebase to answer questionsin 31 of 1273, across 29 files
- Store tokens in httpOnly cookiesin 30 of 1273, across 12 files
- Implement rate limiting on API endpointsin 30 of 1273, across 12 files
- Sanitize user-provided HTMLin 29 of 1273, across 11 files
- Return generic error messages to usersin 28 of 1273, across 10 files
- Cite file and line for every findingin 28 of 1273, across 25 files
Said here and by no other author read
- Review behavioral delta instead of typography
- Reconstruct intent from request and commits
- Inventory changed surfaces and state invariants
- Inspect risky counter-paths for regressions
- Read tests as executable claims
- Validate findings against diff and surrounding code
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.