drt-method 1.0.0

package/src/drt-skills/3-solutioning/drt-create-epics-and-stories/steps/step-01-validate-prerequisites.md

@@ -0,0 +1,263 @@
+# Step 1: Validate Prerequisites and Extract Requirements
+
+## STEP GOAL:
+
+To validate that all required input documents exist and extract all requirements (FRs, NFRs, and additional requirements from UX/Architecture) needed for epic and story creation.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a product strategist and technical specifications writer
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring requirements extraction expertise
+- ✅ User brings their product vision and context
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on extracting and organizing requirements
+- 🚫 FORBIDDEN to start creating epics or stories in this step
+- 💬 Extract requirements from ALL available documents
+- 🚪 POPULATE the template sections exactly as needed
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Extract requirements systematically from all documents
+- 💾 Populate {planning_artifacts}/epics.md with extracted requirements
+- 📖 Update frontmatter with extraction progress
+- 🚫 FORBIDDEN to load next step until user selects 'C' and requirements are extracted
+
+## REQUIREMENTS EXTRACTION PROCESS:
+
+### 1. Welcome and Overview
+
+Welcome {user_name} to comprehensive epic and story creation!
+
+**CRITICAL PREREQUISITE VALIDATION:**
+
+Verify required documents exist and are complete:
+
+1. **PRD.md** - Contains requirements (FRs and NFRs) and product scope
+2. **Architecture.md** - Contains technical decisions, API contracts, data models
+3. **UX design contract** (if UI exists) - Contains visual identity, interaction patterns, mockups, and user flows
+
+### 2. Document Discovery and Validation
+
+Search for required documents using these patterns (sharded means a large document was split into multiple small files with an index.md into a folder) - if the whole document is found, use that instead of the sharded version:
+
+**PRD Document Search Priority:**
+
+1. `{planning_artifacts}/*prd*.md` (whole document)
+2. `{planning_artifacts}/*prd*/index.md` (sharded version)
+
+**Architecture Document Search Priority:**
+
+1. `{planning_artifacts}/*architecture*.md` (whole document)
+2. `{planning_artifacts}/*architecture*/index.md` (sharded version)
+
+**UX Design Document Search (Optional):**
+
+1. `{planning_artifacts}/ux-designs/ux-*/DESIGN.md` and `{planning_artifacts}/ux-designs/ux-*/EXPERIENCE.md` (drt-ux spine pair)
+2. `{planning_artifacts}/*ux*.md` (legacy whole document)
+3. `{planning_artifacts}/*ux*/index.md` (legacy sharded version)
+
+For each matching drt-ux run folder, treat `DESIGN.md` and `EXPERIENCE.md` as one UX design contract:
+
+- Confirm and load both files together. `DESIGN.md` owns visual identity and design tokens; `EXPERIENCE.md` owns information architecture, behavior, states, interactions, accessibility, and journeys.
+- Add both files to the `inputDocuments: []` frontmatter array.
+- If only one spine exists, report the incomplete pair and ask whether the user wants to include the partial UX handoff.
+- If multiple run folders match, show each run folder with the spine frontmatter `status` and `updated` values when available, then ask the user which UX design contract to include.
+
+Before proceeding, Ask the user if there are any other documents to include for analysis, and if anything found should be excluded. Wait for user confirmation. Once confirmed, create the {planning_artifacts}/epics.md from the ../templates/epics-template.md and in the front matter list the files in the array of `inputDocuments: []`.
+
+### 3. Extract Functional Requirements (FRs)
+
+From the PRD document (full or sharded), read then entire document and extract ALL functional requirements:
+
+**Extraction Method:**
+
+- Look for numbered items like "FR1:", "Functional Requirement 1:", or similar
+- Identify requirement statements that describe what the system must DO
+- Include user actions, system behaviors, and business rules
+
+**Format the FR list as:**
+
+```
+FR1: [Clear, testable requirement description]
+FR2: [Clear, testable requirement description]
+...
+```
+
+### 4. Extract Non-Functional Requirements (NFRs)
+
+From the PRD document, extract ALL non-functional requirements:
+
+**Extraction Method:**
+
+- Look for performance, security, usability, reliability requirements
+- Identify constraints and quality attributes
+- Include technical standards and compliance requirements
+
+**Format the NFR list as:**
+
+```
+NFR1: [Performance/Security/Usability requirement]
+NFR2: [Performance/Security/Usability requirement]
+...
+```
+
+### 5. Extract Additional Requirements from Architecture
+
+Review the Architecture document for technical requirements that impact epic and story creation:
+
+**Look for:**
+
+- **Starter Template**: Does Architecture specify a starter/greenfield template? If YES, document this for Epic 1 Story 1
+- Infrastructure and deployment requirements
+- Integration requirements with external systems
+- Data migration or setup requirements
+- Monitoring and logging requirements
+- API versioning or compatibility requirements
+- Security implementation requirements
+
+**IMPORTANT**: If a starter template is mentioned in Architecture, note it prominently. This will impact Epic 1 Story 1.
+
+**Format Additional Requirements as:**
+
+```
+- [Technical requirement from Architecture that affects implementation]
+- [Infrastructure setup requirement]
+- [Integration requirement]
+...
+```
+
+### 6. Extract UX Design Requirements (if UX document exists)
+
+**IMPORTANT**: The UX Design Specification is a first-class input document, not supplementary material. Requirements from the UX spec must be extracted with the same rigor as PRD functional requirements.
+
+Read the FULL UX design contract and extract ALL actionable work items. For a drt-ux spine pair, read both `DESIGN.md` and `EXPERIENCE.md`:
+
+**Look for:**
+
+- **Design token work**: Color systems, spacing scales, typography tokens that need implementation or consolidation
+- **Component proposals**: Reusable UI components identified in the UX spec (e.g., ConfirmActions, StatusMessage, EmptyState, FocusIndicator)
+- **Visual standardization**: Semantic CSS classes, consistent color palette usage, design pattern consolidation
+- **Accessibility requirements**: Contrast audit fixes, ARIA patterns, keyboard navigation, screen reader support
+- **Responsive design requirements**: Breakpoints, layout adaptations, mobile-specific interactions
+- **Interaction patterns**: Animations, transitions, loading states, error handling UX
+- **Browser/device compatibility**: Target platforms, progressive enhancement requirements
+
+**Format UX Design Requirements as a SEPARATE section (not merged into Additional Requirements):**
+
+```
+UX-DR1: [Actionable UX design requirement with clear implementation scope]
+UX-DR2: [Actionable UX design requirement with clear implementation scope]
+...
+```
+
+**🚨 CRITICAL**: Do NOT reduce UX requirements to vague summaries. Each UX-DR must be specific enough to generate a story with testable acceptance criteria. If the UX spec identifies 6 reusable components, list all 6 — not "create reusable components."
+
+### 7. Load and Initialize Template
+
+Load ../templates/epics-template.md and initialize {planning_artifacts}/epics.md:
+
+1. Copy the entire template to {planning_artifacts}/epics.md
+2. Replace {{project_name}} with the actual project name
+3. Replace placeholder sections with extracted requirements:
+   - {{fr_list}} → extracted FRs
+   - {{nfr_list}} → extracted NFRs
+   - {{additional_requirements}} → extracted additional requirements (from Architecture)
+   - {{ux_design_requirements}} → extracted UX Design Requirements (if UX document exists)
+4. Leave {{requirements_coverage_map}} and {{epics_list}} as placeholders for now
+
+### 8. Present Extracted Requirements
+
+Display to user:
+
+**Functional Requirements Extracted:**
+
+- Show count of FRs found
+- Display the first few FRs as examples
+- Ask if any FRs are missing or incorrectly captured
+
+**Non-Functional Requirements Extracted:**
+
+- Show count of NFRs found
+- Display key NFRs
+- Ask if any constraints were missed
+
+**Additional Requirements (Architecture):**
+
+- Summarize technical requirements from Architecture
+- Verify completeness
+
+**UX Design Requirements (if applicable):**
+
+- Show count of UX-DRs found
+- Display key UX Design requirements (design tokens, components, accessibility)
+- Verify each UX-DR is specific enough for story creation
+
+### 9. Get User Confirmation
+
+Ask: "Do these extracted requirements accurately represent what needs to be built? Any additions or corrections?"
+
+Update the requirements based on user feedback until confirmation is received.
+
+## CONTENT TO SAVE TO DOCUMENT:
+
+After extraction and confirmation, update {planning_artifacts}/epics.md with:
+
+- Complete FR list in {{fr_list}} section
+- Complete NFR list in {{nfr_list}} section
+- All additional requirements in {{additional_requirements}} section
+- UX Design requirements in {{ux_design_requirements}} section (if UX document exists)
+
+### 10. Present MENU OPTIONS
+
+Display: `**Confirm the Requirements are complete and correct to [C] continue:**`
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then end with display again of the menu option
+
+#### Menu Handling Logic:
+
+- IF C: Save all to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-02-design-epics.md
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#10-present-menu-options)
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN C is selected and all requirements are saved to document and frontmatter is updated, will you then read fully and follow: ./step-02-design-epics.md to begin epic design step.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All required documents found and validated
+- All FRs extracted and formatted correctly
+- All NFRs extracted and formatted correctly
+- Additional requirements from Architecture/UX identified
+- Template initialized with requirements
+- User confirms requirements are complete and accurate
+
+### ❌ SYSTEM FAILURE:
+
+- Missing required documents
+- Incomplete requirements extraction
+- Template not properly initialized
+- Not saving requirements to output file
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

package/src/drt-skills/3-solutioning/drt-create-epics-and-stories/steps/step-02-design-epics.md

@@ -0,0 +1,242 @@
+# Step 2: Design Epic List
+
+## STEP GOAL:
+
+To design and get approval for the epics_list that will organize all requirements into user-value-focused epics.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a product strategist and technical specifications writer
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring product strategy and epic design expertise
+- ✅ User brings their product vision and priorities
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on creating the epics_list
+- 🚫 FORBIDDEN to create individual stories in this step
+- 💬 Organize epics around user value, not technical layers
+- 🚪 GET explicit approval for the epics_list
+- 🔗 **CRITICAL: Each epic must be standalone and enable future epics without requiring future epics to function**
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Design epics collaboratively based on extracted requirements
+- 💾 Update {{epics_list}} in {planning_artifacts}/epics.md
+- 📖 Document the FR coverage mapping
+- 🚫 FORBIDDEN to load next step until user approves epics_list
+
+## EPIC DESIGN PROCESS:
+
+### 1. Review Extracted Requirements
+
+Load {planning_artifacts}/epics.md and review:
+
+- **Functional Requirements:** Count and review FRs from Step 1
+- **Non-Functional Requirements:** Review NFRs that need to be addressed
+- **Additional Requirements:** Review technical and UX requirements
+
+### 2. Explain Epic Design Principles
+
+**EPIC DESIGN PRINCIPLES:**
+
+1. **User-Value First**: Each epic must enable users to accomplish something meaningful
+2. **Requirements Grouping**: Group related FRs that deliver cohesive user outcomes
+3. **Incremental Delivery**: Each epic should deliver value independently
+4. **Logical Flow**: Natural progression from user's perspective
+5. **Dependency-Free Within Epic**: Stories within an epic must NOT depend on future stories
+6. **Implementation Efficiency**: Consider consolidating epics that all modify the same core files into fewer epics
+
+**⚠️ CRITICAL PRINCIPLE:**
+Organize by USER VALUE, not technical layers:
+
+**✅ CORRECT Epic Examples (Standalone & Enable Future Epics):**
+
+- Epic 1: User Authentication & Profiles (users can register, login, manage profiles) - **Standalone: Complete auth system**
+- Epic 2: Content Creation (users can create, edit, publish content) - **Standalone: Uses auth, creates content**
+- Epic 3: Social Interaction (users can follow, comment, like content) - **Standalone: Uses auth + content**
+- Epic 4: Search & Discovery (users can find content and other users) - **Standalone: Uses all previous**
+
+**❌ WRONG Epic Examples (Technical Layers or Dependencies):**
+
+- Epic 1: Database Setup (creates all tables upfront) - **No user value**
+- Epic 2: API Development (builds all endpoints) - **No user value**
+- Epic 3: Frontend Components (creates reusable components) - **No user value**
+- Epic 4: Deployment Pipeline (CI/CD setup) - **No user value**
+
+**❌ WRONG Epic Examples (File Churn on Same Component):**
+
+- Epic 1: File Upload (modifies model, controller, web form, web API)
+- Epic 2: File Status (modifies model, controller, web form, web API)
+- Epic 3: File Access permissions (modifies model, controller, web form, web API)
+- All three epics touch the same files — consolidate into one epic with ordered stories
+
+**✅ CORRECT Alternative:**
+
+- Epic 1: File Management Enhancement (upload, status, permissions as stories within one epic)
+- Rationale: Single component, fully pre-designed, no feedback loop between epics
+
+**🔗 DEPENDENCY RULES:**
+
+- Each epic must deliver COMPLETE functionality for its domain
+- Epic 2 must not require Epic 3 to function
+- Epic 3 can build upon Epic 1 & 2 but must stand alone
+
+### 3. Design Epic Structure Collaboratively
+
+**Step A: Assess Context and Identify Themes**
+
+First, assess how much of the solution design is already validated (Architecture, UX, Test Design).
+When the outcome is certain and direction changes between epics are unlikely, prefer fewer but larger epics.
+Split into multiple epics when there is a genuine risk boundary or when early feedback could change direction
+of following epics.
+
+Then, identify user value themes:
+
+- Look for natural groupings in the FRs
+- Identify user journeys or workflows
+- Consider user types and their goals
+
+**Step B: Propose Epic Structure**
+
+For each proposed epic (considering whether epics share the same core files):
+
+1. **Epic Title**: User-centric, value-focused
+2. **User Outcome**: What users can accomplish after this epic
+3. **FR Coverage**: Which FR numbers this epic addresses
+4. **Implementation Notes**: Any technical or UX considerations
+
+**Step C: Review for File Overlap**
+
+Assess whether multiple proposed epics repeatedly target the same core files. If overlap is significant:
+
+- Distinguish meaningful overlap (same component end-to-end) from incidental sharing
+- Ask whether to consolidate into one epic with ordered stories
+- If confirmed, merge the epic FRs into a single epic, preserving dependency flow: each story must still fit within
+  a single dev agent's context
+
+**Step D: Create the epics_list**
+
+Format the epics_list as:
+
+```
+## Epic List
+
+### Epic 1: [Epic Title]
+[Epic goal statement - what users can accomplish]
+**FRs covered:** FR1, FR2, FR3, etc.
+
+### Epic 2: [Epic Title]
+[Epic goal statement - what users can accomplish]
+**FRs covered:** FR4, FR5, FR6, etc.
+
+[Continue for all epics]
+```
+
+### 4. Present Epic List for Review
+
+Display the complete epics_list to user with:
+
+- Total number of epics
+- FR coverage per epic
+- User value delivered by each epic
+- Any natural dependencies
+
+### 5. Create Requirements Coverage Map
+
+Create {{requirements_coverage_map}} showing how each FR maps to an epic:
+
+```
+### FR Coverage Map
+
+FR1: Epic 1 - [Brief description]
+FR2: Epic 1 - [Brief description]
+FR3: Epic 2 - [Brief description]
+...
+```
+
+This ensures no FRs are missed.
+
+### 6. Collaborative Refinement
+
+Ask user:
+
+- "Does this epic structure align with your product vision?"
+- "Are all user outcomes properly captured?"
+- "Should we adjust any epic groupings?"
+- "Are there natural dependencies we've missed?"
+
+### 7. Get Final Approval
+
+**CRITICAL:** Must get explicit user approval:
+"Do you approve this epic structure for proceeding to story creation?"
+
+If user wants changes:
+
+- Make the requested adjustments
+- Update the epics_list
+- Re-present for approval
+- Repeat until approval is received
+
+## CONTENT TO UPDATE IN DOCUMENT:
+
+After approval, update {planning_artifacts}/epics.md:
+
+1. Replace {{epics_list}} placeholder with the approved epic list
+2. Replace {{requirements_coverage_map}} with the coverage map
+3. Ensure all FRs are mapped to epics
+
+### 8. Present MENU OPTIONS
+
+Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
+
+#### Menu Handling Logic:
+
+- IF A: Invoke the `drt-advanced-elicitation` skill
+- IF P: Invoke the `drt-party-mode` skill
+- IF C: Save approved epics_list to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-03-create-stories.md
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution completes, redisplay the menu
+- User can chat or ask questions - always respond when conversation ends, redisplay the menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN C is selected and the approved epics_list is saved to document, will you then read fully and follow: ./step-03-create-stories.md to begin story creation step.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Epics designed around user value
+- All FRs mapped to specific epics
+- epics_list created and formatted correctly
+- Requirements coverage map completed
+- User gives explicit approval for epic structure
+- Document updated with approved epics
+
+### ❌ SYSTEM FAILURE:
+
+- Epics organized by technical layers
+- Missing FRs in coverage map
+- No user approval obtained
+- epics_list not saved to document
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.