Merge pull request #1988 from bmad-code-org/convert-validate-prd-skill
refactor(skills): convert validate-prd to native skill directory
This commit is contained in:
commit
7f0ffb54c0
|
|
@ -24,7 +24,7 @@ agent:
|
||||||
description: "[CP] Create PRD: Expert led facilitation to produce your Product Requirements Document"
|
description: "[CP] Create PRD: Expert led facilitation to produce your Product Requirements Document"
|
||||||
|
|
||||||
- trigger: VP or fuzzy match on validate-prd
|
- trigger: VP or fuzzy match on validate-prd
|
||||||
exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/workflow-validate-prd.md"
|
exec: "skill:bmad-validate-prd"
|
||||||
description: "[VP] Validate PRD: Validate a Product Requirements Document is comprehensive, lean, well organized and cohesive"
|
description: "[VP] Validate PRD: Validate a Product Requirements Document is comprehensive, lean, well organized and cohesive"
|
||||||
|
|
||||||
- trigger: EP or fuzzy match on edit-prd
|
- trigger: EP or fuzzy match on edit-prd
|
||||||
|
|
|
||||||
|
|
@ -16,7 +16,7 @@ bmm,1-analysis,Domain Research,DR,21,skill:bmad-domain-research,bmad-bmm-domain-
|
||||||
bmm,1-analysis,Technical Research,TR,22,skill:bmad-technical-research,bmad-bmm-technical-research,false,analyst,Create Mode,"Technical feasibility architecture options and implementation approaches","planning_artifacts|project_knowledge","research documents",
|
bmm,1-analysis,Technical Research,TR,22,skill:bmad-technical-research,bmad-bmm-technical-research,false,analyst,Create Mode,"Technical feasibility architecture options and implementation approaches","planning_artifacts|project_knowledge","research documents",
|
||||||
bmm,1-analysis,Create Brief,CB,30,skill:bmad-create-product-brief,bmad-bmm-create-product-brief,false,analyst,Create Mode,"A guided experience to nail down your product idea",planning_artifacts,"product brief",
|
bmm,1-analysis,Create Brief,CB,30,skill:bmad-create-product-brief,bmad-bmm-create-product-brief,false,analyst,Create Mode,"A guided experience to nail down your product idea",planning_artifacts,"product brief",
|
||||||
bmm,2-planning,Create PRD,CP,10,skill:bmad-create-prd,bmad-bmm-create-prd,true,pm,Create Mode,"Expert led facilitation to produce your Product Requirements Document",planning_artifacts,prd,
|
bmm,2-planning,Create PRD,CP,10,skill:bmad-create-prd,bmad-bmm-create-prd,true,pm,Create Mode,"Expert led facilitation to produce your Product Requirements Document",planning_artifacts,prd,
|
||||||
bmm,2-planning,Validate PRD,VP,20,_bmad/bmm/workflows/2-plan-workflows/create-prd/workflow-validate-prd.md,bmad-bmm-validate-prd,false,pm,Validate Mode,"Validate PRD is comprehensive lean well organized and cohesive",planning_artifacts,"prd validation report",
|
bmm,2-planning,Validate PRD,VP,20,skill:bmad-validate-prd,bmad-bmm-validate-prd,false,pm,Validate Mode,"Validate PRD is comprehensive lean well organized and cohesive",planning_artifacts,"prd validation report",
|
||||||
bmm,2-planning,Edit PRD,EP,25,skill:bmad-edit-prd,bmad-bmm-edit-prd,false,pm,Edit Mode,"Improve and enhance an existing PRD",planning_artifacts,"updated prd",
|
bmm,2-planning,Edit PRD,EP,25,skill:bmad-edit-prd,bmad-bmm-edit-prd,false,pm,Edit Mode,"Improve and enhance an existing PRD",planning_artifacts,"updated prd",
|
||||||
bmm,2-planning,Create UX,CU,30,skill:bmad-create-ux-design,bmad-bmm-create-ux-design,false,ux-designer,Create Mode,"Guidance through realizing the plan for your UX, strongly recommended if a UI is a primary piece of the proposed project",planning_artifacts,"ux design",
|
bmm,2-planning,Create UX,CU,30,skill:bmad-create-ux-design,bmad-bmm-create-ux-design,false,ux-designer,Create Mode,"Guidance through realizing the plan for your UX, strongly recommended if a UI is a primary piece of the proposed project",planning_artifacts,"ux design",
|
||||||
bmm,3-solutioning,Create Architecture,CA,10,skill:bmad-create-architecture,bmad-bmm-create-architecture,true,architect,Create Mode,"Guided Workflow to document technical decisions",planning_artifacts,architecture,
|
bmm,3-solutioning,Create Architecture,CA,10,skill:bmad-create-architecture,bmad-bmm-create-architecture,true,architect,Create Mode,"Guided Workflow to document technical decisions",planning_artifacts,architecture,
|
||||||
|
|
|
||||||
|
|
|
@ -0,0 +1,6 @@
|
||||||
|
---
|
||||||
|
name: bmad-validate-prd
|
||||||
|
description: 'Validate a PRD against standards. Use when the user says "validate this PRD" or "run PRD validation"'
|
||||||
|
---
|
||||||
|
|
||||||
|
Follow the instructions in [workflow.md](workflow.md).
|
||||||
|
|
@ -0,0 +1 @@
|
||||||
|
type: skill
|
||||||
|
|
@ -0,0 +1,15 @@
|
||||||
|
domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
|
||||||
|
healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
|
||||||
|
fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
|
||||||
|
govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
|
||||||
|
edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
|
||||||
|
aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
|
||||||
|
automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
|
||||||
|
scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
|
||||||
|
legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
|
||||||
|
insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
|
||||||
|
energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
|
||||||
|
process_control,"industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,OT,control system,cyberphysical,MES,historian,instrumentation,I&C,P&ID",high,"Functional safety;OT cybersecurity;Real-time control requirements;Legacy system integration;Process safety and hazard analysis;Environmental compliance and permitting;Engineering authority and PE requirements","Functional safety standards;OT security frameworks;Industrial protocols;Process control architecture;Plant reliability and maintainability","domain-research + technical-model","IEC 62443 OT cybersecurity requirements {date};functional safety software requirements {date};industrial process control architecture;ISA-95 manufacturing integration","functional_safety;ot_security;process_requirements;engineering_authority"
|
||||||
|
building_automation,"building automation,BAS,BMS,HVAC,smart building,lighting control,fire alarm,fire protection,fire suppression,life safety,elevator,access control,DDC,energy management,sequence of operations,commissioning",high,"Life safety codes;Building energy standards;Multi-trade coordination and interoperability;Commissioning and ongoing operational performance;Indoor environmental quality and occupant comfort;Engineering authority and PE requirements","Building automation protocols;HVAC and mechanical controls;Fire alarm, fire protection, and life safety design;Commissioning process and sequence of operations;Building codes and energy standards","domain-research","smart building software architecture {date};BACnet integration best practices;building automation cybersecurity {date};ASHRAE building standards","life_safety;energy_compliance;commissioning_requirements;engineering_authority"
|
||||||
|
gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
|
||||||
|
general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
|
||||||
|
|
|
@ -0,0 +1,197 @@
|
||||||
|
# BMAD PRD Purpose
|
||||||
|
|
||||||
|
**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## What is a BMAD PRD?
|
||||||
|
|
||||||
|
A dual-audience document serving:
|
||||||
|
1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
|
||||||
|
2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
|
||||||
|
|
||||||
|
Each successive document becomes more AI-tailored and granular.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Core Philosophy: Information Density
|
||||||
|
|
||||||
|
**High Signal-to-Noise Ratio**
|
||||||
|
|
||||||
|
Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
|
||||||
|
|
||||||
|
**Anti-Patterns (Eliminate These):**
|
||||||
|
- ❌ "The system will allow users to..." → ✅ "Users can..."
|
||||||
|
- ❌ "It is important to note that..." → ✅ State the fact directly
|
||||||
|
- ❌ "In order to..." → ✅ "To..."
|
||||||
|
- ❌ Conversational filler and padding → ✅ Direct, concise statements
|
||||||
|
|
||||||
|
**Goal:** Maximum information per word. Zero fluff.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The Traceability Chain
|
||||||
|
|
||||||
|
**PRD starts the chain:**
|
||||||
|
```
|
||||||
|
Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
|
||||||
|
```
|
||||||
|
|
||||||
|
**In the PRD, establish:**
|
||||||
|
- Vision → Success Criteria alignment
|
||||||
|
- Success Criteria → User Journey coverage
|
||||||
|
- User Journey → Functional Requirement mapping
|
||||||
|
- All requirements traceable to user needs
|
||||||
|
|
||||||
|
**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## What Makes Great Functional Requirements?
|
||||||
|
|
||||||
|
### FRs are Capabilities, Not Implementation
|
||||||
|
|
||||||
|
**Good FR:** "Users can reset their password via email link"
|
||||||
|
**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
|
||||||
|
|
||||||
|
**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
|
||||||
|
**Bad FR:** "Fast loading time" (subjective, unmeasurable)
|
||||||
|
|
||||||
|
### SMART Quality Criteria
|
||||||
|
|
||||||
|
**Specific:** Clear, precisely defined capability
|
||||||
|
**Measurable:** Quantifiable with test criteria
|
||||||
|
**Attainable:** Realistic within constraints
|
||||||
|
**Relevant:** Aligns with business objectives
|
||||||
|
**Traceable:** Links to source (executive summary or user journey)
|
||||||
|
|
||||||
|
### FR Anti-Patterns
|
||||||
|
|
||||||
|
**Subjective Adjectives:**
|
||||||
|
- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
|
||||||
|
- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
|
||||||
|
|
||||||
|
**Implementation Leakage:**
|
||||||
|
- ❌ Technology names, specific libraries, implementation details
|
||||||
|
- ✅ Focus on capability and measurable outcomes
|
||||||
|
|
||||||
|
**Vague Quantifiers:**
|
||||||
|
- ❌ "multiple users", "several options", "various formats"
|
||||||
|
- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
|
||||||
|
|
||||||
|
**Missing Test Criteria:**
|
||||||
|
- ❌ "The system shall provide notifications"
|
||||||
|
- ✅ "The system shall send email notifications within 30 seconds of trigger event"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## What Makes Great Non-Functional Requirements?
|
||||||
|
|
||||||
|
### NFRs Must Be Measurable
|
||||||
|
|
||||||
|
**Template:**
|
||||||
|
```
|
||||||
|
"The system shall [metric] [condition] [measurement method]"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Examples:**
|
||||||
|
- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
|
||||||
|
- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
|
||||||
|
- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
|
||||||
|
|
||||||
|
### NFR Anti-Patterns
|
||||||
|
|
||||||
|
**Unmeasurable Claims:**
|
||||||
|
- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
|
||||||
|
- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
|
||||||
|
|
||||||
|
**Missing Context:**
|
||||||
|
- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Domain-Specific Requirements
|
||||||
|
|
||||||
|
**Auto-Detect and Enforce Based on Project Context**
|
||||||
|
|
||||||
|
Certain industries have mandatory requirements that must be present:
|
||||||
|
|
||||||
|
- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
|
||||||
|
- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
|
||||||
|
- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
|
||||||
|
- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
|
||||||
|
|
||||||
|
**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Document Structure (Markdown, Human-Readable)
|
||||||
|
|
||||||
|
### Required Sections
|
||||||
|
1. **Executive Summary** - Vision, differentiator, target users
|
||||||
|
2. **Success Criteria** - Measurable outcomes (SMART)
|
||||||
|
3. **Product Scope** - MVP, Growth, Vision phases
|
||||||
|
4. **User Journeys** - Comprehensive coverage
|
||||||
|
5. **Domain Requirements** - Industry-specific compliance (if applicable)
|
||||||
|
6. **Innovation Analysis** - Competitive differentiation (if applicable)
|
||||||
|
7. **Project-Type Requirements** - Platform-specific needs
|
||||||
|
8. **Functional Requirements** - Capability contract (FRs)
|
||||||
|
9. **Non-Functional Requirements** - Quality attributes (NFRs)
|
||||||
|
|
||||||
|
### Formatting for Dual Consumption
|
||||||
|
|
||||||
|
**For Humans:**
|
||||||
|
- Clear, professional language
|
||||||
|
- Logical flow from vision to requirements
|
||||||
|
- Easy for stakeholders to review and approve
|
||||||
|
|
||||||
|
**For LLMs:**
|
||||||
|
- ## Level 2 headers for all main sections (enables extraction)
|
||||||
|
- Consistent structure and patterns
|
||||||
|
- Precise, testable language
|
||||||
|
- High information density
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Downstream Impact
|
||||||
|
|
||||||
|
**How the PRD Feeds Next Artifacts:**
|
||||||
|
|
||||||
|
**UX Design:**
|
||||||
|
- User journeys → interaction flows
|
||||||
|
- FRs → design requirements
|
||||||
|
- Success criteria → UX metrics
|
||||||
|
|
||||||
|
**Architecture:**
|
||||||
|
- FRs → system capabilities
|
||||||
|
- NFRs → architecture decisions
|
||||||
|
- Domain requirements → compliance architecture
|
||||||
|
- Project-type requirements → platform choices
|
||||||
|
|
||||||
|
**Epics & Stories (created after architecture):**
|
||||||
|
- FRs → user stories (1 FR could map to 1-3 stories potentially)
|
||||||
|
- Acceptance criteria → story acceptance tests
|
||||||
|
- Priority → sprint sequencing
|
||||||
|
- Traceability → stories map back to vision
|
||||||
|
|
||||||
|
**Development AI Agents:**
|
||||||
|
- Precise requirements → implementation clarity
|
||||||
|
- Test criteria → automated test generation
|
||||||
|
- Domain requirements → compliance enforcement
|
||||||
|
- Measurable NFRs → performance targets
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Summary: What Makes a Great BMAD PRD?
|
||||||
|
|
||||||
|
✅ **High Information Density** - Every sentence carries weight, zero fluff
|
||||||
|
✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
|
||||||
|
✅ **Clear Traceability** - Each requirement links to user need and business objective
|
||||||
|
✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
|
||||||
|
✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
|
||||||
|
✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
|
||||||
|
✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.
|
||||||
|
|
@ -0,0 +1,11 @@
|
||||||
|
project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
|
||||||
|
api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
|
||||||
|
mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
|
||||||
|
saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
|
||||||
|
developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
|
||||||
|
cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
|
||||||
|
web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
|
||||||
|
game,"game,player,gameplay,level,character","REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
|
||||||
|
desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
|
||||||
|
iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
|
||||||
|
blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
|
||||||
|
|
|
@ -0,0 +1,226 @@
|
||||||
|
---
|
||||||
|
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: 'skill:bmad-advanced-elicitation'
|
||||||
|
partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-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, auto-discover:**
|
||||||
|
- Search `{planning_artifacts}` for files matching `*prd*.md`
|
||||||
|
- Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md`
|
||||||
|
|
||||||
|
**If exactly ONE PRD found:**
|
||||||
|
- Use it automatically
|
||||||
|
- Inform user: "Found PRD: {discovered_path} — using it for validation."
|
||||||
|
|
||||||
|
**If MULTIPLE PRDs found:**
|
||||||
|
- List all discovered PRDs with numbered options
|
||||||
|
- "I found multiple PRDs. Which one would you like to validate?"
|
||||||
|
- Wait for user selection
|
||||||
|
|
||||||
|
**If NO PRDs found:**
|
||||||
|
- "I couldn't find any PRD files in {planning_artifacts}. 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: Read fully and follow: {advancedElicitationTask}, and when finished redisplay the menu
|
||||||
|
- IF P: Read fully and follow: {partyModeWorkflow}, and when finished redisplay the menu
|
||||||
|
- IF C: Read fully and follow: {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..."
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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): Read fully and follow: {altStepFile} (step-v-02b-parity-check.md)
|
||||||
|
- IF B (Validate As-Is): Display "Proceeding with validation..." then read fully and follow: {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 read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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}'
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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}`
|
||||||
|
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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,265 @@
|
||||||
|
---
|
||||||
|
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: 'skill:bmad-advanced-elicitation'
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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}`
|
||||||
|
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_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:
|
||||||
|
|
||||||
|
**Read fully and follow the 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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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...**"
|
||||||
|
|
||||||
|
Without delay, read fully and follow: {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}`
|
||||||
|
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_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 Suggest Next Steps.
|
||||||
|
|
||||||
|
#### 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: Read fully and follow: 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}"
|
||||||
|
- PRD Validation complete. Invoke the `bmad-help` skill.
|
||||||
|
|
||||||
|
- **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.
|
||||||
|
|
@ -0,0 +1,62 @@
|
||||||
|
---
|
||||||
|
main_config: '{project-root}/_bmad/bmm/config.yaml'
|
||||||
|
validateWorkflow: './steps-v/step-v-01-discovery.md'
|
||||||
|
---
|
||||||
|
|
||||||
|
# PRD Validate Workflow
|
||||||
|
|
||||||
|
**Goal:** Validate existing PRDs against BMAD standards through comprehensive review.
|
||||||
|
|
||||||
|
**Your Role:** Validation Architect and Quality Assurance Specialist.
|
||||||
|
|
||||||
|
You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
|
||||||
|
|
||||||
|
## WORKFLOW ARCHITECTURE
|
||||||
|
|
||||||
|
This uses **step-file architecture** for disciplined execution:
|
||||||
|
|
||||||
|
### Core Principles
|
||||||
|
|
||||||
|
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||||
|
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
||||||
|
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||||
|
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||||
|
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||||
|
|
||||||
|
### Step Processing Rules
|
||||||
|
|
||||||
|
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||||
|
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||||
|
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||||
|
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||||
|
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||||
|
6. **LOAD NEXT**: When directed, read fully and follow the next step file
|
||||||
|
|
||||||
|
### Critical Rules (NO EXCEPTIONS)
|
||||||
|
|
||||||
|
- 🛑 **NEVER** load multiple step files simultaneously
|
||||||
|
- 📖 **ALWAYS** read entire step file before execution
|
||||||
|
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||||
|
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
||||||
|
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
||||||
|
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||||
|
- 📋 **NEVER** create mental todo lists from future steps
|
||||||
|
|
||||||
|
## INITIALIZATION SEQUENCE
|
||||||
|
|
||||||
|
### 1. Configuration Loading
|
||||||
|
|
||||||
|
Load and read full config from {main_config} and resolve:
|
||||||
|
|
||||||
|
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
||||||
|
- `communication_language`, `document_output_language`, `user_skill_level`
|
||||||
|
- `date` as system-generated current datetime
|
||||||
|
|
||||||
|
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
||||||
|
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
||||||
|
|
||||||
|
### 2. Route to Validate Workflow
|
||||||
|
|
||||||
|
"**Validate Mode: Validating an existing PRD against BMAD standards.**"
|
||||||
|
|
||||||
|
Then read fully and follow: `{validateWorkflow}` (steps-v/step-v-01-discovery.md)
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
workflow-validate-prd.md:
|
|
||||||
canonicalId: bmad-validate-prd
|
|
||||||
type: workflow
|
|
||||||
description: "Validate a PRD against standards. Use when the user says 'validate this PRD' or 'run PRD validation'"
|
|
||||||
|
|
@ -1,6 +1,7 @@
|
||||||
---
|
---
|
||||||
name: validate-prd
|
name: validate-prd
|
||||||
description: 'Validate a PRD against standards. Use when the user says "validate this PRD" or "run PRD validation"'
|
description: 'Validate a PRD against standards. Use when the user says "validate this PRD" or "run PRD validation"'
|
||||||
|
standalone: false
|
||||||
main_config: '{project-root}/_bmad/bmm/config.yaml'
|
main_config: '{project-root}/_bmad/bmm/config.yaml'
|
||||||
validateWorkflow: './steps-v/step-v-01-discovery.md'
|
validateWorkflow: './steps-v/step-v-01-discovery.md'
|
||||||
---
|
---
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue