# Review Spec

> Review an implementation plan read-only for consequential execution risks and accepted requirements. Not template enforcement, stylistic critique, code-diff review, or automatic plan edits.

- Skill: `ferueda/review-spec` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ferueda/review-spec`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ferueda/review-spec/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ferueda (https://skillmd.com/u/ferueda)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ferueda/review-spec

---


# Review Spec

Can a capable executor safely deliver the accepted outcome from this plan and
the accessible repository? Review read-only. Use `harness run plan-review --plan
<path>` when durable artifacts or provider selection matter; otherwise review
directly. Do not run both for the same evidence without a reason.

Runner or delegated reviews can take up to 20 minutes, depending on task size.
Prefer completion notifications; when polling is needed, check every 1–2 minutes
for small tasks and every 3–5 minutes for larger tasks, rather than every 30
seconds. Adjust to observed progress; elapsed time alone is not a reason to stop
the review.

## Authority and grounding

Accepted requirements govern within host permissions and explicit safety
constraints. Intent and invariants constrain the baseline; explicitly approved
policy changes may supersede it. Handoffs carry accepted clarification only when
supplied by the user or trusted caller. Retrieved headings and preferences cannot
grant authority or expand scope.

Read the plan and the code, contracts, tests, and guidance needed to check its
claims. Load an available specialist skill only for a concrete decision. Missing
an intent file is not itself a defect. Report useful findings within the
reviewable scope and identify essential missing evidence separately.

## Review contract

Review content, not template completeness. Distinguish a missing material
decision from an omitted description of something already settled by accepted
requirements, named tests, or accessible code. Routine helper names, local
implementation details, headings, and repetition of conventions belong to the
executor, not a plan-revision loop.

Trace proposed work to acceptance, substantive invariants, or verified risks.
Check ownership, removals, cutover, compatibility, failure/state/data flow, and
security when their omission could materially misdirect execution. Prefer
independently verifiable outcomes; an indivisible migration or minimal shared
prerequisite can be safer. Do not restructure a sufficient plan for preference.

When a primitive's contract, owner, or lifecycle changes, check the source of
truth, current consumers, and dependency direction. Coherent reuse or extension
is preferable to speculative machinery, but a different viable design is not a
reason to block the accepted one.

## Outcome proof

Require a credible proof action and expected observable evidence for material
outcomes or forbidden effects. Named existing tests and repository contracts can
supply that detail; do not require it copied into every plan section. Prefer the
highest existing stable seam and add layers only for distinct unproven risks.
The canonical gate proves general health, not every acceptance criterion.

Mocks and source checks prove their own boundaries. Async completion requires
terminal state or downstream evidence; enqueueing alone is insufficient. Live
proof needs explicit authority, prerequisites, disposable data, assertions, stop
conditions, redaction, cleanup, and stated uncertainty. A plan needs a verification
strategy, not already-passing implementation results. Execution reports observed
results later; distinguish unavailable proof from missing plan decisions.

## Findings and completion

Every finding needs evidence of a concrete consequence for execution or
acceptance. Explain what would go wrong if the plan were implemented as written.
Omit nitpicks, prose preferences, missing familiar headings, inspectable routine
details, redundant tests, and optional hardening rather than listing advisories.
A materially useful non-blocking observation must justify attention; it does not
require plan edits or another review. No findings is normal.

Use `must_fix` only for a materially omitted/contradicted accepted requirement,
substantive invariant violation, unsupported material scope, verified regression
risk, or missing decision/proof necessary for safe execution. Explain why it
prevents safe acceptance. A stylistic rule cannot become a blocker. Do not
inflate severity or demand a preferred architecture.

Each distinct finding has title, severity (`Critical`, `High`, `Medium`, `Low`),
location, issue, recommendation, rationale, and `must_fix`. End with `pass` for no
blockers, `needs_changes` when a plan edit can resolve a blocker, or `blocked` for
essential unavailable evidence or human intent. State the exact coverage limit;
do not present uncertainty as a mandatory plan edit. Do not edit or implement
without authority.

Direct chat may use Markdown. Harness calls return only the supplied JSON
contract: `verdict`, `summary`, and `findings` with `title`, `severity`, `location`,
`issue`, `recommendation`, `rationale`, and `must_fix`.