Skip to main content

plan-plus

Brainstorming-enhanced PDCA planning with intent discovery and YAGNI review. For a single feature's plan use /plan-plus; for grouping multiple features under one scope/budget see /sprint master-plan (v2.1.13). Triggers: plan-plus, brainstorm, plan plus, intent

설치로 이동

소스 정보

저장소
ww-w-ai/bkit-claude-code
최근 소스 활동
2026년 9월 20일 03:24
감지된 SKILL.md 언어
영어
스타
600
포크
154

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
plan-plus
classification
hybrid
classification-reason
Combines workflow automation with capability-dependent features
deprecation-risk
low
effort
high
description
Brainstorming-enhanced PDCA planning with intent discovery and YAGNI review. For a single feature's plan use /plan-plus; for grouping multiple features under one scope/budget see /sprint master-plan (v2.1.13). Triggers: plan-plus, brainstorm, plan plus, intent
argument-hint
[feature]
user-invocable
true
allowed-tools
["Read","Write","Edit","Glob","Grep","Bash","Task","TaskCreate","TaskUpdate","TaskList","AskUserQuestion"]
imports
["${PLUGIN_ROOT}/templates/plan-plus.template.md"]
next-skill
pdca design
pdca-phase
plan
task-template
[Plan] {feature}
# Plan Plus — Brainstorming-Enhanced PDCA Planning > Combines brainstorming's intent discovery with bkit PDCA's structured planning to produce > higher-quality Plan documents through collaborative dialogue. ## Overview Plan Plus enhances the standard `/pdca plan` by adding 4 brainstorming phases before document generation. This ensures that user intent is fully understood, alternatives are explored, and unnecessary features are removed before any implementation begins. **When to use Plan Plus instead of `/pdca plan`:** - The feature has ambiguous or complex requirements - Multiple implementation approaches are possible - You want to ensure YAGNI compliance from the start - The feature involves significant architectural decisions ## HARD-GATE <HARD-GATE> Do NOT write any code, scaffold any project, or invoke any implementation skill until this entire process is complete and the user has approved the Plan document. This applies to EVERY feature regardless of perceived simplicity. A "simple" feature still goes through this process — the design can be short, but you MUST present it and get approval. </HARD-GATE> ## Process Flow ``` Phase 0: Context Exploration (automatic) ↓ Phase 1: Intent Discovery (1 question at a time) ↓ Phase 2: Alternatives Exploration (2-3 approaches) ↓ Phase 3: YAGNI Review (multiSelect verification) ↓ Phase 4: Incremental Design Validation (section-by-section) ↓ Phase 5: Plan Document Generation (plan-plus.template.md) ↓ Phase 6: Next Steps → /pdca design {feature} ``` ## Phase Details ### Phase 0: Project Context Exploration (Automatic) Before asking any questions, explore the current project state: 1. Read CLAUDE.md, package.json, pom.xml, etc. for project information 2. Check recent 5 git commits (understand current work direction) 3. Check existing `docs/01-plan/` documents (prevent duplication) 4. Check ongoing PDCA status — `getPdcaStatusView()` in `lib/pdca/status.js`. It reads `.bkit/state/pdca-status.json` and fills in any feature whose phase is only evidenced by its documents. `.bkit-memory.json` is NOT this store: after migration it is `.bkit/state/memory.json`, which holds the 9-phase pipeline status and nothing about PDCA phase. > Share exploration results briefly: "I've reviewed the current project state: ..." ### Phase 1: Intent Discovery (Brainstorming Style) **Principle: One question at a time, prefer multiple choice** Use `AskUserQuestion` tool to discover the following in order: #### Q1. Core Purpose "What is the core problem this feature solves?" - Provide 3-4 choices (inferred from project context) - Always include a custom input option #### Q2. Target Users "Who will primarily use this feature?" - Admin / End user / Developer / External system #### Q3. Success Criteria "What criteria would indicate this feature is successful?" - Derive specific, measurable criteria #### Q4. Constraints (only when needed) Conflicts with existing systems, performance requirements, technical constraints, etc. > **Important**: Minimize questions. Clear features need only Q1-Q2. > Only proceed to Q3-Q4 for ambiguous features. ### Phase 2: Alternatives Exploration (Brainstorming Core) **Always propose 2-3 approaches** with trade-offs for each. Format: ``` ### Approach A: {name} — Recommended - Pros: ... - Cons: ... - Best for: ... ### Approach B: {name} - Pros: ... - Cons: ... - Best for: ... ### Approach C: {name} (optional) - Pros: ... - Cons: ... ``` > Present the recommended approach first with clear reasoning. > Use AskUserQuestion to let the user choose. ### Phase 3: YAGNI Review (Brainstorming Core) Perform a YAGNI (You Ain't Gonna Need It) review on the selected approach: Use AskUserQuestion with `multiSelect: true`: "Select only what is essential for the first version:" List all features and move unselected items to Out of Scope. **Principle**: Don't abstract what can be done in 3 lines. Don't design for hypothetical future requirements. ### Phase 4: Incremental Design Validation (Brainstorming Style) Present the design section by section, getting approval after each: 1. Architecture overview → "Does this direction look right?" 2. Key components/modules → "Does this structure look right?" 3. Data flow → "Does this flow look right?" > If the user says "no" to any section, revise only that section and re-present. ### Phase 5: Plan Document Generation Generate the Plan document using `plan-plus.template.md` with results from Phases 0-4. **Additional sections** (not in standard plan.template.md): - **User Intent Discovery** — Core problem, target users, success criteria from Phase 1 - **Alternatives Explored** — Approaches compared in Phase 2 - **YAGNI Review** — Included/deferred/removed items from Phase 3 - **Brainstorming Log** — Key decisions from Phases 1-4 - **Executive Summary** -- Auto-synthesize 4-perspective summary (Problem/Solution/Function UX Effect/Core Value) from Phases 1-4 results. Place at document top, before numbered sections. - **Executive Summary Response** -- MANDATORY: After generating the Plan document, also output the Executive Summary table in your response so the user sees the summary immediately without opening the file. **Output Path**: `docs/01-plan/features/{feature}.plan.md` After document generation, the Stop hook records the phase: `scripts/plan-plus-stop.js` writes `phase = "plan"` to `.bkit/state/pdca-status.json` and creates the Task chain (`lib/task/creator.js`, which names each Task `<icon> [Plan] {feature}`). Do not write the phase by hand, and do not write it to `.bkit-memory.json` — that file is the pipeline store, not the PDCA one. State the document path in your closing output. The hook recovers the feature name from it, and without it the phase is recorded against whatever feature was current before. ### Phase 6: Next Steps After Plan document generation: ``` Plan Plus completed Document: docs/01-plan/features/{feature}.plan.md Next step: /pdca design {feature} ``` ## Key Principles | Principle | Origin | Application | |-----------|--------|-------------| | One question at a time | Brainstorming | Sequential questions via AskUserQuestion | | Explore alternatives | Brainstorming | Mandatory 2-3 approaches in Phase 2 | | YAGNI ruthlessly | Brainstorming | multiSelect verification in Phase 3 | | Incremental validation | Brainstorming | Section-by-section approval in Phase 4 | | HARD-GATE | Brainstorming | No code before approval (entire process) | | Context first | Brainstorming | Automatic exploration in Phase 0 | ## Integration with PDCA Plan Plus produces the same output as `/pdca plan` and feeds seamlessly into the standard PDCA cycle: ``` /plan-plus {feature} ← Enhanced planning with brainstorming ↓ /pdca design {feature} ← Standard PDCA continues ↓ /pdca do {feature} ↓ /pdca analyze {feature} ↓ /pdca report {feature} ``` ## Usage Examples ```bash # Start brainstorming-enhanced planning /plan-plus user-authentication # After Plan Plus completes, continue with standard PDCA /pdca design user-authentication /pdca do user-authentication ```
GitHub에서 보기