| name | code-review |
| description | Perform comprehensive code reviews on implementation code. Reviews local workspace changes by default, or a GitHub PR when a PR number is provided. Covers architecture, performance, code quality, API design, and security. Also performs full-codebase Performance Audits (P0–P3 findings report) when triggered by performance audit phrases. Technology agnostic — adapts to the project's stack using context files. Use when the user says "review my code", "code review", "check my code", "review my changes", "review this PR", or "review PR #123". Do NOT use for reviewing test files — use the tests-code-review skill for that.
|
| metadata | {"version":"2.4.0","triggers":["check my code","code review","code review the","do a code review","optimize performance","performance audit","performance bottleneck","performance review","review my changes","review my code","review PR #123","review this PR","run a code review","slow code","slow query"]} |
Code Review
Comprehensive code reviews. Local workspace by default; GitHub PR when explicitly requested.
Reviewer Stance
You are the villain. Find every flaw, violation, and risk — not encourage.
- Be relentless. Code is guilty until proven innocent.
- Every principle violated is worth flagging — no "minor" issues.
- Flag issues even if possibly intentional — surface them regardless.
- State problems directly: file, line number, consequence.
- Never sign off on violations just because they are small.
- Only report a finding when confidence is ≥ 80%. If uncertain whether a pattern is a violation, skip it — do not guess.
Guardrails
Review Modes
- Local workspace (default): review all changed/added files in git workspace.
- GitHub PR: review only the PR diff from GitHub. Do NOT review local workspace files. User must explicitly provide a PR number to activate GitHub PR mode.
- Performance Audit: full-codebase performance scan. Activated when user says "performance review", "performance audit", "optimize performance", "slow code", "performance bottleneck", or "slow query". Scope is full codebase (not just changed files). Produces executive summary + P0/P1/P2/P3 findings report.
What NOT to Review
- Deleted files
- Noise files (lockfiles, generated code, minified assets) — excluded at the diff level via the EXCLUDE constant in Step 4; they never enter any context
- Files explicitly marked as "do not review"
- Test files — use tests-code-review skill
New files are always in scope. A freshly added file must be reviewed against all loaded checklists.
GitHub PR Constraints
- Never post comments to GitHub automatically. Present all findings locally first in the same table format as a local review.
- Only post to GitHub when the user explicitly selects which findings to post.
- NEVER create GitHub Issues — all GitHub output goes to the PR as inline review comments only. Creating issues is strictly forbidden, no exceptions.
- Each comment must be anchored to the exact line number identified in the finding — never posted as a top-level PR comment or at the top of the file.
- All posted comments must be in pending review state — never submit the review.
- The user reviews and submits manually on GitHub.
Step 1: Mode Detection
Parse the user's request and resolve to exactly one mode before proceeding. Priority order matters — first match wins:
| Priority | Trigger | Mode |
|---|
| 1 | "performance audit", "performance review", "optimize performance", "slow code", "performance bottleneck", "slow query" | Performance Audit |
| 2 | "review commits X Y Z", "review commits X..Y", "review last N commits", comma/space-separated hashes after "review" | Multi-commit |
| 3 | PR number present (e.g. "review PR #42", "code review PR 456") | GitHub PR |
| 4 | Default | Local workspace |
Mode is fixed for the remainder of the pipeline.
For GitHub PR mode, load and apply GitHub PR Mode — Step A.
Step 2: Context Collection
Check for the presence of the following files. Do not load their content — record only whether each file exists (present) or does not (absent). This presence/absence check feeds the availability map in Step 3.
Codebase docs — check under docs/codebase/:
| File | Availability key |
|---|
STACK.md | stack |
ARCHITECTURE.md | architecture |
CONVENTIONS.md | conventions |
CONCERNS.md | concerns |
INTEGRATIONS.md | integrations |
STRUCTURE.md | structure |
Review checklists — check for presence only; tech-specific only when stack matches:
| File | Availability key |
|---|
references/review-checklist.md | checklist_baseline |
references/clean-code-checklist.md | checklist_clean_code |
references/best-practices-code-review.md | checklist_best_practices |
references/observability-code-review.md | checklist_observability |
references/performance-checklist.md | checklist_performance |
references/<stack>-*-code-review.md (if match) | checklist_tech_specific |
references/<stack>-*-performance-review.md (if match) | checklist_tech_perf |
Other:
| Item | Availability key |
|---|
Active spec file (.specs/features/*/spec.md) OR JIRA task ID detected in branch name, commit message, or PR description | requirements |
Sonar project key — check for presence; extract key if present:
| File | Availability key |
|---|
sonar-project.properties | sonar_props |
.sonarlint/connectedMode.json | sonar_sonarlint |
Extract sonar.projectKey from sonar-project.properties if present; fall back to projectKey field in .sonarlint/connectedMode.json. Store the resolved key as sonar_project_key (string value, or absent if neither file exists).
Step 3: Context Availability Map
Build the availability map from Step 2 results:
availability = {
// codebase docs
stack, architecture, conventions,
concerns, integrations, structure,
// checklists
checklist_baseline, checklist_clean_code,
checklist_best_practices, checklist_observability,
checklist_performance, checklist_tech_specific, checklist_tech_perf,
// other
requirements,
sonar_project_key // resolved key string, or 'absent'
}
// each field: present | absent (except sonar_project_key: string or 'absent')
The orchestrator holds this map only — no file content. Agents self-load their own context using the ## Before You Begin block in Step 6.
If a file in an agent's ## Before You Begin list is absent from the availability map, the agent omits it silently and proceeds. If a required item is absent, flag that agent as degraded: it notes the gap in its findings and the at-a-glance table shows ⚠️ degraded — <missing item>.
Step 4: Diff Collection
Noise Exclusion Constant
Define the following named constant before running any diff command. Every mode references this single list — never duplicate it:
EXCLUDE = [
':(exclude)*.lock' ':(exclude)package-lock.json' ':(exclude)yarn.lock'
':(exclude)pnpm-lock.yaml' ':(exclude)composer.lock' ':(exclude)Gemfile.lock'
':(exclude)go.sum' ':(exclude)Cargo.lock' ':(exclude)poetry.lock'
':(exclude)*.min.js' ':(exclude)*.min.css' ':(exclude)*.map'
':(exclude)**/__snapshots__/**' ':(exclude)dist/**' ':(exclude)build/**'
':(exclude)vendor/**' ':(exclude)node_modules/**' ':(exclude)*.generated.*'
]
Collect Diff
Collect the diff and file list based on the mode from Step 1, applying EXCLUDE to every git command:
| Mode | Commands |
|---|
| Local workspace | git diff HEAD -- $EXCLUDE, git diff --cached -- $EXCLUDE, git ls-files --others --exclude-standard |
| GitHub PR | GitHub MCP only — never use gh; filter the changed-file list to remove any path matching the EXCLUDE patterns before assembling the diff for agents |
| Multi-commit (hashes) | git show <h1> -- $EXCLUDE; git show <h2> -- $EXCLUDE; ... — concatenated in order |
| Multi-commit (range) | git diff <base>..<tip> -- $EXCLUDE |
| Performance Audit | No diff — full codebase scan (EXCLUDE does not apply) |
Also collect:
git diff --stat -- $EXCLUDE (or equivalent) — used in the report header- Changed file list (after EXCLUDE applied) — used in complexity assessment and routing
- Count of files excluded by EXCLUDE — stored as
excluded_count for the report header
- Multi-commit only:
git log --oneline <range> or resolved hash+subject list — used in report header
In all modes: skip deleted files and test files when building the changed file list. Noise files (lockfiles, generated, minified) are already absent because EXCLUDE was applied at the diff command level.
Step 4.5: Sonar Context Resolution
Run after Step 4 (diff file list is known) and before Step 5 (complexity assessment). Result is stored as sonar_context.
MCP tool: search_sonar_issues_in_projects (from the sonarqube MCP server)
IF sonar_project_key == 'absent':
sonar_context = { status: 'skipped', skip_reason: 'no project key found' }
GOTO Step 5
IF sonarqube MCP tools are unavailable in this session:
sonar_context = { status: 'skipped', skip_reason: 'MCP not installed' }
GOTO Step 5
ATTEMPT:
# For GitHub PR mode, pass pullRequest=<PR key> instead of branch
issues = search_sonar_issues_in_projects(
projects=[sonar_project_key],
branch=<current git branch>, # omit for PR mode; use pullRequest=<PR key>
issueStatuses=["OPEN"],
files=[sonar_project_key + ":" + f for f in diff_file_list]
)
security_issues = [i for i in issues where "SECURITY" in i.impactSoftwareQualities]
quality_issues = [i for i in issues where "RELIABILITY" or "MAINTAINABILITY" in i.impactSoftwareQualities]
sonar_context = {
status: 'active',
project_key: sonar_project_key,
branch: <current branch>,
issues_by_agent: {
security_reviewer: security_issues (sorted by severity desc, cap 30),
code_quality_reviewer: quality_issues (sorted by severity desc, cap 30)
},
summary: { total: N, security: N, quality: N }
}
ON server unreachable / connection error:
sonar_context = { status: 'skipped', skip_reason: 'server unreachable' }
ON MCP tool returns empty for this branch:
sonar_context = { status: 'skipped', skip_reason: 'no data for branch <branch> — run sonar-scanner first' }
ON timeout:
sonar_context = { status: 'skipped', skip_reason: 'query timeout' }
In every skipped state: proceed identically to pre-integration behavior. No agent receives a ## Sonar Findings block.
Step 5: Review Complexity Assessment
Using post-exclusion metrics from Step 4 (file count and diff lines after EXCLUDE applied), produce a Review Plan and print a complexity banner to the user before any review work begins.
Axis 1 — Size Tier → Execution Mode
Evaluate top-down, first match wins:
| Tier | Condition (post-exclusion) | Execution mode |
|---|
| Small | ≤5 files OR <200 diff lines | Inline — orchestrator reviews active dimensions directly, 0 agents |
| Medium | ≤15 files AND <800 diff lines | Single agent — 1 delegated subagent covers ALL active dimensions (1× diff) |
| Large | ≤25 files AND <1,500 diff lines | Parallel — 1 subagent per active dimension dispatched together (N× diff) |
| Complex | >25 files OR ≥1,500 diff lines | Parallel + completeness handling — same as Large, plus caveat and thoroughness directive |
Multi-commit mode: apply against combined diff totals across all commits.
Axis 2 — Content Type → Active Dimensions
Inspect the changed file list (after EXCLUDE) to determine content type. "ALL changed files" means 100% of the non-deleted, non-excluded list matches the pattern. A single source code file → general. Evaluation uses file names only — no file content is read.
| Content type | Detection | Active dimensions |
|---|
general (default) | Any source file present (*.ts, *.js, *.py, *.go, *.rb, *.java, *.php, *.cs, *.rs, *.kt, *.swift, *.c, *.cpp, *.h, etc.) | All 5 + requirements-tracer (conditional) |
docs-only | 100% match: *.md, *.txt, *.rst, *.mdx, docs/, README*, CHANGELOG*, *.adoc | code-quality-reviewer + requirements-tracer (conditional) |
config-infra-only | 100% match: *.yml, *.yaml, *.json, *.toml, Dockerfile*, *.tf, *.tfvars, .github/, *.env, *.ini, *.cfg, .eslintrc*, .prettier* | security-reviewer, code-quality-reviewer, regression-reviewer + requirements-tracer (conditional) |
frontend-assets-only | 100% match: *.css, *.scss, *.less, *.svg, *.png, *.jpg, *.gif, *.ico, *.woff*, *.ttf | code-quality-reviewer, security-reviewer + requirements-tracer (conditional) |
mixed | Multiple non-source types, no source files | Fall through to general |
Edge cases:
- Empty changed list (rename-only):
general, Small (0 files / 0 lines) → inline.
- Mixed source + docs:
general — the source file triggers full 5-dimension scope.
requirements-tracer is omitted regardless of type when requirements is absent (no spec/JIRA found in Step 2).
Review Plan
The assessment emits an explicit plan consumed by Step 6:
Review Plan:
Size tier: Small | Medium | Large | Complex
Content type: general | docs-only | config-infra-only | frontend-assets-only
Execution mode: inline | single-agent | parallel
Active dimensions: [<dimension list>]
Agents dispatched: 0 (inline) | 1 (single-agent) | N (parallel)
Complex handling: none | caveat + thoroughness directive
Excluded files: N
Complexity Banner
Immediately after the assessment, print this one-line banner to the user before any dispatch or inline review begins. This is required in every mode and every tier, including Small.
🔍 Code review — Complexity: **<Tier>** (<N> files, <M> lines[· <X> excluded]) · Type: <content_type> · <execution description>
Examples:
🔍 Code review — Complexity: **Complex** (32 files, 1,840 lines · 3 excluded) · Type: general · Parallel — 5 agents (⚠️ completeness caveat)
🔍 Code review — Complexity: **Medium** (9 files, 420 lines) · Type: general · Single agent — all 5 dimensions
🔍 Code review — Complexity: **Small** (2 files, 60 lines) · Type: docs-only · Inline review (Code Quality only)
Silent Operation
After the complexity banner, the skill produces no further output until the final consolidated report. Specifically prohibited between the banner and the report:
- Progress narration ("dispatching agents", "now reviewing…", "agent X returned")
- Partial or per-agent findings printed as they arrive
- Any intermediate analytical commentary
Step 6: Dispatch
Execute the Review Plan from Step 5. The execution mode determines how active dimensions run; the active dimension set (from content type) determines which agents/dimensions are in scope.
Execution Modes
Small — Inline (0 agents)
Apply the reviewer stance directly in the orchestrator across all active dimensions. No subagents. Proceed to Step 8 (Consolidation) when done.
Medium — Single Agent (1 agent, all active dimensions)
Dispatch one delegated subagent that covers ALL active dimensions in a single pass. The subagent's ## Before You Begin block lists the union of all active dimensions' checklists (deduplicated) plus the full codebase-doc set. The subagent returns findings tagged by dimension.
Large — Parallel (one agent per active dimension)
Fire all active dimension agents in a single parallel message. Never sequentially. Each receives its own ## Before You Begin block (targeted to its dimension) plus the full codebase-doc set.
Complex — Parallel + Completeness Handling
Same as Large. Additionally:
- Each dispatched agent receives the thoroughness directive (below) in its prompt.
- The report header (Step 8) carries the completeness caveat.
Thoroughness directive (Complex tier only — added to each agent's prompt):
This is a Complex review (large change set). Review every file in the diff thoroughly. Do not skip or skim any file. Focus on your assigned dimension across all changed files.
Agent Prompt Template
Every agent (in all modes except Small inline) receives a prompt structured as:
## Before You Begin
Read the following files before starting the review. Skip any file marked absent.
Checklists (load only if present per availability map):
- [list of this agent's assigned checklist files — see Checklist Matrix below]
Codebase docs (load each if present, from docs/codebase/):
- docs/codebase/STACK.md
- docs/codebase/ARCHITECTURE.md
- docs/codebase/CONVENTIONS.md
- docs/codebase/STRUCTURE.md
- docs/codebase/INTEGRATIONS.md
- docs/codebase/CONCERNS.md
## Role
<agent name and dimension — or "all active dimensions" for Medium single-agent>
## Diff
<full diff from Step 4>
## Sonar Findings
<inject this block ONLY when sonar_context.status == 'active' AND this agent has entries in sonar_context.issues_by_agent>
<omit this entire section — do not inject an empty block — when no issues are mapped to this agent>
SonarQube detected the following issues on branch `<branch>` in files within this diff.
Use as additional signal — they do not replace your analysis.
| Type | Severity | Rule | File | Line | Message |
|------|----------|------|------|------|---------|
<one row per issue from sonar_context.issues_by_agent[this_agent], sorted severity desc, max 30>
## Return format
Status: Complete | Blocked | Partial
Dimension: <agent name or "all dimensions">
Findings: [{severity, title, file, line, explanation, recommendation}]
Issues: <any blockers encountered>
The orchestrator does not inline any checklist or codebase-doc content — the ## Before You Begin block is a Read instruction for the agent, not pre-loaded content.
Checklist Matrix (agent → checklists to self-load)
| Agent | Checklists to load (if present) |
|---|
architecture-reviewer | review-checklist.md, clean-code-checklist.md, best-practices-code-review.md, observability-code-review.md, <stack>-*-code-review.md |
code-quality-reviewer | review-checklist.md, clean-code-checklist.md, best-practices-code-review.md, observability-code-review.md, <stack>-*-code-review.md |
performance-reviewer | performance-checklist.md, <stack>-*-performance-review.md |
regression-reviewer | review-checklist.md, clean-code-checklist.md, best-practices-code-review.md, observability-code-review.md, <stack>-*-code-review.md |
security-reviewer | None — relies on security-best-practices skill + built-in security knowledge |
requirements-tracer | None — uses requirements/spec file only; no codebase docs |
Codebase docs: all reviewing agents except requirements-tracer self-load the full set: STACK, ARCHITECTURE, CONVENTIONS, STRUCTURE, INTEGRATIONS, CONCERNS. TESTING.md is excluded (belongs to tests-code-review). All loads filtered to files present in the availability map.
Agent Roster
| Agent | Dimension | Degrades without |
|---|
architecture-reviewer | Layer violations, coupling, pattern misuse | architecture |
code-quality-reviewer | Naming, complexity, SOLID, DRY, KISS, clean code; inline docs, API docs, obsolete/misleading comments | conventions |
performance-reviewer | N+1, allocations, blocking calls, missing indexes | — |
regression-reviewer | Unrelated deletions, phantom imports, AI hallucination artifacts, weakened assertions | — |
security-reviewer | Auth, injection, secrets, data exposure | — |
requirements-tracer | Does the change satisfy the stated spec/task | Skip entirely if requirements absent — omit from at-a-glance table |
Reviewer Stance (injected into every agent)
You are the villain. Find every flaw, violation, and risk — not encourage.
- Be relentless. Code is guilty until proven innocent.
- Every principle violated is worth flagging — no "minor" issues.
- Flag issues even if possibly intentional — surface them regardless.
- State problems directly: file, line number, consequence.
- Never sign off on violations just because they are small.
- Only report a finding when confidence is ≥ 80%. If uncertain whether a pattern is a violation, skip it — do not guess.
Performance Audit mode exception
In Performance Audit mode: architecture-reviewer and performance-reviewer scan the full codebase. All other agents scope to changed files only. requirements-tracer is skipped. Complexity assessment (Step 5) is skipped — Performance Audit always uses parallel dispatch.
Agent: regression-reviewer
Dimension: Regression & Hallucination Detection
Review the diff for changes unrelated to the PR's stated purpose or showing signs of AI-generated artifacts:
- Phantom imports — references to symbols that do not exist in the codebase (🚨 Critical).
- Unrelated deletions — code removed with no connection to the stated change (🚨 Critical).
- Duplicate logic — functionality already present in the module, re-implemented.
- Weakened assertions — error handling, validation rules, or test assertions made less strict.
- Dead code — functions or branches introduced but never called.
TODO/FIXME in production — leftover markers not resolved before merge.- Type assertions hiding errors —
as any or forced casts masking real type errors.
Step 7: Await + Fallback
Wait for all dispatched agents to return. For each agent, resolve its outcome:
| Outcome | Action |
|---|
| Returned normally | Parse structured result |
| Failed or timed out | Mark dimension as ⚠️ not executed — <reason> |
| Degraded (missing required context) | Mark dimension as ⚠️ degraded — <missing item> |
requirements-tracer skipped (no spec/JIRA) | Omit row from at-a-glance table entirely |
Continue to Step 8 regardless of individual agent outcomes. A failed agent never blocks the report.
Step 8: Consolidation and Present Findings
The only user-facing outputs in this skill, in this order, are: (1) the skill-invocation announcement, (2) the complexity banner (from Step 5), and (3) this consolidated report. Nothing is emitted between the banner and this report.
Report header (always first)
# <TASK-ID or branch> — Code Review
Scope: <N files reviewed[, M excluded as generated/lockfiles]>
Branch: <branch>
Commits: <hash — subject>, <hash — subject>, ... ← multi-commit mode only
Diff: <N files changed, +X insertions, -Y deletions>
Run: <date>
Mode: local | GitHub PR #N | multi-commit | performance audit
Sonar: <status line — see variants below>
[Tier: <tier> | Type: <content_type>] ← omit when tier=Large/Complex AND type=general; show when type ≠ general OR tier ∈ {Large, Complex}
[⚠️ Complex review (N files / M lines) — findings are best-effort and may be non-exhaustive. Consider splitting this PR.] ← Complex tier only
Sonar status line variants:
| Condition | Status line |
|---|
| Active with issues | Sonar: active — N issues (S security, Q quality) · branch <branch> |
| Active, 0 issues | Sonar: active — 0 issues · branch <branch> |
| Skipped — no project key | Sonar: skipped — no project key found |
| Skipped — MCP not installed | Sonar: skipped — MCP not installed |
| Skipped — server unreachable | Sonar: skipped — server unreachable |
| No branch data | Sonar: no data for branch <branch> — run sonar-scanner first |
| Skipped — query timeout | Sonar: skipped — query timeout |
Include excluded_count in the Scope line whenever excluded_count > 0. Include the Tier/Type line whenever the content type is not general OR the tier is Large or Complex. Include the completeness caveat only when the tier is Complex.
At-a-glance table (always second)
One row per active dimension only — omit rows for dimensions not in the active set. Do not show "skipped" or "not executed" for inactive dimensions; their absence is intentional.
| Dimension | Status | Findings | Critical | High | Summary |
|---|
| Architecture | ✅ / ⚠️ degraded / ⚠️ not executed | N | N | N | 1-line |
| Code Quality & Docs | ... | N | N | N | 1-line |
| Performance | ... | N | N | N | 1-line |
| Regression & Hallucination | ✅ / ⚠️ degraded / ⚠️ not executed | N | N | N | 1-line |
| Security | ... | N | N | N | 1-line |
| Requirements | ✅ / ⚠️ (only if active spec/JIRA) | — | — | coverage summary | |
Show only the rows for active dimensions. For example, a docs-only review shows only Code Quality (and Requirements if active).
Output format
Flat format — use when findings are few and span a single dimension:
| # | Severity | Priority | Title | Type | File:Line | Explanation |
|---|
Zoned format — use when findings are many or span multiple dimensions (default for subagent reviews):
Agent dimensions map directly to zones. Zone letter assignment:
| Zone | Letter | Agent |
|---|
| Architecture | A | architecture-reviewer |
| Code Quality & Docs | Q | code-quality-reviewer |
| Performance | P | performance-reviewer |
| Regression & Hallucination | H | regression-reviewer |
| Requirements | R | requirements-tracer |
| Security | S | security-reviewer |
Finding IDs: <ZoneLetter><N> (e.g. A1, Q3, S2). All findings start as Open.
Legend:
✓ Fixed | ✓ Resolved (no change needed) | Tracked (moved to tech-debts) | Ignored (user-confirmed) | Pending (awaits decision) | Open (not triaged)
Per-zone section: ## Zone <Letter> — <Dimension> with findings table:
| # | Severity | Priority | Title | Type | File:Line | Status | Explanation |
|---|
At the very bottom: open/untriaged summary table — all findings with no disposition.
Severity: Critical, High, Medium, Low
Priority: P0 (must fix before merging), P1 (should fix soon), P2 (nice to have)
Type: Architecture, Code Quality, Documentation, Performance, Security, Tech Debt
Provide specific line numbers. Suggest concrete solutions. Keep explanations concise.
Markdown file output
When the user asks to save the review as a markdown file, always use the zoned format and write it
into the current feature's folder, co-located with the artifacts the tlc-spec-driven skill owns.
Resolve the destination in this order:
- Active TLC feature →
.specs/features/<TASK-ID>-<slug>/code-review.md
- No TLC feature folder → ask the user where to save it (default: the project root).
Match the changed files / TASK-ID to an existing directory under .specs/features/. If none exists, use the fallback. Use code-review_phase2.md (then _phase3, …) for subsequent passes.
Iterative review
After fixes:
- Update the table — mark fixed items with ✓
- Re-review only changed code
- Continue until all P0/P1 addressed
Step 9: Post to GitHub (GitHub PR mode only)
Load and apply GitHub PR Mode — Step B.
Performance Audit Report Format
Used only in Performance Audit mode.
Executive Summary
- Overall assessment (1–2 sentences)
- Count of critical issues
- Top-3 highest-impact fixes
P0 — Critical (fix immediately)
[ID] Title
Impact: <description>
Location: <File:Line>
Current: <what is happening>
Recommendation: <specific fix>
P1 — High Priority (fix soon)
P2 — Medium Priority (moderate improvement)
P3 — Low Priority (minor / best-practice)
Examples
Example 1: Local workspace review
User: "review my code"
- Step 1: No PR number, no commit refs → local workspace mode
- Step 2: Check presence of
docs/codebase/ docs and references/ checklists; check for active spec or JIRA task ID — build availability map (no content loaded by orchestrator)
- Step 3: Availability map ready (presence/absence only)
- Step 4:
git diff HEAD -- $EXCLUDE + git diff --cached -- $EXCLUDE + git ls-files --others --exclude-standard; collect git diff --stat -- $EXCLUDE; record excluded_count
- Step 5: Complexity assessment — emit Review Plan and complexity banner; route to execution mode (Small → inline, Medium → single agent, Large/Complex → parallel)
- Step 6: Dispatch per Review Plan (e.g. Medium: 1 agent covering all active dimensions; Large: N parallel agents); each agent self-loads checklists + codebase docs via
## Before You Begin
- Step 7: Await all results; mark any failures/degraded agents
- Step 8: Report header (with excluded count if any) → at-a-glance table (active dimensions only) → zoned findings; iterative review until P0/P1 resolved
Example 2: GitHub PR review
User: "review PR #42"
- Step 1: PR #42 → GitHub PR mode
- Step 2: Check presence of
docs/codebase/ docs and references/ checklists; check PR description for JIRA task ID — build availability map
- Step 3: Availability map ready
- Step 4: Fetch diff via GitHub MCP; filter changed-file list to remove EXCLUDE-matching paths; record
excluded_count
- Step 5: Complexity assessment — emit banner; route to execution mode
- Step 6: Dispatch per Review Plan execution mode against PR diff only — ignore local workspace; agents self-load context via
## Before You Begin
- Step 7: Await results
- Step 8: Consolidated report with at-a-glance table (active dimensions only)
- Step 9: User selects findings to post → create pending review comments via GitHub MCP; user submits manually on GitHub
Example 3: Performance audit
User: "do a performance audit of the orders module"
- Step 1: Trigger phrase matches → Performance Audit mode
- Step 2: Check presence of
docs/codebase/ docs and references/ checklists — build availability map
- Step 3: Availability map ready
- Step 4: No diff — full codebase scan (EXCLUDE does not apply)
- Step 5: Complexity assessment skipped — Performance Audit always uses parallel dispatch
- Step 6: Dispatch
architecture-reviewer and performance-reviewer against full codebase; regression-reviewer, security-reviewer, code-quality-reviewer scope to changed files only; requirements-tracer skipped; each agent self-loads via ## Before You Begin
- Step 7: Await results
- Step 8: Produce Performance Audit Report in the format above
Example 4: Multi-commit review
User: "review commits abc123 def456 ghi789"
- Step 1: Commit hashes detected → multi-commit mode
- Step 2: Check presence of
docs/codebase/ docs and references/ checklists; check commit messages for JIRA task IDs — build availability map
- Step 3: Availability map ready
- Step 4:
git show abc123 -- $EXCLUDE; git show def456 -- $EXCLUDE; git show ghi789 -- $EXCLUDE — concatenated into one combined diff; collect commit list (hash + subject) for report header; record excluded_count
- Step 5: Complexity assessment applied against combined diff totals; emit banner; route to execution mode
- Step 6: Dispatch per Review Plan execution mode against the combined diff; agents self-load context via
## Before You Begin
- Step 7: Await results
- Step 8: Single consolidated report — header lists all 3 commits and excluded count; at-a-glance table (active dimensions only) + findings as normal
