chore: sync local changes, add Chinese docs and opencode config
This commit is contained in:
AuraK Developer
@@ -0,0 +1,39 @@
|
||||
---
|
||||
description: Build or rebuild the code review knowledge graph for this project.
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Build Graph
|
||||
|
||||
Build or incrementally update the persistent code knowledge graph for this repository.
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Check graph status** by calling the `list_graph_stats_tool` MCP tool.
|
||||
- If the graph has never been built (last_updated is null), proceed with a full build.
|
||||
- If the graph exists, proceed with an incremental update.
|
||||
|
||||
2. **Build the graph** by calling the `build_or_update_graph_tool` MCP tool:
|
||||
- For first-time setup: `build_or_update_graph_tool(full_rebuild=True)`
|
||||
- For updates: `build_or_update_graph_tool()` (incremental by default)
|
||||
|
||||
3. **Verify** by calling `list_graph_stats_tool` again and report the results:
|
||||
- Number of files parsed
|
||||
- Number of nodes and edges created
|
||||
- Languages detected
|
||||
- Any errors encountered
|
||||
|
||||
## When to Use
|
||||
|
||||
- First time setting up the graph for a repository
|
||||
- After major refactoring or branch switches
|
||||
- If the graph seems stale or out of sync
|
||||
- The graph auto-updates via hooks on edit/commit, so manual builds are rarely needed
|
||||
|
||||
## Notes
|
||||
|
||||
- The graph is stored as a SQLite database (`.code-review-graph/graph.db`) in the repo root
|
||||
- Binary files, generated files, and patterns in `.code-review-graphignore` are skipped
|
||||
- If the graph tools are unavailable, fall back to `code-review-graph build` / `code-review-graph status` via the shell
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
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`.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
description: Review only changes since last commit using impact analysis and blast-radius detection.
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Review Delta
|
||||
|
||||
Perform a focused, token-efficient code review of only the changed code and its blast radius.
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
**Token optimization:** Before starting, call `get_docs_section_tool(section_name="review-delta")` for the optimized workflow. Use ONLY changed nodes + 2-hop neighbors in context.
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Ensure the graph is current** by calling `build_or_update_graph_tool()` (incremental update).
|
||||
|
||||
2. **Get review context** by calling `get_review_context_tool()`. This returns:
|
||||
- Changed files (auto-detected from git diff)
|
||||
- Impacted nodes and files (blast radius)
|
||||
- Source code snippets for changed areas
|
||||
- Review guidance (test coverage gaps, wide impact warnings, inheritance concerns)
|
||||
|
||||
3. **Analyze the blast radius** by reviewing the `impacted_nodes` and `impacted_files` in the context. Focus on:
|
||||
- Functions whose callers changed (may need signature/behavior verification)
|
||||
- Classes with inheritance changes (Liskov substitution concerns)
|
||||
- Files with many dependents (high-risk changes)
|
||||
|
||||
4. **Perform the review** using the context. For each changed file:
|
||||
- Review the source snippet for correctness, style, and potential bugs
|
||||
- Check if impacted callers/dependents need updates
|
||||
- Verify test coverage using `query_graph_tool(pattern="tests_for", target=<function_name>)`
|
||||
- Flag any untested changed functions
|
||||
|
||||
5. **Report findings** in a structured format:
|
||||
- **Summary**: One-line overview of the changes
|
||||
- **Risk level**: Low / Medium / High (based on blast radius)
|
||||
- **Issues found**: Bugs, style issues, missing tests
|
||||
- **Blast radius**: List of impacted files/functions
|
||||
- **Recommendations**: Actionable suggestions
|
||||
|
||||
## Advantages Over Full-Repo Review
|
||||
|
||||
- Only sends changed + impacted code to the model (5-10x fewer tokens)
|
||||
- Automatically identifies blast radius without manual file searching
|
||||
- Provides structural context (who calls what, inheritance chains)
|
||||
- Flags untested functions automatically
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
description: Review a PR or branch diff using the knowledge graph for full structural context with blast-radius analysis.
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Review PR
|
||||
|
||||
Perform a comprehensive code review of a pull request or branch diff using the knowledge graph.
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
**Token optimization:** Before starting, call `get_docs_section_tool(section_name="review-pr")` for the optimized workflow. Never include full files unless explicitly asked.
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Identify the changes** for the PR:
|
||||
- If a PR number or branch is provided in $ARGUMENTS, use `git diff main...<branch>` to get changed files
|
||||
- Otherwise auto-detect from the current branch vs main/master
|
||||
|
||||
2. **Update the graph** by calling `build_or_update_graph_tool(base="main")` to ensure the graph reflects the current state.
|
||||
|
||||
3. **Get the full review context** by calling `get_review_context_tool(base="main")`:
|
||||
- This uses `main` (or the specified base branch) as the diff base
|
||||
- Returns all changed files across all commits in the PR
|
||||
|
||||
4. **Analyze impact** by calling `get_impact_radius_tool(base="main")`:
|
||||
- Review the blast radius across the entire PR
|
||||
- Identify high-risk areas (widely depended-upon code)
|
||||
|
||||
5. **Deep-dive each changed file**:
|
||||
- Read the full source of files with significant changes
|
||||
- Use `query_graph_tool(pattern="callers_of", target=<func>)` for high-risk functions
|
||||
- Use `query_graph_tool(pattern="tests_for", target=<func>)` to verify test coverage
|
||||
- Check for breaking changes in public APIs
|
||||
|
||||
6. **Generate structured review output**:
|
||||
|
||||
```
|
||||
## PR Review: <title>
|
||||
|
||||
### Summary
|
||||
<1-3 sentence overview>
|
||||
|
||||
### Risk Assessment
|
||||
- **Overall risk**: Low / Medium / High
|
||||
- **Blast radius**: X files, Y functions impacted
|
||||
- **Test coverage**: N changed functions covered / M total
|
||||
|
||||
### File-by-File Review
|
||||
#### <file_path>
|
||||
- Changes: <description>
|
||||
- Impact: <who depends on this>
|
||||
- Issues: <bugs, style, concerns>
|
||||
|
||||
### Missing Tests
|
||||
- <function_name> in <file> - no test coverage found
|
||||
|
||||
### Recommendations
|
||||
1. <actionable suggestion>
|
||||
2. <actionable suggestion>
|
||||
```
|
||||
|
||||
## Tips
|
||||
|
||||
- For large PRs, focus on the highest-impact files first (most dependents)
|
||||
- Use `semantic_search_nodes_tool` to find related code the PR might have missed
|
||||
- Check if renamed/moved functions have updated all callers
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
description: Run the three-layer unified review (CRG graph context + score_review + dedupe_findings + generate_report).
|
||||
agent: 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.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
description: 用自然语言为 code-checker 新增一条规则（语义/声明式/Python 兜底）并注册生效
|
||||
agent: build
|
||||
---
|
||||
|
||||
# rulegen
|
||||
|
||||
为 code-checker 新增一条代码规则。先加载 rulegen skill 并按其流程执行（若可用）。
|
||||
|
||||
用户要新增的规则描述：
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## 前置
|
||||
|
||||
- 确认当前工作目录是 code-checker 项目（含 `tools/rulegen.py` 与 `docs/rulegen/prompt-template.md`）。若不是，先切换到该项目根目录或使用其绝对路径执行。
|
||||
- Windows 下若无 `python` 命令，使用 `py`。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. 读取提示词模板 `docs/rulegen/prompt-template.md`，按其 schema 与全部约定执行。
|
||||
2. 判断规则类型（三选一）：
|
||||
- **semantic（语义）**：需理解代码意图（如 catch 块日志、XSS 转义）→ 只生成 `rule.yaml`，必含 `check_prompt` + `message_zh`
|
||||
- **declarative（声明式机械）**：行级正则可表达 → `rule.yaml` 含 `pattern`（**必须用 YAML 单引号**，如 `pattern: 'Thread\\.sleep\\s*\\('`）
|
||||
- **python（机械 Python 兜底）**：需跨行/AST 逻辑，且是 Java（JSP 不支持）→ `rule.yaml` + `checker.py`（继承 `BaseChecker`，`CATEGORIES` 用新类别）
|
||||
3. 在 `rules/_staging/<rule-slug>/` 下生成 `rule.yaml`（必要时含 `checker.py`、`sample.<java|jsp>`、`negative.<java|jsp>`）。
|
||||
4. 依次执行（在项目根目录；退出码 0=OK / 1=失败，失败先修正再重试，**不要**强制跳过）：
|
||||
```
|
||||
python tools/rulegen.py validate rules/_staging/<rule-slug>
|
||||
python tools/rulegen.py smoke rules/_staging/<rule-slug> # 语义规则跳过
|
||||
python tools/rulegen.py register rules/_staging/<rule-slug> --dry-run
|
||||
python tools/rulegen.py register rules/_staging/<rule-slug>
|
||||
```
|
||||
5. 注册完成后向用户报告：规则 ID 与类型、落盘文件（`rules/custom/<lang>-rules.yaml`，python 类另含 `check-engine/custom_checkers/`）、校验/冒烟摘要。
|
||||
|
||||
## 纪律
|
||||
|
||||
- **不修改** `rules/java-rules.yaml` / `rules/jsp-rules.yaml` / `rules/messages.yaml` 等交付文件；只写 `rules/custom/` 与 `check-engine/custom_checkers/`。
|
||||
- ID 编号写 `-001` 即可，`register` 会自动重编号。
|
||||
- 生成后不做 git 提交。
|
||||
Reference in New Issue
Block a user