Collect and act on review results from an external AI agent. Reads the result file written by an external reviewer and presents findings, then offers to fix issues. Use when the user wants to collect an outside review — e.g. "review in", "collect review", "check review results", "cf-review-in", "read external review", "import review".
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
cf-review-in
description
Collect and act on review results from an external AI agent. Reads the result file written by an external reviewer and presents findings, then offers to fix issues. Use when the user wants to collect an outside review — e.g. "review in", "collect review", "check review results", "cf-review-in", "read external review", "import review".
user-invocable
true
argument-hint
<label> [service]
model
sonnet
created
2026-03-23T00:00:00.000Z
updated
2026-07-04T00:00:00.000Z
/cf-review-in
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 .
Reads the review results written by an external AI agent (generated via /cf-review-out) and presents them in the conversation. Then offers to fix any issues found.
Workflow
Step 0: Custom Guide
Custom guide — auto-loaded below (if the raw command shows instead of its output, run it yourself):
If output is not empty, integrate returned sections: ## Before → before first step, ## Rules → apply throughout, ## After → after final step.
Step 1: Determine the label and optional service
Parse $ARGUMENTS as <label> [service] — label is required, service is optional.
If $ARGUMENTS contains a label (and optionally a service), use them. Otherwise:
List available result files in <docsDir>/reviews/ that match *-result-*.md
Extract unique labels from the filenames. Two formats are supported:
New format: YYYY-MM-DD-<label>-result-<service>.md — the full YYYY-MM-DD-<label> stem is the label
Legacy format: <label>-result-<service>.md — the <label> stem is the label
If exactly one label exists, use it
If multiple labels exist, ask the user which one to collect
If none exist, tell the user no results are available and suggest running /cf-review-out first
Step 2: Find and read all result files for the label
Check the docsDir from .coding-friend/config.json (default: docs).
If a service was specified in step 1: try <docsDir>/reviews/<label>-result-<service>.md (works for both formats since <label> may already include the date prefix).
If the file does not exist → tell the user: "No results found for service <service>. Available:" then list existing services from <label>-result-*.md files → STOP.
If no service was specified: glob for all files matching <docsDir>/reviews/<label>-result-*.md (covers both YYYY-MM-DD-<label>-result-*.md and <label>-result-*.md since the full label is used as given).
If no files found → tell the user: "No results found for label <label>. Make sure external agents have written their reviews to <docsDir>/reviews/<label>-result-<service>.md." → STOP.
If one or more files found → read all of them. Extract the service name from each filename (the part after result- and before .md).
If any file is empty or malformed → warn the user about that specific file but continue processing the rest.
Step 3: Validate and parse each result file
For each result file found, check for:
Frontmatter with matching label
Sections: Critical Issues, Important Issues, Suggestions, Summary
If format doesn't match exactly, normalize it — extract issues and categorize by severity
Track which service/reviewer each finding came from
Step 4: Read context (for verification)
Read the prompt file to understand what was reviewed. Try <docsDir>/reviews/<label>-prompt.md first (works for both formats since <label> includes any date prefix). If not found, also try stripping any leading date prefix from <label> and retry. Use the diff from the prompt to understand the code context.
Step 5: Critical verification — do NOT blindly trust external findings
External reviewers (AI or human) can produce false positives, miss context, or misunderstand intent. For every Critical and Important issue reported:
a. Read the actual source code at the referenced file and line number. If the file or line doesn't exist (code may have changed since the review), mark the finding as Stale.
b. Verify the claim against reality:
Does the issue actually exist in the current code?
Did the reviewer miss surrounding context that addresses the concern? (e.g., validation done elsewhere, error handled upstream, intentional design choice)
Is the reviewer applying a generic best practice that doesn't apply to this specific codebase or situation?
Is the reviewer suggesting something that would contradict project conventions (check CLAUDE.md, docs/memory/conventions/)?
c. Classify each finding:
Confirmed — verified the issue exists and is valid
Questionable — the concern has some merit but may not apply here; needs user judgment
Dismissed — false positive, stale reference, or contradicts project context
Stale — referenced code has changed since the review
d. For Suggestions, do a lighter check: skim the referenced code and flag only obviously wrong suggestions. Do not deep-verify every suggestion.
e. Never auto-fix dismissed findings. Only offer to fix Confirmed and Questionable (with user approval) findings.
Step 6: Present the verified results
Display the review with verification verdicts. If multiple reviewers submitted results, present each reviewer's findings under a separate heading. If only one reviewer, use the simpler single-reviewer format.
Multiple reviewers format:
## 🔍 External Review: <label>
> Verified by Coding Friend against current codebase.
> Reviewers: **<service-1>**, **<service-2>**, ...
---
### 📝 <service-1>
#### 🚨 Critical Issues
- **[L<n>]** ✅ Confirmed — <issue> at <file>:<line>
_Verification: <brief explanation of why this is valid>_
- **[L<n>]** ❌ Dismissed — <issue> at <file>:<line>
_Reason: <why this is a false positive or doesn't apply>_
#### ⚠️ Important Issues
- **[L<n>]** ✅ Confirmed — <issue> at <file>:<line>
- **[L<n>]** ❓ Questionable — <issue> at <file>:<line>
_Note: <why this needs user judgment>_
#### 💡 Suggestions
- **[L<n>]** <suggestion>
#### 📋 Reviewer's Summary
<assessment from this reviewer>
---
### 📝 <service-2>
(same structure)
---
### 📊 Combined Verification Summary
- Confirmed: N | Questionable: N | Dismissed: N | Stale: N
- Cross-reviewer agreement: note any issues flagged by multiple reviewers (higher confidence)
Single reviewer format (same as before):
## 🔍 External Review: <label>
> Review by **<reviewer>** (from result frontmatter, or "external agent" if not specified)
> Verified by Coding Friend against current codebase.
### 🚨 Critical Issues
- **[L<n>]** ✅ Confirmed — <issue> at <file>:<line>
_Verification: <brief explanation of why this is valid>_
- **[L<n>]** ❌ Dismissed — <issue> at <file>:<line>
_Reason: <why this is a false positive or doesn't apply>_
### ⚠️ Important Issues
- **[L<n>]** ✅ Confirmed — <issue> at <file>:<line>
- **[L<n>]** ❓ Questionable — <issue> at <file>:<line>
_Note: <why this needs user judgment>_
### 💡 Suggestions
- **[L<n>]** <suggestion>
_(flagged only if obviously wrong)_
### 📊 Verification Summary
- Confirmed: N | Questionable: N | Dismissed: N | Stale: N
### 📋 Reviewer's Summary
<assessment from external agent>
Add a note: "This review was performed by external agent(s). All Critical and Important findings have been independently verified against the current codebase. Dismissed findings are shown for transparency but will not be acted on."
Step 7: Smart capture (conditional — only if memory_store MCP tool is available)
If any reviewer found architectural insights or recurring patterns worth preserving (from Confirmed findings only), call memory_store with type: "fact", importance: 3, source: "auto-capture". Issues flagged by multiple reviewers are especially worth capturing.
Skip if the review was routine with no notable findings.
Step 8: Completion banner and next steps
Count only Confirmed and Questionable findings across all reviewers (ignore Dismissed and Stale).
Label: · Reviewer(s): , , ...
[N] verified issue(s) need attention (M dismissed as false positives).
Shall I fix the confirmed issues now? (Questionable items will be presented for your decision.)
If the user agrees, load the cf-tdd skill and fix each Confirmed issue. Pass --add-tests to enable TDD for fixes when appropriate. For Questionable items, present each one and ask the user before acting.
Step 9: Update prompt status
After collecting, update the frontmatter in the prompt file found in Step 4 (whichever path resolved successfully): change status: pending to status: collected.
