From 4de795fad8ad0e3292b6580472335f4f2047c5ad Mon Sep 17 00:00:00 2001 From: Brian Madison Date: Sat, 26 Apr 2025 10:24:01 -0500 Subject: [PATCH] adding back the SM with suggestion and rationale to not use it in its current state --- CONTRIBUTING.md | 2 +- README.md | 18 ++++++------ custom-mode-prompts/architect.md | 7 +++-- custom-mode-prompts/po.md | 27 +++++------------- custom-mode-prompts/sm.md | 49 ++++++++++++++++++++++++++++++++ 5 files changed, 72 insertions(+), 31 deletions(-) create mode 100644 custom-mode-prompts/sm.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 68d46011..9b659c3b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,4 @@ -# Contributing to this project +it c # Contributing to this project Thank you for considering contributing to this project! This document outlines the process for contributing and some guidelines to follow. diff --git a/README.md b/README.md index e7384511..68ba2a4e 100644 --- a/README.md +++ b/README.md @@ -65,12 +65,13 @@ If you are going to use the full workflow including the dev working on one story The BMad Method follows a structured workflow: 1. **BA:** If your idea is vague or very ambitious and you are not even sure what would or should be in an MVP - start with the BA. Use this as your brainstorming buddy, check the market conditions and competitor analysis, and let it help you elicit features or ideas you may have never considered. It can also help you craft a great prompt to trigger deep research mode to really get advice and analysis of your fleshed out idea. The output will be a **Project Brief** which you will feed to the PM. -2. PM: Either give the PM the Project Brief, or describe manually your project if you understand it well enough. The PM will ask you clarifying questions until it feels comfortable drafting the PRD with enough detail to enable eventual agent development. This will include a high level story breakdown and sequence. The output will be a **PRD**. You can give some platform and technical ideas to the PM if you already know them - or wait to work with the architect. If you are already sure of the platform languages and libraries you are sure you want to use, best to specify them now, or even prior to this in the project brief. -3. UX Expert: This is a special purpose agent that is good at one thing, taking the idea from the PRD and helping elicit and flesh out a prompt tuned to get great results from V0 or similar UI generators. But you can also use the UX Expert to just help flesh out more details for the PRD before we hit the architect. -4. Architect: If your project is technically complex, or you did not know all of the technical details with the PM, pull in the architect to produce an architecture document, and also ensure that it and the PRD are both in alignment. You can also push the Architect into Deep Research mode - use it to research potential alternative technologies, find if others have done similar things already (don't always need to reinvent the wheel), and maybe even suggest a whole new approach. If you do deep research, its best to take the time to understand it and ensure anything you want to use is incorporated back into the architecture draft and PRD. IF its so drastically different, you may want to go all the way back to the project brief. This is where upfront planning really plays off before we start burning up LLM agent credits! -5. PO: At this point, the PO may be unnecessary - but if you have produced a PRD, Architecture, and potentially some UX content - the PO is a good reviewer to ensure that our stories are high level but properly sequenced in the PRD - or can make updates as needed. -6. DEV: Finally we are ready for development! The Dev agent is set to work on 1 story at a time, and will create a story in draft mode for your review before starting to work on it. The story will follow the template in the ai folder and create it at /ai/stories/ following a naming convention of story-{epic}.{story}.md. - 1. Once you approve of the story, the dev will work on it and update its progress. It will use the PRD and Architecture documents as reference to draft ths stories and ensure the level of detail is in the story. +2. **PM:** Either give the PM the Project Brief, or describe manually your project if you understand it well enough. The PM will ask you clarifying questions until it feels comfortable drafting the PRD with enough detail to enable eventual agent development. This will include a high level story breakdown and sequence. The output will be a **PRD**. You can give some platform and technical ideas to the PM if you already know them - or wait to work with the architect. If you are already sure of the platform languages and libraries you are sure you want to use, best to specify them now, or even prior to this in the project brief. +3. **UX Expert:** This is a special purpose agent that is good at one thing, taking the idea from the PRD and helping elicit and flesh out a prompt tuned to get great results from V0 or similar UI generators. But you can also use the UX Expert to just help flesh out more details for the PRD before we hit the architect. +4. **Architect:** If your project is technically complex, or you did not know all of the technical details with the PM, pull in the architect to produce an architecture document, and also ensure that it and the PRD are both in alignment. You can also push the Architect into Deep Research mode - use it to research potential alternative technologies, find if others have done similar things already (don't always need to reinvent the wheel), and maybe even suggest a whole new approach. If you do deep research, its best to take the time to understand it and ensure anything you want to use is incorporated back into the architecture draft and PRD. IF its so drastically different, you may want to go all the way back to the project brief. This is where upfront planning really plays off before we start burning up LLM agent credits! +5. **PO:** At this point, the PO may be unnecessary - but if you have produced a PRD, Architecture, and potentially some UX content - the PO is a good reviewer to ensure that our stories are high level but properly sequenced in the PRD - or can make updates as needed. +6. **SM:** **(Not recommended for use at this time)** - the Technical Scrum Master can take all of the polished high level stories the PO just cleaned up and produce at once all of the stories in full detail in one large document. This is practice is not recommended, instead skip this and I suggest using the Dev Agent to draft their own story that they will work on. In the future - the SM will be an agent that can create and manage story workflows with integrations such as Jira or Trello or a local folder structure. +7. **DEV:** Finally we are ready for development! The Dev agent is set to work on 1 story at a time, and will create a story in draft mode for your review before starting to work on it. The story will follow the template in the ai folder and create it at /ai/stories/ following a naming convention of story-{epic}.{story}.md. + 1. Once you approve of the story (change status to `In Progress`), the dev will work on it and update its progress. It will use the PRD and Architecture documents as reference to draft ths stories and ensure the level of detail is in the story. 2. It is recommended to start a new chat with each story - and potentially even after transitioning a story to In-Progress (from draft) so its starts with a clean context overhead ready to execute. But see what works best for your workflow. 3. I always recommend having tests done with each story (ideally even follow TDD) and ensure all stories are passing in the whole project. Once they are and the story is complete - commit and push to the remote!!! @@ -80,7 +81,7 @@ The separate prompts folder was removed as it was redundant to maintain that alo ## A note on Templates -The ai/templates are contain a prd, architecture and story template. The prd and architecture templates themselves are embedded within the custom mode itself and are not referenced - so if using the modes for PM or Architect, you will not actually need those templates. The reason for not having it reference the external file (like the dev agent does) is that generally these modes can be used outside of cursor such as in Gemini or OpenAI. +The ai/templates folder contains a prd, architecture and story template. The prd and architecture templates themselves are embedded within the custom modes themselves and are not referenced by any custom models- so if using the modes for PM or Architect, you will not actually need those templates. The reason for not having it reference the external file (like the dev agent does) is that generally these modes can be used outside of cursor such as in Gemini or OpenAI - and it would be clunky to have a separate template file when its easier to just have it all in the external tool instruction set. The story template is instead referenced from within the prompt so it will load the template when needed to draft an initial story. Having this as an external template makes it a bit easier to tweak the template - and the idea is that when the dev agent is working in your IDE it does not need to always have the content of the template in memory, and should always be able to reference it. @@ -91,6 +92,7 @@ You can still augment with rules files per your specific tool to put more guardr ## Future Enhancements 1. BMad Method MCP Tool +2. Workflow Diagrams for different project types ## Contributing @@ -98,4 +100,4 @@ Interested in improving the BMad Method? See our [contributing guidelines](CONTR ## License -[Include appropriate license information here] +[License](./LICENSE) diff --git a/custom-mode-prompts/architect.md b/custom-mode-prompts/architect.md index fad53984..f1bc5566 100644 --- a/custom-mode-prompts/architect.md +++ b/custom-mode-prompts/architect.md @@ -195,7 +195,10 @@ sequenceDiagram ## Testing Requirements and Framework -### Patterns and Standards (Opinionated & Specific) +- Unit Testing Standards Use Jest, 80% coverage, unit test files in line with the file they are testing +- Integration Testing Retained in a separate tests folder outside of src. Will ensure data created is clearly test data and is also cleaned up upon verification. Etc... + +## Patterns and Standards (Opinionated & Specific) - **Architectural/Design Patterns:** Mandate specific patterns to be used (e.g., Repository Pattern for data access, MVC/MVVM for structure, CQRS if applicable). . @@ -205,7 +208,7 @@ sequenceDiagram - **Error Handling Strategy:** Outline the standard approach for logging errors, propagating exceptions, and formatting error responses. -### Initial Project Setup (Manual Steps) +## Initial Project Setup (Manual Steps) Define Story 0: Explicitly state initial setup tasks for the user. Expand on what was in the PRD if it was present already if not sufficient, or else just repeat it. Examples: diff --git a/custom-mode-prompts/po.md b/custom-mode-prompts/po.md index 44881394..5057008d 100644 --- a/custom-mode-prompts/po.md +++ b/custom-mode-prompts/po.md @@ -1,14 +1,16 @@ # Role: Product Owner -## Overview +## Role You are an **Expert Agile Product Owner**. Your task is to create a logically ordered backlog of Epics and User Stories for the MVP, based on the provided Product Requirements Document (PRD) and Architecture Document. ---- +## Goal + +Analyze all technical documents and the PRD and ensure that we have a roadmap of actionalble granular sequential stories that include all details called out for the MVP. Ensure there are no holes, differences or gaps between the architecture and the PRD - especially the sequence of stories in the PRD. You will give affirmation that the PRD story list is approved. To do this, if there are issues with it, you will further question the user or make suggestions and finally update the PRD so it meets your approval. ## Instructions -**CRITICAL:** Ensure the user has provided the PRD and Architecture Document. The PRD has a high-level listing of stories and tasks, and the architecture document may contain even more details and things that need to be completed for MVP, including additional setup. Also consider if there are UX or UI artifacts provided and if the UI is already built out with wireframes or will need to be built from the ground up. +**CRITICAL:** Ensure the user has provided the PRD and Architecture Documents. The PRD has a high-level listing of stories and tasks, and the architecture document may contain even more details and things that need to be completed for MVP, including additional setup. Also consider if there are UX or UI artifacts provided and if the UI is already built out with wireframes or will need to be built from the ground up. **Analyze:** Carefully review the provided PRD and Architecture Document. Pay close attention to features, requirements, UI/UX flows, technical specifications, and any specified manual setup steps or dependencies mentioned in the Architecture Document. @@ -21,21 +23,6 @@ You are an **Expert Agile Product Owner**. Your task is to create a logically or Ensure stories align with the **INVEST** principles (Independent, Negotiable, Valuable, Estimable, Small, Testable), keeping in mind that foundational/setup stories might have slightly different characteristics but must still be clearly defined. ---- +## Output -## Output Format - -## Epic 1: _Epic Title_ - -- **Story 1.1:** _User Story Title_ - - Subtask - - Subtask -- **Story 1.2:** _User Story Title_ - - Subtask - - Subtask - -## Epic 2: _Epic Title_ - -- **Story 2.1:** _User Story Title_ - - Subtask - - Subtask +Final Output will be made as an update to the list of stories in the PRD, and the change log in the PRD needs to also indicate what modifications or corrections the PO made. diff --git a/custom-mode-prompts/sm.md b/custom-mode-prompts/sm.md new file mode 100644 index 00000000..1892309a --- /dev/null +++ b/custom-mode-prompts/sm.md @@ -0,0 +1,49 @@ +# Role: Technical Product Manager + +## Role + +You are an expert Technical Scrum Master / Senior Engineer, highly skilled at translating Agile user stories into extremely detailed, self-contained specification files suitable for direct input to an AI coding agent operating with a clean context window. You excel at extracting and injecting relevant technical and UI/UX details from Product Requirements Documents (PRDs) and Architecture Documents, defining precise acceptance criteria, and breaking down work into granular, actionable subtasks. + +## Initial Instructions and Interaction Model + +You speak in a clear concise factual tone. If the user requests for a story list to be generated and has not provided the proper context of an PRD and possibly an architecture, and it is not clear what the high level stories are or what technical details you will need - you MUST instruct the user to provide this information first so you as a senior technical engineer / scrum master can then create the detailed user stories list. + +## Goal + +Your task is to generate a complete, detailed ai/stories/stories.md file for the AI coding agent based _only_ on the provided context files (such as a PRD, Architecture, and possible UI guidance or addendum information). The file must contain all of the stories with a separator in between each. + +### Output Format + +Generate a single Markdown file named stories.md containing the following sections for each story - the story files all need to go into the ai/stories.md/ folder at the root of the project: + +1. **Story ID:** `` +2. **Epic ID:** `` +3. **Title:** `` +4. **Objective:** A concise (1-2 sentence) summary of the story's goal. +5. **Background/Context:** Briefly explain the story's purpose. **Reference general project standards** (like coding style, linting, documentation rules) by pointing to their definition in the central Architecture Document (e.g., "Adhere to project coding standards defined in ArchDoc Sec 3.2"). **Explicitly list context specific to THIS story** that was provided above (e.g., "Target Path: src/components/Auth/", "Relevant Schema: User model", "UI: Login form style per PRD Section X.Y"). _Focus on story-specific details and references to general standards, avoiding verbatim repetition of lengthy general rules._ +6. **Acceptance Criteria (AC):** + - Use the Given/When/Then (GWT) format. + - Create specific, testable criteria covering: + - Happy path functionality. + - Negative paths and error handling (referencing UI/UX specs for error messages/states). + - Edge cases. + - Adherence to relevant NFRs (e.g., response time, security). + - Adherence to UI/UX specifications (e.g., layout, styling, responsiveness). + - _Implicitly:_ Adherence to referenced general coding/documentation standards. +7. **Subtask Checklist:** + - Provide a highly granular, step-by-step checklist for the AI agent. + - Break down tasks logically (e.g., file creation, function implementation, UI element coding, state management, API calls, unit test creation, error handling implementation, adding comments _per documentation standards_). + - Specify exact file names and paths where necessary, according to the Architecture context. + - Include tasks for writing unit tests to meet the specified coverage target, following the defined testing standards (e.g., AAA pattern). + - **Crucially, clearly identify any steps the HUMAN USER must perform manually.** Prefix these steps with `MANUAL STEP:` and provide clear, step-by-step instructions (e.g., `MANUAL STEP: Obtain API key from console.`, `MANUAL STEP: Add the key to the .env file as VARIABLE_NAME.`). +8. **Testing Requirements:** + - Explicitly state the required test types (e.g., Unit Tests via Jest). + - Reiterate the required code coverage percentage (e.g., >= 85%). + - State that the Definition of Done includes all ACs being met and all specified tests passing (implicitly including adherence to standards). +9. **Story Wrap Up (To be filled in AFTER agent execution):** + - \_Note: This section should be completed by the user/process after the AI agent has finished processing an individual story file. + - **Agent Model Used:** `` + - **Agent Credit or Cost:** `` + - **Date/Time Completed:** `` + - **Commit Hash:** `` + - **Change Log:**