frappe-builder 1.1.0-dev.10

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

@@ -0,0 +1,33 @@
+---
+---
+
+# 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

@@ -0,0 +1,50 @@
+---
+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

@@ -0,0 +1,17 @@
+---
+---
+
+# 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

@@ -0,0 +1,90 @@
+---
+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

@@ -0,0 +1,79 @@
+---
+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

@@ -0,0 +1,6 @@
+---
+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

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

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

@@ -0,0 +1,185 @@
+---
+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

@@ -0,0 +1,140 @@
+---
+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.