Request Review
Three-phase process: Obtain review results → Verify review results → Fix confirmed issues.
Phase 1: Obtain Review Results
Obtain review results based on user input, with two sources:
Source 1: User directly pastes
The user provides the review text directly.
Source 2: Specify coding agent
If the user provides a coding agent name (e.g., Claude, Cursor, Kimi), send a review request to the agent via CLI.
The unified prompt is:
Use the thermo-nuclear-code-quality-review skill to review uncommitted changes (read-only)
CLI commands for each agent:
| Agent | Command |
|---|
| Claude | claude -p --dangerously-skip-permissions "prompt"
|
| Cursor | agent -p --yolo --trust "prompt"
|
| Kimi | |
If the agent does not support CLI invocation or the command execution fails, inform the user and request manual pasting of the review results.
Phase 2: Verify Review Results
Verify each item in the review results obtained in Phase 1:
- Parse the review text and identify each independent issue
- Locate the referenced files; if the path is incomplete or ambiguous, search in the repository
- Verify whether the issue is valid against the actual code; mark false positives or outdated line numbers
- Summarize the verification results: which issues are valid and which are false positives, and output a brief verification summary
Phase 3: Fix Confirmed Issues
Only fix issues confirmed as valid in Phase 2:
- Keep behavior unchanged unless fixing confirmed issues
- Do not guess if the issue description is ambiguous; request clarification from the user
- Keep the final summary concise (1-3 sentences or a short table)
Output Format
After all fixes are completed, output a structured report containing two sections:
Fixed
List each successfully resolved issue, each entry must include:
- Issue summary
- Changes made (one sentence)
- File path and line number
Unfixed
List each unfixed issue, each entry must include a valid reason, for example:
- False Positive: Verified against code, the issue does not exist or has been addressed (cite specific evidence)
- High Risk: Fix may introduce regression or break existing behavior (describe specific risks)
- Out of Scope: Requires architectural changes or cross-module coordination (describe the scope involved)
- Insufficient Information: Lacks context or permissions required for security fixes (specify what is missing)
- Design Conflict: The proposed fix contradicts intentional design decisions (cite specific decisions)
Vague reasons such as "Skipped" or "Not processed" are unacceptable. Each unfixed entry must include sufficient reasoning to enable the user to judge whether the decision is reasonable.