Improve developer experience with shared tooling, cleaner docs. (#170)
* docs: add headers and improve formatting for BMAD orchestrator agent documentation ## CHANGES - Add configuration header to cfg file - Improve numbered list formatting consistency - Add proper heading punctuation throughout - Enhance readability with cleaner structure - Standardize markdown formatting conventions * gitignore update * Plaform Engineer role for a robust infrastructure (#135) * Add Platform Engineer role to support a robust and validated infrastructure * Platform Engineer and Architect boundaries, confidence levels, domain expertise * remove duplicate task, leftover artifact * Consistency, workflow, feedback loops between architect and PE * PE customization generalized, updated Architect, consistency check * style: add VSCode integration and standardize document formatting CHANGES - Introduce VSCode recommended extensions and project-specific settings. - Update `.gitignore` to track the `.vscode` directory. - Apply consistent markdown formatting to all checklist documents. - Standardize spacing, list styles, and headers in personas. - Refine formatting and sectioning in task definition files. - Ensure newline termination for all modified text files. - Correct code block specifiers and minor textual content. * docs: remove exclamation from header * fix: spacing at end of line --------- Co-authored-by: Brian Madison <brianmadison@Brians-MacBook-Pro.local> Co-authored-by: Sebastian Ickler <icklers@users.noreply.github.com>
This commit is contained in:
Kayvan Sylvan
2
.gitignore
vendored
2
.gitignore
vendored
@@ -16,6 +16,4 @@ build/
|
||||
# Environment variables
|
||||
.env
|
||||
|
||||
# VSCode settings
|
||||
.vscode/
|
||||
CLAUDE.md
|
||||
6
.vscode/extensions.json
vendored
Normal file
6
.vscode/extensions.json
vendored
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"recommendations": [
|
||||
"davidanson.vscode-markdownlint",
|
||||
"streetsidesoftware.code-spell-checker"
|
||||
]
|
||||
}
|
||||
40
.vscode/settings.json
vendored
Normal file
40
.vscode/settings.json
vendored
Normal file
@@ -0,0 +1,40 @@
|
||||
{
|
||||
"cSpell.words": [
|
||||
"agentic",
|
||||
"Axios",
|
||||
"BMAD",
|
||||
"Centricity",
|
||||
"dataclass",
|
||||
"docstrings",
|
||||
"emergently",
|
||||
"explorative",
|
||||
"frontends",
|
||||
"golint",
|
||||
"Goroutines",
|
||||
"HSTS",
|
||||
"httpx",
|
||||
"Immer",
|
||||
"implementability",
|
||||
"Inclusivity",
|
||||
"Luxon",
|
||||
"pasteable",
|
||||
"Pino",
|
||||
"Polyrepo",
|
||||
"Pydantic",
|
||||
"pyproject",
|
||||
"rescope",
|
||||
"roadmaps",
|
||||
"roleplay",
|
||||
"runbooks",
|
||||
"Serilog",
|
||||
"shadcn",
|
||||
"structlog",
|
||||
"Systemization",
|
||||
"taskroot",
|
||||
"Testcontainers",
|
||||
"tmpl",
|
||||
"VARCHAR",
|
||||
"venv",
|
||||
"WCAG"
|
||||
]
|
||||
}
|
||||
@@ -1,6 +1,6 @@
|
||||
# The BMAD-Method 3.1 (Breakthrough Method of Agile (ai-driven) Development)
|
||||
|
||||
## Do This First, and all will make sense!
|
||||
## Do This First, and all will make sense
|
||||
|
||||
There are lots of docs here, but I HIGHLY suggest you just try the Web Agent - it takes just a few minutes to set up in Gemini - and you can use the BMad Agent to explain how this method works, how to set up in the IDE, how to set up in the Web, what should be done in the web or ide (although you can choose your own path also!) - all just by talking to the bmad agent!
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@
|
||||
|
||||
## 5. Sprint Change Proposal Components
|
||||
|
||||
_(Ensure all agreed-upon points from previous sections are captured in the proposal)_
|
||||
(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.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
# Frontend Architecture Document Review Checklist
|
||||
|
||||
## Purpose
|
||||
|
||||
This checklist is for the Design Architect to use after completing the "Frontend Architecture Mode" and populating the `front-end-architecture-tmpl.txt` (or `.md`) document. It ensures all sections are comprehensively covered and meet quality standards before finalization.
|
||||
|
||||
---
|
||||
@@ -34,10 +35,12 @@ This checklist is for the Design Architect to use after completing the "Frontend
|
||||
## IV. Component Breakdown & Implementation Details
|
||||
|
||||
### Component Naming & Organization
|
||||
|
||||
- [ ] Are conventions for naming components (e.g., PascalCase) described?
|
||||
- [ ] Is the organization of components on the filesystem clearly explained (reiterating from directory structure if needed)?
|
||||
|
||||
### Template for Component Specification
|
||||
|
||||
- [ ] Is the "Template for Component Specification" itself complete and well-defined?
|
||||
- [ ] Does it include fields for: Purpose, Source File(s), Visual Reference?
|
||||
- [ ] Does it include a table structure for Props (Name, Type, Required, Default, Description)?
|
||||
@@ -50,6 +53,7 @@ This checklist is for the Design Architect to use after completing the "Frontend
|
||||
- [ ] Is there a clear statement that this template should be used for most feature-specific components?
|
||||
|
||||
### Foundational/Shared Components (if any specified upfront)
|
||||
|
||||
- [ ] If any foundational/shared UI components are specified, do they follow the "Template for Component Specification"?
|
||||
- [ ] Is the rationale for specifying these components upfront clear?
|
||||
|
||||
|
||||
@@ -5,6 +5,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 1. PROBLEM DEFINITION & CONTEXT
|
||||
|
||||
### 1.1 Problem Statement
|
||||
|
||||
- [ ] Clear articulation of the problem being solved
|
||||
- [ ] Identification of who experiences the problem
|
||||
- [ ] Explanation of why solving this problem matters
|
||||
@@ -12,6 +13,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] 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
|
||||
@@ -19,6 +21,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] 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)
|
||||
@@ -28,6 +31,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 2. MVP SCOPE DEFINITION
|
||||
|
||||
### 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
|
||||
@@ -35,6 +39,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] 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
|
||||
@@ -42,6 +47,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] 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
|
||||
@@ -51,6 +57,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 3. USER EXPERIENCE REQUIREMENTS
|
||||
|
||||
### 3.1 User Journeys & Flows
|
||||
|
||||
- [ ] Primary user flows documented
|
||||
- [ ] Entry and exit points for each flow identified
|
||||
- [ ] Decision points and branches mapped
|
||||
@@ -58,6 +65,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Edge cases considered
|
||||
|
||||
### 3.2 Usability Requirements
|
||||
|
||||
- [ ] Accessibility considerations documented
|
||||
- [ ] Platform/device compatibility specified
|
||||
- [ ] Performance expectations from user perspective defined
|
||||
@@ -65,6 +73,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] User feedback mechanisms identified
|
||||
|
||||
### 3.3 UI Requirements
|
||||
|
||||
- [ ] Information architecture outlined
|
||||
- [ ] Critical UI components identified
|
||||
- [ ] Visual design guidelines referenced (if applicable)
|
||||
@@ -74,6 +83,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 4. FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### 4.1 Feature Completeness
|
||||
|
||||
- [ ] All required features for MVP documented
|
||||
- [ ] Features have clear, user-focused descriptions
|
||||
- [ ] Feature priority/criticality indicated
|
||||
@@ -81,6 +91,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Dependencies between features identified
|
||||
|
||||
### 4.2 Requirements Quality
|
||||
|
||||
- [ ] Requirements are specific and unambiguous
|
||||
- [ ] Requirements focus on WHAT not HOW
|
||||
- [ ] Requirements use consistent terminology
|
||||
@@ -88,6 +99,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] 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)
|
||||
@@ -98,6 +110,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 5. NON-FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### 5.1 Performance Requirements
|
||||
|
||||
- [ ] Response time expectations defined
|
||||
- [ ] Throughput/capacity requirements specified
|
||||
- [ ] Scalability needs documented
|
||||
@@ -105,6 +118,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Load handling expectations set
|
||||
|
||||
### 5.2 Security & Compliance
|
||||
|
||||
- [ ] Data protection requirements specified
|
||||
- [ ] Authentication/authorization needs defined
|
||||
- [ ] Compliance requirements documented
|
||||
@@ -112,6 +126,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Privacy considerations addressed
|
||||
|
||||
### 5.3 Reliability & Resilience
|
||||
|
||||
- [ ] Availability requirements defined
|
||||
- [ ] Backup and recovery needs documented
|
||||
- [ ] Fault tolerance expectations set
|
||||
@@ -119,6 +134,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Maintenance and support considerations included
|
||||
|
||||
### 5.4 Technical Constraints
|
||||
|
||||
- [ ] Platform/technology constraints documented
|
||||
- [ ] Integration requirements outlined
|
||||
- [ ] Third-party service dependencies identified
|
||||
@@ -128,6 +144,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 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
|
||||
@@ -135,6 +152,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] 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
|
||||
@@ -142,6 +160,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] 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
|
||||
@@ -151,6 +170,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 7. TECHNICAL GUIDANCE
|
||||
|
||||
### 7.1 Architecture Guidance
|
||||
|
||||
- [ ] Initial architecture direction provided
|
||||
- [ ] Technical constraints clearly communicated
|
||||
- [ ] Integration points identified
|
||||
@@ -159,6 +179,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] 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)
|
||||
@@ -167,6 +188,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Guidance on technical debt approach provided
|
||||
|
||||
### 7.3 Implementation Considerations
|
||||
|
||||
- [ ] Development approach guidance provided
|
||||
- [ ] Testing requirements articulated
|
||||
- [ ] Deployment expectations set
|
||||
@@ -176,6 +198,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 8. CROSS-FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### 8.1 Data Requirements
|
||||
|
||||
- [ ] Data entities and relationships identified
|
||||
- [ ] Data storage requirements specified
|
||||
- [ ] Data quality requirements defined
|
||||
@@ -184,6 +207,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Schema changes planned iteratively, tied to stories requiring them
|
||||
|
||||
### 8.2 Integration Requirements
|
||||
|
||||
- [ ] External system integrations identified
|
||||
- [ ] API requirements documented
|
||||
- [ ] Authentication for integrations specified
|
||||
@@ -191,6 +215,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Integration testing requirements outlined
|
||||
|
||||
### 8.3 Operational Requirements
|
||||
|
||||
- [ ] Deployment frequency expectations set
|
||||
- [ ] Environment requirements defined
|
||||
- [ ] Monitoring and alerting needs identified
|
||||
@@ -200,6 +225,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## 9. CLARITY & COMMUNICATION
|
||||
|
||||
### 9.1 Documentation Quality
|
||||
|
||||
- [ ] Documents use clear, consistent language
|
||||
- [ ] Documents are well-structured and organized
|
||||
- [ ] Technical terms are defined where necessary
|
||||
@@ -207,6 +233,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
- [ ] Documentation is versioned appropriately
|
||||
|
||||
### 9.2 Stakeholder Alignment
|
||||
|
||||
- [ ] Key stakeholders identified
|
||||
- [ ] Stakeholder input incorporated
|
||||
- [ ] Potential areas of disagreement addressed
|
||||
@@ -216,6 +243,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
## PRD & EPIC VALIDATION SUMMARY
|
||||
|
||||
### Category Statuses
|
||||
|
||||
| Category | Status | Critical Issues |
|
||||
|----------|--------|----------------|
|
||||
| 1. Problem Definition & Context | PASS/FAIL/PARTIAL | |
|
||||
@@ -229,11 +257,14 @@ This checklist serves as a comprehensive framework to ensure the Product Require
|
||||
| 9. Clarity & Communication | PASS/FAIL/PARTIAL | |
|
||||
|
||||
### Critical Deficiencies
|
||||
|
||||
- List all critical issues that must be addressed before handoff to Architect
|
||||
|
||||
### Recommendations
|
||||
|
||||
- Provide specific recommendations for addressing each deficiency
|
||||
|
||||
### 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.
|
||||
@@ -5,6 +5,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 1. PROJECT SETUP & INITIALIZATION
|
||||
|
||||
### 1.1 Project Scaffolding
|
||||
|
||||
- [ ] 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
|
||||
@@ -12,6 +13,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
- [ ] Repository setup and initial commit processes are defined (if applicable)
|
||||
|
||||
### 1.2 Development Environment
|
||||
|
||||
- [ ] Local development environment setup is clearly defined
|
||||
- [ ] Required tools and versions are specified (Node.js, Python, etc.)
|
||||
- [ ] Steps for installing dependencies are included
|
||||
@@ -19,6 +21,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
- [ ] Development server setup is included
|
||||
|
||||
### 1.3 Core Dependencies
|
||||
|
||||
- [ ] All critical packages/libraries are installed early in the process
|
||||
- [ ] Package management (npm, pip, etc.) is properly addressed
|
||||
- [ ] Version specifications are appropriately defined
|
||||
@@ -27,6 +30,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 2. INFRASTRUCTURE & DEPLOYMENT SEQUENCING
|
||||
|
||||
### 2.1 Database & Data Store Setup
|
||||
|
||||
- [ ] Database selection/setup occurs before any database operations
|
||||
- [ ] Schema definitions are created before data operations
|
||||
- [ ] Migration strategies are defined if applicable
|
||||
@@ -34,12 +38,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
- [ ] Database access patterns and security are established early
|
||||
|
||||
### 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
|
||||
|
||||
### 2.3 Deployment Pipeline
|
||||
|
||||
- [ ] CI/CD pipeline is established before any deployment actions
|
||||
- [ ] Infrastructure as Code (IaC) is set up before use
|
||||
- [ ] Environment configurations (dev, staging, prod) are defined early
|
||||
@@ -47,6 +53,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
- [ ] Rollback procedures or considerations are addressed
|
||||
|
||||
### 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
|
||||
@@ -55,18 +62,21 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
@@ -75,12 +85,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 4. USER/AGENT RESPONSIBILITY DELINEATION
|
||||
|
||||
### 4.1 User Actions
|
||||
|
||||
- [ ] User responsibilities are limited to only what requires human intervention
|
||||
- [ ] Account creation on external services is properly assigned to users
|
||||
- [ ] Purchasing or payment actions are correctly assigned to users
|
||||
- [ ] Credential provision is appropriately assigned to users
|
||||
|
||||
### 4.2 Developer Agent Actions
|
||||
|
||||
- [ ] All code-related tasks are assigned to developer agents
|
||||
- [ ] Automated processes are correctly identified as agent responsibilities
|
||||
- [ ] Configuration management is properly assigned
|
||||
@@ -89,18 +101,21 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 5. FEATURE SEQUENCING & DEPENDENCIES
|
||||
|
||||
### 5.1 Functional Dependencies
|
||||
|
||||
- [ ] Features that depend on other features are sequenced correctly
|
||||
- [ ] Shared components are built before their use
|
||||
- [ ] User flows follow a logical progression
|
||||
- [ ] Authentication features precede protected routes/features
|
||||
|
||||
### 5.2 Technical Dependencies
|
||||
|
||||
- [ ] Lower-level services are built before higher-level ones
|
||||
- [ ] Libraries and utilities are created before their use
|
||||
- [ ] Data models are defined before operations on them
|
||||
- [ ] API endpoints are defined before client consumption
|
||||
|
||||
### 5.3 Cross-Epic Dependencies
|
||||
|
||||
- [ ] Later epics build upon functionality from earlier epics
|
||||
- [ ] No epic requires functionality from later epics
|
||||
- [ ] Infrastructure established in early epics is utilized consistently
|
||||
@@ -109,18 +124,21 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 6. MVP SCOPE ALIGNMENT
|
||||
|
||||
### 6.1 PRD Goals Alignment
|
||||
|
||||
- [ ] All core goals defined in the PRD are addressed in epics/stories
|
||||
- [ ] Features directly support the defined MVP goals
|
||||
- [ ] No extraneous features beyond MVP scope are included
|
||||
- [ ] Critical features are prioritized appropriately
|
||||
|
||||
### 6.2 User Journey Completeness
|
||||
|
||||
- [ ] All critical user journeys are fully implemented
|
||||
- [ ] Edge cases and error scenarios are addressed
|
||||
- [ ] User experience considerations are included
|
||||
- [ ] Accessibility requirements are incorporated if specified
|
||||
|
||||
### 6.3 Technical Requirements Satisfaction
|
||||
|
||||
- [ ] All technical constraints from the PRD are addressed
|
||||
- [ ] Non-functional requirements are incorporated
|
||||
- [ ] Architecture decisions align with specified constraints
|
||||
@@ -129,18 +147,21 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 7. RISK MANAGEMENT & PRACTICALITY
|
||||
|
||||
### 7.1 Technical Risk Mitigation
|
||||
|
||||
- [ ] Complex or unfamiliar technologies have appropriate learning/prototyping stories
|
||||
- [ ] High-risk components have explicit validation steps
|
||||
- [ ] Fallback strategies exist for risky integrations
|
||||
- [ ] Performance concerns have explicit testing/validation
|
||||
|
||||
### 7.2 External Dependency Risks
|
||||
|
||||
- [ ] Risks with third-party services are acknowledged and mitigated
|
||||
- [ ] API limits or constraints are addressed
|
||||
- [ ] Backup strategies exist for critical external services
|
||||
- [ ] Cost implications of external services are considered
|
||||
|
||||
### 7.3 Timeline Practicality
|
||||
|
||||
- [ ] Story complexity and sequencing suggest a realistic timeline
|
||||
- [ ] Dependencies on external factors are minimized or managed
|
||||
- [ ] Parallel work is enabled where possible
|
||||
@@ -149,12 +170,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 8. DOCUMENTATION & HANDOFF
|
||||
|
||||
### 8.1 Developer Documentation
|
||||
|
||||
- [ ] API documentation is created alongside implementation
|
||||
- [ ] Setup instructions are comprehensive
|
||||
- [ ] Architecture decisions are documented
|
||||
- [ ] Patterns and conventions are documented
|
||||
|
||||
### 8.2 User Documentation
|
||||
|
||||
- [ ] User guides or help documentation is included if required
|
||||
- [ ] Error messages and user feedback are considered
|
||||
- [ ] Onboarding flows are fully specified
|
||||
@@ -163,12 +186,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## 9. POST-MVP CONSIDERATIONS
|
||||
|
||||
### 9.1 Future Enhancements
|
||||
|
||||
- [ ] Clear separation between MVP and future features
|
||||
- [ ] Architecture supports planned future enhancements
|
||||
- [ ] Technical debt considerations are documented
|
||||
- [ ] Extensibility points are identified
|
||||
|
||||
### 9.2 Feedback Mechanisms
|
||||
|
||||
- [ ] Analytics or usage tracking is included if required
|
||||
- [ ] User feedback collection is considered
|
||||
- [ ] Monitoring and alerting are addressed
|
||||
@@ -177,6 +202,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
## VALIDATION SUMMARY
|
||||
|
||||
### Category Statuses
|
||||
|
||||
| Category | Status | Critical Issues |
|
||||
|----------|--------|----------------|
|
||||
| 1. Project Setup & Initialization | PASS/FAIL/PARTIAL | |
|
||||
@@ -190,11 +216,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
|
||||
| 9. Post-MVP Considerations | PASS/FAIL/PARTIAL | |
|
||||
|
||||
### Critical Deficiencies
|
||||
|
||||
- List all critical issues that must be addressed before approval
|
||||
|
||||
### Recommendations
|
||||
|
||||
- Provide specific recommendations for addressing each deficiency
|
||||
|
||||
### Final Decision
|
||||
|
||||
- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
|
||||
- **REJECTED**: The plan requires revision to address the identified deficiencies.
|
||||
@@ -1,10 +1,10 @@
|
||||
# Story Definition of Done (DoD) Checklist
|
||||
|
||||
## Instructions for Developer Agent:
|
||||
## 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.
|
||||
|
||||
## Checklist Items:
|
||||
## Checklist Items
|
||||
|
||||
1. **Requirements Met:**
|
||||
|
||||
@@ -51,6 +51,6 @@ Before marking a story as 'Review', please go through each item in this checklis
|
||||
- [ ] User-facing documentation updated, if changes impact users.
|
||||
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
|
||||
|
||||
## Final Confirmation:
|
||||
## Final Confirmation
|
||||
|
||||
- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
|
||||
|
||||
@@ -67,7 +67,7 @@ This phase focuses on collaboratively crafting a comprehensive and effective pro
|
||||
|
||||
Choose this phase with the Analyst when you need to prepare for in-depth research by meticulously defining the research questions, scope, objectives, and desired output format for a dedicated research agent or for your own research activities.
|
||||
|
||||
### Instructions
|
||||
### Deep Research Instructions
|
||||
|
||||
<critical*rule>Note on Subsequent Deep Research Execution:</critical_rule>
|
||||
The output of this phase is a research prompt. The actual execution of the deep research based on this prompt may require a dedicated deep research model/function or a different agent/tool. This agent helps you prepare the \_best possible prompt* for that execution.
|
||||
@@ -87,7 +87,7 @@ The output of this phase is a research prompt. The actual execution of the deep
|
||||
- Analytical insights required (e.g., SWOT analysis, trend implications, feasibility assessments).
|
||||
- Validation of specific hypotheses.
|
||||
- **Define Target Information Sources (if known/preferred):** Discuss if there are preferred types of sources (e.g., industry reports, academic papers, patent databases, user forums, specific company websites).
|
||||
- **Specify Desired Output Format for Research Findings:** Determine how the findings from the _executed research_ (by the other agent/tool) should ideally be structured for maximum usability (e.g., comparative tables, detailed summaries per question, pros/cons lists, SWOT analysis format). This will inform the prompt.
|
||||
- **Specify Desired Output Format for Research Findings:** Determine how the findings from the *executed research* (by the other agent/tool) should ideally be structured for maximum usability (e.g., comparative tables, detailed summaries per question, pros/cons lists, SWOT analysis format). This will inform the prompt.
|
||||
- **Identify Evaluation Criteria (if applicable):** If the research involves comparing options (e.g., technologies, solutions), define the criteria for evaluation (e.g., cost, performance, scalability, ease of integration).
|
||||
3. **Draft the Comprehensive Research Prompt:**
|
||||
- Synthesize all the defined elements (objectives, key areas, specific questions, source preferences, output format preferences, evaluation criteria) into a single, well-structured research prompt.
|
||||
@@ -103,7 +103,7 @@ The output of this phase is a research prompt. The actual execution of the deep
|
||||
|
||||
## Project Briefing Phase
|
||||
|
||||
### Instructions
|
||||
### Project Briefing Instructions
|
||||
|
||||
- State that you will use the attached `project-brief-tmpl` as the structure
|
||||
- Guide through defining each section of the template:
|
||||
|
||||
@@ -82,7 +82,7 @@ MUST review and use:
|
||||
- <critical_rule>Update story `Status: Review` in story file if DoD, Tasks and Subtasks are complete.</critical_rule>
|
||||
- State story is complete & HALT!
|
||||
|
||||
## Commands:
|
||||
## Commands
|
||||
|
||||
- `*help` - list these commands
|
||||
- `*core-dump` - ensure story tasks and notes are recorded as of now, and then run bmad-agent/tasks/core-dump.md
|
||||
|
||||
@@ -70,7 +70,7 @@ When responding to requests, gather essential context first:
|
||||
|
||||
For implementation scenarios, summarize key context:
|
||||
|
||||
```
|
||||
```plaintext
|
||||
[Environment] Multi-cloud, multi-region, brownfield
|
||||
[Stack] Microservices, event-driven, containerized
|
||||
[Constraints] SOC2 compliance, 3-month timeline
|
||||
@@ -191,6 +191,7 @@ For complex technical problems, use a structured meta-reasoning approach:
|
||||
## Domain Boundaries with Architecture
|
||||
|
||||
### Collaboration Protocols
|
||||
|
||||
- **Design Review Gates:** Architecture produces technical specifications, DevOps/Platform reviews for implementability
|
||||
- **Feasibility Feedback:** DevOps/Platform provides operational constraints during architecture design phase
|
||||
- **Implementation Planning:** Joint sessions to translate architectural decisions into operational tasks
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Role: Technical Scrum Master (IDE - Story Creator & Validator)
|
||||
|
||||
## File References:
|
||||
## File References
|
||||
|
||||
`Create Next Story Task`: `bmad-agent/tasks/create-next-story-task.md`
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## Deep Research Phase
|
||||
# Deep Research Phase
|
||||
|
||||
Leveraging advanced analytical capabilities, the Deep Research Phase with the PM is designed to provide targeted, strategic insights crucial for product definition. Unlike the broader exploratory research an Analyst might undertake, the PM utilizes deep research to:
|
||||
|
||||
@@ -9,13 +9,13 @@ Leveraging advanced analytical capabilities, the Deep Research Phase with the PM
|
||||
|
||||
Choose this phase with the PM when you need to strategically validate a product direction, fill specific knowledge gaps critical for defining _what_ to build, or ensure a strong, evidence-backed foundation for your PRD, especially if initial Analyst research was not performed or requires deeper, product-focused investigation.
|
||||
|
||||
### Purpose
|
||||
## Purpose
|
||||
|
||||
- To gather foundational information, validate concepts, understand market needs, or analyze competitors when a comprehensive Project Brief from an Analyst is unavailable or insufficient.
|
||||
- To ensure the PM has a solid, data-informed basis for defining a valuable and viable product before committing to PRD specifics.
|
||||
- To de-risk product decisions by grounding them in targeted research, especially if the user is engaging the PM directly without prior Analyst work or if the initial brief lacks necessary depth.
|
||||
|
||||
### Instructions
|
||||
## Instructions
|
||||
|
||||
<critical_rule>Note on Deep Research Execution:</critical_rule>
|
||||
To perform deep research effectively, please be aware:
|
||||
|
||||
@@ -33,7 +33,7 @@ To identify the next logical story based on project progress and epic definition
|
||||
- Verify its `Status` is 'Done' (or equivalent).
|
||||
- If not 'Done', present an alert to the user:
|
||||
|
||||
```
|
||||
```plaintext
|
||||
ALERT: Found incomplete story:
|
||||
File: {lastEpicNum}.{lastStoryNum}.story.md
|
||||
Status: [current status]
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## Purpose
|
||||
|
||||
To implement a comprehensive platform infrastructure stack based on the Infrastructure Architecture Document, including foundation infrastructure, container orchestration, GitOps workflows, service mesh, and developer experience platforms. This integrated approach ensures all platform components work synergetically to provide a complete, secure, and operationally excellent platform foundation.
|
||||
To implement a comprehensive platform infrastructure stack based on the Infrastructure Architecture Document, including foundation infrastructure, container orchestration, GitOps workflows, service mesh, and developer experience platforms. This integrated approach ensures all platform components work synergistically to provide a complete, secure, and operationally excellent platform foundation.
|
||||
|
||||
## Inputs
|
||||
|
||||
|
||||
Reference in New Issue
Block a user