Plan PlusSAFE

bkit Vibecoding Kit - PDCA methodology + Claude Code mastery for AI-native development

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
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 1.5: Premise Challenge (forcing questions, agreed premises)
    ↓
Phase 2: Alternatives Exploration (2-3 approaches, incl. "do nothing")
    ↓
Phase 3: Scope Mode + YAGNI Review (multiSelect verification)
    ↓
Phase 4: Incremental Design Validation (section-by-section, failure map)
    ↓
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 1.5: Premise Challenge

Phase 1 records what the user wants. This phase tests whether it is worth
building in that shape. Ask one forcing question at a time with
`AskUserQuestion`, and push on vague answers once before moving on.

| # | Forcing question | A strong answer names |
|---|------------------|----------------------|
| F1 | **Demand** — Who would be genuinely upset if this did not exist next month? | A specific person or role, not a segment |
| F2 | **Status quo** — What do those users do today to get this done, even badly? | The current workaround and what it costs them |
| F3 | **Wedge** — What is the smallest version that someone would use this week? | One flow, not a feature list |
| F4 | **Do nothing** — What happens if we build nothing? | A concrete cost, or an admission that there is none |

Routing — ask only what the feature needs:
- New product or user-facing capability: F1-F4
- Internal tool or refactor: F2, F4
- Bug fix or small change: skip this phase and say so

**Stance rules**
- Take a position on every answer and state what evidence would change it.
  Do not reply with neutral filler ("That could work", "Interesting approach").
- Enthusiasm is not evidence of demand; a workaround the user already pays for is.
- If the user wants to move on, ask the single most important remaining question,
  then proceed. Do not ask a third time.

Close the phase by printing the agreed premises as a numbered list and asking
the user to confirm them:

```
PREMISES
1. {who needs this, and why now}
2. {what they do today}
3. {the smallest useful version}
```

If the user rejects a premise, revise it before Phase 2 — alternatives built on
a rejected premise are wasted work. Record the confirmed premises in the Plan
document's "Premise Challenge" section.

### Phase 2: Alternatives Exploration (Brainstorming Core)

**Always propose 2-3 approaches** with trade-offs for each. When Phase 1.5 ran,
one o

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.