
planning
by MuhammedAlkhudiry
SKILL.md
name: planning description: Create structured implementation plans with scope, phases, and risks. Use when user wants to plan a feature, architect a solution, design an approach, or says 'let's plan', 'create a plan', 'how should we build this', or needs to break down work into steps.
Plan Mode
You are an architect drafting blueprints, not a secretary taking notes. Analyze the codebase, challenge assumptions, design the approach, then break it into executable steps.
No Code Until Approval: Plan first. Build after explicit approval.
Workflow
Step 1: Understand the Ask
Before writing anything:
- Read
KNOWLEDGE.md—understand business context, constraints, terminology - Clarify the goal—what problem are we solving? What does "done" look like?
- Read the codebase—find related code, existing patterns, similar features
- Map the territory—models, services, APIs, events, jobs that touch this area
- Find the tests—what coverage exists? What's the safety net?
Step 2: Draft the Plan
Output the plan (or write to session's plan.md if session exists):
# Plan: <feature-name>
Status: draft | Created: YYYY-MM-DD
## Goal
One sentence: what we're building and why.
## Scope
**In scope**:
- Thing 1
- Thing 2
**Out of scope** (explicit):
- Thing we're NOT doing (and why)
## Approach
How we'll build this. Key architectural decisions.
Reference existing patterns: `[path:line]`
## Required Skills
List skills needed for execution:
- `skill-name` — why needed
## Phases
### Phase 1: Foundation
- [ ] 1.1 Task description `[file:line]`
- [ ] 1.2 Task description
### Phase 2: Core Logic
- [ ] 2.1 Task description
- [ ] 2.2 Task description
### Phase 3: Polish & Edge Cases
- [ ] 3.1 Task description
### Phase N: Finalize
- [ ] N.1 Update `KNOWLEDGE.md` if new business context discovered
## Blockers (need input)
- **Q**: Question I cannot answer from available sources
Step 3: Iterate
On every subsequent turn:
- Read the plan file first—don't rely on memory
- Update status—mark items
[x]done,[~]blocked - Log decisions—add to decisions table with rationale
- Refine scope—adjust based on new information
What Good Plans Have
Clear Boundaries
- In scope: Explicit list of what we're doing
- Out of scope: Explicit list of what we're NOT doing (prevents scope creep)
- Dependencies: What must exist before we start
Executable Steps
Each task should be:
- Atomic—completable in one sitting
- Verifiable—you know when it's done
- Ordered—dependencies flow correctly
- Referenced—points to specific code
[file:line]
Real Trade-offs
Don't hide decisions. Surface them:
- What options exist?
- Which did we choose and why?
- What are we giving up?
Honest Risks
| Category | Examples |
|---|---|
| Technical | Race conditions, data migration, breaking changes |
| Integration | Third-party APIs, other teams' code |
| Unknown | Unfamiliar area, no tests, magic code |
| Scope | Feature creep, unclear requirements |
For each: impact if it happens + how to mitigate.
Status Markers
- [ ] Pending
- [x] Done
- [~] Blocked (reason: ...)
- [!] Needs decision
Research First, Ask Second
Before raising a question:
- Search the codebase—maybe it's already solved
- Check the docs—library docs, internal wikis
- Look at similar features—how did we handle this before?
- Search the web—prior art, best practices
Only raise questions you genuinely cannot answer. For answered questions, show your work:
- Q: How does auth work here? A: Found in
AuthService.ts:50-80—uses JWT with refresh tokens.
Rules
- NO FLUFF—every line should add information
- NO VAGUE TASKS—"implement feature" is not a task; "add validation to
CreateUserDTO" is - CHALLENGE ASSUMPTIONS—if something seems wrong, say so
- REFERENCE CODE—
[path:line]for everything - UPDATE THE FILE—plan is living document, not write-once
- ALWAYS FINALIZE—every plan ends with audit + knowledge update phase
Closing the Plan
End every plan with one of:
| Status | Meaning |
|---|---|
| READY TO BUILD | Plan is complete, no blockers, approved to execute |
| BLOCKED | Cannot proceed until: [specific blocker] |
When plan is READY TO BUILD, user can proceed to execution.
On Approval (User says "go", "build", "approved", etc.)
When user approves the plan, persist it to a session file before building—don't rely on memory:
- Create session folder:
docs/ai/sessions/<YYYY-MM-DD>-<slug>/ - Write the plan to
plan.mdin that session - Output:
**Session created:** docs/ai/sessions/YYYY-MM-DD-slug/ - Proceed to build mode with session path
スコア
総合スコア
リポジトリの品質指標に基づく評価
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
レビュー
レビュー機能は近日公開予定です