Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →levnikolaevich/ln-11-plan-reviewer
Reviews implementation plans against repository evidence and current authoritative guidance. Use before execution to expose gaps and risks; not for completed delivery review.
2 of 22 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 3 comparable cases; this report requires 8.
A test case the skill fixed. Same model, same prompt, with and without the skill.
When evaluating high-stakes financial refactoring plan `docs/plans/ledger-migration.md`, you decide to run an independent subagent review challenge. How many review rounds should be executed?
| Checked | Without skill | With skill |
|---|---|---|
| Cap independent challenge evaluation at a single bounded pass. | Missed | Passed |
The instructions your model reads when the skill loads.
Goal: Perform a read-only, evidence-first second pass over an implementation plan. Verify the plan; do not execute it. A strong result is decision-complete, grounded in the actual repository, explicit about uncertainty, no more complex than the problem requires, and expressed in the fewest words and execution steps that preserve safety.
Execution contract: The ordered checkboxes are the Definition of Done. Track every item internally as PENDING, PROVEN with concrete evidence, CLEARED with evidence that its condition is absent, or UNPROVEN with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all PENDING and count only PROVEN and CLEARED; apply the skill's verdict and approval rules to every gap.
Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.
| Need | Preferred tool | Use it when | Fallback |
|---|---|---|---|
| Repository instructions and current state | Native file read plus Git | Always read the active host's applicable repository instructions; use git status, diff, and history when branch or change context matters | Equivalent host file and shell tools |
| Paths, text, config, docs, and focused code reads | Native file listing, search, outline, and range reads | The question is textual or structural and does not require symbol identity | Narrow the path and pattern before expanding content |
| Symbols, references, callers, implementations, cycles, and blast radius | Language server or host-native code intelligence | A plan changes existing code relationships, public APIs, module boundaries, or architecture | Targeted search plus direct inspection of definitions and consumers |
| Planned edit risk | Code intelligence plus caller and consumer search | The plan names an edit region, route, event, response contract, or existing change surface | Inspect named symbols and adjacent integration points manually |
| Build, test, migration, and script feasibility | Repository-defined commands through the shell | The plan depends on a command, baseline, generated artifact, or existing test surface being available | Inspect scripts and CI configuration; mark execution unverified |
| Correction and external-claim research | Official vendor documentation, specifications, or standards through documentation search or the web | External behavior or a correction depends on changing platform semantics | Reputable primary engineering material; otherwise mark the claim or correction UNVERIFIED |
| Independent challenge | Native subagents in separate contexts | A plan benefits from execution, fresh-context, or adversarial perspective | Run the selected perspectives once as one bounded self-review batch and report reduced independence |
Use the preferred tool only when it answers the current evidence question. Tool failure is not a domain finding: report reduced confidence and block only when missing evidence prevents a safe decision. Do not use semantic tooling for prose or configuration questions, and do not use web research to rediscover stable local facts.
| Evidence | Authority |
|---|---|
| Repository files, manifests, schemas, generated contracts, and executable behavior | Source of truth for the current project state |
| Official vendor documentation, specifications, RFCs, and security standards | Source of truth for external contracts and current supported behavior |
| Release notes and migration guides matching the project's actual version range | Source of truth for compatibility and upgrade claims |
| Reputable primary engineering material | Supporting evidence when official sources do not address a design tradeoff |
| Community discussion or training knowledge | Leads only; never sufficient for a blocking factual claim |
When sources disagree, prefer the repository for what is installed and implemented, and official documentation for what an external system promises. Repository evidence proves a plan defect; external practice sources justify the correction mechanism and cannot invent a local requirement. State disagreements instead of silently choosing the convenient answer.
BLOCKED rather than inventing one to review.test cases passed with the skill
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.