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
3.5 KiB
name, description
| name | description |
|---|---|
| project-review | Whole-project or single-feature code review (not diff-based) using graph-wide analysis and objective scoring |
Project Review
Review the entire codebase or a single feature/module, independent of the git diff. Two scopes, driven by the user's instruction:
- whole-project: "对项目代码进行全面审查", "全面审查", "整个项目" → review every source file in the graph.
- feature: "审查 <功能/模块> 的代码" (e.g. payment, auth) → review only the code related to the target.
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="project review"). Usedetail_level="minimal"on all calls; escalate to"standard"only when a metric or finding needs evidence.
Step 0 - Parse the scope
Read the user's instruction and set scope: whole-project (contains 全面/整个项目/所有/all) or feature + target (extract the feature/module keyword). Declare both in the report header.
Step 1 - Graph ready
- Call
build_or_update_graph_tool()to ensure the graph is current. - Call
get_minimal_context_tool(task="project review")for stats and community overview.
Step 2 - Architecture map
Call get_architecture_overview_tool(detail_level="minimal") and list_communities_tool(detail_level="minimal") to map the module structure.
Step 3 - High-risk scan (whole-project)
Call get_knowledge_gaps_tool(), get_hub_nodes_tool(), get_bridge_nodes_tool(), find_large_functions_tool() and get_surprising_connections_tool() to locate hotspots, chokepoints, untested areas and odd coupling.
Step 4 - Objective scoring
- whole-project:
score_review_tool(all_files=True)scores every source file in the graph. - feature: locate the target files with
semantic_search_nodes_tool(query=<target>)andquery_graph_tool(pattern="children_of", target=<target>), thenscore_review_tool(changed_files=<files>)andget_impact_radius_tool(changed_files=<files>)for the blast radius.
Step 5 - Chain decomposition
Inspect the scored code across eight categories (interface, business, data, utility, error handling, security, performance, observability) and apply the gstack CRITICAL sub-pass (SQL & Data Safety, Race Conditions, LLM Output Trust Boundary, Shell Injection, Enum Completeness). Mark each ✅ / ⚠️ / —.
Step 6 - Manual adjudication (READ-ONLY)
Present every finding with 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. Do not modify code.
Step 7 - Acceptance gate
Any 🔴 blocker → verdict ❌ FAIL. Classify each finding as Ready / Needs Fix / Unusable.
Step 8 - Report
Call generate_report_tool(review_data=<verdict, scope, metrics, findings>) to write code-review-report.html and code-review-report.md (default format="both").
Output Format
Project Review: N issues (X blocker, Y major, Z minor) — verdict: ✅ PASS / ❌ FAIL. List each issue with severity, confidence, file:line, problem, and proposed fix.
Token Efficiency Rules
- ALWAYS start with
get_minimal_context(task="project review")before any other graph tool. - Use
detail_level="minimal"on all calls. Only escalate to"standard"when minimal is insufficient. - Target: complete a project review in ≤12 tool calls and ≤1800 total output tokens.