dev
84ae9b817e
Adds the unified-review integration that fuses CRG graph context with the ai-code-review scoring methodology and gstack-review fix-first workflow: - scoring.py: objective Layer-2 metrics (sql_risk, exception_coverage, redundancy_rate, high_risk_density, vulnerability_risk) with good/warn/fail grades, plus dedupe_findings (fingerprint merge, multi-source confidence boost, PR quality score) and report data builder - tools/scoring_tools.py + main.py: three new MCP tools (score_review_tool, dedupe_findings_tool, generate_report_tool) - assets/report-template.html: self-contained HTML report template - skills.py + skills/unified-review/: new read-only unified-review skill with language/manual-review/specialist checklists - docs and CHANGELOG updated; tests added (test_scoring, test_report, test_unified_review) and test_skills updated for 5 skills
70 lines
4.8 KiB
Markdown
70 lines
4.8 KiB
Markdown
---
|
|
name: unified-review
|
|
description: 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")`. Use `detail_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)
|
|
|
|
1. Call `build_or_update_graph_tool()` to ensure the graph is current.
|
|
2. Call `get_review_context_tool()` for changed files, blast radius, source snippets and review guidance.
|
|
3. 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`. 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.
|