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

Task template standardization improvements (#163)

Browse Source 
create-doc-from-template used with create-prd template with new template with llm instruction standardization format.
ide-web agent simplifications, removal of overlap, and agent name alignment
advanced elicitation streamlined throughout creation of PRD
This commit is contained in:
Brian
2025-06-05 21:22:01 -05:00
committed by GitHub
parent fa470c92fd
commit 04972720d0
18 changed files with 2496 additions and 791 deletions
Download Patch File Download Diff File Expand all files Collapse all files

270
bmad-agent/templates/prd-tmpl.md
View File

@@ -1,113 +1,182 @@
# {Project Name} Product Requirements Document (PRD)
# {{Project Name}} Product Requirements Document (PRD)
## Goal, Objective and Context
[[LLM: If available, review any provided document or ask if any are optionally available: Project Brief]]
This should come mostly from the user or the provided brief, but ask for clarifications as needed.
## Goals and Background Context
## Functional Requirements (MVP)
[[LLM: Populate the 2 child sections based on what we have received from user description or the provided brief. Allow user to review the 2 sections and offer changes before proceeding]]
You should have a good idea at this point, but clarify suggest question and explain to ensure these are correct.
### Goals
## Non Functional Requirements (MVP)
[[LLM: Bullet list of 1 line desired outcomes the PRD will deliver if successful - user and project desires]]
You should have a good idea at this point, but clarify suggest question and explain to ensure these are correct.
### Background Context
## User Interaction and Design Goals
[[LLM: 1-2 short paragraphs summarizing the background context, such as what we learned in the brief without being redundant with the goals, what and why this solves a problem, what the current landscape or need is etc...]]
{
If the product includes a User Interface (UI), this section captures the Product Manager's high-level vision and goals for the User Experience (UX). This information will serve as a crucial starting point and brief for the Design Architect.
## Requirements
Consider and elicit information from the user regarding:
[[LLM: Draft the list of functional and non functional requirements under the two child sections, and immediately execute tasks#advanced-elicitation display]]
- **Overall Vision & Experience:** What is the desired look and feel (e.g., "modern and minimalist," "friendly and approachable," "data-intensive and professional")? What kind of experience should users have?
- **Key Interaction Paradigms:** Are there specific ways users will interact with core features (e.g., "drag-and-drop interface for X," "wizard-style setup for Y," "real-time dashboard for Z")?
- **Core Screens/Views (Conceptual):** From a product perspective, what are the most critical screens or views necessary to deliver the MVP's value? (e.g., "Login Screen," "Main Dashboard," "Item Detail Page," "Settings Page").
- **Accessibility Aspirations:** Any known high-level accessibility goals (e.g., "must be usable by screen reader users").
- **Branding Considerations (High-Level):** Any known branding elements or style guides that must be incorporated?
- **Target Devices/Platforms:** (e.g., "primarily web desktop," "mobile-first responsive web app").
### Functional
This section is not intended to be a detailed UI specification but rather a product-focused brief to guide the subsequent detailed work by the Design Architect, who will create the comprehensive UI/UX Specification document.
}
[[LLM: Each Requirement will be a bullet markdown and an identifier sequence starting with FR`.]]
@{example: - FR6: The Todo List uses AI to detect and warn against adding potentially duplicate todo items that are worded differently.}
### Non Functional
[[LLM: Each Requirement will be a bullet markdown and an identifier sequence starting with NFR`.]]
@{example: - NFR1: AWS service usage **must** aim to stay within free-tier limits where feasible.}
^^CONDITION: has_ui^^
## User Interface Design Goals
[[LLM: Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
1. Pre-fill all subsections with educated guesses based on project context
2. Present the complete rendered section to user
3. Clearly let the user know where assumptions were made
4. Ask targeted questions for unclear/missing elements or areas needing more specification
5. This is NOT detailed UI spec - focus on product vision and user goals
6. After section completion, immediately apply `tasks#advanced-elicitation` protocol]]
### Overall UX Vision
### Key Interaction Paradigms
### Core Screens and Views
[[LLM: From a product perspective, what are the most critical screens or views necessary to deliver the the PRD values and goals? This is meant to be Conceptual High Level to Drive Rough Epic or User Stories]]
@{example}
- Login Screen
- Main Dashboard
- Item Detail Page
- Settings Page
@{/example}
### Accessibility: { None, WCAG, etc }
### Branding
[[LLM: Any known branding elements or style guides that must be incorporated?]]
@{example}
- Replicate the look and feel of early 1900s black and white cinema, including animated effects replicating film damage or projector glitches during page or state transitions.
- Attached is the full color pallet and tokens for our corporate branding.
@{/example}
### Target Device and Platforms
@{example}
"Web Responsive, and all mobile platforms", "IPhone Only", "ASCII Windows Desktop"
@{/example}
^^/CONDITION: has_ui^^
## Technical Assumptions
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...
[[LLM: Gather technical decisions that will guide the Architect. Steps:
- **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.}
1. Check if `data#technical-preferences` file exists - use it to pre-populate choices
2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
3. For unknowns, offer guidance based on project goals and MVP scope
4. Document ALL technical choices with rationale (why this choice fits the project)
5. These become constraints for the Architect - be specific and complete
6. After section completion, apply `tasks#advanced-elicitation` protocol.]]
### Repository Structure: { Monorepo, Polyrepo, etc...}
### Service Architecture
[[LLM: CRITICAL DECISION - Document the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo).]]
### 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
[[LLM: CRITICAL DECISION - Document the testing requirements, unit only, integration, e2e, manual, need for manual testing convenience methods).]]
## Epic Overview
### Additional Technical Assumptions and Requests
- **Epic {#}: {Title}**
- Goal: {A concise 1-2 sentence statement describing the primary objective and value of this Epic.}
- Story {#}: As a {type of user/system}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}.
- {Acceptance Criteria List}
- Story {#}: As a {type of user/system}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}.
- {Acceptance Criteria List}
- **Epic {#}: {Title}**
- Goal: {A concise 1-2 sentence statement describing the primary objective and value of this Epic.}
- Story {#}: As a {type of user/system}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}.
- {Acceptance Criteria List}
- Story {#}: As a {type of user/system}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}.
- {Acceptance Criteria List}
[[LLM: Throughout the entire process of drafting this document, if any other technical assumptions are raised or discovered appropriate for the architect, add them here as additional bulleted items]]
## Key Reference Documents
## Epics
{ This section will be created later, from the sections prior to this being carved up into smaller documents }
[[LLM: First, present a high-level list of all epics for user approval, the epic_list and immediately execute tasks#advanced-elicitation display. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
## Out of Scope Ideas Post MVP
CRITICAL: Epics MUST be logically sequential following agile best practices:
Anything you and the user agreed it out of scope or can be removed from scope to keep MVP lean. Consider the goals of the PRD and what might be extra gold plating or additional features that could wait until the MVP is completed and delivered to assess functionality and market fit or usage.
- Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
- Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
- Not every project needs multiple epics, an epic needs to deliver value. For example, an API completed can deliver value even if a UI is not complete and planned for a separate epic.
- Err on the side of less epics, but let the user know your rationale and offer options for splitting them if it seems some are too large or focused on disparate things.
- Cross Cutting Concerns should flow through epics and stories and not be final stories. For example, adding a logging framework as a last story of an epic, or at the end of a project as a final epic or story would be terrible as we would not have logging from the beginning.]]
## [OPTIONAL: For Simplified PM-to-Development Workflow Only] Core Technical Decisions & Application Structure
<<REPEAT: epic_list>>
{This section is to be populated ONLY if the PM is operating in the 'Simplified PM-to-Development Workflow'. It captures essential technical foundations that would typically be defined by an Architect, allowing for a more direct path to development. This information should be gathered after initial PRD sections (Goals, Users, etc.) are drafted, and ideally before or in parallel with detailed Epic/Story definition, and updated as needed.}
- Epic{{epic_number}} {{epic_title}}: {{short_goal}}
### Technology Stack Selections
<</REPEAT>>
{Collaboratively define the core technologies. Be specific about choices and versions where appropriate.}
@{example: epic_list}
- **Primary Backend Language/Framework:** {e.g., Python/FastAPI, Node.js/Express, Java/Spring Boot}
- **Primary Frontend Language/Framework (if applicable):** {e.g., TypeScript/React (Next.js), JavaScript/Vue.js}
- **Database:** {e.g., PostgreSQL, MongoDB, AWS DynamoDB}
- **Key Libraries/Services (Backend):** {e.g., Authentication (JWT, OAuth provider), ORM (SQLAlchemy), Caching (Redis)}
- **Key Libraries/Services (Frontend, if applicable):** {e.g., UI Component Library (Material-UI, Tailwind CSS + Headless UI), State Management (Redux, Zustand)}
- **Deployment Platform/Environment:** {e.g., Docker on AWS ECS, Vercel, Netlify, Kubernetes}
- **Version Control System:** {e.g., Git with GitHub/GitLab}
1. Foundation & Core Infrastructure: Establish project setup, authentication, and basic user management
2. Core Business Entities: Create and manage primary domain objects with CRUD operations
3. User Workflows & Interactions: Enable key user journeys and business processes
4. Reporting & Analytics: Provide insights and data visualization for users
### Proposed Application Structure
@{/example}
{Describe the high-level organization of the codebase. This might include a simple text-based directory layout, a list of main modules/components, and a brief explanation of how they interact. The goal is to provide a clear starting point for developers.}
[[LLM: After the epic list is approved, present each `epic_details` with all its stories and acceptance criteria as a complete review unit and immediately execute tasks#advanced-elicitation display, before moving on to the next epic.]]
Example:
<<REPEAT: epic_details>>
```
/
├── app/ # Main application source code
│ ├── api/ # Backend API routes and logic
│ │ ├── v1/
│ │ └── models.py
│ ├── web/ # Frontend components and pages (if monolithic)
│ │ ├── components/
│ │ └── pages/
│ ├── core/ # Shared business logic, utilities
│ └── main.py # Application entry point
├── tests/ # Unit and integration tests
├── scripts/ # Utility scripts
├── Dockerfile
├── requirements.txt
└── README.md
```
## Epic {{epic_number}} {{epic_title}}
- **Monorepo/Polyrepo:** {Specify if a monorepo or polyrepo structure is envisioned, and briefly why.}
- **Key Modules/Components and Responsibilities:**
- {Module 1 Name}: {Brief description of its purpose and key responsibilities}
- {Module 2 Name}: {Brief description of its purpose and key responsibilities}
- ...
- **Data Flow Overview (Conceptual):** {Briefly describe how data is expected to flow between major components, e.g., Frontend -> API -> Core Logic -> Database.}
{{epic_goal}} [[LLM: Expanded goal - 2-3 sentences describing the objective and value all the stories will achieve]]
[[LLM: CRITICAL STORY SEQUENCING REQUIREMENTS:
- Stories within each epic MUST be logically sequential
- Each story should be a "vertical slice" delivering complete functionality
- No story should depend on work from a later story or epic
- Identify and note any direct prerequisite stories
- Focus on "what" and "why" not "how" (leave technical implementation to Architect) yet be precise enough to support a logical sequential order of operations from story to story.
- Ensure each story delivers clear user or business value, try to avoid enablers and build them into stories that deliver value.
- Size stories for AI agent execution: Each story must be completable by a single AI agent in one focused session without context overflow
- Think "junior developer working for 2-4 hours" - stories must be small, focused, and self-contained
- If a story seems complex, break it down further as long as it can deliver a vertical slice
- Each story should result in working, testable code before the agent's context window fills]]
<<REPEAT: story>>
### Story {{epic_number}}.{{story_number}} {{story_title}}
As a {{user_type}},
I want {{action}},
so that {{benefit}}.
#### Acceptance Criteria
[[LLM: Define clear, comprehensive, and testable acceptance criteria that:
- Precisely define what "done" means from a functional perspective
- Are unambiguous and serve as basis for verification
- Include any critical non-functional requirements from the PRD
- Consider local testability for backend/data components
- Specify UI/UX requirements and framework adherence where applicable
- Avoid cross-cutting concerns that should be in other stories or PRD sections]]
<<REPEAT: criteria>>
- {{criterion number}}: {{criteria}}
<</REPEAT>>
<</REPEAT>>
<</REPEAT>>
## Change Log
@@ -118,49 +187,18 @@ Example:
## Checklist Results Report
[[LLM: Before running the checklist and drafting the prompts, offer to output the full updated PRD. If outputting it, confirm with the user that you will be proceeding to run the checklist and produce the report. Once the user confirms, execute the `pm-checklist` and populate the results in this section.]]
----- END Checklist START Design Architect `UI/UX Specification Mode` Prompt ------
## Design Architect Prompt
[[LLM: This section will contain the prompt for the Design Architect, keep it short and to the point to initiate create architecture mode using this document as input.]]
----- END Design Architect `UI/UX Specification Mode` Prompt START Architect Prompt ------
## Initial Architect Prompt
## Architect Prompt
Based on our discussions and requirements analysis for the {Product Name}, I've compiled the following technical guidance to inform your architecture analysis and decisions to kick off Architecture Creation Mode:
[[LLM: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.]]
### 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.)}
- **Backend Platform:** {Framework/language preferences or requirements (Node.js, Python/Django, etc.)}
- **Database Requirements:** {Relational, NoSQL, specific products or services preferred}
### Technical Constraints
- {List any technical constraints that impact architecture decisions}
- {Include any mandatory technologies, services, or platforms}
- {Note any integration requirements with specific technical implications}
### Deployment Considerations
- {Deployment frequency expectations}
- {CI/CD requirements}
- {Environment requirements (local, dev, staging, production)}
### Local Development & Testing Requirements
{Include this section only if the user has indicated these capabilities are important. If not applicable based on user preferences, you may remove this section.}
- {Requirements for local development environment}
- {Expectations for command-line testing capabilities}
- {Needs for testing across different environments}
- {Utility scripts or tools that should be provided}
- {Any specific testability requirements for components}
### Other Technical Considerations
- {Security requirements with technical implications}
- {Scalability needs with architectural impact}
- {Any other technical context the Architect should consider}
----- END Architect Prompt -----
----- END Architect Prompt ------

2
bmad-agent/templates/project-brief-tmpl.md
View File

@@ -45,7 +45,7 @@
## PM Prompt
This Project Brief provides the full context for {Project Name}. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section 1 at a time, asking for any necessary clarification or suggesting improvements as your mode 1 programming allows.
This Project Brief provides the full context for {Project Name}. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section as the template indicates, asking for any necessary clarification or suggesting improvements as your mode 1 programming allows.
<example_handoff_prompt>
This Project Brief provides the full context for Mealmate. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section 1 at a time, asking for any necessary clarification or suggesting improvements as your mode 1 programming allows.</example_handoff_prompt>

43
bmad-agent/templates/template-format.md Normal file
View File

@@ -0,0 +1,43 @@
# MD Template Format:
- {{placeholder}} = Simple text replacement placeholder
- [[LLM: instruction]] = Instructions for the LLM (not included in output)
- <<REPEAT: section_name>> ... <</REPEAT>> = Repeating section
- ^^CONDITION: condition_name^^ ... ^^/CONDITION: condition_name^^ = Conditional section that will render if the condition_name logically applies
- @{example: content} = Single line example content for LLM guidance - do not render
- @{example} ... @{/example} = Multi-line example content for LLM guidance - do not render
## Critical Template Usage Rules
- CRITICAL: Never display or output template markup formatting, LLM instructions or examples
- they MUST be used by you the agent only, AND NEVER shown to users in chat or documented output\*\*
- Present only the final, clean content to users
- Replace template variables with actual project-specific content
- Show examples only when they add value, without the markup
- Process all conditional logic internally - show only relevant sections
- For Canvas mode: Update the document with clean, formatted content only
@{example}
# My Template Foo
[[LLM: Check the current system date and if the user name is unknown, just say hello]]
Hello {{users name}}, this is your foo report for {{todays date}}
<<REPEAT: single_foo>>
[[LLM: For Each Foo, Create a matching creative Bar]]
## Foo: {{Bar}}
<</REPEAT>>
^^CONDITION: if_BAZ_exists^^
## BAZ
### You haz BAZ! Here is your daily Baz Forecast!
[[LLM: Give the user their daily baz report here]]
^^/CONDITION: if_BAZ_exists^^
@{/example}