Run any Skill in Manus with one click

reviewer-runner

Stars7

Forks1

UpdatedJune 7, 2026 at 01:17

Review a diff against a task's success criteria. Use when: a `task_assignment` for role `reviewer` lands; you need to lint, summarize a diff, or produce structured review comments.

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

zhiming-dev

zhiming-dev/Roster

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	reviewer-runner
description	Review a diff against a task's success criteria. Use when: a `task_assignment` for role `reviewer` lands; you need to lint, summarize a diff, or produce structured review comments.
argument-hint	Path to the task_assignment message; the message payload should reference the diff path.

Reviewer Runner

When to Use

The Planner dispatches a task_assignment for role reviewer.
An upstream task has produced a diff artifact and a successCriteria to review against.

Prerequisites

Read reviewer.agent.md.
Read shared/approval-gate/SKILL.md and shared/provenance/SKILL.md.

Procedure

Read the task + upstream diff. Confirm assigneeRole === "reviewer" and the inputs.diffPath points at an existing artifact.
Emit task_started.
Run linters appropriate for the changed files (eslint, ruff, golangci-lint, etc.). Capture output under runs/<runId>/artifacts/<task-id>/lint.log.
Read the diff and judge each hunk against the upstream task's successCriteria.
Write the review at runs/<runId>/artifacts/<task-id>/review.md with two sections:
- Blocking — criterion violations, correctness bugs, security issues, missing tests for a behavior change. Each item cites file:line and the criterion it violates.
- Non-blocking — style, naming, suggestions. Do not gate on these.
Post the review as PR comments (comment:pr capability) if the diff is a real PR. Otherwise the artifact is the deliverable.
Write the TaskResult:
- success if Blocking is empty and lint is clean.
- partial if lint has warnings but no errors and no Blocking items.
- failure if any Blocking item or any lint error.
Emit task_result and message the Planner.

Anti-patterns

"Approving with one nit" but listing five style preferences as Blocking. Be honest about what is and isn't a gate.
Reviewing for what you wish the task were instead of for the success criteria the principal ratified. If the criteria are wrong, surface that as a message to the Planner — do not fail the diff for not matching your imagined criteria.
Modifying the diff. Reviewer never writes source. If a fix is small and obvious, propose it in a comment; do not commit it yourself.

Status

🚧 Scaffold.

More from this repository

same repository

qa-runner

zhiming-dev/Roster

Validate and fact-check another agent's output against evidence and the task's success criteria. Use when: verifying a report, fact-checking claims, cross-checking research findings, confirming a result meets its criteria. Not for browser/E2E testing (see e2e-runner).

2026-07-137

researcher-runner

zhiming-dev/Roster

Procedure the Researcher agent follows to answer a question with web search + page fetch: plan queries, search, open the promising pages, cross-check, and return a source-cited synthesis. Use when a task needs current or external facts.

2026-07-137

example-skill

zhiming-dev/Roster

Example skill scaffold. Replace this with a real, project-specific procedural playbook. The description must clearly state WHEN to use the skill (trigger phrases and scope) so the model can match it to user intent. USE FOR: <list the situations this skill applies to>. DO NOT USE FOR: <list out-of-scope situations and point to the right skill>.

2026-06-267

planner-runner

zhiming-dev/Roster

The Planner's operating procedure. Use when: turning a principal goal into a Plan; revising a plan after rejection; dispatching ratified tasks; supervising sub-agent results; deciding whether to convene the Council; finalizing a run.

2026-06-077

approval-gate

zhiming-dev/Roster

Classify a proposed action's risk tier (T0–T4), apply the gate policy, and (if required) summarize the proposal into a human-reviewable approval request. Use whenever an agent is about to perform an action that touches anything outside its own scratch state.

2026-06-077

provenance

zhiming-dev/Roster

Append a structured event to the run's provenance log. Every agent calls this for every meaningful state transition (plan drafted, task dispatched, action proposed/executed, approval decided, etc.) so the run is fully replayable and auditable.

2026-06-077

Reviewer Runner

When to Use

The Planner dispatches a task_assignment for role reviewer.

An upstream task has produced a diff artifact and a successCriteria to review against.

Prerequisites

Procedure

Read the task + upstream diff. Confirm assigneeRole === "reviewer" and the inputs.diffPath points at an existing artifact.

Emit task_started.

Run linters appropriate for the changed files (eslint, ruff, golangci-lint, etc.). Capture output under runs/<runId>/artifacts/<task-id>/lint.log.

Read the diff and judge each hunk against the upstream task's successCriteria.

Write the review at runs/<runId>/artifacts/<task-id>/review.md with two sections:

Blocking — criterion violations, correctness bugs, security issues, missing tests for a behavior change. Each item cites file:line and the criterion it violates.
Non-blocking — style, naming, suggestions. Do not gate on these.

Post the review as PR comments (comment:pr capability) if the diff is a real PR. Otherwise the artifact is the deliverable.

Write the TaskResult:

success if Blocking is empty and lint is clean.
partial if lint has warnings but no errors and no Blocking items.
failure if any Blocking item or any lint error.

Emit task_result and message the Planner.

Anti-patterns

"Approving with one nit" but listing five style preferences as Blocking. Be honest about what is and isn't a gate.

Reviewing for what you wish the task were instead of for the success criteria the principal ratified. If the criteria are wrong, surface that as a message to the Planner — do not fail the diff for not matching your imagined criteria.

Modifying the diff. Reviewer never writes source. If a fix is small and obvious, propose it in a comment; do not commit it yourself.

Status

🚧 Scaffold.