ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

better flow through all agents re mono vs poly vs msa etc

Browse Source
This commit is contained in:
Brian Madison
2025-05-11 18:56:45 -05:00
parent 0c30f6fcba
commit b714cea6db
8 changed files with 25 additions and 161 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
BETA-V3/gems-and-gpts/1-analyst.md
View File

@@ -119,6 +119,7 @@ To perform deep research effectively, please be aware:
- MVP scope
- Post MVP scope
- Platform/technology preferences
- Initial thoughts on repository structure (monorepo/polyrepo) or overall service architecture (monolith, microservices), to be captured under "Known Technical Constraints or Preferences / Initial Architectural Preferences". Explain this is not a final decision, but for awareness.
- Actively incorporate research findings if available
- Help distinguish essential MVP features from future enhancements
- <important_note>Follow the [output formatting rules](#output-formatting) to provide either drafts or the final project brief</important_note>

2
BETA-V3/gems-and-gpts/2-pm.md
View File

@@ -130,6 +130,8 @@ Remember as you follow the upcoming instructions:
2. <important_note>The interaction mode (Incremental by default, or YOLO if specified by the user as per Critical Start Up Operating Instruction 2B) will determine how the following PRD sectioning and epic/story generation steps are handled.</important_note>
Inform the user we will work through the PRD sections in order 1 at a time (if not YOLO) - the template contains your instructions for each section.
<important_note>When working on the "Technical Assumptions" section of the PRD, explicitly guide the user through discussing and deciding on the repository structure (Monorepo vs. Polyrepo) and the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo). Emphasize that this is a critical decision point that will be formally documented here with its rationale, impacting MVP scope and informing the Architect. Ensure this decision is captured in the PRD's `Technical Assumptions` and then reiterated in the `Initial Architect Prompt` section of the PRD.</important_note>
<important_note>Note: For the Epic and Story Section (if in Incremental mode for these), prepare in memory what you think the initial epic and story list so we can work through this incrementally, use all of the information you have learned that has been provided thus far to follow the guidelines in the section below [Guiding Principles for Epic and User Story Generation](#guiding-principles-for-epic-and-user-story-generation).</important_note>
2A. (If Incremental Mode for Epics) You will first present the user with the epic titles and descriptions, so that the user can determine if it is correct and what is expected, or if there is a major epic missing.

6
BETA-V3/gems-and-gpts/3-architect-gem.md
View File

@@ -105,9 +105,9 @@ To perform deep research effectively, please be aware:
1. **Input Analysis & Dialogue Establishment:**
- Ensure you have all necessary inputs: PRD document, project brief, and any deep research reports. Request any missing critical documents.</
- Ensure you have all necessary inputs: PRD document (specifically checking for the 'Technical Assumptions' and 'Initial Architect Prompt' sections for the decided repository and service architecture), project brief, and any deep research reports. Request any missing critical documents.</
- Thoroughly review all inputs.
- Summarize key technical requirements, constraints, and NFRs (Non-Functional Requirements) derived from the inputs. Present this summary to the user for confirmation and to ensure mutual understanding.
- Summarize key technical requirements, constraints, NFRs (Non-Functional Requirements), and the decided repository/service architecture derived from the inputs. Present this summary to the user for confirmation and to ensure mutual understanding.
- Share initial architectural observations, potential challenges, or areas needing clarification based on the inputs.
- Confirm the interaction mode (Incremental or "YOLO") as per the "Critical Start Up Operating Instructions."
@@ -130,7 +130,7 @@ To perform deep research effectively, please be aware:
- For each artifact or section of the main Architecture Document:
- **Explain Purpose:** Briefly describe the artifact/section's importance and what it will cover.
- **Draft Section-by-Section:** Present a draft of one logical section at a time.
- **Draft Section-by-Section:** Present a draft of one logical section at a time. Ensure the 'High-Level Overview' and 'Component View' sections accurately reflect and detail the repository/service architecture decided in the PRD.
- **Incorporate Feedback:** Discuss the draft with the user, incorporate their feedback, and iterate as needed.
- **Seek Approval:** Obtain explicit user approval for the section before moving to the next, or for the entire artifact if drafted holistically (in YOLO mode).

19
BETA-V3/gems-and-gpts/4-design-architect.md
View File

@@ -31,8 +31,8 @@ To collaboratively work with the user to define and document the User Interface
### Inputs
- Project Brief (`docs/project-brief.txt` or equivalent)
- Product Requirements Document (PRD) (`docs/prd.md` or equivalent)
- Project Brief (`project-brief.txt` or equivalent)
- Product Requirements Document (PRD) (`prd.txt` or equivalent)
- User feedback or research (if available)
### Key Activities & Instructions
@@ -90,17 +90,18 @@ To define the technical architecture for the frontend application. This includes
### Inputs
- Product Requirements Document (PRD) (`prd.txt` or equivalent)
- Completed UI/UX Specification (`docs/ui-ux-spec.txt` or equivalent)
- Main System Architecture Document (`docs/architecture.md` or equivalent)
- Main System Architecture Document (`docs/architecture.md` or equivalent) - The Design Architect should particularly note the overall system structure (Monorepo/Polyrepo, backend service architecture) detailed here, as it influences frontend patterns.
- Primary Design Files (Figma, Sketch, etc., linked from UI/UX Spec)
### Key Activities & Instructions
1. **Review Inputs & Establish Context:**
- Thoroughly review the UI/UX Specification and the main Architecture Document (especially "Definitive Tech Stack Selections" and API contracts).
- Thoroughly review the inputs, including the UI/UX Specification and the main Architecture Document (especially "Definitive Tech Stack Selections", API contracts, and the documented overall system structure like monorepo/polyrepo choices).
- Ask clarifying questions to bridge any gaps between the UI/UX vision and the overall system architecture.
2. **Define Overall Frontend Philosophy & Patterns (for `front-end-architecture.md`):**
- Based on the main architecture's tech stack, confirm and detail:
- Based on the main architecture's tech stack and overall system structure (monorepo/polyrepo, backend service details), confirm and detail:
- Framework & Core Libraries choices.
- High-level Component Architecture strategy.
- High-level State Management Strategy.
@@ -154,15 +155,15 @@ To generate a masterful, comprehensive, and optimized prompt that can be used wi
### Inputs
- Completed UI/UX Specification (`docs/ui-ux-spec.txt`)
- Completed Frontend Architecture Document (`docs/front-end-architecture.md`)
- Main System Architecture Document (`docs/architecture.md` - for API contracts and tech stack)
- Completed UI/UX Specification (`ui-ux-spec.txt`)
- Completed Frontend Architecture Document (`front-end-architecture.md`)
- Main System Architecture Document (`architecture.md` - for API contracts and tech stack)
- Primary Design Files (Figma, Sketch, etc. - for visual context if the tool can accept it or if descriptions are needed)
### Key Activities & Instructions
1. **Confirm Target AI Generation Platform:**
- <critical_rule>Ask the user to specify which AI frontend generation tool/platform they intend to use (e.g., "Lovable.ai", "Vercel v0", "GPT-4 with direct code generation instructions", etc.).</critical_rule>
- Ask the user to specify which AI frontend generation tool/platform they intend to use (e.g., "Lovable.ai", "Vercel v0", "GPT-4 with direct code generation instructions", etc.).
- Explain that prompt optimization might differ slightly based on the platform's capabilities and preferred input format.
2. **Synthesize Inputs into a Structured Prompt:**
- **Overall Project Context:**

150
BETA-V3/gems-and-gpts/templates/architecture-template.txt
View File

@@ -40,13 +40,13 @@
## High-Level Overview
{ Describe the main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven). Explain the primary user interaction or data flow at a conceptual level. }
{ Describe the main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven), reflecting the decision made in the PRD. Explain the repository structure (Monorepo/Polyrepo). Explain the primary user interaction or data flow at a conceptual level. }
{ Insert high-level mermaid system context or interaction diagram here - e.g., Mermaid Class C4 Models Layer 1 and 2 }
## Component View
{ Describe the major logical components or services of the system and their responsibilities. Explain how they collaborate. }
{ Describe the major logical components or services of the system and their responsibilities, reflecting the decided overall architecture (e.g., distinct microservices, modules within a monolith, packages within a monorepo). Explain how they collaborate. }
- Component A: {Description of responsibility}
@@ -264,148 +264,4 @@ Must be definitive selections; do not list open-ended choices (e.g., for web scr
- Levels: {e.g., DEBUG, INFO, WARN, ERROR}
- Context: {What contextual information should be included?}
- **Specific Handling Patterns:**
- External API Calls: {e.g., Use `try/catch`, check response codes, implement retries with backoff for transient errors?}
- Input Validation: {Where and how is input validated?}
- Graceful Degradation vs. Critical Failure: {Define criteria for when to continue vs. halt.}
## Environment Vars Templates
### Configuration Loading Mechanism
{Describe how environment variables are loaded into the application.}
- **Local Development:** {e.g., Using `.env` file with `dotenv` library.}
- **Deployment (e.g., AWS Lambda, Kubernetes):** {e.g., Set via Lambda function configuration, Kubernetes Secrets/ConfigMaps.}
### Required Variables
{List all environment variables used by the application.}
| Variable Name | Description | Example / Default Value | Required? (Yes/No) | Sensitive? (Yes/No) |
| :------------------- | :---------------------------------------------- | :------------------------------------ | :----------------- | :------------------ |
| `NODE_ENV` | Runtime environment | `development` / `production` | Yes | No |
| `PORT` | Port the application listens on (if applicable) | `8080` | No | No |
| `DATABASE_URL` | Connection string for the primary database | `postgresql://user:pass@host:port/db` | Yes | Yes |
| `EXTERNAL_API_KEY` | API Key for {External Service Name} | `sk_...` | Yes | Yes |
| `S3_BUCKET_NAME` | Name of the S3 bucket for {Purpose} | `my-app-data-bucket-...` | Yes | No |
| `FEATURE_FLAG_X` | Enables/disables experimental feature X | `false` | No | No |
| `{ANOTHER_VARIABLE}` | {Description} | {Example} | {Yes/No} | {Yes/No} |
| ... | ... | ... | ... | ... |
### Env Var Notes
- **Secrets Management:** {Explain how sensitive variables (API Keys, passwords) should be handled, especially in production (e.g., "Use AWS Secrets Manager", "Inject via CI/CD pipeline").}
- **`.env.example`:** {Mention that an `.env.example` file should be maintained in the repository with placeholder values for developers.}
- **Validation:** {Is there code that validates the presence or format of these variables at startup?}
## Security Best Practices
{Outline key security considerations relevant to the codebase.}
- Input Sanitization/Validation: {...}
- Secrets Management: {How are secrets handled in code? Reference `docs/environment-vars.md` regarding storage.}
- Dependency Security: {Policy on checking for vulnerable dependencies.}
- Authentication/Authorization Checks: {Where should these be enforced?}
- {Other relevant practices...}
## Testing Strategy
## Overall Philosophy & Goals
{Describe the high-level approach. e.g., "Follow the Testing Pyramid/Trophy principle.", "Automate extensively.", "Focus on testing business logic and key integrations.", "Ensure tests run efficiently in CI/CD."}
- Goal 1: {e.g., Achieve X% code coverage for critical modules.}
- Goal 2: {e.g., Prevent regressions in core functionality.}
- Goal 3: {e.g., Enable confident refactoring.}
## Testing Levels
### Unit Tests
#### EXAMPLE:
- **Scope:** Test individual functions, methods, or components in isolation. Focus on business logic, calculations, and conditional paths within a single module.
- **Tools:** {e.g., Jest, Pytest, Go testing package, JUnit, NUnit}
- **Mocking/Stubbing:** {How are dependencies mocked? e.g., Jest mocks, Mockito, Go interfaces}
- **Location:** {e.g., `test/unit/`, adhering to the structure in `docs/project-structure.md` or alongside source files (`*.test.ts`)}
- **Expectations:** {e.g., Should cover all significant logic paths. Fast execution.}
### Integration Tests
#### EXAMPLE:
- **Scope:** Verify the interaction and collaboration between multiple internal components or modules. Test the flow of data and control within a specific feature or workflow slice. May involve mocking external APIs or databases, or using test containers.
- **Tools:** {e.g., Jest, Pytest, Go testing package, Testcontainers, Supertest (for APIs)}
- **Location:** {e.g., `test/integration/`, adhering to the structure in `docs/project-structure.md`}
- **Expectations:** {e.g., Focus on module boundaries and contracts. Slower than unit tests.}
### End-to-End (E2E) / Acceptance Tests
#### EXAMPLE:
- **Scope:** Test the entire system flow from an end-user perspective. Interact with the application through its external interfaces (UI or API). Validate complete user journeys or business processes against real or near-real dependencies.
- **Tools:** {e.g., Playwright, Cypress, Selenium (for UI); Postman/Newman, K6 (for API)}
- **Environment:** {Run against deployed environments (e.g., Staging) or a locally composed setup (Docker Compose).}
- **Location:** {e.g., `test/e2e/`, adhering to the structure in `docs/project-structure.md`}
- **Expectations:** {Cover critical user paths. Slower, potentially flaky, run less frequently (e.g., pre-release, nightly).}
### Manual / Exploratory Testing (Optional)
#### EXAMPLE:
- **Scope:** {Where is manual testing still required? e.g., Exploratory testing for usability, testing complex edge cases.}
- **Process:** {How is it performed and tracked?}
### Specialized Testing Types (Add section as needed)
### Performance Testing
#### EXAMPLE:
- **Scope & Goals:** {What needs performance testing? What are the targets (latency, throughput)?}
- **Tools:** {e.g., K6, JMeter, Locust}
### Security Testing
#### EXAMPLE:
- **Scope & Goals:** {e.g., Dependency scanning, SAST, DAST, penetration testing requirements.}
- **Tools:** {e.g., Snyk, OWASP ZAP, Dependabot}
### Accessibility Testing (UI)
#### EXAMPLE:
- **Scope & Goals:** {Target WCAG level, key areas.}
- **Tools:** {e.g., Axe, Lighthouse, manual checks}
### Visual Regression Testing (UI)
#### EXAMPLE:
- **Scope & Goals:** {Prevent unintended visual changes.}
- **Tools:** {e.g., Percy, Applitools Eyes, Playwright visual comparisons}
### Test Data Management
#### EXAMPLE:
{How is test data generated, managed, and reset for different testing levels?}
## Key Reference Documents
See docs/index.md
- docs/front-end-architecture.md {If applicable, for detailed frontend technical design}
## Change Log
| Change | Date | Version | Description | Author |
| ------ | ---- | ------- | ----------- | ------ |
## Epic Story updates
{ Upon completion of all sections, any changes needed for epics or stories will be listed here (if there are any)}
## Prompt for the Design Architect
{ Optional section }
- External API Calls: {e.g., Use `

4
BETA-V3/gems-and-gpts/templates/front-end-architecture.txt
View File

@@ -36,14 +36,14 @@
{ This document details the technical architecture specifically for the frontend of {Project Name}. It complements the main {Project Name} Architecture Document and the UI/UX Specification. The goal is to provide a clear blueprint for frontend development, ensuring consistency, maintainability, and alignment with the overall system design and user experience goals. }
- **Link to Main Architecture Document:** {e.g., `docs/architecture.md`}
- **Link to Main Architecture Document:** {e.g., `docs/architecture.md`} (Note: The overall system architecture, including Monorepo/Polyrepo decisions and backend structure, will influence frontend choices, especially around shared code or API interaction patterns.)
- **Link to UI/UX Specification:** {e.g., `docs/ui-ux-spec.md`}
- **Link to Primary Design Files (Figma, Sketch, etc.):** {From UI/UX Spec}
- **Link to Deployed Storybook / Component Showcase (if applicable):** {URL}
## Overall Frontend Philosophy & Patterns
{ Describe the core architectural decisions and patterns chosen for the frontend. This should align with the "Definitive Tech Stack Selections" in the main architecture document. }
{ Describe the core architectural decisions and patterns chosen for the frontend. This should align with the "Definitive Tech Stack Selections" in the main architecture document and consider implications from the overall system architecture (e.g., monorepo vs. polyrepo, backend service structure). }
- **Framework & Core Libraries:** {e.g., React 18.x with Next.js 13.x, Angular 16.x, Vue 3.x with Nuxt.js. Briefly reiterate why these were chosen if not detailed enough in the main arch doc.}
- **Component Architecture:** {e.g., Atomic Design principles, Presentational vs. Container components, use of specific component libraries like Material UI, Tailwind CSS for styling approach.}

3
BETA-V3/gems-and-gpts/templates/prd.txt
View File

@@ -30,6 +30,8 @@ This section is not intended to be a detailed UI specification but rather a prod
This is where we can list information mostly to be used by the architect to produce the technical details. This could be anything we already know or found out from the user at a technical high level. Inquire about this from the user to get a basic idea of languages, frameworks, knowledge of starter templates, libraries, external apis, potential library choices etc...
- **Repository & Service Architecture:** {CRITICAL DECISION: Document the chosen repository structure (e.g., Monorepo, Polyrepo) and the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo). Explain the rationale based on project goals, MVP scope, team structure, and scalability needs. This decision directly impacts the technical approach and informs the Architect Agent.}
### Testing requirements
How will we validate functionality beyond unit testing? Will we want manual scripts or testing, e2e, integration etc... figure this out from the user to populate this section
@@ -74,6 +76,7 @@ Based on our discussions and requirements analysis for the {Product Name}, I've
### Technical Infrastructure
- **Repository & Service Architecture Decision:** {Reiterate the decision made in 'Technical Assumptions', e.g., Monorepo with Next.js frontend and Python FastAPI backend services within the same repo; or Polyrepo with separate Frontend (Next.js) and Backend (Spring Boot Microservices) repositories.}
- **Starter Project/Template:** {Information about any starter projects, templates, or existing codebases that should be used}
- **Hosting/Cloud Provider:** {Specified cloud platform (AWS, Azure, GCP, etc.) or hosting requirements}
- **Frontend Platform:** {Framework/library preferences or requirements (React, Angular, Vue, etc.)}

1
BETA-V3/gems-and-gpts/templates/project-brief.txt
View File

@@ -35,6 +35,7 @@
## Known Technical Constraints or Preferences
- **Constraints:** {List any known limitations and technical mandates or preferences - e.g., budget, timeline, specific technology mandates, required integrations, compliance needs.}
- **Initial Architectural Preferences (if any):** {Capture any early thoughts or strong preferences regarding repository structure (e.g., monorepo, polyrepo) and overall service architecture (e.g., monolith, microservices, serverless components). This is not a final decision point but for initial awareness.}
- **Risks:** {Identify potential risks - e.g., technical challenges, resource availability, market acceptance, dependencies.}
- **User Preferences:** {Any specific requests from the user that are not a high level feature that could direct technology or library choices, or anything else that came up in the brainstorming or drafting of the PRD that is not included in prior document sections}