Run any Skill in Manus with one click

review-chain

Stars1

Forks0

UpdatedJune 3, 2026 at 18:28

Design reviewer order, approval gates, and separation-of-duties rules for agent-generated work. Use when the user asks who should review an implementation, how to set up multi-agent review, when human approval is required, or how to keep coding, security, QA, architecture, and release checks distinct.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

kas1987

kas1987/Chromatic_Governance

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	review-chain
description	Design reviewer order, approval gates, and separation-of-duties rules for agent-generated work. Use when the user asks who should review an implementation, how to set up multi-agent review, when human approval is required, or how to keep coding, security, QA, architecture, and release checks distinct.

Review Chain

Ensure important work is reviewed by the right specialists before merge, release, or external action.

Core procedure

Classify the change by risk: low, medium, high, critical.
Determine required review lanes: implementation, architecture, security, QA/eval, docs, release, observability, product.
Enforce separation of duties for high-risk work: implementer cannot be the only approver.
Order reviews so blockers are found early: architecture/security before large implementation, QA before release, docs before handoff.
Define required evidence for approval: diffs, tests, commands, screenshots, logs, metrics, risk register, rollback path.
State merge/release criteria and human approval triggers.

Output format

Produce a concise, auditable markdown artifact. Include:

## Review Chain

**Scope:** ...
**Decision / recommendation:** ...
**Risk level:** low / medium / high / critical

### Findings
- ...

### Plan / matrix / record
| Item | Owner | Scope | Evidence | Gate / next action |
|---|---|---|---|---|

### Escalations
- ...

### Next actions
1. ...

Expected output focus: review chain table with stage, reviewer, evidence required, pass criteria, fail action, human approval trigger.

Guardrails

Prefer the narrowest capable agent and least authority required.
Do not let an agent approve its own high-risk work.
Mark assumptions separately from confirmed facts.
Require human approval for destructive, credentialed, production, external, legal, financial, or security-sensitive actions.
Do not invent agent capabilities; use the roster, plugin manifests, source files, and explicit user instructions.

Related references

references/review-chain-template.md
references/risk-tier-model.md
references/authority-model.md

More from this repository

same repository

visual-design

kas1987/Chromatic_Governance

Interactive front-end design companion — iterate on layouts, live component previews, and design tokens in a real browser, then hand the validated design to the frontend-family implement skills. Use when the user wants to design or refine UI look-and-feel, compare layout/wireframe options, preview real components, or tune color/spacing/typography before building.

2026-06-051

repo-pdr-swarm-router

kas1987/Chromatic_Governance

Ingest, decompose, govern, and route large repository PDR packages into agent-routable work queues with manifests, decision registers, risk registers, governance gates, and swarm-ready handoff packets. Use when the user provides repo PDR packages, audit bundles, project design records, implementation plans, backlog packs, or governance artifacts and wants them parsed, scored, split into agent assignments, and dispatched through the Chromatic router.

2026-06-041

cognitive-stack-architect

kas1987/Chromatic_Governance

Triage scattered, nonlinear, or overloaded thinking into a structured stack of decisions, priorities, and handoffs. Use when the project feels ambiguous, when too many threads are running in parallel, when you cannot determine what to work on next, or when a session has accumulated more open questions than resolved ones.

2026-06-041

repo-tree-architect

kas1987/Chromatic_Governance

Audit and redesign a repository's folder structure, root hygiene, scattered files, and naming conventions. Use when the repo root is cluttered, directories have grown organically without governance, files are misplaced across boundaries, or you need a clean canonical tree before onboarding agents or contributors.

2026-06-041

tree-repo-auditor

kas1987/Chromatic_Governance

Enforce numbered folder and subfolder naming standards across a repository. Audit whether directories follow an established numeric prefix convention (e.g. .01_, .02_, 01-, 1.) and produce a compliance report with remediation steps. Use when repo directories have grown without consistent naming, when onboarding contributors, or before a structural refactor.

2026-06-041

github-org-governance-manager

kas1987/Chromatic_Governance

Plan, audit, and standardize GitHub organization and repository governance — including personal-to-org repo transfers, branch protection, rulesets, team permissions, labels, repository settings, secrets review, and post-transfer validation. Use when moving repos into an organization, auditing existing permissions, generating settings checklists, or producing migration runbooks.

2026-06-041

name	review-chain
description	Design reviewer order, approval gates, and separation-of-duties rules for agent-generated work. Use when the user asks who should review an implementation, how to set up multi-agent review, when human approval is required, or how to keep coding, security, QA, architecture, and release checks distinct.

Review Chain

Ensure important work is reviewed by the right specialists before merge, release, or external action.

Core procedure

Classify the change by risk: low, medium, high, critical.
Determine required review lanes: implementation, architecture, security, QA/eval, docs, release, observability, product.
Enforce separation of duties for high-risk work: implementer cannot be the only approver.
Order reviews so blockers are found early: architecture/security before large implementation, QA before release, docs before handoff.
Define required evidence for approval: diffs, tests, commands, screenshots, logs, metrics, risk register, rollback path.
State merge/release criteria and human approval triggers.

Output format

Produce a concise, auditable markdown artifact. Include:

## Review Chain

**Scope:** ...
**Decision / recommendation:** ...
**Risk level:** low / medium / high / critical

### Findings
- ...

### Plan / matrix / record
| Item | Owner | Scope | Evidence | Gate / next action |
|---|---|---|---|---|

### Escalations
- ...

### Next actions
1. ...

Expected output focus: review chain table with stage, reviewer, evidence required, pass criteria, fail action, human approval trigger.

Guardrails

Prefer the narrowest capable agent and least authority required.
Do not let an agent approve its own high-risk work.
Mark assumptions separately from confirmed facts.
Require human approval for destructive, credentialed, production, external, legal, financial, or security-sensitive actions.
Do not invent agent capabilities; use the roster, plugin manifests, source files, and explicit user instructions.

Related references

references/review-chain-template.md
references/risk-tier-model.md
references/authority-model.md