mine-plan-review

Independently review implemented plans against architecture, evidence, and acceptance criteria before merging.

16|Updated Jul 23, 2026
One-click install
npx skills add https://github.com/6ixGODD/mine --skill mine-plan-review-6ixgodd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: mine-plan-review
Source: https://github.com/6ixGODD/mine/tree/main/plugins/mine/skills/mine-plan-review
Command: npx skills add https://github.com/6ixGODD/mine --skill mine-plan-review-6ixgodd

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? In multi-session, multi-agent software engineering, implementations can drift from their approved design and plan, and self-reported success claims are unreliable. This Skill acts as an independent acceptance reviewer that verifies a plan's implementation against the governing architecture, immutable plan, real runtime behavior, and downstream contracts before it is accepted or rejected. ## Core Features & Use Cases - Adversarial acceptance review: Builds a traceability matrix mapping every plan goal and acceptance checkbox to architecture sections, commits, and independent test evidence, classifying each as PASS, FAIL, UNVERIFIED, or NOT_APPLICABLE. - Evidence-based lifecycle transitions: Accepts or rejects plans through the MINE MCP tools or JSON CLI (mine plan accept / mine plan reject), never editing the execution graph files directly, and records review reports under docs/plan/reports/. - Scoped reviewer fixes vs. compensating plans: Classifies findings by impact, fixing narrow defects directly with separate reviewer commits, or rejecting and registering a compensating plan for substantial design-level issues. - Release closure mode: Verifies the final sync, runs the stale plan-reference scan (mine scan plan-refs --check), constructs the stable candidate tree, and completes the release closure gates. - Use Case: After an agent finishes implementing plan03, invoke the review to independently re-run its acceptance commands, inspect edge cases, merge the branch into dev with --no-ff, and transition the plan to ACCEPTED with a committed review report. ## Quick Start Ask the agent to review the implemented plan by invoking mine-plan-review with the plan ID, for example: review plan03 and tell me whether it can be accepted.

Frequently Asked Questions about mine-plan-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review an implemented plan before accepting it?

Invoke the review with the exact plan ID or registered path. The reviewer resolves the node via `mine graph show`, prepares the review worktree with `mine plan prepare`, builds a traceability matrix against the architecture and plan, and only then accepts or rejects through the MINE CLI.

What is the difference between a direct reviewer fix and a compensating plan?

Narrow defects with no design impact, such as typos, missing guards, or broken CI steps, are fixed directly by the reviewer in a separate commit with revalidation. Substantial issues that change design decisions, schemas, or public contracts require rejecting the plan and registering a compensating plan.

Does the review trust the implementation report or passing tests?

No. Reports and existing tests are treated as claims to verify, not authority. The reviewer re-runs the plan's exact commands, probes edge and failure cases, and writes independent tests when a key acceptance claim lacks discriminating evidence.

Can the reviewer edit the execution graph files directly?

No. All lifecycle transitions go through the MINE MCP tools or the JSON CLI (`mine plan accept`, `mine plan reject`). The files `docs/plan/execution-graph.toml` and `docs/plan/execution-graph.md` must never be hand-edited.

How does release closure mode work?

Invoke with the literal argument `complete release closure` once every plan is terminal and the final mine-sync has run. The reviewer verifies sync freshness, runs the stale plan-reference scan, builds the stable candidate tree in an isolated worktree, and performs the local stable-branch integration.

What happens when a plan is rejected?

The reviewer commits a review report with findings and evidence, calls `mine plan reject` with the reason and compensating plan ID, and downstream nodes stay blocked. The rejected branch is not merged, and compensation registration and dependency rewiring remain separate operations.