Review Automation Orchestrator

Review Automation Orchestrator

Coordinate recurring repository review work without turning one skill into every reviewer at once.

When to use this skill

Use this skill when you need to:

• Run a periodic repository review across several quality dimensions
• Decide which specialized review skill should own each finding type
• Aggregate review results into one report with clear escalation
• Convert high-confidence, low-risk findings into corrective PRs when feasible
• Configure or run a scheduled review cycle without duplicating the underlying reviewer logic

Do NOT use for:

• Acting as the primary reviewer for API contracts, docs, or code quality by itself
• Replacing the existing CloudBase skill review flow under skill-authoring
• Fixing a single known issue without a broader review cycle
• Merging PRs or making final release decisions

Workflow

Phase 1 — Define the run

1. Clarify whether the run is one-time or periodic. 2. Define the review surfaces and target outputs:

• report only
• issue + report
• fix + PR

3. Read references/escalation-matrix.md before dispatching work.

Phase 2 — Dispatch to the right reviewer

Route by finding type, not by convenience:

• CloudBase API contract correctness → api-contract-review
• Published docs and README drift → doc-freshness-review
• Broad code hygiene and proactive repository health → codebase-audit
• Existing open PR triage and repair → pr-review-fix
• CloudBase source skill quality under config/source/skills → skill-authoring, then load references/repo-skill-review.md and references/cloudbase-skill-review.md

Do not create a redundant top-level CloudBase skill reviewer when the existing skill-authoring flow already covers it.

Phase 3 — Normalize findings

1. Deduplicate overlaps between reviewers. 2. Normalize each finding with:

• scope
• severity
• confidence
• smallest useful fix batch
• recommended action from the escalation matrix

3. Keep reports readable: separate API, docs, code, and skill findings.

Phase 4 — Escalate

1. Use report only for lower-confidence or lower-impact findings. 2. Use issue + report for confirmed but broader or riskier problems. 3. Use fix + PR when the finding is confirmed, mechanically fixable, and small enough for a focused review. 4. Prefer concrete PRs over issue-only churn when the path is already clear and low-risk.

Phase 5 — Scheduling discipline

1. If the user asks for recurrence, create automation that runs the review cycle and stores the task prompt separately from schedule details. 2. Keep the scheduled prompt short and routing-focused. 3. Do not duplicate reviewer checklists inside the automation definition.

Routing

Evaluation prompts

Should-trigger

1. Run a weekly repository review that checks CloudBase API contracts, docs freshness, and skill quality, then decide what should become PRs. 2. Help me set up a periodic review flow that routes findings to the right reviewer and escalates only the high-confidence fixes. 3. Aggregate findings from code, docs, and CloudBase skill review into one actionable maintenance report.

Should-not-trigger

1. Review this one MCP tool for parameter casing errors. 2. Audit doc/ for stale links and missing files. 3. Rewrite a CloudBase source skill description to improve its trigger wording.

Minimum self-check

• Did I dispatch each finding class to the correct specialized reviewer?
• Did I reuse skill-authoring for CloudBase skill review instead of inventing a duplicate flow?
• Did I normalize findings by severity, confidence, and smallest useful fix batch?
• Did I choose report, issue, or PR based on evidence rather than habit?
• If the run is periodic, did I keep the automation prompt focused on routing instead of embedding whole checklists?

Review Escalation Matrix

Purpose

Use this matrix to decide whether a periodic review finding should stay in a report, become an issue, or be fixed in a PR.

Decision matrix

Heuristics

report only

Use this when:

• the evidence is incomplete
• the product contract is still unclear
• the reviewer can see drift but cannot prove the correct replacement yet

issue + report

Use this when:

• the finding is confirmed
• the repair spans several modules or needs human coordination
• the change could alter public behavior or compatibility

fix + PR

Use this when:

• the finding is confirmed
• the fix is small, focused, and reviewable
• the reviewer can update code, tests, or docs without guessing
• the PR is more useful than creating another tracking issue

Bias for action

Routine findings should go to reports. Higher-value, high-confidence, low-risk findings should go beyond issue churn toward a concrete PR when feasible.