---
description: "📋 Feature planning with impact analysis, task breakdown, and effort estimation"
skills: { required: [], contextual: [auto] }
success_criteria: "plan approved by user, tasks broken down, saved to .domyh/plans/"
---

# 📋 /plan — Plan Pro

> Outcome-Focused Feature Planning
> 📚 Impact Analysis • Task Breakdown • RICE Scoring

---

## PLAN FLOW

1. **PHASE 0: DEEP INTERVIEW** — Gather context (skip if clear) → ⛔ STOP if info missing. **ONE question per message** — don't overwhelm user.
2. **PHASE 1: UNDERSTAND** — `hsa_session("plan feature: {name}")`, parse request, detect stack via HSA (`hsa_detect`), load context (`hsa_search` with `output_mode='references'` for quick overview), use `hsa_explore` for codebase overview, clarify scope
3. **PHASE 2: ANALYZE** — Impact assessment, risk analysis, dependencies. `hsa_prefetch` target files for deep analysis
4. **PHASE 3: DESIGN** — Technical design, architecture, API contracts. Propose 2-3 approaches → get user approval on direction
5. **PHASE 4: BREAKDOWN** — Task decomposition using **bite-sized granularity** (see below), effort estimation → ⛔ STOP for user approval
6. **PHASE 5: REVIEW** — Dispatch cascade reviewer for plan quality check (see `cascade-review` skill)
7. **PHASE 6: VALIDATE** — Review with user, finalize plan
8. **PHASE 7: PERSIST** — Save to `.domyh/plans/YYYY-MM-DD_{feature-slug}/plan.md`. If scope ≥ L, also save `impact.md` and `tasks.md`. Update `.agent/memory/state.json` → `phase_progress.active_plan`. Show: `📁 Saved: .domyh/plans/2026-02-12_payment-gateway/`

---

## COMMANDS

| Command                    | Description                         |
| -------------------------- | ----------------------------------- |
| `/plan [feature]`          | Full planning flow                  |
| `/plan quick [feature]`    | Rapid plan (skip Phase 0)           |
| `/plan estimate [feature]` | Effort estimation only              |
| `/plan flow [sprint]`      | Flow metrics for sprint             |
| `/plan forecast [n]`       | Forecast n items                    |
| `/plan specify [feature]`  | Spec-driven (DoR + INVEST)          |
| `/plan sprint`             | Sprint planning (DoD/DoR)           |
| `/plan uat [feature]`      | UAT scenario planning               |
| `/plan list`               | List saved plans in `.domyh/plans/` |
| `/plan open [slug]`        | Open a saved plan                   |
| `/plan compare [a] [b]`    | Compare two plan versions           |

---

## PLAN OUTPUT

```yaml
output:
  base: ".domyh/plans/"
  structure: "YYYY-MM-DD_{feature-slug}/"
  files:
    plan.md: "Main plan (always created)"
    impact.md: "Impact analysis (when scope ≥ L)"
    tasks.md: "Task breakdown (when scope ≥ L)"
  naming:
    slug: "kebab-case from plan title, max 30 chars"
    example: ".domyh/plans/2026-02-12_payment-gateway/"
  active_ref: "Update .agent/memory/state.json → phase_progress.active_plan"
  memory_sync: "Update .agent/memory/state.json with plan metadata"
```

---

## 📐 PLAN DOCUMENT HEADER (MANDATORY)

Every plan MUST start with this standardized header:

```markdown
# [Feature Name] Implementation Plan

> **For agentic workers:** Use cascade-review skill for quality assurance.
> Steps use checkbox (`- [ ]`) syntax for tracking.

**Goal:** [One sentence describing what this builds]

**Architecture:** [2-3 sentences about approach]

**Tech Stack:** [Key technologies/libraries]

---
```

---

## 🎯 BITE-SIZED TASK GRANULARITY

**Each step = ONE action (2-5 minutes):**

```markdown
### Task N: [Component Name]

**Files:**
- Create: `exact/path/to/file.ts`
- Modify: `exact/path/to/existing.ts:123-145`
- Test: `tests/exact/path/to/test.ts`

- [ ] **Step 1: Write the failing test**
- [ ] **Step 2: Run test → verify it fails**
- [ ] **Step 3: Write minimal implementation**
- [ ] **Step 4: Run test → verify it passes**
- [ ] **Step 5: Commit**
```

**Rules:** Exact file paths • Complete code (not "add validation") • Exact commands with expected output • DRY, YAGNI, TDD

---

## 💬 ONE QUESTION PER MESSAGE

<HARD-GATE>
During PHASE 0 (Interview) and PHASE 3 (Design):
- Ask exactly ONE question per message
- Wait for answer before next question
- Present 2-3 options with tradeoffs for design decisions → wait
</HARD-GATE>

---

## 🔒 UNDERSTANDING LOCK (Hard Gate — Before Design)

<HARD-GATE>
Before PHASE 3 (Design), MUST present understanding summary and get explicit confirmation:

1. Summarize understanding in 5-7 bullets:
   - Goal: [what we're building]
   - Users: [who uses it]
   - Constraints: [tech, time, budget]
   - Scope IN: [what's included]
   - Scope OUT: [what's explicitly excluded]
   - Dependencies: [what it needs to work]
   - Success criteria: [how we know it's done]

2. Ask: **"Is this understanding correct? Anything to add/change?"**

3. Only proceed to Design after explicit **"confirmed"** or equivalent.

⛔ Skip = restart Phase 0. Designing without confirmed understanding = wasted effort.
</HARD-GATE>

---

## SCOPE CHECK

If the spec covers multiple independent subsystems → suggest breaking into separate plans — one per subsystem. Each plan should produce working, testable software on its own.

---

## PHASE 0: DEEP INTERVIEW ⭐

> Skip if user already provided enough context

### 3 Golden Questions

| #   | Question                                     | Purpose          | Skip If                |
| --- | -------------------------------------------- | ---------------- | ---------------------- |
| 1   | What does this feature handle/manage?         | Domain & scope   | Request already clear   |
| 2   | Who uses it? How many users?                  | Scale & UX needs | Obvious from context    |
| 3   | Any constraints? (deadline, budget, tech)     | Boundaries       | No special constraints  |

### Follow-up Categories

| Category  | Key Questions                                     |
| --------- | ------------------------------------------------- |
| Technical | Existing endpoints? DB changes? Performance reqs? |
| Business  | Priority? Hard deadline? Success metrics?         |

---

## IMPACT ANALYSIS

| Factor           | Assessment   | Notes    |
| ---------------- | ------------ | -------- |
| Code complexity  | S/M/L/XL     | {detail} |
| Files affected   | {count}      | {list}   |
| Dependencies     | {count}      | {list}   |
| Breaking changes | Yes/No       | {detail} |
| Security impact  | Low/Med/High | {detail} |

### Risk Matrix

|                 | Low Likelihood | Medium | High |
| --------------- | -------------- | ------ | ---- |
| **High Impact** | 🟡             | 🔴     | 🔴   |
| **Med Impact**  | 🟢             | 🟡     | 🔴   |
| **Low Impact**  | 🟢             | 🟢     | 🟡   |

---

## TASK BREAKDOWN & ESTIMATION

### Effort Scale

| Size    | Time  | Examples                  |
| ------- | ----- | ------------------------- |
| **XS**  | < 1h  | Config change, copy fix   |
| **S**   | 1-4h  | Simple endpoint, UI tweak |
| **M**   | 4h-2d | Feature with tests        |
| **L**   | 2-5d  | Multi-component feature   |
| **XL**  | 1-2w  | Cross-cutting feature     |
| **XXL** | 2w+   | **Needs breakdown**       |

> Estimation rules: Include testing (20-30%), buffer (10-20%), code review time

---

## RICE SCORING

| Factor         | Scale         | Description                                        |
| -------------- | ------------- | -------------------------------------------------- |
| **R**each      | Number        | Users affected per quarter                         |
| **I**mpact     | 0.25-3        | 0.25=minimal, 0.5=low, 1=medium, 2=high, 3=massive |
| **C**onfidence | 0-100%        | How sure about estimates                           |
| **E**ffort     | Person-months | Dev time required                                  |

> Formula: `(R × I × C) / E` → Higher = prioritize
---

## REFLECTION CHECKPOINT

⛔ **MANDATORY** — Execute before completing this workflow (SESSION_005):

1. **VERIFY** — Does output meet success_criteria (see YAML frontmatter)?
2. **PERSIST** (if HSA available — preferred, 1 tool call):
   - `hsa_session({action:'persist', task_summary:'[workflow] [summary]', files_touched:[...]})`
   - If key decision → `hsa_session({action:'anchor', content:'[decision]', category:'decision'})`
3. **PERSIST** (if HSA unavailable — manual fallback):
   - Append task summary to `memory/session.md`
   - If last task → Update `memory/CONTEXT_SNAPSHOT.md`

