dev
307d2fd471
Adds the project-review workflow for code review independent of the git diff. The scope is parsed from the user instruction: 全面/整个项目 -> whole-project (score every source file), otherwise feature + target keyword (locate the code with semantic search + graph queries). - scoring_tools.py: score_review_func gains all_files=True to score every source file in the graph via store.get_all_files() - main.py: score_review_tool gains all_files param; registers the project_review MCP prompt (prompts 6->7) - prompts.py: project_review_prompt(scope, target) with whole-project and feature branches (fixed a precedence bug that truncated the feature text) - skills.py + skills/project-review/: new read-only project-review skill with shared checklists - .opencode/command/code-review-graph-project-review.md: slash command - tests: test_project_review.py (prompt rendering), TestProjectReviewPrompt, skill count assertions 5->6, all_files wiring checks - docs: prompts (6->7) + project-review entries across COMMANDS, CLAUDE, README (+localized), INDEX, architecture, LLM-OPTIMIZED-REFERENCE, CHANGELOG
4.8 KiB
name, description
| name | description |
|---|---|
| unified-review | Three-layer unified code review fusing CRG graph context with ai-code-review scoring methodology and gstack-review fix-first workflow |
Unified Review
Perform a three-layer, read-only code review that fuses:
- CRG graph context (blast radius, test gaps, affected flows)
- ai-code-review methodology (Layer-1 chain decomposition, Layer-2 quantitative scoring, Layer-3 acceptance)
- gstack-review workflow (confidence calibration, fix-first, specialist subagents, review-log persistence)
This skill is READ-ONLY. Every finding is presented to the user for a manual fix decision. Never apply code changes, commit, or push.
Token Efficiency Rules
- ALWAYS start with
get_minimal_context(task="unified review"). Usedetail_level="minimal"on all calls; escalate to"standard"only when a metric or finding needs evidence.
Step 0 - Scope and tier
Read .code-review.yaml at the repo root (default tier standard). Tiers: fast (Layer-1 + blockers only), standard (all layers), strict (full + every blocker/major fix needs per-item user confirmation). Single-invocation overrides: 快速审查 → fast, 严格审查 → strict.
Detect the project language/framework and the review scope (change/file/service/chain level). Declare both in the report header.
Step 1 - Graph context (CRG)
- Call
build_or_update_graph_tool()to ensure the graph is current. - Call
get_review_context_tool()for changed files, blast radius, source snippets and review guidance. - Call
detect_changes_tool()for risk-scored change analysis, test gaps and affected flows.
Step 2 - Layer 1: Chain decomposition (ai-code-review)
Inspect the changed code across eight categories: interface, business, data, utility, error handling, security, performance, observability. Mark each ✅ Clean / ⚠️ Issues Found / — N/A. Apply the gstack CRITICAL categories as a sub-pass: SQL & Data Safety, Race Conditions & Concurrency, LLM Output Trust Boundary, Shell Injection, and Enum & Value Completeness. Enum completeness requires reading code OUTSIDE the diff (Grep for sibling values, then Read each consumer).
Step 3 - Layer 2: Quantitative scoring
Call score_review_tool() for the objective metrics (SQL risk, exception coverage, redundancy, high-risk density, vulnerability heuristic). The remaining metrics (requirement coverage, logic alignment, trust boundaries) are judged by you from the requirements doc or a generic baseline; without a requirements doc halve their weight in the verdict.
Step 4 - Specialist dispatch (gstack, diff >= 50 lines)
When the diff has 50+ changed lines, dispatch specialist subagents in parallel via the Agent/task tool, each with a fresh context and its own checklist: testing, maintainability, security, performance, data-migration, api-contract. Security and data-migration always run (insurance). Collect each specialist's JSON findings.
Step 5 - Merge and dedupe
Call dedupe_findings_tool(findings=<all raw findings>) to merge by fingerprint (path:line:category), boost multi-source confidence (+1, cap 10), route low-confidence findings to the appendix, and compute the PR quality score.
Step 6 - Manual adjudication (READ-ONLY)
Present every merged finding with its severity (🔴 blocker / 🟡 major / 🔵 minor), confidence (1-10), file:line and a proposed fix. Group by severity and ask the user per batch: fix / skip / self-fix. 🔴 blockers cannot be batch-skipped. Record skipped findings for prior-review suppression on the next run. Do not modify code.
Step 7 - Acceptance gate (ai-code-review)
Any 🔴 blocker → verdict ❌ FAIL regardless of other scores. Classify each finding as Ready / Needs Fix / Unusable. Verify the change does not deviate from requirements or architecture conventions.
Step 8 - Report
Call generate_report_tool(review_data=<collected verdict, metrics, findings, tier, scope>) to write code-review-report.html and code-review-report.md (default format="both"). Also present the text report inline.
Step 9 - Persistence (optional)
If the gstack-review-log binary is available, record the review outcome (status, counts, quality score, per-finding actions). If it is unavailable, skip silently.
Output Format
Unified Review: N issues (X blocker, Y major, Z minor) — verdict: ✅ PASS / ❌ FAIL. List each issue with severity, confidence, file:line, problem, and proposed fix. List manual-review items (payment, order, inventory, permission, distributed-lock, data-migration) explicitly.
Token Efficiency Rules
- ALWAYS start with
get_minimal_context(task="unified review")before any other graph tool. - Use
detail_level="minimal"on all calls. Only escalate to"standard"when minimal is insufficient. - Target: complete a unified review in ≤8 tool calls and ≤1200 total output tokens.