create-byan-agent 2.1.0 → 2.2.1

package/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-07-project-type.md

@@ -1,237 +0,0 @@
----
-name: 'step-07-project-type'
-description: 'Conduct project-type specific discovery using CSV-driven guidance'
-
-# File References
-nextStepFile: './step-08-scoping.md'
-outputFile: '{planning_artifacts}/prd.md'
-
-# Data Files
-projectTypesCSV: '../data/project-types.csv'
-
-# Task References
-advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
----
-
-# Step 7: Project-Type Deep Dive
-
-**Progress: Step 7 of 11** - Next: Scoping
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on project-type specific requirements and technical considerations
-- 🎯 DATA-DRIVEN: Use CSV configuration to guide discovery
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating project-type content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Project type from step-02 is available for configuration loading
-- Project-type CSV data will be loaded in this step
-- Focus on technical and functional requirements specific to this project type
-
-## YOUR TASK:
-
-Conduct project-type specific discovery using CSV-driven guidance to define technical requirements.
-
-## PROJECT-TYPE DISCOVERY SEQUENCE:
-
-### 1. Load Project-Type Configuration Data
-
-**Attempt subprocess data lookup:**
-
-"Your task: Lookup data in {projectTypesCSV}
-
-**Search criteria:**
-- Find row where project_type matches {{projectTypeFromStep02}}
-
-**Return format:**
-Return ONLY the matching row as a YAML-formatted object with these fields:
-project_type, key_questions, required_sections, skip_sections, innovation_signals
-
-**Do NOT return the entire CSV - only the matching row.**"
-
-**Graceful degradation (if Task tool unavailable):**
-- Load the CSV file directly
-- Find the matching row manually
-- Extract required fields:
-  - `key_questions` (semicolon-separated list of discovery questions)
-  - `required_sections` (semicolon-separated list of sections to document)
-  - `skip_sections` (semicolon-separated list of sections to skip)
-  - `innovation_signals` (already explored in step-6)
-
-### 2. Conduct Guided Discovery Using Key Questions
-
-Parse `key_questions` from CSV and explore each:
-
-#### Question-Based Discovery:
-
-For each question in `key_questions` from CSV:
-
-- Ask the user naturally in conversational style
-- Listen for their response and ask clarifying follow-ups
-- Connect answers to product value proposition
-
-**Example Flow:**
-If key_questions = "Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?"
-
-Ask naturally:
-
-- "What are the main endpoints your API needs to expose?"
-- "How will you handle authentication and authorization?"
-- "What data formats will you support for requests and responses?"
-
-### 3. Document Project-Type Specific Requirements
-
-Based on user answers to key_questions, synthesize comprehensive requirements:
-
-#### Requirement Categories:
-
-Cover the areas indicated by `required_sections` from CSV:
-
-- Synthesize what was discovered for each required section
-- Document specific requirements, constraints, and decisions
-- Connect to product differentiator when relevant
-
-#### Skip Irrelevant Sections:
-
-Skip areas indicated by `skip_sections` from CSV to avoid wasting time on irrelevant aspects.
-
-### 4. Generate Dynamic Content Sections
-
-Parse `required_sections` list from the matched CSV row. For each section name, generate corresponding content:
-
-#### Common CSV Section Mappings:
-
-- "endpoint_specs" or "endpoint_specification" → API endpoints documentation
-- "auth_model" or "authentication_model" → Authentication approach
-- "platform_reqs" or "platform_requirements" → Platform support needs
-- "device_permissions" or "device_features" → Device capabilities
-- "tenant_model" → Multi-tenancy approach
-- "rbac_matrix" or "permission_matrix" → Permission structure
-
-#### Template Variable Strategy:
-
-- For sections matching common template variables: generate specific content
-- For sections without template matches: include in main project_type_requirements
-- Hybrid approach balances template structure with CSV-driven flexibility
-
-### 5. Generate Project-Type Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## [Project Type] Specific Requirements
-
-### Project-Type Overview
-
-[Project type summary based on conversation]
-
-### Technical Architecture Considerations
-
-[Technical architecture requirements based on conversation]
-
-[Dynamic sections based on CSV and conversation]
-
-### Implementation Considerations
-
-[Implementation specific requirements based on conversation]
-```
-
-### 6. Present MENU OPTIONS
-
-Present the project-type content for review, then display menu:
-
-"Based on our conversation and best practices for this product type, I've documented the {project_type}-specific requirements for {{project_name}}.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from section 5]
-
-**What would you like to do?**"
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Scoping (Step 8 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Read fully and follow: {advancedElicitationTask} with the current project-type content, process the enhanced technical insights that come back, ask user "Accept these improvements to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Read fully and follow: {partyModeWorkflow} with the current project-type requirements, process the collaborative technical expertise and validation, ask user "Accept these changes to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
-- IF Any other: help user respond, 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 other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from previous steps.
-
-## SUCCESS METRICS:
-
-✅ Project-type configuration loaded and used effectively
-✅ All key questions from CSV explored with user input
-✅ Required sections generated per CSV configuration
-✅ Skip sections properly avoided to save time
-✅ Technical requirements connected to product value
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Not loading or using project-type CSV configuration
-❌ Missing key questions from CSV in discovery process
-❌ Not generating required sections per CSV configuration
-❌ Documenting sections that should be skipped per CSV
-❌ Creating generic content without project-type specificity
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## PROJECT-TYPE EXAMPLES:
-
-**For api_backend:**
-
-- Focus on endpoints, authentication, data schemas, rate limiting
-- Skip visual design and user journey sections
-- Generate API specification documentation
-
-**For mobile_app:**
-
-- Focus on platform requirements, device permissions, offline mode
-- Skip API endpoint documentation unless needed
-- Generate mobile-specific technical requirements
-
-**For saas_b2b:**
-
-- Focus on multi-tenancy, permissions, integrations
-- Skip mobile-first considerations unless relevant
-- Generate enterprise-specific requirements
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `{nextStepFile}` to define project scope.
-
-Remember: Do NOT proceed to step-08 (Scoping) until user explicitly selects 'C' from the A/P/C menu and content is saved!

package/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-08-scoping.md

@@ -1,228 +0,0 @@
----
-name: 'step-08-scoping'
-description: 'Define MVP boundaries and prioritize features across development phases'
-
-# File References
-nextStepFile: './step-09-functional.md'
-outputFile: '{planning_artifacts}/prd.md'
-
-# Task References
-advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
----
-
-# Step 8: Scoping Exercise - MVP & Future Features
-
-**Progress: Step 8 of 11** - Next: Functional Requirements
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on strategic scope decisions that keep projects viable
-- 🎯 EMPHASIZE lean MVP thinking while preserving long-term vision
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 📚 Review the complete PRD document built so far
-- ⚠️ Present A/P/C menu after generating scoping decisions
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-
-## CONTEXT BOUNDARIES:
-
-- Complete PRD document built so far is available for review
-- User journeys, success criteria, and domain requirements are documented
-- Focus on strategic scope decisions, not feature details
-- Balance between user value and implementation feasibility
-
-## YOUR TASK:
-
-Conduct comprehensive scoping exercise to define MVP boundaries and prioritize features across development phases.
-
-## SCOPING SEQUENCE:
-
-### 1. Review Current PRD State
-
-Analyze everything documented so far:
-- Present synthesis of established vision, success criteria, journeys
-- Assess domain and innovation focus
-- Evaluate scope implications: simple MVP, medium, or complex project
-- Ask if initial assessment feels right or if they see it differently
-
-### 2. Define MVP Strategy
-
-Facilitate strategic MVP decisions:
-- Explore MVP philosophy options: problem-solving, experience, platform, or revenue MVP
-- Ask critical questions:
-  - What's the minimum that would make users say 'this is useful'?
-  - What would make investors/partners say 'this has potential'?
-  - What's the fastest path to validated learning?
-- Guide toward appropriate MVP approach for their product
-
-### 3. Scoping Decision Framework
-
-Use structured decision-making for scope:
-
-**Must-Have Analysis:**
-- Guide identification of absolute MVP necessities
-- For each journey and success criterion, ask:
-  - Without this, does the product fail?
-  - Can this be manual initially?
-  - Is this a deal-breaker for early adopters?
-- Analyze journeys for MVP essentials
-
-**Nice-to-Have Analysis:**
-- Identify what could be added later:
-  - Features that enhance but aren't essential
-  - User types that can be added later
-  - Advanced functionality that builds on MVP
-- Ask what features could be added in versions 2, 3, etc.
-
-### 4. Progressive Feature Roadmap
-
-Create phased development approach:
-- Guide mapping of features across development phases
-- Structure as Phase 1 (MVP), Phase 2 (Growth), Phase 3 (Vision)
-- Ensure clear progression and dependencies
-
-- Core user value delivery
-- Essential user journeys
-- Basic functionality that works reliably
-
-**Phase 2: Growth**
-
-- Additional user types
-- Enhanced features
-- Scale improvements
-
-**Phase 3: Expansion**
-
-- Advanced capabilities
-- Platform features
-- New markets or use cases
-
-**Where does your current vision fit in this development sequence?**"
-
-### 5. Risk-Based Scoping
-
-Identify and mitigate scoping risks:
-
-**Technical Risks:**
-"Looking at your innovation and domain requirements:
-
-- What's the most technically challenging aspect?
-- Could we simplify the initial implementation?
-- What's the riskiest assumption about technology feasibility?"
-
-**Market Risks:**
-
-- What's the biggest market risk?
-- How does the MVP address this?
-- What learning do we need to de-risk this?"
-
-**Resource Risks:**
-
-- What if we have fewer resources than planned?
-- What's the absolute minimum team size needed?
-- Can we launch with a smaller feature set?"
-
-### 6. Generate Scoping Content
-
-Prepare comprehensive scoping section:
-
-#### Content Structure:
-
-```markdown
-## Project Scoping & Phased Development
-
-### MVP Strategy & Philosophy
-
-**MVP Approach:** {{chosen_mvp_approach}}
-**Resource Requirements:** {{mvp_team_size_and_skills}}
-
-### MVP Feature Set (Phase 1)
-
-**Core User Journeys Supported:**
-{{essential_journeys_for_mvp}}
-
-**Must-Have Capabilities:**
-{{list_of_essential_mvp_features}}
-
-### Post-MVP Features
-
-**Phase 2 (Post-MVP):**
-{{planned_growth_features}}
-
-**Phase 3 (Expansion):**
-{{planned_expansion_features}}
-
-### Risk Mitigation Strategy
-
-**Technical Risks:** {{mitigation_approach}}
-**Market Risks:** {{validation_approach}}
-**Resource Risks:** {{contingency_approach}}
-```
-
-### 7. Present MENU OPTIONS
-
-Present the scoping decisions for review, then display menu:
-- Show strategic scoping plan (using structure from step 6)
-- Highlight MVP boundaries and phased roadmap
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Functional Requirements (Step 9 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Read fully and follow: {advancedElicitationTask} with the current scoping analysis, process the enhanced insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF P: Read fully and follow: {partyModeWorkflow} with the scoping context, process the collaborative insights on MVP and roadmap decisions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
-- IF Any other: help user respond, 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 other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ Complete PRD document analyzed for scope implications
-✅ Strategic MVP approach defined and justified
-✅ Clear MVP feature boundaries established
-✅ Phased development roadmap created
-✅ Key risks identified and mitigation strategies defined
-✅ User explicitly agrees to scope decisions
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Not analyzing the complete PRD before making scoping decisions
-❌ Making scope decisions without strategic rationale
-❌ Not getting explicit user agreement on MVP boundaries
-❌ Missing critical risk analysis
-❌ Not creating clear phased development approach
-❌ Not presenting A/P/C menu after content generation
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load {nextStepFile}.
-
-Remember: Do NOT proceed to step-09 until user explicitly selects 'C' from the A/P/C menu and content is saved!

package/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-09-functional.md

@@ -1,231 +0,0 @@
----
-name: 'step-09-functional'
-description: 'Synthesize all discovery into comprehensive functional requirements'
-
-# File References
-nextStepFile: './step-10-nonfunctional.md'
-outputFile: '{planning_artifacts}/prd.md'
-
-# Task References
-advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
----
-
-# Step 9: Functional Requirements Synthesis
-
-**Progress: Step 9 of 11** - Next: Non-Functional Requirements
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on creating comprehensive capability inventory for the product
-- 🎯 CRITICAL: This is THE CAPABILITY CONTRACT for all downstream work
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating functional requirements
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- ALL previous content (executive summary, success criteria, journeys, domain, innovation, project-type) must be referenced
-- No additional data files needed for this step
-- Focus on capabilities, not implementation details
-
-## CRITICAL IMPORTANCE:
-
-**This section defines THE CAPABILITY CONTRACT for the entire product:**
-
-- UX designers will ONLY design what's listed here
-- Architects will ONLY support what's listed here
-- Epic breakdown will ONLY implement what's listed here
-- If a capability is missing from FRs, it will NOT exist in the final product
-
-## FUNCTIONAL REQUIREMENTS SYNTHESIS SEQUENCE:
-
-### 1. Understand FR Purpose and Usage
-
-Start by explaining the critical role of functional requirements:
-
-**Purpose:**
-FRs define WHAT capabilities the product must have. They are the complete inventory of user-facing and system capabilities that deliver the product vision.
-
-**Critical Properties:**
-✅ Each FR is a testable capability
-✅ Each FR is implementation-agnostic (could be built many ways)
-✅ Each FR specifies WHO and WHAT, not HOW
-✅ No UI details, no performance numbers, no technology choices
-✅ Comprehensive coverage of capability areas
-
-**How They Will Be Used:**
-
-1. UX Designer reads FRs → designs interactions for each capability
-2. Architect reads FRs → designs systems to support each capability
-3. PM reads FRs → creates epics and stories to implement each capability
-
-### 2. Review Existing Content for Capability Extraction
-
-Systematically review all previous sections to extract capabilities:
-
-**Extract From:**
-
-- Executive Summary → Core product differentiator capabilities
-- Success Criteria → Success-enabling capabilities
-- User Journeys → Journey-revealed capabilities
-- Domain Requirements → Compliance and regulatory capabilities
-- Innovation Patterns → Innovative feature capabilities
-- Project-Type Requirements → Technical capability needs
-
-### 3. Organize Requirements by Capability Area
-
-Group FRs by logical capability areas (NOT by technology or layer):
-
-**Good Grouping Examples:**
-
-- ✅ "User Management" (not "Authentication System")
-- ✅ "Content Discovery" (not "Search Algorithm")
-- ✅ "Team Collaboration" (not "WebSocket Infrastructure")
-
-**Target 5-8 Capability Areas** for typical projects.
-
-### 4. Generate Comprehensive FR List
-
-Create complete functional requirements using this format:
-
-**Format:**
-
-- FR#: [Actor] can [capability] [context/constraint if needed]
-- Number sequentially (FR1, FR2, FR3...)
-- Aim for 20-50 FRs for typical projects
-
-**Altitude Check:**
-Each FR should answer "WHAT capability exists?" NOT "HOW it's implemented?"
-
-**Examples:**
-
-- ✅ "Users can customize appearance settings"
-- ❌ "Users can toggle light/dark theme with 3 font size options stored in LocalStorage"
-
-### 5. Self-Validation Process
-
-Before presenting to user, validate the FR list:
-
-**Completeness Check:**
-
-1. "Did I cover EVERY capability mentioned in the MVP scope section?"
-2. "Did I include domain-specific requirements as FRs?"
-3. "Did I cover the project-type specific needs?"
-4. "Could a UX designer read ONLY the FRs and know what to design?"
-5. "Could an Architect read ONLY the FRs and know what to support?"
-6. "Are there any user actions or system behaviors we discussed that have no FR?"
-
-**Altitude Check:**
-
-1. "Am I stating capabilities (WHAT) or implementation (HOW)?"
-2. "Am I listing acceptance criteria or UI specifics?" (Remove if yes)
-3. "Could this FR be implemented 5 different ways?" (Good - means it's not prescriptive)
-
-**Quality Check:**
-
-1. "Is each FR clear enough that someone could test whether it exists?"
-2. "Is each FR independent (not dependent on reading other FRs to understand)?"
-3. "Did I avoid vague terms like 'good', 'fast', 'easy'?" (Use NFRs for quality attributes)
-
-### 6. Generate Functional Requirements Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## Functional Requirements
-
-### [Capability Area Name]
-
-- FR1: [Specific Actor] can [specific capability]
-- FR2: [Specific Actor] can [specific capability]
-- FR3: [Specific Actor] can [specific capability]
-
-### [Another Capability Area]
-
-- FR4: [Specific Actor] can [specific capability]
-- FR5: [Specific Actor] can [specific capability]
-
-[Continue for all capability areas discovered in conversation]
-```
-
-### 7. Present MENU OPTIONS
-
-Present the functional requirements for review, then display menu:
-- Show synthesized functional requirements (using structure from step 6)
-- Emphasize this is the capability contract for all downstream work
-- Highlight that every feature must trace back to these requirements
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-**What would you like to do?**"
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Non-Functional Requirements (Step 10 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Read fully and follow: {advancedElicitationTask} with the current FR list, process the enhanced capability coverage that comes back, ask user if they accept the additions, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF P: Read fully and follow: {partyModeWorkflow} with the current FR list, process the collaborative capability validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
-- IF Any other: help user respond, 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 other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ All previous discovery content synthesized into FRs
-✅ FRs organized by capability areas (not technology)
-✅ Each FR states WHAT capability exists, not HOW to implement
-✅ Comprehensive coverage with 20-50 FRs typical
-✅ Altitude validation ensures implementation-agnostic requirements
-✅ Completeness check validates coverage of all discussed capabilities
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Missing capabilities from previous discovery sections
-❌ Organizing FRs by technology instead of capability areas
-❌ Including implementation details or UI specifics in FRs
-❌ Not achieving comprehensive coverage of discussed capabilities
-❌ Using vague terms instead of testable capabilities
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## CAPABILITY CONTRACT REMINDER:
-
-Emphasize to user: "This FR list is now binding. Any feature not listed here will not exist in the final product unless we explicitly add it. This is why it's critical to ensure completeness now."
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load {nextStepFile} to define non-functional requirements.
-
-Remember: Do NOT proceed to step-10 until user explicitly selects 'C' from the A/P/C menu and content is saved!