/review

Rule

The <execute name="main">ARGUMENTS</execute> is entry point for this command.

Skills Rubric

To select skills for reviewing changes, consider the following rubric:

Skill	When to use
coding:testing	Core skill - always required for assessing test quality.
coding:principles	Core skill - always required for checking style and principle consistency.
coding:refactoring	Changes contain code smells or structural issues worth refactoring.
coding:design-patterns	Changes involve patterns that may be misused or missing.
coding:architecture	Changes cross architectural layers, affect dependency direction, or deviate from the recorded structure.
coding:schema	Changes involve database schemas, API contracts, or data serialization.
coding:security	Changes handle user input, auth, secrets, or cross trust boundaries.

The language-specific skills not listed, check all available skills before deciding skills to use.

Definition

Collect the review scope. In deep mode, collects all files under the target instead of just recent diffs.

<condition if="$deep">
    <step>1. use Glob to collect all source and test files under $target (or project root if empty)</step>
    <step>2. categorize files into: source, test, config, docs</step>
    <step>3. use `git log --oneline -10` on the scope to understand recent evolution</step>
    <return>categorized list of all files in scope with recent evolution context</return>
</condition>

<condition if="not $deep">
    <step>1. determine the diff source based on the target argument:</step>
    <condition if="$target == '--staged'">
        <step>2a. use `git diff --staged` to collect staged changes</step>
    </condition>
    <condition if="$target is a path or module">
        <step>2b. use `git diff HEAD -- $target` and `git log --oneline -5 -- $target` to collect recent changes for the path</step>
    </condition>
    <condition if="$target is empty">
        <step>2c. use `git show HEAD` to collect the latest commit changes</step>
    </condition>
    <step>3. list all changed files from the diff output</step>
    <step>4. categorize files into: source, test, config, docs</step>
    <step>5. use `git log --oneline -5` on the changed files to understand recent context</step>
    <return>categorized list of changed files with diff content and recent context</return>
</condition>

According to the changes, determine which skills are needed and activate them. 1. discover available skills from system-reminder 2. analyze the changes with rubric of available skills 3. always include `coding:testing` and `coding:principles` as core skills 4. select additional skills based on change categories and content 5. use Skill($skill) to activate and load its knowledge list of activated skills with their knowledge loaded Compare changes against existing codebase conventions for style consistency. 1. scan unchanged neighboring code to establish existing conventions (naming, structure, error handling, module organization) 2. compare changed code against established conventions 3. check naming consistency (variables, functions, classes, files) 4. check structural consistency (module organization, file placement) 5. check error handling consistency (exception types, error messages, recovery patterns) 6. check import/dependency organization consistency 7. flag deviations with severity (high: breaks convention, medium: inconsistent, low: minor style difference) list of style consistency findings with severity and location Assess test quality for the changed code including coverage, test smells, and boundary testing. 1. identify which changed source files have corresponding test files 2. check for missing integration test coverage on new or changed behaviors 3. detect test smells: over-mocking, testing implementation details, fragile assertions, test duplication, and assertions that pin only return values for functions with observable side effects (such a test cannot detect semantic-contract drift — e.g. sync-to-deferred execution or a shift in what the return value means — because the return type stays identical while the meaning changes) 4. check boundary testing: edge cases, error paths, nil/null handling 5. check for dead code testing (tests for removed or unreachable code) 6. verify tests follow AAA pattern and have clear assertions 7. flag issues with severity (high: missing coverage, medium: test smell, low: minor improvement) list of test quality findings with severity and location Verify architectural alignment including layer boundaries, dependency direction, and circular dependencies. 1. identify the architectural layer of each changed file (Entity, Use Case, Interface Adapter, Framework) 2. check dependency direction: dependencies must point inward (outer layers depend on inner layers) 3. detect potential circular dependencies introduced by the changes 4. verify new classes/modules are placed in the correct architectural layer 5. check for layer violations (e.g., Entity importing from Framework, Use Case depending on concrete adapter) 6. flag issues with severity (high: layer violation, medium: questionable placement, low: minor concern) list of architecture findings with severity and location Check whether the changes align with patterns recorded in this project. Flags drift from recorded shapes and surfaces revisit triggers that may have fired. 1. read `docs/architecture.md` Patterns section and any files under `docs/decisions/` 2. return an empty finding list — nothing to align against yet 3. for each recorded pattern whose "When to apply" overlaps the changed surface, compare the actual implementation against the pattern's recorded Shape and canonical example 4. flag drift with severity (high: implementation contradicts the pattern's Shape; medium: deviation in form but invariants intact; low: stylistic divergence from the canonical example) 5. for each recorded pattern, check whether any "Revisit if" trigger appears to have fired (e.g. team fragmentation grew, blast radius increased, change rate accelerated) — flag as informational so the team can re-run design-forces deliberately, not as a review failure list of pattern-alignment findings with severity, location, and trigger-fired notes Merge all findings, deduplicate, sort by severity, and produce refactoring suggestions for /refactor consumption. 1. merge all findings into a single list 2. deduplicate findings that overlap across checks 3. sort by severity: high → medium → low 4. for each finding, generate a refactoring suggestion with: - the specific issue and location - the recommended refactoring technique name (e.g., Extract Method, Rename, Move Class) - the corresponding skill to apply (e.g., `coding:refactoring`, `coding:principles`) 5. group suggestions by category (style, testing, architecture) 6. produce a summary with counts per severity and category formatted review report with refactoring suggestions ready for /refactor 1. 2. report no recent changes found and suggest: "No recent changes to review. Run `/review [path] --deep` to perform a holistic review of the codebase or module." suggestion to use --deep 3. 4. scan unchanged neighboring code to establish codebase conventions 5. 6. 7. 8. 9. 10. suggest running `/refactor` with the identified targets to address the findings 11. recent changes look clean — suggest: "No issues found in recent changes. Consider running `/review [path] --deep` for a broader holistic review." review report with refactoring suggestions

Task

$ARGUMENTS