moved bmad-core to dot folder so when adding to project it is clear its not part of the project it is added to
This commit is contained in:
Brian Madison
@@ -1,436 +0,0 @@
|
||||
# Architect Solution Validation Checklist
|
||||
|
||||
This checklist serves as a comprehensive framework for the Architect to validate the technical design and architecture before development execution. The Architect should systematically work through each item, ensuring the architecture is robust, scalable, secure, and aligned with the product requirements.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS
|
||||
|
||||
Before proceeding with this checklist, ensure you have access to:
|
||||
|
||||
1. architecture.md - The primary architecture document (check docs/architecture.md)
|
||||
2. prd.md - Product Requirements Document for requirements alignment (check docs/prd.md)
|
||||
3. frontend-architecture.md or fe-architecture.md - If this is a UI project (check docs/frontend-architecture.md)
|
||||
4. Any system diagrams referenced in the architecture
|
||||
5. API documentation if available
|
||||
6. Technology stack details and version specifications
|
||||
|
||||
IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.
|
||||
|
||||
PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
- Does the architecture include a frontend/UI component?
|
||||
- Is there a frontend-architecture.md document?
|
||||
- Does the PRD mention user interfaces or frontend requirements?
|
||||
|
||||
If this is a backend-only or service-only project:
|
||||
- Skip sections marked with [[FRONTEND ONLY]]
|
||||
- Focus extra attention on API design, service architecture, and integration patterns
|
||||
- Note in your final report that frontend sections were skipped due to project type
|
||||
|
||||
VALIDATION APPROACH:
|
||||
For each section, you must:
|
||||
|
||||
1. Deep Analysis - Don't just check boxes, thoroughly analyze each item against the provided documentation
|
||||
2. Evidence-Based - Cite specific sections or quotes from the documents when validating
|
||||
3. Critical Thinking - Question assumptions and identify gaps, not just confirm what's present
|
||||
4. Risk Assessment - Consider what could go wrong with each architectural decision
|
||||
|
||||
EXECUTION MODE:
|
||||
Ask the user if they want to work through the checklist:
|
||||
|
||||
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
|
||||
|
||||
## 1. REQUIREMENTS ALIGNMENT
|
||||
|
||||
[[LLM: Before evaluating this section, take a moment to fully understand the product's purpose and goals from the PRD. What is the core problem being solved? Who are the users? What are the critical success factors? Keep these in mind as you validate alignment. For each item, don't just check if it's mentioned - verify that the architecture provides a concrete technical solution.]]
|
||||
|
||||
### 1.1 Functional Requirements Coverage
|
||||
|
||||
- [ ] Architecture supports all functional requirements in the PRD
|
||||
- [ ] Technical approaches for all epics and stories are addressed
|
||||
- [ ] Edge cases and performance scenarios are considered
|
||||
- [ ] All required integrations are accounted for
|
||||
- [ ] User journeys are supported by the technical architecture
|
||||
|
||||
### 1.2 Non-Functional Requirements Alignment
|
||||
|
||||
- [ ] Performance requirements are addressed with specific solutions
|
||||
- [ ] Scalability considerations are documented with approach
|
||||
- [ ] Security requirements have corresponding technical controls
|
||||
- [ ] Reliability and resilience approaches are defined
|
||||
- [ ] Compliance requirements have technical implementations
|
||||
|
||||
### 1.3 Technical Constraints Adherence
|
||||
|
||||
- [ ] All technical constraints from PRD are satisfied
|
||||
- [ ] Platform/language requirements are followed
|
||||
- [ ] Infrastructure constraints are accommodated
|
||||
- [ ] Third-party service constraints are addressed
|
||||
- [ ] Organizational technical standards are followed
|
||||
|
||||
## 2. ARCHITECTURE FUNDAMENTALS
|
||||
|
||||
[[LLM: Architecture clarity is crucial for successful implementation. As you review this section, visualize the system as if you were explaining it to a new developer. Are there any ambiguities that could lead to misinterpretation? Would an AI agent be able to implement this architecture without confusion? Look for specific diagrams, component definitions, and clear interaction patterns.]]
|
||||
|
||||
### 2.1 Architecture Clarity
|
||||
|
||||
- [ ] Architecture is documented with clear diagrams
|
||||
- [ ] Major components and their responsibilities are defined
|
||||
- [ ] Component interactions and dependencies are mapped
|
||||
- [ ] Data flows are clearly illustrated
|
||||
- [ ] Technology choices for each component are specified
|
||||
|
||||
### 2.2 Separation of Concerns
|
||||
|
||||
- [ ] Clear boundaries between UI, business logic, and data layers
|
||||
- [ ] Responsibilities are cleanly divided between components
|
||||
- [ ] Interfaces between components are well-defined
|
||||
- [ ] Components adhere to single responsibility principle
|
||||
- [ ] Cross-cutting concerns (logging, auth, etc.) are properly addressed
|
||||
|
||||
### 2.3 Design Patterns & Best Practices
|
||||
|
||||
- [ ] Appropriate design patterns are employed
|
||||
- [ ] Industry best practices are followed
|
||||
- [ ] Anti-patterns are avoided
|
||||
- [ ] Consistent architectural style throughout
|
||||
- [ ] Pattern usage is documented and explained
|
||||
|
||||
### 2.4 Modularity & Maintainability
|
||||
|
||||
- [ ] System is divided into cohesive, loosely-coupled modules
|
||||
- [ ] Components can be developed and tested independently
|
||||
- [ ] Changes can be localized to specific components
|
||||
- [ ] Code organization promotes discoverability
|
||||
- [ ] Architecture specifically designed for AI agent implementation
|
||||
|
||||
## 3. TECHNICAL STACK & DECISIONS
|
||||
|
||||
[[LLM: Technology choices have long-term implications. For each technology decision, consider: Is this the simplest solution that could work? Are we over-engineering? Will this scale? What are the maintenance implications? Are there security vulnerabilities in the chosen versions? Verify that specific versions are defined, not ranges.]]
|
||||
|
||||
### 3.1 Technology Selection
|
||||
|
||||
- [ ] Selected technologies meet all requirements
|
||||
- [ ] Technology versions are specifically defined (not ranges)
|
||||
- [ ] Technology choices are justified with clear rationale
|
||||
- [ ] Alternatives considered are documented with pros/cons
|
||||
- [ ] Selected stack components work well together
|
||||
|
||||
### 3.2 Frontend Architecture [[FRONTEND ONLY]]
|
||||
|
||||
[[LLM: Skip this entire section if this is a backend-only or service-only project. Only evaluate if the project includes a user interface.]]
|
||||
|
||||
- [ ] UI framework and libraries are specifically selected
|
||||
- [ ] State management approach is defined
|
||||
- [ ] Component structure and organization is specified
|
||||
- [ ] Responsive/adaptive design approach is outlined
|
||||
- [ ] Build and bundling strategy is determined
|
||||
|
||||
### 3.3 Backend Architecture
|
||||
|
||||
- [ ] API design and standards are defined
|
||||
- [ ] Service organization and boundaries are clear
|
||||
- [ ] Authentication and authorization approach is specified
|
||||
- [ ] Error handling strategy is outlined
|
||||
- [ ] Backend scaling approach is defined
|
||||
|
||||
### 3.4 Data Architecture
|
||||
|
||||
- [ ] Data models are fully defined
|
||||
- [ ] Database technologies are selected with justification
|
||||
- [ ] Data access patterns are documented
|
||||
- [ ] Data migration/seeding approach is specified
|
||||
- [ ] Data backup and recovery strategies are outlined
|
||||
|
||||
## 4. FRONTEND DESIGN & IMPLEMENTATION [[FRONTEND ONLY]]
|
||||
|
||||
[[LLM: This entire section should be skipped for backend-only projects. Only evaluate if the project includes a user interface. When evaluating, ensure alignment between the main architecture document and the frontend-specific architecture document.]]
|
||||
|
||||
### 4.1 Frontend Philosophy & Patterns
|
||||
|
||||
- [ ] Framework & Core Libraries align with main architecture document
|
||||
- [ ] Component Architecture (e.g., Atomic Design) is clearly described
|
||||
- [ ] State Management Strategy is appropriate for application complexity
|
||||
- [ ] Data Flow patterns are consistent and clear
|
||||
- [ ] Styling Approach is defined and tooling specified
|
||||
|
||||
### 4.2 Frontend Structure & Organization
|
||||
|
||||
- [ ] Directory structure is clearly documented with ASCII diagram
|
||||
- [ ] Component organization follows stated patterns
|
||||
- [ ] File naming conventions are explicit
|
||||
- [ ] Structure supports chosen framework's best practices
|
||||
- [ ] Clear guidance on where new components should be placed
|
||||
|
||||
### 4.3 Component Design
|
||||
|
||||
- [ ] Component template/specification format is defined
|
||||
- [ ] Component props, state, and events are well-documented
|
||||
- [ ] Shared/foundational components are identified
|
||||
- [ ] Component reusability patterns are established
|
||||
- [ ] Accessibility requirements are built into component design
|
||||
|
||||
### 4.4 Frontend-Backend Integration
|
||||
|
||||
- [ ] API interaction layer is clearly defined
|
||||
- [ ] HTTP client setup and configuration documented
|
||||
- [ ] Error handling for API calls is comprehensive
|
||||
- [ ] Service definitions follow consistent patterns
|
||||
- [ ] Authentication integration with backend is clear
|
||||
|
||||
### 4.5 Routing & Navigation
|
||||
|
||||
- [ ] Routing strategy and library are specified
|
||||
- [ ] Route definitions table is comprehensive
|
||||
- [ ] Route protection mechanisms are defined
|
||||
- [ ] Deep linking considerations addressed
|
||||
- [ ] Navigation patterns are consistent
|
||||
|
||||
### 4.6 Frontend Performance
|
||||
|
||||
- [ ] Image optimization strategies defined
|
||||
- [ ] Code splitting approach documented
|
||||
- [ ] Lazy loading patterns established
|
||||
- [ ] Re-render optimization techniques specified
|
||||
- [ ] Performance monitoring approach defined
|
||||
|
||||
## 5. RESILIENCE & OPERATIONAL READINESS
|
||||
|
||||
[[LLM: Production systems fail in unexpected ways. As you review this section, think about Murphy's Law - what could go wrong? Consider real-world scenarios: What happens during peak load? How does the system behave when a critical service is down? Can the operations team diagnose issues at 3 AM? Look for specific resilience patterns, not just mentions of "error handling".]]
|
||||
|
||||
### 5.1 Error Handling & Resilience
|
||||
|
||||
- [ ] Error handling strategy is comprehensive
|
||||
- [ ] Retry policies are defined where appropriate
|
||||
- [ ] Circuit breakers or fallbacks are specified for critical services
|
||||
- [ ] Graceful degradation approaches are defined
|
||||
- [ ] System can recover from partial failures
|
||||
|
||||
### 5.2 Monitoring & Observability
|
||||
|
||||
- [ ] Logging strategy is defined
|
||||
- [ ] Monitoring approach is specified
|
||||
- [ ] Key metrics for system health are identified
|
||||
- [ ] Alerting thresholds and strategies are outlined
|
||||
- [ ] Debugging and troubleshooting capabilities are built in
|
||||
|
||||
### 5.3 Performance & Scaling
|
||||
|
||||
- [ ] Performance bottlenecks are identified and addressed
|
||||
- [ ] Caching strategy is defined where appropriate
|
||||
- [ ] Load balancing approach is specified
|
||||
- [ ] Horizontal and vertical scaling strategies are outlined
|
||||
- [ ] Resource sizing recommendations are provided
|
||||
|
||||
### 5.4 Deployment & DevOps
|
||||
|
||||
- [ ] Deployment strategy is defined
|
||||
- [ ] CI/CD pipeline approach is outlined
|
||||
- [ ] Environment strategy (dev, staging, prod) is specified
|
||||
- [ ] Infrastructure as Code approach is defined
|
||||
- [ ] Rollback and recovery procedures are outlined
|
||||
|
||||
## 6. SECURITY & COMPLIANCE
|
||||
|
||||
[[LLM: Security is not optional. Review this section with a hacker's mindset - how could someone exploit this system? Also consider compliance: Are there industry-specific regulations that apply? GDPR? HIPAA? PCI? Ensure the architecture addresses these proactively. Look for specific security controls, not just general statements.]]
|
||||
|
||||
### 6.1 Authentication & Authorization
|
||||
|
||||
- [ ] Authentication mechanism is clearly defined
|
||||
- [ ] Authorization model is specified
|
||||
- [ ] Role-based access control is outlined if required
|
||||
- [ ] Session management approach is defined
|
||||
- [ ] Credential management is addressed
|
||||
|
||||
### 6.2 Data Security
|
||||
|
||||
- [ ] Data encryption approach (at rest and in transit) is specified
|
||||
- [ ] Sensitive data handling procedures are defined
|
||||
- [ ] Data retention and purging policies are outlined
|
||||
- [ ] Backup encryption is addressed if required
|
||||
- [ ] Data access audit trails are specified if required
|
||||
|
||||
### 6.3 API & Service Security
|
||||
|
||||
- [ ] API security controls are defined
|
||||
- [ ] Rate limiting and throttling approaches are specified
|
||||
- [ ] Input validation strategy is outlined
|
||||
- [ ] CSRF/XSS prevention measures are addressed
|
||||
- [ ] Secure communication protocols are specified
|
||||
|
||||
### 6.4 Infrastructure Security
|
||||
|
||||
- [ ] Network security design is outlined
|
||||
- [ ] Firewall and security group configurations are specified
|
||||
- [ ] Service isolation approach is defined
|
||||
- [ ] Least privilege principle is applied
|
||||
- [ ] Security monitoring strategy is outlined
|
||||
|
||||
## 7. IMPLEMENTATION GUIDANCE
|
||||
|
||||
[[LLM: Clear implementation guidance prevents costly mistakes. As you review this section, imagine you're a developer starting on day one. Do they have everything they need to be productive? Are coding standards clear enough to maintain consistency across the team? Look for specific examples and patterns.]]
|
||||
|
||||
### 7.1 Coding Standards & Practices
|
||||
|
||||
- [ ] Coding standards are defined
|
||||
- [ ] Documentation requirements are specified
|
||||
- [ ] Testing expectations are outlined
|
||||
- [ ] Code organization principles are defined
|
||||
- [ ] Naming conventions are specified
|
||||
|
||||
### 7.2 Testing Strategy
|
||||
|
||||
- [ ] Unit testing approach is defined
|
||||
- [ ] Integration testing strategy is outlined
|
||||
- [ ] E2E testing approach is specified
|
||||
- [ ] Performance testing requirements are outlined
|
||||
- [ ] Security testing approach is defined
|
||||
|
||||
### 7.3 Frontend Testing [[FRONTEND ONLY]]
|
||||
|
||||
[[LLM: Skip this subsection for backend-only projects.]]
|
||||
|
||||
- [ ] Component testing scope and tools defined
|
||||
- [ ] UI integration testing approach specified
|
||||
- [ ] Visual regression testing considered
|
||||
- [ ] Accessibility testing tools identified
|
||||
- [ ] Frontend-specific test data management addressed
|
||||
|
||||
### 7.4 Development Environment
|
||||
|
||||
- [ ] Local development environment setup is documented
|
||||
- [ ] Required tools and configurations are specified
|
||||
- [ ] Development workflows are outlined
|
||||
- [ ] Source control practices are defined
|
||||
- [ ] Dependency management approach is specified
|
||||
|
||||
### 7.5 Technical Documentation
|
||||
|
||||
- [ ] API documentation standards are defined
|
||||
- [ ] Architecture documentation requirements are specified
|
||||
- [ ] Code documentation expectations are outlined
|
||||
- [ ] System diagrams and visualizations are included
|
||||
- [ ] Decision records for key choices are included
|
||||
|
||||
## 8. DEPENDENCY & INTEGRATION MANAGEMENT
|
||||
|
||||
[[LLM: Dependencies are often the source of production issues. For each dependency, consider: What happens if it's unavailable? Is there a newer version with security patches? Are we locked into a vendor? What's our contingency plan? Verify specific versions and fallback strategies.]]
|
||||
|
||||
### 8.1 External Dependencies
|
||||
|
||||
- [ ] All external dependencies are identified
|
||||
- [ ] Versioning strategy for dependencies is defined
|
||||
- [ ] Fallback approaches for critical dependencies are specified
|
||||
- [ ] Licensing implications are addressed
|
||||
- [ ] Update and patching strategy is outlined
|
||||
|
||||
### 8.2 Internal Dependencies
|
||||
|
||||
- [ ] Component dependencies are clearly mapped
|
||||
- [ ] Build order dependencies are addressed
|
||||
- [ ] Shared services and utilities are identified
|
||||
- [ ] Circular dependencies are eliminated
|
||||
- [ ] Versioning strategy for internal components is defined
|
||||
|
||||
### 8.3 Third-Party Integrations
|
||||
|
||||
- [ ] All third-party integrations are identified
|
||||
- [ ] Integration approaches are defined
|
||||
- [ ] Authentication with third parties is addressed
|
||||
- [ ] Error handling for integration failures is specified
|
||||
- [ ] Rate limits and quotas are considered
|
||||
|
||||
## 9. AI AGENT IMPLEMENTATION SUITABILITY
|
||||
|
||||
[[LLM: This architecture may be implemented by AI agents. Review with extreme clarity in mind. Are patterns consistent? Is complexity minimized? Would an AI agent make incorrect assumptions? Remember: explicit is better than implicit. Look for clear file structures, naming conventions, and implementation patterns.]]
|
||||
|
||||
### 9.1 Modularity for AI Agents
|
||||
|
||||
- [ ] Components are sized appropriately for AI agent implementation
|
||||
- [ ] Dependencies between components are minimized
|
||||
- [ ] Clear interfaces between components are defined
|
||||
- [ ] Components have singular, well-defined responsibilities
|
||||
- [ ] File and code organization optimized for AI agent understanding
|
||||
|
||||
### 9.2 Clarity & Predictability
|
||||
|
||||
- [ ] Patterns are consistent and predictable
|
||||
- [ ] Complex logic is broken down into simpler steps
|
||||
- [ ] Architecture avoids overly clever or obscure approaches
|
||||
- [ ] Examples are provided for unfamiliar patterns
|
||||
- [ ] Component responsibilities are explicit and clear
|
||||
|
||||
### 9.3 Implementation Guidance
|
||||
|
||||
- [ ] Detailed implementation guidance is provided
|
||||
- [ ] Code structure templates are defined
|
||||
- [ ] Specific implementation patterns are documented
|
||||
- [ ] Common pitfalls are identified with solutions
|
||||
- [ ] References to similar implementations are provided when helpful
|
||||
|
||||
### 9.4 Error Prevention & Handling
|
||||
|
||||
- [ ] Design reduces opportunities for implementation errors
|
||||
- [ ] Validation and error checking approaches are defined
|
||||
- [ ] Self-healing mechanisms are incorporated where possible
|
||||
- [ ] Testing patterns are clearly defined
|
||||
- [ ] Debugging guidance is provided
|
||||
|
||||
## 10. ACCESSIBILITY IMPLEMENTATION [[FRONTEND ONLY]]
|
||||
|
||||
[[LLM: Skip this section for backend-only projects. Accessibility is a core requirement for any user interface.]]
|
||||
|
||||
### 10.1 Accessibility Standards
|
||||
|
||||
- [ ] Semantic HTML usage is emphasized
|
||||
- [ ] ARIA implementation guidelines provided
|
||||
- [ ] Keyboard navigation requirements defined
|
||||
- [ ] Focus management approach specified
|
||||
- [ ] Screen reader compatibility addressed
|
||||
|
||||
### 10.2 Accessibility Testing
|
||||
|
||||
- [ ] Accessibility testing tools identified
|
||||
- [ ] Testing process integrated into workflow
|
||||
- [ ] Compliance targets (WCAG level) specified
|
||||
- [ ] Manual testing procedures defined
|
||||
- [ ] Automated testing approach outlined
|
||||
|
||||
[[LLM: FINAL VALIDATION REPORT GENERATION
|
||||
|
||||
Now that you've completed the checklist, generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
- Overall architecture readiness (High/Medium/Low)
|
||||
- Critical risks identified
|
||||
- Key strengths of the architecture
|
||||
- Project type (Full-stack/Frontend/Backend) and sections evaluated
|
||||
|
||||
2. Section Analysis
|
||||
- Pass rate for each major section (percentage of items passed)
|
||||
- Most concerning failures or gaps
|
||||
- Sections requiring immediate attention
|
||||
- Note any sections skipped due to project type
|
||||
|
||||
3. Risk Assessment
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations for each
|
||||
- Timeline impact of addressing issues
|
||||
|
||||
4. Recommendations
|
||||
- Must-fix items before development
|
||||
- Should-fix items for better quality
|
||||
- Nice-to-have improvements
|
||||
|
||||
5. AI Implementation Readiness
|
||||
- Specific concerns for AI agent implementation
|
||||
- Areas needing additional clarification
|
||||
- Complexity hotspots to address
|
||||
|
||||
6. Frontend-Specific Assessment (if applicable)
|
||||
- Frontend architecture completeness
|
||||
- Alignment between main and frontend architecture docs
|
||||
- UI/UX specification coverage
|
||||
- Component design clarity
|
||||
|
||||
After presenting the report, ask the user if they would like detailed analysis of any specific section, especially those with warnings or failures.]]
|
||||
@@ -1,182 +0,0 @@
|
||||
# Change Navigation Checklist
|
||||
|
||||
**Purpose:** To systematically guide the selected Agent and user through the analysis and planning required when a significant change (pivot, tech issue, missing requirement, failed story) is identified during the BMAD workflow.
|
||||
|
||||
**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - CHANGE NAVIGATION
|
||||
|
||||
Changes during development are inevitable, but how we handle them determines project success or failure.
|
||||
|
||||
Before proceeding, understand:
|
||||
|
||||
1. This checklist is for SIGNIFICANT changes that affect the project direction
|
||||
2. Minor adjustments within a story don't require this process
|
||||
3. The goal is to minimize wasted work while adapting to new realities
|
||||
4. User buy-in is critical - they must understand and approve changes
|
||||
|
||||
Required context:
|
||||
|
||||
- The triggering story or issue
|
||||
- Current project state (completed stories, current epic)
|
||||
- Access to PRD, architecture, and other key documents
|
||||
- Understanding of remaining work planned
|
||||
|
||||
APPROACH:
|
||||
This is an interactive process with the user. Work through each section together, discussing implications and options. The user makes final decisions, but provide expert guidance on technical feasibility and impact.
|
||||
|
||||
REMEMBER: Changes are opportunities to improve, not failures. Handle them professionally and constructively.]]
|
||||
|
||||
---
|
||||
|
||||
## 1. Understand the Trigger & Context
|
||||
|
||||
[[LLM: Start by fully understanding what went wrong and why. Don't jump to solutions yet. Ask probing questions:
|
||||
|
||||
- What exactly happened that triggered this review?
|
||||
- Is this a one-time issue or symptomatic of a larger problem?
|
||||
- Could this have been anticipated earlier?
|
||||
- What assumptions were incorrect?
|
||||
|
||||
Be specific and factual, not blame-oriented.]]
|
||||
|
||||
- [ ] **Identify Triggering Story:** Clearly identify the story (or stories) that revealed the issue.
|
||||
- [ ] **Define the Issue:** Articulate the core problem precisely.
|
||||
- [ ] Is it a technical limitation/dead-end?
|
||||
- [ ] Is it a newly discovered requirement?
|
||||
- [ ] Is it a fundamental misunderstanding of existing requirements?
|
||||
- [ ] Is it a necessary pivot based on feedback or new information?
|
||||
- [ ] Is it a failed/abandoned story needing a new approach?
|
||||
- [ ] **Assess Initial Impact:** Describe the immediate observed consequences (e.g., blocked progress, incorrect functionality, non-viable tech).
|
||||
- [ ] **Gather Evidence:** Note any specific logs, error messages, user feedback, or analysis that supports the issue definition.
|
||||
|
||||
## 2. Epic Impact Assessment
|
||||
|
||||
[[LLM: Changes ripple through the project structure. Systematically evaluate:
|
||||
|
||||
1. Can we salvage the current epic with modifications?
|
||||
2. Do future epics still make sense given this change?
|
||||
3. Are we creating or eliminating dependencies?
|
||||
4. Does the epic sequence need reordering?
|
||||
|
||||
Think about both immediate and downstream effects.]]
|
||||
|
||||
- [ ] **Analyze Current Epic:**
|
||||
- [ ] Can the current epic containing the trigger story still be completed?
|
||||
- [ ] Does the current epic need modification (story changes, additions, removals)?
|
||||
- [ ] Should the current epic be abandoned or fundamentally redefined?
|
||||
- [ ] **Analyze Future Epics:**
|
||||
- [ ] Review all remaining planned epics.
|
||||
- [ ] Does the issue require changes to planned stories in future epics?
|
||||
- [ ] Does the issue invalidate any future epics?
|
||||
- [ ] Does the issue necessitate the creation of entirely new epics?
|
||||
- [ ] Should the order/priority of future epics be changed?
|
||||
- [ ] **Summarize Epic Impact:** Briefly document the overall effect on the project's epic structure and flow.
|
||||
|
||||
## 3. Artifact Conflict & Impact Analysis
|
||||
|
||||
[[LLM: Documentation drives development in BMAD. Check each artifact:
|
||||
|
||||
1. Does this change invalidate documented decisions?
|
||||
2. Are architectural assumptions still valid?
|
||||
3. Do user flows need rethinking?
|
||||
4. Are technical constraints different than documented?
|
||||
|
||||
Be thorough - missed conflicts cause future problems.]]
|
||||
|
||||
- [ ] **Review PRD:**
|
||||
- [ ] Does the issue conflict with the core goals or requirements stated in the PRD?
|
||||
- [ ] Does the PRD need clarification or updates based on the new understanding?
|
||||
- [ ] **Review Architecture Document:**
|
||||
- [ ] Does the issue conflict with the documented architecture (components, patterns, tech choices)?
|
||||
- [ ] Are specific components/diagrams/sections impacted?
|
||||
- [ ] Does the technology list need updating?
|
||||
- [ ] Do data models or schemas need revision?
|
||||
- [ ] Are external API integrations affected?
|
||||
- [ ] **Review Frontend Spec (if applicable):**
|
||||
- [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
|
||||
- [ ] Are specific FE components or user flows impacted?
|
||||
- [ ] **Review Other Artifacts (if applicable):**
|
||||
- [ ] Consider impact on deployment scripts, IaC, monitoring setup, etc.
|
||||
- [ ] **Summarize Artifact Impact:** List all artifacts requiring updates and the nature of the changes needed.
|
||||
|
||||
## 4. Path Forward Evaluation
|
||||
|
||||
[[LLM: Present options clearly with pros/cons. For each path:
|
||||
|
||||
1. What's the effort required?
|
||||
2. What work gets thrown away?
|
||||
3. What risks are we taking?
|
||||
4. How does this affect timeline?
|
||||
5. Is this sustainable long-term?
|
||||
|
||||
Be honest about trade-offs. There's rarely a perfect solution.]]
|
||||
|
||||
- [ ] **Option 1: Direct Adjustment / Integration:**
|
||||
- [ ] Can the issue be addressed by modifying/adding future stories within the existing plan?
|
||||
- [ ] Define the scope and nature of these adjustments.
|
||||
- [ ] Assess feasibility, effort, and risks of this path.
|
||||
- [ ] **Option 2: Potential Rollback:**
|
||||
- [ ] Would reverting completed stories significantly simplify addressing the issue?
|
||||
- [ ] Identify specific stories/commits to consider for rollback.
|
||||
- [ ] Assess the effort required for rollback.
|
||||
- [ ] Assess the impact of rollback (lost work, data implications).
|
||||
- [ ] Compare the net benefit/cost vs. Direct Adjustment.
|
||||
- [ ] **Option 3: PRD MVP Review & Potential Re-scoping:**
|
||||
- [ ] Is the original PRD MVP still achievable given the issue and constraints?
|
||||
- [ ] Does the MVP scope need reduction (removing features/epics)?
|
||||
- [ ] Do the core MVP goals need modification?
|
||||
- [ ] Are alternative approaches needed to meet the original MVP intent?
|
||||
- [ ] **Extreme Case:** Does the issue necessitate a fundamental replan or potentially a new PRD V2 (to be handled by PM)?
|
||||
- [ ] **Select Recommended Path:** Based on the evaluation, agree on the most viable path forward.
|
||||
|
||||
## 5. Sprint Change Proposal Components
|
||||
|
||||
[[LLM: The proposal must be actionable and clear. Ensure:
|
||||
|
||||
1. The issue is explained in plain language
|
||||
2. Impacts are quantified where possible
|
||||
3. The recommended path has clear rationale
|
||||
4. Next steps are specific and assigned
|
||||
5. Success criteria for the change are defined
|
||||
|
||||
This proposal guides all subsequent work.]]
|
||||
|
||||
(Ensure all agreed-upon points from previous sections are captured in the proposal)
|
||||
|
||||
- [ ] **Identified Issue Summary:** Clear, concise problem statement.
|
||||
- [ ] **Epic Impact Summary:** How epics are affected.
|
||||
- [ ] **Artifact Adjustment Needs:** List of documents to change.
|
||||
- [ ] **Recommended Path Forward:** Chosen solution with rationale.
|
||||
- [ ] **PRD MVP Impact:** Changes to scope/goals (if any).
|
||||
- [ ] **High-Level Action Plan:** Next steps for stories/updates.
|
||||
- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
|
||||
|
||||
## 6. Final Review & Handoff
|
||||
|
||||
[[LLM: Changes require coordination. Before concluding:
|
||||
|
||||
1. Is the user fully aligned with the plan?
|
||||
2. Do all stakeholders understand the impacts?
|
||||
3. Are handoffs to other agents clear?
|
||||
4. Is there a rollback plan if the change fails?
|
||||
5. How will we validate the change worked?
|
||||
|
||||
Get explicit approval - implicit agreement causes problems.
|
||||
|
||||
FINAL REPORT:
|
||||
After completing the checklist, provide a concise summary:
|
||||
|
||||
- What changed and why
|
||||
- What we're doing about it
|
||||
- Who needs to do what
|
||||
- When we'll know if it worked
|
||||
|
||||
Keep it action-oriented and forward-looking.]]
|
||||
|
||||
- [ ] **Review Checklist:** Confirm all relevant items were discussed.
|
||||
- [ ] **Review Sprint Change Proposal:** Ensure it accurately reflects the discussion and decisions.
|
||||
- [ ] **User Approval:** Obtain explicit user approval for the proposal.
|
||||
- [ ] **Confirm Next Steps:** Reiterate the handoff plan and the next actions to be taken by specific agents.
|
||||
|
||||
---
|
||||
@@ -1,375 +0,0 @@
|
||||
# Product Manager (PM) Requirements Checklist
|
||||
|
||||
This checklist serves as a comprehensive framework to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development. The PM should systematically work through each item during the product definition process.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - PM CHECKLIST
|
||||
|
||||
Before proceeding with this checklist, ensure you have access to:
|
||||
|
||||
1. prd.md - The Product Requirements Document (check docs/prd.md)
|
||||
2. Any user research, market analysis, or competitive analysis documents
|
||||
3. Business goals and strategy documents
|
||||
4. Any existing epic definitions or user stories
|
||||
|
||||
IMPORTANT: If the PRD is missing, immediately ask the user for its location or content before proceeding.
|
||||
|
||||
VALIDATION APPROACH:
|
||||
|
||||
1. User-Centric - Every requirement should tie back to user value
|
||||
2. MVP Focus - Ensure scope is truly minimal while viable
|
||||
3. Clarity - Requirements should be unambiguous and testable
|
||||
4. Completeness - All aspects of the product vision are covered
|
||||
5. Feasibility - Requirements are technically achievable
|
||||
|
||||
EXECUTION MODE:
|
||||
Ask the user if they want to work through the checklist:
|
||||
|
||||
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
|
||||
|
||||
## 1. PROBLEM DEFINITION & CONTEXT
|
||||
|
||||
[[LLM: The foundation of any product is a clear problem statement. As you review this section:
|
||||
|
||||
1. Verify the problem is real and worth solving
|
||||
2. Check that the target audience is specific, not "everyone"
|
||||
3. Ensure success metrics are measurable, not vague aspirations
|
||||
4. Look for evidence of user research, not just assumptions
|
||||
5. Confirm the problem-solution fit is logical]]
|
||||
|
||||
### 1.1 Problem Statement
|
||||
|
||||
- [ ] Clear articulation of the problem being solved
|
||||
- [ ] Identification of who experiences the problem
|
||||
- [ ] Explanation of why solving this problem matters
|
||||
- [ ] Quantification of problem impact (if possible)
|
||||
- [ ] Differentiation from existing solutions
|
||||
|
||||
### 1.2 Business Goals & Success Metrics
|
||||
|
||||
- [ ] Specific, measurable business objectives defined
|
||||
- [ ] Clear success metrics and KPIs established
|
||||
- [ ] Metrics are tied to user and business value
|
||||
- [ ] Baseline measurements identified (if applicable)
|
||||
- [ ] Timeframe for achieving goals specified
|
||||
|
||||
### 1.3 User Research & Insights
|
||||
|
||||
- [ ] Target user personas clearly defined
|
||||
- [ ] User needs and pain points documented
|
||||
- [ ] User research findings summarized (if available)
|
||||
- [ ] Competitive analysis included
|
||||
- [ ] Market context provided
|
||||
|
||||
## 2. MVP SCOPE DEFINITION
|
||||
|
||||
[[LLM: MVP scope is critical - too much and you waste resources, too little and you can't validate. Check:
|
||||
|
||||
1. Is this truly minimal? Challenge every feature
|
||||
2. Does each feature directly address the core problem?
|
||||
3. Are "nice-to-haves" clearly separated from "must-haves"?
|
||||
4. Is the rationale for inclusion/exclusion documented?
|
||||
5. Can you ship this in the target timeframe?]]
|
||||
|
||||
### 2.1 Core Functionality
|
||||
|
||||
- [ ] Essential features clearly distinguished from nice-to-haves
|
||||
- [ ] Features directly address defined problem statement
|
||||
- [ ] Each Epic ties back to specific user needs
|
||||
- [ ] Features and Stories are described from user perspective
|
||||
- [ ] Minimum requirements for success defined
|
||||
|
||||
### 2.2 Scope Boundaries
|
||||
|
||||
- [ ] Clear articulation of what is OUT of scope
|
||||
- [ ] Future enhancements section included
|
||||
- [ ] Rationale for scope decisions documented
|
||||
- [ ] MVP minimizes functionality while maximizing learning
|
||||
- [ ] Scope has been reviewed and refined multiple times
|
||||
|
||||
### 2.3 MVP Validation Approach
|
||||
|
||||
- [ ] Method for testing MVP success defined
|
||||
- [ ] Initial user feedback mechanisms planned
|
||||
- [ ] Criteria for moving beyond MVP specified
|
||||
- [ ] Learning goals for MVP articulated
|
||||
- [ ] Timeline expectations set
|
||||
|
||||
## 3. USER EXPERIENCE REQUIREMENTS
|
||||
|
||||
[[LLM: UX requirements bridge user needs and technical implementation. Validate:
|
||||
|
||||
1. User flows cover the primary use cases completely
|
||||
2. Edge cases are identified (even if deferred)
|
||||
3. Accessibility isn't an afterthought
|
||||
4. Performance expectations are realistic
|
||||
5. Error states and recovery are planned]]
|
||||
|
||||
### 3.1 User Journeys & Flows
|
||||
|
||||
- [ ] Primary user flows documented
|
||||
- [ ] Entry and exit points for each flow identified
|
||||
- [ ] Decision points and branches mapped
|
||||
- [ ] Critical path highlighted
|
||||
- [ ] Edge cases considered
|
||||
|
||||
### 3.2 Usability Requirements
|
||||
|
||||
- [ ] Accessibility considerations documented
|
||||
- [ ] Platform/device compatibility specified
|
||||
- [ ] Performance expectations from user perspective defined
|
||||
- [ ] Error handling and recovery approaches outlined
|
||||
- [ ] User feedback mechanisms identified
|
||||
|
||||
### 3.3 UI Requirements
|
||||
|
||||
- [ ] Information architecture outlined
|
||||
- [ ] Critical UI components identified
|
||||
- [ ] Visual design guidelines referenced (if applicable)
|
||||
- [ ] Content requirements specified
|
||||
- [ ] High-level navigation structure defined
|
||||
|
||||
## 4. FUNCTIONAL REQUIREMENTS
|
||||
|
||||
[[LLM: Functional requirements must be clear enough for implementation. Check:
|
||||
|
||||
1. Requirements focus on WHAT not HOW (no implementation details)
|
||||
2. Each requirement is testable (how would QA verify it?)
|
||||
3. Dependencies are explicit (what needs to be built first?)
|
||||
4. Requirements use consistent terminology
|
||||
5. Complex features are broken into manageable pieces]]
|
||||
|
||||
### 4.1 Feature Completeness
|
||||
|
||||
- [ ] All required features for MVP documented
|
||||
- [ ] Features have clear, user-focused descriptions
|
||||
- [ ] Feature priority/criticality indicated
|
||||
- [ ] Requirements are testable and verifiable
|
||||
- [ ] Dependencies between features identified
|
||||
|
||||
### 4.2 Requirements Quality
|
||||
|
||||
- [ ] Requirements are specific and unambiguous
|
||||
- [ ] Requirements focus on WHAT not HOW
|
||||
- [ ] Requirements use consistent terminology
|
||||
- [ ] Complex requirements broken into simpler parts
|
||||
- [ ] Technical jargon minimized or explained
|
||||
|
||||
### 4.3 User Stories & Acceptance Criteria
|
||||
|
||||
- [ ] Stories follow consistent format
|
||||
- [ ] Acceptance criteria are testable
|
||||
- [ ] Stories are sized appropriately (not too large)
|
||||
- [ ] Stories are independent where possible
|
||||
- [ ] Stories include necessary context
|
||||
- [ ] Local testability requirements (e.g., via CLI) defined in ACs for relevant backend/data stories
|
||||
|
||||
## 5. NON-FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### 5.1 Performance Requirements
|
||||
|
||||
- [ ] Response time expectations defined
|
||||
- [ ] Throughput/capacity requirements specified
|
||||
- [ ] Scalability needs documented
|
||||
- [ ] Resource utilization constraints identified
|
||||
- [ ] Load handling expectations set
|
||||
|
||||
### 5.2 Security & Compliance
|
||||
|
||||
- [ ] Data protection requirements specified
|
||||
- [ ] Authentication/authorization needs defined
|
||||
- [ ] Compliance requirements documented
|
||||
- [ ] Security testing requirements outlined
|
||||
- [ ] Privacy considerations addressed
|
||||
|
||||
### 5.3 Reliability & Resilience
|
||||
|
||||
- [ ] Availability requirements defined
|
||||
- [ ] Backup and recovery needs documented
|
||||
- [ ] Fault tolerance expectations set
|
||||
- [ ] Error handling requirements specified
|
||||
- [ ] Maintenance and support considerations included
|
||||
|
||||
### 5.4 Technical Constraints
|
||||
|
||||
- [ ] Platform/technology constraints documented
|
||||
- [ ] Integration requirements outlined
|
||||
- [ ] Third-party service dependencies identified
|
||||
- [ ] Infrastructure requirements specified
|
||||
- [ ] Development environment needs identified
|
||||
|
||||
## 6. EPIC & STORY STRUCTURE
|
||||
|
||||
### 6.1 Epic Definition
|
||||
|
||||
- [ ] Epics represent cohesive units of functionality
|
||||
- [ ] Epics focus on user/business value delivery
|
||||
- [ ] Epic goals clearly articulated
|
||||
- [ ] Epics are sized appropriately for incremental delivery
|
||||
- [ ] Epic sequence and dependencies identified
|
||||
|
||||
### 6.2 Story Breakdown
|
||||
|
||||
- [ ] Stories are broken down to appropriate size
|
||||
- [ ] Stories have clear, independent value
|
||||
- [ ] Stories include appropriate acceptance criteria
|
||||
- [ ] Story dependencies and sequence documented
|
||||
- [ ] Stories aligned with epic goals
|
||||
|
||||
### 6.3 First Epic Completeness
|
||||
|
||||
- [ ] First epic includes all necessary setup steps
|
||||
- [ ] Project scaffolding and initialization addressed
|
||||
- [ ] Core infrastructure setup included
|
||||
- [ ] Development environment setup addressed
|
||||
- [ ] Local testability established early
|
||||
|
||||
## 7. TECHNICAL GUIDANCE
|
||||
|
||||
### 7.1 Architecture Guidance
|
||||
|
||||
- [ ] Initial architecture direction provided
|
||||
- [ ] Technical constraints clearly communicated
|
||||
- [ ] Integration points identified
|
||||
- [ ] Performance considerations highlighted
|
||||
- [ ] Security requirements articulated
|
||||
- [ ] Known areas of high complexity or technical risk flagged for architectural deep-dive
|
||||
|
||||
### 7.2 Technical Decision Framework
|
||||
|
||||
- [ ] Decision criteria for technical choices provided
|
||||
- [ ] Trade-offs articulated for key decisions
|
||||
- [ ] Rationale for selecting primary approach over considered alternatives documented (for key design/feature choices)
|
||||
- [ ] Non-negotiable technical requirements highlighted
|
||||
- [ ] Areas requiring technical investigation identified
|
||||
- [ ] Guidance on technical debt approach provided
|
||||
|
||||
### 7.3 Implementation Considerations
|
||||
|
||||
- [ ] Development approach guidance provided
|
||||
- [ ] Testing requirements articulated
|
||||
- [ ] Deployment expectations set
|
||||
- [ ] Monitoring needs identified
|
||||
- [ ] Documentation requirements specified
|
||||
|
||||
## 8. CROSS-FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### 8.1 Data Requirements
|
||||
|
||||
- [ ] Data entities and relationships identified
|
||||
- [ ] Data storage requirements specified
|
||||
- [ ] Data quality requirements defined
|
||||
- [ ] Data retention policies identified
|
||||
- [ ] Data migration needs addressed (if applicable)
|
||||
- [ ] Schema changes planned iteratively, tied to stories requiring them
|
||||
|
||||
### 8.2 Integration Requirements
|
||||
|
||||
- [ ] External system integrations identified
|
||||
- [ ] API requirements documented
|
||||
- [ ] Authentication for integrations specified
|
||||
- [ ] Data exchange formats defined
|
||||
- [ ] Integration testing requirements outlined
|
||||
|
||||
### 8.3 Operational Requirements
|
||||
|
||||
- [ ] Deployment frequency expectations set
|
||||
- [ ] Environment requirements defined
|
||||
- [ ] Monitoring and alerting needs identified
|
||||
- [ ] Support requirements documented
|
||||
- [ ] Performance monitoring approach specified
|
||||
|
||||
## 9. CLARITY & COMMUNICATION
|
||||
|
||||
### 9.1 Documentation Quality
|
||||
|
||||
- [ ] Documents use clear, consistent language
|
||||
- [ ] Documents are well-structured and organized
|
||||
- [ ] Technical terms are defined where necessary
|
||||
- [ ] Diagrams/visuals included where helpful
|
||||
- [ ] Documentation is versioned appropriately
|
||||
|
||||
### 9.2 Stakeholder Alignment
|
||||
|
||||
- [ ] Key stakeholders identified
|
||||
- [ ] Stakeholder input incorporated
|
||||
- [ ] Potential areas of disagreement addressed
|
||||
- [ ] Communication plan for updates established
|
||||
- [ ] Approval process defined
|
||||
|
||||
## PRD & EPIC VALIDATION SUMMARY
|
||||
|
||||
[[LLM: FINAL PM CHECKLIST REPORT GENERATION
|
||||
|
||||
Create a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall PRD completeness (percentage)
|
||||
- MVP scope appropriateness (Too Large/Just Right/Too Small)
|
||||
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
|
||||
- Most critical gaps or concerns
|
||||
|
||||
2. Category Analysis Table
|
||||
Fill in the actual table with:
|
||||
|
||||
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
|
||||
- Critical Issues: Specific problems that block progress
|
||||
|
||||
3. Top Issues by Priority
|
||||
|
||||
- BLOCKERS: Must fix before architect can proceed
|
||||
- HIGH: Should fix for quality
|
||||
- MEDIUM: Would improve clarity
|
||||
- LOW: Nice to have
|
||||
|
||||
4. MVP Scope Assessment
|
||||
|
||||
- Features that might be cut for true MVP
|
||||
- Missing features that are essential
|
||||
- Complexity concerns
|
||||
- Timeline realism
|
||||
|
||||
5. Technical Readiness
|
||||
|
||||
- Clarity of technical constraints
|
||||
- Identified technical risks
|
||||
- Areas needing architect investigation
|
||||
|
||||
6. Recommendations
|
||||
- Specific actions to address each blocker
|
||||
- Suggested improvements
|
||||
- Next steps
|
||||
|
||||
After presenting the report, ask if the user wants:
|
||||
|
||||
- Detailed analysis of any failed sections
|
||||
- Suggestions for improving specific areas
|
||||
- Help with refining MVP scope]]
|
||||
|
||||
### Category Statuses
|
||||
|
||||
| Category | Status | Critical Issues |
|
||||
| -------------------------------- | ------ | --------------- |
|
||||
| 1. Problem Definition & Context | _TBD_ | |
|
||||
| 2. MVP Scope Definition | _TBD_ | |
|
||||
| 3. User Experience Requirements | _TBD_ | |
|
||||
| 4. Functional Requirements | _TBD_ | |
|
||||
| 5. Non-Functional Requirements | _TBD_ | |
|
||||
| 6. Epic & Story Structure | _TBD_ | |
|
||||
| 7. Technical Guidance | _TBD_ | |
|
||||
| 8. Cross-Functional Requirements | _TBD_ | |
|
||||
| 9. Clarity & Communication | _TBD_ | |
|
||||
|
||||
### Critical Deficiencies
|
||||
|
||||
_To be populated during validation_
|
||||
|
||||
### Recommendations
|
||||
|
||||
_To be populated during validation_
|
||||
|
||||
### Final Decision
|
||||
|
||||
- **READY FOR ARCHITECT**: The PRD and epics are comprehensive, properly structured, and ready for architectural design.
|
||||
- **NEEDS REFINEMENT**: The requirements documentation requires additional work to address the identified deficiencies.
|
||||
@@ -1,441 +0,0 @@
|
||||
# Product Owner (PO) Master Validation Checklist
|
||||
|
||||
This checklist serves as a comprehensive framework for the Product Owner to validate project plans before development execution. It adapts intelligently based on project type (greenfield vs brownfield) and includes UI/UX considerations when applicable.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
|
||||
|
||||
PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
3. Does the project include UI/UX components?
|
||||
- Check for: frontend-architecture.md, UI/UX specifications, design files
|
||||
- Look for: Frontend stories, component specifications, user interface mentions
|
||||
|
||||
DOCUMENT REQUIREMENTS:
|
||||
Based on project type, ensure you have access to:
|
||||
|
||||
For GREENFIELD projects:
|
||||
|
||||
- prd.md - The Product Requirements Document
|
||||
- architecture.md - The system architecture
|
||||
- frontend-architecture.md - If UI/UX is involved
|
||||
- All epic and story definitions
|
||||
|
||||
For BROWNFIELD projects:
|
||||
|
||||
- brownfield-prd.md - The brownfield enhancement requirements
|
||||
- brownfield-architecture.md - The enhancement architecture
|
||||
- Existing project codebase access (CRITICAL - cannot proceed without this)
|
||||
- Current deployment configuration and infrastructure details
|
||||
- Database schemas, API documentation, monitoring setup
|
||||
|
||||
SKIP INSTRUCTIONS:
|
||||
|
||||
- Skip sections marked [[BROWNFIELD ONLY]] for greenfield projects
|
||||
- Skip sections marked [[GREENFIELD ONLY]] for brownfield projects
|
||||
- Skip sections marked [[UI/UX ONLY]] for backend-only projects
|
||||
- Note all skipped sections in your final report
|
||||
|
||||
VALIDATION APPROACH:
|
||||
|
||||
1. Deep Analysis - Thoroughly analyze each item against documentation
|
||||
2. Evidence-Based - Cite specific sections or code when validating
|
||||
3. Critical Thinking - Question assumptions and identify gaps
|
||||
4. Risk Assessment - Consider what could go wrong with each decision
|
||||
|
||||
EXECUTION MODE:
|
||||
Ask the user if they want to work through the checklist:
|
||||
|
||||
- Section by section (interactive mode) - Review each section, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present report at end]]
|
||||
|
||||
## 1. PROJECT SETUP & INITIALIZATION
|
||||
|
||||
[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
|
||||
|
||||
### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
|
||||
|
||||
- [ ] Epic 1 includes explicit steps for project creation/initialization
|
||||
- [ ] If using a starter template, steps for cloning/setup are included
|
||||
- [ ] If building from scratch, all necessary scaffolding steps are defined
|
||||
- [ ] Initial README or documentation setup is included
|
||||
- [ ] Repository setup and initial commit processes are defined
|
||||
|
||||
### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
|
||||
|
||||
- [ ] Existing project analysis has been completed and documented
|
||||
- [ ] Integration points with current system are identified
|
||||
- [ ] Development environment preserves existing functionality
|
||||
- [ ] Local testing approach validated for existing features
|
||||
- [ ] Rollback procedures defined for each integration point
|
||||
|
||||
### 1.3 Development Environment
|
||||
|
||||
- [ ] Local development environment setup is clearly defined
|
||||
- [ ] Required tools and versions are specified
|
||||
- [ ] Steps for installing dependencies are included
|
||||
- [ ] Configuration files are addressed appropriately
|
||||
- [ ] Development server setup is included
|
||||
|
||||
### 1.4 Core Dependencies
|
||||
|
||||
- [ ] All critical packages/libraries are installed early
|
||||
- [ ] Package management is properly addressed
|
||||
- [ ] Version specifications are appropriately defined
|
||||
- [ ] Dependency conflicts or special requirements are noted
|
||||
- [ ] [[BROWNFIELD ONLY]] Version compatibility with existing stack verified
|
||||
|
||||
## 2. INFRASTRUCTURE & DEPLOYMENT
|
||||
|
||||
[[LLM: Infrastructure must exist before use. For brownfield, must integrate with existing infrastructure without breaking it.]]
|
||||
|
||||
### 2.1 Database & Data Store Setup
|
||||
|
||||
- [ ] Database selection/setup occurs before any operations
|
||||
- [ ] Schema definitions are created before data operations
|
||||
- [ ] Migration strategies are defined if applicable
|
||||
- [ ] Seed data or initial data setup is included if needed
|
||||
- [ ] [[BROWNFIELD ONLY]] Database migration risks identified and mitigated
|
||||
- [ ] [[BROWNFIELD ONLY]] Backward compatibility ensured
|
||||
|
||||
### 2.2 API & Service Configuration
|
||||
|
||||
- [ ] API frameworks are set up before implementing endpoints
|
||||
- [ ] Service architecture is established before implementing services
|
||||
- [ ] Authentication framework is set up before protected routes
|
||||
- [ ] Middleware and common utilities are created before use
|
||||
- [ ] [[BROWNFIELD ONLY]] API compatibility with existing system maintained
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration with existing authentication preserved
|
||||
|
||||
### 2.3 Deployment Pipeline
|
||||
|
||||
- [ ] CI/CD pipeline is established before deployment actions
|
||||
- [ ] Infrastructure as Code (IaC) is set up before use
|
||||
- [ ] Environment configurations are defined early
|
||||
- [ ] Deployment strategies are defined before implementation
|
||||
- [ ] [[BROWNFIELD ONLY]] Deployment minimizes downtime
|
||||
- [ ] [[BROWNFIELD ONLY]] Blue-green or canary deployment implemented
|
||||
|
||||
### 2.4 Testing Infrastructure
|
||||
|
||||
- [ ] Testing frameworks are installed before writing tests
|
||||
- [ ] Test environment setup precedes test implementation
|
||||
- [ ] Mock services or data are defined before testing
|
||||
- [ ] [[BROWNFIELD ONLY]] Regression testing covers existing functionality
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration testing validates new-to-existing connections
|
||||
|
||||
## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
|
||||
|
||||
[[LLM: External dependencies often block progress. For brownfield, ensure new dependencies don't conflict with existing ones.]]
|
||||
|
||||
### 3.1 Third-Party Services
|
||||
|
||||
- [ ] Account creation steps are identified for required services
|
||||
- [ ] API key acquisition processes are defined
|
||||
- [ ] Steps for securely storing credentials are included
|
||||
- [ ] Fallback or offline development options are considered
|
||||
- [ ] [[BROWNFIELD ONLY]] Compatibility with existing services verified
|
||||
- [ ] [[BROWNFIELD ONLY]] Impact on existing integrations assessed
|
||||
|
||||
### 3.2 External APIs
|
||||
|
||||
- [ ] Integration points with external APIs are clearly identified
|
||||
- [ ] Authentication with external services is properly sequenced
|
||||
- [ ] API limits or constraints are acknowledged
|
||||
- [ ] Backup strategies for API failures are considered
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing API dependencies maintained
|
||||
|
||||
### 3.3 Infrastructure Services
|
||||
|
||||
- [ ] Cloud resource provisioning is properly sequenced
|
||||
- [ ] DNS or domain registration needs are identified
|
||||
- [ ] Email or messaging service setup is included if needed
|
||||
- [ ] CDN or static asset hosting setup precedes their use
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing infrastructure services preserved
|
||||
|
||||
## 4. UI/UX CONSIDERATIONS [[UI/UX ONLY]]
|
||||
|
||||
[[LLM: Only evaluate this section if the project includes user interface components. Skip entirely for backend-only projects.]]
|
||||
|
||||
### 4.1 Design System Setup
|
||||
|
||||
- [ ] UI framework and libraries are selected and installed early
|
||||
- [ ] Design system or component library is established
|
||||
- [ ] Styling approach (CSS modules, styled-components, etc.) is defined
|
||||
- [ ] Responsive design strategy is established
|
||||
- [ ] Accessibility requirements are defined upfront
|
||||
|
||||
### 4.2 Frontend Infrastructure
|
||||
|
||||
- [ ] Frontend build pipeline is configured before development
|
||||
- [ ] Asset optimization strategy is defined
|
||||
- [ ] Frontend testing framework is set up
|
||||
- [ ] Component development workflow is established
|
||||
- [ ] [[BROWNFIELD ONLY]] UI consistency with existing system maintained
|
||||
|
||||
### 4.3 User Experience Flow
|
||||
|
||||
- [ ] User journeys are mapped before implementation
|
||||
- [ ] Navigation patterns are defined early
|
||||
- [ ] Error states and loading states are planned
|
||||
- [ ] Form validation patterns are established
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing user workflows preserved or migrated
|
||||
|
||||
## 5. USER/AGENT RESPONSIBILITY
|
||||
|
||||
[[LLM: Clear ownership prevents confusion. Ensure tasks are assigned appropriately based on what only humans can do.]]
|
||||
|
||||
### 5.1 User Actions
|
||||
|
||||
- [ ] User responsibilities limited to human-only tasks
|
||||
- [ ] Account creation on external services assigned to users
|
||||
- [ ] Purchasing or payment actions assigned to users
|
||||
- [ ] Credential provision appropriately assigned to users
|
||||
|
||||
### 5.2 Developer Agent Actions
|
||||
|
||||
- [ ] All code-related tasks assigned to developer agents
|
||||
- [ ] Automated processes identified as agent responsibilities
|
||||
- [ ] Configuration management properly assigned
|
||||
- [ ] Testing and validation assigned to appropriate agents
|
||||
|
||||
## 6. FEATURE SEQUENCING & DEPENDENCIES
|
||||
|
||||
[[LLM: Dependencies create the critical path. For brownfield, ensure new features don't break existing ones.]]
|
||||
|
||||
### 6.1 Functional Dependencies
|
||||
|
||||
- [ ] Features depending on others are sequenced correctly
|
||||
- [ ] Shared components are built before their use
|
||||
- [ ] User flows follow logical progression
|
||||
- [ ] Authentication features precede protected features
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing functionality preserved throughout
|
||||
|
||||
### 6.2 Technical Dependencies
|
||||
|
||||
- [ ] Lower-level services built before higher-level ones
|
||||
- [ ] Libraries and utilities created before their use
|
||||
- [ ] Data models defined before operations on them
|
||||
- [ ] API endpoints defined before client consumption
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration points tested at each step
|
||||
|
||||
### 6.3 Cross-Epic Dependencies
|
||||
|
||||
- [ ] Later epics build upon earlier epic functionality
|
||||
- [ ] No epic requires functionality from later epics
|
||||
- [ ] Infrastructure from early epics utilized consistently
|
||||
- [ ] Incremental value delivery maintained
|
||||
- [ ] [[BROWNFIELD ONLY]] Each epic maintains system integrity
|
||||
|
||||
## 7. RISK MANAGEMENT [[BROWNFIELD ONLY]]
|
||||
|
||||
[[LLM: This section is CRITICAL for brownfield projects. Think pessimistically about what could break.]]
|
||||
|
||||
### 7.1 Breaking Change Risks
|
||||
|
||||
- [ ] Risk of breaking existing functionality assessed
|
||||
- [ ] Database migration risks identified and mitigated
|
||||
- [ ] API breaking change risks evaluated
|
||||
- [ ] Performance degradation risks identified
|
||||
- [ ] Security vulnerability risks evaluated
|
||||
|
||||
### 7.2 Rollback Strategy
|
||||
|
||||
- [ ] Rollback procedures clearly defined per story
|
||||
- [ ] Feature flag strategy implemented
|
||||
- [ ] Backup and recovery procedures updated
|
||||
- [ ] Monitoring enhanced for new components
|
||||
- [ ] Rollback triggers and thresholds defined
|
||||
|
||||
### 7.3 User Impact Mitigation
|
||||
|
||||
- [ ] Existing user workflows analyzed for impact
|
||||
- [ ] User communication plan developed
|
||||
- [ ] Training materials updated
|
||||
- [ ] Support documentation comprehensive
|
||||
- [ ] Migration path for user data validated
|
||||
|
||||
## 8. MVP SCOPE ALIGNMENT
|
||||
|
||||
[[LLM: MVP means MINIMUM viable product. For brownfield, ensure enhancements are truly necessary.]]
|
||||
|
||||
### 8.1 Core Goals Alignment
|
||||
|
||||
- [ ] All core goals from PRD are addressed
|
||||
- [ ] Features directly support MVP goals
|
||||
- [ ] No extraneous features beyond MVP scope
|
||||
- [ ] Critical features prioritized appropriately
|
||||
- [ ] [[BROWNFIELD ONLY]] Enhancement complexity justified
|
||||
|
||||
### 8.2 User Journey Completeness
|
||||
|
||||
- [ ] All critical user journeys fully implemented
|
||||
- [ ] Edge cases and error scenarios addressed
|
||||
- [ ] User experience considerations included
|
||||
- [ ] [[UI/UX ONLY]] Accessibility requirements incorporated
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing workflows preserved or improved
|
||||
|
||||
### 8.3 Technical Requirements
|
||||
|
||||
- [ ] All technical constraints from PRD addressed
|
||||
- [ ] Non-functional requirements incorporated
|
||||
- [ ] Architecture decisions align with constraints
|
||||
- [ ] Performance considerations addressed
|
||||
- [ ] [[BROWNFIELD ONLY]] Compatibility requirements met
|
||||
|
||||
## 9. DOCUMENTATION & HANDOFF
|
||||
|
||||
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
|
||||
|
||||
### 9.1 Developer Documentation
|
||||
|
||||
- [ ] API documentation created alongside implementation
|
||||
- [ ] Setup instructions are comprehensive
|
||||
- [ ] Architecture decisions documented
|
||||
- [ ] Patterns and conventions documented
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
|
||||
|
||||
### 9.2 User Documentation
|
||||
|
||||
- [ ] User guides or help documentation included if required
|
||||
- [ ] Error messages and user feedback considered
|
||||
- [ ] Onboarding flows fully specified
|
||||
- [ ] [[BROWNFIELD ONLY]] Changes to existing features documented
|
||||
|
||||
### 9.3 Knowledge Transfer
|
||||
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
|
||||
- [ ] Code review knowledge sharing planned
|
||||
- [ ] Deployment knowledge transferred to operations
|
||||
- [ ] Historical context preserved
|
||||
|
||||
## 10. POST-MVP CONSIDERATIONS
|
||||
|
||||
[[LLM: Planning for success prevents technical debt. For brownfield, ensure enhancements don't limit future growth.]]
|
||||
|
||||
### 10.1 Future Enhancements
|
||||
|
||||
- [ ] Clear separation between MVP and future features
|
||||
- [ ] Architecture supports planned enhancements
|
||||
- [ ] Technical debt considerations documented
|
||||
- [ ] Extensibility points identified
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration patterns reusable
|
||||
|
||||
### 10.2 Monitoring & Feedback
|
||||
|
||||
- [ ] Analytics or usage tracking included if required
|
||||
- [ ] User feedback collection considered
|
||||
- [ ] Monitoring and alerting addressed
|
||||
- [ ] Performance measurement incorporated
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing monitoring preserved/enhanced
|
||||
|
||||
## VALIDATION SUMMARY
|
||||
|
||||
[[LLM: FINAL PO VALIDATION REPORT GENERATION
|
||||
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
- Critical blocking issues count
|
||||
- Sections skipped due to project type
|
||||
|
||||
2. Project-Specific Analysis
|
||||
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
- Post-MVP deferrals
|
||||
|
||||
7. [BROWNFIELD ONLY] Integration Confidence
|
||||
- Confidence in preserving existing functionality
|
||||
- Rollback procedure completeness
|
||||
- Monitoring coverage for integration points
|
||||
- Support team readiness
|
||||
|
||||
After presenting the report, ask if the user wants:
|
||||
|
||||
- Detailed analysis of any failed sections
|
||||
- Specific story resequencing suggestions
|
||||
- Risk mitigation strategies
|
||||
- [BROWNFIELD] Integration risk deep-dive]]
|
||||
|
||||
### Category Statuses
|
||||
|
||||
| Category | Status | Critical Issues |
|
||||
| --------------------------------------- | ------ | --------------- |
|
||||
| 1. Project Setup & Initialization | _TBD_ | |
|
||||
| 2. Infrastructure & Deployment | _TBD_ | |
|
||||
| 3. External Dependencies & Integrations | _TBD_ | |
|
||||
| 4. UI/UX Considerations | _TBD_ | |
|
||||
| 5. User/Agent Responsibility | _TBD_ | |
|
||||
| 6. Feature Sequencing & Dependencies | _TBD_ | |
|
||||
| 7. Risk Management (Brownfield) | _TBD_ | |
|
||||
| 8. MVP Scope Alignment | _TBD_ | |
|
||||
| 9. Documentation & Handoff | _TBD_ | |
|
||||
| 10. Post-MVP Considerations | _TBD_ | |
|
||||
|
||||
### Critical Deficiencies
|
||||
|
||||
_To be populated during validation_
|
||||
|
||||
### Recommendations
|
||||
|
||||
_To be populated during validation_
|
||||
|
||||
### Final Decision
|
||||
|
||||
- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
|
||||
- **CONDITIONAL**: The plan requires specific adjustments before proceeding.
|
||||
- **REJECTED**: The plan requires significant revision to address critical deficiencies.
|
||||
@@ -1,101 +0,0 @@
|
||||
# Story Definition of Done (DoD) Checklist
|
||||
|
||||
## Instructions for Developer Agent
|
||||
|
||||
Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - STORY DOD VALIDATION
|
||||
|
||||
This checklist is for DEVELOPER AGENTS to self-validate their work before marking a story complete.
|
||||
|
||||
IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
|
||||
|
||||
EXECUTION APPROACH:
|
||||
|
||||
1. Go through each section systematically
|
||||
2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
|
||||
3. Add brief comments explaining any [ ] or [N/A] items
|
||||
4. Be specific about what was actually implemented
|
||||
5. Flag any concerns or technical debt created
|
||||
|
||||
The goal is quality delivery, not just checking boxes.]]
|
||||
|
||||
## Checklist Items
|
||||
|
||||
1. **Requirements Met:**
|
||||
|
||||
[[LLM: Be specific - list each requirement and whether it's complete]]
|
||||
|
||||
- [ ] All functional requirements specified in the story are implemented.
|
||||
- [ ] All acceptance criteria defined in the story are met.
|
||||
|
||||
2. **Coding Standards & Project Structure:**
|
||||
|
||||
[[LLM: Code quality matters for maintainability. Check each item carefully]]
|
||||
|
||||
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
|
||||
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
|
||||
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
|
||||
- [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
|
||||
- [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
|
||||
- [ ] No new linter errors or warnings introduced.
|
||||
- [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
|
||||
|
||||
3. **Testing:**
|
||||
|
||||
[[LLM: Testing proves your code works. Be honest about test coverage]]
|
||||
|
||||
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
||||
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
||||
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
|
||||
- [ ] Test coverage meets project standards (if defined).
|
||||
|
||||
4. **Functionality & Verification:**
|
||||
|
||||
[[LLM: Did you actually run and test your code? Be specific about what you tested]]
|
||||
|
||||
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
|
||||
- [ ] Edge cases and potential error conditions considered and handled gracefully.
|
||||
|
||||
5. **Story Administration:**
|
||||
|
||||
[[LLM: Documentation helps the next developer. What should they know?]]
|
||||
|
||||
- [ ] All tasks within the story file are marked as complete.
|
||||
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
|
||||
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
|
||||
|
||||
6. **Dependencies, Build & Configuration:**
|
||||
|
||||
[[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
|
||||
|
||||
- [ ] Project builds successfully without errors.
|
||||
- [ ] Project linting passes
|
||||
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
|
||||
- [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
|
||||
- [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
|
||||
- [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
|
||||
|
||||
7. **Documentation (If Applicable):**
|
||||
|
||||
[[LLM: Good documentation prevents future confusion. What needs explaining?]]
|
||||
|
||||
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
|
||||
- [ ] User-facing documentation updated, if changes impact users.
|
||||
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
|
||||
|
||||
## Final Confirmation
|
||||
|
||||
[[LLM: FINAL DOD SUMMARY
|
||||
|
||||
After completing the checklist:
|
||||
|
||||
1. Summarize what was accomplished in this story
|
||||
2. List any items marked as [ ] Not Done with explanations
|
||||
3. Identify any technical debt or follow-up work needed
|
||||
4. Note any challenges or learnings for future stories
|
||||
5. Confirm whether the story is truly ready for review
|
||||
|
||||
Be honest - it's better to flag issues now than have them discovered later.]]
|
||||
|
||||
- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
|
||||
@@ -1,156 +0,0 @@
|
||||
# Story Draft Checklist
|
||||
|
||||
The Scrum Master should use this checklist to validate that each story contains sufficient context for a developer agent to implement it successfully, while assuming the dev agent has reasonable capabilities to figure things out.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - STORY DRAFT VALIDATION
|
||||
|
||||
Before proceeding with this checklist, ensure you have access to:
|
||||
|
||||
1. The story document being validated (usually in docs/stories/ or provided directly)
|
||||
2. The parent epic context
|
||||
3. Any referenced architecture or design documents
|
||||
4. Previous related stories if this builds on prior work
|
||||
|
||||
IMPORTANT: This checklist validates individual stories BEFORE implementation begins.
|
||||
|
||||
VALIDATION PRINCIPLES:
|
||||
|
||||
1. Clarity - A developer should understand WHAT to build
|
||||
2. Context - WHY this is being built and how it fits
|
||||
3. Guidance - Key technical decisions and patterns to follow
|
||||
4. Testability - How to verify the implementation works
|
||||
5. Self-Contained - Most info needed is in the story itself
|
||||
|
||||
REMEMBER: We assume competent developer agents who can:
|
||||
|
||||
- Research documentation and codebases
|
||||
- Make reasonable technical decisions
|
||||
- Follow established patterns
|
||||
- Ask for clarification when truly stuck
|
||||
|
||||
We're checking for SUFFICIENT guidance, not exhaustive detail.]]
|
||||
|
||||
## 1. GOAL & CONTEXT CLARITY
|
||||
|
||||
[[LLM: Without clear goals, developers build the wrong thing. Verify:
|
||||
|
||||
1. The story states WHAT functionality to implement
|
||||
2. The business value or user benefit is clear
|
||||
3. How this fits into the larger epic/product is explained
|
||||
4. Dependencies are explicit ("requires Story X to be complete")
|
||||
5. Success looks like something specific, not vague]]
|
||||
|
||||
- [ ] Story goal/purpose is clearly stated
|
||||
- [ ] Relationship to epic goals is evident
|
||||
- [ ] How the story fits into overall system flow is explained
|
||||
- [ ] Dependencies on previous stories are identified (if applicable)
|
||||
- [ ] Business context and value are clear
|
||||
|
||||
## 2. TECHNICAL IMPLEMENTATION GUIDANCE
|
||||
|
||||
[[LLM: Developers need enough technical context to start coding. Check:
|
||||
|
||||
1. Key files/components to create or modify are mentioned
|
||||
2. Technology choices are specified where non-obvious
|
||||
3. Integration points with existing code are identified
|
||||
4. Data models or API contracts are defined or referenced
|
||||
5. Non-standard patterns or exceptions are called out
|
||||
|
||||
Note: We don't need every file listed - just the important ones.]]
|
||||
|
||||
- [ ] Key files to create/modify are identified (not necessarily exhaustive)
|
||||
- [ ] Technologies specifically needed for this story are mentioned
|
||||
- [ ] Critical APIs or interfaces are sufficiently described
|
||||
- [ ] Necessary data models or structures are referenced
|
||||
- [ ] Required environment variables are listed (if applicable)
|
||||
- [ ] Any exceptions to standard coding patterns are noted
|
||||
|
||||
## 3. REFERENCE EFFECTIVENESS
|
||||
|
||||
[[LLM: References should help, not create a treasure hunt. Ensure:
|
||||
|
||||
1. References point to specific sections, not whole documents
|
||||
2. The relevance of each reference is explained
|
||||
3. Critical information is summarized in the story
|
||||
4. References are accessible (not broken links)
|
||||
5. Previous story context is summarized if needed]]
|
||||
|
||||
- [ ] References to external documents point to specific relevant sections
|
||||
- [ ] Critical information from previous stories is summarized (not just referenced)
|
||||
- [ ] Context is provided for why references are relevant
|
||||
- [ ] References use consistent format (e.g., `docs/filename.md#section`)
|
||||
|
||||
## 4. SELF-CONTAINMENT ASSESSMENT
|
||||
|
||||
[[LLM: Stories should be mostly self-contained to avoid context switching. Verify:
|
||||
|
||||
1. Core requirements are in the story, not just in references
|
||||
2. Domain terms are explained or obvious from context
|
||||
3. Assumptions are stated explicitly
|
||||
4. Edge cases are mentioned (even if deferred)
|
||||
5. The story could be understood without reading 10 other documents]]
|
||||
|
||||
- [ ] Core information needed is included (not overly reliant on external docs)
|
||||
- [ ] Implicit assumptions are made explicit
|
||||
- [ ] Domain-specific terms or concepts are explained
|
||||
- [ ] Edge cases or error scenarios are addressed
|
||||
|
||||
## 5. TESTING GUIDANCE
|
||||
|
||||
[[LLM: Testing ensures the implementation actually works. Check:
|
||||
|
||||
1. Test approach is specified (unit, integration, e2e)
|
||||
2. Key test scenarios are listed
|
||||
3. Success criteria are measurable
|
||||
4. Special test considerations are noted
|
||||
5. Acceptance criteria in the story are testable]]
|
||||
|
||||
- [ ] Required testing approach is outlined
|
||||
- [ ] Key test scenarios are identified
|
||||
- [ ] Success criteria are defined
|
||||
- [ ] Special testing considerations are noted (if applicable)
|
||||
|
||||
## VALIDATION RESULT
|
||||
|
||||
[[LLM: FINAL STORY VALIDATION REPORT
|
||||
|
||||
Generate a concise validation report:
|
||||
|
||||
1. Quick Summary
|
||||
|
||||
- Story readiness: READY / NEEDS REVISION / BLOCKED
|
||||
- Clarity score (1-10)
|
||||
- Major gaps identified
|
||||
|
||||
2. Fill in the validation table with:
|
||||
|
||||
- PASS: Requirements clearly met
|
||||
- PARTIAL: Some gaps but workable
|
||||
- FAIL: Critical information missing
|
||||
|
||||
3. Specific Issues (if any)
|
||||
|
||||
- List concrete problems to fix
|
||||
- Suggest specific improvements
|
||||
- Identify any blocking dependencies
|
||||
|
||||
4. Developer Perspective
|
||||
- Could YOU implement this story as written?
|
||||
- What questions would you have?
|
||||
- What might cause delays or rework?
|
||||
|
||||
Be pragmatic - perfect documentation doesn't exist. Focus on whether a competent developer can succeed with this story.]]
|
||||
|
||||
| Category | Status | Issues |
|
||||
| ------------------------------------ | ------ | ------ |
|
||||
| 1. Goal & Context Clarity | _TBD_ | |
|
||||
| 2. Technical Implementation Guidance | _TBD_ | |
|
||||
| 3. Reference Effectiveness | _TBD_ | |
|
||||
| 4. Self-Containment Assessment | _TBD_ | |
|
||||
| 5. Testing Guidance | _TBD_ | |
|
||||
|
||||
**Final Assessment:**
|
||||
|
||||
- READY: The story provides sufficient context for implementation
|
||||
- NEEDS REVISION: The story requires updates (see issues)
|
||||
- BLOCKED: External information required (specify what information)
|
||||
Reference in New Issue
Block a user