---
name: Review Automation Orchestrator
slug: review-automation-orchestrator
category: Automation
description: Review Automation Orchestrator routes recurring repository reviews to the right specialized checks, then normalizes and escalates findings into reports, issues, or small corrective PRs. Use it when you need one coordinated review cycle across API contracts, docs freshness, code quality, and skill quality.
github: "https://github.com/TencentCloudBase/CloudBase-AI-Toolkit/tree/main/skills/review-automation-orchestrator"
language: TypeScript
stars: 1074
forks: 134
install: "npx degit https://github.com/TencentCloudBase/CloudBase-AI-Toolkit/tree/main/skills/review-automation-orchestrator ~/.claude/skills/review-automation-orchestrator"
installs_to: ~/.claude/skills/review-automation-orchestrator
source_path: skills/review-automation-orchestrator/SKILL.md
collection_size: 25
category_size: 1523
collection_url: "https://dirskills.com/collections/TencentCloudBase/CloudBase-AI-Toolkit"
added: 2026-08-21T05:13:33.840Z
last_synced: 2026-08-21T05:13:33.840Z
canonical_url: "https://dirskills.com/skills/review-automation-orchestrator"
---

# Review Automation Orchestrator

Review Automation Orchestrator routes recurring repository reviews to the right specialized checks, then normalizes and escalates findings into reports, issues, or small corrective PRs. Use it when you need one coordinated review cycle across API contracts, docs freshness, code quality, and skill quality.

**Install:**

```bash
npx degit https://github.com/TencentCloudBase/CloudBase-AI-Toolkit/tree/main/skills/review-automation-orchestrator ~/.claude/skills/review-automation-orchestrator
```

## README

# 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

| 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

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?