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
43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
---
|
|
description: Whole-project or single-feature code review (not diff-based) using graph-wide analysis and objective scoring.
|
|
agent: build
|
|
---
|
|
|
|
# Project Review
|
|
|
|
Review the entire codebase or a single feature/module, independent of the git diff. The scope is driven by your instruction.
|
|
|
|
$ARGUMENTS
|
|
|
|
**Token optimization:** Before starting, call `get_docs_section_tool(section_name="project-review")` for the optimized workflow.
|
|
|
|
## Steps
|
|
|
|
1. **Parse the scope** from the user instruction:
|
|
- "对项目代码进行全面审查" / "全面审查" / "整个项目" → `scope=whole-project`
|
|
- "审查 <功能/模块> 的代码" (e.g. payment, auth) → `scope=feature`, target=<keyword>
|
|
|
|
2. **Ensure the graph is current** by calling `build_or_update_graph_tool()`.
|
|
|
|
3. **Map the architecture** by calling `get_architecture_overview_tool(detail_level="minimal")` and `list_communities_tool(detail_level="minimal")`.
|
|
|
|
4. **Scan high-risk areas** (whole-project): `get_knowledge_gaps_tool()`, `get_hub_nodes_tool()`, `get_bridge_nodes_tool()`, `find_large_functions_tool()`, `get_surprising_connections_tool()`.
|
|
|
|
5. **Score objectively**:
|
|
- whole-project: `score_review_tool(all_files=True)` — every source file in the graph
|
|
- feature: `semantic_search_nodes_tool(query=<target>)` + `query_graph_tool(pattern="children_of", target=<target>)` to locate files, then `score_review_tool(changed_files=<files>)` + `get_impact_radius_tool(changed_files=<files>)`
|
|
|
|
6. **Review the code** (Layer 1 chain decomposition): eight categories + gstack CRITICAL sub-pass. 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>)`.
|
|
|
|
8. **Generate the report** by calling `generate_report_tool(review_data=<verdict, 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.
|
|
- This is **not** a diff review. For diff-based review use `/code-review-graph-unified-review`.
|