| version | 1.0.0 |
| name | vibe-plan-review |
| description | Use when the user asks to review, confirm, walk through, or pre-check a saved Markdown implementation plan before implementation; interactively reviews plan items one at a time and manages localized item-level decisions. |
Vibe Plan Review
Overview
Review a saved Markdown implementation plan with the user before implementation
begins. The goal is to surface requirement mismatches, ordering problems,
missing work, ambiguity, risks, and unverifiable items while preserving user
control over every plan item decision.
This skill reviews the plan; it does not execute it. Stop after item review and
the final plan-reflection confirmation workflow. Do not proceed into
implementation, tests, commits, releases, or adjacent coding work.
Runtime responses should match the user's language. Before rendering item-review
output, interpreting item decisions, counting review-file thresholds, reflecting
decisions into the plan, or summarizing review results, read
references/localized-labels.md and use its exact localized labels, numeric
choice identifiers, and decision semantics. Preserve file paths, commands,
identifiers, and review-state paths exactly.
Required Inputs
The primary target is a saved Markdown implementation plan file. If the user
does not provide a local path or otherwise identify one specific saved plan,
ask for the plan file before starting review.
Treat summaries, chat excerpts, issue descriptions, and pasted snippets as
context only. The saved plan file controls the review.
Phase Boundary
Use this skill only after an implementation plan exists and before
implementation starts. Do not name or require any neighboring workflow as a
prerequisite or next step. When review is complete, report the reviewed state
and stop at the user's next decision point.
Start Of Review
Before reviewing items:
- Read the target plan file.
- Identify whether the plan explicitly references a corresponding requirements
spec path.
- If an explicit requirements spec path exists, read that file.
- If no explicit path exists, look for an obvious same-goal requirements spec
in
specs/ and in the plan's directory.
- If no corresponding requirements spec can be identified, continue only with
explicitly limited requirement-alignment confidence.
- Identify plan items using the item extraction rules below.
- Determine whether a temporary review file is required before presenting the
first item.
If a corresponding requirements spec exists, it is requirement evidence for
the review. If the requirements spec and implementation plan conflict, stop the
review, state the conflict, and ask whether the requirements or the plan should
be corrected. Do not continue item review while the conflict controls the item.
If the plan lacks information needed to review it, stop the review, state what
is missing, and ask how to complete the plan. Do not invent missing behavior,
requirements, acceptance criteria, test paths, data handling, or user
experience.
Source And Code Inspection
Default to minimal source and code inspection. Read only the files needed to
check the current plan item unless the user asks for deeper investigation or
the item has high implementation impact.
High implementation impact includes changes that could affect data handling,
permissions, security posture, releases, migrations, external contracts,
destructive writes, or broad user experience. When deeper inspection is needed,
explain why the item needs it before expanding the read scope.
Item Extraction
Prefer explicit task or checklist items in the saved plan. If the plan is
organized by headings rather than checkboxes, review the smallest executable
sections in file order.
If item boundaries are ambiguous, stop and ask the user whether to use the
detected sections or revise the plan structure first. Do not silently choose a
more convenient item granularity.
Keep item identity stable during review. If you propose splitting, merging, or
reordering items, present the proposal as a recommendation and wait for the
user's decision before treating it as part of the executable plan.
Per-Item Review
Read references/localized-labels.md before the first per-item review in a
session.
Review one item at a time. For each item, check:
- Requirement alignment.
- Implementation order and dependency sequencing.
- Missing work.
- Ambiguity.
- Risks.
- Verifiability.
The user's item decision is the source of truth. AI judgment guides the
decision but does not override it.
Render each user decision option with the stable numeric identifiers defined in
references/localized-labels.md. Accept either the canonical localized decision
label or an unambiguous numeric identifier for the current item decision. Store,
count, summarize, and reflect the decision as its canonical localized label, not
as the numeric identifier. If a user's reply contains conflicting labels or
identifiers, ask which decision they intend before continuing.
Temporary Review File
Short reviews remain chat-only when all of these are true:
- The plan has fewer than 8 detected items.
- Fewer than 3 item decisions are revise-or-hold decisions as defined in
references/localized-labels.md.
- The user has not asked for a review file.
Create or update a temporary review file when any of these are true:
- The plan has 8 or more detected items.
- 3 or more item decisions are revise-or-hold decisions as defined in
references/localized-labels.md.
- The user asks for a review file.
Store the temporary review file beside the plan as .<plan-name>.review.md,
where <plan-name> is the target plan filename stem, meaning the filename
without its final suffix. For plans/payment-plan.md, use
plans/.payment-plan.review.md; for plans/payment.plan.md, use
plans/.payment.plan.review.md.
During item review, the only allowed file write is creating or updating this
temporary review file. Do not modify the original implementation plan during
item review.
Record enough state to resume review:
- Target plan path.
- Requirements spec path when known, or the limited-confidence no-spec status.
- Detected item list.
- Current review position.
- Per-item AI judgments.
- User decisions as canonical localized labels, even when the user supplied a
numeric identifier.
- Unresolved blockers.
- Important decision summaries.
- Conversation summary when the user asks for it or when an important decision
should survive context loss.
If the temporary review file already exists, read it before writing. Resume only
when it clearly matches the target plan and is parseable. If ownership, target
identity, parseability, or external edits are unclear, stop and ask whether to
resume, replace, or preserve the file. Do not overwrite or delete a preexisting
review file while that question is unresolved.
Reflection Into The Plan
After all detected items have been reviewed, ask for explicit confirmation
before modifying the original implementation plan. The confirmation must state
how decisions will be reflected according to references/localized-labels.md.
Do not reflect review results into the original plan without this explicit
confirmation. A general request to review the plan is not reflection consent.
Reflected plans should contain executable plan content plus unresolved held
items. Remove review-history annotations, per-item judgment logs, and chat
discussion notes from the executable plan.
After successful reflection, ask whether to delete the temporary review file.
Honor a user instruction to keep it. If the file has unexpected changes or
ownership is unclear, preserve it and report the reason.
Stop Conditions
Stop and ask for user direction when:
- No saved Markdown implementation plan file is identified.
- The target plan file cannot be read.
- A corresponding requirements spec exists but cannot be read.
- The requirements spec and implementation plan conflict.
- Plan information needed for review is missing.
- Item boundaries are ambiguous.
- A preexisting temporary review file is mismatched, unparseable, externally
edited, or has unclear ownership.
- The user asks to change scope beyond reviewing and reflecting the saved plan.
- The user asks to start implementation, tests, commits, release preparation, or
other work outside plan review.
When stopping, state the blocker, the evidence that triggered it, the effect on
review, and the closest next user decision.
Completion Summary
When the review workflow completes, summarize:
- Target plan path.
- Requirements spec path or limited-confidence no-spec status.
- Number of items reviewed.
- Decisions by count for the four canonical user decision labels, not their
numeric identifiers.
- Unresolved blockers or held items.
- Whether the original plan was reflected after explicit confirmation.
- Whether the temporary review file was created, kept, or deleted.
- That implementation was not started.
