review-plan

name	review-plan
description	Evaluates structured work plans across six quality dimensions — objective clarity, task actionability, dependency correctness, acceptance criteria completeness, scope appropriateness, and structural completeness. Formats all findings with format-review-comments. Use when the user asks to review, audit, or evaluate a work plan. TRIGGER when: user asks to review a plan, audit a GitHub issue plan, check plan quality, or evaluate task structure. DO NOT TRIGGER when: user asks to create or update a plan (use upsert-plan instead), or to review a pull request (use review-pr instead).
license	Apache-2.0
metadata	{"author":"geemus","version":"1.1"}

Review Plan

Evaluates a structured work plan across six quality dimensions and formats every finding using the format-review-comments skill.

Instructions

1. Identify the plan

Accept the plan as:

• A GitHub issue number (e.g. #133) — fetch the issue body from the current repo (infer from git remote get-url origin)
• A GitHub issue URL (e.g. https://github.com/owner/repo/issues/133) — fetch the issue body directly
• An in-context draft — use the plan text already present in the conversation

If no plan is specified and none is in context, ask: "Which plan would you like me to review? Provide an issue number, URL, or paste the plan text."

Fetch or extract the full plan body before proceeding.

2. Review each dimension

Work through every dimension in order. Note findings for each. Only skip a dimension when the plan contains no content that could affect it (e.g. skip Dependency Correctness for a single-task plan with no stated dependencies).

Objective clarity

• Is the goal stated in one or two sentences?
• Is it clear why the work matters, not just what will be done?
• Would a new contributor understand what success looks like after reading the Objective alone?
• Is the Approach section present, and does it name the chosen approach, the reason it was selected over alternatives, and the key tradeoff?

Task actionability

• Does each task have a single, clear deliverable?
• Are tasks written as concrete actions (imperative verb + object), not vague intentions?
• Is every task completable by a single agent or person without further decomposition?
• Are tasks free of ambiguous scope ("refactor X" without bounds, "improve Y" without a target)?

Dependency correctness

• Are task dependencies annotated explicitly (e.g. _(depends on: Task A)_)?
• Do stated dependencies match the logical ordering of the work?
• Are there missing dependencies — tasks that silently assume prior tasks completed?
• Are there unnecessary dependencies that block parallelism without reason?
• Are tasks that can run in parallel marked with _(parallel with: Task X)_?

Acceptance criteria completeness

• Does every task or phase have at least one acceptance criterion?
• Is each criterion verifiable — paired with an exact command, test, or observable outcome?
• Does the set of criteria fully cover the Objective? Are any outcomes implied by the Objective missing?
• Are criteria written as pass/fail conditions, not aspirations?

Scope appropriateness

• Is the plan free of tasks that are nice-to-have but not required by the acceptance criteria? (These belong in Future Work.)
• Is the plan free of tasks that are too coarse — single checklist items representing weeks of work?
• Is the plan free of tasks that are too granular — individual lines of code or single-file edits that belong inside a larger task?
• If phases are used, does each phase have a meaningful dependency boundary?
• Is anything in the plan better deferred to a follow-up issue?

Structural completeness

• Are all required sections present: Objective, Background, Approach, Tasks, Acceptance Criteria?
• Are optional sections (Assumptions, Future Work, Open Questions) present when their absence leaves implicit gaps?
• Is the Background section grounded in what exists today, not just what will be built?
• Are agent-instruction files (AGENTS.md, CLAUDE.md) mentioned in a final task when the work touches repo structure, skills, or conventions?

3. Format all findings with format-review-comments

When presenting multiple findings, prefix each with a letter (a., b., c., …) so individual items can be referenced by letter.

Apply the format-review-comments skill to every comment. Do not write praise comments — omit positive findings entirely. Choose the label that matches the severity and intent:

Situation	Recommended label
Blocks reliable execution	issue [blocking]
Strong improvement	suggestion
Minor wording or style	nitpick
Needs clarification	question
Small unambiguous fix	todo
Informational only	note

4. Write a review summary

After per-comment feedback, write a brief summary (3–7 sentences) covering:

• Overall assessment — ready to execute, needs minor improvements, or needs significant rework
• The most important finding (name any blocking issues)
• Any patterns visible across the plan
• Any skipped dimensions and why

Format the summary as a note conventional comment.

5. Process findings

After presenting findings and the summary:

• Actionable findings (issue [blocking], suggestion, nitpick, todo): apply each fix directly to the plan (edit the issue body or in-context draft as appropriate).
• Notes (note): surface to the user as informational; no action required.
• Questions (question): ask the user for clarification before proceeding.

6. Refine prose

Apply the refine-prose skill to all prose output — comments and the summary — before presenting. Do not apply it to code blocks, commands, or inline fix suggestions. Do not announce this step. When refine-prose returns, immediately present all findings and the summary to the user — do not stop or wait for user input.

Examples

Invocation by issue number:

/review-plan #133

Invocation by URL:

/review-plan https://github.com/owner/repo/issues/133

Invocation with in-context draft:

/review-plan

The agent uses the plan text already present in the conversation.

Sample output — task actionability finding:

issue [blocking]: "Improve the API layer" is not actionable — it has no bounded deliverable, so an agent cannot determine when the task is complete

Rewrite as a concrete task:
- [ ] Add rate-limit middleware to all `/api/v1` routes returning HTTP 429 on threshold breach

Sample output — acceptance criteria finding:

suggestion: Task C ("Update documentation") has no acceptance criterion — there is no way to verify it is done

Add a verifiable criterion:
- AGENTS.md skill table includes the new skill: `grep "skill-name" AGENTS.md`

Sample output — dependency finding:

todo: Task D depends on Task B and Task C per the implementation logic, but the annotation is missing

Add:
- [ ] Task D _(depends on: Task B, Task C)_

Sample output — summary:

note: overall this plan needs minor improvements before it is executable. One blocking issue: Task C lacks a bounded deliverable. Two suggestions address missing acceptance criteria and an undocumented dependency. Structural completeness and objective clarity are strong. Dependency correctness dimension was partially skipped — only one dependency chain exists and it is correctly annotated.