# Code Review Invocation

Use the `code-review` skill whenever the task involves reviewing code rather than implementing changes.

## When to invoke it

Invoke the `code-review` skill for any of the following:

- the user asks to review a diff, pull request, commit, staged changes, or a file set
- the user asks for a bug hunt, security audit, architecture review, scalability review, concurrency review, or maintainability review
- the user asks whether code is safe to merge
- the user asks for test-gap analysis or release-risk assessment
- the task involves validating code quality before merge, release, or handoff

## Default review behavior

When the `code-review` skill is invoked:

- treat the task as review and analysis, not implementation
- do not modify application code unless the user explicitly asks for fixes after the review
- inspect for security, correctness, edge cases, maintainability, design-pattern fit, lint/type risks, test gaps, I/O behavior, memory/resource usage, concurrency issues, scalability concerns, and architecture risk
- focus first on high-severity and high-confidence findings
- prefer concrete evidence over generic advice
- if the change is a diff or PR, prioritize introduced risk first, then surrounding code only when it materially affects the change

## Required artifact

A review is not complete until findings are written to `ISSUES.md`.

Rules for `ISSUES.md`:

- create `ISSUES.md` if it does not exist
- update it if it already exists
- preserve useful existing content where possible
- remove or rewrite stale, duplicate, or conflicting entries
- keep findings concrete, actionable, and evidence-based
- avoid duplicating multiple symptoms of the same root cause

`ISSUES.md` must contain:

1. review scope
2. overall assessment
3. priority summary with all findings sorted by severity
4. findings grouped by type
5. missing or weak tests
6. positive notes
7. unverified areas

Sorting rules:

- overall priority order: Critical, High, Medium, Low
- within each type section, sort findings by the same severity order
- if two findings have the same severity, put the more user-impacting or merge-blocking issue first

## Required response shape

For review tasks, the final response should include:

- Scope reviewed
- Overall assessment: `safe to merge`, `merge with fixes`, or `needs significant changes`
- Top risks
- Findings with severity, location, type, impact, evidence, failure mode, recommendation, and confidence
- Missing or weak tests
- Positive notes
- Unverified areas
- confirmation that `ISSUES.md` was created or updated

## What not to do during review

Do not:

- silently fix code during a review-only request
- pad the review with style-only commentary
- suggest large refactors without a concrete risk-based reason
- claim certainty when evidence is incomplete
- skip `ISSUES.md`

## If the user asks for fixes after review

If the user explicitly asks for remediation after the review:

- use the review findings as the worklist
- preserve the highest-priority fixes first
- update `ISSUES.md` to reflect resolved, remaining, and newly discovered issues
- clearly separate reviewed findings from implemented fixes