mirror of
https://github.com/mmahdium/portfolio.git
synced 2026-09-29 11:01:41 +03:30
chore: add BMAD agent workflows and configuration system
- Add comprehensive agent workflow definitions for 8 specialized roles (analyst, architect, developer, product manager, scrum master, technical writer, UX designer, QA engineer) - Add 35+ workflow definitions covering analysis, planning, solutioning, and implementation phases - Add BMAD configuration system with agent, task, tool, workflow, and file manifests - Add BMM (Business Model Methodology) documentation including quick-start guides, architecture references, and workflow analysis - Add test architecture knowledge base with 20+ testing patterns and best practices - Add team configuration templates and party mode setup for collaborative development - Establish foundation for enterprise agentic development framework with adaptive scaling capabilities
This commit is contained in:
mahdiarghyani
@@ -0,0 +1,310 @@
|
||||
# Create UX Design Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate UX Design Specification is complete, collaborative, and implementation-ready.
|
||||
|
||||
**Paradigm**: Visual collaboration-driven, not template generation
|
||||
|
||||
**Expected Outputs**:
|
||||
|
||||
- ux-design-specification.md
|
||||
- ux-color-themes.html (color theme visualizer)
|
||||
- ux-design-directions.html (design mockups)
|
||||
- Optional: ux-prototype.html, ux-component-showcase.html, ai-frontend-prompt.md
|
||||
|
||||
---
|
||||
|
||||
## 1. Output Files Exist
|
||||
|
||||
- [ ] **ux-design-specification.md** created in output folder
|
||||
- [ ] **ux-color-themes.html** generated (interactive color exploration)
|
||||
- [ ] **ux-design-directions.html** generated (6-8 design mockups)
|
||||
- [ ] No unfilled {{template_variables}} in specification
|
||||
- [ ] All sections have content (not placeholder text)
|
||||
|
||||
---
|
||||
|
||||
## 2. Collaborative Process Validation
|
||||
|
||||
**The workflow should facilitate decisions WITH the user, not FOR them**
|
||||
|
||||
- [ ] **Design system chosen by user** (not auto-selected)
|
||||
- [ ] **Color theme selected from options** (user saw visualizations and chose)
|
||||
- [ ] **Design direction chosen from mockups** (user explored 6-8 options)
|
||||
- [ ] **User journey flows designed collaboratively** (options presented, user decided)
|
||||
- [ ] **UX patterns decided with user input** (not just generated)
|
||||
- [ ] **Decisions documented WITH rationale** (why each choice was made)
|
||||
|
||||
---
|
||||
|
||||
## 3. Visual Collaboration Artifacts
|
||||
|
||||
### Color Theme Visualizer
|
||||
|
||||
- [ ] **HTML file exists and is valid** (ux-color-themes.html)
|
||||
- [ ] **Shows 3-4 theme options** (or documented existing brand)
|
||||
- [ ] **Each theme has complete palette** (primary, secondary, semantic colors)
|
||||
- [ ] **Live UI component examples** in each theme (buttons, forms, cards)
|
||||
- [ ] **Side-by-side comparison** enabled
|
||||
- [ ] **User's selection documented** in specification
|
||||
|
||||
### Design Direction Mockups
|
||||
|
||||
- [ ] **HTML file exists and is valid** (ux-design-directions.html)
|
||||
- [ ] **6-8 different design approaches** shown
|
||||
- [ ] **Full-screen mockups** of key screens
|
||||
- [ ] **Design philosophy labeled** for each direction (e.g., "Dense Dashboard", "Spacious Explorer")
|
||||
- [ ] **Interactive navigation** between directions
|
||||
- [ ] **Responsive preview** toggle available
|
||||
- [ ] **User's choice documented WITH reasoning** (what they liked, why it fits)
|
||||
|
||||
---
|
||||
|
||||
## 4. Design System Foundation
|
||||
|
||||
- [ ] **Design system chosen** (or custom design decision documented)
|
||||
- [ ] **Current version identified** (if using established system)
|
||||
- [ ] **Components provided by system documented**
|
||||
- [ ] **Custom components needed identified**
|
||||
- [ ] **Decision rationale clear** (why this system for this project)
|
||||
|
||||
---
|
||||
|
||||
## 5. Core Experience Definition
|
||||
|
||||
- [ ] **Defining experience articulated** (the ONE thing that makes this app unique)
|
||||
- [ ] **Novel UX patterns identified** (if applicable)
|
||||
- [ ] **Novel patterns fully designed** (interaction model, states, feedback)
|
||||
- [ ] **Core experience principles defined** (speed, guidance, flexibility, feedback)
|
||||
|
||||
---
|
||||
|
||||
## 6. Visual Foundation
|
||||
|
||||
### Color System
|
||||
|
||||
- [ ] **Complete color palette** (primary, secondary, accent, semantic, neutrals)
|
||||
- [ ] **Semantic color usage defined** (success, warning, error, info)
|
||||
- [ ] **Color accessibility considered** (contrast ratios for text)
|
||||
- [ ] **Brand alignment** (follows existing brand or establishes new identity)
|
||||
|
||||
### Typography
|
||||
|
||||
- [ ] **Font families selected** (heading, body, monospace if needed)
|
||||
- [ ] **Type scale defined** (h1-h6, body, small, etc.)
|
||||
- [ ] **Font weights documented** (when to use each)
|
||||
- [ ] **Line heights specified** for readability
|
||||
|
||||
### Spacing & Layout
|
||||
|
||||
- [ ] **Spacing system defined** (base unit, scale)
|
||||
- [ ] **Layout grid approach** (columns, gutters)
|
||||
- [ ] **Container widths** for different breakpoints
|
||||
|
||||
---
|
||||
|
||||
## 7. Design Direction
|
||||
|
||||
- [ ] **Specific direction chosen** from mockups (not generic)
|
||||
- [ ] **Layout pattern documented** (navigation, content structure)
|
||||
- [ ] **Visual hierarchy defined** (density, emphasis, focus)
|
||||
- [ ] **Interaction patterns specified** (modal vs inline, disclosure approach)
|
||||
- [ ] **Visual style documented** (minimal, balanced, rich, maximalist)
|
||||
- [ ] **User's reasoning captured** (why this direction fits their vision)
|
||||
|
||||
---
|
||||
|
||||
## 8. User Journey Flows
|
||||
|
||||
- [ ] **All critical journeys from PRD designed** (no missing flows)
|
||||
- [ ] **Each flow has clear goal** (what user accomplishes)
|
||||
- [ ] **Flow approach chosen collaboratively** (user picked from options)
|
||||
- [ ] **Step-by-step documentation** (screens, actions, feedback)
|
||||
- [ ] **Decision points and branching** defined
|
||||
- [ ] **Error states and recovery** addressed
|
||||
- [ ] **Success states specified** (completion feedback)
|
||||
- [ ] **Mermaid diagrams or clear flow descriptions** included
|
||||
|
||||
---
|
||||
|
||||
## 9. Component Library Strategy
|
||||
|
||||
- [ ] **All required components identified** (from design system + custom)
|
||||
- [ ] **Custom components fully specified**:
|
||||
- Purpose and user-facing value
|
||||
- Content/data displayed
|
||||
- User actions available
|
||||
- All states (default, hover, active, loading, error, disabled)
|
||||
- Variants (sizes, styles, layouts)
|
||||
- Behavior on interaction
|
||||
- Accessibility considerations
|
||||
- [ ] **Design system components customization needs** documented
|
||||
|
||||
---
|
||||
|
||||
## 10. UX Pattern Consistency Rules
|
||||
|
||||
**These patterns ensure consistent UX across the entire app**
|
||||
|
||||
- [ ] **Button hierarchy defined** (primary, secondary, tertiary, destructive)
|
||||
- [ ] **Feedback patterns established** (success, error, warning, info, loading)
|
||||
- [ ] **Form patterns specified** (labels, validation, errors, help text)
|
||||
- [ ] **Modal patterns defined** (sizes, dismiss behavior, focus, stacking)
|
||||
- [ ] **Navigation patterns documented** (active state, breadcrumbs, back button)
|
||||
- [ ] **Empty state patterns** (first use, no results, cleared content)
|
||||
- [ ] **Confirmation patterns** (when to confirm destructive actions)
|
||||
- [ ] **Notification patterns** (placement, duration, stacking, priority)
|
||||
- [ ] **Search patterns** (trigger, results, filters, no results)
|
||||
- [ ] **Date/time patterns** (format, timezone, pickers)
|
||||
|
||||
**Each pattern should have:**
|
||||
|
||||
- [ ] Clear specification (how it works)
|
||||
- [ ] Usage guidance (when to use)
|
||||
- [ ] Examples (concrete implementations)
|
||||
|
||||
---
|
||||
|
||||
## 11. Responsive Design
|
||||
|
||||
- [ ] **Breakpoints defined** for target devices (mobile, tablet, desktop)
|
||||
- [ ] **Adaptation patterns documented** (how layouts change)
|
||||
- [ ] **Navigation adaptation** (how nav changes on small screens)
|
||||
- [ ] **Content organization changes** (multi-column to single, grid to list)
|
||||
- [ ] **Touch targets adequate** on mobile (minimum size specified)
|
||||
- [ ] **Responsive strategy aligned** with chosen design direction
|
||||
|
||||
---
|
||||
|
||||
## 12. Accessibility
|
||||
|
||||
- [ ] **WCAG compliance level specified** (A, AA, or AAA)
|
||||
- [ ] **Color contrast requirements** documented (ratios for text)
|
||||
- [ ] **Keyboard navigation** addressed (all interactive elements accessible)
|
||||
- [ ] **Focus indicators** specified (visible focus states)
|
||||
- [ ] **ARIA requirements** noted (roles, labels, announcements)
|
||||
- [ ] **Screen reader considerations** (meaningful labels, structure)
|
||||
- [ ] **Alt text strategy** for images
|
||||
- [ ] **Form accessibility** (label associations, error identification)
|
||||
- [ ] **Testing strategy** defined (automated tools, manual testing)
|
||||
|
||||
---
|
||||
|
||||
## 13. Coherence and Integration
|
||||
|
||||
- [ ] **Design system and custom components visually consistent**
|
||||
- [ ] **All screens follow chosen design direction**
|
||||
- [ ] **Color usage consistent with semantic meanings**
|
||||
- [ ] **Typography hierarchy clear and consistent**
|
||||
- [ ] **Similar actions handled the same way** (pattern consistency)
|
||||
- [ ] **All PRD user journeys have UX design**
|
||||
- [ ] **All entry points designed**
|
||||
- [ ] **Error and edge cases handled**
|
||||
- [ ] **Every interactive element meets accessibility requirements**
|
||||
- [ ] **All flows keyboard-navigable**
|
||||
- [ ] **Colors meet contrast requirements**
|
||||
|
||||
---
|
||||
|
||||
## 14. Cross-Workflow Alignment (Epics File Update)
|
||||
|
||||
**As UX design progresses, you discover implementation details that affect the story breakdown**
|
||||
|
||||
### Stories Discovered During UX Design
|
||||
|
||||
- [ ] **Review epics.md file** for alignment with UX design
|
||||
- [ ] **New stories identified** during UX design that weren't in epics.md:
|
||||
- [ ] Custom component build stories (if significant)
|
||||
- [ ] UX pattern implementation stories
|
||||
- [ ] Animation/transition stories
|
||||
- [ ] Responsive adaptation stories
|
||||
- [ ] Accessibility implementation stories
|
||||
- [ ] Edge case handling stories discovered during journey design
|
||||
- [ ] Onboarding/empty state stories
|
||||
- [ ] Error state handling stories
|
||||
|
||||
### Story Complexity Adjustments
|
||||
|
||||
- [ ] **Existing stories complexity reassessed** based on UX design:
|
||||
- [ ] Stories that are now more complex (UX revealed additional requirements)
|
||||
- [ ] Stories that are simpler (design system handles more than expected)
|
||||
- [ ] Stories that should be split (UX design shows multiple components/flows)
|
||||
- [ ] Stories that can be combined (UX design shows they're tightly coupled)
|
||||
|
||||
### Epic Alignment
|
||||
|
||||
- [ ] **Epic scope still accurate** after UX design
|
||||
- [ ] **New epic needed** for discovered work (if significant)
|
||||
- [ ] **Epic ordering might change** based on UX dependencies
|
||||
|
||||
### Action Items for Epics File Update
|
||||
|
||||
- [ ] **List of new stories to add** to epics.md documented
|
||||
- [ ] **Complexity adjustments noted** for existing stories
|
||||
- [ ] **Update epics.md** OR flag for architecture review first
|
||||
- [ ] **Rationale documented** for why new stories/changes are needed
|
||||
|
||||
**Note:** If significant story changes are identified, consider running architecture workflow BEFORE updating epics.md, since architecture decisions might reveal additional adjustments needed.
|
||||
|
||||
---
|
||||
|
||||
## 15. Decision Rationale
|
||||
|
||||
**Unlike template-driven workflows, this workflow should document WHY**
|
||||
|
||||
- [ ] **Design system choice has rationale** (why this fits the project)
|
||||
- [ ] **Color theme selection has reasoning** (why this emotional impact)
|
||||
- [ ] **Design direction choice explained** (what user liked, how it fits vision)
|
||||
- [ ] **User journey approaches justified** (why this flow pattern)
|
||||
- [ ] **UX pattern decisions have context** (why these patterns for this app)
|
||||
- [ ] **Responsive strategy aligned with user priorities**
|
||||
- [ ] **Accessibility level appropriate for deployment intent**
|
||||
|
||||
---
|
||||
|
||||
## 16. Implementation Readiness
|
||||
|
||||
- [ ] **Designers can create high-fidelity mockups** from this spec
|
||||
- [ ] **Developers can implement** with clear UX guidance
|
||||
- [ ] **Sufficient detail** for frontend development
|
||||
- [ ] **Component specifications actionable** (states, variants, behaviors)
|
||||
- [ ] **Flows implementable** (clear steps, decision logic, error handling)
|
||||
- [ ] **Visual foundation complete** (colors, typography, spacing all defined)
|
||||
- [ ] **Pattern consistency enforceable** (clear rules for implementation)
|
||||
|
||||
---
|
||||
|
||||
## 17. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **No visual collaboration** (color themes or design mockups not generated)
|
||||
- [ ] ❌ **User not involved in decisions** (auto-generated without collaboration)
|
||||
- [ ] ❌ **No design direction chosen** (missing key visual decisions)
|
||||
- [ ] ❌ **No user journey designs** (critical flows not documented)
|
||||
- [ ] ❌ **No UX pattern consistency rules** (implementation will be inconsistent)
|
||||
- [ ] ❌ **Missing core experience definition** (no clarity on what makes app unique)
|
||||
- [ ] ❌ **No component specifications** (components not actionable)
|
||||
- [ ] ❌ **Responsive strategy missing** (for multi-platform projects)
|
||||
- [ ] ❌ **Accessibility ignored** (no compliance target or requirements)
|
||||
- [ ] ❌ **Generic/templated content** (not specific to this project)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document findings:**
|
||||
|
||||
- UX Design Quality: [Exceptional / Strong / Adequate / Needs Work / Incomplete]
|
||||
- Collaboration Level: [Highly Collaborative / Collaborative / Somewhat Collaborative / Generated]
|
||||
- Visual Artifacts: [Complete & Interactive / Partial / Missing]
|
||||
- Implementation Readiness: [Ready / Needs Design Phase / Not Ready]
|
||||
|
||||
## **Strengths:**
|
||||
|
||||
## **Areas for Improvement:**
|
||||
|
||||
## **Recommended Actions:**
|
||||
|
||||
**Ready for next phase?** [Yes - Proceed to Design / Yes - Proceed to Development / Needs Refinement]
|
||||
|
||||
---
|
||||
|
||||
_This checklist validates collaborative UX design facilitation, not template generation. A successful UX workflow creates design decisions WITH the user through visual exploration and informed choices._
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,145 @@
|
||||
# {{project_name}} UX Design Specification
|
||||
|
||||
_Created on {{date}} by {{user_name}}_
|
||||
_Generated using BMad Method - Create UX Design Workflow v1.0_
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{project_vision}}
|
||||
|
||||
---
|
||||
|
||||
## 1. Design System Foundation
|
||||
|
||||
### 1.1 Design System Choice
|
||||
|
||||
{{design_system_decision}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Core User Experience
|
||||
|
||||
### 2.1 Defining Experience
|
||||
|
||||
{{core_experience}}
|
||||
|
||||
### 2.2 Novel UX Patterns
|
||||
|
||||
{{novel_ux_patterns}}
|
||||
|
||||
---
|
||||
|
||||
## 3. Visual Foundation
|
||||
|
||||
### 3.1 Color System
|
||||
|
||||
{{visual_foundation}}
|
||||
|
||||
**Interactive Visualizations:**
|
||||
|
||||
- Color Theme Explorer: [ux-color-themes.html](./ux-color-themes.html)
|
||||
|
||||
---
|
||||
|
||||
## 4. Design Direction
|
||||
|
||||
### 4.1 Chosen Design Approach
|
||||
|
||||
{{design_direction_decision}}
|
||||
|
||||
**Interactive Mockups:**
|
||||
|
||||
- Design Direction Showcase: [ux-design-directions.html](./ux-design-directions.html)
|
||||
|
||||
---
|
||||
|
||||
## 5. User Journey Flows
|
||||
|
||||
### 5.1 Critical User Paths
|
||||
|
||||
{{user_journey_flows}}
|
||||
|
||||
---
|
||||
|
||||
## 6. Component Library
|
||||
|
||||
### 6.1 Component Strategy
|
||||
|
||||
{{component_library_strategy}}
|
||||
|
||||
---
|
||||
|
||||
## 7. UX Pattern Decisions
|
||||
|
||||
### 7.1 Consistency Rules
|
||||
|
||||
{{ux_pattern_decisions}}
|
||||
|
||||
---
|
||||
|
||||
## 8. Responsive Design & Accessibility
|
||||
|
||||
### 8.1 Responsive Strategy
|
||||
|
||||
{{responsive_accessibility_strategy}}
|
||||
|
||||
---
|
||||
|
||||
## 9. Implementation Guidance
|
||||
|
||||
### 9.1 Completion Summary
|
||||
|
||||
{{completion_summary}}
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Related Documents
|
||||
|
||||
- Product Requirements: `{{prd_file}}`
|
||||
- Product Brief: `{{brief_file}}`
|
||||
- Brainstorming: `{{brainstorm_file}}`
|
||||
|
||||
### Core Interactive Deliverables
|
||||
|
||||
This UX Design Specification was created through visual collaboration:
|
||||
|
||||
- **Color Theme Visualizer**: {{color_themes_html}}
|
||||
- Interactive HTML showing all color theme options explored
|
||||
- Live UI component examples in each theme
|
||||
- Side-by-side comparison and semantic color usage
|
||||
|
||||
- **Design Direction Mockups**: {{design_directions_html}}
|
||||
- Interactive HTML with 6-8 complete design approaches
|
||||
- Full-screen mockups of key screens
|
||||
- Design philosophy and rationale for each direction
|
||||
|
||||
### Optional Enhancement Deliverables
|
||||
|
||||
_This section will be populated if additional UX artifacts are generated through follow-up workflows._
|
||||
|
||||
<!-- Additional deliverables added here by other workflows -->
|
||||
|
||||
### Next Steps & Follow-Up Workflows
|
||||
|
||||
This UX Design Specification can serve as input to:
|
||||
|
||||
- **Wireframe Generation Workflow** - Create detailed wireframes from user flows
|
||||
- **Figma Design Workflow** - Generate Figma files via MCP integration
|
||||
- **Interactive Prototype Workflow** - Build clickable HTML prototypes
|
||||
- **Component Showcase Workflow** - Create interactive component library
|
||||
- **AI Frontend Prompt Workflow** - Generate prompts for v0, Lovable, Bolt, etc.
|
||||
- **Solution Architecture Workflow** - Define technical architecture with UX context
|
||||
|
||||
### Version History
|
||||
|
||||
| Date | Version | Changes | Author |
|
||||
| -------- | ------- | ------------------------------- | ------------- |
|
||||
| {{date}} | 1.0 | Initial UX Design Specification | {{user_name}} |
|
||||
|
||||
---
|
||||
|
||||
_This UX Design Specification was created through collaborative design facilitation, not template generation. All decisions were made with user input and are documented with rationale._
|
||||
@@ -0,0 +1,61 @@
|
||||
# Create UX Design Workflow Configuration
|
||||
name: create-ux-design
|
||||
description: "Collaborative UX design facilitation workflow that creates exceptional user experiences through visual exploration and informed decision-making. Unlike template-driven approaches, this workflow facilitates discovery, generates visual options, and collaboratively designs the UX with the user at every step."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/.bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
|
||||
input_file_patterns:
|
||||
prd:
|
||||
description: "Features and user journeys (optional)"
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
product_brief:
|
||||
description: "Product vision and target users (optional)"
|
||||
whole: "{output_folder}/*brief*.md"
|
||||
sharded: "{output_folder}/*brief*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
epics:
|
||||
description: "Epic and story breakdown (optional)"
|
||||
whole: "{output_folder}/*epic*.md"
|
||||
sharded: "{output_folder}/*epic*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
brainstorming:
|
||||
description: "Brainstorming ideas and concepts (optional)"
|
||||
whole: "{output_folder}/*brainstorm*.md"
|
||||
sharded: "{output_folder}/*brainstorm*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
document_project:
|
||||
description: "Brownfield project documentation (optional)"
|
||||
sharded: "{output_folder}/index.md"
|
||||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/.bmad/bmm/workflows/2-plan-workflows/create-ux-design"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
template: "{installed_path}/ux-design-template.md"
|
||||
|
||||
# Output configuration - Progressive saves throughout workflow
|
||||
default_output_file: "{output_folder}/ux-design-specification.md"
|
||||
color_themes_html: "{output_folder}/ux-color-themes.html"
|
||||
design_directions_html: "{output_folder}/ux-design-directions.html"
|
||||
|
||||
standalone: true
|
||||
|
||||
# Web bundle configuration for standalone deployment
|
||||
@@ -0,0 +1,346 @@
|
||||
# PRD + Epics + Stories Validation Checklist
|
||||
|
||||
**Purpose**: Comprehensive validation that PRD, epics, and stories form a complete, implementable product plan.
|
||||
|
||||
**Scope**: Validates the complete planning output (PRD.md + epics.md) for Levels 2-4 software projects
|
||||
|
||||
**Expected Outputs**:
|
||||
|
||||
- PRD.md with complete requirements
|
||||
- epics.md with detailed epic and story breakdown
|
||||
- Updated bmm-workflow-status.yaml
|
||||
|
||||
---
|
||||
|
||||
## 1. PRD Document Completeness
|
||||
|
||||
### Core Sections Present
|
||||
|
||||
- [ ] Executive Summary with vision alignment
|
||||
- [ ] Product differentiator clearly articulated
|
||||
- [ ] Project classification (type, domain, complexity)
|
||||
- [ ] Success criteria defined
|
||||
- [ ] Product scope (MVP, Growth, Vision) clearly delineated
|
||||
- [ ] Functional requirements comprehensive and numbered
|
||||
- [ ] Non-functional requirements (when applicable)
|
||||
- [ ] References section with source documents
|
||||
|
||||
### Project-Specific Sections
|
||||
|
||||
- [ ] **If complex domain:** Domain context and considerations documented
|
||||
- [ ] **If innovation:** Innovation patterns and validation approach documented
|
||||
- [ ] **If API/Backend:** Endpoint specification and authentication model included
|
||||
- [ ] **If Mobile:** Platform requirements and device features documented
|
||||
- [ ] **If SaaS B2B:** Tenant model and permission matrix included
|
||||
- [ ] **If UI exists:** UX principles and key interactions documented
|
||||
|
||||
### Quality Checks
|
||||
|
||||
- [ ] No unfilled template variables ({{variable}})
|
||||
- [ ] All variables properly populated with meaningful content
|
||||
- [ ] Product differentiator reflected throughout (not just stated once)
|
||||
- [ ] Language is clear, specific, and measurable
|
||||
- [ ] Project type correctly identified and sections match
|
||||
- [ ] Domain complexity appropriately addressed
|
||||
|
||||
---
|
||||
|
||||
## 2. Functional Requirements Quality
|
||||
|
||||
### FR Format and Structure
|
||||
|
||||
- [ ] Each FR has unique identifier (FR-001, FR-002, etc.)
|
||||
- [ ] FRs describe WHAT capabilities, not HOW to implement
|
||||
- [ ] FRs are specific and measurable
|
||||
- [ ] FRs are testable and verifiable
|
||||
- [ ] FRs focus on user/business value
|
||||
- [ ] No technical implementation details in FRs (those belong in architecture)
|
||||
|
||||
### FR Completeness
|
||||
|
||||
- [ ] All MVP scope features have corresponding FRs
|
||||
- [ ] Growth features documented (even if deferred)
|
||||
- [ ] Vision features captured for future reference
|
||||
- [ ] Domain-mandated requirements included
|
||||
- [ ] Innovation requirements captured with validation needs
|
||||
- [ ] Project-type specific requirements complete
|
||||
|
||||
### FR Organization
|
||||
|
||||
- [ ] FRs organized by capability/feature area (not by tech stack)
|
||||
- [ ] Related FRs grouped logically
|
||||
- [ ] Dependencies between FRs noted when critical
|
||||
- [ ] Priority/phase indicated (MVP vs Growth vs Vision)
|
||||
|
||||
---
|
||||
|
||||
## 3. Epics Document Completeness
|
||||
|
||||
### Required Files
|
||||
|
||||
- [ ] epics.md exists in output folder
|
||||
- [ ] Epic list in PRD.md matches epics in epics.md (titles and count)
|
||||
- [ ] All epics have detailed breakdown sections
|
||||
|
||||
### Epic Quality
|
||||
|
||||
- [ ] Each epic has clear goal and value proposition
|
||||
- [ ] Each epic includes complete story breakdown
|
||||
- [ ] Stories follow proper user story format: "As a [role], I want [goal], so that [benefit]"
|
||||
- [ ] Each story has numbered acceptance criteria
|
||||
- [ ] Prerequisites/dependencies explicitly stated per story
|
||||
- [ ] Stories are AI-agent sized (completable in 2-4 hour session)
|
||||
|
||||
---
|
||||
|
||||
## 4. FR Coverage Validation (CRITICAL)
|
||||
|
||||
### Complete Traceability
|
||||
|
||||
- [ ] **Every FR from PRD.md is covered by at least one story in epics.md**
|
||||
- [ ] Each story references relevant FR numbers
|
||||
- [ ] No orphaned FRs (requirements without stories)
|
||||
- [ ] No orphaned stories (stories without FR connection)
|
||||
- [ ] Coverage matrix verified (can trace FR → Epic → Stories)
|
||||
|
||||
### Coverage Quality
|
||||
|
||||
- [ ] Stories sufficiently decompose FRs into implementable units
|
||||
- [ ] Complex FRs broken into multiple stories appropriately
|
||||
- [ ] Simple FRs have appropriately scoped single stories
|
||||
- [ ] Non-functional requirements reflected in story acceptance criteria
|
||||
- [ ] Domain requirements embedded in relevant stories
|
||||
|
||||
---
|
||||
|
||||
## 5. Story Sequencing Validation (CRITICAL)
|
||||
|
||||
### Epic 1 Foundation Check
|
||||
|
||||
- [ ] **Epic 1 establishes foundational infrastructure**
|
||||
- [ ] Epic 1 delivers initial deployable functionality
|
||||
- [ ] Epic 1 creates baseline for subsequent epics
|
||||
- [ ] Exception: If adding to existing app, foundation requirement adapted appropriately
|
||||
|
||||
### Vertical Slicing
|
||||
|
||||
- [ ] **Each story delivers complete, testable functionality** (not horizontal layers)
|
||||
- [ ] No "build database" or "create UI" stories in isolation
|
||||
- [ ] Stories integrate across stack (data + logic + presentation when applicable)
|
||||
- [ ] Each story leaves system in working/deployable state
|
||||
|
||||
### No Forward Dependencies
|
||||
|
||||
- [ ] **No story depends on work from a LATER story or epic**
|
||||
- [ ] Stories within each epic are sequentially ordered
|
||||
- [ ] Each story builds only on previous work
|
||||
- [ ] Dependencies flow backward only (can reference earlier stories)
|
||||
- [ ] Parallel tracks clearly indicated if stories are independent
|
||||
|
||||
### Value Delivery Path
|
||||
|
||||
- [ ] Each epic delivers significant end-to-end value
|
||||
- [ ] Epic sequence shows logical product evolution
|
||||
- [ ] User can see value after each epic completion
|
||||
- [ ] MVP scope clearly achieved by end of designated epics
|
||||
|
||||
---
|
||||
|
||||
## 6. Scope Management
|
||||
|
||||
### MVP Discipline
|
||||
|
||||
- [ ] MVP scope is genuinely minimal and viable
|
||||
- [ ] Core features list contains only true must-haves
|
||||
- [ ] Each MVP feature has clear rationale for inclusion
|
||||
- [ ] No obvious scope creep in "must-have" list
|
||||
|
||||
### Future Work Captured
|
||||
|
||||
- [ ] Growth features documented for post-MVP
|
||||
- [ ] Vision features captured to maintain long-term direction
|
||||
- [ ] Out-of-scope items explicitly listed
|
||||
- [ ] Deferred features have clear reasoning for deferral
|
||||
|
||||
### Clear Boundaries
|
||||
|
||||
- [ ] Stories marked as MVP vs Growth vs Vision
|
||||
- [ ] Epic sequencing aligns with MVP → Growth progression
|
||||
- [ ] No confusion about what's in vs out of initial scope
|
||||
|
||||
---
|
||||
|
||||
## 7. Research and Context Integration
|
||||
|
||||
### Source Document Integration
|
||||
|
||||
- [ ] **If product brief exists:** Key insights incorporated into PRD
|
||||
- [ ] **If domain brief exists:** Domain requirements reflected in FRs and stories
|
||||
- [ ] **If research documents exist:** Research findings inform requirements
|
||||
- [ ] **If competitive analysis exists:** Differentiation strategy clear in PRD
|
||||
- [ ] All source documents referenced in PRD References section
|
||||
|
||||
### Research Continuity to Architecture
|
||||
|
||||
- [ ] Domain complexity considerations documented for architects
|
||||
- [ ] Technical constraints from research captured
|
||||
- [ ] Regulatory/compliance requirements clearly stated
|
||||
- [ ] Integration requirements with existing systems documented
|
||||
- [ ] Performance/scale requirements informed by research data
|
||||
|
||||
### Information Completeness for Next Phase
|
||||
|
||||
- [ ] PRD provides sufficient context for architecture decisions
|
||||
- [ ] Epics provide sufficient detail for technical design
|
||||
- [ ] Stories have enough acceptance criteria for implementation
|
||||
- [ ] Non-obvious business rules documented
|
||||
- [ ] Edge cases and special scenarios captured
|
||||
|
||||
---
|
||||
|
||||
## 8. Cross-Document Consistency
|
||||
|
||||
### Terminology Consistency
|
||||
|
||||
- [ ] Same terms used across PRD and epics for concepts
|
||||
- [ ] Feature names consistent between documents
|
||||
- [ ] Epic titles match between PRD and epics.md
|
||||
- [ ] No contradictions between PRD and epics
|
||||
|
||||
### Alignment Checks
|
||||
|
||||
- [ ] Success metrics in PRD align with story outcomes
|
||||
- [ ] Product differentiator articulated in PRD reflected in epic goals
|
||||
- [ ] Technical preferences in PRD align with story implementation hints
|
||||
- [ ] Scope boundaries consistent across all documents
|
||||
|
||||
---
|
||||
|
||||
## 9. Readiness for Implementation
|
||||
|
||||
### Architecture Readiness (Next Phase)
|
||||
|
||||
- [ ] PRD provides sufficient context for architecture workflow
|
||||
- [ ] Technical constraints and preferences documented
|
||||
- [ ] Integration points identified
|
||||
- [ ] Performance/scale requirements specified
|
||||
- [ ] Security and compliance needs clear
|
||||
|
||||
### Development Readiness
|
||||
|
||||
- [ ] Stories are specific enough to estimate
|
||||
- [ ] Acceptance criteria are testable
|
||||
- [ ] Technical unknowns identified and flagged
|
||||
- [ ] Dependencies on external systems documented
|
||||
- [ ] Data requirements specified
|
||||
|
||||
### Track-Appropriate Detail
|
||||
|
||||
**If BMad Method:**
|
||||
|
||||
- [ ] PRD supports full architecture workflow
|
||||
- [ ] Epic structure supports phased delivery
|
||||
- [ ] Scope appropriate for product/platform development
|
||||
- [ ] Clear value delivery through epic sequence
|
||||
|
||||
**If Enterprise Method:**
|
||||
|
||||
- [ ] PRD addresses enterprise requirements (security, compliance, multi-tenancy)
|
||||
- [ ] Epic structure supports extended planning phases
|
||||
- [ ] Scope includes security, devops, and test strategy considerations
|
||||
- [ ] Clear value delivery with enterprise gates
|
||||
|
||||
---
|
||||
|
||||
## 10. Quality and Polish
|
||||
|
||||
### Writing Quality
|
||||
|
||||
- [ ] Language is clear and free of jargon (or jargon is defined)
|
||||
- [ ] Sentences are concise and specific
|
||||
- [ ] No vague statements ("should be fast", "user-friendly")
|
||||
- [ ] Measurable criteria used throughout
|
||||
- [ ] Professional tone appropriate for stakeholder review
|
||||
|
||||
### Document Structure
|
||||
|
||||
- [ ] Sections flow logically
|
||||
- [ ] Headers and numbering consistent
|
||||
- [ ] Cross-references accurate (FR numbers, section references)
|
||||
- [ ] Formatting consistent throughout
|
||||
- [ ] Tables/lists formatted properly
|
||||
|
||||
### Completeness Indicators
|
||||
|
||||
- [ ] No [TODO] or [TBD] markers remain
|
||||
- [ ] No placeholder text
|
||||
- [ ] All sections have substantive content
|
||||
- [ ] Optional sections either complete or omitted (not half-done)
|
||||
|
||||
---
|
||||
|
||||
## Critical Failures (Auto-Fail)
|
||||
|
||||
If ANY of these are true, validation FAILS:
|
||||
|
||||
- [ ] ❌ **No epics.md file exists** (two-file output required)
|
||||
- [ ] ❌ **Epic 1 doesn't establish foundation** (violates core sequencing principle)
|
||||
- [ ] ❌ **Stories have forward dependencies** (breaks sequential implementation)
|
||||
- [ ] ❌ **Stories not vertically sliced** (horizontal layers block value delivery)
|
||||
- [ ] ❌ **Epics don't cover all FRs** (orphaned requirements)
|
||||
- [ ] ❌ **FRs contain technical implementation details** (should be in architecture)
|
||||
- [ ] ❌ **No FR traceability to stories** (can't validate coverage)
|
||||
- [ ] ❌ **Template variables unfilled** (incomplete document)
|
||||
|
||||
---
|
||||
|
||||
## Validation Summary
|
||||
|
||||
- **Pass Rate ≥ 95%:** ✅ EXCELLENT - Ready for architecture phase
|
||||
- **Pass Rate 85-94%:** ⚠️ GOOD - Minor fixes needed
|
||||
- **Pass Rate 70-84%:** ⚠️ FAIR - Important issues to address
|
||||
- **Pass Rate < 70%:** ❌ POOR - Significant rework required
|
||||
|
||||
### Critical Issue Threshold
|
||||
|
||||
- **0 Critical Failures:** Proceed to fixes
|
||||
- **1+ Critical Failures:** STOP - Must fix critical issues first
|
||||
|
||||
---
|
||||
|
||||
## Validation Execution Notes
|
||||
|
||||
**When validating:**
|
||||
|
||||
1. **Load ALL documents - whole or sharded (but not both of each) for example epics.md vs epics/\*.md:**
|
||||
- PRD.md (required)
|
||||
- epics.md (required)
|
||||
- product-brief.md (if exists)
|
||||
- domain-brief.md (if exists)
|
||||
- research documents (if referenced)
|
||||
|
||||
2. **Validate in order:**
|
||||
- Check critical failures first (immediate stop if any found)
|
||||
- Verify PRD completeness
|
||||
- Verify epics completeness
|
||||
- Cross-reference FR coverage (most important)
|
||||
- Check sequencing (second most important)
|
||||
- Validate research integration
|
||||
- Check polish and quality
|
||||
|
||||
3. **Report findings:**
|
||||
- List critical failures prominently
|
||||
- Group issues by severity
|
||||
- Provide specific line numbers/sections
|
||||
- Suggest concrete fixes
|
||||
- Highlight what's working well
|
||||
|
||||
4. **Provide actionable next steps:**
|
||||
- If validation passes: "Ready for architecture workflow"
|
||||
- If minor issues: "Fix [X] items then re-validate"
|
||||
- If major issues: "Rework [sections] then re-validate"
|
||||
- If critical failures: "Must fix critical items before proceeding"
|
||||
|
||||
---
|
||||
|
||||
**Remember:** This validation ensures the entire planning phase is complete and the implementation phase has everything needed to succeed. Be thorough but fair - the goal is quality, not perfection.
|
||||
@@ -0,0 +1,13 @@
|
||||
domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
|
||||
healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
|
||||
fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
|
||||
govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
|
||||
edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
|
||||
aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
|
||||
automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
|
||||
scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
|
||||
legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
|
||||
insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
|
||||
energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
|
||||
gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
|
||||
general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
|
||||
|
@@ -0,0 +1,703 @@
|
||||
# PRD Workflow - Intent-Driven Product Planning
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/.bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>This workflow uses INTENT-DRIVEN PLANNING - adapt organically to product type and context</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end</critical>
|
||||
<critical>GUIDING PRINCIPLE: Identify what makes this product special and ensure it's reflected throughout the PRD</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 {status_file} exists</action>
|
||||
|
||||
<action if="status file not found">Set standalone_mode = true</action>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {status_file}</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "prd" workflow</action>
|
||||
<action>Get project_track from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_track is Quick Flow">
|
||||
<output>**Quick Flow Track - Redirecting**
|
||||
|
||||
Quick Flow projects use tech-spec workflow for implementation-focused planning.
|
||||
PRD is for BMad Method and Enterprise Method tracks that need comprehensive requirements.</output>
|
||||
<action>Exit and suggest tech-spec workflow</action>
|
||||
</check>
|
||||
|
||||
<check if="prd status is file path (already completed)">
|
||||
<output>⚠️ PRD already completed: {{prd status}}</output>
|
||||
<ask>Re-running will overwrite the existing PRD. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Discover and load input documents">
|
||||
<invoke-protocol name="discover_inputs" />
|
||||
<note>After discovery, these content variables are available: {product_brief_content}, {research_content}, {document_project_content}</note>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Discovery - Project, Domain, and Vision">
|
||||
<action>Welcome {user_name} and begin comprehensive discovery, and then start to GATHER ALL CONTEXT:
|
||||
1. Check workflow-status.yaml for project_context (if exists)
|
||||
2. Review loaded content: {product_brief_content}, {research_content}, {document_project_content} (auto-loaded in Step 0.5)
|
||||
3. Detect project type AND domain complexity using data-driven classification
|
||||
</action>
|
||||
|
||||
<action>Load classification data files COMPLETELY:
|
||||
|
||||
- Load {project_types_data} - contains project type definitions, detection signals, and requirements
|
||||
- Load {domain_complexity_data} - contains domain classifications, complexity levels, and special requirements
|
||||
|
||||
Parse CSV structure:
|
||||
|
||||
- project_types_data has columns: project_type, detection_signals, key_questions, required_sections, skip_sections, web_search_triggers, innovation_signals
|
||||
- domain_complexity_data has columns: domain, signals, complexity, key_concerns, required_knowledge, suggested_workflow, web_searches, special_sections
|
||||
|
||||
Store these in memory for use throughout the workflow.
|
||||
</action>
|
||||
|
||||
<action>Begin natural discovery conversation:
|
||||
"Tell me about what you want to build - what problem does it solve and for whom?"
|
||||
|
||||
As the user describes their product, listen for signals to classify:
|
||||
|
||||
1. PROJECT TYPE classification
|
||||
2. DOMAIN classification
|
||||
</action>
|
||||
|
||||
<action>DUAL DETECTION - Use CSV data to match:
|
||||
|
||||
**Project Type Detection:**
|
||||
|
||||
- Compare user's description against detection_signals from each row in project_types_data
|
||||
- Look for keyword matches (semicolon-separated in CSV)
|
||||
- Identify best matching project_type (api_backend, mobile_app, saas_b2b, developer_tool, cli_tool, web_app, game, desktop_app, iot_embedded, blockchain_web3)
|
||||
- If multiple matches, ask clarifying question
|
||||
- Store matched project_type value
|
||||
|
||||
**Domain Detection:**
|
||||
|
||||
- Compare user's description against signals from each row in domain_complexity_data
|
||||
- Match domain keywords (semicolon-separated in CSV)
|
||||
- Identify domain (healthcare, fintech, govtech, edtech, aerospace, automotive, scientific, legaltech, insuretech, energy, gaming, general)
|
||||
- Get complexity level from matched row (high/medium/low/redirect)
|
||||
- Store matched domain and complexity_level values
|
||||
|
||||
**Special Cases from CSV:**
|
||||
|
||||
- If project_type = "game" → Use project_types_data row to get redirect message
|
||||
- If domain = "gaming" → Use domain_complexity_data redirect action
|
||||
- If complexity = "high" → Note suggested_workflow and web_searches from domain row
|
||||
</action>
|
||||
|
||||
<action>SPECIAL ROUTING based on detected values:
|
||||
|
||||
**If game detected (from project_types_data):**
|
||||
"Game development requires the BMGD module (BMad Game Development) which has specialized workflows for game design."
|
||||
Exit workflow and redirect to BMGD.
|
||||
|
||||
**If complex domain detected (complexity = "high" from domain_complexity_data):**
|
||||
Extract suggested_workflow and web_searches from the matched domain row.
|
||||
Offer domain research options:
|
||||
A) Run {suggested_workflow} workflow (thorough) - from CSV
|
||||
B) Quick web search using {web_searches} queries - from CSV
|
||||
C) User provides their own domain context
|
||||
D) Continue with general knowledge
|
||||
|
||||
Present the options and WAIT for user choice.
|
||||
</action>
|
||||
|
||||
<action>IDENTIFY WHAT MAKES IT SPECIAL early in conversation:
|
||||
Ask questions like:
|
||||
|
||||
- "What excites you most about this product?"
|
||||
- "What would make users love this?"
|
||||
- "What's the unique value or compelling moment?"
|
||||
- "What makes this different from alternatives?"
|
||||
|
||||
Capture this differentiator - it becomes a thread connecting throughout the PRD.
|
||||
</action>
|
||||
|
||||
<template-output>vision_alignment</template-output>
|
||||
<template-output>project_classification</template-output>
|
||||
<template-output>project_type</template-output>
|
||||
<template-output>domain_type</template-output>
|
||||
<template-output>complexity_level</template-output>
|
||||
<check if="complexity_level == 'high'">
|
||||
<template-output>domain_context_summary</template-output>
|
||||
</check>
|
||||
<template-output>product_differentiator</template-output>
|
||||
<template-output>product_brief_path</template-output>
|
||||
<template-output>domain_brief_path</template-output>
|
||||
<template-output>research_documents</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Success Definition">
|
||||
<action>Define what winning looks like for THIS specific product
|
||||
|
||||
INTENT: Meaningful success criteria, not generic metrics
|
||||
|
||||
Adapt to context:
|
||||
|
||||
- Consumer: User love, engagement, retention
|
||||
- B2B: ROI, efficiency, adoption
|
||||
- Developer tools: Developer experience, community
|
||||
- Regulated: Compliance, safety, validation
|
||||
|
||||
Make it specific:
|
||||
|
||||
- NOT: "10,000 users"
|
||||
- BUT: "100 power users who rely on it daily"
|
||||
|
||||
- NOT: "99.9% uptime"
|
||||
- BUT: "Zero data loss during critical operations"
|
||||
|
||||
Connect to what makes the product special:
|
||||
|
||||
- "Success means users experience [key value moment] and achieve [desired outcome]"</action>
|
||||
|
||||
<template-output>success_criteria</template-output>
|
||||
<check if="business focus">
|
||||
<template-output>business_metrics</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Scope Definition">
|
||||
<action>Smart scope negotiation - find the sweet spot
|
||||
|
||||
The Scoping Game:
|
||||
|
||||
1. "What must work for this to be useful?" → MVP
|
||||
2. "What makes it competitive?" → Growth
|
||||
3. "What's the dream version?" → Vision
|
||||
|
||||
Challenge scope creep conversationally:
|
||||
|
||||
- "Could that wait until after launch?"
|
||||
- "Is that essential for proving the concept?"
|
||||
|
||||
For complex domains:
|
||||
|
||||
- Include compliance minimums in MVP
|
||||
- Note regulatory gates between phases</action>
|
||||
|
||||
<template-output>mvp_scope</template-output>
|
||||
<template-output>growth_features</template-output>
|
||||
<template-output>vision_features</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Domain-Specific Exploration" optional="true">
|
||||
<critical>This step is DATA-DRIVEN using domain_complexity_data CSV loaded in Step 1</critical>
|
||||
<action>Execute only if complexity_level = "high" OR domain-brief exists</action>
|
||||
|
||||
<action>Retrieve domain-specific configuration from CSV:
|
||||
|
||||
1. Find the row in {domain_complexity_data} where domain column matches the detected {domain} from Step 1
|
||||
2. Extract these columns from the matched row:
|
||||
- key_concerns (semicolon-separated list)
|
||||
- required_knowledge (describes what expertise is needed)
|
||||
- web_searches (suggested search queries if research needed)
|
||||
- special_sections (semicolon-separated list of domain-specific sections to document)
|
||||
3. Parse the semicolon-separated values into lists
|
||||
4. Store for use in this step
|
||||
</action>
|
||||
|
||||
<action>Explore domain-specific requirements using key_concerns from CSV:
|
||||
|
||||
Parse key_concerns into individual concern areas.
|
||||
For each concern:
|
||||
|
||||
- Ask the user about their approach to this concern
|
||||
- Discuss implications for the product
|
||||
- Document requirements, constraints, and compliance needs
|
||||
|
||||
Example for healthcare domain:
|
||||
If key_concerns = "FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability"
|
||||
Then explore:
|
||||
|
||||
- "Will this product require FDA approval? What classification?"
|
||||
- "How will you validate clinical accuracy and safety?"
|
||||
- "What HIPAA compliance measures are needed?"
|
||||
- "What patient safety protocols must be in place?"
|
||||
- "What liability considerations affect the design?"
|
||||
|
||||
Synthesize domain requirements that will shape everything:
|
||||
|
||||
- Regulatory requirements (from key_concerns)
|
||||
- Compliance needs (from key_concerns)
|
||||
- Industry standards (from required_knowledge)
|
||||
- Safety/risk factors (from key_concerns)
|
||||
- Required validations (from key_concerns)
|
||||
- Special expertise needed (from required_knowledge)
|
||||
|
||||
These inform:
|
||||
|
||||
- What features are mandatory
|
||||
- What NFRs are critical
|
||||
- How to sequence development
|
||||
- What validation is required
|
||||
</action>
|
||||
|
||||
<check if="complexity_level == 'high'">
|
||||
<template-output>domain_considerations</template-output>
|
||||
|
||||
<action>Generate domain-specific special sections if defined:
|
||||
Parse special_sections list from the matched CSV row.
|
||||
For each section name, generate corresponding template-output.
|
||||
|
||||
Example mappings from CSV:
|
||||
|
||||
- "clinical_requirements" → <template-output>clinical_requirements</template-output>
|
||||
- "regulatory_pathway" → <template-output>regulatory_pathway</template-output>
|
||||
- "safety_measures" → <template-output>safety_measures</template-output>
|
||||
- "compliance_matrix" → <template-output>compliance_matrix</template-output>
|
||||
</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Innovation Discovery" optional="true">
|
||||
<critical>This step uses innovation_signals from project_types_data CSV loaded in Step 1</critical>
|
||||
|
||||
<action>Check for innovation in this product:
|
||||
|
||||
1. Retrieve innovation_signals from the project_type row in {project_types_data}
|
||||
2. Parse the semicolon-separated innovation signals specific to this project type
|
||||
3. Listen for these signals in user's description and throughout conversation
|
||||
|
||||
Example for api_backend:
|
||||
innovation_signals = "API composition;New protocol"
|
||||
|
||||
Example for mobile_app:
|
||||
innovation_signals = "Gesture innovation;AR/VR features"
|
||||
|
||||
Example for saas_b2b:
|
||||
innovation_signals = "Workflow automation;AI agents"
|
||||
</action>
|
||||
|
||||
<action>Listen for general innovation signals in conversation:
|
||||
|
||||
User language indicators:
|
||||
|
||||
- "Nothing like this exists"
|
||||
- "We're rethinking how [X] works"
|
||||
- "Combining [A] with [B] for the first time"
|
||||
- "Novel approach to [problem]"
|
||||
- "No one has done [concept] before"
|
||||
|
||||
Project-type-specific signals (from CSV innovation_signals column):
|
||||
|
||||
- Match user's descriptions against the innovation_signals for their project_type
|
||||
- If matches found, flag as innovation opportunity
|
||||
</action>
|
||||
|
||||
<action>If innovation detected (general OR project-type-specific):
|
||||
|
||||
Explore deeply:
|
||||
|
||||
- What makes it unique?
|
||||
- What assumption are you challenging?
|
||||
- How do we validate it works?
|
||||
- What's the fallback if it doesn't?
|
||||
- Has anyone tried this before?
|
||||
|
||||
Use web_search_triggers from project_types_data CSV if relevant:
|
||||
<WebSearch if="novel">{web_search_triggers} {concept} innovations {date}</WebSearch>
|
||||
</action>
|
||||
|
||||
<check if="innovation detected">
|
||||
<template-output>innovation_patterns</template-output>
|
||||
<template-output>validation_approach</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Project-Specific Deep Dive">
|
||||
<critical>This step is DATA-DRIVEN using project_types_data CSV loaded in Step 1</critical>
|
||||
|
||||
<action>Retrieve project-specific configuration from CSV:
|
||||
|
||||
1. Find the row in {project_types_data} where project_type column matches the detected {project_type} from Step 1
|
||||
2. Extract these columns from the matched row:
|
||||
- key_questions (semicolon-separated list)
|
||||
- required_sections (semicolon-separated list)
|
||||
- skip_sections (semicolon-separated list)
|
||||
- innovation_signals (semicolon-separated list)
|
||||
3. Parse the semicolon-separated values into lists
|
||||
4. Store for use in this step
|
||||
</action>
|
||||
|
||||
<action>Conduct guided discovery using key_questions from CSV:
|
||||
|
||||
Parse key_questions into individual questions.
|
||||
For each question:
|
||||
|
||||
- Ask the user naturally in conversational style
|
||||
- Listen for their response
|
||||
- Ask clarifying follow-ups as needed
|
||||
- Connect answers to product value proposition
|
||||
|
||||
Example flow:
|
||||
If key_questions = "Endpoints needed?;Authentication method?;Data formats?"
|
||||
Then ask:
|
||||
|
||||
- "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?"
|
||||
|
||||
Adapt questions to the user's context and skill level.
|
||||
</action>
|
||||
|
||||
<action>Document project-type-specific requirements:
|
||||
|
||||
Based on the user's answers to key_questions, synthesize comprehensive requirements for this project type.
|
||||
|
||||
Cover the areas indicated by required_sections from CSV (semicolon-separated list).
|
||||
Skip areas indicated by skip_sections from CSV.
|
||||
|
||||
For each required section:
|
||||
|
||||
- Summarize what was discovered
|
||||
- Document specific requirements, constraints, and decisions
|
||||
- Connect to product differentiator when relevant
|
||||
|
||||
Always connect requirements to product value:
|
||||
"How does [requirement] support the product's core value proposition?"
|
||||
</action>
|
||||
|
||||
<template-output>project_type_requirements</template-output>
|
||||
|
||||
<!-- Dynamic template outputs based on required_sections from CSV -->
|
||||
|
||||
<action>Generate dynamic template outputs based on required_sections:
|
||||
|
||||
Parse required_sections list from the matched CSV row.
|
||||
For each section name in the list, generate a corresponding template-output.
|
||||
|
||||
Common mappings (adapt based on actual CSV values):
|
||||
|
||||
- "endpoint_specs" or "endpoint_specification" → <template-output>endpoint_specification</template-output>
|
||||
- "auth_model" or "authentication_model" → <template-output>authentication_model</template-output>
|
||||
- "platform_reqs" or "platform_requirements" → <template-output>platform_requirements</template-output>
|
||||
- "device_permissions" or "device_features" → <template-output>device_features</template-output>
|
||||
- "tenant_model" → <template-output>tenant_model</template-output>
|
||||
- "rbac_matrix" or "permission_matrix" → <template-output>permission_matrix</template-output>
|
||||
|
||||
Generate all outputs dynamically - do not hardcode specific project types.
|
||||
</action>
|
||||
|
||||
<note>Example CSV row for api_backend:
|
||||
key_questions = "Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?"
|
||||
required_sections = "endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs"
|
||||
skip_sections = "ux_ui;visual_design;user_journeys"
|
||||
|
||||
The LLM should parse these and generate corresponding template outputs dynamically.
|
||||
|
||||
**Template Variable Strategy:**
|
||||
The prd-template.md has common template variables defined (endpoint_specification, authentication_model, platform_requirements, device_features, tenant_model, permission_matrix).
|
||||
|
||||
For required_sections that match these common variables:
|
||||
|
||||
- Generate the specific template-output (e.g., endpoint_specs → endpoint_specification)
|
||||
- These will render in their own subsections in the template
|
||||
|
||||
For required_sections that DON'T have matching template variables:
|
||||
|
||||
- Include the content in the main project_type_requirements variable
|
||||
- This ensures all requirements are captured even if template doesn't have dedicated sections
|
||||
|
||||
This hybrid approach balances template structure with CSV-driven flexibility.
|
||||
</note>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="UX Principles" if="project has UI or UX">
|
||||
<action>Only if product has a UI
|
||||
|
||||
Light touch on UX - not full design:
|
||||
|
||||
- Visual personality
|
||||
- Key interaction patterns
|
||||
- Critical user flows
|
||||
|
||||
"How should this feel to use?"
|
||||
"What's the vibe - professional, playful, minimal?"
|
||||
|
||||
Connect UX to product vision:
|
||||
"The UI should reinforce [core value proposition] through [design approach]"</action>
|
||||
|
||||
<check if="has UI">
|
||||
<template-output>ux_principles</template-output>
|
||||
<template-output>key_interactions</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Functional Requirements Synthesis">
|
||||
<critical>This section is THE CAPABILITY CONTRACT for all downstream work</critical>
|
||||
<critical>UX designers will ONLY design what's listed here</critical>
|
||||
<critical>Architects will ONLY support what's listed here</critical>
|
||||
<critical>Epic breakdown will ONLY implement what's listed here</critical>
|
||||
<critical>If a capability is missing from FRs, it will NOT exist in the final product</critical>
|
||||
|
||||
<action>Before writing FRs, understand their PURPOSE and USAGE:
|
||||
|
||||
**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.
|
||||
|
||||
**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
|
||||
4. Dev Agent reads assembled context → implements stories based on FRs
|
||||
|
||||
**Critical Property - COMPLETENESS:**
|
||||
Every capability discussed in vision, scope, domain requirements, and project-specific
|
||||
sections MUST be represented as an FR. Missing FRs = missing capabilities.
|
||||
|
||||
**Critical Property - ALTITUDE:**
|
||||
FRs state WHAT capability exists and WHO it serves, NOT HOW it's implemented or
|
||||
specific UI/UX details. Those come later from UX and Architecture.
|
||||
</action>
|
||||
|
||||
<action>Transform everything discovered into comprehensive functional requirements:
|
||||
|
||||
**Coverage - Pull from EVERYWHERE:**
|
||||
|
||||
- Core features from MVP scope → FRs
|
||||
- Growth features → FRs (marked as post-MVP if needed)
|
||||
- Domain-mandated features → FRs
|
||||
- Project-type specific needs → FRs
|
||||
- Innovation requirements → FRs
|
||||
- Anti-patterns (explicitly NOT doing) → Note in FR section if needed
|
||||
|
||||
**Organization - Group by CAPABILITY AREA:**
|
||||
Don't organize by technology or layer. Group by what users/system can DO:
|
||||
|
||||
- ✅ "User Management" (not "Authentication System")
|
||||
- ✅ "Content Discovery" (not "Search Algorithm")
|
||||
- ✅ "Team Collaboration" (not "WebSocket Infrastructure")
|
||||
|
||||
**Format - Flat, Numbered List:**
|
||||
Each FR is one clear capability statement:
|
||||
|
||||
- FR#: [Actor] can [capability] [context/constraint if needed]
|
||||
- Number sequentially (FR1, FR2, FR3...)
|
||||
- Aim for 20-50 FRs for typical projects (fewer for simple, more for complex)
|
||||
|
||||
**Altitude Check:**
|
||||
Each FR should answer "WHAT capability exists?" NOT "HOW is it implemented?"
|
||||
|
||||
- ✅ "Users can customize appearance settings"
|
||||
- ❌ "Users can toggle light/dark theme with 3 font size options stored in LocalStorage"
|
||||
|
||||
The second example belongs in Epic Breakdown, not PRD.
|
||||
</action>
|
||||
|
||||
<example>
|
||||
**Well-written FRs at the correct altitude:**
|
||||
|
||||
**User Account & Access:**
|
||||
|
||||
- FR1: Users can create accounts with email or social authentication
|
||||
- FR2: Users can log in securely and maintain sessions across devices
|
||||
- FR3: Users can reset passwords via email verification
|
||||
- FR4: Users can update profile information and preferences
|
||||
- FR5: Administrators can manage user roles and permissions
|
||||
|
||||
**Content Management:**
|
||||
|
||||
- FR6: Users can create, edit, and delete content items
|
||||
- FR7: Users can organize content with tags and categories
|
||||
- FR8: Users can search content by keyword, tag, or date range
|
||||
- FR9: Users can export content in multiple formats
|
||||
|
||||
**Data Ownership (local-first products):**
|
||||
|
||||
- FR10: All user data stored locally on user's device
|
||||
- FR11: Users can export complete data at any time
|
||||
- FR12: Users can import previously exported data
|
||||
- FR13: System monitors storage usage and warns before limits
|
||||
|
||||
**Collaboration:**
|
||||
|
||||
- FR14: Users can share content with specific users or teams
|
||||
- FR15: Users can comment on shared content
|
||||
- FR16: Users can track content change history
|
||||
- FR17: Users receive notifications for relevant updates
|
||||
|
||||
**Notice:**
|
||||
✅ 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
|
||||
</example>
|
||||
|
||||
<action>Generate the complete FR list by systematically extracting capabilities:
|
||||
|
||||
1. MVP scope → extract all capabilities → write as FRs
|
||||
2. Growth features → extract capabilities → write as FRs (note if post-MVP)
|
||||
3. Domain requirements → extract mandatory capabilities → write as FRs
|
||||
4. Project-type specifics → extract type-specific capabilities → write as FRs
|
||||
5. Innovation patterns → extract novel capabilities → write as FRs
|
||||
|
||||
Organize FRs by logical capability groups (5-8 groups typically).
|
||||
Number sequentially across all groups (FR1, FR2... FR47).
|
||||
</action>
|
||||
|
||||
<action>SELF-VALIDATION - Before finalizing, ask yourself:
|
||||
|
||||
**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 (API/Mobile/SaaS/etc)?"
|
||||
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)
|
||||
|
||||
COMPLETENESS GATE: Review your FR list against the entire PRD written so far and think hard - did you miss anything? Add it now before proceeding.
|
||||
</action>
|
||||
|
||||
<template-output>functional_requirements_complete</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Non-Functional Requirements Discovery">
|
||||
<action>Only document NFRs that matter for THIS product
|
||||
|
||||
Performance: Only if user-facing impact
|
||||
Security: Only if handling sensitive data
|
||||
Scale: Only if growth expected
|
||||
Accessibility: Only if broad audience
|
||||
Integration: Only if connecting systems
|
||||
|
||||
For each NFR:
|
||||
|
||||
- Why it matters for THIS product
|
||||
- Specific measurable criteria
|
||||
- Domain-driven requirements
|
||||
|
||||
Skip categories that don't apply!</action>
|
||||
|
||||
<!-- Only output sections that were discussed -->
|
||||
<check if="performance matters">
|
||||
<template-output>performance_requirements</template-output>
|
||||
</check>
|
||||
<check if="security matters">
|
||||
<template-output>security_requirements</template-output>
|
||||
</check>
|
||||
<check if="scale matters">
|
||||
<template-output>scalability_requirements</template-output>
|
||||
</check>
|
||||
<check if="accessibility matters">
|
||||
<template-output>accessibility_requirements</template-output>
|
||||
</check>
|
||||
<check if="integration matters">
|
||||
<template-output>integration_requirements</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Complete PRD and determine next steps">
|
||||
<action>Quick review of captured requirements:
|
||||
|
||||
"We've captured:
|
||||
|
||||
- {{fr_count}} functional requirements
|
||||
- {{nfr_count}} non-functional requirements
|
||||
- MVP scope defined
|
||||
{{if domain_complexity == 'high'}}
|
||||
- Domain-specific requirements addressed
|
||||
{{/if}}
|
||||
{{if innovation_detected}}
|
||||
- Innovation patterns documented
|
||||
{{/if}}
|
||||
|
||||
Your PRD is complete!"
|
||||
</action>
|
||||
|
||||
<template-output>prd_summary</template-output>
|
||||
<template-output>product_value_summary</template-output>
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {status_file}</action>
|
||||
<action>Update workflow_status["prd"] = "{default_output_file}"</action>
|
||||
<action>Save file, preserving ALL comments and structure</action>
|
||||
|
||||
<action>Check workflow path to determine next expected workflows:
|
||||
|
||||
- Look for "create-epics-and-stories" as optional after PRD
|
||||
- Look for "create-design" as conditional (if_has_ui)
|
||||
- Look for "create-epics-and-stories-after-ux" as optional
|
||||
- Identify the required next phase workflow
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ PRD Complete, {user_name}!**
|
||||
|
||||
**Created:** PRD.md with {{fr_count}} FRs and NFRs
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
Based on your {{project_track}} workflow path, you can:
|
||||
|
||||
**Option A: Create Epic Breakdown Now** (Optional)
|
||||
`workflow create-epics-and-stories`
|
||||
|
||||
- Creates basic epic structure from PRD
|
||||
- Can be enhanced later with UX/Architecture context
|
||||
|
||||
<check if="UI_exists">
|
||||
**Option B: UX Design First** (Recommended if UI)
|
||||
`workflow create-design`
|
||||
- Design user experience and interactions
|
||||
- Epic breakdown can incorporate UX details later
|
||||
</check>
|
||||
|
||||
**Option C: Skip to Architecture**
|
||||
`workflow create-architecture`
|
||||
|
||||
- Define technical decisions
|
||||
- Epic breakdown created after with full context
|
||||
|
||||
**Recommendation:** {{if UI_exists}}Do UX Design first, then Architecture, then create epics with full context{{else}}Go straight to Architecture, then create epics{{/if}}
|
||||
</check>
|
||||
|
||||
<check if="standalone_mode == true">
|
||||
**Typical next workflows:**
|
||||
1. `workflow create-design` - UX Design (if UI exists)
|
||||
2. `workflow create-architecture` - Technical architecture
|
||||
3. `workflow create-epics-and-stories` - Epic breakdown
|
||||
|
||||
**Note:** Epics can be created at any point but have richer detail when created after UX/Architecture.
|
||||
</check>
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,204 @@
|
||||
# {{project_name}} - Product Requirements Document
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**Version:** 1.0
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{vision_alignment}}
|
||||
|
||||
### What Makes This Special
|
||||
|
||||
{{product_differentiator}}
|
||||
|
||||
---
|
||||
|
||||
## Project Classification
|
||||
|
||||
**Technical Type:** {{project_type}}
|
||||
**Domain:** {{domain_type}}
|
||||
**Complexity:** {{complexity_level}}
|
||||
|
||||
{{project_classification}}
|
||||
|
||||
{{#if domain_context_summary}}
|
||||
|
||||
### Domain Context
|
||||
|
||||
{{domain_context_summary}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
|
||||
{{success_criteria}}
|
||||
|
||||
{{#if business_metrics}}
|
||||
|
||||
### Business Metrics
|
||||
|
||||
{{business_metrics}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Product Scope
|
||||
|
||||
### MVP - Minimum Viable Product
|
||||
|
||||
{{mvp_scope}}
|
||||
|
||||
### Growth Features (Post-MVP)
|
||||
|
||||
{{growth_features}}
|
||||
|
||||
### Vision (Future)
|
||||
|
||||
{{vision_features}}
|
||||
|
||||
---
|
||||
|
||||
{{#if domain_considerations}}
|
||||
|
||||
## Domain-Specific Requirements
|
||||
|
||||
{{domain_considerations}}
|
||||
|
||||
This section shapes all functional and non-functional requirements below.
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
{{#if innovation_patterns}}
|
||||
|
||||
## Innovation & Novel Patterns
|
||||
|
||||
{{innovation_patterns}}
|
||||
|
||||
### Validation Approach
|
||||
|
||||
{{validation_approach}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
{{#if project_type_requirements}}
|
||||
|
||||
## {{project_type}} Specific Requirements
|
||||
|
||||
{{project_type_requirements}}
|
||||
|
||||
{{#if endpoint_specification}}
|
||||
|
||||
### API Specification
|
||||
|
||||
{{endpoint_specification}}
|
||||
{{/if}}
|
||||
|
||||
{{#if authentication_model}}
|
||||
|
||||
### Authentication & Authorization
|
||||
|
||||
{{authentication_model}}
|
||||
{{/if}}
|
||||
|
||||
{{#if platform_requirements}}
|
||||
|
||||
### Platform Support
|
||||
|
||||
{{platform_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if device_features}}
|
||||
|
||||
### Device Capabilities
|
||||
|
||||
{{device_features}}
|
||||
{{/if}}
|
||||
|
||||
{{#if tenant_model}}
|
||||
|
||||
### Multi-Tenancy Architecture
|
||||
|
||||
{{tenant_model}}
|
||||
{{/if}}
|
||||
|
||||
{{#if permission_matrix}}
|
||||
|
||||
### Permissions & Roles
|
||||
|
||||
{{permission_matrix}}
|
||||
{{/if}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
{{#if ux_principles}}
|
||||
|
||||
## User Experience Principles
|
||||
|
||||
{{ux_principles}}
|
||||
|
||||
### Key Interactions
|
||||
|
||||
{{key_interactions}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
{{functional_requirements_complete}}
|
||||
|
||||
---
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
{{#if performance_requirements}}
|
||||
|
||||
### Performance
|
||||
|
||||
{{performance_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if security_requirements}}
|
||||
|
||||
### Security
|
||||
|
||||
{{security_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if scalability_requirements}}
|
||||
|
||||
### Scalability
|
||||
|
||||
{{scalability_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if accessibility_requirements}}
|
||||
|
||||
### Accessibility
|
||||
|
||||
{{accessibility_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if integration_requirements}}
|
||||
|
||||
### Integration
|
||||
|
||||
{{integration_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if no_nfrs}}
|
||||
_No specific non-functional requirements identified for this project type._
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
_This PRD captures the essence of {{project_name}} - {{product_value_summary}}_
|
||||
|
||||
_Created through collaborative discovery between {{user_name}} and AI facilitator._
|
||||
@@ -0,0 +1,11 @@
|
||||
project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
|
||||
api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
|
||||
mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
|
||||
saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
|
||||
developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
|
||||
cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
|
||||
web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
|
||||
game,"game,player,gameplay,level,character","REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
|
||||
desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
|
||||
iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
|
||||
blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
|
||||
|
@@ -0,0 +1,52 @@
|
||||
# Product Requirements Document (PRD) Workflow
|
||||
name: prd
|
||||
description: "Unified PRD workflow for BMad Method and Enterprise Method tracks. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Quick Flow track uses tech-spec workflow."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/.bmad/bmm/config.yaml"
|
||||
project_name: "{config_source}:project_name"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/.bmad/bmm/workflows/2-plan-workflows/prd"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
|
||||
# Templates
|
||||
prd_template: "{installed_path}/prd-template.md"
|
||||
|
||||
# Data files for data-driven behavior
|
||||
project_types_data: "{installed_path}/project-types.csv"
|
||||
domain_complexity_data: "{installed_path}/domain-complexity.csv"
|
||||
|
||||
# Output files
|
||||
status_file: "{output_folder}/bmm-workflow-status.yaml"
|
||||
default_output_file: "{output_folder}/prd.md"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
|
||||
input_file_patterns:
|
||||
product_brief:
|
||||
description: "Product vision and goals (optional)"
|
||||
whole: "{output_folder}/*brief*.md"
|
||||
sharded: "{output_folder}/*brief*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
research:
|
||||
description: "Market or domain research (optional)"
|
||||
whole: "{output_folder}/*research*.md"
|
||||
sharded: "{output_folder}/*research*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
document_project:
|
||||
description: "Brownfield project documentation (optional)"
|
||||
sharded: "{output_folder}/index.md"
|
||||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
standalone: true
|
||||
@@ -0,0 +1,217 @@
|
||||
# Tech-Spec Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate tech-spec workflow outputs are context-rich, definitive, complete, and implementation-ready.
|
||||
|
||||
**Scope**: Quick-flow software projects (1-5 stories)
|
||||
|
||||
**Expected Outputs**: tech-spec.md + epics.md + story files (1-5 stories)
|
||||
|
||||
**New Standard**: Tech-spec should be comprehensive enough to replace story-context for most quick-flow projects
|
||||
|
||||
---
|
||||
|
||||
## 1. Output Files Exist
|
||||
|
||||
- [ ] tech-spec.md created in output folder
|
||||
- [ ] epics.md created (minimal for 1 story, detailed for multiple)
|
||||
- [ ] Story file(s) created in sprint_artifacts
|
||||
- Naming convention: story-{epic-slug}-N.md (where N = 1 to story_count)
|
||||
- 1 story: story-{epic-slug}-1.md
|
||||
- Multiple stories: story-{epic-slug}-1.md through story-{epic-slug}-N.md
|
||||
- [ ] bmm-workflow-status.yaml updated (if not standalone mode)
|
||||
- [ ] No unfilled {{template_variables}} in any files
|
||||
|
||||
---
|
||||
|
||||
## 2. Context Gathering (NEW - CRITICAL)
|
||||
|
||||
### Document Discovery
|
||||
|
||||
- [ ] **Existing documents loaded**: Product brief, research docs found and incorporated (if they exist)
|
||||
- [ ] **Document-project output**: Checked for {output_folder}/index.md (brownfield codebase map)
|
||||
- [ ] **Sharded documents**: If sharded versions found, ALL sections loaded and synthesized
|
||||
- [ ] **Context summary**: loaded_documents_summary lists all sources used
|
||||
|
||||
### Project Stack Detection
|
||||
|
||||
- [ ] **Setup files identified**: package.json, requirements.txt, or equivalent found and parsed
|
||||
- [ ] **Framework detected**: Exact framework name and version captured (e.g., "Express 4.18.2")
|
||||
- [ ] **Dependencies extracted**: All production dependencies with specific versions
|
||||
- [ ] **Dev tools identified**: TypeScript, Jest, ESLint, pytest, etc. with versions
|
||||
- [ ] **Scripts documented**: Available npm/pip/etc scripts identified
|
||||
- [ ] **Stack summary**: project_stack_summary is complete and accurate
|
||||
|
||||
### Brownfield Analysis (if applicable)
|
||||
|
||||
- [ ] **Directory structure**: Main code directories identified and documented
|
||||
- [ ] **Code patterns**: Dominant patterns identified (class-based, functional, MVC, etc.)
|
||||
- [ ] **Naming conventions**: Existing conventions documented (camelCase, snake_case, etc.)
|
||||
- [ ] **Key modules**: Important existing modules/services identified
|
||||
- [ ] **Testing patterns**: Test framework and patterns documented
|
||||
- [ ] **Structure summary**: existing_structure_summary is comprehensive
|
||||
|
||||
---
|
||||
|
||||
## 3. Tech-Spec Definitiveness (CRITICAL)
|
||||
|
||||
### No Ambiguity Allowed
|
||||
|
||||
- [ ] **Zero "or" statements**: NO "use X or Y", "either A or B", "options include"
|
||||
- [ ] **Specific versions**: All frameworks, libraries, tools have EXACT versions
|
||||
- ✅ GOOD: "Python 3.11", "React 18.2.0", "winston v3.8.2 (from package.json)"
|
||||
- ❌ BAD: "Python 2 or 3", "React 18+", "a logger like pino or winston"
|
||||
- [ ] **Definitive decisions**: Every technical choice is final, not a proposal
|
||||
- [ ] **Stack-aligned**: Decisions reference detected project stack
|
||||
|
||||
### Implementation Clarity
|
||||
|
||||
- [ ] **Source tree changes**: EXACT file paths with CREATE/MODIFY/DELETE actions
|
||||
- ✅ GOOD: "src/services/UserService.ts - MODIFY - Add validateEmail() method"
|
||||
- ❌ BAD: "Update some files in the services folder"
|
||||
- [ ] **Technical approach**: Describes SPECIFIC implementation using detected stack
|
||||
- [ ] **Existing patterns**: Documents brownfield patterns to follow (if applicable)
|
||||
- [ ] **Integration points**: Specific modules, APIs, services identified
|
||||
|
||||
---
|
||||
|
||||
## 4. Context-Rich Content (NEW)
|
||||
|
||||
### Context Section
|
||||
|
||||
- [ ] **Available Documents**: Lists all loaded documents
|
||||
- [ ] **Project Stack**: Complete framework and dependency information
|
||||
- [ ] **Existing Codebase Structure**: Brownfield analysis or greenfield notation
|
||||
|
||||
### The Change Section
|
||||
|
||||
- [ ] **Problem Statement**: Clear, specific problem definition
|
||||
- [ ] **Proposed Solution**: Concrete solution approach
|
||||
- [ ] **Scope In/Out**: Clear boundaries defined
|
||||
|
||||
### Development Context Section
|
||||
|
||||
- [ ] **Relevant Existing Code**: References to specific files and line numbers (brownfield)
|
||||
- [ ] **Framework Dependencies**: Complete list with exact versions from project
|
||||
- [ ] **Internal Dependencies**: Internal modules listed
|
||||
- [ ] **Configuration Changes**: Specific config file updates identified
|
||||
|
||||
### Developer Resources Section
|
||||
|
||||
- [ ] **File Paths Reference**: Complete list of all files involved
|
||||
- [ ] **Key Code Locations**: Functions, classes, modules with file:line references
|
||||
- [ ] **Testing Locations**: Specific test directories and patterns
|
||||
- [ ] **Documentation Updates**: Docs that need updating identified
|
||||
|
||||
---
|
||||
|
||||
## 5. Story Quality
|
||||
|
||||
### Story Format
|
||||
|
||||
- [ ] All stories use "As a [role], I want [capability], so that [benefit]" format
|
||||
- [ ] Each story has numbered acceptance criteria
|
||||
- [ ] Tasks reference AC numbers: (AC: #1), (AC: #2)
|
||||
- [ ] Dev Notes section links to tech-spec.md
|
||||
|
||||
### Story Context Integration (NEW)
|
||||
|
||||
- [ ] **Tech-Spec Reference**: Story explicitly references tech-spec.md as primary context
|
||||
- [ ] **Dev Agent Record**: Includes all required sections (Context Reference, Agent Model, etc.)
|
||||
- [ ] **Test Results section**: Placeholder ready for dev execution
|
||||
- [ ] **Review Notes section**: Placeholder ready for code review
|
||||
|
||||
### Story Sequencing (If Level 1)
|
||||
|
||||
- [ ] **Vertical slices**: Each story delivers complete, testable functionality
|
||||
- [ ] **Sequential ordering**: Stories in logical progression
|
||||
- [ ] **No forward dependencies**: No story depends on later work
|
||||
- [ ] Each story leaves system in working state
|
||||
|
||||
### Coverage
|
||||
|
||||
- [ ] Story acceptance criteria derived from tech-spec
|
||||
- [ ] Story tasks map to tech-spec implementation guide
|
||||
- [ ] Files in stories match tech-spec source tree
|
||||
- [ ] Key code references align with tech-spec Developer Resources
|
||||
|
||||
---
|
||||
|
||||
## 6. Epic Quality (All Projects)
|
||||
|
||||
- [ ] **Epic title**: User-focused outcome (not implementation detail)
|
||||
- [ ] **Epic slug**: Clean kebab-case slug (2-3 words)
|
||||
- [ ] **Epic goal**: Clear purpose and value statement
|
||||
- [ ] **Epic scope**: Boundaries clearly defined
|
||||
- [ ] **Success criteria**: Measurable outcomes
|
||||
- [ ] **Story map** (if multiple stories): Visual representation of epic → stories
|
||||
- [ ] **Implementation sequence** (if multiple stories): Logical story ordering with dependencies
|
||||
- [ ] **Tech-spec reference**: Links back to tech-spec.md
|
||||
- [ ] **Detail level appropriate**: Minimal for 1 story, detailed for multiple
|
||||
|
||||
---
|
||||
|
||||
## 7. Workflow Status Integration
|
||||
|
||||
- [ ] bmm-workflow-status.yaml updated (if exists)
|
||||
- [ ] Current phase reflects tech-spec completion
|
||||
- [ ] Progress percentage updated appropriately
|
||||
- [ ] Next workflow clearly identified
|
||||
|
||||
---
|
||||
|
||||
## 8. Implementation Readiness (NEW - ENHANCED)
|
||||
|
||||
### Can Developer Start Immediately?
|
||||
|
||||
- [ ] **All context available**: Brownfield analysis + stack details + existing patterns
|
||||
- [ ] **No research needed**: Developer doesn't need to hunt for framework versions or patterns
|
||||
- [ ] **Specific file paths**: Developer knows exactly which files to create/modify
|
||||
- [ ] **Code references**: Can find similar code to reference (brownfield)
|
||||
- [ ] **Testing clear**: Knows what to test and how
|
||||
- [ ] **Deployment documented**: Knows how to deploy and rollback
|
||||
|
||||
### Tech-Spec Replaces Story-Context?
|
||||
|
||||
- [ ] **Comprehensive enough**: Contains all info typically in story-context XML
|
||||
- [ ] **Brownfield analysis**: If applicable, includes codebase reconnaissance
|
||||
- [ ] **Framework specifics**: Exact versions and usage patterns
|
||||
- [ ] **Pattern guidance**: Shows examples of existing patterns to follow
|
||||
|
||||
---
|
||||
|
||||
## 9. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **Non-definitive technical decisions** (any "option A or B" or vague choices)
|
||||
- [ ] ❌ **Missing versions** (framework/library without specific version)
|
||||
- [ ] ❌ **Context not gathered** (didn't check for document-project, setup files, etc.)
|
||||
- [ ] ❌ **Stack mismatch** (decisions don't align with detected project stack)
|
||||
- [ ] ❌ **Stories don't match template** (missing Dev Agent Record sections)
|
||||
- [ ] ❌ **Missing tech-spec sections** (required section missing from enhanced template)
|
||||
- [ ] ❌ **Stories have forward dependencies** (would break sequential implementation)
|
||||
- [ ] ❌ **Vague source tree** (file changes not specific with actions)
|
||||
- [ ] ❌ **No brownfield analysis** (when document-project output exists but wasn't used)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document any findings:**
|
||||
|
||||
- **Context Gathering Score**: [Comprehensive / Partial / Insufficient]
|
||||
- **Definitiveness Score**: [All definitive / Some ambiguity / Significant ambiguity]
|
||||
- **Brownfield Integration**: [N/A - Greenfield / Excellent / Partial / Missing]
|
||||
- **Stack Alignment**: [Perfect / Good / Partial / None]
|
||||
|
||||
## **Strengths:**
|
||||
|
||||
## **Issues to address:**
|
||||
|
||||
## **Recommended actions:**
|
||||
|
||||
**Ready for implementation?** [Yes / No - explain]
|
||||
|
||||
**Can skip story-context?** [Yes - tech-spec is comprehensive / No - additional context needed / N/A]
|
||||
|
||||
---
|
||||
|
||||
_The tech-spec should be a RICH CONTEXT DOCUMENT that gives developers everything they need without requiring separate context generation._
|
||||
@@ -0,0 +1,74 @@
|
||||
# {{project_name}} - Epic Breakdown
|
||||
|
||||
**Date:** {{date}}
|
||||
**Project Level:** {{project_level}}
|
||||
|
||||
---
|
||||
|
||||
<!-- Repeat for each epic (N = 1, 2, 3...) -->
|
||||
|
||||
## Epic {{N}}: {{epic_title_N}}
|
||||
|
||||
**Slug:** {{epic_slug_N}}
|
||||
|
||||
### Goal
|
||||
|
||||
{{epic_goal_N}}
|
||||
|
||||
### Scope
|
||||
|
||||
{{epic_scope_N}}
|
||||
|
||||
### Success Criteria
|
||||
|
||||
{{epic_success_criteria_N}}
|
||||
|
||||
### Dependencies
|
||||
|
||||
{{epic_dependencies_N}}
|
||||
|
||||
---
|
||||
|
||||
## Story Map - Epic {{N}}
|
||||
|
||||
{{story_map_N}}
|
||||
|
||||
---
|
||||
|
||||
## Stories - Epic {{N}}
|
||||
|
||||
<!-- Repeat for each story (M = 1, 2, 3...) within epic N -->
|
||||
|
||||
### Story {{N}}.{{M}}: {{story_title_N_M}}
|
||||
|
||||
As a {{user_type}},
|
||||
I want {{capability}},
|
||||
So that {{value_benefit}}.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
**Given** {{precondition}}
|
||||
**When** {{action}}
|
||||
**Then** {{expected_outcome}}
|
||||
|
||||
**And** {{additional_criteria}}
|
||||
|
||||
**Prerequisites:** {{dependencies_on_previous_stories}}
|
||||
|
||||
**Technical Notes:** {{implementation_guidance}}
|
||||
|
||||
**Estimated Effort:** {{story_points}} points ({{time_estimate}})
|
||||
|
||||
<!-- End story repeat -->
|
||||
|
||||
---
|
||||
|
||||
## Implementation Timeline - Epic {{N}}
|
||||
|
||||
**Total Story Points:** {{total_points_N}}
|
||||
|
||||
**Estimated Timeline:** {{estimated_timeline_N}}
|
||||
|
||||
---
|
||||
|
||||
<!-- End epic repeat -->
|
||||
@@ -0,0 +1,436 @@
|
||||
# Unified Epic and Story Generation
|
||||
|
||||
<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>
|
||||
|
||||
<critical>This generates epic + stories for ALL quick-flow projects</critical>
|
||||
<critical>Always generates: epics.md + story files (1-5 stories based on {{story_count}})</critical>
|
||||
<critical>Runs AFTER tech-spec.md completion</critical>
|
||||
<critical>Story format MUST match create-story template for compatibility with story-context and dev-story workflows</critical>
|
||||
|
||||
<step n="1" goal="Load tech spec and extract implementation context">
|
||||
|
||||
<action>Read the completed tech-spec.md file from {default_output_file}</action>
|
||||
<action>Load bmm-workflow-status.yaml from {workflow-status} (if exists)</action>
|
||||
<action>Get story_count from workflow variables (1-5)</action>
|
||||
<action>Ensure {sprint_artifacts} directory exists</action>
|
||||
|
||||
<action>Extract from tech-spec structure:
|
||||
|
||||
**From "The Change" section:**
|
||||
|
||||
- Problem statement and solution overview
|
||||
- Scope (in/out)
|
||||
|
||||
**From "Implementation Details" section:**
|
||||
|
||||
- Source tree changes
|
||||
- Technical approach
|
||||
- Integration points
|
||||
|
||||
**From "Implementation Guide" section:**
|
||||
|
||||
- Implementation steps
|
||||
- Testing strategy
|
||||
- Acceptance criteria
|
||||
- Time estimates
|
||||
|
||||
**From "Development Context" section:**
|
||||
|
||||
- Framework dependencies with versions
|
||||
- Existing code references
|
||||
- Internal dependencies
|
||||
|
||||
**From "Developer Resources" section:**
|
||||
|
||||
- File paths
|
||||
- Key code locations
|
||||
- Testing locations
|
||||
|
||||
Use this rich context to generate comprehensive, implementation-ready epic and stories.
|
||||
</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Generate epic slug and structure">
|
||||
|
||||
<action>Create epic based on the overall feature/change from tech-spec</action>
|
||||
|
||||
<action>Derive epic slug from the feature name:
|
||||
|
||||
- Use 2-3 words max
|
||||
- Kebab-case format
|
||||
- User-focused, not implementation-focused
|
||||
|
||||
Examples:
|
||||
|
||||
- "OAuth Integration" → "oauth-integration"
|
||||
- "Fix Login Bug" → "login-fix"
|
||||
- "User Profile Page" → "user-profile"
|
||||
</action>
|
||||
|
||||
<action>Store as {{epic_slug}} - this will be used for all story filenames</action>
|
||||
|
||||
<action>Adapt epic detail to story count:
|
||||
|
||||
**For single story (story_count == 1):**
|
||||
|
||||
- Epic is minimal - just enough structure
|
||||
- Goal: Brief statement of what's being accomplished
|
||||
- Scope: High-level boundary
|
||||
- Success criteria: Core outcomes
|
||||
|
||||
**For multiple stories (story_count > 1):**
|
||||
|
||||
- Epic is detailed - full breakdown
|
||||
- Goal: Comprehensive purpose and value statement
|
||||
- Scope: Clear boundaries with in/out examples
|
||||
- Success criteria: Measurable, testable outcomes
|
||||
- Story map: Visual representation of epic → stories
|
||||
- Implementation sequence: Logical ordering with dependencies
|
||||
</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Generate epic document">
|
||||
|
||||
<action>Initialize {epics_file} using {epics_template}</action>
|
||||
|
||||
<action>Populate epic metadata from tech-spec context:
|
||||
|
||||
**Epic Title:** User-facing outcome (not implementation detail)
|
||||
|
||||
- Good: "OAuth Integration", "Login Bug Fix", "Icon Reliability"
|
||||
- Bad: "Update recommendedLibraries.ts", "Refactor auth service"
|
||||
|
||||
**Epic Goal:** Why this matters to users/business
|
||||
|
||||
**Epic Scope:** Clear boundaries from tech-spec scope section
|
||||
|
||||
**Epic Success Criteria:** Measurable outcomes from tech-spec acceptance criteria
|
||||
|
||||
**Dependencies:** From tech-spec integration points and dependencies
|
||||
</action>
|
||||
|
||||
<template-output file="{epics_file}">project_name</template-output>
|
||||
<template-output file="{epics_file}">date</template-output>
|
||||
<template-output file="{epics_file}">epic_title</template-output>
|
||||
<template-output file="{epics_file}">epic_slug</template-output>
|
||||
<template-output file="{epics_file}">epic_goal</template-output>
|
||||
<template-output file="{epics_file}">epic_scope</template-output>
|
||||
<template-output file="{epics_file}">epic_success_criteria</template-output>
|
||||
<template-output file="{epics_file}">epic_dependencies</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Intelligently break down into stories">
|
||||
|
||||
<action>Analyze tech-spec implementation steps and create story breakdown
|
||||
|
||||
**For story_count == 1:**
|
||||
|
||||
- Create single comprehensive story covering all implementation
|
||||
- Title: Focused on the deliverable outcome
|
||||
- Tasks: Map directly to tech-spec implementation steps
|
||||
- Estimated points: Typically 1-5 points
|
||||
|
||||
**For story_count > 1:**
|
||||
|
||||
- Break implementation into logical story boundaries
|
||||
- Each story must be:
|
||||
- Independently valuable (delivers working functionality)
|
||||
- Testable (has clear acceptance criteria)
|
||||
- Sequentially ordered (no forward dependencies)
|
||||
- Right-sized (prefer 2-4 stories over many tiny ones)
|
||||
|
||||
**Story Sequencing Rules (CRITICAL):**
|
||||
|
||||
1. Foundation → Build → Test → Polish
|
||||
2. Database → API → UI
|
||||
3. Backend → Frontend
|
||||
4. Core → Enhancement
|
||||
5. NO story can depend on a later story!
|
||||
|
||||
Validate sequence: Each story N should only depend on stories 1...N-1
|
||||
</action>
|
||||
|
||||
<action>For each story position (1 to {{story_count}}):
|
||||
|
||||
1. **Determine story scope from tech-spec tasks**
|
||||
- Group related implementation steps
|
||||
- Ensure story leaves system in working state
|
||||
|
||||
2. **Create story title**
|
||||
- User-focused deliverable
|
||||
- Active, clear language
|
||||
- Good: "OAuth Backend Integration", "OAuth UI Components"
|
||||
- Bad: "Write some OAuth code", "Update files"
|
||||
|
||||
3. **Extract acceptance criteria**
|
||||
- From tech-spec testing strategy and acceptance criteria
|
||||
- Must be numbered (AC #1, AC #2, etc.)
|
||||
- Must be specific and testable
|
||||
- Use Given/When/Then format when applicable
|
||||
|
||||
4. **Map tasks to implementation steps**
|
||||
- Break down tech-spec implementation steps for this story
|
||||
- Create checkbox list
|
||||
- Reference AC numbers: (AC: #1), (AC: #2)
|
||||
|
||||
5. **Estimate story points**
|
||||
- 1 point = < 1 day (2-4 hours)
|
||||
- 2 points = 1-2 days
|
||||
- 3 points = 2-3 days
|
||||
- 5 points = 3-5 days
|
||||
- Total across all stories should align with tech-spec estimates
|
||||
</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Generate story files">
|
||||
|
||||
<for-each story="1 to story_count">
|
||||
<action>Set story_filename = "story-{{epic_slug}}-{{n}}.md"</action>
|
||||
<action>Set story_path = "{sprint_artifacts}/{{story_filename}}"</action>
|
||||
|
||||
<action>Create story file using {user_story_template}</action>
|
||||
|
||||
<action>Populate story with:
|
||||
|
||||
**Story Header:**
|
||||
|
||||
- N.M format (where N is always 1 for quick-flow, M is story number)
|
||||
- Title: User-focused deliverable
|
||||
- Status: Draft
|
||||
|
||||
**User Story:**
|
||||
|
||||
- As a [role] (developer, user, admin, system, etc.)
|
||||
- I want [capability/change]
|
||||
- So that [benefit/value]
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
- Numbered list (AC #1, AC #2, ...)
|
||||
- Specific, measurable, testable
|
||||
- Derived from tech-spec testing strategy and acceptance criteria
|
||||
- Cover all success conditions for this story
|
||||
|
||||
**Tasks/Subtasks:**
|
||||
|
||||
- Checkbox list mapped to tech-spec implementation steps
|
||||
- Each task references AC numbers: (AC: #1)
|
||||
- Include explicit testing tasks
|
||||
|
||||
**Technical Summary:**
|
||||
|
||||
- High-level approach for this story
|
||||
- Key technical decisions
|
||||
- Files/modules involved
|
||||
|
||||
**Project Structure Notes:**
|
||||
|
||||
- files_to_modify: From tech-spec "Developer Resources → File Paths"
|
||||
- test_locations: From tech-spec "Developer Resources → Testing Locations"
|
||||
- story_points: Estimated effort
|
||||
- dependencies: Prerequisites (other stories, systems, data)
|
||||
|
||||
**Key Code References:**
|
||||
|
||||
- From tech-spec "Development Context → Relevant Existing Code"
|
||||
- From tech-spec "Developer Resources → Key Code Locations"
|
||||
- Specific file:line references when available
|
||||
|
||||
**Context References:**
|
||||
|
||||
- Link to tech-spec.md (primary context document)
|
||||
- Note: Tech-spec contains brownfield analysis, framework versions, patterns, etc.
|
||||
|
||||
**Dev Agent Record:**
|
||||
|
||||
- Empty sections (populated during dev-story execution)
|
||||
- Agent Model Used
|
||||
- Debug Log References
|
||||
- Completion Notes
|
||||
- Files Modified
|
||||
- Test Results
|
||||
|
||||
**Review Notes:**
|
||||
|
||||
- Empty section (populated during code review)
|
||||
</action>
|
||||
|
||||
<template-output file="{{story_path}}">story_number</template-output>
|
||||
<template-output file="{{story_path}}">story_title</template-output>
|
||||
<template-output file="{{story_path}}">user_role</template-output>
|
||||
<template-output file="{{story_path}}">capability</template-output>
|
||||
<template-output file="{{story_path}}">benefit</template-output>
|
||||
<template-output file="{{story_path}}">acceptance_criteria</template-output>
|
||||
<template-output file="{{story_path}}">tasks_subtasks</template-output>
|
||||
<template-output file="{{story_path}}">technical_summary</template-output>
|
||||
<template-output file="{{story_path}}">files_to_modify</template-output>
|
||||
<template-output file="{{story_path}}">test_locations</template-output>
|
||||
<template-output file="{{story_path}}">story_points</template-output>
|
||||
<template-output file="{{story_path}}">time_estimate</template-output>
|
||||
<template-output file="{{story_path}}">dependencies</template-output>
|
||||
<template-output file="{{story_path}}">existing_code_references</template-output>
|
||||
</for-each>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Generate story map and finalize epic" if="story_count > 1">
|
||||
|
||||
<action>Create visual story map showing epic → stories hierarchy
|
||||
|
||||
Include:
|
||||
|
||||
- Epic title at top
|
||||
- Stories listed with point estimates
|
||||
- Dependencies noted
|
||||
- Sequence validation confirmation
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
Epic: OAuth Integration (8 points)
|
||||
├── Story 1.1: OAuth Backend (3 points)
|
||||
│ Dependencies: None
|
||||
│
|
||||
├── Story 1.2: OAuth UI Components (3 points)
|
||||
│ Dependencies: Story 1.1
|
||||
│
|
||||
└── Story 1.3: OAuth Testing & Polish (2 points)
|
||||
Dependencies: Stories 1.1, 1.2
|
||||
```
|
||||
|
||||
</action>
|
||||
|
||||
<action>Calculate totals:
|
||||
|
||||
- Total story points across all stories
|
||||
- Estimated timeline (typically 1-2 points per day)
|
||||
</action>
|
||||
|
||||
<action>Append to {epics_file}:
|
||||
|
||||
- Story summaries
|
||||
- Story map visual
|
||||
- Implementation sequence
|
||||
- Total points and timeline
|
||||
</action>
|
||||
|
||||
<template-output file="{epics_file}">story_map</template-output>
|
||||
<template-output file="{epics_file}">story_summaries</template-output>
|
||||
<template-output file="{epics_file}">total_points</template-output>
|
||||
<template-output file="{epics_file}">estimated_timeline</template-output>
|
||||
<template-output file="{epics_file}">implementation_sequence</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Validate story quality">
|
||||
|
||||
<critical>Always run validation - NOT optional!</critical>
|
||||
|
||||
<action>Validate all stories against quality standards:
|
||||
|
||||
**Story Sequence Validation (CRITICAL):**
|
||||
|
||||
- For each story N, verify it doesn't depend on story N+1 or later
|
||||
- Check: Can stories be implemented in order 1→2→3→...?
|
||||
- If sequence invalid: Identify problem, propose reordering, ask user to confirm
|
||||
|
||||
**Acceptance Criteria Quality:**
|
||||
|
||||
- All AC are numbered (AC #1, AC #2, ...)
|
||||
- Each AC is specific and testable (no "works well", "is good", "performs fast")
|
||||
- AC use Given/When/Then or equivalent structure
|
||||
- All success conditions are covered
|
||||
|
||||
**Story Completeness:**
|
||||
|
||||
- All stories map to tech-spec implementation steps
|
||||
- Story points align with tech-spec time estimates
|
||||
- Dependencies are clearly documented
|
||||
- Each story has testable AC
|
||||
- Files and locations reference tech-spec developer resources
|
||||
|
||||
**Template Compliance:**
|
||||
|
||||
- All required sections present
|
||||
- Dev Agent Record sections exist (even if empty)
|
||||
- Context references link to tech-spec.md
|
||||
- Story numbering follows N.M format
|
||||
</action>
|
||||
|
||||
<check if="validation issues found">
|
||||
<output>⚠️ **Story Validation Issues:**
|
||||
|
||||
{{issues_list}}
|
||||
|
||||
**Recommended Fixes:**
|
||||
{{fixes}}
|
||||
|
||||
Shall I fix these automatically? (yes/no)</output>
|
||||
|
||||
<ask>Apply fixes? (yes/no)</ask>
|
||||
|
||||
<check if="yes">
|
||||
<action>Apply fixes (reorder stories, rewrite vague AC, add missing details)</action>
|
||||
<action>Re-validate</action>
|
||||
<output>✅ Validation passed after fixes!</output>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="validation passes">
|
||||
<output>✅ **Story Validation Passed!**
|
||||
|
||||
**Quality Scores:**
|
||||
|
||||
- Sequence: ✅ Valid (no forward dependencies)
|
||||
- AC Quality: ✅ All specific and testable
|
||||
- Completeness: ✅ All tech spec tasks covered
|
||||
- Template Compliance: ✅ All sections present
|
||||
|
||||
Stories are implementation-ready!</output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Update workflow status and finalize">
|
||||
|
||||
<action>Update bmm-workflow-status.yaml (if exists):
|
||||
|
||||
- Mark tech-spec as complete
|
||||
- Initialize story sequence tracking
|
||||
- Set first story as TODO
|
||||
- Track epic slug and story count
|
||||
</action>
|
||||
|
||||
<output>**✅ Epic and Stories Generated!**
|
||||
|
||||
**Epic:** {{epic_title}} ({{epic_slug}})
|
||||
**Total Stories:** {{story_count}}
|
||||
{{#if story_count > 1}}**Total Points:** {{total_points}}
|
||||
**Estimated Timeline:** {{estimated_timeline}}{{/if}}
|
||||
|
||||
**Files Created:**
|
||||
|
||||
- `{epics_file}` - Epic structure{{#if story_count == 1}} (minimal){{/if}}
|
||||
- `{sprint_artifacts}/story-{{epic_slug}}-1.md`{{#if story_count > 1}}
|
||||
- `{sprint_artifacts}/story-{{epic_slug}}-2.md`{{/if}}{{#if story_count > 2}}
|
||||
- Through story-{{epic_slug}}-{{story_count}}.md{{/if}}
|
||||
|
||||
**What's Next:**
|
||||
All stories reference tech-spec.md as primary context. You can proceed directly to development with the DEV agent!
|
||||
|
||||
Story files are ready for:
|
||||
|
||||
- Direct implementation (dev-story workflow)
|
||||
- Optional context generation (story-context workflow for complex cases)
|
||||
- Sprint planning organization (sprint-planning workflow for multi-story coordination)
|
||||
</output>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,980 @@
|
||||
# Tech-Spec Workflow - Context-Aware Technical Planning (quick-flow)
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/.bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>This is quick-flow efforts - tech-spec with context-rich story generation</critical>
|
||||
<critical>Quick Flow: tech-spec + epic with 1-5 stories (always generates epic structure)</critical>
|
||||
<critical>LIVING DOCUMENT: Write to tech-spec.md continuously as you discover - never wait until the end</critical>
|
||||
<critical>CONTEXT IS KING: Gather ALL available context before generating specs</critical>
|
||||
<critical>DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</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>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness and detect project level" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Tech-spec workflow 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>
|
||||
<output>**Quick Start:** Continue in standalone mode - perfect for rapid prototyping and quick changes!</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
|
||||
<output>Great! Let's quickly configure your project...</output>
|
||||
|
||||
<ask>How many user stories do you think this work requires?
|
||||
|
||||
**Single Story** - Simple change (bug fix, small isolated feature, single file change)
|
||||
→ Generates: tech-spec + epic (minimal) + 1 story
|
||||
→ Example: "Fix login validation bug" or "Add email field to user form"
|
||||
|
||||
**Multiple Stories (2-5)** - Coherent feature (multiple related changes, small feature set)
|
||||
→ Generates: tech-spec + epic (detailed) + 2-5 stories
|
||||
→ Example: "Add OAuth integration" or "Build user profile page"
|
||||
|
||||
Enter **1** for single story, or **2-5** for number of stories you estimate</ask>
|
||||
|
||||
<action>Capture user response as story_count (1-5)</action>
|
||||
<action>Validate: If not 1-5, ask for clarification. If > 5, suggest using full BMad Method instead</action>
|
||||
|
||||
<ask if="not already known greenfield vs brownfield">Is this a **greenfield** (new/empty codebase) or **brownfield** (existing codebase) project?
|
||||
|
||||
**Greenfield** - Starting fresh, no existing code aside from starter templates
|
||||
**Brownfield** - Adding to or modifying existing functional code or project
|
||||
|
||||
Enter **greenfield** or **brownfield**:</ask>
|
||||
|
||||
<action>Capture user response as field_type (greenfield or brownfield)</action>
|
||||
<action>Validate: If not greenfield or brownfield, ask again</action>
|
||||
|
||||
<output>Perfect! Running as:
|
||||
|
||||
- **Story Count:** {{story_count}} {{#if story_count == 1}}story (minimal epic){{else}}stories (detailed epic){{/if}}
|
||||
- **Field Type:** {{field_type}}
|
||||
- **Mode:** Standalone (no status file tracking)
|
||||
|
||||
Let's build your tech-spec!</output>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {workflow-status}</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "tech-spec" workflow</action>
|
||||
<action>Get selected_track from YAML metadata indicating this is quick-flow-greenfield or quick-flow-brownfield</action>
|
||||
<action>Get field_type from YAML metadata (greenfield or brownfield)</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="selected_track is NOT quick-flow-greenfield AND NOT quick-flow-brownfield">
|
||||
<output>**Incorrect Workflow for Level {{selected_track}}**
|
||||
Tech-spec is for Simple projects. **Correct workflow:** `create-prd` (PM agent). You should Exit at this point, unless you want to force run this workflow.
|
||||
</output>
|
||||
</check>
|
||||
|
||||
<check if="tech-spec status is file path (already completed)">
|
||||
<output>⚠️ Tech-spec already completed: {{tech-spec status}}</output>
|
||||
<ask>Re-running will overwrite the existing tech-spec. 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="tech-spec is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Tech-spec is out of sequence.</output>
|
||||
<ask>Continue with tech-spec 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>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Discover and load input documents">
|
||||
<invoke-protocol name="discover_inputs" />
|
||||
<note>After discovery, these content variables are available: {product_brief_content}, {research_content}, {document_project_content}</note>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Comprehensive context discovery - gather everything available">
|
||||
|
||||
<action>Welcome {user_name} warmly and explain what we're about to do:
|
||||
|
||||
"I'm going to gather all available context about your project before we dive into the technical spec. The following content has been auto-loaded:
|
||||
|
||||
- Product briefs and research: {product_brief_content}, {research_content}
|
||||
- Brownfield codebase documentation: {document_project_content} (loaded via INDEX_GUIDED strategy)
|
||||
- Your project's tech stack and dependencies
|
||||
- Existing code patterns and structure
|
||||
|
||||
This ensures the tech-spec is grounded in reality and gives developers everything they need."
|
||||
</action>
|
||||
|
||||
<action>**PHASE 1: Load Existing Documents**
|
||||
|
||||
Search for and load (using dual-strategy: whole first, then sharded):
|
||||
|
||||
1. **Product Brief:**
|
||||
- Search pattern: {output*folder}/\_brief*.md
|
||||
- Sharded: {output*folder}/\_brief*/index.md
|
||||
- If found: Load completely and extract key context
|
||||
|
||||
2. **Research Documents:**
|
||||
- Search pattern: {output*folder}/\_research*.md
|
||||
- Sharded: {output*folder}/\_research*/index.md
|
||||
- If found: Load completely and extract insights
|
||||
|
||||
3. **Document-Project Output (CRITICAL for brownfield):**
|
||||
- Always check: {output_folder}/index.md
|
||||
- If found: This is the brownfield codebase map - load ALL shards!
|
||||
- Extract: File structure, key modules, existing patterns, naming conventions
|
||||
|
||||
Create a summary of what was found and ask user if there are other documents or information to consider before proceeding:
|
||||
|
||||
- List of loaded documents
|
||||
- Key insights from each
|
||||
- Brownfield vs greenfield determination
|
||||
</action>
|
||||
|
||||
<action>**PHASE 2: Intelligently Detect Project Stack**
|
||||
|
||||
Use your comprehensive knowledge as a coding-capable LLM to analyze the project:
|
||||
|
||||
**Discover Setup Files:**
|
||||
|
||||
- Search {project-root} for dependency manifests (package.json, requirements.txt, Gemfile, go.mod, Cargo.toml, composer.json, pom.xml, build.gradle, pyproject.toml, etc.)
|
||||
- Adapt to ANY project type - you know the ecosystem conventions
|
||||
|
||||
**Extract Critical Information:**
|
||||
|
||||
1. Framework name and EXACT version (e.g., "React 18.2.0", "Django 4.2.1")
|
||||
2. All production dependencies with specific versions
|
||||
3. Dev tools and testing frameworks (Jest, pytest, ESLint, etc.)
|
||||
4. Available build/test scripts
|
||||
5. Project type (web app, API, CLI, library, etc.)
|
||||
|
||||
**Assess Currency:**
|
||||
|
||||
- Identify if major dependencies are outdated (>2 years old)
|
||||
- Use WebSearch to find current recommended versions if needed
|
||||
- Note migration complexity in your summary
|
||||
|
||||
**For Greenfield Projects:**
|
||||
<check if="field_type == greenfield">
|
||||
<action>Use WebSearch to discover current best practices and official starter templates</action>
|
||||
<action>Recommend appropriate starters based on detected framework (or user's intended stack)</action>
|
||||
<action>Present benefits conversationally: setup time saved, modern patterns, testing included</action>
|
||||
<ask>Would you like to use a starter template? (yes/no/show-me-options)</ask>
|
||||
<action>Capture preference and include in implementation stack if accepted</action>
|
||||
</check>
|
||||
|
||||
**Trust Your Intelligence:**
|
||||
You understand project ecosystems deeply. Adapt your analysis to any stack - don't be constrained by examples. Extract what matters for developers.
|
||||
|
||||
Store comprehensive findings as {{project_stack_summary}}
|
||||
</action>
|
||||
|
||||
<action>**PHASE 3: Brownfield Codebase Reconnaissance** (if applicable)
|
||||
|
||||
<check if="field_type == brownfield OR document-project output found">
|
||||
|
||||
Analyze the existing project structure:
|
||||
|
||||
1. **Directory Structure:**
|
||||
- Identify main code directories (src/, lib/, app/, components/, services/)
|
||||
- Note organization patterns (feature-based, layer-based, domain-driven)
|
||||
- Identify test directories and patterns
|
||||
|
||||
2. **Code Patterns:**
|
||||
- Look for dominant patterns (class-based, functional, MVC, microservices)
|
||||
- Identify naming conventions (camelCase, snake_case, PascalCase)
|
||||
- Note file organization patterns
|
||||
|
||||
3. **Key Modules/Services:**
|
||||
- Identify major modules or services already in place
|
||||
- Note entry points (main.js, app.py, index.ts)
|
||||
- Document important utilities or shared code
|
||||
|
||||
4. **Testing Patterns & Standards (CRITICAL):**
|
||||
- Identify test framework in use (from package.json/requirements.txt)
|
||||
- Note test file naming patterns (.test.js, test.py, .spec.ts, Test.java)
|
||||
- Document test organization (tests/, **tests**, spec/, test/)
|
||||
- Look for test configuration files (jest.config.js, pytest.ini, .rspec)
|
||||
- Check for coverage requirements (in CI config, test scripts)
|
||||
- Identify mocking/stubbing libraries (jest.mock, unittest.mock, sinon)
|
||||
- Note assertion styles (expect, assert, should)
|
||||
|
||||
5. **Code Style & Conventions (MUST CONFORM):**
|
||||
- Check for linter config (.eslintrc, .pylintrc, rubocop.yml)
|
||||
- Check for formatter config (.prettierrc, .black, .editorconfig)
|
||||
- Identify code style:
|
||||
- Semicolons: yes/no (JavaScript/TypeScript)
|
||||
- Quotes: single/double
|
||||
- Indentation: spaces/tabs, size
|
||||
- Line length limits
|
||||
- Import/export patterns (named vs default, organization)
|
||||
- Error handling patterns (try/catch, Result types, error classes)
|
||||
- Logging patterns (console, winston, logging module, specific formats)
|
||||
- Documentation style (JSDoc, docstrings, YARD, JavaDoc)
|
||||
|
||||
Store this as {{existing_structure_summary}}
|
||||
|
||||
**CRITICAL: Confirm Conventions with User**
|
||||
<ask>I've detected these conventions in your codebase:
|
||||
|
||||
**Code Style:**
|
||||
{{detected_code_style}}
|
||||
|
||||
**Test Patterns:**
|
||||
{{detected_test_patterns}}
|
||||
|
||||
**File Organization:**
|
||||
{{detected_file_organization}}
|
||||
|
||||
Should I follow these existing conventions for the new code?
|
||||
|
||||
Enter **yes** to conform to existing patterns, or **no** if you want to establish new standards:</ask>
|
||||
|
||||
<action>Capture user response as conform_to_conventions (yes/no)</action>
|
||||
|
||||
<check if="conform_to_conventions == no">
|
||||
<ask>What conventions would you like to use instead? (Or should I suggest modern best practices?)</ask>
|
||||
<action>Capture new conventions or use WebSearch for current best practices</action>
|
||||
</check>
|
||||
|
||||
<action>Store confirmed conventions as {{existing_conventions}}</action>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="field_type == greenfield">
|
||||
<action>Note: Greenfield project - no existing code to analyze</action>
|
||||
<action>Set {{existing_structure_summary}} = "Greenfield project - new codebase"</action>
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
<action>**PHASE 4: Synthesize Context Summary**
|
||||
|
||||
Create {{loaded_documents_summary}} that includes:
|
||||
|
||||
- Documents found and loaded
|
||||
- Brownfield vs greenfield status
|
||||
- Tech stack detected (or "To be determined" if greenfield)
|
||||
- Existing patterns identified (or "None - greenfield" if applicable)
|
||||
|
||||
Present this summary to {user_name} conversationally:
|
||||
|
||||
"Here's what I found about your project:
|
||||
|
||||
**Documents Available:**
|
||||
[List what was found]
|
||||
|
||||
**Project Type:**
|
||||
[Brownfield with X framework Y version OR Greenfield - new project]
|
||||
|
||||
**Existing Stack:**
|
||||
[Framework and dependencies OR "To be determined"]
|
||||
|
||||
**Code Structure:**
|
||||
[Existing patterns OR "New codebase"]
|
||||
|
||||
This gives me a solid foundation for creating a context-rich tech spec!"
|
||||
</action>
|
||||
|
||||
<template-output>loaded_documents_summary</template-output>
|
||||
<template-output>project_stack_summary</template-output>
|
||||
<template-output>existing_structure_summary</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Conversational discovery of the change/feature">
|
||||
|
||||
<action>Engage {user_name} in natural, adaptive conversation to deeply understand what needs to be built.
|
||||
|
||||
**Discovery Approach:**
|
||||
Adapt your questioning style to the complexity:
|
||||
|
||||
- For single-story changes: Focus on the specific problem, location, and approach
|
||||
- For multi-story features: Explore user value, integration strategy, and scope boundaries
|
||||
|
||||
**Core Discovery Goals (accomplish through natural dialogue):**
|
||||
|
||||
1. **The Problem/Need**
|
||||
- What user or technical problem are we solving?
|
||||
- Why does this matter now?
|
||||
- What's the impact if we don't do this?
|
||||
|
||||
2. **The Solution Approach**
|
||||
- What's the proposed solution?
|
||||
- How should this work from a user/system perspective?
|
||||
- What alternatives were considered?
|
||||
|
||||
3. **Integration & Location**
|
||||
- <check if="brownfield">Where does this fit in the existing codebase?</check>
|
||||
- What existing code/patterns should we reference or follow?
|
||||
- What are the integration points?
|
||||
|
||||
4. **Scope Clarity**
|
||||
- What's IN scope for this work?
|
||||
- What's explicitly OUT of scope (future work, not needed)?
|
||||
- If multiple stories: What's MVP vs enhancement?
|
||||
|
||||
5. **Constraints & Dependencies**
|
||||
- Technical limitations or requirements?
|
||||
- Dependencies on other systems, APIs, or services?
|
||||
- Performance, security, or compliance considerations?
|
||||
|
||||
6. **Success Criteria**
|
||||
- How will we know this is done correctly?
|
||||
- What does "working" look like?
|
||||
- What edge cases matter?
|
||||
|
||||
**Conversation Style:**
|
||||
|
||||
- Be warm and collaborative, not interrogative
|
||||
- Ask follow-up questions based on their responses
|
||||
- Help them think through implications
|
||||
- Reference context from Phase 1 (existing code, stack, patterns)
|
||||
- Adapt depth to {{story_count}} complexity
|
||||
|
||||
Synthesize discoveries into clear, comprehensive specifications.
|
||||
</action>
|
||||
|
||||
<template-output>problem_statement</template-output>
|
||||
<template-output>solution_overview</template-output>
|
||||
<template-output>change_type</template-output>
|
||||
<template-output>scope_in</template-output>
|
||||
<template-output>scope_out</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Generate context-aware, definitive technical specification">
|
||||
|
||||
<critical>ALL TECHNICAL DECISIONS MUST BE DEFINITIVE - NO AMBIGUITY ALLOWED</critical>
|
||||
<critical>Use existing stack info to make SPECIFIC decisions</critical>
|
||||
<critical>Reference brownfield code to guide implementation</critical>
|
||||
|
||||
<action>Initialize tech-spec.md with the rich template</action>
|
||||
|
||||
<action>**Generate Context Section (already captured):**
|
||||
|
||||
These template variables are already populated from Step 1:
|
||||
|
||||
- {{loaded_documents_summary}}
|
||||
- {{project_stack_summary}}
|
||||
- {{existing_structure_summary}}
|
||||
|
||||
Just save them to the file.
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">loaded_documents_summary</template-output>
|
||||
<template-output file="tech-spec.md">project_stack_summary</template-output>
|
||||
<template-output file="tech-spec.md">existing_structure_summary</template-output>
|
||||
|
||||
<action>**Generate The Change Section:**
|
||||
|
||||
Already captured from Step 2:
|
||||
|
||||
- {{problem_statement}}
|
||||
- {{solution_overview}}
|
||||
- {{scope_in}}
|
||||
- {{scope_out}}
|
||||
|
||||
Save to file.
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">problem_statement</template-output>
|
||||
<template-output file="tech-spec.md">solution_overview</template-output>
|
||||
<template-output file="tech-spec.md">scope_in</template-output>
|
||||
<template-output file="tech-spec.md">scope_out</template-output>
|
||||
|
||||
<action>**Generate Implementation Details:**
|
||||
|
||||
Now make DEFINITIVE technical decisions using all the context gathered.
|
||||
|
||||
**Source Tree Changes - BE SPECIFIC:**
|
||||
|
||||
Bad (NEVER do this):
|
||||
|
||||
- "Update some files in the services folder"
|
||||
- "Add tests somewhere"
|
||||
|
||||
Good (ALWAYS do this):
|
||||
|
||||
- "src/services/UserService.ts - MODIFY - Add validateEmail() method at line 45"
|
||||
- "src/routes/api/users.ts - MODIFY - Add POST /users/validate endpoint"
|
||||
- "tests/services/UserService.test.ts - CREATE - Test suite for email validation"
|
||||
|
||||
Include:
|
||||
|
||||
- Exact file paths
|
||||
- Action: CREATE, MODIFY, DELETE
|
||||
- Specific what changes (methods, classes, endpoints, components)
|
||||
|
||||
**Use brownfield context:**
|
||||
|
||||
- If modifying existing files, reference current structure
|
||||
- Follow existing naming patterns
|
||||
- Place new code logically based on current organization
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">source_tree_changes</template-output>
|
||||
|
||||
<action>**Technical Approach - BE DEFINITIVE:**
|
||||
|
||||
Bad (ambiguous):
|
||||
|
||||
- "Use a logging library like winston or pino"
|
||||
- "Use Python 2 or 3"
|
||||
- "Set up some kind of validation"
|
||||
|
||||
Good (definitive):
|
||||
|
||||
- "Use winston v3.8.2 (already in package.json) for logging"
|
||||
- "Implement using Python 3.11 as specified in pyproject.toml"
|
||||
- "Use Joi v17.9.0 for request validation following pattern in UserController.ts"
|
||||
|
||||
**Use detected stack:**
|
||||
|
||||
- Reference exact versions from package.json/requirements.txt
|
||||
- Specify frameworks already in use
|
||||
- Make decisions based on what's already there
|
||||
|
||||
**For greenfield:**
|
||||
|
||||
- Make definitive choices and justify them
|
||||
- Specify exact versions
|
||||
- No "or" statements allowed
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">technical_approach</template-output>
|
||||
|
||||
<action>**Existing Patterns to Follow:**
|
||||
|
||||
<check if="brownfield">
|
||||
Document patterns from the existing codebase:
|
||||
- Class structure patterns
|
||||
- Function naming conventions
|
||||
- Error handling approach
|
||||
- Testing patterns
|
||||
- Documentation style
|
||||
|
||||
Example:
|
||||
"Follow the service pattern established in UserService.ts:
|
||||
|
||||
- Export class with constructor injection
|
||||
- Use async/await for all asynchronous operations
|
||||
- Throw ServiceError with error codes
|
||||
- Include JSDoc comments for all public methods"
|
||||
</check>
|
||||
|
||||
<check if="greenfield">
|
||||
"Greenfield project - establishing new patterns:
|
||||
- [Define the patterns to establish]"
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">existing_patterns</template-output>
|
||||
|
||||
<action>**Integration Points:**
|
||||
|
||||
Identify how this change connects:
|
||||
|
||||
- Internal modules it depends on
|
||||
- External APIs or services
|
||||
- Database interactions
|
||||
- Event emitters/listeners
|
||||
- State management
|
||||
|
||||
Be specific about interfaces and contracts.
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">integration_points</template-output>
|
||||
|
||||
<action>**Development Context:**
|
||||
|
||||
**Relevant Existing Code:**
|
||||
<check if="brownfield">
|
||||
Reference specific files or code sections developers should review:
|
||||
|
||||
- "See UserService.ts lines 120-150 for similar validation pattern"
|
||||
- "Reference AuthMiddleware.ts for authentication approach"
|
||||
- "Follow error handling in PaymentService.ts"
|
||||
</check>
|
||||
|
||||
**Framework/Libraries:**
|
||||
List with EXACT versions from detected stack:
|
||||
|
||||
- Express 4.18.2 (web framework)
|
||||
- winston 3.8.2 (logging)
|
||||
- Joi 17.9.0 (validation)
|
||||
- TypeScript 5.1.6 (language)
|
||||
|
||||
**Internal Modules:**
|
||||
List internal dependencies:
|
||||
|
||||
- @/services/UserService
|
||||
- @/middleware/auth
|
||||
- @/utils/validation
|
||||
|
||||
**Configuration Changes:**
|
||||
Any config files to update:
|
||||
|
||||
- Update .env with new SMTP settings
|
||||
- Add validation schema to config/schemas.ts
|
||||
- Update package.json scripts if needed
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">existing_code_references</template-output>
|
||||
<template-output file="tech-spec.md">framework_dependencies</template-output>
|
||||
<template-output file="tech-spec.md">internal_dependencies</template-output>
|
||||
<template-output file="tech-spec.md">configuration_changes</template-output>
|
||||
|
||||
<check if="field_type == brownfield">
|
||||
<template-output file="tech-spec.md">existing_conventions</template-output>
|
||||
</check>
|
||||
|
||||
<check if="field_type == greenfield">
|
||||
<action>Set {{existing_conventions}} = "Greenfield project - establishing new conventions per modern best practices"</action>
|
||||
<template-output file="tech-spec.md">existing_conventions</template-output>
|
||||
</check>
|
||||
|
||||
<action>**Implementation Stack:**
|
||||
|
||||
Comprehensive stack with versions:
|
||||
|
||||
- Runtime: Node.js 20.x
|
||||
- Framework: Express 4.18.2
|
||||
- Language: TypeScript 5.1.6
|
||||
- Testing: Jest 29.5.0
|
||||
- Linting: ESLint 8.42.0
|
||||
- Validation: Joi 17.9.0
|
||||
|
||||
All from detected project setup!
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">implementation_stack</template-output>
|
||||
|
||||
<action>**Technical Details:**
|
||||
|
||||
Deep technical specifics:
|
||||
|
||||
- Algorithms to implement
|
||||
- Data structures to use
|
||||
- Performance considerations
|
||||
- Security considerations
|
||||
- Error scenarios and handling
|
||||
- Edge cases
|
||||
|
||||
Be thorough - developers need details!
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">technical_details</template-output>
|
||||
|
||||
<action>**Development Setup:**
|
||||
|
||||
What does a developer need to run this locally?
|
||||
|
||||
Based on detected stack and scripts:
|
||||
|
||||
```
|
||||
1. Clone repo (if not already)
|
||||
2. npm install (installs all deps from package.json)
|
||||
3. cp .env.example .env (configure environment)
|
||||
4. npm run dev (starts development server)
|
||||
5. npm test (runs test suite)
|
||||
```
|
||||
|
||||
Or for Python:
|
||||
|
||||
```
|
||||
1. python -m venv venv
|
||||
2. source venv/bin/activate
|
||||
3. pip install -r requirements.txt
|
||||
4. python manage.py runserver
|
||||
```
|
||||
|
||||
Use the actual scripts from package.json/setup files!
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">development_setup</template-output>
|
||||
|
||||
<action>**Implementation Guide:**
|
||||
|
||||
**Setup Steps:**
|
||||
Pre-implementation checklist:
|
||||
|
||||
- Create feature branch
|
||||
- Verify dev environment running
|
||||
- Review existing code references
|
||||
- Set up test data if needed
|
||||
|
||||
**Implementation Steps:**
|
||||
Step-by-step breakdown:
|
||||
|
||||
For single-story changes:
|
||||
|
||||
1. [Step 1 with specific file and action]
|
||||
2. [Step 2 with specific file and action]
|
||||
3. [Write tests]
|
||||
4. [Verify acceptance criteria]
|
||||
|
||||
For multi-story features:
|
||||
Organize by story/phase:
|
||||
|
||||
1. Phase 1: [Foundation work]
|
||||
2. Phase 2: [Core implementation]
|
||||
3. Phase 3: [Testing and validation]
|
||||
|
||||
**Testing Strategy:**
|
||||
|
||||
- Unit tests for [specific functions]
|
||||
- Integration tests for [specific flows]
|
||||
- Manual testing checklist
|
||||
- Performance testing if applicable
|
||||
|
||||
**Acceptance Criteria:**
|
||||
Specific, measurable, testable criteria:
|
||||
|
||||
1. Given [scenario], when [action], then [outcome]
|
||||
2. [Metric] meets [threshold]
|
||||
3. [Feature] works in [environment]
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">setup_steps</template-output>
|
||||
<template-output file="tech-spec.md">implementation_steps</template-output>
|
||||
<template-output file="tech-spec.md">testing_strategy</template-output>
|
||||
<template-output file="tech-spec.md">acceptance_criteria</template-output>
|
||||
|
||||
<action>**Developer Resources:**
|
||||
|
||||
**File Paths Reference:**
|
||||
Complete list of all files involved:
|
||||
|
||||
- /src/services/UserService.ts
|
||||
- /src/routes/api/users.ts
|
||||
- /tests/services/UserService.test.ts
|
||||
- /src/types/user.ts
|
||||
|
||||
**Key Code Locations:**
|
||||
Important functions, classes, modules:
|
||||
|
||||
- UserService class (src/services/UserService.ts:15)
|
||||
- validateUser function (src/utils/validation.ts:42)
|
||||
- User type definition (src/types/user.ts:8)
|
||||
|
||||
**Testing Locations:**
|
||||
Where tests go:
|
||||
|
||||
- Unit: tests/services/
|
||||
- Integration: tests/integration/
|
||||
- E2E: tests/e2e/
|
||||
|
||||
**Documentation to Update:**
|
||||
Docs that need updating:
|
||||
|
||||
- README.md - Add new endpoint documentation
|
||||
- API.md - Document /users/validate endpoint
|
||||
- CHANGELOG.md - Note the new feature
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">file_paths_complete</template-output>
|
||||
<template-output file="tech-spec.md">key_code_locations</template-output>
|
||||
<template-output file="tech-spec.md">testing_locations</template-output>
|
||||
<template-output file="tech-spec.md">documentation_updates</template-output>
|
||||
|
||||
<action>**UX/UI Considerations:**
|
||||
|
||||
<check if="change affects user interface OR user experience">
|
||||
**Determine if this change has UI/UX impact:**
|
||||
- Does it change what users see?
|
||||
- Does it change how users interact?
|
||||
- Does it affect user workflows?
|
||||
|
||||
If YES, document:
|
||||
|
||||
**UI Components Affected:**
|
||||
|
||||
- List specific components (buttons, forms, modals, pages)
|
||||
- Note which need creation vs modification
|
||||
|
||||
**UX Flow Changes:**
|
||||
|
||||
- Current flow vs new flow
|
||||
- User journey impact
|
||||
- Navigation changes
|
||||
|
||||
**Visual/Interaction Patterns:**
|
||||
|
||||
- Follow existing design system? (check for design tokens, component library)
|
||||
- New patterns needed?
|
||||
- Responsive design considerations (mobile, tablet, desktop)
|
||||
|
||||
**Accessibility:**
|
||||
|
||||
- Keyboard navigation requirements
|
||||
- Screen reader compatibility
|
||||
- ARIA labels needed
|
||||
- Color contrast standards
|
||||
|
||||
**User Feedback:**
|
||||
|
||||
- Loading states
|
||||
- Error messages
|
||||
- Success confirmations
|
||||
- Progress indicators
|
||||
</check>
|
||||
|
||||
<check if="no UI/UX impact">
|
||||
"No UI/UX impact - backend/API/infrastructure change only"
|
||||
</check>
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">ux_ui_considerations</template-output>
|
||||
|
||||
<action>**Testing Approach:**
|
||||
|
||||
Comprehensive testing strategy using {{test_framework_info}}:
|
||||
|
||||
**CONFORM TO EXISTING TEST STANDARDS:**
|
||||
<check if="conform_to_conventions == yes">
|
||||
|
||||
- Follow existing test file naming: {{detected_test_patterns.file_naming}}
|
||||
- Use existing test organization: {{detected_test_patterns.organization}}
|
||||
- Match existing assertion style: {{detected_test_patterns.assertion_style}}
|
||||
- Meet existing coverage requirements: {{detected_test_patterns.coverage}}
|
||||
</check>
|
||||
|
||||
**Test Strategy:**
|
||||
|
||||
- Test framework: {{detected_test_framework}} (from project dependencies)
|
||||
- Unit tests for [specific functions/methods]
|
||||
- Integration tests for [specific flows/APIs]
|
||||
- E2E tests if UI changes
|
||||
- Mock/stub strategies (use existing patterns: {{detected_test_patterns.mocking}})
|
||||
- Performance benchmarks if applicable
|
||||
- Accessibility tests if UI changes
|
||||
|
||||
**Coverage:**
|
||||
|
||||
- Unit test coverage: [target %]
|
||||
- Integration coverage: [critical paths]
|
||||
- Ensure all acceptance criteria have corresponding tests
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">test_framework_info</template-output>
|
||||
<template-output file="tech-spec.md">testing_approach</template-output>
|
||||
|
||||
<action>**Deployment Strategy:**
|
||||
|
||||
**Deployment Steps:**
|
||||
How to deploy this change:
|
||||
|
||||
1. Merge to main branch
|
||||
2. Run CI/CD pipeline
|
||||
3. Deploy to staging
|
||||
4. Verify in staging
|
||||
5. Deploy to production
|
||||
6. Monitor for issues
|
||||
|
||||
**Rollback Plan:**
|
||||
How to undo if problems:
|
||||
|
||||
1. Revert commit [hash]
|
||||
2. Redeploy previous version
|
||||
3. Verify rollback successful
|
||||
|
||||
**Monitoring:**
|
||||
What to watch after deployment:
|
||||
|
||||
- Error rates in [logging service]
|
||||
- Response times for [endpoint]
|
||||
- User feedback on [feature]
|
||||
</action>
|
||||
|
||||
<template-output file="tech-spec.md">deployment_steps</template-output>
|
||||
<template-output file="tech-spec.md">rollback_plan</template-output>
|
||||
<template-output file="tech-spec.md">monitoring_approach</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Auto-validate cohesion, completeness, and quality">
|
||||
|
||||
<critical>Always run validation - this is NOT optional!</critical>
|
||||
|
||||
<action>Tech-spec generation complete! Now running automatic validation...</action>
|
||||
|
||||
<action>Load {installed_path}/checklist.md</action>
|
||||
<action>Review tech-spec.md against ALL checklist criteria:
|
||||
|
||||
**Section 1: Output Files Exist**
|
||||
|
||||
- Verify tech-spec.md created
|
||||
- Check for unfilled template variables
|
||||
|
||||
**Section 2: Context Gathering**
|
||||
|
||||
- Validate all available documents were loaded
|
||||
- Confirm stack detection worked
|
||||
- Verify brownfield analysis (if applicable)
|
||||
|
||||
**Section 3: Tech-Spec Definitiveness**
|
||||
|
||||
- Scan for "or" statements (FAIL if found)
|
||||
- Verify all versions are specific
|
||||
- Check stack alignment
|
||||
|
||||
**Section 4: Context-Rich Content**
|
||||
|
||||
- Verify all new template sections populated
|
||||
- Check existing code references (brownfield)
|
||||
- Validate framework dependencies listed
|
||||
|
||||
**Section 5-6: Story Quality (deferred to Step 5)**
|
||||
|
||||
**Section 7: Workflow Status (if applicable)**
|
||||
|
||||
**Section 8: Implementation Readiness**
|
||||
|
||||
- Can developer start immediately?
|
||||
- Is tech-spec comprehensive enough?
|
||||
</action>
|
||||
|
||||
<action>Generate validation report with specific scores:
|
||||
|
||||
- Context Gathering: [Comprehensive/Partial/Insufficient]
|
||||
- Definitiveness: [All definitive/Some ambiguity/Major issues]
|
||||
- Brownfield Integration: [N/A/Excellent/Partial/Missing]
|
||||
- Stack Alignment: [Perfect/Good/Partial/None]
|
||||
- Implementation Readiness: [Yes/No]
|
||||
</action>
|
||||
|
||||
<check if="validation issues found">
|
||||
<output>⚠️ **Validation Issues Detected:**
|
||||
|
||||
{{list_of_issues}}
|
||||
|
||||
I can fix these automatically. Shall I proceed? (yes/no)</output>
|
||||
|
||||
<ask>Fix validation issues? (yes/no)</ask>
|
||||
|
||||
<check if="yes">
|
||||
<action>Fix each issue and re-validate</action>
|
||||
<output>✅ Issues fixed! Re-validation passed.</output>
|
||||
</check>
|
||||
|
||||
<check if="no">
|
||||
<output>⚠️ Proceeding with warnings. Issues should be addressed manually.</output>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="validation passes">
|
||||
<output>✅ **Validation Passed!**
|
||||
|
||||
**Scores:**
|
||||
|
||||
- Context Gathering: {{context_score}}
|
||||
- Definitiveness: {{definitiveness_score}}
|
||||
- Brownfield Integration: {{brownfield_score}}
|
||||
- Stack Alignment: {{stack_score}}
|
||||
- Implementation Readiness: ✅ Ready
|
||||
|
||||
Tech-spec is high quality and ready for story generation!</output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Generate epic and context-rich stories">
|
||||
|
||||
<action>Invoke unified story generation workflow: {instructions_generate_stories}</action>
|
||||
|
||||
<action>This will generate:
|
||||
|
||||
- **epics.md** - Epic structure (minimal for 1 story, detailed for multiple)
|
||||
- **story-{epic-slug}-N.md** - Story files (where N = 1 to {{story_count}})
|
||||
|
||||
All stories reference tech-spec.md as primary context - comprehensive enough that developers can often skip story-context workflow.
|
||||
</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Finalize and guide next steps">
|
||||
|
||||
<output>**✅ Tech-Spec Complete, {user_name}!**
|
||||
|
||||
**Deliverables Created:**
|
||||
|
||||
- ✅ **tech-spec.md** - Context-rich technical specification
|
||||
- Includes: brownfield analysis, framework details, existing patterns
|
||||
- ✅ **epics.md** - Epic structure{{#if story_count == 1}} (minimal for single story){{else}} with {{story_count}} stories{{/if}}
|
||||
- ✅ **story-{epic-slug}-1.md** - First story{{#if story_count > 1}}
|
||||
- ✅ **story-{epic-slug}-2.md** - Second story{{/if}}{{#if story_count > 2}}
|
||||
- ✅ **story-{epic-slug}-3.md** - Third story{{/if}}{{#if story_count > 3}}
|
||||
- ✅ **Additional stories** through story-{epic-slug}-{{story_count}}.md{{/if}}
|
||||
|
||||
**What Makes This Tech-Spec Special:**
|
||||
|
||||
The tech-spec is comprehensive enough to serve as the primary context document:
|
||||
|
||||
- ✨ Brownfield codebase analysis (if applicable)
|
||||
- ✨ Exact framework and library versions from your project
|
||||
- ✨ Existing patterns and code references
|
||||
- ✨ Specific file paths and integration points
|
||||
- ✨ Complete developer resources
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
**🎯 Recommended Path - Direct to Development:**
|
||||
|
||||
Since the tech-spec is CONTEXT-RICH, you can often skip story-context generation!
|
||||
|
||||
{{#if story_count == 1}}
|
||||
**For Your Single Story:**
|
||||
|
||||
1. Ask DEV agent to run `dev-story`
|
||||
- Select story-{epic-slug}-1.md
|
||||
- Tech-spec provides all the context needed!
|
||||
|
||||
💡 **Optional:** Only run `story-context` (SM agent) if this is unusually complex
|
||||
{{else}}
|
||||
**For Your {{story_count}} Stories - Iterative Approach:**
|
||||
|
||||
1. **Start with Story 1:**
|
||||
- Ask DEV agent to run `dev-story`
|
||||
- Select story-{epic-slug}-1.md
|
||||
- Tech-spec provides context
|
||||
|
||||
2. **After Story 1 Complete:**
|
||||
- Repeat for story-{epic-slug}-2.md
|
||||
- Continue through story {{story_count}}
|
||||
|
||||
💡 **Alternative:** Use `sprint-planning` (SM agent) to organize all stories as a coordinated sprint
|
||||
|
||||
💡 **Optional:** Run `story-context` (SM agent) for complex stories needing additional context
|
||||
{{/if}}
|
||||
|
||||
**Your Tech-Spec:**
|
||||
|
||||
- 📄 Saved to: `{output_folder}/tech-spec.md`
|
||||
- Epic & Stories: `{output_folder}/epics.md` + `{sprint_artifacts}/`
|
||||
- Contains: All context, decisions, patterns, and implementation guidance
|
||||
- Ready for: Direct development!
|
||||
|
||||
The tech-spec is your single source of truth! 🚀
|
||||
</output>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,181 @@
|
||||
# {{project_name}} - Technical Specification
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**Project Level:** {{project_level}}
|
||||
**Change Type:** {{change_type}}
|
||||
**Development Context:** {{development_context}}
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
### Available Documents
|
||||
|
||||
{{loaded_documents_summary}}
|
||||
|
||||
### Project Stack
|
||||
|
||||
{{project_stack_summary}}
|
||||
|
||||
### Existing Codebase Structure
|
||||
|
||||
{{existing_structure_summary}}
|
||||
|
||||
---
|
||||
|
||||
## The Change
|
||||
|
||||
### Problem Statement
|
||||
|
||||
{{problem_statement}}
|
||||
|
||||
### Proposed Solution
|
||||
|
||||
{{solution_overview}}
|
||||
|
||||
### Scope
|
||||
|
||||
**In Scope:**
|
||||
|
||||
{{scope_in}}
|
||||
|
||||
**Out of Scope:**
|
||||
|
||||
{{scope_out}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Source Tree Changes
|
||||
|
||||
{{source_tree_changes}}
|
||||
|
||||
### Technical Approach
|
||||
|
||||
{{technical_approach}}
|
||||
|
||||
### Existing Patterns to Follow
|
||||
|
||||
{{existing_patterns}}
|
||||
|
||||
### Integration Points
|
||||
|
||||
{{integration_points}}
|
||||
|
||||
---
|
||||
|
||||
## Development Context
|
||||
|
||||
### Relevant Existing Code
|
||||
|
||||
{{existing_code_references}}
|
||||
|
||||
### Dependencies
|
||||
|
||||
**Framework/Libraries:**
|
||||
|
||||
{{framework_dependencies}}
|
||||
|
||||
**Internal Modules:**
|
||||
|
||||
{{internal_dependencies}}
|
||||
|
||||
### Configuration Changes
|
||||
|
||||
{{configuration_changes}}
|
||||
|
||||
### Existing Conventions (Brownfield)
|
||||
|
||||
{{existing_conventions}}
|
||||
|
||||
### Test Framework & Standards
|
||||
|
||||
{{test_framework_info}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Stack
|
||||
|
||||
{{implementation_stack}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Details
|
||||
|
||||
{{technical_details}}
|
||||
|
||||
---
|
||||
|
||||
## Development Setup
|
||||
|
||||
{{development_setup}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Guide
|
||||
|
||||
### Setup Steps
|
||||
|
||||
{{setup_steps}}
|
||||
|
||||
### Implementation Steps
|
||||
|
||||
{{implementation_steps}}
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
{{acceptance_criteria}}
|
||||
|
||||
---
|
||||
|
||||
## Developer Resources
|
||||
|
||||
### File Paths Reference
|
||||
|
||||
{{file_paths_complete}}
|
||||
|
||||
### Key Code Locations
|
||||
|
||||
{{key_code_locations}}
|
||||
|
||||
### Testing Locations
|
||||
|
||||
{{testing_locations}}
|
||||
|
||||
### Documentation to Update
|
||||
|
||||
{{documentation_updates}}
|
||||
|
||||
---
|
||||
|
||||
## UX/UI Considerations
|
||||
|
||||
{{ux_ui_considerations}}
|
||||
|
||||
---
|
||||
|
||||
## Testing Approach
|
||||
|
||||
{{testing_approach}}
|
||||
|
||||
---
|
||||
|
||||
## Deployment Strategy
|
||||
|
||||
### Deployment Steps
|
||||
|
||||
{{deployment_steps}}
|
||||
|
||||
### Rollback Plan
|
||||
|
||||
{{rollback_plan}}
|
||||
|
||||
### Monitoring
|
||||
|
||||
{{monitoring_approach}}
|
||||
@@ -0,0 +1,90 @@
|
||||
# Story {{N}}.{{M}}: {{story_title}}
|
||||
|
||||
**Status:** Draft
|
||||
|
||||
---
|
||||
|
||||
## User Story
|
||||
|
||||
As a {{user_type}},
|
||||
I want {{capability}},
|
||||
So that {{value_benefit}}.
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
**Given** {{precondition}}
|
||||
**When** {{action}}
|
||||
**Then** {{expected_outcome}}
|
||||
|
||||
**And** {{additional_criteria}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Tasks / Subtasks
|
||||
|
||||
{{tasks_subtasks}}
|
||||
|
||||
### Technical Summary
|
||||
|
||||
{{technical_summary}}
|
||||
|
||||
### Project Structure Notes
|
||||
|
||||
- **Files to modify:** {{files_to_modify}}
|
||||
- **Expected test locations:** {{test_locations}}
|
||||
- **Estimated effort:** {{story_points}} story points ({{time_estimate}})
|
||||
- **Prerequisites:** {{dependencies}}
|
||||
|
||||
### Key Code References
|
||||
|
||||
{{existing_code_references}}
|
||||
|
||||
---
|
||||
|
||||
## Context References
|
||||
|
||||
**Tech-Spec:** [tech-spec.md](../tech-spec.md) - Primary context document containing:
|
||||
|
||||
- Brownfield codebase analysis (if applicable)
|
||||
- Framework and library details with versions
|
||||
- Existing patterns to follow
|
||||
- Integration points and dependencies
|
||||
- Complete implementation guidance
|
||||
|
||||
**Architecture:** {{architecture_references}}
|
||||
|
||||
<!-- Additional context XML paths will be added here if story-context workflow is run -->
|
||||
|
||||
---
|
||||
|
||||
## Dev Agent Record
|
||||
|
||||
### Agent Model Used
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### Debug Log References
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### Completion Notes
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### Files Modified
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
### Test Results
|
||||
|
||||
<!-- Will be populated during dev-story execution -->
|
||||
|
||||
---
|
||||
|
||||
## Review Notes
|
||||
|
||||
<!-- Will be populated during code review -->
|
||||
@@ -0,0 +1,58 @@
|
||||
# Technical Specification
|
||||
name: tech-spec
|
||||
description: "Technical specification workflow for quick-flow projects. Creates focused tech spec and generates epic + stories (1 story for simple changes, 2-5 stories for features). Tech-spec only - no PRD needed."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/.bmad/bmm/config.yaml"
|
||||
project_name: "{config_source}:project_name"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
workflow-status: "{output_folder}/bmm-workflow-status.yaml"
|
||||
|
||||
# Runtime variables (captured during workflow execution)
|
||||
story_count: runtime-captured
|
||||
epic_slug: runtime-captured
|
||||
change_type: runtime-captured
|
||||
field_type: runtime-captured
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/.bmad/bmm/workflows/2-plan-workflows/tech-spec"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
template: "{installed_path}/tech-spec-template.md"
|
||||
|
||||
# Story generation (unified approach - always generates epic + stories)
|
||||
instructions_generate_stories: "{installed_path}/instructions-generate-stories.md"
|
||||
user_story_template: "{installed_path}/user-story-template.md"
|
||||
epics_template: "{installed_path}/epics-template.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/tech-spec.md"
|
||||
epics_file: "{output_folder}/epics.md"
|
||||
sprint_artifacts: "{output_folder}/sprint_artifacts"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
|
||||
input_file_patterns:
|
||||
product_brief:
|
||||
description: "Product vision and goals (optional)"
|
||||
whole: "{output_folder}/*brief*.md"
|
||||
sharded: "{output_folder}/*brief*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
research:
|
||||
description: "Market or domain research (optional)"
|
||||
whole: "{output_folder}/*research*.md"
|
||||
sharded: "{output_folder}/*research*/index.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
document_project:
|
||||
description: "Brownfield project documentation (optional)"
|
||||
sharded: "{output_folder}/index.md"
|
||||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
standalone: true
|
||||
Reference in New Issue
Block a user