agentleFS
JetBrainsKnown publisherJetBrains/youtrackdb/.claude/skills/review-plan/SKILL.md

review-plan

Skill442 starsChanged 5 months agoApache-2.0View on GitHub

Manually re-run the autonomous plan review (Phase 2 — consistency + structural). The same review runs automatically as the first phase of /execute-tracks; this command is for re-runs after inline replanning or whenever the plan needs explicit re-validation. TRIGGER when: user asks to re-validate the plan after inline replanning; user requests explicit plan review outside /execute-tracks. SKIP: /execute-tracks already running State 0 in this session (autonomous Phase 2 path will fire) — do not double-run.

We split this skill into the rules it gives an agent

8 rules. 0 are common, 2 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 31 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When you Read any file under .claude/workflow/ or .claude/skills/, follow the protocol in conventions.md §1.8:

    line 10
  2. Very specific:

    Read the TOC region: from <!--Document index start--> to <!--Document index end--> (read to the closing delimiter, not a fixed line count).

    line 12
  3. Very specific:

    Use Read(offset, limit) to read only matched sections.

    line 14
  4. Distinctive:

    Read and follow the workflow for Phase 2 (Implementation Review).

    line 29
  5. Distinctive:

    Read these workflow documents in order before starting:

    line 42
  6. Very specific:

    Run the clean-tree precondition from implementation-review.md:orchestrator,reviewer-plan:2 § How to run > Precondition — path-scoped to the …

    line 84
  7. Very specific:

    After both reviews pass, write the audit summary to plan-review.md (auto-fixed/escalated listings) and record review state in the phase …

    line 100
  8. Very specific:

    Commit plan-review.md, the phase ledger, and any plan / track-file / design updates the review touched with the message Plan review …

    line 110

“Common” is measured: kept by at least 6 in 10 of the 31 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Reading workflow files (TOC protocol)

When you Read any file under .claude/workflow/ or .claude/skills/, follow the protocol in conventions.md §1.8:

  1. Read the TOC region: from <!--Document index start--> to <!--Document index end--> (read to the closing delimiter, not a fixed line count). If the file has no TOC region (a file whose only ## heading is this bootstrap block carries none, per §1.8(d)), read the file in full.
  2. Match TOC rows where Roles contains any of your roles (or your role is any, or the row's Roles is any) AND Phases contains any of your phases (or your phase is any, or the row's Phases is any).
  3. Use Read(offset, limit) to read only matched sections; if no row matches your role/phase, the file holds nothing for you — do not read further.

Your role: orchestrator or reviewer-plan (whichever invoked this skill). Your phase: 2 (Plan Review).

Inline refs you find inside workflow files carry the same name:roles:phases suffix; apply file-level filtering before opening: a ref matches when any of your roles is in its roles and any of your phases is in its phases, your own any on either axis matches every ref on that axis, and a ref whose own roles or phases is any matches you. Backtick-wrapped refs carry no suffix; open or skip them at your discretion.

<!--Document index start-->
SectionRolesPhasesSummary
§What this skill doesorchestrator,reviewer-plan2Manual entry-point steps: clean-tree check, run both reviews, apply or escalate fixes, write the audit trail, commit.
<!--Document index end-->

Read and follow the workflow for Phase 2 (Implementation Review).

House style for chat-scale prose. User-facing prose produced from this file (status updates, escalation prompts, replanning summaries, review-mode loop turns, handoff notes, whichever apply) follows the AI-tell subset of house-style.md: ## Banned sentence patterns, ## Banned analysis patterns, ## Orientation, and ## Plain language. Structural rules (§ BLUF lead, § Structural rules for the ≤200-word section cap, § Document-shape rules (design / ADR-specific)) do not apply to chat-scale prose. See conventions.md:orchestrator,reviewer-plan:2 §1.5 for the workflow-level anchor and tier mapping.

Manual override. Phase 2 normally runs autonomously as the first phase of /execute-tracks when the startup protocol detects State 0 (the phase ledger has no phase boundary yet — D3; there is no plan ## Plan Review checkbox under the thinned plan). This skill is a manual entry point for re-running the same review — useful after inline replanning has produced a revised plan, or when you want to explicitly re-validate the plan against current code without going through /execute-tracks.

Read these workflow documents in order before starting:

  1. conventions.md:orchestrator,reviewer-plan:2 — shared formats, glossary, plan file structure, scope indicators, review iteration protocol
  2. implementation-review.md:orchestrator,reviewer-plan:2 — Phase 2 orchestration: autonomous classifier flow (mechanical findings auto-fixed, design-decision findings escalated to user), audit trail, mutation discipline for design.md fixes

You are the Implementation Review Orchestrator. Your job is to validate the plan's consistency with the codebase and design document, then validate its structural quality — applying mechanical fixes autonomously and escalating only design-level decisions to the user. The full orchestration loop, classifier rules, and audit-trail format all live in implementation-review.md:orchestrator,reviewer-plan:2; this skill exists only to provide a manual entry point.

Plan directory name: if "$ARGUMENTS" is non-empty, use it as the directory name. Otherwise, default to the current git branch name (git branch --show-current).

Plan file: docs/adr/<dir-name>/_workflow/implementation-plan.md Track files directory: docs/adr/<dir-name>/_workflow/plan/ Design document: docs/adr/<dir-name>/_workflow/design.md

Each plan/track-N.md track file carries the pending track's detail across four plan-at-start sections: ## Purpose / Big Picture (BLUF + intro paragraph), ## Context and Orientation (codebase state at the start of the track plus any track-level Mermaid diagram), ## Plan of Work (prose sequence of edits, ordering constraints, invariants), and ## Interfaces and Dependencies (in-scope/out-of-scope files, inter-track dependencies, signatures). See conventions-execution.md:orchestrator:3A,3B,3C §2.1 Section lifecycle for the per-section writer/reader matrix. Phase 2 sub-agents read every pending track's track file alongside the plan to verify pending-track descriptions; pass the absolute track-files directory path as the plan_dir argument on each sub-agent spawn.


What this skill does

<!-- roles=orchestrator,reviewer-plan phases=2 summary="Manual entry-point steps: clean-tree check, run both reviews, apply or escalate fixes, write the audit trail, commit." -->
  1. Run the clean-tree precondition from implementation-review.md:orchestrator,reviewer-plan:2 § How to run > Precondition — path-scoped to the workflow files the audit-trail commit will touch (plan, plan-review.md, the phase ledger, every track file under plan/, design, design-mechanics, design-mutations). Halt and ask the user to commit or stash if any of those are dirty. Other dirty paths in the working tree are safe to ignore.
  2. Load implementation-review.md:orchestrator,reviewer-plan:2 and follow its §"Step 1: Consistency Review" → §"Step 2: Structural Review" → § "Completion" sections in order. The orchestration is identical to the autonomous State 0 path inside /execute-tracks.
  3. Apply mechanical fixes via Edit (plan / track files) or the edit-design skill (design.md — mutation discipline).
  4. Batch-escalate any design-decision findings to the user once per step. Apply user-resolved fixes the same way.
  5. After both reviews pass, write the audit summary to plan-review.md (auto-fixed/escalated listings) and record review state in the phase ledger by appending a phase=A boundary (.claude/scripts/workflow-startup-precheck.sh --append-ledger --phase A) per implementation-review.md:orchestrator,reviewer-plan:2 §"The plan-review.md document and the ledger review state" (D7). There is no plan ## Plan Review section to overwrite under the thinned plan; plan-review.md exists in every tier, so a minimal change with no plan still has a review-fact home, and a re-run appends the new verdict there and re-appends the phase=A boundary.
  6. Commit plan-review.md, the phase ledger, and any plan / track-file / design updates the review touched with the message Plan review autonomous fixes for <plan-name> and push.
  7. End the session.

The behavior is identical to the autonomous State 0 path — both share the same orchestration in implementation-review.md:orchestrator,reviewer-plan:2. The only thing this skill adds is the entry point.

Download now (ZIP)

  • Other versions32 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 32

    1. penpot/penpot★ 62ksame name
    2. wallstop/unity-helpers★ 176same name
    3. shader-slang/slangpy★ 156same name
    4. fitlab-ai/agent-infra★ 87same name
    5. microsoft/vscode-team-kit★ 64same name
    6. DasDigitaleMomentum/opencode-processing-skills★ 60same name
    7. Cleveland-RD/hivehouse★ 46same name
    8. atomicinnovation/accelerator★ 34same name
    9. hawkyre/hawk-skills★ 30same name
    10. amatray/claude-skills-public★ 9same name

    22 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use review-design, implement-plan and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • dirkkok101Skill

      review-design

      Use before /plan, after /technical-design, when user says "review design", "check the design", or when design quality is uncertain.

      Also in 3 projects that use this

    • JasonPaffSkill

      implement-plan

      Execute implementation plan with structured tracking and validation using subagent architecture

      Also in 5 projects that use this

    • NVIDIASkill

      review-code

      Review a code repository for concrete issues in correctness, robustness, security, maintainability, tests, and integration. Use for repository-wide or focused code review where practical engineering judgment and strict scope control matter.

      Also in 6 projects that use this

    • PydanticSkill

      review-security

      Security review of the current branch against its merge base — sandbox escapes, memory errors, panics and resource-limit bypasses. Use when reviewing changes for security risk, or before merging anything touching the heap/ module, path_security.rs, the wire protocol or the pool.

      Also in 3 projects that use this

    • am-willSkill

      planner

      Create comprehensive, phased implementation plans with sprints and atomic tasks. Use when user says: "make a plan", "create a plan", "plan this out", "plan the implementation", "help me plan", "design a plan", "draft a plan", "write a plan", "outline the steps", "break this down into tasks", "what's the plan for", or any similar planning request. Also triggers on explicit "/planner" or "/plan" commands.

      Also in 3 projects that use this

    • sahinSkill

      execute

      Also in 3 projects that use this

  • In this repository17 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.