fix: ChatBubble crash and DeepSeek API compatibility
- Fix ChatBubble to handle non-string content with String() wrapper - Fix API route to use generateText for non-streaming requests - Add @ai-sdk/openai-compatible for non-OpenAI providers (DeepSeek, etc.) - Use Chat Completions API instead of Responses API for compatible providers - Update ChatBubble tests and fix component exports to kebab-case - Remove stale PascalCase ChatBubble.tsx file
This commit is contained in:
Max
@@ -0,0 +1,218 @@
|
||||
---
|
||||
name: 'step-v-01-discovery'
|
||||
description: 'Document Discovery & Confirmation - Handle fresh context validation, confirm PRD path, discover input documents'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-02-format-detection.md'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
prdPurpose: '../data/prd-purpose.md'
|
||||
---
|
||||
|
||||
# Step 1: Document Discovery & Confirmation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Handle fresh context validation by confirming PRD path, discovering and loading input documents from frontmatter, and initializing the validation report.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ 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 systematic validation expertise and analytical rigor
|
||||
- ✅ User brings domain knowledge and specific PRD context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on discovering PRD and input documents, not validating yet
|
||||
- 🚫 FORBIDDEN to perform any validation checks in this step
|
||||
- 💬 Approach: Systematic discovery with clear reporting to user
|
||||
- 🚪 This is the setup step - get everything ready for validation
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Discover and confirm PRD to validate
|
||||
- 💾 Load PRD and all input documents from frontmatter
|
||||
- 📖 Initialize validation report next to PRD
|
||||
- 🚫 FORBIDDEN to load next step until user confirms setup
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD path (user-specified or discovered), workflow configuration
|
||||
- Focus: Document discovery and setup only
|
||||
- Limits: Don't perform validation, don't skip discovery
|
||||
- Dependencies: Configuration loaded from PRD workflow.md initialization
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load PRD Purpose and Standards
|
||||
|
||||
Load and read the complete file at:
|
||||
`{prdPurpose}`
|
||||
|
||||
This file contains the BMAD PRD philosophy, standards, and validation criteria that will guide all validation checks. Internalize this understanding - it defines what makes a great BMAD PRD.
|
||||
|
||||
### 2. Discover PRD to Validate
|
||||
|
||||
**If PRD path provided as invocation parameter:**
|
||||
- Use provided path
|
||||
|
||||
**If no PRD path provided:**
|
||||
"**PRD Validation Workflow**
|
||||
|
||||
Which PRD would you like to validate?
|
||||
|
||||
Please provide the path to the PRD file you want to validate."
|
||||
|
||||
**Wait for user to provide PRD path.**
|
||||
|
||||
### 3. Validate PRD Exists and Load
|
||||
|
||||
Once PRD path is provided:
|
||||
|
||||
- Check if PRD file exists at specified path
|
||||
- If not found: "I cannot find a PRD at that path. Please check the path and try again."
|
||||
- If found: Load the complete PRD file including frontmatter
|
||||
|
||||
### 4. Extract Frontmatter and Input Documents
|
||||
|
||||
From the loaded PRD frontmatter, extract:
|
||||
|
||||
- `inputDocuments: []` array (if present)
|
||||
- Any other relevant metadata (classification, date, etc.)
|
||||
|
||||
**If no inputDocuments array exists:**
|
||||
Note this and proceed with PRD-only validation
|
||||
|
||||
### 5. Load Input Documents
|
||||
|
||||
For each document listed in `inputDocuments`:
|
||||
|
||||
- Attempt to load the document
|
||||
- Track successfully loaded documents
|
||||
- Note any documents that fail to load
|
||||
|
||||
**Build list of loaded input documents:**
|
||||
- Product Brief (if present)
|
||||
- Research documents (if present)
|
||||
- Other reference materials (if present)
|
||||
|
||||
### 6. Ask About Additional Reference Documents
|
||||
|
||||
"**I've loaded the following documents from your PRD frontmatter:**
|
||||
|
||||
{list loaded documents with file names}
|
||||
|
||||
**Are there any additional reference documents you'd like me to include in this validation?**
|
||||
|
||||
These could include:
|
||||
- Additional research or context documents
|
||||
- Project documentation not tracked in frontmatter
|
||||
- Standards or compliance documents
|
||||
- Competitive analysis or benchmarks
|
||||
|
||||
Please provide paths to any additional documents, or type 'none' to proceed."
|
||||
|
||||
**Load any additional documents provided by user.**
|
||||
|
||||
### 7. Initialize Validation Report
|
||||
|
||||
Create validation report at: `{validationReportPath}`
|
||||
|
||||
**Initialize with frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
validationTarget: '{prd_path}'
|
||||
validationDate: '{current_date}'
|
||||
inputDocuments: [list of all loaded documents]
|
||||
validationStepsCompleted: []
|
||||
validationStatus: IN_PROGRESS
|
||||
---
|
||||
```
|
||||
|
||||
**Initial content:**
|
||||
```markdown
|
||||
# PRD Validation Report
|
||||
|
||||
**PRD Being Validated:** {prd_path}
|
||||
**Validation Date:** {current_date}
|
||||
|
||||
## Input Documents
|
||||
|
||||
{list all documents loaded for validation}
|
||||
|
||||
## Validation Findings
|
||||
|
||||
[Findings will be appended as validation progresses]
|
||||
```
|
||||
|
||||
### 8. Present Discovery Summary
|
||||
|
||||
"**Setup Complete!**
|
||||
|
||||
**PRD to Validate:** {prd_path}
|
||||
|
||||
**Input Documents Loaded:**
|
||||
- PRD: {prd_name} ✓
|
||||
- Product Brief: {count} {if count > 0}✓{else}(none found){/if}
|
||||
- Research: {count} {if count > 0}✓{else}(none found){/if}
|
||||
- Additional References: {count} {if count > 0}✓{else}(none){/if}
|
||||
|
||||
**Validation Report:** {validationReportPath}
|
||||
|
||||
**Ready to begin validation.**"
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Format Detection
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can ask questions or add more documents - always respond and redisplay menu
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Load, read entire file, then execute {nextStepFile} to begin format detection
|
||||
- IF user provides additional document: Load it, update report, redisplay summary
|
||||
- IF Any other: help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- PRD path discovered and confirmed
|
||||
- PRD file exists and loads successfully
|
||||
- All input documents from frontmatter loaded
|
||||
- Additional reference documents (if any) loaded
|
||||
- Validation report initialized next to PRD
|
||||
- User clearly informed of setup status
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding with non-existent PRD file
|
||||
- Not loading input documents from frontmatter
|
||||
- Creating validation report in wrong location
|
||||
- Proceeding without user confirming setup
|
||||
- Not handling missing input documents gracefully
|
||||
|
||||
**Master Rule:** Complete discovery and setup BEFORE validation. This step ensures everything is in place for systematic validation checks.
|
||||
@@ -0,0 +1,191 @@
|
||||
---
|
||||
name: 'step-v-02-format-detection'
|
||||
description: 'Format Detection & Structure Analysis - Classify PRD format and route appropriately'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-03-density-validation.md'
|
||||
altStepFile: './step-v-02b-parity-check.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
---
|
||||
|
||||
# Step 2: Format Detection & Structure Analysis
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Detect if PRD follows BMAD format and route appropriately - classify as BMAD Standard / BMAD Variant / Non-Standard, with optional parity check for non-standard formats.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ 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 systematic validation expertise and pattern recognition
|
||||
- ✅ User brings domain knowledge and PRD context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on detecting format and classifying structure
|
||||
- 🚫 FORBIDDEN to perform other validation checks in this step
|
||||
- 💬 Approach: Analytical and systematic, clear reporting of findings
|
||||
- 🚪 This is a branch step - may route to parity check for non-standard PRDs
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Analyze PRD structure systematically
|
||||
- 💾 Append format findings to validation report
|
||||
- 📖 Route appropriately based on format classification
|
||||
- 🚫 FORBIDDEN to skip format detection or proceed without classification
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file loaded in step 1, validation report initialized
|
||||
- Focus: Format detection and classification only
|
||||
- Limits: Don't perform other validation, don't skip classification
|
||||
- Dependencies: Step 1 completed - PRD loaded and report initialized
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Extract PRD Structure
|
||||
|
||||
Load the complete PRD file and extract:
|
||||
|
||||
**All Level 2 (##) headers:**
|
||||
- Scan through entire PRD document
|
||||
- Extract all ## section headers
|
||||
- List them in order
|
||||
|
||||
**PRD frontmatter:**
|
||||
- Extract classification.domain if present
|
||||
- Extract classification.projectType if present
|
||||
- Note any other relevant metadata
|
||||
|
||||
### 2. Check for BMAD PRD Core Sections
|
||||
|
||||
Check if the PRD contains the following BMAD PRD core sections:
|
||||
|
||||
1. **Executive Summary** (or variations: ## Executive Summary, ## Overview, ## Introduction)
|
||||
2. **Success Criteria** (or: ## Success Criteria, ## Goals, ## Objectives)
|
||||
3. **Product Scope** (or: ## Product Scope, ## Scope, ## In Scope, ## Out of Scope)
|
||||
4. **User Journeys** (or: ## User Journeys, ## User Stories, ## User Flows)
|
||||
5. **Functional Requirements** (or: ## Functional Requirements, ## Features, ## Capabilities)
|
||||
6. **Non-Functional Requirements** (or: ## Non-Functional Requirements, ## NFRs, ## Quality Attributes)
|
||||
|
||||
**Count matches:**
|
||||
- How many of these 6 core sections are present?
|
||||
- Which specific sections are present?
|
||||
- Which are missing?
|
||||
|
||||
### 3. Classify PRD Format
|
||||
|
||||
Based on core section count, classify:
|
||||
|
||||
**BMAD Standard:**
|
||||
- 5-6 core sections present
|
||||
- Follows BMAD PRD structure closely
|
||||
|
||||
**BMAD Variant:**
|
||||
- 3-4 core sections present
|
||||
- Generally follows BMAD patterns but may have structural differences
|
||||
- Missing some sections but recognizable as BMAD-style
|
||||
|
||||
**Non-Standard:**
|
||||
- Fewer than 3 core sections present
|
||||
- Does not follow BMAD PRD structure
|
||||
- May be completely custom format, legacy format, or from another framework
|
||||
|
||||
### 4. Report Format Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Format Detection
|
||||
|
||||
**PRD Structure:**
|
||||
[List all ## Level 2 headers found]
|
||||
|
||||
**BMAD Core Sections Present:**
|
||||
- Executive Summary: [Present/Missing]
|
||||
- Success Criteria: [Present/Missing]
|
||||
- Product Scope: [Present/Missing]
|
||||
- User Journeys: [Present/Missing]
|
||||
- Functional Requirements: [Present/Missing]
|
||||
- Non-Functional Requirements: [Present/Missing]
|
||||
|
||||
**Format Classification:** [BMAD Standard / BMAD Variant / Non-Standard]
|
||||
**Core Sections Present:** [count]/6
|
||||
```
|
||||
|
||||
### 5. Route Based on Format Classification
|
||||
|
||||
**IF format is BMAD Standard or BMAD Variant:**
|
||||
|
||||
Display: "**Format Detected:** {classification}
|
||||
|
||||
Proceeding to systematic validation checks..."
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-03-density-validation.md)
|
||||
|
||||
**IF format is Non-Standard (< 3 core sections):**
|
||||
|
||||
Display: "**Format Detected:** Non-Standard PRD
|
||||
|
||||
This PRD does not follow BMAD standard structure (only {count}/6 core sections present).
|
||||
|
||||
You have options:"
|
||||
|
||||
Present MENU OPTIONS below for user selection
|
||||
|
||||
### 6. Present MENU OPTIONS (Non-Standard PRDs Only)
|
||||
|
||||
**[A] Parity Check** - Analyze gaps and estimate effort to reach BMAD PRD parity
|
||||
**[B] Validate As-Is** - Proceed with validation using current structure
|
||||
**[C] Exit** - Exit validation and review format findings
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- Only proceed based on user selection
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A (Parity Check): Load, read entire file, then execute {altStepFile} (step-v-02b-parity-check.md)
|
||||
- IF B (Validate As-Is): Display "Proceeding with validation..." then load, read entire file, then execute {nextStepFile}
|
||||
- IF C (Exit): Display format findings summary and exit validation
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All ## Level 2 headers extracted successfully
|
||||
- BMAD core sections checked systematically
|
||||
- Format classified correctly based on section count
|
||||
- Findings reported to validation report
|
||||
- BMAD Standard/Variant PRDs proceed directly to next validation step
|
||||
- Non-Standard PRDs pause and present options to user
|
||||
- User can choose parity check, validate as-is, or exit
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not extracting all headers before classification
|
||||
- Incorrect format classification
|
||||
- Not reporting findings to validation report
|
||||
- Not pausing for non-standard PRDs
|
||||
- Proceeding without user decision for non-standard formats
|
||||
|
||||
**Master Rule:** Format detection determines validation path. Non-standard PRDs require user choice before proceeding.
|
||||
@@ -0,0 +1,209 @@
|
||||
---
|
||||
name: 'step-v-02b-parity-check'
|
||||
description: 'Document Parity Check - Analyze non-standard PRD and identify gaps to achieve BMAD PRD parity'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-03-density-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
---
|
||||
|
||||
# Step 2B: Document Parity Check
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Analyze non-standard PRD and identify gaps to achieve BMAD PRD parity, presenting user with options for how to proceed.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ 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 BMAD PRD standards expertise and gap analysis
|
||||
- ✅ User brings domain knowledge and PRD context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on analyzing gaps and estimating parity effort
|
||||
- 🚫 FORBIDDEN to perform other validation checks in this step
|
||||
- 💬 Approach: Systematic gap analysis with clear recommendations
|
||||
- 🚪 This is an optional branch step - user chooses next action
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Analyze each BMAD PRD section for gaps
|
||||
- 💾 Append parity analysis to validation report
|
||||
- 📖 Present options and await user decision
|
||||
- 🚫 FORBIDDEN to proceed without user selection
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Non-standard PRD from step 2, validation report in progress
|
||||
- Focus: Parity analysis only - what's missing, what's needed
|
||||
- Limits: Don't perform validation checks, don't auto-proceed
|
||||
- Dependencies: Step 2 classified PRD as non-standard and user chose parity check
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Analyze Each BMAD PRD Section
|
||||
|
||||
For each of the 6 BMAD PRD core sections, analyze:
|
||||
|
||||
**Executive Summary:**
|
||||
- Does PRD have vision/overview?
|
||||
- Is problem statement clear?
|
||||
- Are target users identified?
|
||||
- Gap: [What's missing or incomplete]
|
||||
|
||||
**Success Criteria:**
|
||||
- Are measurable goals defined?
|
||||
- Is success clearly defined?
|
||||
- Gap: [What's missing or incomplete]
|
||||
|
||||
**Product Scope:**
|
||||
- Is scope clearly defined?
|
||||
- Are in-scope items listed?
|
||||
- Are out-of-scope items listed?
|
||||
- Gap: [What's missing or incomplete]
|
||||
|
||||
**User Journeys:**
|
||||
- Are user types/personas identified?
|
||||
- Are user flows documented?
|
||||
- Gap: [What's missing or incomplete]
|
||||
|
||||
**Functional Requirements:**
|
||||
- Are features/capabilities listed?
|
||||
- Are requirements structured?
|
||||
- Gap: [What's missing or incomplete]
|
||||
|
||||
**Non-Functional Requirements:**
|
||||
- Are quality attributes defined?
|
||||
- Are performance/security/etc. requirements documented?
|
||||
- Gap: [What's missing or incomplete]
|
||||
|
||||
### 2. Estimate Effort to Reach Parity
|
||||
|
||||
For each missing or incomplete section, estimate:
|
||||
|
||||
**Effort Level:**
|
||||
- Minimal - Section exists but needs minor enhancements
|
||||
- Moderate - Section missing but content exists elsewhere in PRD
|
||||
- Significant - Section missing, requires new content creation
|
||||
|
||||
**Total Parity Effort:**
|
||||
- Based on individual section estimates
|
||||
- Classify overall: Quick / Moderate / Substantial effort
|
||||
|
||||
### 3. Report Parity Analysis to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Parity Analysis (Non-Standard PRD)
|
||||
|
||||
### Section-by-Section Gap Analysis
|
||||
|
||||
**Executive Summary:**
|
||||
- Status: [Present/Missing/Incomplete]
|
||||
- Gap: [specific gap description]
|
||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
||||
|
||||
**Success Criteria:**
|
||||
- Status: [Present/Missing/Incomplete]
|
||||
- Gap: [specific gap description]
|
||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
||||
|
||||
**Product Scope:**
|
||||
- Status: [Present/Missing/Incomplete]
|
||||
- Gap: [specific gap description]
|
||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
||||
|
||||
**User Journeys:**
|
||||
- Status: [Present/Missing/Incomplete]
|
||||
- Gap: [specific gap description]
|
||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
||||
|
||||
**Functional Requirements:**
|
||||
- Status: [Present/Missing/Incomplete]
|
||||
- Gap: [specific gap description]
|
||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
||||
|
||||
**Non-Functional Requirements:**
|
||||
- Status: [Present/Missing/Incomplete]
|
||||
- Gap: [specific gap description]
|
||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
||||
|
||||
### Overall Parity Assessment
|
||||
|
||||
**Overall Effort to Reach BMAD Standard:** [Quick/Moderate/Substantial]
|
||||
**Recommendation:** [Brief recommendation based on analysis]
|
||||
```
|
||||
|
||||
### 4. Present Parity Analysis and Options
|
||||
|
||||
Display:
|
||||
|
||||
"**Parity Analysis Complete**
|
||||
|
||||
Your PRD is missing {count} of 6 core BMAD PRD sections. The overall effort to reach BMAD standard is: **{effort level}**
|
||||
|
||||
**Quick Summary:**
|
||||
[2-3 sentence summary of key gaps]
|
||||
|
||||
**Recommendation:**
|
||||
{recommendation from analysis}
|
||||
|
||||
**How would you like to proceed?**"
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
**[C] Continue Validation** - Proceed with validation using current structure
|
||||
**[E] Exit & Review** - Exit validation and review parity report
|
||||
**[S] Save & Exit** - Save parity report and exit
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- Only proceed based on user selection
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C (Continue): Display "Proceeding with validation..." then load, read entire file, then execute {nextStepFile}
|
||||
- IF E (Exit): Display parity summary and exit validation
|
||||
- IF S (Save): Confirm saved, display summary, exit
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All 6 BMAD PRD sections analyzed for gaps
|
||||
- Effort estimates provided for each gap
|
||||
- Overall parity effort assessed correctly
|
||||
- Parity analysis reported to validation report
|
||||
- Clear summary presented to user
|
||||
- User can choose to continue validation, exit, or save report
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not analyzing all 6 sections systematically
|
||||
- Missing effort estimates
|
||||
- Not reporting parity analysis to validation report
|
||||
- Auto-proceeding without user decision
|
||||
- Unclear recommendations
|
||||
|
||||
**Master Rule:** Parity check informs user of gaps and effort, but user decides whether to proceed with validation or address gaps first.
|
||||
@@ -0,0 +1,174 @@
|
||||
---
|
||||
name: 'step-v-03-density-validation'
|
||||
description: 'Information Density Check - Scan for anti-patterns that violate information density principles'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-04-brief-coverage-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
---
|
||||
|
||||
# Step 3: Information Density Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate PRD meets BMAD information density standards by scanning for conversational filler, wordy phrases, and redundant expressions that violate conciseness principles.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring analytical rigor and attention to detail
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on information density anti-patterns
|
||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
||||
- 💬 Approach: Systematic scanning and categorization
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Scan PRD for density anti-patterns systematically
|
||||
- 💾 Append density findings to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file, validation report with format findings
|
||||
- Focus: Information density validation only
|
||||
- Limits: Don't validate other aspects, don't pause for user input
|
||||
- Dependencies: Step 2 completed - format classification done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Attempt Sub-Process Validation
|
||||
|
||||
**Try to use Task tool to spawn a subprocess:**
|
||||
|
||||
"Perform information density validation on this PRD:
|
||||
|
||||
1. Load the PRD file
|
||||
2. Scan for the following anti-patterns:
|
||||
- Conversational filler phrases (examples: 'The system will allow users to...', 'It is important to note that...', 'In order to')
|
||||
- Wordy phrases (examples: 'Due to the fact that', 'In the event of', 'For the purpose of')
|
||||
- Redundant phrases (examples: 'Future plans', 'Absolutely essential', 'Past history')
|
||||
3. Count violations by category with line numbers
|
||||
4. Classify severity: Critical (>10 violations), Warning (5-10), Pass (<5)
|
||||
|
||||
Return structured findings with counts and examples."
|
||||
|
||||
### 2. Graceful Degradation (if Task tool unavailable)
|
||||
|
||||
If Task tool unavailable, perform analysis directly:
|
||||
|
||||
**Scan for conversational filler patterns:**
|
||||
- "The system will allow users to..."
|
||||
- "It is important to note that..."
|
||||
- "In order to"
|
||||
- "For the purpose of"
|
||||
- "With regard to"
|
||||
- Count occurrences and note line numbers
|
||||
|
||||
**Scan for wordy phrases:**
|
||||
- "Due to the fact that" (use "because")
|
||||
- "In the event of" (use "if")
|
||||
- "At this point in time" (use "now")
|
||||
- "In a manner that" (use "how")
|
||||
- Count occurrences and note line numbers
|
||||
|
||||
**Scan for redundant phrases:**
|
||||
- "Future plans" (just "plans")
|
||||
- "Past history" (just "history")
|
||||
- "Absolutely essential" (just "essential")
|
||||
- "Completely finish" (just "finish")
|
||||
- Count occurrences and note line numbers
|
||||
|
||||
### 3. Classify Severity
|
||||
|
||||
**Calculate total violations:**
|
||||
- Conversational filler count
|
||||
- Wordy phrases count
|
||||
- Redundant phrases count
|
||||
- Total = sum of all categories
|
||||
|
||||
**Determine severity:**
|
||||
- **Critical:** Total > 10 violations
|
||||
- **Warning:** Total 5-10 violations
|
||||
- **Pass:** Total < 5 violations
|
||||
|
||||
### 4. Report Density Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Information Density Validation
|
||||
|
||||
**Anti-Pattern Violations:**
|
||||
|
||||
**Conversational Filler:** {count} occurrences
|
||||
[If count > 0, list examples with line numbers]
|
||||
|
||||
**Wordy Phrases:** {count} occurrences
|
||||
[If count > 0, list examples with line numbers]
|
||||
|
||||
**Redundant Phrases:** {count} occurrences
|
||||
[If count > 0, list examples with line numbers]
|
||||
|
||||
**Total Violations:** {total}
|
||||
|
||||
**Severity Assessment:** [Critical/Warning/Pass]
|
||||
|
||||
**Recommendation:**
|
||||
[If Critical] "PRD requires significant revision to improve information density. Every sentence should carry weight without filler."
|
||||
[If Warning] "PRD would benefit from reducing wordiness and eliminating filler phrases."
|
||||
[If Pass] "PRD demonstrates good information density with minimal violations."
|
||||
```
|
||||
|
||||
### 5. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Information Density Validation Complete**
|
||||
|
||||
Severity: {Critical/Warning/Pass}
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-04-brief-coverage-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- PRD scanned for all three anti-pattern categories
|
||||
- Violations counted with line numbers
|
||||
- Severity classified correctly
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not scanning all anti-pattern categories
|
||||
- Missing severity classification
|
||||
- Not reporting findings to validation report
|
||||
- Pausing for user input (should auto-proceed)
|
||||
- Not attempting subprocess architecture
|
||||
|
||||
**Master Rule:** Information density validation runs autonomously. Scan, classify, report, auto-proceed. No user interaction needed.
|
||||
@@ -0,0 +1,214 @@
|
||||
---
|
||||
name: 'step-v-04-brief-coverage-validation'
|
||||
description: 'Product Brief Coverage Check - Validate PRD covers all content from Product Brief (if used as input)'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-05-measurability-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
productBrief: '{product_brief_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
---
|
||||
|
||||
# Step 4: Product Brief Coverage Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate that PRD covers all content from Product Brief (if brief was used as input), mapping brief content to PRD sections and identifying gaps.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring analytical rigor and traceability expertise
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on Product Brief coverage (conditional on brief existence)
|
||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
||||
- 💬 Approach: Systematic mapping and gap analysis
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Check if Product Brief exists in input documents
|
||||
- 💬 If no brief: Skip this check and report "N/A - No Product Brief"
|
||||
- 🎯 If brief exists: Map brief content to PRD sections
|
||||
- 💾 Append coverage findings to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file, input documents from step 1, validation report
|
||||
- Focus: Product Brief coverage only (conditional)
|
||||
- Limits: Don't validate other aspects, conditional execution
|
||||
- Dependencies: Step 1 completed - input documents loaded
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Check for Product Brief
|
||||
|
||||
Check if Product Brief was loaded in step 1's inputDocuments:
|
||||
|
||||
**IF no Product Brief found:**
|
||||
Append to validation report:
|
||||
```markdown
|
||||
## Product Brief Coverage
|
||||
|
||||
**Status:** N/A - No Product Brief was provided as input
|
||||
```
|
||||
|
||||
Display: "**Product Brief Coverage: Skipped** (No Product Brief provided)
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile}
|
||||
|
||||
**IF Product Brief exists:** Continue to step 2 below
|
||||
|
||||
### 2. Attempt Sub-Process Validation
|
||||
|
||||
**Try to use Task tool to spawn a subprocess:**
|
||||
|
||||
"Perform Product Brief coverage validation:
|
||||
|
||||
1. Load the Product Brief
|
||||
2. Extract key content:
|
||||
- Vision statement
|
||||
- Target users/personas
|
||||
- Problem statement
|
||||
- Key features
|
||||
- Goals/objectives
|
||||
- Differentiators
|
||||
- Constraints
|
||||
3. For each item, search PRD for corresponding coverage
|
||||
4. Classify coverage: Fully Covered / Partially Covered / Not Found / Intentionally Excluded
|
||||
5. Note any gaps with severity: Critical / Moderate / Informational
|
||||
|
||||
Return structured coverage map with classifications."
|
||||
|
||||
### 3. Graceful Degradation (if Task tool unavailable)
|
||||
|
||||
If Task tool unavailable, perform analysis directly:
|
||||
|
||||
**Extract from Product Brief:**
|
||||
- Vision: What is this product?
|
||||
- Users: Who is it for?
|
||||
- Problem: What problem does it solve?
|
||||
- Features: What are the key capabilities?
|
||||
- Goals: What are the success criteria?
|
||||
- Differentiators: What makes it unique?
|
||||
|
||||
**For each item, search PRD:**
|
||||
- Scan Executive Summary for vision
|
||||
- Check User Journeys or user personas
|
||||
- Look for problem statement
|
||||
- Review Functional Requirements for features
|
||||
- Check Success Criteria section
|
||||
- Search for differentiators
|
||||
|
||||
**Classify coverage:**
|
||||
- **Fully Covered:** Content present and complete
|
||||
- **Partially Covered:** Content present but incomplete
|
||||
- **Not Found:** Content missing from PRD
|
||||
- **Intentionally Excluded:** Content explicitly out of scope
|
||||
|
||||
### 4. Assess Coverage and Severity
|
||||
|
||||
**For each gap (Partially Covered or Not Found):**
|
||||
- Is this Critical? (Core vision, primary users, main features)
|
||||
- Is this Moderate? (Secondary features, some goals)
|
||||
- Is this Informational? (Nice-to-have features, minor details)
|
||||
|
||||
**Note:** Some exclusions may be intentional (valid scoping decisions)
|
||||
|
||||
### 5. Report Coverage Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Product Brief Coverage
|
||||
|
||||
**Product Brief:** {brief_file_name}
|
||||
|
||||
### Coverage Map
|
||||
|
||||
**Vision Statement:** [Fully/Partially/Not Found/Intentionally Excluded]
|
||||
[If gap: Note severity and specific missing content]
|
||||
|
||||
**Target Users:** [Fully/Partially/Not Found/Intentionally Excluded]
|
||||
[If gap: Note severity and specific missing content]
|
||||
|
||||
**Problem Statement:** [Fully/Partially/Not Found/Intentionally Excluded]
|
||||
[If gap: Note severity and specific missing content]
|
||||
|
||||
**Key Features:** [Fully/Partially/Not Found/Intentionally Excluded]
|
||||
[If gap: List specific features with severity]
|
||||
|
||||
**Goals/Objectives:** [Fully/Partially/Not Found/Intentionally Excluded]
|
||||
[If gap: Note severity and specific missing content]
|
||||
|
||||
**Differentiators:** [Fully/Partially/Not Found/Intentionally Excluded]
|
||||
[If gap: Note severity and specific missing content]
|
||||
|
||||
### Coverage Summary
|
||||
|
||||
**Overall Coverage:** [percentage or qualitative assessment]
|
||||
**Critical Gaps:** [count] [list if any]
|
||||
**Moderate Gaps:** [count] [list if any]
|
||||
**Informational Gaps:** [count] [list if any]
|
||||
|
||||
**Recommendation:**
|
||||
[If critical gaps exist] "PRD should be revised to cover critical Product Brief content."
|
||||
[If moderate gaps] "Consider addressing moderate gaps for complete coverage."
|
||||
[If minimal gaps] "PRD provides good coverage of Product Brief content."
|
||||
```
|
||||
|
||||
### 6. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Product Brief Coverage Validation Complete**
|
||||
|
||||
Overall Coverage: {assessment}
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-05-measurability-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Checked for Product Brief existence correctly
|
||||
- If no brief: Reported "N/A" and skipped gracefully
|
||||
- If brief exists: Mapped all key brief content to PRD sections
|
||||
- Coverage classified appropriately (Fully/Partially/Not Found/Intentionally Excluded)
|
||||
- Severity assessed for gaps (Critical/Moderate/Informational)
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking for brief existence before attempting validation
|
||||
- If brief exists: not mapping all key content areas
|
||||
- Missing coverage classifications
|
||||
- Not reporting findings to validation report
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** Product Brief coverage is conditional - skip if no brief, validate thoroughly if brief exists. Always auto-proceed.
|
||||
@@ -0,0 +1,228 @@
|
||||
---
|
||||
name: 'step-v-05-measurability-validation'
|
||||
description: 'Measurability Validation - Validate that all requirements (FRs and NFRs) are measurable and testable'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-06-traceability-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
---
|
||||
|
||||
# Step 5: Measurability Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate that all Functional Requirements (FRs) and Non-Functional Requirements (NFRs) are measurable, testable, and follow proper format without implementation details.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring analytical rigor and requirements engineering expertise
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on FR and NFR measurability
|
||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
||||
- 💬 Approach: Systematic requirement-by-requirement analysis
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Extract all FRs and NFRs from PRD
|
||||
- 💾 Validate each for measurability and format
|
||||
- 📖 Append findings to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file, validation report
|
||||
- Focus: FR and NFR measurability only
|
||||
- Limits: Don't validate other aspects, don't pause for user input
|
||||
- Dependencies: Steps 2-4 completed - initial validation checks done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Attempt Sub-Process Validation
|
||||
|
||||
**Try to use Task tool to spawn a subprocess:**
|
||||
|
||||
"Perform measurability validation on this PRD:
|
||||
|
||||
**Functional Requirements (FRs):**
|
||||
1. Extract all FRs from Functional Requirements section
|
||||
2. Check each FR for:
|
||||
- '[Actor] can [capability]' format compliance
|
||||
- No subjective adjectives (easy, fast, simple, intuitive, etc.)
|
||||
- No vague quantifiers (multiple, several, some, many, etc.)
|
||||
- No implementation details (technology names, library names, data structures unless capability-relevant)
|
||||
3. Document violations with line numbers
|
||||
|
||||
**Non-Functional Requirements (NFRs):**
|
||||
1. Extract all NFRs from Non-Functional Requirements section
|
||||
2. Check each NFR for:
|
||||
- Specific metrics with measurement methods
|
||||
- Template compliance (criterion, metric, measurement method, context)
|
||||
- Context included (why this matters, who it affects)
|
||||
3. Document violations with line numbers
|
||||
|
||||
Return structured findings with violation counts and examples."
|
||||
|
||||
### 2. Graceful Degradation (if Task tool unavailable)
|
||||
|
||||
If Task tool unavailable, perform analysis directly:
|
||||
|
||||
**Functional Requirements Analysis:**
|
||||
|
||||
Extract all FRs and check each for:
|
||||
|
||||
**Format compliance:**
|
||||
- Does it follow "[Actor] can [capability]" pattern?
|
||||
- Is actor clearly defined?
|
||||
- Is capability actionable and testable?
|
||||
|
||||
**No subjective adjectives:**
|
||||
- Scan for: easy, fast, simple, intuitive, user-friendly, responsive, quick, efficient (without metrics)
|
||||
- Note line numbers
|
||||
|
||||
**No vague quantifiers:**
|
||||
- Scan for: multiple, several, some, many, few, various, number of
|
||||
- Note line numbers
|
||||
|
||||
**No implementation details:**
|
||||
- Scan for: React, Vue, Angular, PostgreSQL, MongoDB, AWS, Docker, Kubernetes, Redux, etc.
|
||||
- Unless capability-relevant (e.g., "API consumers can access...")
|
||||
- Note line numbers
|
||||
|
||||
**Non-Functional Requirements Analysis:**
|
||||
|
||||
Extract all NFRs and check each for:
|
||||
|
||||
**Specific metrics:**
|
||||
- Is there a measurable criterion? (e.g., "response time < 200ms", not "fast response")
|
||||
- Can this be measured or tested?
|
||||
|
||||
**Template compliance:**
|
||||
- Criterion defined?
|
||||
- Metric specified?
|
||||
- Measurement method included?
|
||||
- Context provided?
|
||||
|
||||
### 3. Tally Violations
|
||||
|
||||
**FR Violations:**
|
||||
- Format violations: count
|
||||
- Subjective adjectives: count
|
||||
- Vague quantifiers: count
|
||||
- Implementation leakage: count
|
||||
- Total FR violations: sum
|
||||
|
||||
**NFR Violations:**
|
||||
- Missing metrics: count
|
||||
- Incomplete template: count
|
||||
- Missing context: count
|
||||
- Total NFR violations: sum
|
||||
|
||||
**Total violations:** FR violations + NFR violations
|
||||
|
||||
### 4. Report Measurability Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Measurability Validation
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
**Total FRs Analyzed:** {count}
|
||||
|
||||
**Format Violations:** {count}
|
||||
[If violations exist, list examples with line numbers]
|
||||
|
||||
**Subjective Adjectives Found:** {count}
|
||||
[If found, list examples with line numbers]
|
||||
|
||||
**Vague Quantifiers Found:** {count}
|
||||
[If found, list examples with line numbers]
|
||||
|
||||
**Implementation Leakage:** {count}
|
||||
[If found, list examples with line numbers]
|
||||
|
||||
**FR Violations Total:** {total}
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
**Total NFRs Analyzed:** {count}
|
||||
|
||||
**Missing Metrics:** {count}
|
||||
[If missing, list examples with line numbers]
|
||||
|
||||
**Incomplete Template:** {count}
|
||||
[If incomplete, list examples with line numbers]
|
||||
|
||||
**Missing Context:** {count}
|
||||
[If missing, list examples with line numbers]
|
||||
|
||||
**NFR Violations Total:** {total}
|
||||
|
||||
### Overall Assessment
|
||||
|
||||
**Total Requirements:** {FRs + NFRs}
|
||||
**Total Violations:** {FR violations + NFR violations}
|
||||
|
||||
**Severity:** [Critical if >10 violations, Warning if 5-10, Pass if <5]
|
||||
|
||||
**Recommendation:**
|
||||
[If Critical] "Many requirements are not measurable or testable. Requirements must be revised to be testable for downstream work."
|
||||
[If Warning] "Some requirements need refinement for measurability. Focus on violating requirements above."
|
||||
[If Pass] "Requirements demonstrate good measurability with minimal issues."
|
||||
```
|
||||
|
||||
### 5. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Measurability Validation Complete**
|
||||
|
||||
Total Violations: {count} ({severity})
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-06-traceability-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All FRs extracted and analyzed for measurability
|
||||
- All NFRs extracted and analyzed for measurability
|
||||
- Violations documented with line numbers
|
||||
- Severity assessed correctly
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not analyzing all FRs and NFRs
|
||||
- Missing line numbers for violations
|
||||
- Not reporting findings to validation report
|
||||
- Not assessing severity
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** Requirements must be testable to be useful. Validate every requirement for measurability, document violations, auto-proceed.
|
||||
@@ -0,0 +1,217 @@
|
||||
---
|
||||
name: 'step-v-06-traceability-validation'
|
||||
description: 'Traceability Validation - Validate the traceability chain from vision → success → journeys → FRs is intact'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-07-implementation-leakage-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
---
|
||||
|
||||
# Step 6: Traceability Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate the traceability chain from Executive Summary → Success Criteria → User Journeys → Functional Requirements is intact, ensuring every requirement traces back to a user need or business objective.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring analytical rigor and traceability matrix expertise
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on traceability chain validation
|
||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
||||
- 💬 Approach: Systematic chain validation and orphan detection
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Build and validate traceability matrix
|
||||
- 💾 Identify broken chains and orphan requirements
|
||||
- 📖 Append findings to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file, validation report
|
||||
- Focus: Traceability chain validation only
|
||||
- Limits: Don't validate other aspects, don't pause for user input
|
||||
- Dependencies: Steps 2-5 completed - initial validations done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Attempt Sub-Process Validation
|
||||
|
||||
**Try to use Task tool to spawn a subprocess:**
|
||||
|
||||
"Perform traceability validation on this PRD:
|
||||
|
||||
1. Extract content from Executive Summary (vision, goals)
|
||||
2. Extract Success Criteria
|
||||
3. Extract User Journeys (user types, flows, outcomes)
|
||||
4. Extract Functional Requirements (FRs)
|
||||
5. Extract Product Scope (in-scope items)
|
||||
|
||||
**Validate chains:**
|
||||
- Executive Summary → Success Criteria: Does vision align with defined success?
|
||||
- Success Criteria → User Journeys: Are success criteria supported by user journeys?
|
||||
- User Journeys → Functional Requirements: Does each FR trace back to a user journey?
|
||||
- Scope → FRs: Do MVP scope FRs align with in-scope items?
|
||||
|
||||
**Identify orphans:**
|
||||
- FRs not traceable to any user journey or business objective
|
||||
- Success criteria not supported by user journeys
|
||||
- User journeys without supporting FRs
|
||||
|
||||
Build traceability matrix and identify broken chains and orphan FRs.
|
||||
|
||||
Return structured findings with chain status and orphan list."
|
||||
|
||||
### 2. Graceful Degradation (if Task tool unavailable)
|
||||
|
||||
If Task tool unavailable, perform analysis directly:
|
||||
|
||||
**Step 1: Extract key elements**
|
||||
- Executive Summary: Note vision, goals, objectives
|
||||
- Success Criteria: List all criteria
|
||||
- User Journeys: List user types and their flows
|
||||
- Functional Requirements: List all FRs
|
||||
- Product Scope: List in-scope items
|
||||
|
||||
**Step 2: Validate Executive Summary → Success Criteria**
|
||||
- Does Executive Summary mention the success dimensions?
|
||||
- Are Success Criteria aligned with vision?
|
||||
- Note any misalignment
|
||||
|
||||
**Step 3: Validate Success Criteria → User Journeys**
|
||||
- For each success criterion, is there a user journey that achieves it?
|
||||
- Note success criteria without supporting journeys
|
||||
|
||||
**Step 4: Validate User Journeys → FRs**
|
||||
- For each user journey/flow, are there FRs that enable it?
|
||||
- List FRs with no clear user journey origin
|
||||
- Note orphan FRs (requirements without traceable source)
|
||||
|
||||
**Step 5: Validate Scope → FR Alignment**
|
||||
- Does MVP scope align with essential FRs?
|
||||
- Are in-scope items supported by FRs?
|
||||
- Note misalignments
|
||||
|
||||
**Step 6: Build traceability matrix**
|
||||
- Map each FR to its source (journey or business objective)
|
||||
- Note orphan FRs
|
||||
- Identify broken chains
|
||||
|
||||
### 3. Tally Traceability Issues
|
||||
|
||||
**Broken chains:**
|
||||
- Executive Summary → Success Criteria gaps: count
|
||||
- Success Criteria → User Journeys gaps: count
|
||||
- User Journeys → FRs gaps: count
|
||||
- Scope → FR misalignments: count
|
||||
|
||||
**Orphan elements:**
|
||||
- Orphan FRs (no traceable source): count
|
||||
- Unsupported success criteria: count
|
||||
- User journeys without FRs: count
|
||||
|
||||
**Total issues:** Sum of all broken chains and orphans
|
||||
|
||||
### 4. Report Traceability Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Traceability Validation
|
||||
|
||||
### Chain Validation
|
||||
|
||||
**Executive Summary → Success Criteria:** [Intact/Gaps Identified]
|
||||
{If gaps: List specific misalignments}
|
||||
|
||||
**Success Criteria → User Journeys:** [Intact/Gaps Identified]
|
||||
{If gaps: List unsupported success criteria}
|
||||
|
||||
**User Journeys → Functional Requirements:** [Intact/Gaps Identified]
|
||||
{If gaps: List journeys without supporting FRs}
|
||||
|
||||
**Scope → FR Alignment:** [Intact/Misaligned]
|
||||
{If misaligned: List specific issues}
|
||||
|
||||
### Orphan Elements
|
||||
|
||||
**Orphan Functional Requirements:** {count}
|
||||
{List orphan FRs with numbers}
|
||||
|
||||
**Unsupported Success Criteria:** {count}
|
||||
{List unsupported criteria}
|
||||
|
||||
**User Journeys Without FRs:** {count}
|
||||
{List journeys without FRs}
|
||||
|
||||
### Traceability Matrix
|
||||
|
||||
{Summary table showing traceability coverage}
|
||||
|
||||
**Total Traceability Issues:** {total}
|
||||
|
||||
**Severity:** [Critical if orphan FRs exist, Warning if gaps, Pass if intact]
|
||||
|
||||
**Recommendation:**
|
||||
[If Critical] "Orphan requirements exist - every FR must trace back to a user need or business objective."
|
||||
[If Warning] "Traceability gaps identified - strengthen chains to ensure all requirements are justified."
|
||||
[If Pass] "Traceability chain is intact - all requirements trace to user needs or business objectives."
|
||||
```
|
||||
|
||||
### 5. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Traceability Validation Complete**
|
||||
|
||||
Total Issues: {count} ({severity})
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-07-implementation-leakage-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All traceability chains validated systematically
|
||||
- Orphan FRs identified with numbers
|
||||
- Broken chains documented
|
||||
- Traceability matrix built
|
||||
- Severity assessed correctly
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not validating all traceability chains
|
||||
- Missing orphan FR detection
|
||||
- Not building traceability matrix
|
||||
- Not reporting findings to validation report
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** Every requirement should trace to a user need or business objective. Orphan FRs indicate broken traceability that must be fixed.
|
||||
@@ -0,0 +1,205 @@
|
||||
---
|
||||
name: 'step-v-07-implementation-leakage-validation'
|
||||
description: 'Implementation Leakage Check - Ensure FRs and NFRs don\'t include implementation details'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-08-domain-compliance-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
---
|
||||
|
||||
# Step 7: Implementation Leakage Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Ensure Functional Requirements and Non-Functional Requirements don't include implementation details - they should specify WHAT, not HOW.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring analytical rigor and separation of concerns expertise
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on implementation leakage detection
|
||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
||||
- 💬 Approach: Systematic scanning for technology and implementation terms
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Scan FRs and NFRs for implementation terms
|
||||
- 💾 Distinguish capability-relevant vs leakage
|
||||
- 📖 Append findings to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file, validation report
|
||||
- Focus: Implementation leakage detection only
|
||||
- Limits: Don't validate other aspects, don't pause for user input
|
||||
- Dependencies: Steps 2-6 completed - initial validations done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Attempt Sub-Process Validation
|
||||
|
||||
**Try to use Task tool to spawn a subprocess:**
|
||||
|
||||
"Perform implementation leakage validation on this PRD:
|
||||
|
||||
**Scan for:**
|
||||
1. Technology names (React, Vue, Angular, PostgreSQL, MongoDB, AWS, GCP, Azure, Docker, Kubernetes, etc.)
|
||||
2. Library names (Redux, axios, lodash, Express, Django, Rails, Spring, etc.)
|
||||
3. Data structures (JSON, XML, CSV) unless relevant to capability
|
||||
4. Architecture patterns (MVC, microservices, serverless) unless business requirement
|
||||
5. Protocol names (HTTP, REST, GraphQL, WebSockets) - check if capability-relevant
|
||||
|
||||
**For each term found:**
|
||||
- Is this capability-relevant? (e.g., 'API consumers can access...' - API is capability)
|
||||
- Or is this implementation detail? (e.g., 'React component for...' - implementation)
|
||||
|
||||
Document violations with line numbers and explanation.
|
||||
|
||||
Return structured findings with leakage counts and examples."
|
||||
|
||||
### 2. Graceful Degradation (if Task tool unavailable)
|
||||
|
||||
If Task tool unavailable, perform analysis directly:
|
||||
|
||||
**Implementation leakage terms to scan for:**
|
||||
|
||||
**Frontend Frameworks:**
|
||||
React, Vue, Angular, Svelte, Solid, Next.js, Nuxt, etc.
|
||||
|
||||
**Backend Frameworks:**
|
||||
Express, Django, Rails, Spring, Laravel, FastAPI, etc.
|
||||
|
||||
**Databases:**
|
||||
PostgreSQL, MySQL, MongoDB, Redis, DynamoDB, Cassandra, etc.
|
||||
|
||||
**Cloud Platforms:**
|
||||
AWS, GCP, Azure, Cloudflare, Vercel, Netlify, etc.
|
||||
|
||||
**Infrastructure:**
|
||||
Docker, Kubernetes, Terraform, Ansible, etc.
|
||||
|
||||
**Libraries:**
|
||||
Redux, Zustand, axios, fetch, lodash, jQuery, etc.
|
||||
|
||||
**Data Formats:**
|
||||
JSON, XML, YAML, CSV (unless capability-relevant)
|
||||
|
||||
**For each term found in FRs/NFRs:**
|
||||
- Determine if it's capability-relevant or implementation leakage
|
||||
- Example: "API consumers can access data via REST endpoints" - API/REST is capability
|
||||
- Example: "React components fetch data using Redux" - implementation leakage
|
||||
|
||||
**Count violations and note line numbers**
|
||||
|
||||
### 3. Tally Implementation Leakage
|
||||
|
||||
**By category:**
|
||||
- Frontend framework leakage: count
|
||||
- Backend framework leakage: count
|
||||
- Database leakage: count
|
||||
- Cloud platform leakage: count
|
||||
- Infrastructure leakage: count
|
||||
- Library leakage: count
|
||||
- Other implementation details: count
|
||||
|
||||
**Total implementation leakage violations:** sum
|
||||
|
||||
### 4. Report Implementation Leakage Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Implementation Leakage Validation
|
||||
|
||||
### Leakage by Category
|
||||
|
||||
**Frontend Frameworks:** {count} violations
|
||||
{If violations, list examples with line numbers}
|
||||
|
||||
**Backend Frameworks:** {count} violations
|
||||
{If violations, list examples with line numbers}
|
||||
|
||||
**Databases:** {count} violations
|
||||
{If violations, list examples with line numbers}
|
||||
|
||||
**Cloud Platforms:** {count} violations
|
||||
{If violations, list examples with line numbers}
|
||||
|
||||
**Infrastructure:** {count} violations
|
||||
{If violations, list examples with line numbers}
|
||||
|
||||
**Libraries:** {count} violations
|
||||
{If violations, list examples with line numbers}
|
||||
|
||||
**Other Implementation Details:** {count} violations
|
||||
{If violations, list examples with line numbers}
|
||||
|
||||
### Summary
|
||||
|
||||
**Total Implementation Leakage Violations:** {total}
|
||||
|
||||
**Severity:** [Critical if >5 violations, Warning if 2-5, Pass if <2]
|
||||
|
||||
**Recommendation:**
|
||||
[If Critical] "Extensive implementation leakage found. Requirements specify HOW instead of WHAT. Remove all implementation details - these belong in architecture, not PRD."
|
||||
[If Warning] "Some implementation leakage detected. Review violations and remove implementation details from requirements."
|
||||
[If Pass] "No significant implementation leakage found. Requirements properly specify WHAT without HOW."
|
||||
|
||||
**Note:** API consumers, GraphQL (when required), and other capability-relevant terms are acceptable when they describe WHAT the system must do, not HOW to build it.
|
||||
```
|
||||
|
||||
### 5. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Implementation Leakage Validation Complete**
|
||||
|
||||
Total Violations: {count} ({severity})
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-08-domain-compliance-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Scanned FRs and NFRs for all implementation term categories
|
||||
- Distinguished capability-relevant from implementation leakage
|
||||
- Violations documented with line numbers and explanations
|
||||
- Severity assessed correctly
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not scanning all implementation term categories
|
||||
- Not distinguishing capability-relevant from leakage
|
||||
- Missing line numbers for violations
|
||||
- Not reporting findings to validation report
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** Requirements specify WHAT, not HOW. Implementation details belong in architecture documents, not PRDs.
|
||||
@@ -0,0 +1,243 @@
|
||||
---
|
||||
name: 'step-v-08-domain-compliance-validation'
|
||||
description: 'Domain Compliance Validation - Validate domain-specific requirements are present for high-complexity domains'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-09-project-type-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
prdFrontmatter: '{prd_frontmatter}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
domainComplexityData: '../data/domain-complexity.csv'
|
||||
---
|
||||
|
||||
# Step 8: Domain Compliance Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate domain-specific requirements are present for high-complexity domains (Healthcare, Fintech, GovTech, etc.), ensuring regulatory and compliance requirements are properly documented.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring domain expertise and compliance knowledge
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on domain-specific compliance requirements
|
||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
||||
- 💬 Approach: Conditional validation based on domain classification
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Check classification.domain from PRD frontmatter
|
||||
- 💬 If low complexity (general): Skip detailed checks
|
||||
- 🎯 If high complexity: Validate required special sections
|
||||
- 💾 Append compliance findings to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file with frontmatter classification, validation report
|
||||
- Focus: Domain compliance only (conditional on domain complexity)
|
||||
- Limits: Don't validate other aspects, conditional execution
|
||||
- Dependencies: Steps 2-7 completed - format and requirements validation done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Domain Complexity Data
|
||||
|
||||
Load and read the complete file at:
|
||||
`{domainComplexityData}` (../data/domain-complexity.csv)
|
||||
|
||||
This CSV contains:
|
||||
- Domain classifications and complexity levels (high/medium/low)
|
||||
- Required special sections for each domain
|
||||
- Key concerns and requirements for regulated industries
|
||||
|
||||
Internalize this data - it drives which domains require special compliance sections.
|
||||
|
||||
### 2. Extract Domain Classification
|
||||
|
||||
From PRD frontmatter, extract:
|
||||
- `classification.domain` - what domain is this PRD for?
|
||||
|
||||
**If no domain classification found:**
|
||||
Treat as "general" (low complexity) and proceed to step 4
|
||||
|
||||
### 2. Determine Domain Complexity
|
||||
|
||||
**Low complexity domains (skip detailed checks):**
|
||||
- General
|
||||
- Consumer apps (standard e-commerce, social, productivity)
|
||||
- Content websites
|
||||
- Business tools (standard)
|
||||
|
||||
**High complexity domains (require special sections):**
|
||||
- Healthcare / Healthtech
|
||||
- Fintech / Financial services
|
||||
- GovTech / Public sector
|
||||
- EdTech (educational records, accredited courses)
|
||||
- Legal tech
|
||||
- Other regulated domains
|
||||
|
||||
### 3. For High-Complexity Domains: Validate Required Special Sections
|
||||
|
||||
**Attempt subprocess validation:**
|
||||
|
||||
"Perform domain compliance validation for {domain}:
|
||||
|
||||
Based on {domain} requirements, check PRD for:
|
||||
|
||||
**Healthcare:**
|
||||
- Clinical Requirements section
|
||||
- Regulatory Pathway (FDA, HIPAA, etc.)
|
||||
- Safety Measures
|
||||
- HIPAA Compliance (data privacy, security)
|
||||
- Patient safety considerations
|
||||
|
||||
**Fintech:**
|
||||
- Compliance Matrix (SOC2, PCI-DSS, GDPR, etc.)
|
||||
- Security Architecture
|
||||
- Audit Requirements
|
||||
- Fraud Prevention measures
|
||||
- Financial transaction handling
|
||||
|
||||
**GovTech:**
|
||||
- Accessibility Standards (WCAG 2.1 AA, Section 508)
|
||||
- Procurement Compliance
|
||||
- Security Clearance requirements
|
||||
- Data residency requirements
|
||||
|
||||
**Other regulated domains:**
|
||||
- Check for domain-specific regulatory sections
|
||||
- Compliance requirements
|
||||
- Special considerations
|
||||
|
||||
For each required section:
|
||||
- Is it present in PRD?
|
||||
- Is it adequately documented?
|
||||
- Note any gaps
|
||||
|
||||
Return compliance matrix with presence/adequacy assessment."
|
||||
|
||||
**Graceful degradation (if no Task tool):**
|
||||
- Manually check for required sections based on domain
|
||||
- List present sections and missing sections
|
||||
- Assess adequacy of documentation
|
||||
|
||||
### 5. For Low-Complexity Domains: Skip Detailed Checks
|
||||
|
||||
Append to validation report:
|
||||
```markdown
|
||||
## Domain Compliance Validation
|
||||
|
||||
**Domain:** {domain}
|
||||
**Complexity:** Low (general/standard)
|
||||
**Assessment:** N/A - No special domain compliance requirements
|
||||
|
||||
**Note:** This PRD is for a standard domain without regulatory compliance requirements.
|
||||
```
|
||||
|
||||
Display: "**Domain Compliance Validation Skipped**
|
||||
|
||||
Domain: {domain} (low complexity)
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile}
|
||||
|
||||
### 6. Report Compliance Findings (High-Complexity Domains)
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Domain Compliance Validation
|
||||
|
||||
**Domain:** {domain}
|
||||
**Complexity:** High (regulated)
|
||||
|
||||
### Required Special Sections
|
||||
|
||||
**{Section 1 Name}:** [Present/Missing/Adequate]
|
||||
{If missing or inadequate: Note specific gaps}
|
||||
|
||||
**{Section 2 Name}:** [Present/Missing/Adequate]
|
||||
{If missing or inadequate: Note specific gaps}
|
||||
|
||||
[Continue for all required sections]
|
||||
|
||||
### Compliance Matrix
|
||||
|
||||
| Requirement | Status | Notes |
|
||||
|-------------|--------|-------|
|
||||
| {Requirement 1} | [Met/Partial/Missing] | {Notes} |
|
||||
| {Requirement 2} | [Met/Partial/Missing] | {Notes} |
|
||||
[... continue for all requirements]
|
||||
|
||||
### Summary
|
||||
|
||||
**Required Sections Present:** {count}/{total}
|
||||
**Compliance Gaps:** {count}
|
||||
|
||||
**Severity:** [Critical if missing regulatory sections, Warning if incomplete, Pass if complete]
|
||||
|
||||
**Recommendation:**
|
||||
[If Critical] "PRD is missing required domain-specific compliance sections. These are essential for {domain} products."
|
||||
[If Warning] "Some domain compliance sections are incomplete. Strengthen documentation for full compliance."
|
||||
[If Pass] "All required domain compliance sections are present and adequately documented."
|
||||
```
|
||||
|
||||
### 7. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Domain Compliance Validation Complete**
|
||||
|
||||
Domain: {domain} ({complexity})
|
||||
Compliance Status: {status}
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-09-project-type-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Domain classification extracted correctly
|
||||
- Complexity assessed appropriately
|
||||
- Low complexity domains: Skipped with clear "N/A" documentation
|
||||
- High complexity domains: All required sections checked
|
||||
- Compliance matrix built with status for each requirement
|
||||
- Severity assessed correctly
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking domain classification before proceeding
|
||||
- Performing detailed checks on low complexity domains
|
||||
- For high complexity: missing required section checks
|
||||
- Not building compliance matrix
|
||||
- Not reporting findings to validation report
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** Domain compliance is conditional. High-complexity domains require special sections - low complexity domains skip these checks.
|
||||
@@ -0,0 +1,263 @@
|
||||
---
|
||||
name: 'step-v-09-project-type-validation'
|
||||
description: 'Project-Type Compliance Validation - Validate project-type specific requirements are properly documented'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-10-smart-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
prdFrontmatter: '{prd_frontmatter}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
projectTypesData: '../data/project-types.csv'
|
||||
---
|
||||
|
||||
# Step 9: Project-Type Compliance Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate project-type specific requirements are properly documented - different project types (api_backend, web_app, mobile_app, etc.) have different required and excluded sections.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring project type expertise and architectural knowledge
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on project-type compliance
|
||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
||||
- 💬 Approach: Validate required sections present, excluded sections absent
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Check classification.projectType from PRD frontmatter
|
||||
- 🎯 Validate required sections for that project type are present
|
||||
- 🎯 Validate excluded sections for that project type are absent
|
||||
- 💾 Append compliance findings to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file with frontmatter classification, validation report
|
||||
- Focus: Project-type compliance only
|
||||
- Limits: Don't validate other aspects, don't pause for user input
|
||||
- Dependencies: Steps 2-8 completed - domain and requirements validation done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Project Types Data
|
||||
|
||||
Load and read the complete file at:
|
||||
`{projectTypesData}` (../data/project-types.csv)
|
||||
|
||||
This CSV contains:
|
||||
- Detection signals for each project type
|
||||
- Required sections for each project type
|
||||
- Skip/excluded sections for each project type
|
||||
- Innovation signals
|
||||
|
||||
Internalize this data - it drives what sections must be present or absent for each project type.
|
||||
|
||||
### 2. Extract Project Type Classification
|
||||
|
||||
From PRD frontmatter, extract:
|
||||
- `classification.projectType` - what type of project is this?
|
||||
|
||||
**Common project types:**
|
||||
- api_backend
|
||||
- web_app
|
||||
- mobile_app
|
||||
- desktop_app
|
||||
- data_pipeline
|
||||
- ml_system
|
||||
- library_sdk
|
||||
- infrastructure
|
||||
- other
|
||||
|
||||
**If no projectType classification found:**
|
||||
Assume "web_app" (most common) and note in findings
|
||||
|
||||
### 3. Determine Required and Excluded Sections from CSV Data
|
||||
|
||||
**From loaded project-types.csv data, for this project type:**
|
||||
|
||||
**Required sections:** (from required_sections column)
|
||||
These MUST be present in the PRD
|
||||
|
||||
**Skip sections:** (from skip_sections column)
|
||||
These MUST NOT be present in the PRD
|
||||
|
||||
**Example mappings from CSV:**
|
||||
- api_backend: Required=[endpoint_specs, auth_model, data_schemas], Skip=[ux_ui, visual_design]
|
||||
- mobile_app: Required=[platform_reqs, device_permissions, offline_mode], Skip=[desktop_features, cli_commands]
|
||||
- cli_tool: Required=[command_structure, output_formats, config_schema], Skip=[visual_design, ux_principles, touch_interactions]
|
||||
- etc.
|
||||
|
||||
### 4. Validate Against CSV-Based Requirements
|
||||
|
||||
**Based on project type, determine:**
|
||||
|
||||
**api_backend:**
|
||||
- Required: Endpoint Specs, Auth Model, Data Schemas, API Versioning
|
||||
- Excluded: UX/UI sections, mobile-specific sections
|
||||
|
||||
**web_app:**
|
||||
- Required: User Journeys, UX/UI Requirements, Responsive Design
|
||||
- Excluded: None typically
|
||||
|
||||
**mobile_app:**
|
||||
- Required: Mobile UX, Platform specifics (iOS/Android), Offline mode
|
||||
- Excluded: Desktop-specific sections
|
||||
|
||||
**desktop_app:**
|
||||
- Required: Desktop UX, Platform specifics (Windows/Mac/Linux)
|
||||
- Excluded: Mobile-specific sections
|
||||
|
||||
**data_pipeline:**
|
||||
- Required: Data Sources, Data Transformation, Data Sinks, Error Handling
|
||||
- Excluded: UX/UI sections
|
||||
|
||||
**ml_system:**
|
||||
- Required: Model Requirements, Training Data, Inference Requirements, Model Performance
|
||||
- Excluded: UX/UI sections (unless ML UI)
|
||||
|
||||
**library_sdk:**
|
||||
- Required: API Surface, Usage Examples, Integration Guide
|
||||
- Excluded: UX/UI sections, deployment sections
|
||||
|
||||
**infrastructure:**
|
||||
- Required: Infrastructure Components, Deployment, Monitoring, Scaling
|
||||
- Excluded: Feature requirements (this is infrastructure, not product)
|
||||
|
||||
### 4. Attempt Sub-Process Validation
|
||||
|
||||
"Perform project-type compliance validation for {projectType}:
|
||||
|
||||
**Check that required sections are present:**
|
||||
{List required sections for this project type}
|
||||
For each: Is it present in PRD? Is it adequately documented?
|
||||
|
||||
**Check that excluded sections are absent:**
|
||||
{List excluded sections for this project type}
|
||||
For each: Is it absent from PRD? (Should not be present)
|
||||
|
||||
Build compliance table showing:
|
||||
- Required sections: [Present/Missing/Incomplete]
|
||||
- Excluded sections: [Absent/Present] (Present = violation)
|
||||
|
||||
Return compliance table with findings."
|
||||
|
||||
**Graceful degradation (if no Task tool):**
|
||||
- Manually check PRD for required sections
|
||||
- Manually check PRD for excluded sections
|
||||
- Build compliance table
|
||||
|
||||
### 5. Build Compliance Table
|
||||
|
||||
**Required sections check:**
|
||||
- For each required section: Present / Missing / Incomplete
|
||||
- Count: Required sections present vs total required
|
||||
|
||||
**Excluded sections check:**
|
||||
- For each excluded section: Absent / Present (violation)
|
||||
- Count: Excluded sections present (violations)
|
||||
|
||||
**Total compliance score:**
|
||||
- Required: {present}/{total}
|
||||
- Excluded violations: {count}
|
||||
|
||||
### 6. Report Project-Type Compliance Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Project-Type Compliance Validation
|
||||
|
||||
**Project Type:** {projectType}
|
||||
|
||||
### Required Sections
|
||||
|
||||
**{Section 1}:** [Present/Missing/Incomplete]
|
||||
{If missing or incomplete: Note specific gaps}
|
||||
|
||||
**{Section 2}:** [Present/Missing/Incomplete]
|
||||
{If missing or incomplete: Note specific gaps}
|
||||
|
||||
[Continue for all required sections]
|
||||
|
||||
### Excluded Sections (Should Not Be Present)
|
||||
|
||||
**{Section 1}:** [Absent/Present] ✓
|
||||
{If present: This section should not be present for {projectType}}
|
||||
|
||||
**{Section 2}:** [Absent/Present] ✓
|
||||
{If present: This section should not be present for {projectType}}
|
||||
|
||||
[Continue for all excluded sections]
|
||||
|
||||
### Compliance Summary
|
||||
|
||||
**Required Sections:** {present}/{total} present
|
||||
**Excluded Sections Present:** {violations} (should be 0)
|
||||
**Compliance Score:** {percentage}%
|
||||
|
||||
**Severity:** [Critical if required sections missing, Warning if incomplete, Pass if complete]
|
||||
|
||||
**Recommendation:**
|
||||
[If Critical] "PRD is missing required sections for {projectType}. Add missing sections to properly specify this type of project."
|
||||
[If Warning] "Some required sections for {projectType} are incomplete. Strengthen documentation."
|
||||
[If Pass] "All required sections for {projectType} are present. No excluded sections found."
|
||||
```
|
||||
|
||||
### 7. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Project-Type Compliance Validation Complete**
|
||||
|
||||
Project Type: {projectType}
|
||||
Compliance: {score}%
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-10-smart-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Project type extracted correctly (or default assumed)
|
||||
- Required sections validated for presence and completeness
|
||||
- Excluded sections validated for absence
|
||||
- Compliance table built with status for all sections
|
||||
- Severity assessed correctly
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking project type before proceeding
|
||||
- Missing required section checks
|
||||
- Missing excluded section checks
|
||||
- Not building compliance table
|
||||
- Not reporting findings to validation report
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** Different project types have different requirements. API PRDs don't need UX sections - validate accordingly.
|
||||
@@ -0,0 +1,209 @@
|
||||
---
|
||||
name: 'step-v-10-smart-validation'
|
||||
description: 'SMART Requirements Validation - Validate Functional Requirements meet SMART quality criteria'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-11-holistic-quality-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
---
|
||||
|
||||
# Step 10: SMART Requirements Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate Functional Requirements meet SMART quality criteria (Specific, Measurable, Attainable, Relevant, Traceable), ensuring high-quality requirements.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring requirements engineering expertise and quality assessment
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on FR quality assessment using SMART framework
|
||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
||||
- 💬 Approach: Score each FR on SMART criteria (1-5 scale)
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Extract all FRs from PRD
|
||||
- 🎯 Score each FR on SMART criteria (Specific, Measurable, Attainable, Relevant, Traceable)
|
||||
- 💾 Flag FRs with score < 3 in any category
|
||||
- 📖 Append scoring table and suggestions to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: PRD file, validation report
|
||||
- Focus: FR quality assessment only using SMART framework
|
||||
- Limits: Don't validate NFRs or other aspects, don't pause for user input
|
||||
- Dependencies: Steps 2-9 completed - comprehensive validation checks done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Extract All Functional Requirements
|
||||
|
||||
From the PRD's Functional Requirements section, extract:
|
||||
- All FRs with their FR numbers (FR-001, FR-002, etc.)
|
||||
- Count total FRs
|
||||
|
||||
### 2. Attempt Sub-Process Validation
|
||||
|
||||
**Try to use Task tool to spawn a subprocess:**
|
||||
|
||||
"Perform SMART requirements validation on these Functional Requirements:
|
||||
|
||||
{List all FRs}
|
||||
|
||||
**For each FR, score on SMART criteria (1-5 scale):**
|
||||
|
||||
**Specific (1-5):**
|
||||
- 5: Clear, unambiguous, well-defined
|
||||
- 3: Somewhat clear but could be more specific
|
||||
- 1: Vague, ambiguous, unclear
|
||||
|
||||
**Measurable (1-5):**
|
||||
- 5: Quantifiable metrics, testable
|
||||
- 3: Partially measurable
|
||||
- 1: Not measurable, subjective
|
||||
|
||||
**Attainable (1-5):**
|
||||
- 5: Realistic, achievable with constraints
|
||||
- 3: Probably achievable but uncertain
|
||||
- 1: Unrealistic, technically infeasible
|
||||
|
||||
**Relevant (1-5):**
|
||||
- 5: Clearly aligned with user needs and business objectives
|
||||
- 3: Somewhat relevant but connection unclear
|
||||
- 1: Not relevant, doesn't align with goals
|
||||
|
||||
**Traceable (1-5):**
|
||||
- 5: Clearly traces to user journey or business objective
|
||||
- 3: Partially traceable
|
||||
- 1: Orphan requirement, no clear source
|
||||
|
||||
**For each FR with score < 3 in any category:**
|
||||
- Provide specific improvement suggestions
|
||||
|
||||
Return scoring table with all FR scores and improvement suggestions for low-scoring FRs."
|
||||
|
||||
**Graceful degradation (if no Task tool):**
|
||||
- Manually score each FR on SMART criteria
|
||||
- Note FRs with low scores
|
||||
- Provide improvement suggestions
|
||||
|
||||
### 3. Build Scoring Table
|
||||
|
||||
For each FR:
|
||||
- FR number
|
||||
- Specific score (1-5)
|
||||
- Measurable score (1-5)
|
||||
- Attainable score (1-5)
|
||||
- Relevant score (1-5)
|
||||
- Traceable score (1-5)
|
||||
- Average score
|
||||
- Flag if any category < 3
|
||||
|
||||
**Calculate overall FR quality:**
|
||||
- Percentage of FRs with all scores ≥ 3
|
||||
- Percentage of FRs with all scores ≥ 4
|
||||
- Average score across all FRs and categories
|
||||
|
||||
### 4. Report SMART Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## SMART Requirements Validation
|
||||
|
||||
**Total Functional Requirements:** {count}
|
||||
|
||||
### Scoring Summary
|
||||
|
||||
**All scores ≥ 3:** {percentage}% ({count}/{total})
|
||||
**All scores ≥ 4:** {percentage}% ({count}/{total})
|
||||
**Overall Average Score:** {average}/5.0
|
||||
|
||||
### Scoring Table
|
||||
|
||||
| FR # | Specific | Measurable | Attainable | Relevant | Traceable | Average | Flag |
|
||||
|------|----------|------------|------------|----------|-----------|--------|------|
|
||||
| FR-001 | {s1} | {m1} | {a1} | {r1} | {t1} | {avg1} | {X if any <3} |
|
||||
| FR-002 | {s2} | {m2} | {a2} | {r2} | {t2} | {avg2} | {X if any <3} |
|
||||
[Continue for all FRs]
|
||||
|
||||
**Legend:** 1=Poor, 3=Acceptable, 5=Excellent
|
||||
**Flag:** X = Score < 3 in one or more categories
|
||||
|
||||
### Improvement Suggestions
|
||||
|
||||
**Low-Scoring FRs:**
|
||||
|
||||
**FR-{number}:** {specific suggestion for improvement}
|
||||
[For each FR with score < 3 in any category]
|
||||
|
||||
### Overall Assessment
|
||||
|
||||
**Severity:** [Critical if >30% flagged FRs, Warning if 10-30%, Pass if <10%]
|
||||
|
||||
**Recommendation:**
|
||||
[If Critical] "Many FRs have quality issues. Revise flagged FRs using SMART framework to improve clarity and testability."
|
||||
[If Warning] "Some FRs would benefit from SMART refinement. Focus on flagged requirements above."
|
||||
[If Pass] "Functional Requirements demonstrate good SMART quality overall."
|
||||
```
|
||||
|
||||
### 5. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**SMART Requirements Validation Complete**
|
||||
|
||||
FR Quality: {percentage}% with acceptable scores ({severity})
|
||||
|
||||
**Proceeding to next validation check...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-11-holistic-quality-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All FRs extracted from PRD
|
||||
- Each FR scored on all 5 SMART criteria (1-5 scale)
|
||||
- FRs with scores < 3 flagged for improvement
|
||||
- Improvement suggestions provided for low-scoring FRs
|
||||
- Scoring table built with all FR scores
|
||||
- Overall quality assessment calculated
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not scoring all FRs on all SMART criteria
|
||||
- Missing improvement suggestions for low-scoring FRs
|
||||
- Not building scoring table
|
||||
- Not calculating overall quality metrics
|
||||
- Not reporting findings to validation report
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** FRs should be high-quality, not just present. SMART framework provides objective quality measure.
|
||||
@@ -0,0 +1,264 @@
|
||||
---
|
||||
name: 'step-v-11-holistic-quality-validation'
|
||||
description: 'Holistic Quality Assessment - Assess PRD as cohesive, compelling document - is it a good PRD?'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-12-completeness-validation.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
---
|
||||
|
||||
# Step 11: Holistic Quality Assessment
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Assess the PRD as a cohesive, compelling document - evaluating document flow, dual audience effectiveness (humans and LLMs), BMAD PRD principles compliance, and overall quality rating.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring analytical rigor and document quality expertise
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
- ✅ Uses Advanced Elicitation for multi-perspective evaluation
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on holistic document quality assessment
|
||||
- 🚫 FORBIDDEN to validate individual components (done in previous steps)
|
||||
- 💬 Approach: Multi-perspective evaluation using Advanced Elicitation
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Use Advanced Elicitation for multi-perspective assessment
|
||||
- 🎯 Evaluate document flow, dual audience, BMAD principles
|
||||
- 💾 Append comprehensive assessment to validation report
|
||||
- 📖 Display "Proceeding to next check..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Complete PRD file, validation report with findings from steps 1-10
|
||||
- Focus: Holistic quality - the WHOLE document
|
||||
- Limits: Don't re-validate individual components, don't pause for user input
|
||||
- Dependencies: Steps 1-10 completed - all systematic checks done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Attempt Sub-Process with Advanced Elicitation
|
||||
|
||||
**Try to use Task tool to spawn a subprocess using Advanced Elicitation:**
|
||||
|
||||
"Perform holistic quality assessment on this PRD using multi-perspective evaluation:
|
||||
|
||||
**Load and execute Advanced Elicitation workflow:**
|
||||
{advancedElicitationTask}
|
||||
|
||||
**Evaluate the PRD from these perspectives:**
|
||||
|
||||
**1. Document Flow & Coherence:**
|
||||
- Read entire PRD
|
||||
- Evaluate narrative flow - does it tell a cohesive story?
|
||||
- Check transitions between sections
|
||||
- Assess consistency - is it coherent throughout?
|
||||
- Evaluate readability - is it clear and well-organized?
|
||||
|
||||
**2. Dual Audience Effectiveness:**
|
||||
|
||||
**For Humans:**
|
||||
- Executive-friendly: Can executives understand vision and goals quickly?
|
||||
- Developer clarity: Do developers have clear requirements to build from?
|
||||
- Designer clarity: Do designers understand user needs and flows?
|
||||
- Stakeholder decision-making: Can stakeholders make informed decisions?
|
||||
|
||||
**For LLMs:**
|
||||
- Machine-readable structure: Is the PRD structured for LLM consumption?
|
||||
- UX readiness: Can an LLM generate UX designs from this?
|
||||
- Architecture readiness: Can an LLM generate architecture from this?
|
||||
- Epic/Story readiness: Can an LLM break down into epics and stories?
|
||||
|
||||
**3. BMAD PRD Principles Compliance:**
|
||||
- Information density: Every sentence carries weight?
|
||||
- Measurability: Requirements testable?
|
||||
- Traceability: Requirements trace to sources?
|
||||
- Domain awareness: Domain-specific considerations included?
|
||||
- Zero anti-patterns: No filler or wordiness?
|
||||
- Dual audience: Works for both humans and LLMs?
|
||||
- Markdown format: Proper structure and formatting?
|
||||
|
||||
**4. Overall Quality Rating:**
|
||||
Rate the PRD on 5-point scale:
|
||||
- Excellent (5/5): Exemplary, ready for production use
|
||||
- Good (4/5): Strong with minor improvements needed
|
||||
- Adequate (3/5): Acceptable but needs refinement
|
||||
- Needs Work (2/5): Significant gaps or issues
|
||||
- Problematic (1/5): Major flaws, needs substantial revision
|
||||
|
||||
**5. Top 3 Improvements:**
|
||||
Identify the 3 most impactful improvements to make this a great PRD
|
||||
|
||||
Return comprehensive assessment with all perspectives, rating, and top 3 improvements."
|
||||
|
||||
**Graceful degradation (if no Task tool or Advanced Elicitation unavailable):**
|
||||
- Perform holistic assessment directly in current context
|
||||
- Read complete PRD
|
||||
- Evaluate document flow, coherence, transitions
|
||||
- Assess dual audience effectiveness
|
||||
- Check BMAD principles compliance
|
||||
- Assign overall quality rating
|
||||
- Identify top 3 improvements
|
||||
|
||||
### 2. Synthesize Assessment
|
||||
|
||||
**Compile findings from multi-perspective evaluation:**
|
||||
|
||||
**Document Flow & Coherence:**
|
||||
- Overall assessment: [Excellent/Good/Adequate/Needs Work/Problematic]
|
||||
- Key strengths: [list]
|
||||
- Key weaknesses: [list]
|
||||
|
||||
**Dual Audience Effectiveness:**
|
||||
- For Humans: [assessment]
|
||||
- For LLMs: [assessment]
|
||||
- Overall dual audience score: [1-5]
|
||||
|
||||
**BMAD Principles Compliance:**
|
||||
- Principles met: [count]/7
|
||||
- Principles with issues: [list]
|
||||
|
||||
**Overall Quality Rating:** [1-5 with label]
|
||||
|
||||
**Top 3 Improvements:**
|
||||
1. [Improvement 1]
|
||||
2. [Improvement 2]
|
||||
3. [Improvement 3]
|
||||
|
||||
### 3. Report Holistic Quality Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Holistic Quality Assessment
|
||||
|
||||
### Document Flow & Coherence
|
||||
|
||||
**Assessment:** [Excellent/Good/Adequate/Needs Work/Problematic]
|
||||
|
||||
**Strengths:**
|
||||
{List key strengths}
|
||||
|
||||
**Areas for Improvement:**
|
||||
{List key weaknesses}
|
||||
|
||||
### Dual Audience Effectiveness
|
||||
|
||||
**For Humans:**
|
||||
- Executive-friendly: [assessment]
|
||||
- Developer clarity: [assessment]
|
||||
- Designer clarity: [assessment]
|
||||
- Stakeholder decision-making: [assessment]
|
||||
|
||||
**For LLMs:**
|
||||
- Machine-readable structure: [assessment]
|
||||
- UX readiness: [assessment]
|
||||
- Architecture readiness: [assessment]
|
||||
- Epic/Story readiness: [assessment]
|
||||
|
||||
**Dual Audience Score:** {score}/5
|
||||
|
||||
### BMAD PRD Principles Compliance
|
||||
|
||||
| Principle | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| Information Density | [Met/Partial/Not Met] | {notes} |
|
||||
| Measurability | [Met/Partial/Not Met] | {notes} |
|
||||
| Traceability | [Met/Partial/Not Met] | {notes} |
|
||||
| Domain Awareness | [Met/Partial/Not Met] | {notes} |
|
||||
| Zero Anti-Patterns | [Met/Partial/Not Met] | {notes} |
|
||||
| Dual Audience | [Met/Partial/Not Met] | {notes} |
|
||||
| Markdown Format | [Met/Partial/Not Met] | {notes} |
|
||||
|
||||
**Principles Met:** {count}/7
|
||||
|
||||
### Overall Quality Rating
|
||||
|
||||
**Rating:** {rating}/5 - {label}
|
||||
|
||||
**Scale:**
|
||||
- 5/5 - Excellent: Exemplary, ready for production use
|
||||
- 4/5 - Good: Strong with minor improvements needed
|
||||
- 3/5 - Adequate: Acceptable but needs refinement
|
||||
- 2/5 - Needs Work: Significant gaps or issues
|
||||
- 1/5 - Problematic: Major flaws, needs substantial revision
|
||||
|
||||
### Top 3 Improvements
|
||||
|
||||
1. **{Improvement 1}**
|
||||
{Brief explanation of why and how}
|
||||
|
||||
2. **{Improvement 2}**
|
||||
{Brief explanation of why and how}
|
||||
|
||||
3. **{Improvement 3}**
|
||||
{Brief explanation of why and how}
|
||||
|
||||
### Summary
|
||||
|
||||
**This PRD is:** {one-sentence overall assessment}
|
||||
|
||||
**To make it great:** Focus on the top 3 improvements above.
|
||||
```
|
||||
|
||||
### 4. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Holistic Quality Assessment Complete**
|
||||
|
||||
Overall Rating: {rating}/5 - {label}
|
||||
|
||||
**Proceeding to final validation checks...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-12-completeness-validation.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Advanced Elicitation used for multi-perspective evaluation (or graceful degradation)
|
||||
- Document flow & coherence assessed
|
||||
- Dual audience effectiveness evaluated (humans and LLMs)
|
||||
- BMAD PRD principles compliance checked
|
||||
- Overall quality rating assigned (1-5 scale)
|
||||
- Top 3 improvements identified
|
||||
- Comprehensive assessment reported to validation report
|
||||
- Auto-proceeds to next validation step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not using Advanced Elicitation for multi-perspective evaluation
|
||||
- Missing document flow assessment
|
||||
- Missing dual audience evaluation
|
||||
- Not checking all BMAD principles
|
||||
- Not assigning overall quality rating
|
||||
- Missing top 3 improvements
|
||||
- Not reporting comprehensive assessment to validation report
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** This evaluates the WHOLE document, not just components. Answers "Is this a good PRD?" and "What would make it great?"
|
||||
@@ -0,0 +1,242 @@
|
||||
---
|
||||
name: 'step-v-12-completeness-validation'
|
||||
description: 'Completeness Check - Final comprehensive completeness check before report generation'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
nextStepFile: './step-v-13-report-complete.md'
|
||||
prdFile: '{prd_file_path}'
|
||||
prdFrontmatter: '{prd_frontmatter}'
|
||||
validationReportPath: '{validation_report_path}'
|
||||
---
|
||||
|
||||
# Step 12: Completeness Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Final comprehensive completeness check - validate no template variables remain, each section has required content, section-specific completeness, and frontmatter is properly populated.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
||||
- ✅ You bring attention to detail and completeness verification
|
||||
- ✅ This step runs autonomously - no user input needed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on completeness verification
|
||||
- 🚫 FORBIDDEN to validate quality (done in step 11) or other aspects
|
||||
- 💬 Approach: Systematic checklist-style verification
|
||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Check template completeness (no variables remaining)
|
||||
- 🎯 Validate content completeness (each section has required content)
|
||||
- 🎯 Validate section-specific completeness
|
||||
- 🎯 Validate frontmatter completeness
|
||||
- 💾 Append completeness matrix to validation report
|
||||
- 📖 Display "Proceeding to final step..." and load next step
|
||||
- 🚫 FORBIDDEN to pause or request user input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Complete PRD file, frontmatter, validation report
|
||||
- Focus: Completeness verification only (final gate)
|
||||
- Limits: Don't assess quality, don't pause for user input
|
||||
- Dependencies: Steps 1-11 completed - all validation checks done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Attempt Sub-Process Validation
|
||||
|
||||
**Try to use Task tool to spawn a subprocess:**
|
||||
|
||||
"Perform completeness validation on this PRD - final gate check:
|
||||
|
||||
**1. Template Completeness:**
|
||||
- Scan PRD for any remaining template variables
|
||||
- Look for: {variable}, {{variable}}, {placeholder}, [placeholder], etc.
|
||||
- List any found with line numbers
|
||||
|
||||
**2. Content Completeness:**
|
||||
- Executive Summary: Has vision statement? ({key content})
|
||||
- Success Criteria: All criteria measurable? ({metrics present})
|
||||
- Product Scope: In-scope and out-of-scope defined? ({both present})
|
||||
- User Journeys: User types identified? ({users listed})
|
||||
- Functional Requirements: FRs listed with proper format? ({FRs present})
|
||||
- Non-Functional Requirements: NFRs with metrics? ({NFRs present})
|
||||
|
||||
For each section: Is required content present? (Yes/No/Partial)
|
||||
|
||||
**3. Section-Specific Completeness:**
|
||||
- Success Criteria: Each has specific measurement method?
|
||||
- User Journeys: Cover all user types?
|
||||
- Functional Requirements: Cover MVP scope?
|
||||
- Non-Functional Requirements: Each has specific criteria?
|
||||
|
||||
**4. Frontmatter Completeness:**
|
||||
- stepsCompleted: Populated?
|
||||
- classification: Present (domain, projectType)?
|
||||
- inputDocuments: Tracked?
|
||||
- date: Present?
|
||||
|
||||
Return completeness matrix with status for each check."
|
||||
|
||||
**Graceful degradation (if no Task tool):**
|
||||
- Manually scan for template variables
|
||||
- Manually check each section for required content
|
||||
- Manually verify frontmatter fields
|
||||
- Build completeness matrix
|
||||
|
||||
### 2. Build Completeness Matrix
|
||||
|
||||
**Template Completeness:**
|
||||
- Template variables found: count
|
||||
- List if any found
|
||||
|
||||
**Content Completeness by Section:**
|
||||
- Executive Summary: Complete / Incomplete / Missing
|
||||
- Success Criteria: Complete / Incomplete / Missing
|
||||
- Product Scope: Complete / Incomplete / Missing
|
||||
- User Journeys: Complete / Incomplete / Missing
|
||||
- Functional Requirements: Complete / Incomplete / Missing
|
||||
- Non-Functional Requirements: Complete / Incomplete / Missing
|
||||
- Other sections: [List completeness]
|
||||
|
||||
**Section-Specific Completeness:**
|
||||
- Success criteria measurable: All / Some / None
|
||||
- Journeys cover all users: Yes / Partial / No
|
||||
- FRs cover MVP scope: Yes / Partial / No
|
||||
- NFRs have specific criteria: All / Some / None
|
||||
|
||||
**Frontmatter Completeness:**
|
||||
- stepsCompleted: Present / Missing
|
||||
- classification: Present / Missing
|
||||
- inputDocuments: Present / Missing
|
||||
- date: Present / Missing
|
||||
|
||||
**Overall completeness:**
|
||||
- Sections complete: X/Y
|
||||
- Critical gaps: [list if any]
|
||||
|
||||
### 3. Report Completeness Findings to Validation Report
|
||||
|
||||
Append to validation report:
|
||||
|
||||
```markdown
|
||||
## Completeness Validation
|
||||
|
||||
### Template Completeness
|
||||
|
||||
**Template Variables Found:** {count}
|
||||
{If count > 0, list variables with line numbers}
|
||||
{If count = 0, note: No template variables remaining ✓}
|
||||
|
||||
### Content Completeness by Section
|
||||
|
||||
**Executive Summary:** [Complete/Incomplete/Missing]
|
||||
{If incomplete or missing, note specific gaps}
|
||||
|
||||
**Success Criteria:** [Complete/Incomplete/Missing]
|
||||
{If incomplete or missing, note specific gaps}
|
||||
|
||||
**Product Scope:** [Complete/Incomplete/Missing]
|
||||
{If incomplete or missing, note specific gaps}
|
||||
|
||||
**User Journeys:** [Complete/Incomplete/Missing]
|
||||
{If incomplete or missing, note specific gaps}
|
||||
|
||||
**Functional Requirements:** [Complete/Incomplete/Missing]
|
||||
{If incomplete or missing, note specific gaps}
|
||||
|
||||
**Non-Functional Requirements:** [Complete/Incomplete/Missing]
|
||||
{If incomplete or missing, note specific gaps}
|
||||
|
||||
### Section-Specific Completeness
|
||||
|
||||
**Success Criteria Measurability:** [All/Some/None] measurable
|
||||
{If Some or None, note which criteria lack metrics}
|
||||
|
||||
**User Journeys Coverage:** [Yes/Partial/No] - covers all user types
|
||||
{If Partial or No, note missing user types}
|
||||
|
||||
**FRs Cover MVP Scope:** [Yes/Partial/No]
|
||||
{If Partial or No, note scope gaps}
|
||||
|
||||
**NFRs Have Specific Criteria:** [All/Some/None]
|
||||
{If Some or None, note which NFRs lack specificity}
|
||||
|
||||
### Frontmatter Completeness
|
||||
|
||||
**stepsCompleted:** [Present/Missing]
|
||||
**classification:** [Present/Missing]
|
||||
**inputDocuments:** [Present/Missing]
|
||||
**date:** [Present/Missing]
|
||||
|
||||
**Frontmatter Completeness:** {complete_fields}/4
|
||||
|
||||
### Completeness Summary
|
||||
|
||||
**Overall Completeness:** {percentage}% ({complete_sections}/{total_sections})
|
||||
|
||||
**Critical Gaps:** [count] [list if any]
|
||||
**Minor Gaps:** [count] [list if any]
|
||||
|
||||
**Severity:** [Critical if template variables exist or critical sections missing, Warning if minor gaps, Pass if complete]
|
||||
|
||||
**Recommendation:**
|
||||
[If Critical] "PRD has completeness gaps that must be addressed before use. Fix template variables and complete missing sections."
|
||||
[If Warning] "PRD has minor completeness gaps. Address minor gaps for complete documentation."
|
||||
[If Pass] "PRD is complete with all required sections and content present."
|
||||
```
|
||||
|
||||
### 4. Display Progress and Auto-Proceed
|
||||
|
||||
Display: "**Completeness Validation Complete**
|
||||
|
||||
Overall Completeness: {percentage}% ({severity})
|
||||
|
||||
**Proceeding to final step...**"
|
||||
|
||||
Immediately load and execute {nextStepFile} (step-v-13-report-complete.md)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Scanned for template variables systematically
|
||||
- Validated each section for required content
|
||||
- Validated section-specific completeness (measurability, coverage, scope)
|
||||
- Validated frontmatter completeness
|
||||
- Completeness matrix built with all checks
|
||||
- Severity assessed correctly
|
||||
- Findings reported to validation report
|
||||
- Auto-proceeds to final step
|
||||
- Subprocess attempted with graceful degradation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not scanning for template variables
|
||||
- Missing section-specific completeness checks
|
||||
- Not validating frontmatter
|
||||
- Not building completeness matrix
|
||||
- Not reporting findings to validation report
|
||||
- Not auto-proceeding
|
||||
|
||||
**Master Rule:** Final gate to ensure document is complete before presenting findings. Template variables or critical gaps must be fixed.
|
||||
@@ -0,0 +1,232 @@
|
||||
---
|
||||
name: 'step-v-13-report-complete'
|
||||
description: 'Validation Report Complete - Finalize report, summarize findings, present to user, offer next steps'
|
||||
|
||||
# File references (ONLY variables used in this step)
|
||||
validationReportPath: '{validation_report_path}'
|
||||
prdFile: '{prd_file_path}'
|
||||
---
|
||||
|
||||
# Step 13: Validation Report Complete
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Finalize validation report, summarize all findings from steps 1-12, present summary to user conversationally, and offer actionable next steps.
|
||||
|
||||
## 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 Validation Architect and Quality Assurance Specialist
|
||||
- ✅ 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 synthesis and summary expertise
|
||||
- ✅ This is the FINAL step - requires user interaction
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on summarizing findings and presenting options
|
||||
- 🚫 FORBIDDEN to perform additional validation
|
||||
- 💬 Approach: Conversational summary with clear next steps
|
||||
- 🚪 This is the final step - no next step after this
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load complete validation report
|
||||
- 🎯 Summarize all findings from steps 1-12
|
||||
- 🎯 Update report frontmatter with final status
|
||||
- 💬 Present summary to user conversationally
|
||||
- 💬 Offer menu options for next actions
|
||||
- 🚫 FORBIDDEN to proceed without user selection
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Complete validation report with findings from all validation steps
|
||||
- Focus: Summary and presentation only (no new validation)
|
||||
- Limits: Don't add new findings, just synthesize existing
|
||||
- Dependencies: Steps 1-12 completed - all validation checks done
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Complete Validation Report
|
||||
|
||||
Read the entire validation report from {validationReportPath}
|
||||
|
||||
Extract all findings from:
|
||||
- Format Detection (Step 2)
|
||||
- Parity Analysis (Step 2B, if applicable)
|
||||
- Information Density (Step 3)
|
||||
- Product Brief Coverage (Step 4)
|
||||
- Measurability (Step 5)
|
||||
- Traceability (Step 6)
|
||||
- Implementation Leakage (Step 7)
|
||||
- Domain Compliance (Step 8)
|
||||
- Project-Type Compliance (Step 9)
|
||||
- SMART Requirements (Step 10)
|
||||
- Holistic Quality (Step 11)
|
||||
- Completeness (Step 12)
|
||||
|
||||
### 2. Update Report Frontmatter with Final Status
|
||||
|
||||
Update validation report frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
validationTarget: '{prd_path}'
|
||||
validationDate: '{current_date}'
|
||||
inputDocuments: [list of documents]
|
||||
validationStepsCompleted: ['step-v-01-discovery', 'step-v-02-format-detection', 'step-v-03-density-validation', 'step-v-04-brief-coverage-validation', 'step-v-05-measurability-validation', 'step-v-06-traceability-validation', 'step-v-07-implementation-leakage-validation', 'step-v-08-domain-compliance-validation', 'step-v-09-project-type-validation', 'step-v-10-smart-validation', 'step-v-11-holistic-quality-validation', 'step-v-12-completeness-validation']
|
||||
validationStatus: COMPLETE
|
||||
holisticQualityRating: '{rating from step 11}'
|
||||
overallStatus: '{Pass/Warning/Critical based on all findings}'
|
||||
---
|
||||
```
|
||||
|
||||
### 3. Create Summary of Findings
|
||||
|
||||
**Overall Status:**
|
||||
- Determine from all validation findings
|
||||
- **Pass:** All critical checks pass, minor warnings acceptable
|
||||
- **Warning:** Some issues found but PRD is usable
|
||||
- **Critical:** Major issues that prevent PRD from being fit for purpose
|
||||
|
||||
**Quick Results Table:**
|
||||
- Format: [classification]
|
||||
- Information Density: [severity]
|
||||
- Measurability: [severity]
|
||||
- Traceability: [severity]
|
||||
- Implementation Leakage: [severity]
|
||||
- Domain Compliance: [status]
|
||||
- Project-Type Compliance: [compliance score]
|
||||
- SMART Quality: [percentage]
|
||||
- Holistic Quality: [rating/5]
|
||||
- Completeness: [percentage]
|
||||
|
||||
**Critical Issues:** List from all validation steps
|
||||
**Warnings:** List from all validation steps
|
||||
**Strengths:** List positives from all validation steps
|
||||
|
||||
**Holistic Quality Rating:** From step 11
|
||||
**Top 3 Improvements:** From step 11
|
||||
|
||||
**Recommendation:** Based on overall status
|
||||
|
||||
### 4. Present Summary to User Conversationally
|
||||
|
||||
Display:
|
||||
|
||||
"**✓ PRD Validation Complete**
|
||||
|
||||
**Overall Status:** {Pass/Warning/Critical}
|
||||
|
||||
**Quick Results:**
|
||||
{Present quick results table with key findings}
|
||||
|
||||
**Critical Issues:** {count or "None"}
|
||||
{If any, list briefly}
|
||||
|
||||
**Warnings:** {count or "None"}
|
||||
{If any, list briefly}
|
||||
|
||||
**Strengths:**
|
||||
{List key strengths}
|
||||
|
||||
**Holistic Quality:** {rating}/5 - {label}
|
||||
|
||||
**Top 3 Improvements:**
|
||||
1. {Improvement 1}
|
||||
2. {Improvement 2}
|
||||
3. {Improvement 3}
|
||||
|
||||
**Recommendation:**
|
||||
{Based on overall status:
|
||||
- Pass: "PRD is in good shape. Address minor improvements to make it great."
|
||||
- Warning: "PRD is usable but has issues that should be addressed. Review warnings and improve where needed."
|
||||
- Critical: "PRD has significant issues that should be fixed before use. Focus on critical issues above."}
|
||||
|
||||
**What would you like to do next?**"
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display:
|
||||
|
||||
**[R] Review Detailed Findings** - Walk through validation report section by section
|
||||
**[E] Use Edit Workflow** - Use validation report with Edit workflow for systematic improvements
|
||||
**[F] Fix Simpler Items** - Immediate fixes for simple issues (anti-patterns, leakage, missing headers)
|
||||
**[X] Exit** - Exit and review validation report
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- Only proceed based on user selection
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- **IF R (Review Detailed Findings):**
|
||||
- Walk through validation report section by section
|
||||
- Present findings from each validation step
|
||||
- Allow user to ask questions
|
||||
- After review, return to menu
|
||||
|
||||
- **IF E (Use Edit Workflow):**
|
||||
- Explain: "The Edit workflow (steps-e/) can use this validation report to systematically address issues. Edit mode will guide you through discovering what to edit, reviewing the PRD, and applying targeted improvements."
|
||||
- Offer: "Would you like to launch Edit mode now? It will help you fix validation findings systematically."
|
||||
- If yes: Load and execute steps-e/step-e-01-discovery.md
|
||||
- If no: Return to menu
|
||||
|
||||
- **IF F (Fix Simpler Items):**
|
||||
- Offer immediate fixes for:
|
||||
- Template variables (fill in with appropriate content)
|
||||
- Conversational filler (remove wordy phrases)
|
||||
- Implementation leakage (remove technology names from FRs/NFRs)
|
||||
- Missing section headers (add ## headers)
|
||||
- Ask: "Which simple fixes would you like me to make?"
|
||||
- If user specifies fixes, make them and update validation report
|
||||
- Return to menu
|
||||
|
||||
- **IF X (Exit):**
|
||||
- Display: "**Validation Report Saved:** {validationReportPath}"
|
||||
- Display: "**Summary:** {overall status} - {recommendation}"
|
||||
- Display: "**Next Steps:** Review the validation report and address findings. For systematic improvements, consider using Edit workflow when available, or manually fix issues identified in this report."
|
||||
- Exit validation
|
||||
|
||||
- **IF Any other:** Help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Complete validation report loaded successfully
|
||||
- All findings from steps 1-12 summarized
|
||||
- Report frontmatter updated with final status
|
||||
- Overall status determined correctly (Pass/Warning/Critical)
|
||||
- Quick results table presented
|
||||
- Critical issues, warnings, and strengths listed
|
||||
- Holistic quality rating included
|
||||
- Top 3 improvements presented
|
||||
- Clear recommendation provided
|
||||
- Menu options presented with clear explanations
|
||||
- User can review findings, get help, or exit
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not loading complete validation report
|
||||
- Missing summary of findings
|
||||
- Not updating report frontmatter
|
||||
- Not determining overall status
|
||||
- Missing menu options
|
||||
- Unclear next steps
|
||||
|
||||
**Master Rule:** User needs clear summary and actionable next steps. Edit workflow is best for complex issues; immediate fixes available for simpler ones.
|
||||
Reference in New Issue
Block a user