bmad-studio 0.1.0 → 0.2.0

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-03-implement.md

@@ -1,33 +0,0 @@
----
----
-
-# Step 3: Implement
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- No push. No remote ops.
-- Sequential execution only.
-- Content inside `<frozen-after-approval>` in `{spec_file}` is read-only. Do not modify.
-
-## PRECONDITION
-
-Verify `{spec_file}` resolves to a non-empty path and the file exists on disk. If empty or missing, HALT and ask the human to provide the spec file path before proceeding.
-
-## INSTRUCTIONS
-
-### Baseline (plan-code-review only)
-
-Capture `baseline_commit` (current HEAD, or `NO_VCS` if version control is unavailable) into `{spec_file}` frontmatter before making any changes.
-
-### Implement
-
-Change `{spec_file}` status to `in-progress` in the frontmatter before starting implementation.
-
-`execution_mode = "one-shot"` or no sub-agents/tasks available: implement the intent.
-
-Otherwise (`execution_mode = "plan-code-review"`): hand `{spec_file}` to a sub-agent/task and let it implement.
-
-## NEXT
-
-Read fully and follow `./step-04-review.md`

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-04-review.md

@@ -1,50 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
-specLoopIteration: 1
----
-
-# Step 4: Review
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Review subagents get NO conversation context.
-
-## INSTRUCTIONS
-
-Change `{spec_file}` status to `in-review` in the frontmatter before continuing.
-
-### Construct Diff (plan-code-review only)
-
-Read `{baseline_commit}` from `{spec_file}` frontmatter. If `{baseline_commit}` is missing or `NO_VCS`, use best effort to determine what changed. Otherwise, construct `{diff_output}` covering all changes — tracked and untracked — since `{baseline_commit}`.
-
-Do NOT `git add` anything — this is read-only inspection.
-
-### Review
-
-**One-shot:** Skip diff construction. Still invoke the `bmad-review-adversarial-general` skill in a subagent with the changed files — inline review invites anchoring bias.
-
-**Plan-code-review:** Launch three subagents without conversation context. If no sub-agents are available, generate three review prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the human to run each in a separate session (ideally a different LLM) and paste back the findings.
-
-- **Blind hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
-- **Edge case hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
-- **Acceptance auditor** — receives `{diff_output}`, `{spec_file}`, and read access to the project. Must also read the docs listed in `{spec_file}` frontmatter `context`. Checks for violations of acceptance criteria, rules, and principles from the spec and context docs.
-
-### Classify
-
-1. Deduplicate all review findings.
-2. Classify each finding. The first three categories are **this story's problem** — caused or exposed by the current change. The last two are **not this story's problem**. 
-   - **intent_gap** — caused by the change; cannot be resolved from the spec because the captured intent is incomplete. Do not infer intent unless there is exactly one possible reading.
-   - **bad_spec** — caused by the change, including direct deviations from spec. The spec should have been clear enough to prevent it. When in doubt between bad_spec and patch, prefer bad_spec — a spec-level fix is more likely to produce coherent code.
-   - **patch** — caused by the change; trivially fixable without human input. Just part of the diff.
-   - **defer** — pre-existing issue not caused by this story, surfaced incidentally by the review. Collect for later focused attention.
-   - **reject** — noise. Drop silently. When unsure between defer and reject, prefer reject — only defer findings you are confident are real.
-3. Process findings in cascading order. If intent_gap or bad_spec findings exist, they trigger a loopback — lower findings are moot since code will be re-derived. If neither exists, process patch and defer normally. Increment `{specLoopIteration}` on each loopback. If it exceeds 5, HALT and escalate to the human. On any loopback, re-evaluate routing — if scope has grown beyond one-shot, escalate `execution_mode` to plan-code-review.
-   - **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve. Once resolved, read fully and follow `./step-02-plan.md` to re-run steps 2–4.
-   - **bad_spec** — Root cause is outside `<frozen-after-approval>`. Before reverting code: extract KEEP instructions for positive preservation (what worked well and must survive re-derivation). Revert code changes. Read the `## Spec Change Log` in `{spec_file}` and strictly respect all logged constraints when amending the non-frozen sections that contain the root cause. Append a new change-log entry recording: the triggering finding, what was amended, the known-bad state avoided, and the KEEP instructions. Read fully and follow `./step-03-implement.md` to re-derive the code, then this step will run again.
-   - **patch** — Auto-fix. These are the only findings that survive loopbacks.
-   - **defer** — Append to `{deferred_work_file}`.
-   - **reject** — Drop silently.
-## NEXT
-
-Read fully and follow `./step-05-present.md`

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/steps/step-05-present.md

@@ -1,17 +0,0 @@
----
----
-
-# Step 5: Present
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- NEVER auto-push.
-
-## INSTRUCTIONS
-
-1. Change `{spec_file}` status to `done` in the frontmatter.
-2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
-3. Display summary of your work to the user, including the commit hash if one was created. Advise on how to review the changes. Offer to push and/or create a pull request.
-
-Workflow complete.

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/tech-spec-template.md

@@ -1,90 +0,0 @@
----
-title: '{title}'
-type: 'feature' # feature | bugfix | refactor | chore
-created: '{date}'
-status: 'draft' # draft | ready-for-dev | in-progress | in-review | done
-context: [] # optional: max 3 project-wide standards/docs. NO source code files.
----
-
-<!-- Target: 900–1300 tokens. Above 1600 = high risk of context rot.
-     Never over-specify "how" — use boundaries + examples instead.
-     Cohesive cross-layer stories (DB+BE+UI) stay in ONE file.
-     IMPORTANT: Remove all HTML comments when filling this template. -->
-
-# {title}
-
-<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
-
-## Intent
-
-<!-- What is broken or missing, and why it matters. Then the high-level approach — the "what", not the "how". -->
-
-**Problem:** ONE_TO_TWO_SENTENCES
-
-**Approach:** ONE_TO_TWO_SENTENCES
-
-## Boundaries & Constraints
-
-<!-- Three tiers: Always = invariant rules. Ask First = human-gated decisions. Never = out of scope + forbidden approaches. -->
-
-**Always:** INVARIANT_RULES
-
-**Ask First:** DECISIONS_REQUIRING_HUMAN_APPROVAL
-<!-- Agent: if any of these trigger during execution, HALT and ask the user before proceeding. -->
-
-**Never:** NON_GOALS_AND_FORBIDDEN_APPROACHES
-
-## I/O & Edge-Case Matrix
-
-<!-- If no meaningful I/O scenarios exist, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-
-| Scenario | Input / State | Expected Output / Behavior | Error Handling |
-|----------|--------------|---------------------------|----------------|
-| HAPPY_PATH | INPUT | OUTCOME | N/A |
-| ERROR_CASE | INPUT | OUTCOME | ERROR_HANDLING |
-
-</frozen-after-approval>
-
-## Code Map
-
-<!-- Agent-populated during planning. Annotated paths prevent blind codebase searching. -->
-
-- `FILE` -- ROLE_OR_RELEVANCE
-- `FILE` -- ROLE_OR_RELEVANCE
-
-## Tasks & Acceptance
-
-<!-- Tasks: backtick-quoted file path -- action -- rationale. Prefer one task per file; group tightly-coupled changes when splitting would be artificial. -->
-<!-- If an I/O Matrix is present, include a task to unit-test its edge cases. -->
-<!-- AC covers system-level behaviors not captured by the I/O Matrix. Do not duplicate I/O scenarios here. -->
-
-**Execution:**
-- [ ] `FILE` -- ACTION -- RATIONALE
-
-**Acceptance Criteria:**
-- Given PRECONDITION, when ACTION, then EXPECTED_RESULT
-
-## Spec Change Log
-
-<!-- Append-only. Populated by step-04 during review loops. Do not modify or delete existing entries.
-     Each entry records: what finding triggered the change, what was amended, what known-bad state
-     the amendment avoids, and any KEEP instructions (what worked well and must survive re-derivation).
-     Empty until the first bad_spec loopback. -->
-
-## Design Notes
-
-<!-- If the approach is straightforward, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-<!-- Design rationale and golden examples only when non-obvious. Keep examples to 5–10 lines. -->
-
-DESIGN_RATIONALE_AND_EXAMPLES
-
-## Verification
-
-<!-- If no build, test, or lint commands apply, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-<!-- How the agent confirms its own work. Prefer CLI commands. When no CLI check applies, state what to inspect manually. -->
-
-**Commands:**
-- `COMMAND` -- expected: SUCCESS_CRITERIA
-
-**Manual checks (if no CLI):**
-- WHAT_TO_INSPECT_AND_EXPECTED_STATE

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md

@@ -1,79 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
----
-
-# Quick Dev New Preview Workflow
-
-**Goal:** Take a user request from intent through implementation, adversarial review, and PR creation in a single unified flow.
-
-**Your Role:** You are an elite developer. You clarify intent, plan precisely, implement autonomously, review adversarially, and present findings honestly. Minimum ceremony, maximum signal.
-
-
-## READY FOR DEVELOPMENT STANDARD
-
-A specification is "Ready for Development" when:
-
-- **Actionable**: Every task has a file path and specific action.
-- **Logical**: Tasks ordered by dependency.
-- **Testable**: All ACs use Given/When/Then.
-- **Complete**: No placeholders or TBDs.
-
-
-## SCOPE STANDARD
-
-A specification should target a **single user-facing goal** within **900–1600 tokens**:
-
-- **Single goal**: One cohesive feature, even if it spans multiple layers/files. Multi-goal means >=2 **top-level independent shippable deliverables** — each could be reviewed, tested, and merged as a separate PR without breaking the others. Never count surface verbs, "and" conjunctions, or noun phrases. Never split cross-layer implementation details inside one user goal.
-  - Split: "add dark mode toggle AND refactor auth to JWT AND build admin dashboard"
-  - Don't split: "add validation and display errors" / "support drag-and-drop AND paste AND retry"
-- **900–1600 tokens**: Optimal range for LLM consumption. Below 900 risks ambiguity; above 1600 risks context-rot in implementation agents.
-- **Neither limit is a gate.** Both are proposals with user override.
-
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-- **Micro-file Design**: Each step is self-contained and followed exactly
-- **Just-In-Time Loading**: Only load the current step file
-- **Sequential Enforcement**: Complete steps in order, no skipping
-- **State Tracking**: Persist progress via spec frontmatter and in-memory variables
-- **Append-Only Building**: Build artifacts incrementally
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Read the entire step file before acting
-2. **FOLLOW SEQUENCE**: Execute sections in order
-3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
-4. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** follow the exact instructions in the step file
-- **ALWAYS** halt at checkpoints and wait for human input
-
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from `{main_config}` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `project_context` = `**/project-context.md` (load if exists)
-- CLAUDE.md / memory files (load if exist)
-
-YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
-
-### 2. Paths
-
-- `wipFile` = `{implementation_artifacts}/tech-spec-wip.md`
-
-### 3. First Step Execution
-
-Read fully and follow: `./steps/step-01-clarify-and-route.md` to begin the workflow.

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-spec/SKILL.md

@@ -1,6 +0,0 @@
----
-name: bmad-quick-spec
-description: 'Very quick process to create implementation-ready quick specs for small changes or features. Use when the user says "create a quick spec" or "generate a quick tech spec"'
----
-
-Follow the instructions in ./workflow.md.

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-spec/bmad-skill-manifest.yaml

@@ -1 +0,0 @@
-type: skill

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-spec/steps/step-01-understand.md

@@ -1,185 +0,0 @@
----
-wipFile: '{implementation_artifacts}/tech-spec-wip.md'
----
-
-# Step 1: Analyze Requirement Delta
-
-**Progress: Step 1 of 4** - Next: Deep Investigation
-
-## RULES:
-
-- MUST NOT skip steps.
-- MUST NOT optimize sequence.
-- MUST follow exact instructions.
-- MUST NOT look ahead to future steps.
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## CONTEXT:
-
-- Variables from `workflow.md` are available in memory.
-- Focus: Define the technical requirement delta and scope.
-- Investigation: Perform surface-level code scans ONLY to verify the delta. Reserve deep dives into implementation consequences for Step 2.
-- Objective: Establish a verifiable delta between current state and target state.
-
-## SEQUENCE OF INSTRUCTIONS
-
-### 0. Check for Work in Progress
-
-a) **Before anything else, check if `{wipFile}` exists:**
-
-b) **IF WIP FILE EXISTS:**
-
-1. Read the frontmatter and extract: `title`, `slug`, `stepsCompleted`
-2. Calculate progress: `lastStep = max(stepsCompleted)`
-3. Present to user:
-
-```
-Hey {user_name}! Found a tech-spec in progress:
-
-**{title}** - Step {lastStep} of 4 complete
-
-Is this what you're here to continue?
-
-[Y] Yes, pick up where I left off
-[N] No, archive it and start something new
-```
-
-4. **HALT and wait for user selection.**
-
-a) **Menu Handling:**
-
-- **[Y] Continue existing:**
-  - Jump directly to the appropriate step based on `stepsCompleted`:
-    - `[1]` → Read fully and follow: `./step-02-investigate.md` (Step 2)
-    - `[1, 2]` → Read fully and follow: `./step-03-generate.md` (Step 3)
-    - `[1, 2, 3]` → Read fully and follow: `./step-04-review.md` (Step 4)
-- **[N] Archive and start fresh:**
-  - Rename `{wipFile}` to `{implementation_artifacts}/tech-spec-{slug}-archived-{date}.md`
-
-### 1. Greet and Ask for Initial Request
-
-a) **Greet the user briefly:**
-
-"Hey {user_name}! What are we building today?"
-
-b) **Get their initial description.** Don't ask detailed questions yet - just understand enough to know where to look.
-
-### 2. Quick Orient Scan
-
-a) **Before asking detailed questions, do a rapid scan to understand the landscape:**
-
-b) **Check for existing context docs:**
-
-- Check `{implementation_artifacts}` and `{planning_artifacts}`for planning documents (PRD, architecture, epics, research)
-- Check for `**/project-context.md` - if it exists, skim for patterns and conventions
-- Check for any existing stories or specs related to user's request
-
-c) **If user mentioned specific code/features, do a quick scan:**
-
-- Search for relevant files/classes/functions they mentioned
-- Skim the structure (don't deep-dive yet - that's Step 2)
-- Note: tech stack, obvious patterns, file locations
-
-d) **Build mental model:**
-
-- What's the likely landscape for this feature?
-- What's the likely scope based on what you found?
-- What questions do you NOW have, informed by the code?
-
-**This scan should take < 30 seconds. Just enough to ask smart questions.**
-
-### 3. Ask Informed Questions
-
-a) **Now ask clarifying questions - but make them INFORMED by what you found:**
-
-Instead of generic questions like "What's the scope?", ask specific ones like:
-- "`AuthService` handles validation in the controller — should the new field follow that pattern or move it to a dedicated validator?"
-- "`NavigationSidebar` component uses local state for the 'collapsed' toggle — should we stick with that or move it to the global store?"
-- "The epics doc mentions X - is this related?"
-
-**Adapt to {user_skill_level}.** Technical users want technical questions. Non-technical users need translation.
-
-b) **If no existing code is found:**
-
-- Ask about intended architecture, patterns, constraints
-- Ask what similar systems they'd like to emulate
-
-### 4. Capture Core Understanding
-
-a) **From the conversation, extract and confirm:**
-
-- **Title**: A clear, concise name for this work
-- **Slug**: URL-safe version of title (lowercase, hyphens, no spaces)
-- **Problem Statement**: What problem are we solving?
-- **Solution**: High-level approach (1-2 sentences)
-- **In Scope**: What's included
-- **Out of Scope**: What's explicitly NOT included
-
-b) **Ask the user to confirm the captured understanding before proceeding.**
-
-### 5. Initialize WIP File
-
-a) **Create the tech-spec WIP file:**
-
-1. Copy template from `../tech-spec-template.md`
-2. Write to `{wipFile}`
-3. Update frontmatter with captured values:
-   ```yaml
-   ---
-   title: '{title}'
-   slug: '{slug}'
-   created: '{date}'
-   status: 'in-progress'
-   stepsCompleted: [1]
-   tech_stack: []
-   files_to_modify: []
-   code_patterns: []
-   test_patterns: []
-   ---
-   ```
-4. Fill in Overview section with Problem Statement, Solution, and Scope
-5. Fill in Context for Development section with any technical preferences or constraints gathered during informed discovery.
-6. Write the file
-
-b) **Report to user:**
-
-"Created: `{wipFile}`
-
-**Captured:**
-
-- Title: {title}
-- Problem: {problem_statement_summary}
-- Scope: {scope_summary}"
-
-### 6. Present Checkpoint Menu
-
-a) **Display menu:**
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Deep Investigation (Step 2 of 4)"
-
-b) **HALT and wait for user selection.**
-
-#### Menu Handling Logic:
-
-- IF A: Invoke the `bmad-advanced-elicitation` skill with current tech-spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update WIP file then redisplay menu, if no keep original then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with current tech-spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update WIP file then redisplay menu, if no keep original then redisplay menu
-- IF C: Verify `{wipFile}` has `stepsCompleted: [1]`, then read fully and follow: `./step-02-investigate.md`
-- IF Any other comments or queries: respond helpfully then redisplay menu
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After A or P execution, return to this menu
-
----
-
-## REQUIRED OUTPUTS:
-
-- MUST initialize WIP file with captured metadata.
-
-## VERIFICATION CHECKLIST:
-
-- [ ] WIP check performed FIRST before any greeting.
-- [ ] `{wipFile}` created with correct frontmatter, Overview, Context for Development, and `stepsCompleted: [1]`.
-- [ ] User selected [C] to continue.

package/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-spec/steps/step-02-investigate.md

@@ -1,140 +0,0 @@
----
-wipFile: '{implementation_artifacts}/tech-spec-wip.md'
----
-
-# Step 2: Map Technical Constraints & Anchor Points
-
-**Progress: Step 2 of 4** - Next: Generate Plan
-
-## RULES:
-
-- MUST NOT skip steps.
-- MUST NOT optimize sequence.
-- MUST follow exact instructions.
-- MUST NOT generate the full spec yet (that's Step 3).
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## CONTEXT:
-
-- Requires `{wipFile}` from Step 1 with the "Problem Statement" defined.
-- Focus: Map the problem statement to specific anchor points in the codebase.
-- Output: Exact files to touch, classes/patterns to extend, and technical constraints identified.
-- Objective: Provide the implementation-ready ground truth for the plan.
-
-## SEQUENCE OF INSTRUCTIONS
-
-### 1. Load Current State
-
-**Read `{wipFile}` and extract:**
-
-- Problem statement and scope from Overview section
-- Any context gathered in Step 1
-
-### 2. Execute Investigation Path
-
-**Universal Code Investigation:**
-
-_Isolate deep exploration in sub-agents/tasks where available. Return distilled summaries only to prevent context snowballing._
-
-a) **Build on Step 1's Quick Scan**
-
-Review what was found in Step 1's orient scan. Then ask:
-
-"Based on my quick look, I see [files/patterns found]. Are there other files or directories I should investigate deeply?"
-
-b) **Read and Analyze Code**
-
-For each file/directory provided:
-
-- Read the complete file(s)
-- Identify patterns, conventions, coding style
-- Note dependencies and imports
-- Find related test files
-
-**If NO relevant code is found (Clean Slate):**
-
-- Identify the target directory where the feature should live.
-- Scan parent directories for architectural context.
-- Identify standard project utilities or boilerplate that SHOULD be used.
-- Document this as "Confirmed Clean Slate" - establishing that no legacy constraints exist.
-
-
-c) **Document Technical Context**
-
-Capture and confirm with user:
-
-- **Tech Stack**: Languages, frameworks, libraries
-- **Code Patterns**: Architecture patterns, naming conventions, file structure
-- **Files to Modify/Create**: Specific files that will need changes or new files to be created
-- **Test Patterns**: How tests are structured, test frameworks used
-
-d) **Look for project-context.md**
-
-If `**/project-context.md` exists and wasn't loaded in Step 1:
-
-- Load it now
-- Extract patterns and conventions
-- Note any rules that must be followed
-
-### 3. Update WIP File
-
-**Update `{wipFile}` frontmatter:**
-
-```yaml
----
-# ... existing frontmatter ...
-stepsCompleted: [1, 2]
-tech_stack: ['{captured_tech_stack}']
-files_to_modify: ['{captured_files}']
-code_patterns: ['{captured_patterns}']
-test_patterns: ['{captured_test_patterns}']
----
-```
-
-**Update the Context for Development section:**
-
-Fill in:
-
-- Codebase Patterns (from investigation)
-- Files to Reference table (files reviewed)
-- Technical Decisions (any decisions made during investigation)
-
-**Report to user:**
-
-"**Context Gathered:**
-
-- Tech Stack: {tech_stack_summary}
-- Files to Modify: {files_count} files identified
-- Patterns: {patterns_summary}
-- Tests: {test_patterns_summary}"
-
-### 4. Present Checkpoint Menu
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Generate Spec (Step 3 of 4)"
-
-**HALT and wait for user selection.**
-
-#### Menu Handling Logic:
-
-- IF A: Invoke the `bmad-advanced-elicitation` skill with current tech-spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update WIP file then redisplay menu, if no keep original then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with current tech-spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update WIP file then redisplay menu, if no keep original then redisplay menu
-- IF C: Verify frontmatter updated with `stepsCompleted: [1, 2]`, then read fully and follow: `./step-03-generate.md`
-- IF Any other comments or queries: respond helpfully then redisplay menu
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After A or P execution, return to this menu
-
----
-
-## REQUIRED OUTPUTS:
-
-- MUST document technical context (stack, patterns, files identified).
-- MUST update `{wipFile}` with functional context.
-
-## VERIFICATION CHECKLIST:
-
-- [ ] Technical mapping performed and documented.
-- [ ] `stepsCompleted: [1, 2]` set in frontmatter.