333 lines
13 KiB
Markdown
333 lines
13 KiB
Markdown
# Implementation Readiness - Workflow Instructions
|
|
|
|
<critical>The workflow execution engine is governed by: {project-root}/.bmad/core/tasks/workflow.xml</critical>
|
|
<critical>You MUST have already loaded and processed: {project-root}/.bmad/bmm/workflows/3-solutioning/implementation-readiness/workflow.yaml</critical>
|
|
<critical>Communicate all findings and analysis in {communication_language} throughout the assessment</critical>
|
|
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
|
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
|
|
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
|
|
|
|
<workflow>
|
|
|
|
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
|
<action>Check if {workflow_status_file} exists</action>
|
|
|
|
<check if="status file not found">
|
|
<output>No workflow status file found. Implementation Readiness check can run standalone or as part of BMM workflow path.</output>
|
|
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
|
|
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
|
<check if="continue">
|
|
<action>Set standalone_mode = true</action>
|
|
</check>
|
|
<check if="exit">
|
|
<action>Exit workflow</action>
|
|
</check>
|
|
</check>
|
|
|
|
<check if="status file found">
|
|
<action>Load the FULL file: {workflow_status_file}</action>
|
|
<action>Parse workflow_status section</action>
|
|
<action>Check status of "implementation-readiness" workflow</action>
|
|
<action>Get {selected_track} (quick-flow, bmad-method, or enterprise-bmad-method)</action>
|
|
<action>Find first non-completed workflow (next expected workflow)</action>
|
|
|
|
<action>Based on the selected_track, understand what artifacts should exist: - quick-flow: Tech spec and simple stories in an epic only (no PRD, minimal solutioning) - bmad-method and enterprise-bmad-method: PRD, UX design, epics/stories, architecture</action>
|
|
|
|
<check if="implementation-readiness status is file path (already completed)">
|
|
<output>⚠️ Implementation readiness check already completed: {{implementation-readiness status}}</output>
|
|
<ask>Re-running will create a new validation report. Continue? (y/n)</ask>
|
|
<check if="n">
|
|
<output>Exiting. Use workflow-status to see your next step.</output>
|
|
<action>Exit workflow</action>
|
|
</check>
|
|
</check>
|
|
|
|
<check if="implementation-readiness is not the next expected workflow">
|
|
<output>⚠️ Next expected workflow: {{next_workflow}}. Implementation readiness check is out of sequence.</output>
|
|
<ask>Continue with readiness check anyway? (y/n)</ask>
|
|
<check if="n">
|
|
<output>Exiting. Run {{next_workflow}} instead.</output>
|
|
<action>Exit workflow</action>
|
|
</check>
|
|
</check>
|
|
|
|
<action>Set standalone_mode = false</action>
|
|
</check>
|
|
|
|
<template-output>project_context</template-output>
|
|
</step>
|
|
|
|
<step n="0.5" goal="Discover and load input documents">
|
|
<invoke-protocol name="discover_inputs" />
|
|
<note>After discovery, these content variables are available: {prd_content}, {epics_content}, {architecture_content}, {ux_design_content}, {tech_spec_content}, {document_project_content}</note>
|
|
</step>
|
|
|
|
<step n="1" goal="Inventory loaded project artifacts">
|
|
<action>Review the content loaded by Step 0.5 and create an inventory</action>
|
|
|
|
<action>Inventory of available documents:
|
|
|
|
- PRD: {prd_content} (loaded if available)
|
|
- Architecture: {architecture_content} (loaded if available)
|
|
- Epics: {epics_content} (loaded if available)
|
|
- UX Design: {ux_design_content} (loaded if available)
|
|
- Tech Spec: {tech_spec_content} (loaded if available, Quick Flow track)
|
|
- Brownfield docs: {document_project_content} (loaded via INDEX_GUIDED if available)
|
|
</action>
|
|
|
|
<action>For each loaded document, extract:
|
|
|
|
- Document type and purpose
|
|
- Brief description of what it contains
|
|
- Flag any expected documents that are missing as potential issues
|
|
</action>
|
|
|
|
<template-output>document_inventory</template-output>
|
|
</step>
|
|
|
|
<step n="2" goal="Deep analysis of core planning documents">
|
|
<action>Thoroughly analyze each loaded document to extract:
|
|
- Core requirements and success criteria
|
|
- Architectural decisions and constraints
|
|
- Technical implementation approaches
|
|
- User stories and acceptance criteria
|
|
- Dependencies and sequencing requirements
|
|
- Any assumptions or risks documented
|
|
</action>
|
|
|
|
<action>For PRD analysis, focus on:
|
|
|
|
- User requirements and use cases
|
|
- Functional and non-functional requirements
|
|
- Success metrics and acceptance criteria
|
|
- Scope boundaries and explicitly excluded items
|
|
- Priority levels for different features
|
|
</action>
|
|
|
|
<action>For Architecture/Tech Spec analysis, focus on:
|
|
|
|
- System design decisions and rationale
|
|
- Technology stack and framework choices
|
|
- Integration points and APIs
|
|
- Data models and storage decisions
|
|
- Security and performance considerations
|
|
- Any architectural constraints that might affect story implementation
|
|
</action>
|
|
|
|
<action>For Epic/Story analysis, focus on:
|
|
|
|
- Coverage of PRD requirements
|
|
- Story sequencing and dependencies
|
|
- Acceptance criteria completeness
|
|
- Technical tasks within stories
|
|
- Estimated complexity and effort indicators
|
|
</action>
|
|
|
|
<template-output>document_analysis</template-output>
|
|
</step>
|
|
|
|
<step n="3" goal="Cross-reference validation and alignment check">
|
|
|
|
<action>PRD ↔ Architecture Alignment:
|
|
|
|
- Verify every PRD requirement has corresponding architectural support
|
|
- Check that architectural decisions don't contradict PRD constraints
|
|
- Identify any architectural additions beyond PRD scope (potential gold-plating)
|
|
- Ensure non-functional requirements from PRD are addressed in architecture document
|
|
- If using new architecture workflow: verify implementation patterns are defined
|
|
</action>
|
|
|
|
<action>PRD ↔ Stories Coverage:
|
|
|
|
- Map each PRD requirement to implementing stories
|
|
- Identify any PRD requirements without story coverage
|
|
- Find stories that don't trace back to PRD requirements
|
|
- Validate that story acceptance criteria align with PRD success criteria
|
|
</action>
|
|
|
|
<action>Architecture ↔ Stories Implementation Check:
|
|
|
|
- Verify architectural decisions are reflected in relevant stories
|
|
- Check that story technical tasks align with architectural approach
|
|
- Identify any stories that might violate architectural constraints
|
|
- Ensure infrastructure and setup stories exist for architectural components
|
|
</action>
|
|
|
|
<template-output>alignment_validation</template-output>
|
|
</step>
|
|
|
|
<step n="4" goal="Gap and risk analysis">
|
|
<action>Identify and categorize all gaps, risks, and potential issues discovered during validation</action>
|
|
|
|
<action>Check for Critical Gaps:
|
|
|
|
- Missing stories for core requirements
|
|
- Unaddressed architectural concerns
|
|
- Absent infrastructure or setup stories for greenfield projects
|
|
- Missing error handling or edge case coverage
|
|
- Security or compliance requirements not addressed
|
|
</action>
|
|
|
|
<action>Identify Sequencing Issues:
|
|
|
|
- Dependencies not properly ordered
|
|
- Stories that assume components not yet built
|
|
- Parallel work that should be sequential
|
|
- Missing prerequisite technical tasks
|
|
</action>
|
|
|
|
<action>Detect Potential Contradictions:
|
|
|
|
- Conflicts between PRD and architecture approaches
|
|
- Stories with conflicting technical approaches
|
|
- Acceptance criteria that contradict requirements
|
|
- Resource or technology conflicts
|
|
</action>
|
|
|
|
<action>Find Gold-Plating and Scope Creep:
|
|
|
|
- Features in architecture not required by PRD
|
|
- Stories implementing beyond requirements
|
|
- Technical complexity beyond project needs
|
|
- Over-engineering indicators
|
|
</action>
|
|
|
|
<action>Check Testability Review (if test-design exists in Phase 3):
|
|
|
|
**Note:** test-design is recommended for BMad Method, required for Enterprise Method
|
|
|
|
- Check if {output_folder}/test-design-system.md exists
|
|
- If exists: Review testability assessment (Controllability, Observability, Reliability)
|
|
- If testability concerns documented: Flag for gate decision
|
|
- If missing AND track is Enterprise: Flag as CRITICAL gap
|
|
- If missing AND track is Method: Note as recommendation (not blocker)
|
|
</action>
|
|
|
|
<template-output>gap_risk_analysis</template-output>
|
|
</step>
|
|
|
|
<step n="5" goal="UX and special concerns validation" optional="true">
|
|
<check if="UX artifacts exist or UX workflow in active path">
|
|
<action>Review UX artifacts and validate integration:
|
|
- Check that UX requirements are reflected in PRD
|
|
- Verify stories include UX implementation tasks
|
|
- Ensure architecture supports UX requirements (performance, responsiveness)
|
|
- Identify any UX concerns not addressed in stories
|
|
</action>
|
|
|
|
<action>Validate accessibility and usability coverage:
|
|
- Check for accessibility requirement coverage in stories
|
|
- Verify responsive design considerations if applicable
|
|
- Ensure user flow completeness across stories
|
|
</action>
|
|
|
|
</check>
|
|
|
|
<template-output>ux_validation</template-output>
|
|
</step>
|
|
|
|
<step n="6" goal="Generate comprehensive readiness assessment">
|
|
<action>Compile all findings into a structured readiness report with:
|
|
- Executive summary of readiness status
|
|
- Project context and validation scope
|
|
- Document inventory and coverage assessment
|
|
- Detailed findings organized by severity (Critical, High, Medium, Low)
|
|
- Specific recommendations for each issue
|
|
- Overall readiness recommendation (Ready, Ready with Conditions, Not Ready)
|
|
</action>
|
|
|
|
<action>Provide actionable next steps:
|
|
|
|
- List any critical issues that must be resolved
|
|
- Suggest specific document updates needed
|
|
- Recommend additional stories or tasks required
|
|
- Propose sequencing adjustments if needed
|
|
</action>
|
|
|
|
<action>Include positive findings:
|
|
|
|
- Highlight well-aligned areas
|
|
- Note particularly thorough documentation
|
|
- Recognize good architectural decisions
|
|
- Commend comprehensive story coverage where found
|
|
</action>
|
|
|
|
<template-output>readiness_assessment</template-output>
|
|
</step>
|
|
|
|
<step n="7" goal="Update status and complete" tag="workflow-status">
|
|
<check if="standalone_mode != true">
|
|
<action>Load the FULL file: {workflow_status_file}</action>
|
|
<action>Find workflow_status key "implementation-readiness"</action>
|
|
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
|
<action>Update workflow_status["implementation-readiness"] = "{output_folder}/implementation-readiness-report-{{date}}.md"</action>
|
|
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
|
|
|
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
|
<action>Determine next agent from path file based on next workflow</action>
|
|
</check>
|
|
|
|
<action>Determine overall readiness status from the readiness_assessment (Ready, Ready with Conditions, or Not Ready)</action>
|
|
|
|
<output>**✅ Implementation Readiness Check Complete!**
|
|
|
|
**Assessment Report:**
|
|
|
|
- Readiness assessment saved to: {output_folder}/implementation-readiness-report-{{date}}.md
|
|
|
|
{{#if standalone_mode != true}}
|
|
**Status Updated:**
|
|
|
|
- Progress tracking updated: implementation-readiness marked complete
|
|
- Next workflow: {{next_workflow}}
|
|
{{else}}
|
|
**Note:** Running in standalone mode (no progress tracking)
|
|
{{/if}}
|
|
|
|
**Next Steps:**
|
|
|
|
{{#if standalone_mode != true}}
|
|
|
|
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
|
|
- Review the assessment report and address any critical issues before proceeding
|
|
|
|
Check status anytime with: `workflow-status`
|
|
{{else}}
|
|
Since no workflow is in progress:
|
|
|
|
- Refer to the BMM workflow guide if unsure what to do next
|
|
- Or run `workflow-init` to create a workflow path and get guided next steps
|
|
{{/if}}
|
|
</output>
|
|
|
|
<check if="overall readiness status is Ready OR Ready with Conditions">
|
|
<output>**🚀 Ready for Implementation!**
|
|
|
|
Your project artifacts are aligned and complete. You can now proceed to Phase 4: Implementation.
|
|
</output>
|
|
|
|
<ask>Would you like to run the **sprint-planning** workflow to initialize your sprint tracking and prepare for development? (yes/no)</ask>
|
|
|
|
<check if="yes">
|
|
<action>Inform user that sprint-planning workflow will be invoked</action>
|
|
<invoke-workflow path="{project-root}/.bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml" />
|
|
</check>
|
|
<check if="no">
|
|
<output>You can run sprint-planning later when ready: `sprint-planning`</output>
|
|
</check>
|
|
</check>
|
|
|
|
<check if="overall readiness status is Not Ready">
|
|
<output>**⚠️ Not Ready for Implementation**
|
|
|
|
Critical issues must be resolved before proceeding. Review the assessment report and address the identified gaps.
|
|
|
|
Once issues are resolved, re-run implementation-readiness to validate again.
|
|
</output>
|
|
</check>
|
|
|
|
<template-output>status_update_result</template-output>
|
|
</step>
|
|
|
|
</workflow>
|