@devo-bmad-custom/agent-orchestration 1.0.0

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

@@ -0,0 +1,175 @@
+---
+name: 'step-09-functional'
+description: 'Synthesize all discovery into comprehensive functional requirements'
+
+# File References
+nextStepFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/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
+
+## YOUR TASK
+
+Synthesize all discovery into comprehensive functional requirements. 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
+
+### Step-Specific Rule
+
+CRITICAL: This is THE CAPABILITY CONTRACT for all downstream work.
+
+## 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
+
+**What would you like to do?**"
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [AR] Adversarial Review [PL] Party Mode Loop [AL] Adversarial Review Loop [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 PL: Prompt user for loops N, then execute {project-root}/_bmad/core/tasks/review-party-loop.xml with loops=N, then redisplay menu
+    - IF AL: Prompt user for loops N, then execute {project-root}/_bmad/core/tasks/review-adversarial-loop.xml with loops=N, then redisplay menu
+- IF AR: Execute {project-root}/_bmad/core/tasks/review-adversarial-general.xml — pass the current editPlan (or plan document in context) as the content to review; display findings with recommendations; then redisplay this 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
+
+DO NOT halt after presenting the menu if you have finished generating the content. You should automatically assume 'C' and proceed to {nextStepFile} unless the user explicitly interrupts. 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.
+
+## 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."

package/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-10-nonfunctional.md

@@ -0,0 +1,189 @@
+---
+name: 'step-10-nonfunctional'
+description: 'Define quality attributes that matter for this specific product'
+
+# File References
+nextStepFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.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 10: Non-Functional Requirements
+
+**Progress: Step 10 of 12** - Next: Polish Document
+
+## YOUR TASK
+
+Define non-functional requirements that specify quality attributes for the product, focusing only on what matters for THIS specific product.
+
+### Step-Specific Rules
+- AUTONOMY OVERRIDE: If you have enough context to answer any discovery questions yourself, DO NOT ask the user. Make expert assumptions, generate the content, display it, and immediately proceed to {nextStepFile} without halting.
+
+- SELECTIVE: Only document NFRs that actually apply to the product
+- Focus on quality attributes that matter for THIS specific product
+
+## NON-FUNCTIONAL REQUIREMENTS SEQUENCE:
+
+### 1. Explain NFR Purpose and Scope
+
+Start by clarifying what NFRs are and why we're selective:
+
+**NFR Purpose:**
+NFRs define HOW WELL the system must perform, not WHAT it must do. They specify quality attributes like performance, security, scalability, etc.
+
+**Selective Approach:**
+We only document NFRs that matter for THIS product. If a category doesn't apply, we skip it entirely. This prevents requirement bloat and focuses on what's actually important.
+
+### 2. Assess Product Context for NFR Relevance
+
+Evaluate which NFR categories matter based on product context:
+
+**Quick Assessment Questions:**
+
+- **Performance**: Is there user-facing impact of speed?
+- **Security**: Are we handling sensitive data or payments?
+- **Scalability**: Do we expect rapid user growth?
+- **Accessibility**: Are we serving broad public audiences?
+- **Integration**: Do we need to connect with other systems?
+- **Reliability**: Would downtime cause significant problems?
+
+### 3. Explore Relevant NFR Categories
+
+For each relevant category, conduct targeted discovery:
+
+#### Performance NFRs (If relevant):
+
+Explore performance requirements:
+- What parts of the system need to be fast for users to be successful?
+- Are there specific response time expectations?
+- What happens if performance is slower than expected?
+- Are there concurrent user scenarios we need to support?
+
+#### Security NFRs (If relevant):
+
+Explore security requirements:
+- What data needs to be protected?
+- Who should have access to what?
+- What are the security risks we need to mitigate?
+- Are there compliance requirements (GDPR, HIPAA, PCI-DSS)?
+
+#### Scalability NFRs (If relevant):
+
+Explore scalability requirements:
+- How many users do we expect initially? Long-term?
+- Are there seasonal or event-based traffic spikes?
+- What happens if we exceed our capacity?
+- What growth scenarios should we plan for?
+
+#### Accessibility NFRs (If relevant):
+
+Explore accessibility requirements:
+- Are we serving users with visual, hearing, or motor impairments?
+- Are there legal accessibility requirements (WCAG, Section 508)?
+- What accessibility features are most important for our users?
+
+#### Integration NFRs (If relevant):
+
+Explore integration requirements:
+- What external systems do we need to connect with?
+- Are there APIs or data formats we must support?
+- How reliable do these integrations need to be?
+
+### 4. Make NFRs Specific and Measurable
+
+For each relevant NFR category, ensure criteria are testable:
+
+**From Vague to Specific:**
+
+- NOT: "The system should be fast" → "User actions complete within 2 seconds"
+- NOT: "The system should be secure" → "All data is encrypted at rest and in transit"
+- NOT: "The system should scale" → "System supports 10x user growth with <10% performance degradation"
+
+### 5. Generate NFR Content (Only Relevant Categories)
+
+Prepare the content to append to the document:
+
+#### Content Structure (Dynamic based on relevance):
+
+When saving to document, append these Level 2 and Level 3 sections (only include sections that are relevant):
+
+```markdown
+## Non-Functional Requirements
+
+### Performance
+
+[Performance requirements based on conversation - only include if relevant]
+
+### Security
+
+[Security requirements based on conversation - only include if relevant]
+
+### Scalability
+
+[Scalability requirements based on conversation - only include if relevant]
+
+### Accessibility
+
+[Accessibility requirements based on conversation - only include if relevant]
+
+### Integration
+
+[Integration requirements based on conversation - only include if relevant]
+```
+
+### 6. Present MENU OPTIONS
+
+Present the non-functional requirements for review, then display menu:
+- Show defined NFRs (using structure from step 5)
+- Note that only relevant categories were included
+- Emphasize NFRs specify how well the system needs to perform
+- Ask if they'd like to refine further, get other perspectives, or proceed
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [AR] Adversarial Review [PL] Party Mode Loop [AL] Adversarial Review Loop [C] Continue to Polish Document (Step 11 of 12)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask} with the current NFR content, process the enhanced quality attribute 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 current NFR list, process the collaborative technical 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 PL: Prompt user for loops N, then execute {project-root}/_bmad/core/tasks/review-party-loop.xml with loops=N, then redisplay menu
+    - IF AL: Prompt user for loops N, then execute {project-root}/_bmad/core/tasks/review-adversarial-loop.xml with loops=N, then redisplay menu
+- IF AR: Execute {project-root}/_bmad/core/tasks/review-adversarial-general.xml — pass the current editPlan (or plan document in context) as the content to review; display findings with recommendations; then redisplay this 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
+
+DO NOT halt after presenting the menu if you have finished generating the content. You should automatically assume 'C' and proceed to {nextStepFile} unless the user explicitly interrupts. 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 5.
+
+## NFR CATEGORY GUIDANCE:
+
+**Include Performance When:**
+
+- User-facing response times impact success
+- Real-time interactions are critical
+- Performance is a competitive differentiator
+
+**Include Security When:**
+
+- Handling sensitive user data
+- Processing payments or financial information
+- Subject to compliance regulations
+- Protecting intellectual property
+
+**Include Scalability When:**
+
+- Expecting rapid user growth
+- Handling variable traffic patterns
+- Supporting enterprise-scale usage
+- Planning for market expansion
+
+**Include Accessibility When:**
+
+- Serving broad public audiences
+- Subject to accessibility regulations
+- Targeting users with disabilities
+- B2B customers with accessibility requirements

package/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md

@@ -0,0 +1,162 @@
+---
+name: 'step-11-polish'
+description: 'Optimize and polish the complete PRD document for flow, coherence, and readability'
+
+# File References
+nextStepFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-12-complete.md'
+outputFile: '{planning_artifacts}/prd.md'
+purposeFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/data/prd-purpose.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 11: Document Polish
+
+**Progress: Step 11 of 12** - Next: Complete PRD
+
+## YOUR TASK
+
+Optimize the complete PRD document for flow, coherence, and professional presentation while preserving all essential information.
+
+### Step-Specific Rules
+- AUTONOMY OVERRIDE: If you have enough context to answer any discovery questions yourself, DO NOT ask the user. Make expert assumptions, generate the content, display it, and immediately proceed to {nextStepFile} without halting.
+
+- CRITICAL: Load the ENTIRE document before making changes
+- This is a POLISH step — optimize existing content
+- PRESERVE user's voice and intent
+- MAINTAIN all essential information while improving presentation
+
+## DOCUMENT POLISH SEQUENCE:
+
+### 1. Load Context and Document
+
+**CRITICAL:** Load the PRD purpose document first:
+
+- Read `{purposeFile}` to understand what makes a great BMAD PRD
+- Internalize the philosophy: information density, traceability, measurable requirements
+- Keep the dual-audience nature (humans + LLMs) in mind
+
+**Then Load the PRD Document:**
+
+- Read `{outputFile}` completely from start to finish
+- Understand the full document structure and content
+- Identify all sections and their relationships
+- Note areas that need attention
+
+### 2. Document Quality Review
+
+Review the entire document with PRD purpose principles in mind:
+
+**Information Density:**
+- Are there wordy phrases that can be condensed?
+- Is conversational padding present?
+- Can sentences be more direct and concise?
+
+**Flow and Coherence:**
+- Do sections transition smoothly?
+- Are there jarring topic shifts?
+- Does the document tell a cohesive story?
+- Is the progression logical for readers?
+
+**Duplication Detection:**
+- Are ideas repeated across sections?
+- Is the same information stated multiple times?
+- Can redundant content be consolidated?
+- Are there contradictory statements?
+
+**Header Structure:**
+- Are all main sections using ## Level 2 headers?
+- Is the hierarchy consistent (##, ###, ####)?
+- Can sections be easily extracted or referenced?
+- Are headers descriptive and clear?
+
+**Readability:**
+- Are sentences clear and concise?
+- Is the language consistent throughout?
+- Are technical terms used appropriately?
+- Would stakeholders find this easy to understand?
+
+### 3. Optimization Actions
+
+Make targeted improvements:
+
+**Improve Flow:**
+- Add transition sentences between sections
+- Smooth out jarring topic shifts
+- Ensure logical progression
+- Connect related concepts across sections
+
+**Reduce Duplication:**
+- Consolidate repeated information
+- Keep content in the most appropriate section
+- Use cross-references instead of repetition
+- Remove redundant explanations
+
+**Enhance Coherence:**
+- Ensure consistent terminology throughout
+- Align all sections with product differentiator
+- Maintain consistent voice and tone
+- Verify scope consistency across sections
+
+**Optimize Headers:**
+- Ensure all main sections use ## Level 2
+- Make headers descriptive and action-oriented
+- Check that headers follow consistent patterns
+- Verify headers support document navigation
+
+### 4. Preserve Critical Information
+
+**While optimizing, ensure NOTHING essential is lost:**
+
+**Must Preserve:**
+- All user success criteria
+- All functional requirements (capability contract)
+- All user journey narratives
+- All scope decisions (MVP, Growth, Vision)
+- All non-functional requirements
+- Product differentiator and vision
+- Domain-specific requirements
+- Innovation analysis (if present)
+
+**Can Consolidate:**
+- Repeated explanations of the same concept
+- Redundant background information
+- Multiple versions of similar content
+- Overlapping examples
+
+### 5. Generate Optimized Document
+
+Create the polished version:
+
+**Polishing Process:**
+1. Start with original document
+2. Apply all optimization actions
+3. Review to ensure nothing essential was lost
+4. Verify improvements enhance readability
+5. Prepare optimized version for review
+
+### 6. Present MENU OPTIONS
+
+Present the polished document for review, then display menu:
+- Show what changed in the polish
+- Highlight improvements made (flow, duplication, headers)
+- Ask if they'd like to refine further, get other perspectives, or proceed
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [AR] Adversarial Review [PL] Party Mode Loop [AL] Adversarial Review Loop [C] Continue to Complete PRD (Step 12 of 12)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask} with the polished document, process the enhanced refinements that come back, ask user "Accept these polish improvements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
+- IF P: Read fully and follow: {partyModeWorkflow} with the polished document, process the collaborative refinements to flow and coherence, ask user "Accept these polish changes? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
+    - IF PL: Prompt user for loops N, then execute {project-root}/_bmad/core/tasks/review-party-loop.xml with loops=N, then redisplay menu
+    - IF AL: Prompt user for loops N, then execute {project-root}/_bmad/core/tasks/review-adversarial-loop.xml with loops=N, then redisplay menu
+- IF AR: Execute {project-root}/_bmad/core/tasks/review-adversarial-general.xml — pass the current editPlan (or plan document in context) as the content to review; display findings with recommendations; then redisplay this menu
+- IF C: Save the polished document 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
+
+DO NOT halt after presenting the menu if you have finished generating the content. You should automatically assume 'C' and proceed to {nextStepFile} unless the user explicitly interrupts. After other menu items execution, return to this menu.
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the entire document content with the polished version.

package/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-12-complete.md

@@ -0,0 +1,79 @@
+---
+name: 'step-12-complete'
+description: 'Complete the PRD workflow, update status files, and suggest next steps including validation'
+
+# File References
+outputFile: '{planning_artifacts}/prd.md'
+validationFlow: '../steps-v/step-v-01-discovery.md'
+---
+
+# Step 12: Workflow Completion
+
+**Final Step - Complete the PRD**
+
+## YOUR TASK
+
+Complete the PRD workflow, update status files, offer validation options, and suggest next steps for the project.
+
+### Step-Specific Rules
+- AUTONOMY OVERRIDE: If you have enough context to answer any discovery questions yourself, DO NOT ask the user. Make expert assumptions, generate the content, display it, and immediately proceed to {nextStepFile} without halting.
+
+- THIS IS A FINAL STEP — workflow completion required
+- NO content generation — this is a wrap-up step
+- UPDATE workflow status files with completion information
+- DO NOT load additional steps after this one
+
+## WORKFLOW COMPLETION SEQUENCE:
+
+### 1. Announce Workflow Completion
+
+Inform user that the PRD is complete and polished:
+- Celebrate successful completion of comprehensive PRD
+- Summarize all sections that were created
+- Highlight that document has been polished for flow and coherence
+- Emphasize document is ready for downstream work
+
+### 2. Workflow Status Update
+
+Update the main workflow status file if there is one:
+
+- Load `{status_file}` from workflow configuration (if exists)
+- Update workflow_status["prd"] = "{default_output_file}"
+- Save file, preserving all comments and structure
+- Mark current timestamp as completion time
+
+### 3. Validation Workflow Options
+
+Offer validation workflows to ensure PRD is ready for implementation:
+
+**Available Validation Workflows:**
+
+**Option 1: Check Implementation Readiness** (`{checkImplementationReadinessWorkflow}`)
+- Validates PRD has all information needed for development
+- Checks epic coverage completeness
+- Reviews UX alignment with requirements
+- Assesses epic quality and readiness
+- Identifies gaps before architecture/design work begins
+
+**When to use:** Before starting technical architecture or epic breakdown
+
+**Option 2: Skip for Now**
+- Proceed directly to next workflows (architecture, UX, epics)
+- Validation can be done later if needed
+- Some teams prefer to validate during architecture reviews
+
+### 4. Suggest Next Workflows
+
+PRD complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
+
+### 5. Final Completion Confirmation
+
+- Confirm completion with user and summarize what has been accomplished
+- Document now contains: Executive Summary, Success Criteria, User Journeys, Domain Requirements (if applicable), Innovation Analysis (if applicable), Project-Type Requirements, Functional Requirements (capability contract), Non-Functional Requirements, and has been polished for flow and coherence
+- Ask if they'd like to run validation workflow or proceed to next workflows
+
+## FINAL REMINDER to give the user:
+
+The polished PRD serves as the foundation for all subsequent product development activities. All design, architecture, and development work should trace back to the requirements and vision documented in this PRD - update it also as needed as you continue planning.
+
+**Congratulations on completing the Product Requirements Document for {{project_name}}!** 🎉