Review Change

Review Change

Trigger

Use when the user asks for a code review, PR review, diff review, architecture review of changes, or risk assessment.

When To Use

• Before merge or release.
• After implementation.
• When a change touches shared behavior, security, data, or deployment.

Inputs Inspected

• Git diff, PR context, or changed files.
• Implementation plan and relevant lifecycle artifacts.
• Tests and existing conventions.

Workflow

1. Inspect the actual diff or changed files before making claims.
2. Compare behavior against the implementation plan, architecture decisions, and test strategy where available.
3. Review correctness, security, data/migration impact, API compatibility, operational risk, and maintainability.
4. Put findings first, ordered by severity, with concrete file references.
5. State tests actually run separately from recommended tests.
6. When the review surfaces a high-stakes, irreversible, or cross-cutting decision, recommend run-engineering-council before merge.
7. Write the review artifact and validate it with python "${CLAUDE_PLUGIN_ROOT}/scripts/validate-artifact.py" <review artifact>.

Edge Handling

• Empty input (no diff, PR, branch, or files named): ask the user for the diff, PR, or branch to review before proceeding (empty-argument) — do not invent a change to review.
• No changes to inspect (the diff/PR/branch resolves to nothing): report that there is nothing to review rather than fabricating findings (no-diff).

Outputs

• .project/.engineering/initiatives/<initiative-id>/review/change-review.md

Required Front Matter

• initiative_id
• skill
• created_at
• status
• confidence
• source_artifacts

Required Sections

• Findings
• Tests
• Residual Risk
• Open Questions

Safety Constraints

• Findings first, ordered by severity.
• Cite concrete files and evidence.
• Do not invent test results.
• Mark residual risk when checks cannot be run.

Related Agents

• solution-architect
• security-reviewer
• qa-test-strategist
• repo-hygiene-maintainer