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

12
bmad-agent/data/technical-preferences.md Normal file
View File

@@ -0,0 +1,12 @@
# User-Defined Preferred Patterns and Preferences
List out your preferred:
- technical preferences
- design patterns
- languages
- framework
- etc...
Anything you learn or prefer over time to drive future project choices, add them here.
These will be used by the agents when producing PRD and Architectures

6
bmad-agent/data/technical-preferences.txt
View File

@@ -1,6 +0,0 @@
# User-Defined Preferred Patterns and Preferences
See example files in this folder.
list out your technical preferences, patterns you like to follow, language framework or starter project preferences.
Anything you learn or prefer over time to drive future project choices, add the here.

41
bmad-agent/ide-bmad-orchestrator.cfg.md
View File

@@ -14,7 +14,7 @@ Example: If above cfg has `agent-root: root/foo/` and `tasks: (agent-root)/tasks
## Title: Analyst
- Name: Wendy
- Name: Mary
- Customize: ""
- Description: "Research assistant, brain storming coach, requirements gathering, project briefs."
- Persona: "analyst.md"
@@ -25,18 +25,19 @@ Example: If above cfg has `agent-root: root/foo/` and `tasks: (agent-root)/tasks
## Title: Product Manager (PM)
- Name: Bill
- Name: John
- Customize: ""
- Description: "Jack has only one goal - to produce or maintain the best possible PRD - or discuss the product with you to ideate or plan current or future efforts related to the product."
- Description: "Main goal is to help produce or maintain the best possible PRD and represent the end user the product will serve."
- Persona: "pm.md"
- Tasks:
- [Create PRD](create-prd.md)
- [Create Document](tasks#create-doc-from-template):
- [Prd](templates#prd-tmpl)
## Title: Architect
- Name: Timmy
- Name: Fred
- Customize: ""
- Description: "Generates Architecture, Can help plan a story, and will also help update PRD level epic and stories."
- Description: "For system architecture, technical design, architecture checklists."
- Persona: "architect.md"
- Tasks:
- [Create Architecture](create-architecture.md)
@@ -46,30 +47,34 @@ Example: If above cfg has `agent-root: root/foo/` and `tasks: (agent-root)/tasks
## Title: Design Architect
- Name: Karen
- Name: Jane
- Customize: ""
- Description: "Help design a website or web application, produce prompts for UI GEneration AI's, and plan a full comprehensive front end architecture."
- Description: "For UI/UX specifications, front-end architecture, and UI 1-shot prompting."
- Persona: "design-architect.md"
- Tasks:
- [Create Frontend Architecture](create-frontend-architecture.md)
- [Create Next Story](create-ai-frontend-prompt.md)
- [Slice Documents](create-uxui-spec.md)
## Title: Product Owner AKA PO
## Title: PO
- Name: Jimmy
- Name: Sarah
- Customize: ""
- Description: "Jack of many trades, from PRD Generation and maintenance to the mid sprint Course Correct. Also able to draft masterful stories for the dev agent."
- Description: "Product Owner helps validate the artifacts are all cohesive with a master checklist, and also helps coach significant changes"
- Persona: "po.md"
- Tasks:
- [Create PRD](create-prd.md)
- [Create Next Story](create-next-story-task.md)
- [Slice Documents](doc-sharding-task.md)
- [Correct Course](correct-course.md)
- checklists:
- [Po Master Checklist](checklists#po-master-checklist)
- [Change Checklist](checklists#change-checklist)
- templates:
- [Story Tmpl](templates#story-tmpl)
- tasks:
- [Checklist Run Task](tasks#checklist-run-task)
- [Extracts Epics and shards the Architecture](tasks#doc-sharding-task)
- [Correct Course](tasks#correct-course)
## Title: Frontend Dev
- Name: Rodney
- Name: Ellyn
- Customize: "Specialized in NextJS, React, Typescript, HTML, Tailwind"
- Description: "Master Front End Web Application Developer"
- Persona: "dev.ide.md"
@@ -94,7 +99,7 @@ Example: If above cfg has `agent-root: root/foo/` and `tasks: (agent-root)/tasks
## Title: Scrum Master: SM
- Name: Fran
- Name: Bob
- Customize: ""
- Description: "Specialized in Next Story Generation"
- Persona: "sm.md"

77
bmad-agent/tasks/advanced-elicitation.md Normal file
View File

@@ -0,0 +1,77 @@
# Advanced Elicitation Task
## Purpose
- Provide optional reflective and brainstorming actions to enhance content quality
- Enable deeper exploration of ideas through structured elicitation techniques
- Support iterative refinement through multiple analytical perspectives
## Task Instructions
### 1. Ask for review and Present Action List
[[LLM: Ask the user to review the {drafted document section, or context or document this protocol was executed from}. In the SAME message, inform them that they can suggest additions, removals, or modifications, OR they can select an action by number from the 'Advanced Reflective, Elicitation & Brainstorming Actions'. Then, present ONLY the numbered list (0-9) of these actions as defined in tasks#advanced-elicitation. Conclude by stating that selecting 9 will proceed to the next section. Await user selection. If an elicitation action (0-8) is chosen, execute it and then re-offer this combined review/elicitation choice. If option 9 is chosen, or if the user provides direct feedback on requirements, proceed accordingly.]]
**Present the numbered list (0-9) with this exact format:**
```
**Advanced Reflective, Elicitation & Brainstorming Actions**
Choose an action (0-9 - 9 to bypass - HELP for explanation of these options):
0. Expand or Contract for Audience
1. Explain Reasoning (CoT Step-by-Step)
2. Critique and Refine
3. Analyze Logical Flow and Dependencies
4. Assess Alignment with Overall Goals
5. Identify Potential Risks and Unforeseen Issues
6. Challenge from Critical Perspective (Self or Other Persona)
7. Explore Diverse Alternatives (ToT-Inspired)
8. Hindsight is 20/20: The 'If Only...' Reflection
9. Proceed / No Further Actions
```
### 2. Processing Guidelines
**Do NOT show:**
- The full protocol text with `[[LLM: ...]]` instructions
- Detailed explanations of each option unless executing or the user asks, when giving the definition you can modify to tie its relevance
- Any internal template markup
**After user selection from the list:**
- Execute the chosen action according to the protocol instructions below
- Ask if they want to select another action or proceed with option 9 once complete
- Continue until user selects option 9 or indicates completion
## Action Definitions
0. Expand or Contract for Audience
[[LLM: Ask the user whether they want to 'expand' on the content (add more detail, elaborate) or 'contract' it (simplify, clarify, make more concise). Also, ask if there's a specific target audience they have in mind. Once clarified, perform the expansion or contraction from your current role's perspective, tailored to the specified audience if provided.]]
1. Explain Reasoning (CoT Step-by-Step)
[[LLM: Explain the step-by-step thinking process, characteristic of your role, that you used to arrive at the current proposal for this content.]]
2. Critique and Refine
[[LLM: From your current role's perspective, review your last output or the current section for flaws, inconsistencies, or areas for improvement, and then suggest a refined version reflecting your expertise.]]
3. Analyze Logical Flow and Dependencies
[[LLM: From your role's standpoint, examine the content's structure for logical progression, internal consistency, and any relevant dependencies. Confirm if elements are presented in an effective order.]]
4. Assess Alignment with Overall Goals
[[LLM: Evaluate how well the current content contributes to the stated overall goals of the document, interpreting this from your specific role's perspective and identifying any misalignments you perceive.]]
5. Identify Potential Risks and Unforeseen Issues
[[LLM: Based on your role's expertise, brainstorm potential risks, overlooked edge cases, or unintended consequences related to the current content or proposal.]]
6. Challenge from Critical Perspective (Self or Other Persona)
[[LLM: Adopt a critical perspective on the current content. If the user specifies another role or persona (e.g., 'as a customer', 'as [Another Persona Name]'), critique the content or play devil's advocate from that specified viewpoint. If no other role is specified, play devil's advocate from your own current persona's viewpoint, arguing against the proposal or current content and highlighting weaknesses or counterarguments specific to your concerns. This can also randomly include YAGNI when appropriate, such as when trimming the scope of an MVP, the perspective might challenge the need for something to cut MVP scope.]]
7. Explore Diverse Alternatives (ToT-Inspired)
[[LLM: From your role's perspective, first broadly brainstorm a range of diverse approaches or solutions to the current topic. Then, from this wider exploration, select and present 2 distinct alternatives, detailing the pros, cons, and potential implications you foresee for each.]]
8. Hindsight is 20/20: The 'If Only...' Reflection
[[LLM: In your current persona, imagine it's a retrospective for a project based on the current content. What's the one 'if only we had known/done X...' that your role would humorously or dramatically highlight, along with the imagined consequences?]]
9. Proceed / No Further Actions
[[LLM: Acknowledge the user's choice to finalize the current work, accept the AI's last output as is, or move on to the next step without selecting another action from this list. Prepare to proceed accordingly.]]

93
bmad-agent/tasks/create-doc-from-template.md Normal file
View File

@@ -0,0 +1,93 @@
# Create Document from Template Task
## Purpose
- Generate documents from any specified template following embedded instructions
- Support multiple document types through template-driven approach
- Enable any persona to create consistent, well-structured documents
## Instructions
### 1. Identify Template and Context
- Determine which template to use (user-provided or list available for selection to user)
- agent-config specific agents will list what docs they have available under this task, for each item consider it a unique task. So if the user had for example:
@{example}
- tasks:
- [Create Document](tasks#create-doc-from-template):
- [Prd](templates#prd-tmpl)
- [Architecture](templates#architecture-tmpl)
@{/example}
you would list `Create Document PRD` and `Create Document Architecture` as tasks the agent could perform.
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
- Understand the document purpose and target audience
### 2. Determine Interaction Mode
Confirm with the user their preferred interaction style:
- **Incremental:** Work through chunks of the document.
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
### 3. Execute Template
- Load specified template from `templates#*` or the /templates directory
- Follow ALL embedded LLM instructions within the template
- Process template markup according to `templates#template-format` conventions
### 4. Template Processing Rules
**CRITICAL: Never display template markup, LLM instructions, or examples to users**
- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process <<REPEAT>> sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them
### 5. Content Generation
- **Incremental Mode**: Present each major section for review before proceeding
- **YOLO Mode**: Generate all sections, then review complete document with user
- Apply any elicitation protocols specified in template
- Incorporate user feedback and iterate as needed
### 6. Validation
If template specifies a checklist:
- Run the appropriate checklist against completed document
- Document completion status for each item
- Address any deficiencies found
- Present validation summary to user
### 7. Final Presentation
- Present clean, formatted content only
- Ensure all sections are complete
- DO NOT truncate or summarize content
- Begin directly with document content (no preamble)
- Include any handoff prompts specified in template
## Key Resources
- **Template Format:** `templates#template-format`
- **Available Templates:** All files in `templates#` directory
- **Checklists:** As specified by template or persona
- **User Preferences:** `data#technical-preferences`
## Important Notes
- This task is template and persona agnostic
- All specific instructions are embedded in templates
- Focus on faithful template execution and clean output
- Template markup is for AI processing only - never expose to users

248
bmad-agent/tasks/create-prd.md
View File

@@ -2,228 +2,88 @@
## Purpose
- Transform inputs into core product definition documents conforming to the `prd-tmpl` template.
- Define clear MVP scope focused on essential functionality.
- Provide foundation for Architect and eventually AI dev agents.
Remember as you follow the upcoming instructions:
- Your documents form the foundation for the entire development process.
- Output will be directly used by the Architect to create an architecture document and solution designs to make definitive technical decisions.
- Your epics/stories will ultimately be transformed into development tasks.
- While you focus on the "what" not "how", be precise enough to support a logical sequential order of operations that once later further details can logically be followed where a story will complete what is needed.
- Transform inputs into core product definition documents conforming to a PRD template
- Define clear MVP scope focused on essential functionality
- Provide foundation for Architect and Design Architect to help create technical artifacts which will in turn later draft further details for very junior engineers or simple dev ai agents.
## Instructions
### 1. Define Project Workflow Context
### 1. Review Inputs
- Before PRD generation, ask the user to choose their intended workflow:
Review all provided inputs including project brief, research documents, prd template and user ideas to guide PRD generation.
A. **Outcome Focused (Default):** (Agent defines outcome-focused User Stories, leaving detailed technical "how" for Architect/Scrum Master. Capture nuances as "Notes for Architect/Scrum Master in the Prompt for Architect.")
### 2. Determine Interaction Mode
B. **Very Technical (Not Recommended):** (Agent adopts a "solution-aware" stance, providing more detailed, implementation-aware Acceptance Criteria to bridge to development, potentially with no architect involved at all, instead filling in all of the technical details. \<important_note\>When this workflow is selected, you are also responsible for collaboratively defining and documenting key technical foundations—such as technology stack choices and proposed application structure—directly within a new, dedicated section of the PRD template titled '[OPTIONAL: For Simplified PM-to-Development Workflow Only] Core Technical Decisions & Application Structure'.\</important_note\>)
Confirm with the user their preferred interaction style:
- Explain this choice sets a default detail level, which can be fine-tuned later per story/epic.
- **Incremental:** Work through sections one at a time via chat messages as defined in the template.
### 2. Determine Interaction Mode (for PRD Structure & Detail)
- **YOLO Mode:** Draft the complete PRD making assumptions as necessary. Present full document at once, noting which sections required assumptions.
- Confirm with the user their preferred interaction style for creating the PRD if unknown - INCREMENTAL or YOLO?:
- **Incrementally (Default):** Address PRD sections sequentially, seeking feedback on each. For Epics/Stories: first present the ordered Epic list for approval, then detail stories for each Epic one by one.
- **"YOLO" Mode:** Draft a more comprehensive PRD (or significant portions with multiple sections, epics, and stories) for a single, larger review.
### 3. Execute Template
### 3. Review inputs provided
- Use the `prd-tmpl` template (or user-specified alternative template)
- Follow all embedded LLM instructions within the template
- Template contains section-specific guidance and examples
Review the inputs provided so far, such as a project brief, any research, and user input and ideas.
### 4. Template Processing Notes
### 4. Process PRD Sections
- **Incremental Mode**: Present each section for review before proceeding
- **YOLO Mode**: Generate all sections, then review with user
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. After presenting the section to the user, also [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)
Process all template elements according to `templates#template-format` conventions.
<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>
**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 document output**
<important_note>Specifically for "Simplified PM-to-Development Workflow":
After discussing initial PRD sections (like Problem, Goals, User Personas) and before or in parallel with defining detailed Epics and Stories, you must introduce and populate the "[OPTIONAL: For Simplified PM-to-Development Workflow Only] Core Technical Decisions & Application Structure" section of the PRD.
**Content Presentation Guidelines:**
When doing so, first check if a `docs/technical-preferences.md` file exists or has been provided. If it does, inform the user you will consult it to help guide these technical decisions, while still confirming all choices with them. Ask targeted questions such as:
- Present only the final, clean content to users
- Replace template variables with actual project-specific content
- Process all conditional logic internally - show only relevant sections
- For Canvas mode: Update the document with clean, formatted content only
1. "What are your preliminary thoughts on the primary programming languages and frameworks for the backend and frontend (if applicable)? (I will cross-reference any preferences you've noted in `technical-preferences`.)"
2. "Which database system are you considering? (Checking preferences...)"
3. "Are there any specific cloud services, key libraries, or deployment platforms we should plan for at this stage? (Checking preferences...)"
4. "How do you envision the high-level folder structure or main modules of the application? Could you describe the key components and their responsibilities? (I'll consider any structural preferences noted.)"
5. "Will this be a monorepo or are you thinking of separate repositories for different parts of the application?"
This section should be collaboratively filled and updated as needed if subsequent epic/story discussions reveal new requirements or constraints.
### 7. Prepare Handoffs
</important_note\>
Based on PRD content, prepare appropriate next-step prompts:
<important_note>
**If UI Component Exists:**
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](https://www.google.com/search?q=%23guiding-principles-for-epic-and-user-story-generation).
1. Add Design Architect prompt in designated template section
2. Recommend: User engages Design Architect first for UI/UX Specification
3. Then proceed to Architect with enriched PRD
</important_note>
**If No UI Component:**
#### 4A. Epic Presentation and Drafting Strategy
- Add Architect prompt in designated template section
- Recommend proceeding directly to Architect
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.
### 8. Validate with Checklist
#### 4B. Story Generation and Review within Epics (Incremental Mode)
- Run the `pm-checklist` against completed PRD
- Document completion status for each checklist item
- Present summary by section, address any deficiencies
- Generate final checklist report with findings and resolutions
**Once the Epic List is approved, THEN for each Epic, you will proceed as follows:**
### 9. Final Presentation
i. **Draft All Stories for the Current Epic:** Based on the Epic's goal and your discussions, draft all the necessary User Stories for this Epic, following the "Guiding Principles for Epic and User Story Generation".
ii. **Perform Internal Story Analysis & Propose Order:** Before presenting the stories for detailed review, you will internally:
a. **Re-evaluate for Cross-Cutting Concerns:** Ensure no drafted stories should actually be ACs or notes within other stories, as per the guiding principle. Make necessary adjustments.
b. **Analyze for Logical Sequence & Dependencies:** For all stories within this Epic, determine their logical implementation order. Identify any direct prerequisite stories (e.g., "Story X must be completed before Story Y because Y consumes the output of X").
c. **Formulate a Rationale for the Order:** Prepare a brief explanation for why the proposed order is logical.
iii. **Present Proposed Story Set & Order for the Epic:** Present to the user:
a. The complete list of (potentially revised) User Stories for the Epic.
b. The proposed sequence for these stories.
c. Your brief rationale for the sequencing and any key dependencies you've noted (e.g., "I suggest this order because Story 2 builds upon the data prepared in Story 1, and Story 3 then uses the results from Story 2.").
iv. **Collaborative Review of Sequence & Story Shells:** Discuss this proposed structure and sequence with the user. Make any adjustments to the story list or their order based on user feedback.
v. Once the overall structure and sequence of stories for the Epic are agreed upon, THEN you will work with the user to review the details (description, Acceptance Criteria) of each story in the agreed-upon sequence for that Epic.
vi. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)
**General Guidelines:**
#### 4C. Present Complete Draft
- Present complete documents in clean, full format
- DO NOT truncate unchanged information
- Begin directly with content (no introductory text needed)
- Ensure all template sections are properly filled
- **NEVER show template markup, instructions, or processing directives to users**
Present the user with the complete full draft once all sections are completed (or as per YOLO mode interaction).
## Key Resources
#### 4D. UI Component Handoff Note
- **Default Template:** `templates#prd-tmpl`
- **Validation:** `checklists#pm-checklist`
- **User Preferences:** `data#technical-preferences`
- **Elicitation Protocol:** `tasks#advanced-elicitation`
If there is a UI component to this PRD, you can inform the user that the Design Architect should take this final output.
## Important Notes
### 5\. Checklist Assessment
- Use the `pm-checklist` to consider each item in the checklist is met (or n/a) against the PRD.
- Document completion status for each item.
- Present the user with summary of each section of the checklist before going to the next section.
- Address deficiencies with user for input or suggested updates or corrections.
- Once complete and address, output the final checklist with all the checked items or skipped items, the section summary table, and any final notes. The checklist should have any findings that were discuss and resolved or ignored also. This will be a nice artifact for the user to keep.
### 6\. Produce the PRD
Produce the PRD with PM Prompt per the `prd-tmpl` utilizing the following guidance:
**General Presentation & Content:**
- Present Project Briefs (drafts or final) in a clean, full format.
- Crucially, DO NOT truncate information that has not changed from a previous version.
- For complete documents, begin directly with the content (no introductory text is needed).
<important_note>
**Next Steps for UI/UX Specification (If Applicable):**
- If the product described in this PRD includes a user interface:
1. **Include Design Architect Prompt in PRD:** You will add a dedicated section in the PRD document you are producing, specifically at the location marked `(END Checklist START Design Architect UI/UX Specification Mode Prompt)` (as per the `prd-tmpl` structure). This section will contain a prompt for the **Design Architect** agent.
- The prompt should clearly state that the Design Architect is to operate in its **'UI/UX Specification Mode'**.
- It should instruct the Design Architect to use this PRD as primary input to collaboratively define and document detailed UI/UX specifications. This might involve creating/populating a `front-end-spec-tmpl` and ensuring key UI/UX considerations are integrated or referenced back into the PRD to enrich it.
- Example prompt text to insert:
```markdown
## Prompt for Design Architect (UI/UX Specification Mode)
**Objective:** Elaborate on the UI/UX aspects of the product defined in this PRD.
**Mode:** UI/UX Specification Mode
**Input:** This completed PRD document.
**Key Tasks:**
1. Review the product goals, user stories, and any UI-related notes herein.
2. Collaboratively define detailed user flows, wire-frames (conceptual), and key screen mockups/descriptions.
3. Specify usability requirements and accessibility considerations.
4. Populate or create the `front-end-spec-tmpl` document.
5. Ensure that this PRD is updated or clearly references the detailed UI/UX specifications derived from your work, so that it provides a comprehensive foundation for subsequent architecture and development phases.
Please guide the user through this process to enrich the PRD with detailed UI/UX specifications.
```
2. **Recommend User Workflow:** After finalizing this PRD (with the included prompt for the Design Architect), strongly recommend to the user the following sequence:
a. First, engage the **Design Architect** agent (using the prompt you've embedded in the PRD) to operate in **'UI/UX Specification Mode'**. Explain that this step is crucial for detailing the user interface and experience, and the output (e.g., a populated `front-end-spec-tmpl` and potentially updated PRD sections) will be vital.
b. Second, _after_ the Design Architect has completed its UI/UX specification work, the user should then proceed to engage the **Architect** agent (using the 'Initial Architect Prompt' also contained in this PRD). The PRD, now enriched with UI/UX details, will provide a more complete basis for technical architecture design.
- If the product does not include a user interface, you will simply recommend proceeding to the Architect agent using the 'Initial Architect Prompt' in the PRD.
</important_note>
## Guiding Principles for Epic and User Story Generation
### I. Strategic Foundation: Define Core Value & MVP Scope Rigorously
Understand & Clarify Core Needs: Start by deeply understanding and clarifying the core problem this product solves, the essential needs of the defined User Personas (or system actors), and the key business objectives for the Minimum Viable Product (MVP).
Challenge Scope Relentlessly: Actively challenge all requested features and scope at every stage. For each potential feature or story, rigorously ask, "Does this directly support the core MVP goals and provide significant value to a target User Persona?" Clearly identify and defer non-essential functionalities to a Post-MVP backlog.
### II. Structuring the Work: Value-Driven Epics & Logical Sequencing
Organize into Deployable, Value-Driven Epics: Structure the MVP scope into Epics. Each Epic must be designed to deliver a significant, end-to-end, and fully deployable increment of testable functionality that provides tangible value to the user or business. Epics should represent logical functional blocks or coherent user journeys.
Logical Epic Sequencing & Foundational Work:
Ensure the sequence of Epics follows a logical implementation order, making dependencies between Epics clear and explicitly managed.
The first Epic must always establish the foundational project infrastructure (e.g., initial app setup, Git repository, CI/CD pipeline, core cloud service configurations, basic user authentication shell if needed universally) necessary to support its own deployable functionality and that of subsequent Epics.
Ensure Logical Story Sequencing and Dependency Awareness within Epics:
After initially drafting all User Stories for an Epic, but before detailed review with the user, you (the AI Agent executing this task) must explicitly perform an internal review to establish a logical sequence for these stories.
For each story, identify if it has direct prerequisite stories within the same Epic or from already completed Epics.
Propose a clear story order to the user, explaining the rationale based on these dependencies (e.g., "Story X needs to be done before Story Y because..."). Make significant dependencies visible, perhaps as a note within the story description.
### III. Crafting Effective User Stories: Vertical Slices Focused on Value & Clarity
Define Stories as "Vertical Slices": Within each Epic, define User Stories as "vertical slices". This means each story must deliver a complete piece of functionality that achieves a specific user or system goal, potentially cutting through all necessary layers (e.g., UI, API, business logic, database).
Focus on "What" and "Why," Not "How":
Stories will primarily focus on the functional outcome, the user value ("what"), and the reason ("why"). Avoid detailing technical implementation ("how") in the story's main description.
The "As a {specific User Persona/system actor}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}" format is standard. Be precise and consistent when defining the '{specific User Persona/system actor}', ensuring it aligns with defined personas.
Ensure User Value, Not Just Technical Tasks: User Stories must articulate clear user or business value. Avoid creating stories that are purely technical tasks (e.g., "Set up database," "Refactor module X"), unless they are part of the foundational infrastructure Epic or are essential enabling tasks that are explicitly linked to, and justified by, a user-facing story that delivers value.
Appropriate Sizing & Strive for Independence:
Ensure User Stories are appropriately sized for a typical development iteration (i.e., can be completed by the team in one sprint/iteration).
If a vertically sliced story is too large or complex, work with the user to split it into smaller, still valuable, and still vertically sliced increments.
Where feasible, define stories so they can be developed, tested, and potentially delivered independently of others. If dependencies are unavoidable, they must be clearly identified and managed through sequencing.
### IV. Detailing Stories: Comprehensive Acceptance Criteria & Developer Enablement
Clear, Comprehensive, and Testable Acceptance Criteria (ACs):
Every User Story will have detailed, unambiguous, and testable Acceptance Criteria.
ACs precisely define what "done" means for that story from a functional perspective and serve as the basis for verification.
Where a specific Non-Functional Requirement (NFR) from the PRD (e.g., a particular performance target for a specific action, a security constraint for handling certain data) is critical to a story, ensure it is explicitly captured or clearly referenced within its Acceptance Criteria.
Integrate Developer Enablement & Iterative Design into Stories:
Local Testability (CLI): For User Stories involving backend processing or data components, ensure the ACs consider or specify the ability for developers to test that functionality locally (e.g., via CLI commands, local service instances).
Iterative Schema Definition: Database schema changes (new tables, columns) should be introduced iteratively within the User Stories that functionally require them, rather than defining the entire schema upfront.
Upfront UI/UX Standards (if UI applicable): For User Stories with a UI component, ACs should explicitly state requirements regarding look and feel, responsiveness, and adherence to chosen frameworks/libraries (e.g., Tailwind CSS, shadcn/ui) from the start.
### V. Managing Complexity: Addressing Cross-Cutting Concerns Effectively
Critically Evaluate for Cross-Cutting Concerns:
Before finalizing a User Story, evaluate if the described functionality is truly a discrete, user-facing piece of value or if it represents a cross-cutting concern (e.g., a specific logging requirement, a UI theme element used by many views, a core technical enabler for multiple other stories, a specific aspect of error handling).
If a piece of functionality is identified as a cross-cutting concern:
a. Avoid creating a separate User Story for it unless it delivers standalone, testable user value.
b. Instead, integrate the requirement as specific Acceptance Criteria within all relevant User Stories it impacts.
c. Alternatively, if it's a pervasive technical enabler or a non-functional requirement that applies broadly, document it clearly within the relevant PRD section (e.g., 'Non Functional Requirements', 'Technical Assumptions'), or as a note for the Architect within the story descriptions if highly specific.
Your aim is to ensure User Stories remain focused on delivering measurable user value, while still capturing all necessary technical and functional details appropriately.
### VI. Ensuring Quality & Smooth Handoff
Maintain Clarity for Handoff and Architectural Freedom: User Stories, their descriptions, and Acceptance Criteria must be detailed enough to provide the Architect with a clear and comprehensive understanding of "what is required," while allowing for architectural flexibility on the "how."
Confirm "Ready" State: Before considering an Epic's stories complete, ensure each story is effectively "ready" for subsequent architectural review or development planning – meaning it's clear, understandable, testable, its dependencies are noted, and any foundational work (like from the first epic) is accounted for.
## Offer Advanced Self-Refinement & Elicitation Options
(This section is called when needed prior to this)
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
{Instruction for AI Agent: Display the title of each numbered item below. If the user asks what a specific option means, provide a brief explanation of the action you will take, drawing from detailed descriptions tailored for the context.}
1. **Critical Self-Review & User Goal Alignment**
2. **Generate & Evaluate Alternative Design Solutions**
3. **User Journey & Interaction Stress Test (Conceptual)**
4. **Deep Dive into Design Assumptions & Constraints**
5. **Usability & Accessibility Audit Review & Probing Questions**
6. **Collaborative Ideation & UI Feature Brainstorming**
7. **Elicit 'Unforeseen User Needs' & Future Interaction Questions**
8. **Finalize this Section and Proceed.**
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNIT the user indicates it is time to proceed ot the next section (or selects #8)
- This task is template-agnostic - users may specify custom templates
- All detailed instructions are embedded in templates, not this task file
- Focus on orchestration and workflow
- **Template markup is for AI processing only - users should never see output indicators from templates#template-format**

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}

33
bmad-agent/web-bmad-orchestrator-agent.cfg.md
View File

@@ -19,9 +19,6 @@
- "Brain Storming"
- "Deep Research"
- "Project Briefing"
- Interaction Modes:
- "Interactive"
- "YOLO"
- templates:
- [Project Brief Tmpl](templates#project-brief-tmpl)
@@ -29,20 +26,16 @@
- Name: John
- Customize: ""
- Description: "For PRDs, project planning, PM checklists and potential replans."
- Description: "Main goal is to help produce or maintain the best possible PRD and represent the end user the product will serve."
- Persona: "personas#pm"
- checklists:
- [Pm Checklist](checklists#pm-checklist)
- [Change Checklist](checklists#change-checklist)
- templates:
- [Prd Tmpl](templates#prd-tmpl)
- tasks:
- [Create Prd](tasks#create-prd)
- [Create Document](tasks#create-doc-from-template):
- [Prd](templates#prd-tmpl)
- [Correct Course](tasks#correct-course)
- [Create Deep Research Prompt](tasks#create-deep-research-prompt)
- Interaction Modes:
- "Interactive"
- "YOLO"
## Title: Architect
@@ -57,9 +50,6 @@
- tasks:
- [Create Architecture](tasks#create-architecture)
- [Create Deep Research Prompt](tasks#create-deep-research-prompt)
- Interaction Modes:
- "Interactive"
- "YOLO"
## Title: Platform Engineer
@@ -77,7 +67,7 @@
- Name: Jane
- Customize: ""
- Description: "For UI/UX specifications, front-end architecture."
- Description: "For UI/UX specifications, front-end architecture, and UI 1-shot prompting."
- Persona: "personas#design-architect"
- checklists:
- [Frontend Architecture Checklist](checklists#frontend-architecture-checklist)
@@ -88,15 +78,12 @@
- [Create Frontend Architecture](tasks#create-frontend-architecture)
- [Create Ai Frontend Prompt](tasks#create-ai-frontend-prompt)
- [Create UX/UI Spec](tasks#create-uxui-spec)
- Interaction Modes:
- "Interactive"
- "YOLO"
## Title: PO
- Name: Sarah
- Customize: ""
- Description: "Product Owner"
- Description: "Product Owner helps validate the artifacts are all cohesive with a master checklist, and also helps coach significant changes"
- Persona: "personas#po"
- checklists:
- [Po Master Checklist](checklists#po-master-checklist)
@@ -107,9 +94,6 @@
- [Checklist Run Task](tasks#checklist-run-task)
- [Extracts Epics and shards the Architecture](tasks#doc-sharding-task)
- [Correct Course](tasks#correct-course)
- Interaction Modes:
- "Interactive"
- "YOLO"
## Title: SM
@@ -118,15 +102,8 @@
- Description: "A very Technical Scrum Master helps the team run the Scrum process."
- Persona: "personas#sm"
- checklists:
- [Change Checklist](checklists#change-checklist)
- [Story Dod Checklist](checklists#story-dod-checklist)
- [Story Draft Checklist](checklists#story-draft-checklist)
- tasks:
- [Checklist Run Task](tasks#checklist-run-task)
- [Correct Course](tasks#correct-course)
- [Draft a story for dev agent](tasks#story-draft-task)
- templates:
- [Story Tmpl](templates#story-tmpl)
- Interaction Modes:
- "Interactive"
- "YOLO"