How do I install the Plan Check skill?

Run npx skillmds@latest add vasuag09/plan-check in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Plan Check safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Plan Check?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Plan Check free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Plan Check?

vasuag09 (@vasuag09) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Plan Check by vasuag09 — Agent Skill

Name: Plan Check
Author: vasuag09

Plan Check

Adversarially review a plan against its spec before implementation — check that every acceptance criterion is covered, no scope crept in, and parallel tasks have disjoint write-sets. Use after /plan, before /implement. Read-only gate; delegates to the harness-claude:planner agent in a check pass. Non-blocking except on Critical.

vasuag09 Updated Sep 21, 2026

File contents

/plan-check — gate the plan before building

Goal: catch a broken plan before an executor acts on it. An ambiguous or incomplete plan produces an executor that guesses; parallel executors guessing differently about the same file produce conflicts. Cheaper to fix the plan now than to unwind code later.

This is the plan-phase counterpart to /harness-claude:review — same adversarial stance, one step earlier. It is read-only: it reports, it does not edit the plan.

Do this

Load the artifacts: .claude/planning/<slug>/PLAN.md and SPEC.md (slug is in .claude/STATE.md). If there's no PLAN.md on disk (trivial/inline work), review the plan from the conversation instead — the checks are the same.
Delegate to the harness-claude:planner agent in a check pass (read-only — pass it the plan, the spec, and the objective: "find why this plan fails before we build it"). Get back a summary with severities, not a raw dump.
Check the plan across three dimensions:
- Criteria coverage — does every AC-n in SPEC.md map to at least one task's addresses:? Name any uncovered criterion.
- Scope — does any task do work no criterion asked for (scope creep), or is any in-scope item unplanned? Flag both directions.
- Task independence — for tasks meant to run in parallel (same wave / no depends_on between them), are the write-sets pairwise disjoint? Are depends_on edges acyclic and complete (no task reads another's output without declaring it)? Overlapping write-sets or a missing edge is a correctness bug.
Red-team it: assume the plan already failed in execution and ask why. Attack hidden assumptions, not just the obvious risks.
If findings warrant a revision, hand them back to /harness-claude:plan and re-check — loop ≤ 3 times (per rules/agents.md), then accept or escalate to the user.

Output

A findings list, most-severe first, each with a severity:

Severity	Meaning	Action
Critical	The plan cannot satisfy a criterion, or parallel tasks collide on a file	BLOCK — fix the plan before `/harness-claude:implement`
High	Likely bug or significant gap	Fix before building
Medium	Maintainability / clarity concern	Fix when reasonable
Low	Minor suggestion	Optional

If nothing survives, say so plainly — a clean plan is a valid result.

State

Patch .claude/STATE.md: phase: plan-check, status: done (or blocked if a Critical stands), next_skill: /implement.

Exit criterion

No Critical finding remains (High/Medium/Low may be noted and carried). Then /harness-claude:implement.

---name: plan-checkdescription: Adversarially review a plan against its spec before implementation — check that every acceptance criterion is covered, no scope crept in, and parallel tasks have disjoint write-sets. Use after /plan, before /implement. Read-only gate; delegates to the harness-claude:planner agent in a check pass. Non-blocking except on Critical.---# /plan-check — gate the plan before buildingGoal: catch a broken plan **before** an executor acts on it. An ambiguous or incompleteplan produces an executor that guesses; parallel executors guessing differently about thesame file produce conflicts. Cheaper to fix the plan now than to unwind code later.This is the plan-phase counterpart to `/harness-claude:review` — same adversarial stance, one stepearlier. It is **read-only**: it reports, it does not edit the plan.## Do this1. Load the artifacts: `.claude/planning/<slug>/PLAN.md` and `SPEC.md` (slug is in `.claude/STATE.md`). If there's no `PLAN.md` on disk (trivial/inline work), review the plan from the conversation instead — the checks are the same.2. **Delegate to the `harness-claude:planner` agent in a check pass** (read-only — pass it the plan, the spec, and the objective: "find why this plan fails before we build it"). Get back a summary with severities, not a raw dump.3. Check the plan across three dimensions: - **Criteria coverage** — does every `AC-n` in `SPEC.md` map to at least one task's `addresses:`? Name any uncovered criterion. - **Scope** — does any task do work no criterion asked for (scope creep), or is any in-scope item unplanned? Flag both directions. - **Task independence** — for tasks meant to run in parallel (same wave / no `depends_on` between them), are the **write-sets pairwise disjoint**? Are `depends_on` edges acyclic and complete (no task reads another's output without declaring it)? Overlapping write-sets or a missing edge is a correctness bug.4. Red-team it: assume the plan already failed in execution and ask why. Attack hidden assumptions, not just the obvious risks.5. If findings warrant a revision, hand them back to `/harness-claude:plan` and re-check — **loop ≤ 3 times** (per rules/agents.md), then accept or escalate to the user.## OutputA findings list, most-severe first, each with a severity:| Severity | Meaning | Action ||----------|---------|--------|| Critical | The plan **cannot** satisfy a criterion, or parallel tasks collide on a file | BLOCK — fix the plan before `/harness-claude:implement` || High | Likely bug or significant gap | Fix before building || Medium | Maintainability / clarity concern | Fix when reasonable || Low | Minor suggestion | Optional |If nothing survives, say so plainly — a clean plan is a valid result.## StatePatch `.claude/STATE.md`: `phase: plan-check`, `status: done` (or `blocked` if a Criticalstands), `next_skill: /implement`.## Exit criterionNo Critical finding remains (High/Medium/Low may be noted and carried). Then`/harness-claude:implement`.

Frequently asked questions