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
- Clarify whether the run is one-time or periodic.
- Define the review surfaces and target outputs:
- report only
- issue + report
- fix + PR
- Read
references/escalation-matrix.mdbefore 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 loadreferences/repo-skill-review.mdandreferences/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
- Deduplicate overlaps between reviewers.
- Normalize each finding with:
- scope
- severity
- confidence
- smallest useful fix batch
- recommended action from the escalation matrix
- Keep reports readable: separate API, docs, code, and skill findings.
Phase 4 — Escalate
- Use
report onlyfor lower-confidence or lower-impact findings. - Use
issue + reportfor confirmed but broader or riskier problems. - Use
fix + PRwhen the finding is confirmed, mechanically fixable, and small enough for a focused review. - Prefer concrete PRs over issue-only churn when the path is already clear and low-risk.
Phase 5 — Scheduling discipline
- If the user asks for recurrence, create automation that runs the review cycle and stores the task prompt separately from schedule details.
- Keep the scheduled prompt short and routing-focused.
- Do not duplicate reviewer checklists inside the automation definition.
Routing
| Task | Read |
| --- | --- |
| Decide escalation from severity and confidence | references/escalation-matrix.md |
| Review CloudBase API contract correctness | api-contract-review |
| Review doc and README drift | doc-freshness-review |
| Run broad repository code review | codebase-audit |
| Repair existing PRs after review | pr-review-fix |
| Review CloudBase source skills | skill-authoring |
Evaluation prompts
Should-trigger
- Run a weekly repository review that checks CloudBase API contracts, docs freshness, and skill quality, then decide what should become PRs.
- Help me set up a periodic review flow that routes findings to the right reviewer and escalates only the high-confidence fixes.
- Aggregate findings from code, docs, and CloudBase skill review into one actionable maintenance report.
Should-not-trigger
- Review this one MCP tool for parameter casing errors.
- Audit
doc/for stale links and missing files. - 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-authoringfor 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?