Skip to content
Back to skills

Per Task Review Cycle

ASecurity

Implement → spec review → quality review → targeted fix → re-review cycle for multi-task subagent development. Use when executing an implementation plan where each task needs independent verification before moving to the next.

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 1, 2026
ai-agentsgit

Security analysis

A100/100

Scanned October 1, 2026

npx -y skills add williamblair333/Uncle-J-s-Refinery --skill per-task-review-cycle --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Per Task Review Cycle?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Per Task Review Cycle
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/williamblair333-per-task-review-cycle/badge)](https://www.skillsdirectory.com/skills/williamblair333-per-task-review-cycle)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: per-task-review-cycle
description: Implement → spec review → quality review → targeted fix → re-review cycle for multi-task subagent development. Use when executing an implementation plan where each task needs independent verification before moving to the next.
type: process
---

# Per-Task Review Cycle

Use this within a `superpowers:subagent-driven-development` session when tasks have verifiable specs and code quality standards that must be confirmed before merging.

## When to use

- Executing a multi-task plan where each task has a written spec
- Each task produces a standalone file or feature (not deeply interleaved)
- You want to catch issues per task rather than at the end

## Cycle per task

implementer subagent
    → spec reviewer subagent       (parallel if independent)
    → quality reviewer subagent    (parallel if independent)
    → [if issues] targeted fixer subagent
    → re-review only the fixed portions
    → APPROVED → next task

Run spec and quality reviews **in parallel** after implementation completes — they're independent reads.

## Override protocol

When a reviewer flags something that is **architecturally correct by contract** (e.g., `trap 'exit 0' ERR` in a Stop hook, intentional silent exit, framework-mandated behavior):

1. Identify the specific reviewer error (wrong lens, wrong contract model)
2. State the correct invariant explicitly
3. Override to APPROVED with documented rationale
4. Do not dispatch a fix for correct code

## Final integration review

After all tasks complete, run one cross-task review subagent scoped to the full diff. Catches:
- Duplicate flags or args across files
- Inconsistent PATH/env injection patterns
- Missing error propagation contracts

## Checklist

- [ ] Implementer dispatched
- [ ] Spec + quality reviews run (in parallel)
- [ ] Issues triaged: real fix vs. reviewer error
- [ ] Targeted fixer dispatched for real issues only
- [ ] Re-review confirms fixes
- [ ] Task marked APPROVED
- [ ] Final cross-task review after all tasks done
- [ ] Changelog written from meaningful commits

## Key signals for reviewer override

| Reviewer claim | Real situation | Override? |
|---|---|---|
| "Missing error handling" | Stop hook must exit 0 on all paths | Yes |
| "Source path wrong" | Reviewer assumed wrong lib file | Yes — grep to confirm |
| "Executable bit missing" | `100755` confirmed in git | Yes |
| "Duplicate flag" | Actually distinct flags (`-p` vs `--print`) | No — real bug |

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.