plan-review-gate

Name: plan-review-gate
Author: dsifry

361stars51forks

How to install plan-review-gate?

dsifry/metaswarm/plan-review-gate

$npx -y skills add dsifry/metaswarm --skill plan-review-gate

Installs into the current project.

Summary

Automatic adversarial review gate that spawns 3 independent reviewers in parallel after any plan is drafted - all must PASS before presenting to user

Files · 1

View on GitHub

SKILL.md

1	# Plan Review Gate
2
3	Core principle: No plan reaches the user without surviving independent adversarial scrutiny.
4
5	## Purpose
6
7	This skill automatically activates after any implementation plan is drafted, before presenting it to the user. It spawns three independent adversarial reviewers in parallel — Feasibility, Completeness, and Scope & Alignment — each as a fresh `Task()` instance. ALL three must PASS. On failure, the planner incorporates feedback and resubmits to entirely fresh reviewer instances. The gate iterates until consensus or max iterations.
8
9	---
10
11	## Activation Triggers
12
13	This skill auto-activates when:
14
15	1. An implementation plan is drafted (by planner, explorer, or orchestrator)
16	2. The `writing-plans` skill completes a plan
17	3. The orchestrator's plan validation phase produces a plan for review
18	4. User explicitly requests: `/plan-review <path-to-plan>`
19
20	Do NOT use for: Trivial changes (single-file bug fixes, copy edits, config tweaks). The plan must have at least 2 work units or touch 3+ files to warrant gate review.
21
22	---
23
24	## The 3 Adversarial Reviewers
25
26	Each reviewer is a fresh `Task()` instance with read-only access to the codebase. Reviewers produce binary PASS/FAIL verdicts backed by cited evidence. No suggestions — only findings.
27
28	### Reviewer 1: Feasibility
29
30	Can this plan actually be executed against the real codebase?
31
32	\| Check \| Classification \| Criteria \|
33	\| --- \| --- \| --- \|
34	\| File paths exist \| BLOCKING if fabricated \| Every file path referenced in the plan must exist (verify with glob/grep) \|
35	\| Dependency ordering correct \| BLOCKING if circular or forward-ref \| Work units depend only on things that exist or are created before them \|
36	\| Technical approach matches codebase \| BLOCKING if incompatible \| Proposed patterns, libraries, and conventions match what the codebase actually uses \|
37	\| No unstated assumptions \| BLOCKING if critical \| Plan does not silently depend on services, env vars, or infrastructure that doesn't exist \|
38	\| File scope realistic \| WARNING \| Each work unit's file scope is achievable without cascading changes \|
39
40	### Reviewer 2: Completeness
41
42	Does the plan fully address every aspect of the user's request?
43
44	\| Check \| Classification \| Criteria \|
45	\| --- \| --- \| --- \|
46	\| All requirements mapped \| BLOCKING if gap exists \| Every user requirement maps to at least one plan item \|
47	\| Verification steps defined \| BLOCKING if missing \| Each change has a way to verify it worked (test, manual check, or assertion) \|
48	\| Edge cases considered \| BLOCKING if obvious gaps \| Error scenarios, empty states, boundary conditions addressed \|
49	\| Rollback/backward compatibility \| WARNING \| Plan considers what happens if changes need to be reverted \|
50	\| Cross-file integration points \| BLOCKING if missing \| Files that import/depend on changed files are accounted for \|
51
52	### Reviewer 3: Scope & Alignment
53
54	Is the plan right-sized for what the user actually asked?
55
56	\| Check \| Classification \| Criteria \|
57	\| --- \| --- \| --- \|
58	\| Matches user request \| BLOCKING if divergent \| Plan solves what was asked, not what the planner finds interesting \|
59	\| No scope creep \| BLOCKING if present \| No unnecessary features, abstractions, or refactoring beyond the request \|
60	\| No under-scoping \| BLOCKING if present \| Obvious implications of the request are not omitted \|
61	\| Complexity proportional \| WARNING \| Solution complexity matches problem complexity \|
62	\| No simpler alternative missed \| WARNING \| Plan is not over-engineered when a simpler approach would suffice \|
63
64	---
65
66	## Reviewer Isolation Rules
67
68	These rules are mandatory. Violating any of them invalidates the review.
69
70	1. Fresh instances only. Each reviewer is a new `Task()` instance — never resumed, never given prior context.
71	2. No cross-reviewer visibility. No reviewer sees another reviewer's output. Ever.
72	3. Read-only codebase access. Reviewers can read files, run grep/glob, but cannot modify anything.
73	4. No prior review findings on re-review. When re-reviewing after iteration, completely fresh instances are spawned. The new reviewers have zero knowledge of what previous reviewers found.
74	5. Input is limited to: the plan text, the user's original request, and the codebase (via read-only tools).
75
76	Why isolation matters: Reviewers who see prior findings anchor on those findings instead of reviewing independently. Fresh instances prevent this bias and ensure each review cycle is a genuine independent check.
77
78	---
79
80	## Workflow
81
82	```text
83	1. Plan drafted by planner/explorer/orchestrator
84	2. Spawn 3 adversarial reviewers in PARALLEL (fresh Task() instances)
85	3. Collect all 3 verdicts
86	4. IF all PASS --> present pl

People who liked this also viewed

6 picks

Type

plan-review-gate

361stars51forks

View on GitHub

How to install plan-review-gate?

dsifry/metaswarm/plan-review-gate

$npx -y skills add dsifry/metaswarm --skill plan-review-gate

Installs into the current project.

Summary

Automatic adversarial review gate that spawns 3 independent reviewers in parallel after any plan is drafted - all must PASS before presenting to user

Files · 1

View on GitHub

SKILL.md

1	# Plan Review Gate
2
3	Core principle: No plan reaches the user without surviving independent adversarial scrutiny.
4
5	## Purpose
6
7	This skill automatically activates after any implementation plan is drafted, before presenting it to the user. It spawns three independent adversarial reviewers in parallel — Feasibility, Completeness, and Scope & Alignment — each as a fresh `Task()` instance. ALL three must PASS. On failure, the planner incorporates feedback and resubmits to entirely fresh reviewer instances. The gate iterates until consensus or max iterations.
8
9	---
10
11	## Activation Triggers
12
13	This skill auto-activates when:
14
15	1. An implementation plan is drafted (by planner, explorer, or orchestrator)
16	2. The `writing-plans` skill completes a plan
17	3. The orchestrator's plan validation phase produces a plan for review
18	4. User explicitly requests: `/plan-review <path-to-plan>`
19
20	Do NOT use for: Trivial changes (single-file bug fixes, copy edits, config tweaks). The plan must have at least 2 work units or touch 3+ files to warrant gate review.
21
22	---
23
24	## The 3 Adversarial Reviewers
25
26	Each reviewer is a fresh `Task()` instance with read-only access to the codebase. Reviewers produce binary PASS/FAIL verdicts backed by cited evidence. No suggestions — only findings.
27
28	### Reviewer 1: Feasibility
29
30	Can this plan actually be executed against the real codebase?
31
32	\| Check \| Classification \| Criteria \|
33	\| --- \| --- \| --- \|
34	\| File paths exist \| BLOCKING if fabricated \| Every file path referenced in the plan must exist (verify with glob/grep) \|
35	\| Dependency ordering correct \| BLOCKING if circular or forward-ref \| Work units depend only on things that exist or are created before them \|
36	\| Technical approach matches codebase \| BLOCKING if incompatible \| Proposed patterns, libraries, and conventions match what the codebase actually uses \|
37	\| No unstated assumptions \| BLOCKING if critical \| Plan does not silently depend on services, env vars, or infrastructure that doesn't exist \|
38	\| File scope realistic \| WARNING \| Each work unit's file scope is achievable without cascading changes \|
39
40	### Reviewer 2: Completeness
41
42	Does the plan fully address every aspect of the user's request?
43
44	\| Check \| Classification \| Criteria \|
45	\| --- \| --- \| --- \|
46	\| All requirements mapped \| BLOCKING if gap exists \| Every user requirement maps to at least one plan item \|
47	\| Verification steps defined \| BLOCKING if missing \| Each change has a way to verify it worked (test, manual check, or assertion) \|
48	\| Edge cases considered \| BLOCKING if obvious gaps \| Error scenarios, empty states, boundary conditions addressed \|
49	\| Rollback/backward compatibility \| WARNING \| Plan considers what happens if changes need to be reverted \|
50	\| Cross-file integration points \| BLOCKING if missing \| Files that import/depend on changed files are accounted for \|
51
52	### Reviewer 3: Scope & Alignment
53
54	Is the plan right-sized for what the user actually asked?
55
56	\| Check \| Classification \| Criteria \|
57	\| --- \| --- \| --- \|
58	\| Matches user request \| BLOCKING if divergent \| Plan solves what was asked, not what the planner finds interesting \|
59	\| No scope creep \| BLOCKING if present \| No unnecessary features, abstractions, or refactoring beyond the request \|
60	\| No under-scoping \| BLOCKING if present \| Obvious implications of the request are not omitted \|
61	\| Complexity proportional \| WARNING \| Solution complexity matches problem complexity \|
62	\| No simpler alternative missed \| WARNING \| Plan is not over-engineered when a simpler approach would suffice \|
63
64	---
65
66	## Reviewer Isolation Rules
67
68	These rules are mandatory. Violating any of them invalidates the review.
69
70	1. Fresh instances only. Each reviewer is a new `Task()` instance — never resumed, never given prior context.
71	2. No cross-reviewer visibility. No reviewer sees another reviewer's output. Ever.
72	3. Read-only codebase access. Reviewers can read files, run grep/glob, but cannot modify anything.
73	4. No prior review findings on re-review. When re-reviewing after iteration, completely fresh instances are spawned. The new reviewers have zero knowledge of what previous reviewers found.
74	5. Input is limited to: the plan text, the user's original request, and the codebase (via read-only tools).
75
76	Why isolation matters: Reviewers who see prior findings anchor on those findings instead of reviewing independently. Fresh instances prevent this bias and ensure each review cycle is a genuine independent check.
77
78	---
79
80	## Workflow
81
82	```text
83	1. Plan drafted by planner/explorer/orchestrator
84	2. Spawn 3 adversarial reviewers in PARALLEL (fresh Task() instances)
85	3. Collect all 3 verdicts
86	4. IF all PASS --> present pl

People who liked this also viewed

6 picks

Type