ln-11-plan-reviewer
starsforks
How to install ln-11-plan-reviewer?
levnikolaevich/claude-code-skills/ln-11-plan-reviewer
$npx -y skills add levnikolaevich/claude-code-skills --skill ln-11-plan-reviewerReviews implementation plans against repository evidence and current authoritative guidance. Use before execution to expose gaps and risks; not for completed delivery review.
SKILL.md
| 1 | # Plan Reviewer |
| 2 | |
| 3 | **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, and no more complex than the problem requires. |
| 4 | |
| 5 | **Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete. |
| 6 | Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: None | section/item — reason; outcome impact; exact next action**; list every incomplete item. |
| 7 | |
| 8 | ## Tool Routing |
| 9 | |
| 10 | | Need | Preferred tool | Use it when | Fallback | |
| 11 | |---|---|---|---| |
| 12 | | Repository instructions and current state | Native file read plus Git | Always read applicable `AGENTS.md`/`CLAUDE.md`; use `git status`, `diff`, and history when branch or change context matters | Equivalent host file and shell tools | |
| 13 | | 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 | |
| 14 | | 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 | |
| 15 | | 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 | |
| 16 | | 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 | |
| 17 | | External APIs, versions, standards, and current practice | Official vendor documentation or standards through documentation search or the web | An external or time-sensitive fact can change the plan | Built-in knowledge only when tools fail, marked `UNVERIFIED` | |
| 18 | | Independent challenge | Native subagents in separate contexts | A non-trivial plan benefits from execution, fresh-context, and adversarial perspectives | Run the same perspectives as distinct self-review passes and report reduced independence | |
| 19 | |
| 20 | 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. |
| 21 | |
| 22 | ## Evidence Rules |
| 23 | |
| 24 | | Evidence | Authority | |
| 25 | |---|---| |
| 26 | | Repository files, manifests, schemas, generated contracts, and executable behavior | Source of truth for the current project state | |
| 27 | | Official vendor documentation, specifications, RFCs, and security standards | Source of truth for external contracts and current supported behavior | |
| 28 | | Release notes and migration guides matching the project's actual version range | Source of truth for compatibility and upgrade claims | |
| 29 | | Reputable primary engineering material | Supporting evidence when official sources do not address a design tradeoff | |
| 30 | | Community discussion or training knowledge | Leads only; never sufficient for a blocking factual claim | |
| 31 | |
| 32 | When sources disagree, prefer the repository for what is installed and implemented, and official documentation for what an external system promises. State the disagreement instead of silently choosing the convenient answer. |
| 33 | |
| 34 | ## Checklist |
| 35 | |
| 36 | ### 1. Establish the Review Contract |
| 37 | |
| 38 | - [ ] Resolve the exact plan, user request, linked requirements, and repository scope. If no concrete plan exists, stop with `BLOCKED` rather than inventing one to review. |
| 39 | - [ ] Read all applicable repository instruction files before interpreting code, documentation, or expected workflow. |
| 40 | - [ ] Inspect Git state when it can affect the review: current branch, uncommitted changes, comparison base, and relevant recent history. |
| 41 | - [ ] State the real goal, observable definition of done, explicit non-goals, constraints, and assumptions implied by the request or plan. |
| 42 | - [ ] Separate defects in the plan from pre-existing adjacent problems. Treat an existing problem as a plan finding only when the plan introduces or worsens it, depends on a false assumption about |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
