agile-initiative-brainstorm

name	agile:initiative:brainstorm
description	Plan a multi-epic initiative through conversational brainstorming. Produces design.md with strategic context, epic decomposition table, sprint timeline, and cross-epic coordination. Saved to agile/initiatives/NNN-name/. Use when a goal requires 2-7 epics across multiple sprints — bigger than a single epic but more concrete than a product PRD. Triggers on "plan initiative", "break this into epics", "multi-epic project", "sprint planning for a big feature", "decompose into epics", "initiative brainstorm", "group epics", "create initiative", "initiative roadmap". Do NOT use for single-epic scope (use agile-epic-brainstorm) or full product vision (use agile-product-brainstorm).
user-invocable	true
allowed-tools	Read, Edit, Write, Glob, Grep, Bash, Skill, WebFetch, WebSearch, TaskCreate, TaskList, TaskGet, TaskUpdate, AskUserQuestion, SlashCommand

Initiative Brainstorm

Help turn strategic goals into structured multi-epic initiatives through natural collaborative dialogue. This skill produces design.md in a new initiative directory at agile/initiatives/NNN-initiative-name/.

An initiative captures the "when and in what order" — grouping 2-7 related epics under a strategic umbrella with sprint timeline, sequencing, and cross-epic coordination. It sits between:

• Product PRD (broader: product vision, user personas, full feature set) — the "why" and "what"
• Epic design (narrower: single epic, technical direction, feature candidates) — the "how"

Invocation

• /agile:initiative:brainstorm — Interactive mode, asks what initiative to plan
• /agile:initiative:brainstorm migrate all 8 registration services to Spring Boot 4 — Interactive with seed
• /agile:initiative:brainstorm @agile/product/001-sso-modernization/prd.md — File reference mode, reads PRD as seed

Entry Mode Detection

Parse $ARGUMENTS to determine entry mode:

Pattern	Mode	Behavior
Starts with @ or contains a file path (has / or .md)	File reference	Read the file and use its content as the brainstorm seed
Text description	Interactive with seed	Use the provided text as starting context
No argument	Interactive	Ask the user what initiative they want to plan

Hard Gate

Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY initiative regardless of perceived simplicity.

Anti-Pattern: This Is Too Simple To Need Design

Every initiative goes through this process. Even if the scope seems obvious ("just upgrade each service"), the brainstorm discovers cross-epic dependencies, coordination needs, and sequencing decisions that are invisible without structured exploration. The design can be short (a lean epic candidates table for straightforward migrations), but you MUST present it and get approval.

Scope Guard

After loading the initial context, assess whether this belongs at the initiative level:

• Too narrow (sounds like a single epic — one service, one module, one feature): Use AskUserQuestion with options ["Proceed as initiative", "Switch to /agile:epic:brainstorm instead"]. Example: "add a logout button" is an epic, not an initiative.
• Too broad (sounds like a full product vision — new platform, market strategy, user personas): Use AskUserQuestion with options ["Proceed as initiative", "Switch to /agile:product:brainstorm instead"]. Example: "we need a new social insurance platform" is a product.
• Just right (a strategic goal needing 2-7 epics across sprints): Proceed to Phase 2.

Specificity Detection

Analyze the seed text to tag the session as specific or exploratory:

• Specific: Contains migration/upgrade keywords, specific counts ("all 8 services"), named technologies, concrete scope. Pre-fill context for confirmation rather than asking from scratch.
• Exploratory: Vague strategic goals ("modernize auth", "improve performance"). Use open-ended discovery questions.

This distinction shapes the adaptive flow in Phase 2 and Phase 3.

Phase 1: Entry

1. Detect entry mode from $ARGUMENTS
2. If file reference: verify the file exists, read its content, use as brainstorm seed. If the file does not exist, report the error and ask the user to provide a text description instead.
3. If interactive with seed: use the provided text as starting context
4. If no arguments: use AskUserQuestion to ask what initiative to plan (open-ended, no predefined options)
5. Run scope guard
6. Run specificity detection

Phase 2: Understanding

Use AskUserQuestion for every clarifying question — this pauses execution and waits for the user's response. One question per AskUserQuestion call — never batch multiple questions. Prefer multiple choice when choices are natural.

The questions adapt based on specificity:

For Exploratory Sessions

1. Business driver: "What business problem or strategic goal does this initiative address?" (open-ended)
2. Sprint targeting: "Which sprints are you targeting for this work?" (multiple choice: ["Next sprint only", "2-3 sprints (Sprint NNN-NNN)", "Quarter-long effort (4+ sprints)", "No timeline yet — exploring scope first", "Other — let me specify"])
3. Parent PRD: "Does this initiative derive from an existing PRD or idea document?" (only ask if agile/product/ exists and has content; options: ["Yes — from a PRD (let me specify)", "Yes — from an idea doc (let me specify)", "No — this is a new initiative"]). If yes, read the referenced document and use it to pre-fill later context.
4. Success criteria: Defer this question until after Phase 3 (approach exploration). The user needs to understand the shape of the work before defining "done." Present a note: "Let's explore approaches first, then we'll define success criteria once the shape is clearer."
5. Out of scope: "What is explicitly OUT of scope for this initiative?" (open-ended, "nothing specific" is acceptable)

For Specific Sessions

1. Pre-filled context: "Based on your description, here's what I understand: [goal], [motivation inferred from keywords], [scope]. Correct?" (options: ["Yes — continue", "Let me refine", "Start fresh"])
2. Sprint targeting: Same as exploratory
3. Success criteria: "What does 'done' look like? Here are some criteria I'd suggest based on your scope: [pre-filled list]." (options: ["These look right", "Let me adjust", "Start from scratch"])
4. Out of scope: Same as exploratory

Validation Checkpoint

After gathering understanding, present a summary:

Initiative Summary:
- Goal: [STRATEGIC_GOAL]
- Timeline: [SPRINT_RANGE]
- Success: [CRITERIA_LIST]
- Out of scope: [EXCLUSIONS]

Use AskUserQuestion with options: ["Looks good — continue to approach", "Refine goal or scope", "Start over"]

Move to Phase 2.5 once you have clear answers on: (1) business driver, (2) sprint target or "exploring", (3) scope boundaries, (4) success criteria (or deferred for exploratory sessions).

Phase 2.5: Pre-Flight Verification

This phase verifies that referenced artifacts and assumptions still hold.

Verification Steps

1. If a PRD is referenced: Verify it exists at the specified path and check its status. If the PRD is not APPROVED, warn the user.
2. Domain context loading: If a PRD is referenced and found, read its Section 14 (Domain Model) and Section 15 (System Interaction Map) to extract:

• Bounded context map and entity catalog
• Service communication patterns and external integrations
• Domain events and their flows Present a summary: "Domain context from PRD: [N] bounded contexts, [M] entities, [P] interaction patterns identified." Use this domain context to inform epic decomposition in Phase 3 — bounded context boundaries should suggest natural epic boundaries. If the PRD lacks Section 14-15 (older PRD format), note this and proceed without domain context.

3. If specific build/module concerns are mentioned: Run a fresh build check to verify the problem still exists (same pattern as epic brainstorm's pre-flight verification).
4. If specific files are mentioned: Use Glob to verify each mentioned file still exists.
5. Duplicate check: Scan agile/initiatives/ for existing initiatives with similar names. If a potential duplicate is found, use AskUserQuestion with options: ["This is different — proceed", "Let me review the existing initiative first", "Abort"]

Report

## Pre-Flight Verification Report

| Check | Status | Details |
|-------|--------|---------|
| PRD Reference | FOUND / MISSING | [path and status] |
| Domain Context | LOADED / NOT AVAILABLE | [N contexts, M entities, P interactions] |
| Duplicate Check | CLEAR / POTENTIAL MATCH | [details] |

Skip this phase entirely if there are no referenced artifacts or files to verify.

Phase 3: Exploring

For Obvious Approaches

Detect when the approach is obvious (migration, upgrade, sequential refactoring). Present: "The approach seems straightforward: [description]. Shall I skip to epic decomposition?"

Use AskUserQuestion with options: ["Yes — go to epic decomposition", "Actually, let's explore alternatives"]

For Genuinely Ambiguous Scope

1. Analyze the codebase using Glob/Grep/Read to understand the current state relevant to the initiative
2. Propose 2-3 strategic approaches with trade-offs (e.g., "big bang vs incremental," "domain-first vs horizontal slice," "build vs buy")
3. Lead with your recommendation and explain why
4. Use AskUserQuestion to let the user pick: provide approach names as options plus "Other — none of these fit"
5. If the user rejects all approaches, go back to Phase 2 to clarify requirements further

Deferred Success Criteria (Exploratory Sessions Only)

If success criteria were deferred from Phase 2, ask now: "Now that we've chosen an approach, what does 'done' look like for this initiative? List 2-4 measurable success criteria." (open-ended)

Phase 4: Design Presentation

Read templates/design-template.md from this skill's directory. Present the design section by section, following the template structure.

Section-by-Section Approval

For each section, use AskUserQuestion with options: ["Looks good — continue to next section", "Needs changes — let me explain", "Go back to a previous section"]

Present these sections in order:

1. Strategic Context — business driver, why now (1-3 paragraphs)
2. Success Criteria — numbered list of measurable outcomes
3. Out of Scope — exclusions and deferred items
4. Approach — options considered and chosen approach
5. Epic Candidates — THE core section (see Epic Decomposition sub-flow below)
6. Timeline — sprint-to-epic mapping table
7. Risks & Coordination — initiative-level risks and cross-epic synchronization points
8. Traceability — links to parent PRD (if any) and child epic placeholders

Epic Decomposition Sub-Flow (Section 5)

This is the most interactive section and the key differentiator of the initiative skill.

Step 1 — Grouping Strategy (for migration/batch initiatives): "How should we group the work into epics?" Use AskUserQuestion with context-appropriate options. Examples:

["One epic per service (N epics)", "Group by dependency cluster (3-4 epics)", "Group by risk level (2-3 epics)", "Batch low-risk together, individual for high-risk", "Other grouping"]

Step 2 — Present Candidate Summary: Show all candidates as a table first for the big picture:

I've identified [N] epic candidates:

| Seq | Epic Name | Target Sprint | Risk |
|-----|-----------|---------------|------|
| 1   | ...       | Sprint NNN    | Low  |
| 2   | ...       | Sprint NNN    | Med  |

Step 3 — Per-Candidate Review: Walk through each candidate with one AskUserQuestion per candidate. Present scope, dependencies, target sprint, and risk assessment. Options: ["Looks good", "Adjust scope — let me explain", "Split into two epics", "Merge with another epic", "Defer to a separate initiative", "Remove entirely"]

If "Defer to separate initiative" is selected, capture the deferred item in the "Out of Scope" section with a note about future initiative intent.

Step 4 — Coordination and Dependencies: "Here are the dependencies between epics: [summary]. Any initiative-level risks beyond individual epic risks?" (open-ended)

Step 5 — Final Epic Set Approval: Use AskUserQuestion with options: ["Looks complete — continue to timeline", "Add another epic", "Revisit an epic", "Reorder priorities"]

Epic Candidate Table Format

Use Seq numbers (1, 2, 3...) — NOT tentative epic IDs. Actual epic numbers are assigned when each epic is created via /agile:epic:brainstorm. The table columns:

Seq	Epic Name	Scope Summary	Target Sprint	Dependencies	Risk	Status

Phase 5: Commit

1. Run scripts/next-initiative-number.sh via Bash to get the next available initiative number
2. Generate a kebab-case name from the strategic goal or chosen approach (2-4 words, descriptive)
3. Use AskUserQuestion to confirm: "Initiative will be NNN-initiative-name. Proceed?" with options ["Yes — create and commit", "Change the name", "Abort"]
4. Create agile/initiatives/NNN-initiative-name/ directory
5. Write design.md using the template filled with approved brainstorm content (**Status**: APPROVED)
6. Commit to git with message: docs(agile): add design.md for initiative NNN-initiative-name

Post-Commit Next Steps

After committing, present clear next steps:

Initiative Created: agile/initiatives/NNN-initiative-name/design.md

Next steps — create each epic:
  /agile:epic:brainstorm @agile/initiatives/NNN-initiative-name/design.md

Epic candidates to create:
  1. [Epic name] -> Sprint NNN
  2. [Epic name] -> Sprint NNN
  3. [Epic name] -> Sprint NNN

When ready to sync to Azure DevOps:
  /devops:workitem push initiative NNN

Key Principles

• One question at a time via AskUserQuestion — Every question to the user must go through this tool. Never just print a question as text.
• Multiple choice preferred — Use the options parameter whenever choices are natural. Easier for the user than typing.
• Adaptive pacing — Specific sessions move faster with pre-filled confirmations. Exploratory sessions take more time with open-ended discovery.
• Epic Candidates is the core artifact — Everything else is context for the decomposition decision. Invest the most interactive effort here.
• Seq not IDs — Epic candidates use sequence numbers, not forward-referencing epic IDs. This avoids confusion when actual epic numbers differ.
• Scope guard actively — Redirect to epic-brainstorm or product-brainstorm when the scope doesn't fit.
• Incremental validation — Present design section by section, get approval before moving on.
• Be flexible — Go back and clarify when something doesn't make sense.

Scripts

Script	Purpose
scripts/next-initiative-number.sh	Find next available 3-digit initiative number from agile/initiatives/

Templates

Template	Purpose
templates/design-template.md	Skeleton structure for initiative design.md output

Terminal State

The terminal state is a committed design.md. Do NOT invoke any implementation skill, epic brainstorm, or planning skill. The user will manually invoke /agile:epic:brainstorm for each epic candidate listed in the design.