architect checklist draft and readme updates
This commit is contained in:
Brian Madison
@@ -4,6 +4,8 @@ You are an expert Solution/Software Architect with deep technical knowledge acro
|
||||
|
||||
You have a strong understanding of technical trade-offs (cost, performance, complexity, security, maintainability), testing strategies, and **architecting systems optimized for clarity, modularity, and ease of modification, particularly suitable for development by AI agents working on small, well-defined tasks.** You communicate technical concepts clearly through diagrams and well-structured documentation using standard templates, **proactively explaining the rationale and trade-offs behind key decisions.**
|
||||
|
||||
To ensure thorough and high-quality architecture, you use the comprehensive `docs/templates/architect-checklist.md` as your systematic validation framework, ensuring no critical aspects of the technical design are overlooked.
|
||||
|
||||
# Core Capabilities & Goal
|
||||
|
||||
You operate in three distinct modes, each serving different needs in the product development lifecycle. Unless the user specifically indicates the desired mode, you should ask which mode they'd like to use:
|
||||
@@ -92,6 +94,16 @@ Design the complete technical architecture based on requirements and produce all
|
||||
- Local development environment setup
|
||||
- Testing infrastructure
|
||||
7. **Epic refinement input:** Provide technical details to enhance epic/story descriptions and acceptance criteria.
|
||||
8. **Architecture Validation:** Before finalizing the architecture, systematically apply the Architecture Validation Checklist to ensure completeness and quality:
|
||||
|
||||
**Apply the Architecture Solution Validation Checklist:** Systematically work through the `docs/templates/architect-checklist.md` to validate the completeness and quality of your architecture definition:
|
||||
|
||||
- Document whether each checklist item is satisfied
|
||||
- Note any deficiencies or areas for improvement
|
||||
- Create a validation summary with status for each category
|
||||
- Address any critical deficiencies before proceeding
|
||||
|
||||
Once validation is complete and the architecture meets quality standards, finalize all documentation and prepare for handoff to the development team.
|
||||
|
||||
# Mode 3: Master Architect Advisory
|
||||
|
||||
|
||||
124
CURRENT-V2/agents/instructions.md
Normal file
124
CURRENT-V2/agents/instructions.md
Normal file
@@ -0,0 +1,124 @@
|
||||
# IDE Instructions for Agent Configuration
|
||||
|
||||
This document provides ideas and some initial guidance on how to set up custom agent modes in various integrated development environments (IDEs) to implement the BMAD Method workflow. Optimally and in the future, the BMAD method will be fully available behind MCP as an option allowing functioning especially of the SM and Dev Agents to work with the artifacts properly.
|
||||
|
||||
The alternative for all of this is if not using custom agents, this whole system can be modified to a system of rules, which at the end of the day are really very similar to custom mode instructions
|
||||
|
||||
## Cursor
|
||||
|
||||
### Setting Up Custom Modes in Cursor
|
||||
|
||||
1. **Access Agent Configuration**:
|
||||
|
||||
- Navigate to Cursor Settings > Features > Chat & Composer
|
||||
- Look for the "Rules for AI" section to set basic guidelines for all agents
|
||||
|
||||
2. **Creating Custom Agents**:
|
||||
|
||||
- Custom Agents can be created and configured with specific tools, models, and custom prompts
|
||||
- Cursor allows creating custom agents through a GUI interface
|
||||
- See [Cursor Custom Modes doc](https://docs.cursor.com/chat/custom-modes#custom-modes)
|
||||
|
||||
3. **Configuring BMAD Method Agents**:
|
||||
|
||||
- Define specific roles for each agent in your workflow (Analyst, PM, Architect, PO/SM, etc.)
|
||||
- Specify what tools each agent can use (both Cursor-native and MCP)
|
||||
- Set custom prompts that define how each agent should operate
|
||||
- Control which model each agent uses based on their role
|
||||
- Configure what they can and cannot YOLO
|
||||
|
||||
## Windsurf
|
||||
|
||||
### Setting Up Custom Modes in Windsurf
|
||||
|
||||
1. **Access Agent Configuration**:
|
||||
|
||||
- Click on "Windsurf - Settings" button on the bottom right
|
||||
- Access Advanced Settings via the button in the settings panel or from the top right profile dropdown
|
||||
|
||||
2. **Configuring Custom Rules**:
|
||||
|
||||
- Define custom AI rules for Cascade (Windsurf's agentic chatbot)
|
||||
- Specify that agents should respond in certain ways, use particular frameworks, or follow specific APIs
|
||||
|
||||
3. **Using Flows**:
|
||||
|
||||
- Flows combine Agents and Copilots for a comprehensive workflow
|
||||
- The Windsurf Editor is designed for AI agents that can tackle complex tasks independently
|
||||
- Use Model Context Protocol (MCP) to extend agent capabilities
|
||||
|
||||
4. **BMAD Method Implementation**:
|
||||
- Create custom agents for each role in the BMAD workflow
|
||||
- Configure each agent with appropriate permissions and capabilities
|
||||
- Utilize Windsurf's agentic features to maintain workflow continuity
|
||||
|
||||
## RooCode
|
||||
|
||||
### Setting Up Custom Agents in RooCode
|
||||
|
||||
1. **Custom Modes Configuration**:
|
||||
|
||||
- Create tailored AI behaviors through configuration files
|
||||
- Each custom mode can have specific prompts, file restrictions, and auto-approval settings
|
||||
|
||||
2. **Creating BMAD Method Agents**:
|
||||
|
||||
- Create distinct modes for each BMAD role (Analyst, PM, Architect, PO/SM, Dev etc...)
|
||||
- Customize each mode with tailored prompts specific to their role
|
||||
- Configure file restrictions appropriate to each role (e.g., Architect and PM modes may edit markdown files)
|
||||
- Set up direct mode switching so agents can request to switch to other modes when needed
|
||||
|
||||
3. **Model Configuration**:
|
||||
|
||||
- Configure different models per mode (e.g., advanced model for architecture vs. cheaper model for daily coding tasks)
|
||||
- RooCode supports multiple API providers including OpenRouter, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, and local models
|
||||
|
||||
4. **Usage Tracking**:
|
||||
- Monitor token and cost usage for each session
|
||||
- Optimize model selection based on the complexity of tasks
|
||||
|
||||
## Cline
|
||||
|
||||
### Setting Up Custom Agents in Cline
|
||||
|
||||
1. **Custom Instructions**:
|
||||
|
||||
- Access via Cline > Settings > Custom Instructions
|
||||
- Provide behavioral guidelines for your agents
|
||||
|
||||
2. **Custom Tools Integration**:
|
||||
|
||||
- Cline can extend capabilities through the Model Context Protocol (MCP)
|
||||
- Ask Cline to "add a tool" and it will create a new MCP server tailored to your specific workflow
|
||||
- Custom tools are saved locally at ~/Documents/Cline/MCP, making them easy to share with your team
|
||||
|
||||
3. **BMAD Method Implementation**:
|
||||
|
||||
- Create custom tools for each role in the BMAD workflow
|
||||
- Configure behavioral guidelines specific to each role
|
||||
- Utilize Cline's autonomous abilities to handle the entire workflow
|
||||
|
||||
4. **Model Selection**:
|
||||
- Configure Cline to use different models based on the role and task complexity
|
||||
|
||||
## GitHub Copilot
|
||||
|
||||
### Custom Agent Configuration (Coming Soon)
|
||||
|
||||
GitHub Copilot is currently developing its Copilot Extensions system, which will allow for custom agent/mode creation:
|
||||
|
||||
1. **Copilot Extensions**:
|
||||
|
||||
- Combines a GitHub App with a Copilot agent to create custom functionality
|
||||
- Allows developers to build and integrate custom features directly into Copilot Chat
|
||||
|
||||
2. **Building Custom Agents**:
|
||||
|
||||
- Requires creating a GitHub App and integrating it with a Copilot agent
|
||||
- Custom agents can be deployed to a server reachable by HTTP request
|
||||
|
||||
3. **Custom Instructions**:
|
||||
- Currently supports basic custom instructions for guiding general behavior
|
||||
- Full agent customization support is under development
|
||||
|
||||
_Note: Full custom mode configuration in GitHub Copilot is still in development. Check GitHub's documentation for the latest updates._
|
||||
259
CURRENT-V2/docs/templates/architect-checklist.md
vendored
Normal file
259
CURRENT-V2/docs/templates/architect-checklist.md
vendored
Normal file
@@ -0,0 +1,259 @@
|
||||
# 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.
|
||||
|
||||
## 1. REQUIREMENTS ALIGNMENT
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
- [ ] 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. RESILIENCE & OPERATIONAL READINESS
|
||||
|
||||
### 4.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
|
||||
|
||||
### 4.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
|
||||
|
||||
### 4.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
|
||||
|
||||
### 4.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
|
||||
|
||||
## 5. SECURITY & COMPLIANCE
|
||||
|
||||
### 5.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
|
||||
|
||||
### 5.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
|
||||
|
||||
### 5.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
|
||||
|
||||
### 5.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
|
||||
|
||||
## 6. IMPLEMENTATION GUIDANCE
|
||||
|
||||
### 6.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
|
||||
|
||||
### 6.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
|
||||
|
||||
### 6.3 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
|
||||
|
||||
### 6.4 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
|
||||
|
||||
## 7. DEPENDENCY & INTEGRATION MANAGEMENT
|
||||
|
||||
### 7.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
|
||||
|
||||
### 7.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
|
||||
|
||||
### 7.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
|
||||
|
||||
## 8. AI AGENT IMPLEMENTATION SUITABILITY
|
||||
|
||||
### 8.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
|
||||
|
||||
### 8.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
|
||||
|
||||
### 8.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
|
||||
|
||||
### 8.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
|
||||
@@ -4,6 +4,8 @@ You are an expert Solution/Software Architect with deep technical knowledge acro
|
||||
|
||||
You have a strong understanding of technical trade-offs (cost, performance, complexity, security, maintainability), testing strategies, and **architecting systems optimized for clarity, modularity, and ease of modification, particularly suitable for development by AI agents working on small, well-defined tasks.** You communicate technical concepts clearly through diagrams and well-structured documentation using standard templates, **proactively explaining the rationale and trade-offs behind key decisions.**
|
||||
|
||||
To ensure thorough and high-quality architecture, you use the comprehensive [Architect Checklist](architect-checklist.txt) as your systematic validation framework, ensuring no critical aspects of the technical design are overlooked.
|
||||
|
||||
# Core Capabilities & Goal
|
||||
|
||||
You operate in three distinct modes, each serving different needs in the product development lifecycle. Unless the user specifically indicates the desired mode, you should ask which mode they'd like to use:
|
||||
@@ -92,6 +94,16 @@ Design the complete technical architecture based on requirements and produce all
|
||||
- Local development environment setup
|
||||
- Testing infrastructure
|
||||
7. **Epic refinement input:** Provide technical details to enhance epic/story descriptions and acceptance criteria.
|
||||
8. **Architecture Validation:** Before finalizing the architecture, systematically apply the Architecture Validation Checklist to ensure completeness and quality:
|
||||
|
||||
**Apply the Architecture Solution Validation Checklist:** Systematically work through the [Architect Checklist](architect-checklist.txt) to validate the completeness and quality of your architecture definition:
|
||||
|
||||
- Document whether each checklist item is satisfied
|
||||
- Note any deficiencies or areas for improvement
|
||||
- Create a validation summary with status for each category
|
||||
- Address any critical deficiencies before proceeding
|
||||
|
||||
Once validation is complete and the architecture meets quality standards, finalize all documentation and prepare for handoff to the development team.
|
||||
|
||||
# Mode 3: Master Architect Advisory
|
||||
|
||||
|
||||
@@ -29,18 +29,65 @@ Your primary goal is to **autonomously prepare the next executable stories in a
|
||||
|
||||
## PO Mode Instructions
|
||||
|
||||
1. **Input Consumption:** Inform the user you are in PO Mode and will start analysis with provided materials, or requesting the user provide materials. Receive the complete, refined MVP plan package. This includes the latest versions of `prd.md`, `architecture.md`, the _technically enriched_ `epicN.md...` files, and relevant reference documents the architecture references, provided after initial PM/Architect collaboration and refinement.
|
||||
2. **Perform Validation Checks:** Meticulously review the entire package _only_ against the following criteria:
|
||||
- **Scope/Value Alignment:** Does the detailed plan accurately reflect the intended MVP scope defined in the PRD? Does it deliver the core business/user value proposition?
|
||||
- **Sequence/Dependency Validation:** Examine the order of stories within the `docs/epicN.md` files. Is the flow logical from a user journey and value delivery perspective? Are functional dependencies correctly accounted for in the proposed order? Is value delivered incrementally where feasible?
|
||||
- **Holistic PRD Alignment:** Does the complete plan (functional requirements in Epics + technical approach overview in Architecture) cohesively fulfill the overall goals, user experience, and functional requirements outlined in the `docs/prd.md`? Are there any noticeable functional gaps or contradictions between the detailed plan and the high-level PRD?
|
||||
3. **Make Go/No-Go Decision:** Based _only_ on the validation checks performed in Step 2, make the final decision:
|
||||
1. **Input Consumption:** Inform the user you are in PO Mode and will start analysis with provided materials, or requesting the user provide materials. Receive the complete, refined MVP plan package. This includes the latest versions of PRD, architecture, the _technically enriched_ epic files, and relevant reference documents the architecture references, provided after initial PM/Architect collaboration and refinement.
|
||||
|
||||
- **Approve:** If all checks pass satisfactorily, formally state **"Plan Approved"**. This signals readiness to proceed to Phase 4 (Story Generation).
|
||||
- **Reject:** If significant issues are found in scope/value alignment, sequence logic, or holistic integrity, formally state **"Plan Rejected"**. Provide specific, actionable reasons directly tied to the validation criteria (e.g., "Reject: Sequence in Epic 2, Story 2.3 depends on 2.5 functionally, order must be revised.", "Reject: PRD Goal 'X' is not adequately addressed in the current Epic plan."). This sends the process back for revision by the PM/Architect.
|
||||
2. **Apply the PO Checklist:** Systematically work through each item in the [PO Checklist](po-checklist.txt), using it as your comprehensive validation framework. For each checklist category and item:
|
||||
|
||||
- NOTE: It is possible some stories may be provided, or an indication that some epics are partially or completely finished - if this is the case, you are directed to asses what remains to meet the final goals of the MVP. IF none have started or are completed (Done) then you are to assess wholistically from beginning to end.
|
||||
- IMPORTANT: Getting this phase correct and confirming to the user all is sufficient, or you are blocking progress without approval for various reasons, is CRITICAL before letting the user you are transitioning to SM mode.
|
||||
- Document whether the plan satisfies the requirement
|
||||
- Note any deficiencies or concerns
|
||||
- Assign a status (Pass/Fail/Partial) to each major category
|
||||
|
||||
3. **Perform Comprehensive Validation Checks:** Using the checklist as your guide, meticulously review the entire package against the following comprehensive criteria:
|
||||
|
||||
## A. Foundational Implementation Logic
|
||||
|
||||
- **Project Initialization Check:** Does Epic 1 explicitly include all necessary project setup steps?
|
||||
- **Infrastructure Sequence Logic:** Are infrastructure components set up before they're used?
|
||||
- **User vs. Agent Action Appropriateness:** Is there a clear separation of responsibilities?
|
||||
- **External Dependencies Management:** Are there appropriate stories for handling external requirements?
|
||||
|
||||
## B. Technical Sequence Viability
|
||||
|
||||
- **Local Development Capability:** Does the plan establish local development capabilities early?
|
||||
- **Deployment Prerequisites:** Are all deployment prerequisites established before deployment stories?
|
||||
- **Testing Infrastructure:** Is testing infrastructure established before test implementation stories?
|
||||
|
||||
## C. Original Validation Criteria
|
||||
|
||||
- **Scope/Value Alignment:** Does the detailed plan reflect the intended MVP scope defined in the PRD?
|
||||
- **Sequence/Dependency Validation:** Is the flow logical from a user journey and value delivery perspective?
|
||||
- **Holistic PRD Alignment:** Does the complete plan cohesively fulfill the overall goals?
|
||||
|
||||
4. **Apply Real-World Implementation Wisdom:** Consider real-world project implementation questions:
|
||||
|
||||
- If using new technology, are there appropriate stories for learning or proof-of-concepts?
|
||||
- Are there risk mitigation stories for technically complex components?
|
||||
- Is there a strategy for handling potential blockers from external dependencies?
|
||||
- Are early epics focused on establishing core infrastructure rather than jumping to feature development?
|
||||
|
||||
5. **Create Checklist Summary:** Once you've completed the checklist evaluation, create a structured summary showing:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass/Fail/Partial status for each major category
|
||||
- Specific items that failed validation with clear explanations
|
||||
- Recommendations for addressing each deficiency
|
||||
|
||||
6. **Make Go/No-Go Decision:** Based on the comprehensive validation checks performed and the checklist results, make the final decision:
|
||||
|
||||
- **Approve:** If all checklist sections score sufficiently well, formally state **"Plan Approved"** and provide the completed checklist summary.
|
||||
- **Reject:** If significant issues are found in any validation area, formally state **"Plan Rejected"** and provide the checklist summary with specific, actionable reasons tied to the validation criteria.
|
||||
|
||||
7. **Specific Checks for Common Issues:** Explicitly verify these frequently missed aspects:
|
||||
|
||||
- Does Epic 1 include ALL necessary project setup steps if there's no starter template?
|
||||
- Is all infrastructure established before it's used in features?
|
||||
- Are deployment pipelines created before any deployment actions occur?
|
||||
- Are user actions limited only to what requires human intervention?
|
||||
- Are all external dependencies properly accounted for with setup stories?
|
||||
- Is there a logical progression from core infrastructure to features to refinement?
|
||||
|
||||
- NOTE: It is possible some stories may be provided, or an indication that some epics are partially or completely finished - if this is the case, you are directed to assess what remains to meet the final goals of the MVP. If none have started or are completed (Done) then you are to assess holistically from beginning to end.
|
||||
- IMPORTANT: Getting this phase correct and confirming to the user all is sufficient, or you are blocking progress without approval for various reasons, is CRITICAL before letting the user you are transitioning to SM mode.
|
||||
|
||||
## SM Mode Instructions
|
||||
|
||||
|
||||
259
CURRENT-V2/gems-and-gpts/architect-checklist.txt
Normal file
259
CURRENT-V2/gems-and-gpts/architect-checklist.txt
Normal file
@@ -0,0 +1,259 @@
|
||||
# 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.
|
||||
|
||||
## 1. REQUIREMENTS ALIGNMENT
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
- [ ] 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. RESILIENCE & OPERATIONAL READINESS
|
||||
|
||||
### 4.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
|
||||
|
||||
### 4.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
|
||||
|
||||
### 4.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
|
||||
|
||||
### 4.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
|
||||
|
||||
## 5. SECURITY & COMPLIANCE
|
||||
|
||||
### 5.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
|
||||
|
||||
### 5.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
|
||||
|
||||
### 5.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
|
||||
|
||||
### 5.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
|
||||
|
||||
## 6. IMPLEMENTATION GUIDANCE
|
||||
|
||||
### 6.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
|
||||
|
||||
### 6.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
|
||||
|
||||
### 6.3 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
|
||||
|
||||
### 6.4 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
|
||||
|
||||
## 7. DEPENDENCY & INTEGRATION MANAGEMENT
|
||||
|
||||
### 7.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
|
||||
|
||||
### 7.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
|
||||
|
||||
### 7.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
|
||||
|
||||
## 8. AI AGENT IMPLEMENTATION SUITABILITY
|
||||
|
||||
### 8.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
|
||||
|
||||
### 8.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
|
||||
|
||||
### 8.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
|
||||
|
||||
### 8.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
|
||||
@@ -23,7 +23,7 @@
|
||||
### Architect
|
||||
|
||||
- Instructions: 3-architect-gem.md pasted into instructions
|
||||
- Knowledge: architect-templates.txt
|
||||
- Knowledge: architecture-templates.txt, architect-checklist.txt
|
||||
- During Chat - Mode 1 - 2.5 Pro Deep Research recommended. Mode 2 2.5 Pro Thinking Mode. Start by also attaching the product brief, PRD, and any generated Epic files. If architecture deep research was done as mode 1, attach it to the new chat. Also if there was deep research from the PRD that is not fully distilled in the PRD (deep technical details or solutions), provide to the architect.
|
||||
|
||||
### PO + SM
|
||||
|
||||
37
README.md
37
README.md
@@ -11,6 +11,8 @@ The BMad Method has undergone a significant transformation with our V2 (beta) re
|
||||
- **Streamlined Workflow**: Clearer process from idea to deployment
|
||||
- **Improved Agile Integration**: Better support for agile methodologies
|
||||
- **Agent vs Gem Agent Distinction**: V2 has specific [gems](#custom-gems-and-gpts) (agent with embedded templates) in parity with the IDE agents.
|
||||
- **Comprehensive Checklists**: New detailed checklists for PM, Architect, and PO roles to ensure quality and completeness at each phase!
|
||||
- **Multi-Mode Agents**: Each agent now operates in distinct modes tailored to different project phases or complexity levels - allowing flexibility to match your project needs and knowledge level
|
||||
|
||||
## No Rules Required!
|
||||
|
||||
@@ -21,6 +23,15 @@ One of the biggest advantages of the BMad Method is that it doesn't require cust
|
||||
|
||||
This flexibility allows you to choose the implementation that works best for your workflow while maintaining consistent quality across your project.
|
||||
|
||||
## IDE Agent Integration
|
||||
|
||||
The BMad Method now includes detailed [instructions for setting up custom agent modes](./CURRENT-V2/agents/instructions.md) in various IDEs. For the most direct translation of the full agent system, especially for the crucial SM and Dev agent roles, the following are recommended:
|
||||
|
||||
- **RooCode**: Excellent custom mode support with robust file permission controls and mode switching
|
||||
- **Cursor**: Strong custom agent capabilities with advanced context management
|
||||
|
||||
Both provide an optimal experience for implementing the BMAD workflow, though the method can be adapted to work with any IDE. See the full [instructions file](./CURRENT-V2/agents/instructions.md) for details on configuring each supported IDE.
|
||||
|
||||
## What is the BMad Method?
|
||||
|
||||
The BMad Method is a revolutionary approach that elevates "vibe coding" to the next level—what I call "Vibe CEOing." Unlike the spontaneity of pure vibe coding for quick prototypes, this method helps you plan, execute, and keep your project on track. Build faster, cheaper, and easier while leveraging AI-driven processes to accelerate and enhance the entire product development lifecycle from ideation and market fit through agentic code implementation.
|
||||
@@ -56,11 +67,31 @@ Join the [Community Discussion Forum](https://github.com/bmadcode/BMAD-METHOD/di
|
||||
|
||||
### Analyst (Business Analyst (BA), Research Assistant (RA), Brainstorming Coach)
|
||||
|
||||
The Analyst agent is a versatile entry point into the BMad Method, operating in three distinct modes: Brainstorming Coach, Deep Research, and Project Briefing. It helps transform initial ideas or vague concepts into well-defined project briefs through creative ideation techniques, market analysis, or structured requirement gathering. In Brainstorming mode, it uses proven techniques like SCAMPER and "What if" scenarios to expand possibilities. The Deep Research mode generates comprehensive research prompts to explore market needs, competitors, and target users. Finally, the Project Briefing mode collaboratively builds a structured brief document with a dedicated PM Agent Handoff Prompt section that provides strategic guidance for the next phase. This agent is ideal for users who need help refining their vision before moving to detailed product definition.
|
||||
The Analyst agent is a versatile entry point into the BMad Method, operating in three distinct modes to help transform initial ideas or vague concepts into well-defined project briefs through creative ideation techniques, market analysis, or structured requirement gathering. This agent is ideal for users who need help refining their vision before moving to detailed product definition.
|
||||
|
||||
#### Brainstorming Coach Mode
|
||||
|
||||
This mode uses proven brainstorming techniques like SCAMPER and "What if" scenarios to expand possibilities. The agent guides users through structured ideation frameworks, encourages divergent thinking, and helps challenge assumptions that might be limiting creativity.
|
||||
|
||||
#### Deep Research Mode
|
||||
|
||||
This mode generates comprehensive research prompts to explore market needs, competitors, and target users. It focuses on executing deep research into market conditions, industry trends, competitive landscape, and user needs to inform the project direction.
|
||||
|
||||
#### Project Briefing Mode
|
||||
|
||||
This mode collaboratively builds a structured brief document with a dedicated PM Agent Handoff Prompt section that provides strategic guidance for the next phase. It leverages research findings and user input to create a well-defined project brief that serves as the foundation for product development.
|
||||
|
||||
### Product Manager (PM)
|
||||
|
||||
The Product Manager agent excels at transforming high-level project briefs or initial ideas into comprehensive product specifications and actionable development plans. As a scope refinement specialist, the PM actively challenges assumptions about what features are truly necessary for the MVP, seeking opportunities to reduce complexity while ensuring perfect alignment with core business goals. The PM creates three key artifacts: a detailed Product Requirements Document (PRD) outlining goals, functional and non-functional requirements; a set of epic definitions that break down the work into independently deployable chunks; and an Initial Architect Prompt that captures critical technical decisions. Throughout the process, the PM engages in multiple rounds of scope refinement—first during initial scoping discussions, then after drafting the PRD, and finally after creating epics—always framing conversations around time, cost, and quality tradeoffs. The PM also identifies deployment considerations and testing requirements (if valued by stakeholders), ensuring each epic builds logically on previous ones with Epic 1 containing all necessary infrastructure setup. This agent is essential for users who need to translate their vision into a practical, well-structured development plan with appropriate scope for an MVP.
|
||||
The Product Manager agent excels at transforming high-level project briefs or initial ideas into comprehensive product specifications and actionable development plans. As a scope refinement specialist, the PM actively challenges assumptions about what features are truly necessary for the MVP, seeking opportunities to reduce complexity while ensuring perfect alignment with core business goals.
|
||||
|
||||
#### Mode 1: Initial Product Definition
|
||||
|
||||
In this mode, the PM creates the core product definition documents for the MVP from scratch. The agent produces three key artifacts: a detailed Product Requirements Document (PRD) outlining goals, functional and non-functional requirements; a set of epic definitions that break down the work into independently deployable chunks; and an Initial Architect Prompt that captures critical technical decisions. Throughout the process, the PM engages in multiple rounds of scope refinement—first during initial scoping discussions, then after drafting the PRD, and finally after creating epics—always framing conversations around time, cost, and quality tradeoffs. The PM also identifies deployment considerations and testing requirements, ensuring each epic builds logically on previous ones with Epic 1 containing all necessary infrastructure setup.
|
||||
|
||||
#### Mode 2: Product Refinement & Advisory
|
||||
|
||||
In this mode, which activates when a PRD already exists and is approved, the PM serves as an ongoing product advisor to provide clarification on existing requirements, facilitate modifications as the product evolves, assess the impact of proposed changes, manage scope adjustments, and maintain consistent, up-to-date product documentation throughout the development process.
|
||||
|
||||
### Architect
|
||||
|
||||
@@ -82,6 +113,8 @@ This mode provides ongoing technical guidance throughout the project, explaining
|
||||
|
||||
### Product Owner (PO)
|
||||
|
||||
The Product Owner agent serves as the validation and quality assurance checkpoint for the entire MVP plan before development begins. Using a comprehensive validation checklist, the PO agent systematically reviews all project artifacts to ensure they are complete, well-structured, and properly aligned. The PO agent verifies proper project setup and initialization steps, validates infrastructure and deployment sequencing, confirms all external dependencies are properly addressed, delineates user versus agent responsibilities, ensures features are correctly sequenced with dependencies managed, validates that all MVP goals from the PRD are addressed in epics/stories, and checks that all technical requirements are satisfied. The agent also evaluates risk management strategies, documentation completeness, and verifies that post-MVP considerations are properly handled. This systematic validation process helps catch potential issues early, ensuring the development phase proceeds smoothly.
|
||||
|
||||
### Scrum Master (SM)
|
||||
|
||||
### Dev Agent (Dev)
|
||||
|
||||
Reference in New Issue
Block a user