بنقرة واحدة
review-plan
Review implementation plans for parallelization, TDD, types, libraries, and security before execution
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Review implementation plans for parallelization, TDD, types, libraries, and security before execution
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | review-plan |
| description | Review implementation plans for parallelization, TDD, types, libraries, and security before execution |
| disable-model-invocation | true |
Review implementation plans (such as those produced by a plan-writing skill) before execution.
docs/plans/2025-01-15-auth-feature.md)Before issuing any verdict — flag a gap, raise an issue, or assign a verdict — you MUST echo the exact artifact you are judging, quoted from a source you read in this turn:
The artifact is the only source of truth. Never infer what the plan says from the branch name, the working directory, surrounding files, or recollection. If your mental model differs from the freshly read source, the source wins. A verdict issued without a same-turn echo of its target is invalid — emit the echo first, or do not emit the verdict.
This gate exists because an LLM under contextual priming will confidently flag content that is not in the plan. It runs before the hard gates below.
Do not skip ahead; each step passes only when the condition is objectively satisfied (artifact path, tool success, or labeled capture—not “I read it mentally”).
Path succeeds; if not, stop and report the missing path. Pass: You can quote or point to where **Goal:**, **Architecture:**, and **Tech Stack:** appear, or you record “header field X absent” as a finding before Step 2.N/A with reason, e.g. stack not present). Do not start the Step 3 reviews until this gate passes.[plan-dir]/[plan-basename]-review.md exists; Pass: reading that path succeeds. Only then run the “Next Steps” / options prompt in Step 5.Read the plan file and extract:
Header fields:
**Goal:** - Feature description**Architecture:** - Approach summary**Tech Stack:** - Technologies usedVerify via file patterns:
.py files → Python.ts, .tsx files → TypeScript.go files → Gopytest commands → pytestvitest, jest commands → JavaScript/TypeScript testinggo test commands → Go testingLoad each applicable skill (e.g. the python-code-review skill).
Based on detected tech stack, load relevant skills:
| Detected | Skill |
|---|---|
| Python | python-code-review |
| FastAPI | fastapi-code-review |
| SQLAlchemy | sqlalchemy-code-review |
| PostgreSQL | postgres-code-review |
| pytest | pytest-code-review |
| React Router | react-router-code-review |
| React Flow | react-flow-code-review |
| shadcn/ui | shadcn-code-review |
| vitest | vitest-testing |
| Go | go-code-review |
| BubbleTea | bubbletea-code-review |
Run all five review lenses below. If the agent supports subagents, dispatch the five in parallel as separate subagents; otherwise work through them sequentially yourself, producing the same five labeled outputs. Each review receives:
Analyze whether this implementation plan can be executed by parallel subagents.
INVESTIGATE:
1. Which tasks can run in parallel (no dependencies between them)?
2. Which tasks must be sequential (Task B depends on Task A output)?
3. Are there any circular dependencies or blocking issues?
4. What is the critical path?
Return:
- Recommended batch structure for parallel execution
- Maximum concurrent agents
- Any blocking issues that prevent parallelization
Verify TDD discipline in this implementation plan.
CHECK each task for:
1. Tests written BEFORE implementation (RED phase)
2. Step to run test and verify it fails
3. Minimal implementation to make test pass (GREEN phase)
4. Tests focus on behavior, not implementation details
LOOK FOR over-engineering:
- Excessive mocking (testing implementation vs behavior)
- Too many abstraction layers
- Defensive code for impossible scenarios
- Premature optimization
Return: TDD adherence assessment and over-engineering concerns.
Verify types and APIs in the plan match the actual codebase.
SEARCH the codebase for:
1. All types referenced in the plan's code blocks
2. Existing type definitions
3. API endpoint contracts (request/response shapes)
4. Import paths
VERIFY:
1. All properties referenced exist in the types
2. Enum values match between plan and codebase
3. Import paths are correct
4. No type mismatches
Return: List of mismatches with file:line references.
Verify library usage in this plan follows best practices.
For each library referenced:
1. Are function signatures correct for current versions?
2. Are there deprecated APIs being used?
3. Does usage follow library documentation?
4. Are installation commands correct?
Check against loaded skills for technology-specific guidance.
Return: Incorrect API usage with recommendations.
Check for security gaps and missing error handling.
VERIFY:
1. Input validation at system boundaries
2. Error handling in API/DB operations
3. Auth/authz checks where needed
4. Edge cases are handled
Return: Security gaps and missing error handling.
Gate: Hard gate 3 must pass (five labeled review outputs present). Once all five lenses complete (parallel subagents or sequential passes), create the consolidated report:
## Plan Review: [Feature Name from plan]
**Plan:** `[path to plan file]`
**Tech Stack:** [Detected technologies]
### Summary Table
| Criterion | Status | Notes |
|-----------|--------|-------|
| Parallelization | ✅ GOOD / ⚠️ ISSUES | [Brief note] |
| TDD Adherence | ✅ GOOD / ⚠️ ISSUES | [Brief note] |
| Type/API Match | ✅ GOOD / ⚠️ ISSUES | [Brief note] |
| Library Practices | ✅ GOOD / ⚠️ ISSUES | [Brief note] |
| Security/Edge Cases | ✅ GOOD / ⚠️ ISSUES | [Brief note] |
### Issues Found
#### Critical (Must Fix Before Execution)
1. [Task N, Step M] ISSUE_CODE
- Issue: What's wrong
- Why: Impact if not fixed
- Fix: Specific change
- Suggested edit:
[replacement content]
#### Major (Should Fix)
2. [Task N] ISSUE_CODE
- Issue: ...
- Why: ...
- Fix: ...
#### Minor (Nice to Have)
3. [Task N] ISSUE_CODE
- Issue: ...
- Fix: ...
### Verdict
**Ready to execute?** Yes | With fixes (1-N) | No
**Reasoning:** [1-2 sentence assessment]
Gate: After writing the review file, satisfy Hard gate 4 (reading the review path succeeds) before prompting the user.
Save review to same directory as plan:
docs/plans/2025-01-15-feature.mddocs/plans/2025-01-15-feature-review.mdReview file header:
# Plan Review: [Feature Name]
> **To apply fixes:** Open new session, run:
> `Read this file, then apply the suggested fixes to [plan path]`
**Reviewed:** [Current date/time]
**Verdict:** [Yes | With fixes (1-N) | No]
---
Prompt user:
---
## Next Steps
**Review saved to:** `[review file path]`
**Options:**
1. **Apply fixes now** - Edit the plan file to address issues
2. **Save & fix later** - Open new session to apply fixes
3. **Proceed anyway** - Execute plan despite issues (not recommended for Critical)
Which option?
Use when you need a bite-sized, TDD-driven implementation plan but do NOT have a brainstorm-beagle spec to plan against. quick-plan reconstructs intent from the current conversation, fans out domain-expert exploration subagents across the codebase, and synthesizes the same plan format write-plan produces — without requiring `.beagle/concepts/<slug>/spec.md`. Triggers on: "quick plan", "plan this out", "plan what we just discussed", "turn this into an implementation plan", "plan this without a spec", "I don't have a spec, just plan it", "write-plan but no spec". Make sure to use this skill whenever the user wants an implementation or TDD plan and there is no spec to plan against — even if they just say "plan it" after discussing a feature. Writes to `.beagle/plans/<slug>/plan.md`. If a finalized spec already exists at `.beagle/concepts/<slug>/spec.md`, prefer write-plan. Does NOT brainstorm specs, write code, or execute the plan — produces the plan document (and an optional handoff prompt) only.
Use when the user has a fuzzy idea and wants to shape it into a concrete project spec before planning or building. Triggers on: "brainstorm this", "I have an idea for...", "help me think through this project", "what should I build", "spec this out". Also catches vague feature descriptions needing structured questioning to clarify scope. Does NOT write code, plan implementation, review strategy docs, or run strategy interviews — produces a WHAT/WHY spec through dialogue, not a HOW plan.
Use as the follow-up to brainstorm-beagle when a spec has an Open Questions section (or quietly carries latent gaps) that need closing before planning or implementation can begin. Triggers on: "resolve the open questions", "close the gaps in this spec", "research the open items", "finalize my spec", "make this spec implementation-ready", "answer the TBDs". Also triggers whenever the user points at a brainstorm-beagle spec and asks for research, proposals, or answers to unresolved items. Orchestrates parallel research subagents when available (falls back to inline sequential research otherwise), proposes answers one at a time for user approval, then rewrites the spec in place so it arrives at planning with no known gaps. Does NOT write code, design implementation, or create plans — it only produces a complete spec.
Use when you have a finalized brainstorm-beagle spec at `.beagle/concepts/<slug>/spec.md` and need a bite-sized, TDD-driven implementation plan before any code is written. Triggers on: "write a plan", "plan this spec", "turn the spec into a plan", "now plan the implementation", "write-plan". Reads the spec, designs the file structure, decomposes work into 2-5 minute TDD steps with exact paths and commands, self-reviews against the spec, gets user approval, then writes to `.beagle/concepts/<slug>/plan.md` and offers to generate an execution handoff prompt via the subagent-prompt skill. Does NOT brainstorm specs, write code, or execute the plan — produces the plan document (and an optional handoff prompt) only.
Core technical documentation writing principles for voice, tone, structure, and LLM-friendly patterns. Use when writing or reviewing any documentation.
Generate first-draft technical documentation from code analysis