Files
code-review-graph/.opencode/command/code-review-graph-unified-review.md
T
dev 307d2fd471 feat: add project-review workflow (whole-project / single-feature review)
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
2026-08-06 13:56:54 +08:00

2.3 KiB

description, agent
description agent
Run the three-layer unified review (CRG graph context + score_review + dedupe_findings + generate_report). build

Unified Review

Run the three-layer unified code review using the MCP prompt workflow.

$ARGUMENTS

Token optimization: Before starting, call get_docs_section_tool(section_name="unified-review") for the optimized workflow.

Steps

  1. Load the workflow by calling the unified_review MCP prompt (or the unified-review skill). This drives the full READ-ONLY review pipeline.

  2. Ensure the graph is current by calling build_or_update_graph_tool().

  3. Get the review context by calling get_review_context_tool() — changed files, blast radius, source snippets.

  4. Detect changes by calling detect_changes_tool() — risk score, changed functions, test gaps, affected flows.

  5. Score objectively by calling score_review_tool() — SQL risk, exception coverage, redundancy, high-risk density, vulnerability heuristic (good/warn/fail grades). LLM-judged metrics are in llm_judged.

  6. Review the changed code (Layer 1 chain decomposition): interface, business, data, utility, error handling, security, performance, observability. Produce findings with severity (blocker/major/minor), confidence (1-10), file:line, and proposed fix.

  7. Merge findings by calling dedupe_findings_tool(findings=<your findings>) — fingerprint dedup, multi-source confidence boost, PR quality score.

  8. Generate the report by calling generate_report_tool(review_data=<verdict, tier, scope, metrics, merged findings>) — writes code-review-report.html and code-review-report.md (default format="both").

  9. Report the verdict ( PASS / FAIL), severity counts, each issue with confidence + fix, and manual-review items.

Important Rules

  • READ-ONLY. This workflow never modifies code, commits, or pushes. Every finding waits for a manual fix decision.
  • Any blocker → verdict FAIL, regardless of other scores.
  • Tier (fast / standard / strict) comes from .code-review.yaml at the repo root, or the tier argument.

Tips

  • For large diffs (50+ lines), dispatch specialist subagents (testing, maintainability, security, performance, data-migration, api-contract) in parallel before dedupe.
  • Security and data-migration are insurance specialists — always run even when silent.