popup-studio-ai/bkit-claude-code/pdca

PDCA Skill

Unified Skill for managing PDCA cycle. Supports the entire Plan → Design → Do → Check → Act flow.

Arguments

Action Details

pm (PM Analysis Phase)

Run PM Agent Team for product discovery and strategy analysis before Plan phase.

1. Call pm-lead Agent (orchestrates 4 sub-agents)
2. pm-lead runs Phase 1: Context Collection (project info, git history)
3. pm-lead runs Phase 2: Parallel Analysis (3 agents simultaneously)

• pm-discovery: Opportunity Solution Tree (Teresa Torres)
• pm-strategy: Value Proposition (JTBD 6-Part) + Lean Canvas
• pm-research: 3 Personas + 5 Competitors + TAM/SAM/SOM

1. pm-lead runs Phase 3: PRD Synthesis via pm-prd agent

• Beachhead Segment (Geoffrey Moore) + GTM Strategy
• 8-section PRD generation

1. Output PRD to docs/00-pm/{feature}.prd.md
2. Create Task: [PM] {feature}
3. Update .bkit/state/pdca-status.json: phase = "pm"
4. Guide user to next step: /pdca plan {feature}

Output Path: docs/00-pm/{feature}.prd.md

Requirements:

• Agent Teams enabled: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Project level: Dynamic or Enterprise (Starter not supported)

plan (Plan Phase)

1. Template Loading: Read ${CLAUDE_PLUGIN_ROOT}/templates/plan.template.md to understand the required Plan document structure and sections. Use this template's sections as your document outline. This is MANDATORY — do not generate Plan documents from memory or assumptions.
2. PRD Auto-Reference: Check if docs/00-pm/{feature}.prd.md exists

• If found: Read PRD and use as context for Plan document (improves quality significantly)
• If not found: Proceed normally (tip: run /pdca pm {feature} first for better results)

1. Check if docs/01-plan/features/{feature}.plan.md exists
2. If not, create based on plan.template.md
3. If exists, display content and suggest modifications
4. Checkpoint 1 — Requirements Confirmation: Present understanding of the feature (problem, scope, constraints) and use AskUserQuestion: "요구사항 이해가 맞나요? 빠진 건 없나요?" Wait for user confirmation before proceeding.
5. Checkpoint 2 — Clarifying Questions: Identify underspecified elements (edge cases, error handling, integration points, compatibility). Present organized question list. Wait for answers before generating the document.
6. Generate Plan document with user-confirmed requirements
7. Complete predecessor Task first: If a [PM] {feature} Task exists and is still in_progress, use TaskList to find it and TaskUpdate it to status: "completed" before creating the Plan Task (see Phase Transition Rule). Then Create Task: [Plan] {feature}
8. Update .bkit/state/pdca-status.json: phase = "plan"
9. Write ## Executive Summary at document top with 4-perspective table (Problem/Solution/Function UX Effect/Core Value), each 1-2 sentences
10. Context Anchor Generation: After generating Plan document, extract Context Anchor (WHY/WHO/RISK/SUCCESS/SCOPE) from Executive Summary, Requirements, and Risk sections. Write as ## Context Anchor table between Executive Summary and Section 1. This anchor propagates to Design/Do documents for cross-session context continuity.
11. MANDATORY: After completing the document, also output the Executive Summary table in your response so the user sees it immediately without opening the file

Output Path: docs/01-plan/features/{feature}.plan.md

Tip: For features with ambiguous requirements or multiple implementation approaches,

use /plan-plus {feature} instead. Plan Plus adds brainstorming phases (intent discovery,

alternatives exploration, YAGNI review) before document generation for higher-quality plans.

design (Design Phase)

1. Template Loading: Read ${CLAUDE_PLUGIN_ROOT}/templates/design.template.md to understand the required Design document structure. Use this template's sections as your document outline. This is MANDATORY — do not generate Design documents from memory or assumptions.
2. Verify Plan document exists (required - suggest running plan first if missing)
3. Read Plan document to understand requirements and scope
4. PRD Context Loading: Check if docs/00-pm/{feature}.prd.md exists. If found, read the Executive Summary and Beachhead/GTM sections to inform architecture decisions with market context. This prevents strategic context loss at the Plan→Design handoff.
5. Context Anchor Embed: Copy Plan's ## Context Anchor table to Design document top (between header metadata and ## 1. Overview). If Plan has no Context Anchor (legacy), skip this step gracefully.
6. Generate 3 Architecture Options (inspired by feature-dev Phase 4):

• Option A — Minimal Changes: Least modification, maximum reuse of existing code. Fast but potentially coupled.
• Option B — Clean Architecture: Best separation of concerns, most maintainable. More files, more refactoring.
• Option C — Pragmatic Balance: Good boundaries without over-engineering. Recommended default.

1. Present comparison table with trade-offs (complexity, maintainability, effort, risk)
2. Checkpoint 3 — Architecture Selection: Use AskUserQuestion: "3가지 설계안 중 어떤 걸 선택하시겠습니까?" Include recommendation. Wait for user selection.
3. Create docs/02-design/features/{feature}.design.md using selected architecture
4. Use design.template.md structure + reference Plan content
5. Session Guide Generation: Analyze Design's ## 11. Implementation Guide structure to generate Module Map and Recommended Session Plan. Add as ### 11.3 Session Guide within Implementation Guide section. This enables /pdca do {feature} --scope module-N for multi-session incremental implementation.
6. Design Anchor Integration (Pencil MCP): If the feature involves UI and Pencil MCP is available:

• Suggest: "UI 컨셉 페이지를 1-2개 먼저 만든 후 /design-anchor capture {feature} 로 디자인 토큰을 잠그세요"
• If Design Anchor already exists (docs/02-design/styles/{feature}.design-anchor.md), embed it in the Design document as ## Design Anchor section
• This ensures design tokens (colors, typography, spacing) are locked before implementation

1. Complete predecessor Task first: Use TaskList to find the [Plan] {feature} Task (and any earlier phase Task for this feature still in_progress) and TaskUpdate each to status: "completed" — this resolves the blockedBy chain and prevents stale phase status from leaking into prompt context (see Phase Transition Rule). Then Create Task: [Design] {feature} (blockedBy: Plan task)
2. Update .bkit/state/pdca-status.json: phase = "design"

Output Path: docs/02-design/features/{feature}.design.md

do (Do Phase)

1. Verify Design document exists (required)
2. Read Design document FULLY (read the entire document, not just a summary. This is critical — full context reload ensures each session starts with complete architectural context)
3. Full Upstream Context Loading (Phase 2+3): Load the COMPLETE upstream document chain:

• Read PRD (docs/00-pm/{feature}.prd.md) — extract WHY context (JTBD, value proposition, market positioning)
• Read Plan (docs/01-plan/features/{feature}.plan.md) — extract Context Anchor, Success Criteria, Requirements
• This ensures implementation decisions are guided by strategic intent from PRD→Plan→Design, not just the Design spec

1. Decision Record Chain Display: Extract and display key decisions from PRD→Plan→Design as a unified chain. Format:

`` 📋 Decision Record Chain [PRD] Target: {market/user segment} — {rationale} [Plan] Architecture: {selected option} — {rationale} [Design] State Mgmt: {selected approach} — {rationale} ``

1. Success Criteria Tracking: Extract Success Criteria from Plan document. Display as implementation checklist — each criterion must be addressed during implementation. Mark criteria that are covered by the current --scope.
2. Parse --scope parameter: If arguments contain --scope <value>, extract module list (comma-separated scope keys). Match against Design's Session Guide Module Map. Filter implementation items to show only matching modules.
3. Display Context Anchor: Show the Context Anchor table from Design document header. Format: "📌 Context Anchor" + WHY/WHO/RISK/SUCCESS/SCOPE table. This reminds the user WHY we're building this feature.
4. Session Guide Display:

• If no --scope: Show full Module Map from Design + recommend session split + proceed with full implementation guide
• If --scope provided: Show only the selected modules' implementation items

1. Summarize implementation scope:

• Files to create: N
• Files to modify: M
• Estimated changes: ~X lines

1. Checkpoint 4 — Implementation Approval: Present scope summary and use AskUserQuestion: "이 범위로 구현을 시작해도 되겠습니까?" DO NOT START IMPLEMENTATION WITHOUT USER APPROVAL.
2. After approval, provide implementation guide based on do.template.md
3. Reference implementation order from Design document (filtered by --scope if provided)
4. Code Comment Convention (Phase 3): During implementation, add Design reference comments for key architectural decisions:

• At module/file level: // Design Ref: §{section} — {decision rationale}
• At critical logic: // Plan SC: {success criteria being addressed}
• These comments create traceable links from code back to design decisions

1. Complete predecessor Task first: Use TaskList to find the [Design] {feature} Task (and any earlier phase Task for this feature still in_progress) and TaskUpdate each to status: "completed" — this resolves the blockedBy chain and prevents stale phase status from leaking into prompt context (see Phase Transition Rule). Then Create Task: [Do] {feature} (blockedBy: Design task)
2. Update .bkit/state/pdca-status.json: phase = "do"

--scope Parameter:

/pdca do feature                      # Full scope (backward compatible) + session guide
/pdca do feature --scope module-1     # Only module-1
/pdca do feature --scope module-1,module-2  # Multiple modules

Guide Provided:

• Context Anchor (WHY/WHO/RISK/SUCCESS/SCOPE)
• Session scope (filtered or full)
• Implementation order checklist
• Key files/components list
• Dependency installation commands

analyze (Check Phase)