plan-judge

Evaluates implementation plans for readiness and outputs schema-conforming JSON verdicts.

9|Updated Jun 10, 2026
One-click install
npx skills add https://github.com/eventbalancer/agent-quorum --skill plan-judge-eventbalancer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: plan-judge
Source: https://github.com/eventbalancer/agent-quorum/tree/main/skills/plan-judge
Command: npx skills add https://github.com/eventbalancer/agent-quorum --skill plan-judge-eventbalancer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? A single-pass plan review tends to rubber-stamp incomplete work: vague file references, missing acceptance gates, and unresolved design questions slip through. This Skill acts as an adversarial judge in the agent-quorum plan-refinement loop, independently deciding whether a plan is truly implementation-ready before a coding agent executes it. ## Core Features & Use Cases - Readiness verdicts: Returns a strict JSON verdict (ready true/false) conforming to readiness.schema.json, with no prose or markdown fences. - Invariant coverage accounting: Assesses every active invariant and retained occurrence exactly once with grounded evidence references, deriving coverage_complete and unresolved_occurrence_ids from exact accounting. - Scoped evaluation: Handles both intermediate revisions (with a single fixable revision_issue) and final canonical plans (independent verification where critique is advisory only). - Use Case: In a multi-agent plan → critique → update loop, run the judge after each revision to decide whether the exact plan revision has concrete file lists, per-phase acceptance gates, and no open blocker or major concerns before execution begins. ## Quick Start Evaluate this implementation plan for readiness and return the JSON verdict conforming to readiness.schema.json.

Frequently Asked Questions about plan-judge

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate whether an implementation plan is ready for execution?

Submit the plan with its critique context and retained invariants to the judge, which checks concrete file lists, per-phase acceptance gates, open blockers, and ambiguous design gaps. It returns ready: true only when all conditions hold, otherwise ready: false with a rationale.

What output format does the plan readiness evaluation produce?

The output is JSON only, conforming to readiness.schema.json, with fields ready, rationale, revision_issue, coverage_complete, unresolved_occurrence_ids, and invariant_assessments. No markdown fences or prose are allowed outside the JSON.

What is the difference between intermediate and final scope evaluation?

For intermediate scope the critique is current and a negative verdict may include one fixable revision_issue. For final scope the plan is the authoritative post-fix artifact, the critique is advisory only, and revision_issue is always null.

When should a revision_issue be included in the verdict?

Include it only for intermediate scope when a concrete blocker or major gap caused the negative verdict and the creator can fix it within the frozen boundary. It must include severity, category, claim, evidence, typed evidence_refs, and suggested_fix; otherwise set it to null.

Why does the judge reject plans even when the critic found no issues?

The critique covers logical issues, not completeness. The judge independently verifies coverage of every invariant and occurrence, so a plan with open gaps or unverifiable references still returns ready: false under the anti-rubber-stamp rule.