# Review Changes > Diff/PR/commit-range impact review beyond changed lines. - Skill: `applicate2628/review-changes` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add applicate2628/review-changes` - Raw SKILL.md: https://api.skillmd.com/api/skills/applicate2628/review-changes/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: applicate2628 (https://skillmd.com/u/applicate2628) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/applicate2628/review-changes --- # Review Changes Run a repository-wide impact review triggered by recent changes. The changed files are only the starting point; the review target is the full affected behavior surface, including unchanged dependents, nearby contracts, tests, and likely regression paths. ## Core stance - Stay read-only. - Use the `review` template semantics from the installed `AGENTS.md` (Template routing section): select the objective-named reviewer and admit only evidence-triggered helpers. - Review the repo in light of the changes, not just the diff lines themselves. - Findings come first, ordered by severity. - Do NOT commit or modify files. ## Scope decision 1. Check `$ARGUMENTS`. - If a PR URL, PR number, branch, commit range, or diff target is given, use that scope. - Otherwise inspect current unstaged and staged changes with `git diff` and `git diff --cached`. - If no changes are present, stop and tell the user there is nothing to review. 2. If the user mentions a bug, review thread, accepted plan, or expected fix list, use that as the completion baseline. 3. If no explicit baseline exists, review against the observed change impact and say that fix-completeness against an external checklist could not be verified. ## Review workflow 1. First identify the reviewer required by the review objective; this selection is the route's anchor, not the last stage of a fixed Analyst/QA/Architecture chain. - A test, regression, or fix-completeness objective normally selects `$qa-engineer`. - An architecture or maintainability objective selects `$architecture-reviewer`. - A security, performance, user-experience, accessibility, or user-interface test objective selects the matching specialist reviewer. 2. Admit helpers only for evidence the selected reviewer actually needs. - Add a factual or research helper only when required evidence is missing; use `$analyst` to inspect changed code plus callers, dependents, tests, configuration, schemas, and adjacent modules when that factual inventory is needed. - Add a Quality Assurance (QA) helper only when the objective needs test, regression, or fix-completeness evidence that is not already the objective reviewer's lane. - Add an Architecture Reviewer only when the objective is architectural or verified architecture or maintainability risk requires that gate. - Add `$security-reviewer` if the change touches auth, trust boundaries, secrets, dangerous configuration, input validation, or vulnerability surfaces. - Add `$performance-reviewer` if the change touches hot paths, query plans, rendering loops, budgets, throughput, or latency-sensitive behavior. - Add `$ux-reviewer`, `$accessibility-reviewer`, or `$ui-test-engineer` when the affected surface is clearly user-facing and the risk is interaction quality rather than pure logic. - If external review is preferred for an eligible QA or review-side slot, `$external-reviewer` may stand in for the matching role. 3. Execute every admitted lane in research -> QA -> review order and omit every lane without an evidence trigger. Keep the chain sequential in Codex unless the user explicitly approves a delegated team and the scopes are clearly independent. 4. Apply these routing scenarios as pressure tests: - Narrow QA-only objective: select `$qa-engineer`; do not add Analyst or Architecture review without a separate evidence trigger. - Architecture objective: the Architecture Reviewer is the objective reviewer; do not add Analyst or QA unless required evidence is missing. - Research needed: when the selected reviewer cannot decide without a caller, dependency, or contract inventory, admit an Analyst to collect those facts before the downstream QA or review verdict. 5. When the existing multi-fix anti-layering trigger applies, its Architecture Reviewer lane and distinct-engine audit remain mandatory; a `PILED` verdict maps to `REVISE` and blocks push. Workflow economy does not waive this trigger. ## What to verify - The requested fixes are actually present. - The apparent root cause is covered, not just one symptom. - Unchanged callers, consumers, configs, tests, or docs are still compatible with the new behavior. - Nearby logic still makes sense after the change. - Hidden regressions, stale assumptions, and missed edge cases are surfaced. - Validation is strong enough for the touched behavior, or the exact gap is called out. - The change did not leave partial rewires, stale branches, dead conditions, or forgotten follow-up adjustments in unchanged files. ## Output Return one unified review with: - scope reviewed - findings ordered by severity - impacted unchanged surfaces that were checked - what could not be verified - verdict: `PASS`, `REVISE`, or `BLOCKED` If the user asked "did we fix everything?", answer that directly before the detailed findings. ## Persistence - If the current task has `work-items/active//`, persist only the accepted review artifact there and return its concise result/provenance for the root ledger. - With no active work-item, a meaningful standalone review MAY use one `.reports/YYYY-MM/` summary using the standard report naming convention. ## Rules - Do not role-play specialist reviewers inline when delegation is available and permitted. - Treat changed files as entry points, not as the review boundary. - If a critical issue appears early, surface it immediately. - If the impact surface is too large for a trustworthy single pass, say so and recommend splitting the review into smaller scopes. - Delegate authorized GitHub review-thread resolution to `$github-pr-review-bot`; this observational review skill does not resolve threads itself. - The review entry point remains read-only; the delegated GitHub action is allowed only with explicit user authorization or existing standing authorization for that pull request. - The bot owner must refresh the pull request's hosted `headRefOid`, verify the fix on that hosted head, re-read the exact thread, and resolve only that exact authorized thread. Local ancestry, a local diff, a user-interface badge, a notification, or stale prior bot evidence is insufficient. - Thread resolution does not establish a clean bot result or `PASS`; it does not trigger a new review, start Continuous Integration (CI), or grant merge or publication authority. Those remain separate bot-state and human gates.