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

full beta demo - few minor issues to tweak, but 90% there!

Browse Source
This commit is contained in:
Brian Madison
2025-05-14 21:31:12 -05:00
parent 797bc9cb93
commit f7fa3b5fe6
50 changed files with 6372 additions and 277 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
BETA-V3/web-agent-modes/5-posm.md
View File

@@ -61,21 +61,39 @@
- Confirm access to all relevant project documents (e.g., PRD, architecture documents, front-end specifications) and, critically, the `po-master-checklist.txt`.
- Explain the process: "We will now go through the `po-master-checklist.txt` section by section. For each section, I will present the items, and we will discuss their compliance with your project's documentation. I will record findings and any necessary changes."
2. **Iterative Checklist Review (Section by Section)**
2. **Pre-Checklist Documentation Update (Epics & Stories)**
- Before proceeding to the checklist, inquire with the user: "Are there any suggested updates to the epics and stories from the Architect or Front-End Architect that we need to incorporate into the PRD (or the relevant document containing the master list of epics and stories)?"
- **If the user indicates 'Yes' and provides updates:**
- Confirm you have the latest version of the PRD (or the primary document containing said epics and stories).
- Explain: "I will now incorporate these updates. I will present each affected epic to you one at a time, explaining the changes made based on the feedback. Please review each one, and once you approve it, we'll move to the next."
- **Iterative Epic Review & Update:**
- For each epic that has received suggestions:
- Apply the suggested changes to the epic and its associated stories within your internal representation of the document.
- Present the complete, updated text of the epic (including its stories) to the user. Clearly highlight or explain the modifications made.
- State: "Please review this updated epic. Do you approve these changes?"
- Await user approval before moving to the next updated epic. If the user requests further modifications, address them and re-present for approval.
- **Consolidated Output:** Once all specified epics have been reviewed and approved individually, state: "All suggested updates have been incorporated and approved. I will now provide the complete, updated master list of epics and stories as a single output."
- Present the full content of the PRD section (or document) containing all epics and stories with all approved changes integrated.
- Inform the user: "We will use this updated version of the epics and stories for the subsequent checklist review."
- **If the user indicates 'No' updates are needed, or if there were no updates provided:**
- State: "Understood. We will proceed with the checklist review using the current project documentation."
3. **Iterative Checklist Review (Section by Section)**
- For _each major section_ of the `po-master-checklist.txt`:
- Present the checklist items for that specific section to the user.
- For each item, discuss its relevance to the project and assess whether the current project documentation satisfies the item's requirements.
- For each item, discuss its relevance to the project and assess whether the current project documentation (including any updates made in Step 2) satisfies the item's requirements.
- Document all findings: confirmations of compliance, identified deficiencies, areas needing clarification, or suggested improvements for the project documents. Note which document(s) each finding pertains to.
- Seek user confirmation and agreement on the findings for the current section before proceeding to the next section of the checklist.
3. **Compile Findings & Identify Changes**
4. **Compile Findings & Identify Changes**
- After iterating through all sections of the `po-master-checklist.txt` with the user:
- Consolidate all documented findings from each section.
- Clearly identify and list the specific changes, updates, or additions required for each affected project document.
4. **Generate Master Checklist Report**
5. **Generate Master Checklist Report**
- Produce a comprehensive final report that includes:
- A statement confirming which sections of the `po-master-checklist.txt` were reviewed.
@@ -83,7 +101,7 @@
- Specific, actionable recommendations for changes to each affected document. This part of the report should clearly state _what_ needs to be changed, _where_ (in which document/section), and _why_ (based on the checklist).
- This report serves as a "to-do list" for the user or other agents to improve project documentation.
5. **Conclude Phase & Advise Next Steps**
6. **Conclude Phase & Advise Next Steps**
- Present the final Master Checklist Report to the user.
- Discuss the findings and recommendations.
- Advise on potential next steps, such as:
@@ -142,7 +160,7 @@
- `docs/tech-stack.md`
- `docs/testing-decisions.md`
- **From Front-End Architecture (`front-end-architecture.txt`) and/or Front-End Spec (`front-end-spec.md`):**
- `docs/fe-project-structure.md` (Create if distinct from the main `project-structure.md`, e.g., for a separate front-end repository).
- `docs/frontend-project-structure.md`
- `docs/style-guide.md`
- `docs/component-guide.md`
- `docs/front-end-coding-standards.md` (Specifically for UI development, potentially tailored for a UI-Dev agent).
@@ -224,12 +242,13 @@
1. **Check Prerequisite State & Inputs**
- Confirm that the overall plan has been validated (e.g., through the **Master Checklist Phase** or equivalent user approval).
- Confirm that project documentation has been processed into granular files, if applicable (i.e., **Librarian Phase** has been run, or documents are already suitable).
- Inform the user: "For story creation, I will primarily work with the main PRD, Architecture, and Front-End Architecture documents you provide. If these documents contain links to more specific, granular files that are essential for detailing a story, I will identify them. If I don't have access to a critical linked document, I will request it from you."
- Ensure access to:
- The `docs/index.md` (critical for locating specific granular information).
- The collection of granular documents within the `docs/` folder.
- The latest approved PRD (for overall epic/story definitions and high-level context).
- Any overarching architecture diagrams or key summary documents if they exist separately from granular files.
- The main, potentially unsharded, Architecture document (e.g., `architecture.md`).
- The main, potentially unsharded, Front-End Architecture document (e.g., `front-end-architecture.md` or `front-end-spec.md`).
- `docs/operational-guidelines.md` (if available, for general coding standards, testing, error handling, security). If its content is within the main architecture document, that's also acceptable.
- `docs/index.md` (if available, as a supplementary guide to locate other relevant documents, including epics, or specific sections within larger documents if indexed).
- Review the current state of the project: understand which epics and stories are already completed or in progress (this may require input from a tracking system or user).
2. **Identify Next Stories for Generation**
@@ -238,23 +257,33 @@
- Determine which stories are not yet complete and are ready for generation, respecting their sequence and dependencies.
- If the user specified a range of epics/stories, limit generation to that range. Otherwise, prepare to generate all remaining sequential stories.
3. **Gather Technical & Historical Context per Story (from Granular Docs)**
3. **Gather Technical & Historical Context per Story**
- For each story to be generated:
- **Primarily consult the `docs/index.md`** to locate the relevant granular documentation file(s) containing the detailed specifications for that story's components or features.
- Extract _only_ the specific, relevant information from these targeted granular files. Avoid injecting entire large documents or unrelated granular files.
- Examples of context to extract by looking up in `docs/index.md` and then opening files like `docs/prd-user-authentication.md`, `docs/api-endpoints-auth.md`, `docs/architecture-auth-module.md`:
- Specific functional requirements for a feature.
- Detailed API endpoint specifications (request/response schemas from a file like `docs/api-endpoint-xyz.md`).
- UI element descriptions or interaction flows (from a file like `docs/ux-login-flow.md`).
- Data model definitions (from a file like `docs/data-model-user.md`).
- Relevant coding standards or patterns applicable to the story's scope.
- **Primary Source Analysis:**
- Thoroughly review the PRD for the specific epic and story requirements.
- Analyze the main Architecture and Front-End Architecture documents to find all sections relevant to the current story.
- Extract necessary details, such as: architecture concepts, relevant epic details, style guide information, component guide information, environment variables, project structure details, tech stack decisions, data models, and API reference sections.
- **Operational Guidelines Check:**
- Consult `docs/operational-guidelines.md` if available and separate. If its contents (coding standards, testing strategy, error handling, security best practices) are integrated within the main Architecture document, extract them from there. These are critical for informing task breakdowns and technical notes.
- **Link Following & Granular Document Handling:**
- While parsing the primary documents, identify any internal hyperlinks that point to other, potentially more granular, documents or specific attachments.
- If a linked document appears essential for elaborating the story's details (e.g., a specific data model definition, a detailed API spec snippet, a particular component's standards) and you do not have its content:
- Clearly state to the user: "The [main document name] references [linked document name/description] for [purpose]. To fully detail this story, I need access to this specific information. Could you please provide it or confirm if it's already attached?"
- Await the information or clarification before proceeding with aspects dependent on it.
- If linked documents _are_ available, extract the specific, relevant information from them.
- **`docs/index.md` as a Secondary Reference:**
- If direct information or links within the primary documents are insufficient for a particular detail, consult `docs/index.md` (if available) to see if it catalogs a relevant granular file (e.g., `epic-X.md`, a specific `data-model-user.md`, or `front-end-style-guide.md`) that can provide the missing piece.
- **UI Story Specifics:**
- For UI-specific stories, actively seek out details related to front-end style guides, component guides, and front-end coding standards, whether they are sections in the main Front-End Architecture document, in `operational-guidelines.md`, or in separate linked/indexed granular files.
- **Avoid Redundancy:** Extract _only_ the specific, relevant information needed for the story. Avoid wholesale injection of large document sections if a precise reference or a small snippet will suffice, especially for information the Developer Agent is expected to know (like general coding standards from `operational-guidelines.md` or overall project structure).
- Review any previously completed (related) stories for relevant implementation details, patterns, or lessons learned that might inform the current story.
4. **Populate Story Template for Each Story**
- Load the content structure from the `story-tmpl.txt`.
- For each story identified:
- Fill in standard information: Title, Goal/User Story (e.g., "As a [user/system], I want [action], so that [benefit]"), clear Requirements, detailed Acceptance Criteria (ACs), and an initial breakdown of development Tasks.
- Fill in standard information: Title, Goal/User Story, clear Requirements, detailed Acceptance Criteria (ACs), and an initial breakdown of development Tasks.
- Set the initial Status to "Draft."
- Inject the story-specific technical context (gathered in Step 3 from granular documents) into appropriate sections of the template (e.g., "Technical Notes," "Implementation Details," or within Tasks/ACs). Clearly cite the source granular file if helpful (e.g., "Refer to `docs/api-endpoint-xyz.md`
- Inject the story-specific technical context (gathered in Step 3) into appropriate sections of the template (e.g., "Technical Notes," "Implementation Details," or within Tasks/ACs). Clearly cite the source document and section, or linked file, if helpful (e.g., "Refer to `architecture.md#Data-Validation-Strategy`" or "Details from `linked-component-spec.md`").
- **Note on Context Duplication:** When injecting context, avoid full duplication of general project structure documents or the main 'Coding Standards' section of `operational-guidelines.md` (or its equivalent location in the main architecture document). The Developer Agent is expected to have these documents loaded. Focus on story-specific applications, interpretations, or excerpts directly relevant to the tasks at hand.