Review Code

Setup

On first use, read `setup.md` for integration guidance and local memory initialization.

When to Use

User asks for a code review, PR review, merge-readiness check, or bug-risk audit before shipping. Agent delivers a risk-ranked review with explicit evidence, impact, confidence, and concrete fix direction.

Architecture

Memory lives in `~/review-code/`. See `memory-template.md` for structure and starter templates.

```text ~/review-code/ ├── memory.md # Review preferences, stack context, and recent constraints ├── findings/ # Optional per-review finding logs ├── baselines/ # Team conventions and accepted risk baselines └── sessions/ # Session summaries for ongoing audits ```

Quick Reference

| Topic | File | |-------|------| | Setup and integration behavior | `setup.md` | | Memory schema and templates | `memory-template.md` | | End-to-end review execution flow | `review-workflow.md` | | Severity and confidence calibration | `severity-and-confidence.md` | | Language and architecture risk checks | `language-risk-checklists.md` | | Test impact requirements by change type | `test-impact-playbook.md` | | Comment and report templates | `comment-templates.md` | | Patch strategy for actionable fixes | `patch-strategy.md` |

Data Storage

Local notes stay in `~/review-code/`. Before creating or changing local files, present the planned write and ask for user confirmation.

Core Rules

1. Define the Review Contract First Confirm target scope before reviewing: branch, files, risk tolerance, and release context. If scope is unclear, state assumptions explicitly and keep findings tied to those assumptions.

2. Start With Risk Mapping, Then Deep Dive Run a fast pass to locate high-risk zones first: auth, money, data integrity, concurrency, and migration paths. Only then perform line-level analysis with `review-workflow.md` so major failures are surfaced early.

3. Every Finding Must Be Evidence-Backed Do not report vague concerns. Each finding must include: trigger location, concrete failure mode, user or business impact, and minimal reproduction clue. If evidence is weak, mark low confidence or downgrade to a question.

4. Separate Blocking vs Advisory With Severity + Confidence Use `severity-and-confidence.md` for consistent triage. Blocking findings must be reproducible or highly probable with strong impact. Advisory feedback must remain concise and never hide blockers.

5. Always Pair Findings With a Fix Path For each blocking issue, provide a minimally disruptive fix strategy. Use `patch-strategy.md` to propose rollback-safe edits, guard tests, and verification steps.

6. Tie Review Quality to Test Impact Map each change to required tests using `test-impact-playbook.md`. If tests are missing, list the exact scenarios that must be added and why they prevent regressions.

7. Optimize for Signal, Not Volume Prioritize high-impact defects over style noise. If no blockers are found, state that explicitly and list residual risks, test gaps, and monitoring advice.

Common Traps

• Reporting opinions as facts -> review credibility drops and teams ignore real blockers.
• Mixing blocker and nit feedback without labels -> delayed merges and mis-prioritized fixes.
• Calling something “probably fine” without tests -> silent regressions in production.
• Suggesting large rewrites for local defects -> good fixes are postponed indefinitely.
• Ignoring release context (hotfix vs refactor) -> wrong trade-offs for urgency.
• Missing migration and backward-compatibility checks -> runtime failures after deploy.

External Endpoints

This skill makes NO external network requests.

| Endpoint | Data Sent | Purpose | |----------|-----------|---------| | None | None | N/A |

No other data is sent externally.

Security & Privacy

• Data that leaves your machine:
• Nothing by default. This is an instruction-only review skill unless the user explicitly exports artifacts.

• Data stored locally:
• Review preferences, project constraints, and optional findings approved by the user.
• Stored in `~/review-code/`.

• This skill does NOT:
• auto-approve code or merge pull requests.
• make undeclared network calls.
• store credentials, tokens, or sensitive payloads.
• modify its own core instructions or auxiliary files.

Trust

This is an instruction-only code review skill. No credentials are required and no third-party services are contacted by default.

Related Skills Install with `clawhub install <slug>` if user confirms: - `code` - implementation workflow that complements review findings. - `git` - safer branch, diff, and commit handling during remediation. - `typescript` - stricter typing and runtime safety review for TS-heavy codebases. - `ci-cd` - release-gate checks and deployment safeguards after fixes. - `devops` - production risk assessment and rollback planning.

Feedback

• If useful: `clawhub star review-code`
• Stay updated: `clawhub sync`