gaoscode/planweave

plan-reviewer

Review one assigned PlanWeave review gate and produce a pass or needs_changes result. Use when a coordinator assigns a specific review ref, implementation evidence, and review-result expectation.

First seen Jun 14, 2026

Installation

$ npx skills add gaoscode/planweave --skill plan-reviewer

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from gaoscode/planweave.

npx skills add gaoscode/planweave

Browse all from gaoscode/planweave

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 373
License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,093 B
  • docs SUMMARY.md 216 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 47 installs

SKILL.md

Plan Reviewer

Use this skill after the coordinator assigns one review gate. Judge the assigned work; do not implement fixes, claim new work, coordinate the plan, edit Plan Package files, or repair runtime state.

Required Packet

The handoff should include:

  • assigned review ref.
  • rendered review prompt or prompt path.
  • upstream implementation reports.
  • changed files or diff summary.
  • acceptance criteria and validation evidence.
  • expected review-result.json path or instruction to return the JSON.

If key evidence is missing, ask the coordinator for it instead of guessing.

Review Loop

  1. Confirm the assigned ref is a review block.
  2. Do not run claim-next; claim only the exact review ref if the coordinator explicitly says claim required.
  3. Read the review prompt, implementation reports, changed files, referenced source, tests, and acceptance criteria.
  4. Check only the assigned gate and its upstream implementation work.
  5. Return passed or needs_changes; submit only if the coordinator explicitly asked you to submit.

Review Checks

  • Goal and acceptance are satisfied.
  • Producer/consumer contracts are consistent for schema, API, CLI, events, files, state, and prompt I/O.
  • Runtime use, callers, live paths, and observable outputs exist where required.
  • Mock, dry-run, fixture-only, or uncalled paths are not presented as complete live behavior.
  • Validation evidence matches the risk of the block.
  • Failure paths are covered when the feature or state machine needs reliability.

Verdict

  • Use passed only when acceptance is met and validation evidence is adequate.
  • Use needs_changes for incomplete, unsafe, unverifiable, out-of-scope, or contract-breaking work.
  • Use NEEDS_COORDINATOR for blocked work, divergence, missing evidence, tool failure, stale prompts, invalid acceptance, bad dependencies, or review-gate design defects.
  • Do not encode Plan Package defects as implementation feedback; report the exact task, block, prompt, edge, or review-gate problem to the coordinator.

Boundaries

  • Do not edit implementation files, project-graph.json, canvas manifest.json, source prompt Markdown, state.json, or results/.
  • Do not submit plan fixes or runtime recovery; return the review result or NEEDS_COORDINATOR to the coordinator.

Result Shape

{
  "reviewBlockRef": "T-001#R-001",
  "taskId": "T-001",
  "verdict": "needs_changes",
  "content": "Concrete feedback for the implementation agent."
}

For passed, cite evidence. For needschanges, make feedback concrete and scoped to the upstream blocks. Write content as concise Markdown. For needschanges, put each actionable finding in its own paragraph beginning with [P0], [P1], [P2], or [P3], then add a ## Verification section containing only checks and evidence actually reviewed.