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.
~/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