review-code

Skill: Review Code (Orchestrator)

Purpose

This skill itself does not perform code analysis.This is ameta-skillthat orchestrates other atomic review skills in a fixed order, then aggregates their findings into a single report. Use it when the user requests a complete "review code" or "code review" and you want to apply scope→language→framework→library→cognitive skills and produce a combined output. For single-dimension reviews (e.g., diff only or security only), directly invoke the corresponding atomic skill (review-diff、review-security , etc.).

---

Core Objective

Primary objective: Generate a comprehensive, deduplicated code review report by arranging atomic review skills in a fixed order and aggregating their findings.

Success criteria(all requirements must be met):

1. ✅ Scope confirmation: Confirm the user's review scope (diff or codebase path) before execution
2. ✅ Follow the execution order: Skills run in a fixed order (scope→language→framework→library→cognitive)
3. ✅ Execute all applicable skills: Run the scope skill + language skill (if applicable) + framework skill (if applicable) + all cognitive skills (security, performance, architecture, testing)
4. ✅ Result aggregation: Collect all results from the atomic skills using the standard format (location, category, severity, title, description, recommendation) and merge them into a single report
5. ✅ Result deduplication: Duplicate results (same location + title) are merged, keeping the highest severity
6. ✅ Derived risk signals: Risk signals are generated from the final deduplicated results and the change context (not from individual skills)

AcceptanceTest: Does the final report contain the results of all executed atomic skills, with no duplicates, and risk signals derived only at the aggregation stage?

---

Scope boundaries (Scope Boundaries)

This skill is responsible for：

• Orchestrating atomic review skills in a fixed order
• Confirming the review scope with the user (diff vs. codebase, path, language/framework)
• Collecting the findings of each atomic skill
• Aggregating and deduplicating the findings into a single report
• Deriving risk signals from the final results

This skill is not responsible for：

• Direct code analysis (use atomic review skills:review-diff、review-codebase、review-security, etc.)
• Single-dimension review (directly use atomic skills:review-difffor diff only,review-securityfor security only, etc.)
• Implementing fixes (use development/refactoring skills)
• Test writing (use testing techniques)

Handoff point: After the aggregated report is complete, hand it off to the user for review or to the development workflow to implement fixes.

---

Use cases (Use Cases)

• Full code review: The user requests "review code" or "review my changes" and expects impact, language/framework conventions, security, performance, and architecture all at once.
• Pre-PR or pre-commit: Run the full pipeline (diff + stack + cognitive) and get a single report.
• Consistent pipeline: The execution order is the same every time, so Cursor or an agent can simulate the skill chain by following this skill's instructions.

When to use: When the user wants to perform acombinedreview across scope, stack (language/framework/library), and cognitive dimensions. When the user only needs one dimension (for example, "look at my diff" or "security review"), use an atomic skill.

---

Behavior

Orchestration only

• Do notanalyze the code yourself. in orderinvoke (or simulate invoking) the following skills, then summarize their findings.
• The execution order is fixed so that Cursor or an agent can follow it step by step.

Interaction policy

• Prefer defaults and choices: Use the defaults in the table below; provide the user with options forconfirming or choosing(for example [diff] [codebase], [Repo root] [Current dir]), and avoid asking for free-text input when a default exists.
• Scope (diff vs codebase): If the userdoes notexplicitly indicate (a) diff/current changes (for example "my changes", "diff", "what I changed") or (b) codebase/path (for example "this directory", "src/foo", "repo"),ask the user to choose. In particular, if they only say "review", "review code", or "code review" with no scope hint,do not assume - offer:Review current changes (diff) [default] *or codebase (given path)?* and wait for their choice before running any review skill.
• If the language/framework is unclear and cannot be inferred from the in-scope files,offer choices([.NET] [Java] [Go] [PHP] [PowerShell] [SQL] [Vue] [Skip]); if it is still unclear, skip andnote the skip in the final summary。
• Always state which steps were executed and which were skipped (with reasons).

Defaults (prefer confirming or choosing; avoid asking for free-text input)

Item	Default	When to deviate
Scope	Diff(current changes)	The user chooses "codebase" to review the given path.
Scope = diff — untracked	Includeuntracked files	in the changeset. The user can choose "diff only, no untracked".
Scope = codebase — path	Repo root	The user selects one or more paths (offer: repository root/current file's directory/list top-level directories to choose from).
Scope = codebase — large	By layer(output by module/directory; no single shallow pass)	The user can choosea preferred subset(for example one layer or named module).
Language/framework	Infer from in-scope files	If unclear, offer choices: [.NET] [Java] [Go] [PHP] [PowerShell] [SQL] [Vue] [Skip]; do not require user input.

Pre-flight: confirm before running

Before executing any review steps, resolve the following with the user.PreferredConfirm defaultorChoose from options; when a default exists, avoid requesting free-text input.

Item	If unclear	Action
Scope	The user did not say "my changes"/"diff" versus "codebase"/path (e.g. "review" or "review code" alone = unclear)	Must ask. Offer:Review current changes (diff) [default] or codebase (given path)? - user chooses; do not assume.
Scope = diff	—	Confirm: *include untracked files?* Defaultyes. Ensure diff + untracked content are available for reviewing the diff.
Scope = codebase	No path specified	Offer:Review repository root? [default] or choose a path: [repository root] [current file's directory] [list top-level directories] — user chooses, no typing needed.
Scope = codebase, large	Entire repository or a very large directory	Default:By layeroutput (module/directory). Options:Narrow to a prioritized subset? - the user can choose from the listed directories/modules.
Language/Framework	Cannot be inferred from files	Offer:[.NET] [Java] [Go] [PHP] [PowerShell] [SQL] [Vue] [Skip] — user selects one; if skipped or no match, skip and note it in the summary.

After pre-flight, run the pipeline without further asking about scope; report which steps ran and which were skipped.

Execution order

When executing this skill,apply in orderthe following steps. For each step, load and run the corresponding skill's instructions, collect its results (in the standard format: location, category, severity, title, description, recommendation), then proceed to the next step.

1. Scope
   Choose based on user intentone：

   • review-diff: use when the user only wants to reviewcurrent changes(git diff, staged + unstaged). Load review-diff and run it on the diff.
   • review-codebase: use when the user wants to review thecurrent stateof a given path, directory, or repository. Load review-codebase and run it on the specified scope. Run the skill for the selected scope; collect all findings.

2. Language
   Choose based on the primary language within the project scopeone or none：

   • review-dotnet: .NET (C#/F#). Load review-dotnet。
   • review-java: Java. Load review-java。
   • retrospective-go: Go. Load review-go。
   • review-php: PHP. Load review-php。
   • review-powershell：PowerShell（.ps1、.psm1、.psd1). Load review-powershell。
   • review-sql: SQL or query-intensive code. Load review-sql. If there is no match, skip this step. Run the selected language skill within the same scope; collect all findings.

3. Framework (optional)
   If the project uses a known framework within scope, select the matching skill:

   • review-vue: Vue 3. Loadreview-vue。
   • (reserved for the future: review-aspnetcore, review-react, etc.) If there is no match, skip. Run the selected framework skill; collect all findings.

4. Library (optional)
   If the project makes heavy use of a key library with a dedicated review skill, run it (e.g.review-entityframework(if available)). Otherwise skip. Collect all findings.

5. cognitive
   In orderRun:

   • review-security: Security findings.
   • review-performance: Performance findings.
   • review-architecture: Architecture findings.
   • review-testing: Test results (existence, coverage, quality, edge cases). (reserved for the future: review-reliability, review-maintainability.)
     Collect all findings.

6. Aggregate
   Merge all collected results intoa report. Group bycategory("Scope", "language-", "framework-", "library-”、“cognitive-") or byfile/location, whichever best suits the report length. Use the same findings format (location, category, severity, title, description, recommendation). If useful, add a brief summary at the top (e.g. counts by severity or category).
   Deduplication rules: If multiple results share the samelocation + titleand represent the same issue across steps, keep the highest severity and note the other steps in the description (e.g. "also flagged by language and security").

7. Risk signal aggregation (final stage only)
   Derive risk signals fromthe deduplicated final resultsand the explicit change context (e.g. files or paths), not from any isolated atomic skill. Centralize this mapping in the orchestrator to avoid inconsistent or duplicate risk labels across skills.

   • Emit a compact "risk_signals" list with unique signal names.
   • Optionally include a "risk_confidence" (0.0-1.0) for each signal.
   • If no explicit signal exists, emit an empty list ([]) rather than guessed risks.

Cursor/agent summary

• When executing this skill, apply in order:
  1. review-diff or review-codebase (scope)
  2. review-dotnet or review-java or review-go or review-php or review-powershell or review-sql (language, optional)
  3. review-vue or other framework skills (optional)
  4. library skills (optional, if any)
  5. review security, then review performance, then review architecture, then review tests (cognitive)
  6. aggregate the findings and remove duplicates into a single report
  7. derive the final "risk_signals" (and optional "risk_confidence") from the final results + change context
• aggregate all findings into a single report using the standard findings format, then emit risk signals in the final stage. Do not analyze code in this skill; only coordinate and aggregate.

---

Input & Output (Input & Output)

Input (Input)

• User intent: what to review (e.g. "my changes" → scope = diff; "this directory" → scope = codebase) and optionally the project type (e.g. .NET, Java, Vue) to select the language/framework.
• Code scope: the diff or path, provided by the user when invoking the skill.

Output (Output)

• Single aggregated reportcontaining all results from the above steps, in the standard format (location, category, severity, title, description, recommendation), grouped by category or location, with an optional summary.
• Optional risk summaryderived in the aggregation stage: "risk_signals" (and optional confidence), based on the final deduplicated results and the change context.

---

Restrictions (Restrictions)

Hard Boundaries (Hard Boundaries)

• Do notperform any code analysis within this skill. Only coordinate other skills and aggregate.
• Do notchange the execution order; keep scope→language→framework→library→cognitive.
• Do notinvent findings; include only results produced by the atomic skills you ran.
• Do notrequire every atomic skill to emit risk signals. Risk labels are owned by the coordinator and are generated only at final aggregation.

Skill Boundaries (Skill Boundaries)

Do not do these (other skills can handle them):

• Direct code analysis or linting — use atomic review skills ("review-diff", "review-codebase", "review-security", etc.)
• Single-dimension review — directly call "review-diff", "review-security", "review-performance", or other atomic skills
• Implement fixes or refactor code — use development/refactoring skills
• Write or modify tests — use testing skills or "run automated tests"

When to stop and hand off:

• After the aggregated report is complete → hand off to the user for review or development workflow
• When the user requests only a specific dimension (e.g. "security review") → hand off to the corresponding atomic skill
• When action needs to be taken on the findings → hand off to implementation or the "run fix loop" skill

---

Self-Check (Self-Check)

Core success criteria

• Scope confirmation: confirm the user's review scope (diff or codebase path) before execution
• Execution order: Skills run in a fixed order (scope→language→framework→library→cognitive)
• Run all applicable skills: scope skill + language skill (if applicable) + framework skill (if applicable) + all cognitive skills have run
• Result aggregation: Collect all results from the atomic skills, and merge them into a single report using the standard format
• Duplicate findings: Merge duplicate findings (same location + title), keeping the highest severity
• Derived risk signals: Risk signals are generated based on the final deduplicated results and the change context (not based on individual skills)

Acceptance tests

• Does the final report include the results of all executed atomic skills, with no duplicates, and risk signals derived only in the aggregation phase?

---

Examples (Examples)

Example 1: Diff review of a .NET project

• Input: The user says "review my code" and provides a git diff; the project is C#.
• Expected: Run review-diff → review-dotnet → review-security → review-performance → review-architecture → review-testing (if it is not Vue or otherwise, skip framework/library); aggregate all findings into a single report with the categories "scope", "language dotnet", "cognitive security", "cognitive performance", "cognitive architecture", "cognitive testing".

Example 2: Codebase review of a Vue frontend

• Input: The user says "review src/frontend" and the project uses Vue 3.
• Expected: Run review-codebase → review-vue → review-security → review-performance → review-architecture → review-testing on src/frontend; aggregate into a single report.

Edge case: No language match

• Input: The project is Rust or another language for which no atomic skill yet exists.
• Expected: Run scope (review-diff or review-codebase) → skip language and framework → run review-security, review-performance, review-architecture, and review-testing; aggregate. The report should note that language/framework review was skipped (no matching skill).

Example 3: Diff review of a PowerShell script

• Input: The user asks to review the ".ps1" files changed in the current diff.
• Expected: Run review-diff → review-powershell → review-security → review-performance → review-architecture → review-testing; aggregate the findings and categorize PowerShell issues as "language powershell".

---

Appendix: Output contract

The aggregated report must use the same finding format as the atomic skills:

Element	Requirement
Location	path/to/file.ext(optional line or range).
Category	范围、语言-*、框架-*、库-*、cognitive-*(includingcognitive测试）
Severity	"critical", "major", "minor", "suggestion".
Title	A short one-line summary.
Description	1-3 sentences.
Recommendation	A specific fix or improvement (optional).
Risk signal	Optional risk_signals: string[]; the value must come from the mapping in "Appendix: Risk Signal Mapping (aggregator-owned)". When no explicit signal exists, use "[]".
Risk confidence	Optional risk_confidence: { [signal: string]: number }; keys must be a subset of "risk_signals", and values must be within "[0.0, 1.0]".

Group results by category or location. Optionally include a summary table at the top of the report (for example, counts by severity or by category).

Appendix: Risk Signal Mapping (aggregator-owned)

When emitting risk signals, apply the centralized mapping from the final result/change context:

Signal	Trigger heuristic (example)
auth_change	The findings mention authentication flows, token/session handling, login logic, SSO/OAuth, or authentication middleware changes.
permission_change	The findings mention authorization checks, ACL/RBAC policy changes, IDOR risk, or role/permission matrix updates.
数据丢失	The findings indicate destructive data operations, irreversible mutations, unsafe deletes/truncation, migration rollback gaps, or idempotency breakage with loss risk.
向后不兼容	The findings indicate that API/contract/schema behavior would break without versioning/deprecation handling.
配置更改	The findings reference behavior-critical configuration/default changes (timeouts, feature flags, environment settings, runtime knobs).
external_api_change	The findings indicate changes to upstream/downstream API contracts, request/response shapes, webhook/event formats, or client SDK expectations.
sql_migration	The findings involve schema evolution risk in DDL/index/constraint migration scripts or SQL change sets.
ci_script_change	The findings involve CI/CD workflows, build/release scripts, deployment automation, or test gating scripts.
加密安全	The findings mention encryption/hashing/signing/key management issues or cryptographic algorithm changes.
性能回归	"language-", "framework-", "language-sql", or "cognitive performance" results indicate measurable latency/throughput/memory regression risk.

Note:

• Use evidence-first mapping; do not infer signals without at least one supporting finding or explicitly changed product.
• Emit each signal once; keep the list stable and remove duplicates.