Purpose
Chain the atomic review-* skills in a fixed order and aggregate findings. This skill only orchestrates; it does not perform code analysis. For single-dimension reviews, call the corresponding atomic skill directly (e.g., for diff-only checks use review-diff, for security-only checks use review-security）。
Orchestrator Role
By naming convention, the orchestration skilldoes only 4 things：
- Detect context: determine scope (diff / codebase), language, and framework based on user intent and project state
- Chain calls: execute the atomic review-* skills in the fixed order scope → language → framework → library → cognitive
- halt-on-failure: when any atomic skill fails, stop subsequent steps and report the findings collected so far
- Aggregate output: merge findings, deduplicate (same location + title keeps the highest severity), and mechanically derive risk_signals
Strictly prohibited: performing code analysis within this skill, embedding lint rules, or reimplementing the logic of a single atomic skill.
Execution order (fixed)
| Step | Type | Candidate atomic skills | Selection rule |
|---|---|---|---|
| 1 | scope | review-diff or review-codebase |
choose one based on user intent (diff = current changes; codebase = given path) |
| 2 | language | review-typescript / review-python / review-go / review-java / review-php / review-powershell / review-dotnet / review-sql |
0 or 1, inferred from the primary language in scope |
| 3 | framework | review-react / review-vue |
0 or 1, inferred from the framework in scope |
| 4 | library | review-orm-usage |
0 or 1, inferred from ORM usage in scope |
| 5 | cognitive | review-security → review-performance → review-architecture → review-testing |
execute all in order |
Steps with no match are skipped; the final report notes which steps were skipped and why.
Behavior
Step 1: Detect context
- Scope confirmation: if the user has not specified it, have them choose between
diff/codebasechoose one of the two - diff mode includes untracked files by default
- codebase mode defaults to the repository root; a path may be specified
- Language / framework inference: infer from file extensions and dependency files (package.json, pyproject.toml, etc.) within scope; if uncertain, have the user choose from a candidate list
Step 2: Chain calls
Call the atomic skills in sequence according to the table above, collecting findings at each step (standard format: location / category / severity / title / description / suggestion).
Step 3: halt-on-failure
If any atomic skill fails → stop subsequent steps and output the findings collected so far + an explanation of the failure.
Step 4: Aggregate output
- Deduplication rule: identical
location + titleare merged across steps, keeping the highest severity, and noting the other steps where they were hit in the description - Risk signals: based on the aggregated findings + change context, performmechanical rule mapping(by severity distribution, file coverage, keyword matching), without subjective judgment; when there is no clear signal, output an empty list
[]
Input and Output
Input
- User intent (whether to check diff / codebase / a specified path)
- Optional: language / framework hints
Output
A single aggregated report:
- Findings from each atomic skill (grouped by category or location)
- Explanation of skipped steps
risk_signalsList (each entry contains signal_name + optional confidence ∈ [0, 1])- Top summary (count by severity, count by category)
Restrictions
Hard boundaries
- Do not perform code analysis, lint, or rule matching within this skill (violates the orchestrator 4-things principle)
- Do not change the execution order (scope → language → framework → library → cognitive)
- Do not invent findings; only aggregate atomic skill outputs
- Do not require every atomic skill to output risk_signals; risk labels are only produced during the aggregation stage
- Do not modify code / do not implement fixes (leave to development or
orchestrate-repair-loop）
Skill boundaries
Not done within the orchestration skill(should be handled by atomic sub-skills or downstream skills):
- Direct code analysis → each atomic review-* skill
- Single-dimension review → directly call the corresponding atomic skill
- Fix implementation →
orchestrate-repair-loopor development process - Test writing → testing-related skills
Self-check
- Only does the 4 things "detect context / chain calls / halt-on-failure / aggregate output"
- Domain detection logic is not implemented within this skill
- scope has been confirmed with the user
- Execution order is fixed (scope → language → framework → library → cognitive)
- Skipped steps have been noted in the report
- Findings deduplication rules have been applied (same location + title keeps the highest severity)
- risk_signals are mechanically derived based on aggregated findings, with no subjective judgment
Examples
Example 1: .NET project diff review
- Input: user says "check my changes", the project is C#
- Dispatch:
review-diff→review-dotnet→review-security→review-performance→review-architecture→review-testing - Skip: framework / library steps (no match)
- Aggregate: single report + risk_signals
Example 2: Vue frontend codebase review
- Input:
src/frontend, the project uses Vue 3 + ORM - Dispatch:
review-codebase→review-typescript→review-vue→review-orm-usage→review-security→review-performance→review-architecture→review-testing - Aggregate: single report
Example 3: boundary scenario—no language match
- Input: Rust project (no corresponding atomic skill)
- Dispatch:
review-codebase→ skip language / framework / library → execute all cognitive - Aggregate: report notes the skipped language / framework steps and the reasons