run-review

/run-review

Lists all reviews with status = 'pending' and guides the reviewer agent through recording an approval or rejection for each one.

When to use

Run /run-review to process the current review backlog — either after a build cycle or on demand to unblock downstream tasks.

Steps

1. Load pending reviews — call read_reviews (no filters) and filter client-side for rows where status = 'pending'. If there are none, report "No pending reviews." and stop.

2. For each pending review:

   a. Call read_tasks with the review's task_id to load the task context (title, task_type, status).

   b. Present the review to the user:

   • Task ID, title, and task_type
   • Review ID
   • Any existing notes

   c. Ask the user (or apply automated criteria) for a decision: approve or reject.

   d. If approving — call update_review with:

   • status = 'approved'
   • notes: a brief rationale for approval

   e. If rejecting — call update_review with:

   • status = 'rejected'
   • notes: clear feedback explaining what needs to change

   f. The server sets reviewed_at automatically on approved or rejected — do not attempt to set it.

3. After all reviews — report a summary table:

   • Review ID | Task title | Decision | reviewed_at

Notes

• Process reviews one at a time. Do not batch-approve without user confirmation.
• If a rejected task needs rework, suggest updating its status to 'blocked' or 'in_progress' using the Builder or Tester agent.
• reviewed_at is set by the MCP server — never pass it as an argument to update_review.