Review Change

Review a specified change along two axes: Standards, whether it follows the project's coding rules and supported design practices; and Spec, whether it implements the intended requirements. Trace behavior and run focused checks when they help judge those axes. Return findings and evidence to the user or consuming workflow. That workflow retains implementation and delivery ownership.

This method supports direct requests and calls from other skills. Its scope is the selected change and the behavior it affects. A review does not authorize product fixes, a whole-repository audit, remote comments, approval or merging. It does not start skill evolution.

For factual uncertainty that could change a finding, use Investigate with Evidence. Install that shared method alongside this skill. If it is unavailable, continue supported review and identify the dependent check that remains unresolved; do not install it at runtime. Review output alone does not create a working-record or tracker workflow.

Response language

A skill mention and a PR link carry no language request. Use the conversation language or the user's established language preference from the first update. Honor explicit language requests for the output they apply to. Use simple-english only for prose that will be in English and only when the skill is available. Preserve meaning, uncertainty, requirement strength, source quotations and requested formats.

1. Identify the change

After identifying the target repository, the coordinator reads its project AGENTS.md in the configured records store when available. Use relevant experience to select checks. For a first review or omission check, only the coordinator reads the records copy. Give reviewers neutral conditions and explicitly exclude that file from their inputs and delegated investigations. Withhold prior verdicts and proposed fixes. For a repair review, follow the existing finding handoff below. Judge risk and findings from the current patch.

Recover the requested target and comparison point from the user, active task and repository state. Resolve refs and inspect the worktree before selecting a diff. Ask only when a remaining ambiguity would change what gets reviewed.