Agent skill

Review Plan

by adamayoung in adamayoung/TMDb

Adversarially review the current implementation plan with three independent critic subagents, reconcile their findings into a consensus, and apply the agreed feedback to the plan.

Apache-2.0Auto-check passedAgent Workflows

Install Review Plan

skills CLI
$ npx skills add adamayoung/TMDb --skill review-plan -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install adamayoung/TMDb review-plan --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/adamayoung/TMDb.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/review-plan .claude/skills/review-plan && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
review-plan
GitHub stars
178
Token cost
~3.1k tokens
SKILL.md length
1,118 words
Files
1
Skills in repo
18
Repo updated
First seen
Licence
Apache-2.0

At a glance

Adversarially review the current implementation plan with three independent critic subagents, reconcile their findings into a consensus, and apply the agreed feedback to the plan.

  • Works in 6 steps: Find the plan first; never invent one.… → Three reviewers, three lenses, via one… → Adversarial, not agreeable. Each… → …
  • Asks to pressure-test
  • SKILL.md covers Agent Behaviour Contract, Locate the plan, Run the review (Workflow) and Severity rubric, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Review Plan is an agent skill from adamayoung/TMDb. Adversarially review the current implementation plan with three independent critic subagents, reconcile their findings into a consensus, and apply the agreed feedback to the plan. Use after drafting a plan (in plan mode or a plan/design doc) and before starting implementation, or whenever the user asks to pressure-test, critique, or harden a plan.

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows, covering Planning and Architecture decision records. The repository describes itself as: The Movie Database Swift Package. The licence is Apache-2.0.

When your agent uses it

  • Asks to pressure-test
  • Tasks that involve Planning
  • Tasks that involve Architecture decision records

Example prompts

  • “/review-plan”

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Find the plan first; never invent one. Locate the actual current plan
  2. Three reviewers, three lenses, via one Workflow. Run the embedded
  3. Adversarial, not agreeable. Each reviewer assumes the plan is flawed and
  4. Ground every finding in the codebase. Findings must cite real files,
  5. Reconcile to a consensus — you adjudicate. Merge overlapping findings,
  6. Apply the agreed feedback, then show your work. Revise the plan in place,

What it can do on your machine

Read from SKILL.md and the folder at commit a3f1311. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are javascript).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Review Plan loads about 3.1k tokens when it runs. Until then it costs about 90 tokens; SKILL.md has 1,118 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~90
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from adamayoung/TMDb at commit a3f1311, republished under its Apache-2.0 licence (© adamayoung). 1,118 words, ~3,140 tokens.

Download SKILL.mdSave it as .claude/skills/review-plan/SKILL.md (or your agent's skills folder).
name
review-plan
description
Adversarially review the current implementation plan with three independent critic subagents, reconcile their findings into a consensus, and apply the agreed feedback to the plan. Use after drafting a plan (in plan mode or a plan/design doc) and before starting implementation, or whenever the user asks to pressure-test, critique, or harden a plan.

Review Plan

Pressure-test the current plan before any code is written. Three independent adversarial critics review the plan in parallel, each from a distinct lens; their findings are reconciled into a consensus; and the agreed feedback is folded back into the plan. The point is to surface the gaps, risks, and over-engineering that a single pass misses — three skeptics, not one cheerleader.

A plan that survives three hostile reviewers is worth implementing. A plan that nobody challenged is just the first idea that came to mind.

Agent Behaviour Contract

The point of this skill: do these by default, without being reminded.

  1. Find the plan first; never invent one. Locate the actual current plan (see Locate the plan). If there is no plan, say so and stop — do not fabricate a plan just to review it.
  2. Three reviewers, three lenses, via one Workflow. Run the embedded Workflow script below — it fans out exactly three critic agents in parallel, each pinned to the opus model at xhigh effort and forced to return a schema-validated verdict. Each carries a distinct adversarial mandate. They are read-only — reviewers critique, they do not edit the plan or the code.
  3. Adversarial, not agreeable. Each reviewer assumes the plan is flawed and hunts for the strongest objection. A reviewer that finds nothing must say so explicitly and justify why each common failure mode does not apply.
  4. Ground every finding in the codebase. Findings must cite real files, symbols, or constraints (file:line) — not generic plan-review platitudes. An objection that cannot be tied to this repository's reality is noise.
  5. Reconcile to a consensus — you adjudicate. Merge overlapping findings, record agreement level, and resolve direct contradictions yourself with a stated rationale. Do not just concatenate three reports.
  6. Apply the agreed feedback, then show your work. Revise the plan in place, then report what changed, what was deliberately rejected, and why.

Locate the plan

Use the first that applies:

  1. An explicit target the user named — a file path (e.g. a design doc or PLAN.md), or plan text passed as the skill argument.
  2. The active plan-mode plan — the most recent plan you presented via ExitPlanMode, or the plan you are currently drafting in plan mode.
  3. A plan in the conversation — the most recent structured plan / task breakdown you produced (including a TodoWrite list framed as the plan).

If none of these exists, stop and tell the user there is no plan to review, and offer to draft one (e.g. via the Plan agent or plan mode) first.

Before reviewing, restate in one or two sentences what the plan is for (the underlying goal/task) — the reviewers need the problem, not just the proposed solution, to judge whether the solution fits.

Run the review (Workflow)

The three critics run as a single Workflow so that the opus model and xhigh effort are guaranteed per agent (these are first-class agent() options) and each verdict is schema-validated rather than free-text. Invoking this skill is itself the opt-in to call the Workflow tool.

Pass the plan and goal as args — never inline them into the script body (they contain arbitrary text). Call Workflow with args: { plan: "<full plan text>", goal: "<one–two sentence restatement of the underlying task>" } and the script below. The three lenses live in the script; only args changes per run.

Args may arrive stringified. The harness sometimes delivers args to the script as a JSON string rather than an object, so reading args.plan directly yields undefined and the critics silently review an empty plan. The script below already guards against this (typeof args === 'string' ? JSON.parse(args) : args) — keep that guard. If a critic ever reports the plan or goal is literally "undefined", this is the cause: the args weren't parsed.

javascript
export const meta = {
  name: 'review-plan-critics',
  description: 'Three adversarial Opus critics review a plan in parallel',
  phases: [{ title: 'Review', detail: 'three opus/xhigh critics, one per lens' }],
  model: 'opus',
}

const RUBRIC = `Grade each finding by CONSEQUENCE IF THE PLAN SHIPS UNCHANGED, not by your confidence:
- blocker: the plan will fail or do harm as written (goal not met, wrong approach, breaking change, data loss, security hole, irreversible step with no rollback). Implementation must not start until resolved.
- major: can proceed but will likely cause real pain (missing edge case/error path, no test coverage for new behaviour, significant over-engineering or scope creep, portability/concurrency gap, violated project convention).
- minor: a refinement that does not change viability (step ordering, naming, small simplification, docs/DocC reminder).
If unsure whether a finding is real, set "confidence" to low/medium and say so in the claim — do NOT inflate or deflate severity to express doubt.`

const LENSES = [
  {
    key: 'correctness',
    title: 'Correctness & Completeness',
    brief: `Does the plan actually achieve the goal? Hunt for: missing steps, wrong assumptions about how the code works, unhandled edge cases and error paths, ordering/dependency mistakes, missing tests, and "done" criteria that do not actually prove the feature works. This is a Swift package (see CLAUDE.md) — scrutinise Sendable/concurrency gaps, Codable/JSON-fixture coverage of every decoder branch, Linux portability, and public-API + DocC obligations.`,
  },
  {
    key: 'risk',
    title: 'Risk & Failure Modes (red team)',
    brief: `Assume the plan ships and something breaks. Hunt for: breaking changes to the public API, hidden coupling and side effects, backward-compatibility and migration risk, security/secret exposure, data-loss or irreversible steps, flaky or environment-dependent tests, and the absence of a rollback or verification path. Rank by blast radius.`,
  },
  {
    key: 'simplicity',
    title: 'Simplicity, Scope & Fit',
    brief: `Assume the plan does too much, the wrong way. Hunt for: over-engineering and speculative generality (YAGNI), scope creep beyond the stated goal, reinvention of something the codebase already provides, and divergence from established conventions and patterns in this repo. Propose the simpler alternative the plan should have taken.`,
  },
]

const VERDICT_SCHEMA = {
  type: 'object',
  additionalProperties: false,
  properties: {
    lens: { type: 'string' },
    stance: { type: 'string', enum: ['sound', 'sound-with-fixes', 'not-ready'] },
    findings: {
      type: 'array',
      items: {
        type: 'object',
        additionalProperties: false,
        properties: {
          severity: { type: 'string', enum: ['blocker', 'major', 'minor'] },
          confidence: { type: 'string', enum: ['high', 'medium', 'low'] },
          claim: { type: 'string', description: 'one-line statement of the problem' },
          evidence: { type: 'string', description: 'file:line or a concrete repo constraint' },
          suggestedChange: { type: 'string', description: 'concrete change to make to the plan' },
        },
        required: ['severity', 'confidence', 'claim', 'evidence', 'suggestedChange'],
      },
    },
    cleanNote: { type: 'string', description: 'if a category is clean, why each common failure mode does not apply' },
  },
  required: ['lens', 'stance', 'findings'],
}

// `args` can arrive as a JSON string rather than an object (a known harness
// gotcha), in which case `args.plan` / `args.goal` would be `undefined` and the
// critics would review an empty plan. Parse it back to an object first.
const input = typeof args === 'string' ? JSON.parse(args) : args
const plan = input.plan
const goal = input.goal

phase('Review')
const verdicts = await parallel(LENSES.map((lens) => () =>
  agent(
    `You are an ADVERSARIAL plan reviewer. Assume the plan is flawed and find the strongest objections through the lens of "${lens.title}".\n\n` +
    `${lens.brief}\n\n` +
    `THE GOAL THIS PLAN MUST ACHIEVE:\n${goal}\n\n` +
    `THE PLAN UNDER REVIEW:\n${plan}\n\n` +
    `You are READ-ONLY: read the codebase to verify your claims against real files/symbols, but do not edit anything or run mutating commands. Every finding MUST cite concrete evidence (file:line or a real repo constraint) — generic plan-review platitudes are noise and must be omitted. If your lens is genuinely clean, return an empty findings array and explain in "cleanNote" why each common failure mode does not apply.\n\n` +
    `SEVERITY RUBRIC:\n${RUBRIC}`,
    { label: `critic:${lens.key}`, phase: 'Review', model: 'opus', effort: 'xhigh', schema: VERDICT_SCHEMA }
  ).then((v) => v && { ...v, lens: lens.title })
))

return verdicts.filter(Boolean)

The script returns an array of up to three verdicts. If a critic dies, it drops to null and is filtered out — note in your reconciliation if fewer than three came back. To iterate on the script, edit the file path returned by the Workflow tool and re-invoke with { scriptPath } rather than resending it.

Show full SKILL.md (441 more words)Show less

Severity rubric

Every reviewer grades each finding against the same rubric, so severities are comparable when you reconcile. Severity is about consequence if the plan ships unchanged, not how confident the reviewer is.

  • blocker — the plan will fail or do harm as written. The goal is not met, the approach is wrong, or it introduces a breaking change, data loss, security hole, or irreversible step with no rollback. Implementation must not start until this is resolved. Always must-apply.
  • major — the plan can proceed but will likely cause real pain: a missing edge case or error path, absent test coverage for new behaviour, significant over-engineering or scope creep, a portability/concurrency gap, or a violated project convention. Should be fixed now; cheap to address in the plan, expensive to discover mid-implementation.
  • minor — a refinement that improves the plan without changing its viability: clearer step ordering, a naming nit, a small simplification, or a documentation/DocC reminder. Apply if cheap; defer-able.

When a reviewer is unsure whether something is real, it states the uncertainty in the finding rather than inflating or deflating the severity — you weigh confidence during reconciliation.

Reconcile to consensus

Synthesize the three reports yourself — do not delegate this:

  1. Merge findings that describe the same concern across reviewers.
  2. Label agreement: unanimous (3), majority (2), or lone (1).
  3. Decide what to apply. A finding is must-apply if it is a blocker, or if ≥2 reviewers raise it. A lone major/minor is applied only if you judge it correct on the merits — say so. Reject findings that are wrong, out of scope for the stated goal, or contradicted by the code; record the reason.
  4. Adjudicate contradictions. When reviewers conflict (e.g. "add X" vs "X is scope creep"), make the call and state why — usually favouring the smallest change that satisfies the goal and the project's conventions.

Present a short consensus table/summary: each finding, its agreement level, severity, and your decision (apply / reject + reason).

Apply the feedback

Revise the plan to incorporate every must-apply finding and any lone findings you accepted:

  • Plan in a file → edit the file in place.
  • Plan-mode plan → produce the revised plan and re-present it (via ExitPlanMode when you are ready to exit plan mode, otherwise inline).
  • Plan in the conversation → restate the corrected plan.

Then close with a brief change log:

  • Applied — the changes folded in, grouped by the finding that drove them.
  • Rejected — findings you deliberately did not apply, each with a one-line reason.
  • Open questions — anything the reviewers surfaced that needs a human decision before implementation.

Do not silently drop a finding. Every reviewer finding ends up either applied or explicitly rejected with a reason.

© adamayoung, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/review-plan of adamayoung/TMDb.

Open the folder on GitHubat commit a3f1311

Compare with similar skills

Review Plan next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Review Plan compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Review Plan this skilladamayoung/TMDb178—~3.1kAutomated safety check: PassApache-2.0
Plan Previewu-ichi/reviewable-html-workbench2981 repos~1.8kAutomated safety check: PassMIT
Manual Planningfjrevoredo/mini-diarium310—~4.2kAutomated safety check: PassMIT
Idea To Implementation DocAkoliteZA/hermes-agent-idea-workflow272—~3.1kAutomated safety check: PassMIT
Designsynnaxlabs/synnax128—~4.5kAutomated safety check: PassCustom licence
Idea Discoverymuratgur/ordinus113—~851Automated safety check: PassMIT

Similar skills

  • Plan Preview

    u-ichi/reviewable-html-workbench

    Plan Mode の <proposedplan を出す直前に、計画の段階・依存関係・検証観点を一時HTMLで視覚確認したい時に使う agent-internal skill。Use this agent-internal skill to create a temporary HTML preview for a plan just before presenting…

    298 GitHub starsUsed in 1 repo~1.8k tokens
    Agent WorkflowsAuto-check passed
  • Manual Planning

    fjrevoredo/mini-diarium

    Create, update, review, and execute manual Markdown implementation plans when harness planning mode is not being used.

    310 GitHub stars~4.2k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Idea To Implementation Doc

    AkoliteZA/hermes-agent-idea-workflow

    A skill your agent uses when reviewing one specific idea/design doc, researching similar products, and producing a separate technical implementation plan or roadmap.

    272 GitHub stars~3.1k tokensUpdated 5 mo ago
    Agent WorkflowsAuto-check passed
  • Design

    synnaxlabs/synnax

    Process and hard rules for designing and planning complex new features, refactors, and re-architectures.

    128 GitHub stars~4.5k tokensUpdated yesterday
    Agent WorkflowsAuto-check passed
  • Idea Discovery

    muratgur/ordinus

    Explore a new feature, product idea, technical design, workflow change, or ADR candidate before committing to an implementation plan.

    113 GitHub stars~851 tokensUpdated 1 mo ago
    Agent WorkflowsAuto-check passed
  • A skill your agent uses when creating or refining a structured Java implementation plan from trusted issue summaries, approved designs, ADRs, OpenSpec changes, existing plans, or a valid combination.

    447 GitHub stars~1.1k tokensUpdated 3 days ago
    Agent WorkflowsAuto-check passed

More from adamayoung/TMDb

All 18 skills in this repo
  • Writes and maintains DocC /// comments for the public API of the TMDb Swift package, following the project's summary patterns and comment structure.

    178 GitHub stars~2.6k tokensUpdated 7 days ago
    Auto-check passed
  • Diagnoses a failing scheduled TMDb Integration run, re-runs transient failures, and fixes real API drift on its own branch with a PR, merging it only when told to.

    178 GitHub stars~2.7k tokensUpdated 7 days ago
    Auto-check passed
  • Drives an approved plan to completion test-first, deriving a Canon TDD test list, showing it before any code and stopping only when every item is written, passing and green.

    178 GitHub stars~4.5k tokensUpdated 7 days ago
    Auto-check passed
  • TMDb Backlog Triager

    adamayoung/TMDb

    Grooms the Backlog column of a GitHub project board by re-verifying each issue against current main, closing dead ones, promoting actionable ones to Ready and naming the decision the rest need.

    178 GitHub stars~5k tokensUpdated 7 days ago
    Auto-check passed
  • Canon TDD Workflow

    adamayoung/TMDb

    Has your agent build features and fix bugs in Canon TDD order: write a test list, then one failing test, make it pass, refactor, and repeat until the list is empty.

    178 GitHub stars~1.3k tokensUpdated 7 days ago
    Auto-check passed
  • Capture Knowledge

    adamayoung/TMDb

    Records non-obvious lessons from a finished task, such as gotchas, API quirks and design decisions, into a project's knowledge folder before a pull request opens.

    178 GitHub stars~2.3k tokensUpdated 7 days ago
    Auto-check passed

Categories

Questions about Review Plan

What does Review Plan do?

Adversarially review the current implementation plan with three independent critic subagents, reconcile their findings into a consensus, and apply the agreed feedback to the plan. Review Plan is an agent skill from adamayoung/TMDb. Adversarially review the current implementation plan with three independent critic subagents, reconcile their findings into a consensus, and apply the agreed feedback to the plan.

When should I use Review Plan?

Review Plan fits situations like: asks to pressure-test; tasks that involve Planning; tasks that involve Architecture decision records.

How do I install Review Plan in Claude Code?

Run `npx skills add adamayoung/TMDb --skill review-plan -a claude-code`. Or copy the skill folder (.claude/skills/review-plan in adamayoung/TMDb) into .claude/skills/review-plan in your project. Claude Code loads it when a task matches its description.

How do I install Review Plan in Codex?

Run `npx skills add adamayoung/TMDb --skill review-plan -a codex`. Or copy the skill folder (.claude/skills/review-plan in adamayoung/TMDb) into .agents/skills/review-plan in your project. Codex loads it when a task matches its description.

Can I use Review Plan in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add adamayoung/TMDb --skill review-plan -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/review-plan, .gemini/skills/review-plan, .github/skills/review-plan and .opencode/skills/review-plan in your project.

What does Review Plan need to run?

SKILL.md names no scripts, command-line tools or credentials: Review Plan is instructions for the agent only.

Does Review Plan access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Review Plan safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Review Plan use?

Review Plan is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Review Plan use?

About 3.1k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Review Plan?

Skills that share tags, products or a category with Review Plan: Plan Preview (u-ichi/reviewable-html-workbench, 298 stars), Manual Planning (fjrevoredo/mini-diarium, 310 stars), Idea To Implementation Doc (AkoliteZA/hermes-agent-idea-workflow, 272 stars) and Design (synnaxlabs/synnax, 128 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Review Plan?

adamayoung (a GitHub user) maintains it in adamayoung/TMDb, which has 178 GitHub stars. The repository holds 18 skills in this directory. The repository was last updated on October 3, 2026.

Source: adamayoung/TMDb on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.