vibe-plan-review — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited vibe-plan-review (Agent Skill) and scored it 91/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 1 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} is the classic direct prompt-injection phrasing. Placed in a skill body that the agent reads as trusted instructions, it tries to make the agent abandon its prior rules and follow whatever comes next — a full system-prompt override.
ignore/disregard/forget … previous instructions sentence.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
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.
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.
Before reviewing items:
spec path.
in specs/ and in the plan's directory.
explicitly limited requirement-alignment confidence.
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.
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.
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.
Read references/localized-labels.md before the first per-item review in a session.
Review one item at a time. For each item, check:
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.
Short reviews remain chat-only when all of these are true:
references/localized-labels.md.
Create or update a temporary review file when any of these are true:
references/localized-labels.md.
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:
numeric identifier.
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.
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 and ask for user direction when:
edited, or has unclear ownership.
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.
When the review workflow completes, summarize:
numeric identifiers.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.