27 added, 56 removed. Audit A to A.
---
name: cf-review
description: >
Dispatch code review to a subagent. Triggers: "review this", "review my changes", "check
the code", "code review", "any issues with this?", "review before merge", "review the
diff". Also for reviewing specific files, commits, or branches.
created: 2026-02-17
updated: 2026-08-27
---
# /cf-review
> **CLI Requirement:** OPTIONAL — Uses the memory MCP from `coding-friend-cli` for fast indexed search and storage. Without the CLI: falls back to grep over `docs/memory/` and direct file writes. Full functionality preserved, slower memory recall. See [CLI requirements](../../../docs/cli-requirements.md).
> ✨ **CODING FRIEND** → /cf-review activated
Review the code changes for: **$ARGUMENTS**
## Auto-Triggered
- This skill is automatically invoked by other skills — you don't always need to run it manually:
-
- - **`/cf-plan`** — runs `/cf-review` after all implementation tasks complete
- - **`/cf-fix`** — runs `/cf-review` after the fix is verified
- - **`/cf-optimize`** — runs `/cf-review` after the optimization is measured and verified
+ Invoked by `/cf-plan` (after all tasks), `/cf-fix` (after verified fix), and `/cf-optimize` (after measured + verified).
## Workflow
### Step 0: Custom Guide
- Custom guide — auto-loaded below (if the raw command shows instead of its output, run it yourself):
-
```!
bash "<plugin-root>/lib/load-custom-guide.sh" cf-review
```
- If output is not empty, integrate returned sections: `## Before` → before first step, `## Rules` → apply throughout, `## After` → after final step.
+ If output is not empty: `## Before` → before first step, `## Rules` → throughout, `## After` → after final step.
### Step 1: Identify the target
- - If `$ARGUMENTS` is empty, review all uncommitted changes (`git diff` + `git diff --staged`)
- - If `$ARGUMENTS` is a file path, review that file
- - If `$ARGUMENTS` is a commit range (e.g., `HEAD~3..HEAD`), review those commits
- - If `$ARGUMENTS` is a natural language description (e.g., "the auth logic changes"), review all uncommitted changes but **focus the review** on the described area — filter findings to only report issues relevant to that description
- - If `$ARGUMENTS` contains `--deep` or `--quick`, use that mode (override auto-detection)
+ - Empty `$ARGUMENTS` → all uncommitted changes (`git diff` + `git diff --staged`)
+ - File path → that file
+ - Commit range (e.g. `HEAD~3..HEAD`) → those commits
+ - Natural-language description (e.g. "the auth logic changes") → default uncommitted set, **focus** findings on that area
+ - `--deep` / `--quick` → force that mode (override auto-detection)
**Antigravity host behavior:**
- This skill already runs inside Google Antigravity. Ignore `--with-codex`, its `--codex` alias, and `review.withCodex`; do not launch a nested `codex review` subprocess.
- Run the Coding Friend multi-agent review below.
### Step 2: Gather the diff
```bash
bash "<plugin-root>/skills/cf-review/scripts/gather-diff.sh"
```
### Step 3: Assess change size
- Determine review depth. Run the bundled script (one permission prompt instead of many):
-
```bash
bash "<plugin-root>/skills/cf-review/scripts/assess-changes.sh"
```
- The script prints `KEY=value` lines: `FILES_CHANGED`, `LINES_CHANGED`, `SENSITIVE`, `CHANGED_FILES`, and `MODE`.
- Use the `MODE` value directly — no further calculation needed.
+ Script prints `KEY=value`: `FILES_CHANGED`, `LINES_CHANGED`, `SENSITIVE`, `CHANGED_FILES`, `MODE`. Use `MODE` as-is.
- | Mode | Condition | Behavior |
- | ------------ | -------------------------------------------------- | ----------------------------------------------------------------------- |
- | **QUICK** | ≤3 files AND ≤50 lines AND no sensitive paths | Layer 3: secrets + obvious injection only. Skip context research. |
- | **STANDARD** | 4–10 files OR 51–300 lines | Full 5-layer review. All security phases, concise. |
- | **DEEP** | >10 files OR >300 lines OR sensitive paths touched | Full 5-layer + extended security. Data flow tracing. Exploit scenarios. |
+ | Mode | Condition | Behavior |
+ | ------------ | -------------------------------------------------- | ----------------------------------------------------------------- |
+ | **QUICK** | ≤3 files AND ≤50 lines AND no sensitive paths | Layer 3: secrets + obvious injection. Skip context research. |
+ | **STANDARD** | 4–10 files OR 51–300 lines | Full 5-layer review. All security phases, concise. |
+ | **DEEP** | >10 files OR >300 lines OR sensitive paths touched | Full 5-layer + extended security. Data-flow tracing. Exploits. |
- If `SENSITIVE > 0`, always escalate to **DEEP** regardless of size.
+ `SENSITIVE > 0` → always **DEEP**.
### Step 4: Gather context (conditional — based on review mode)
- - **QUICK mode**: Skip this step entirely.
- - **STANDARD mode**: Search memory only (if `memory_search` tool is available). Call `memory_search` with: `{ "query": "<area being reviewed — e.g. auth, API, database>", "limit": 5 }`. Use results as context hints for the review.
- - **DEEP mode**: Launch the **cf-explorer agent** to understand callers, dependencies, and data flows around the changed files. Call `invoke_subagent` with agent `cf-explorer`. Pass:
-
- > Explore the codebase context around these changed files: [list changed files]
- >
- > Questions to answer:
- >
- > 1. What calls these files/functions? (callers, entry points)
- > 2. What do these files depend on? (downstream effects)
- > 3. What conventions and patterns exist in the surrounding code?
- > 4. Are there related tests that should be checked?
-
- **Note:** cf-explorer already checks memory internally — do NOT call `memory_search` separately when using cf-explorer.
+ - **QUICK mode**: Skip.
+ - **STANDARD mode**: If `memory_search` is available, call `{ "query": "<area — e.g. auth, API, database>", "limit": 5 }`. Hints only.
+ - **DEEP mode**: Launch **cf-explorer**. Call `invoke_subagent` with agent `cf-explorer`. Pass changed files; ask callers, deps, nearby conventions, related tests. cf-explorer searches memory itself — do NOT also call `memory_search`.
- Memory and explorer results are **hints** — always verify against actual code.
+ Memory and explorer results are **hints** — verify against code.
### Step 5: Read changed files
- Read changed files in full — do not review only the diff, understand the context.
+ Read each changed file in full — not just the diff.
### Step 6: Dispatch the cf-reviewer agent
- Call `invoke_subagent` with agent `cf-reviewer`. Pass the full context:
+ Call `invoke_subagent` with agent `cf-reviewer`. Pass:
> **Review mode:** [QUICK | STANDARD | DEEP]
>
> **Diff:**
> [full diff from Step 2]
>
> **Changed files (full content):**
- > [full content of each changed file from Step 5]
+ > [full content from Step 5]
>
> **Context (if gathered in Step 4):**
- > [memory search results or cf-explorer findings, if any]
+ > [memory or cf-explorer findings]
>
> Run the review now. Return the unified report in the 🚨/⚠️/💡/📋 format.
- Wait for the agent to return its report.
+ Wait for the report.
### Step 7: Collect the report
The result of Step 6 is the final formatted report (Critical / Important / Suggestions / Summary). Do not reformat or restructure it; use it as-is in Step 10.
### Step 8: Mark review complete and display status
```bash
bash "<plugin-root>/skills/cf-review/scripts/mark-reviewed.sh"
```
### Step 9: Smart capture (conditional — only if `memory_store` MCP tool is available)
- If the review found **architectural insights** or **recurring patterns** worth preserving, call `memory_store` with:
-
- - type: "fact"
- - importance: 3
- - source: "auto-capture"
- - title/description/tags/content summarizing the insight
-
- Skip if the review was routine with no notable findings.
+ If the review found **architectural insights** or **recurring patterns**, call `memory_store` with type `"fact"`, importance `3`, source `"auto-capture"`, plus title/description/tags/content. Skip routine reviews.
### Step 10: Final output
- Display the full report followed by the status banner in a **single message**.
-
- **IMPORTANT**: The structured report from step 8 and the banner below MUST appear together in the same final response. Do NOT split them across separate messages. This ensures the complete review is visible in the last message.
+ Display the full report and the status banner in one message. Do NOT split them.
- Display the cf-reviewer's report first, then append the appropriate banner. When any external source contributed, add a `· Reviewed by: <in-session> + …` suffix listing the in-session reviewer plus each external agent/codex that actually contributed (e.g. `· Reviewed by: Claude + Codex + Gemini`). Label the in-session reviewer by the `HOST` value from the session bootstrap context, capitalized (`claude` → `Claude`, `codex` → `Codex`); if no `HOST:` line is present, use the neutral label `In-session AI` — do NOT hardcode `Claude`, since the assistant running this skill may be another host (Grok, Cursor, …). Omit the suffix when only the in-session reviewer ran.
+ Display the cf-reviewer's report first, then append the appropriate banner.
- Skip this step's banner when `out=true` — Step 6.7 already showed the export panel.
+ Skip this banner when `out=true` — Step 6.7 already showed the export panel.
**If NO critical issues were found:**
```
╔══════════════════════════════════════════════════╗
║ ✅ Code Review Complete ║
╚══════════════════════════════════════════════════╝
```
> Mode: **[QUICK|STANDARD|DEEP]** · No blocking issues found.
>
> You're clear to commit. Run `/cf-commit` when ready.
**If critical issues were found** — show the banner, then wait for the user's answer:
```
╔══════════════════════════════════════════════════╗
║ ⚠️ Review Complete — Action Needed ║
╚══════════════════════════════════════════════════╝
```
> Mode: **[QUICK|STANDARD|DEEP]** · **[N] critical issue(s)** must be resolved before committing.
>
> Resolve the critical issues listed above. Shall I help fix them now?