plan-review-gate
Scannednpx machina-cli add skill a5c-ai/babysitter/plan-review-gate --openclawPlan Review Gate
Overview
Three independent adversarial reviewers validate any implementation plan before it is presented to the user. Each reviews independently with no shared context.
When to Use
- After the Architect creates an implementation plan
- Before presenting a plan for user approval
- When validating work unit decomposition quality
Process
- Feasibility Reviewer - Can this plan actually be implemented? Technical viability, resource requirements, timeline reality
- Completeness Reviewer - Does the plan cover everything? Missing edge cases, untested paths, incomplete DoD items
- Scope & Alignment Reviewer - Does the plan match the issue? Scope creep detection, requirement traceability
All 3 must PASS before the plan is presented.
Key Rules
- Reviewers operate independently (no shared context)
- Each provides a binary PASS/FAIL verdict
- Findings include specific references to plan sections
- Failed plans require revision before re-review
Tool Use
Invoke as part of: methodologies/metaswarm/metaswarm-orchestrator (Phase 1b)
Source
git clone https://github.com/a5c-ai/babysitter/blob/main/plugins/babysitter/skills/babysit/process/methodologies/metaswarm/skills/plan-review-gate/SKILL.mdView on GitHub Overview
Three independent adversarial reviewers validate any implementation plan before it is presented to the user. Feasibility, Completeness, and Scope & Alignment assess technical viability, coverage, and alignment with the issue, with no shared context among reviewers. All three must PASS before presenting the plan.
How This Skill Works
An Architect creates an implementation plan. Three reviewers—Feasibility, Completeness, Scope & Alignment—evaluate independently and return a binary PASS or FAIL with references to specific plan sections. If any reviewer fails, the plan is revised and re reviewed; the process is invoked as part of methodologies/metaswarm/metaswarm-orchestrator (Phase 1b) and only passes when all three verdicts are PASS.
When to Use It
- After the Architect creates an implementation plan
- Before presenting a plan for user approval
- When validating work unit decomposition quality
- When edge cases, untested paths, or incomplete DoD items are suspected
- During revision rounds after a failure to re validate
Quick Start
- Step 1: Initiate the gate via methodologies/metaswarm/metaswarm-orchestrator Phase 1b
- Step 2: Each reviewer returns PASS or FAIL with section references
- Step 3: If all PASS, present the plan to the user; otherwise revise and re run the gate
Best Practices
- Ensure reviewers have no shared context to preserve adversarial independence
- Require explicit binary PASS or FAIL with direct references to plan sections
- Document and locate findings to specific sections of the plan
- Use the DoD and issue scope to guide evaluation and traceability
- Retain a record of the final PASS verdict and re review triggers
Example Use Cases
- Architecture teams gate plans before large deployments
- Edge cases and untested paths are flagged for post review
- Plans spanning multiple subsystems undergo independent validation
- Compliance heavy projects require formal traceability of findings
- Critical path and resource constraint checks are verified before user presentation