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

fix web orchestrator build and sample update

Browse Source
This commit is contained in:
Brian Madison
2025-05-21 20:09:09 -05:00
parent 7e84908280
commit dcc2858873
3 changed files with 161 additions and 168 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
build-bmad-web-orchestrator.js
View File

@@ -60,7 +60,7 @@ async function main() {
}
// 2. Determine and validate asset folder root and build directory
const workspaceRoot = path.resolve(__dirname, "../../");
const workspaceRoot = path.resolve(__dirname, ".");
const assetFolderRootInput = config.asset_root;
let assetFolderRoot;
@@ -310,7 +310,7 @@ Processing '${subdirName}' directory into '${targetFile}'`);
Script finished. Output files are in ${buildDir}`);
console.log(
`To run this script: node ${path.relative(
path.resolve(__dirname, "../.."),
path.resolve(__dirname, "."),
__filename
)}`
);

323
web-build-sample/tasks.txt
View File

@@ -387,29 +387,9 @@ To generate a masterful, comprehensive, and optimized prompt that can be used wi
- The convention for unit test file location (e.g., co-located with source files, or in a separate folder like `tests/` or `__tests__/`).
- The naming convention for unit test files (e.g., `*.test.js`, `*.spec.ts`, `test_*.py`).
- When discussing Coding Standards, inform the user that these will serve as firm rules for the AI developer agent. Emphasize that these standards should be kept to the minimum necessary to prevent undesirable or messy code from the agent. Guide the user to understand that overly prescriptive or obvious standards (e.g., "use SOLID principles," which well-trained LLMs should already know) should be avoided, as the user, knowing the specific agents and tools they will employ, can best judge the appropriate level of detail.
- **Incorporate Feedback:** Discuss the draft with the user, incorporate their feedback, and iterate as needed.
- Offer Advanced Reflective & Elicitation Options:
<critical_rule>Once a draft of a significant architecture document section (e.g., 'Component View', 'Data Management Strategy', 'Security Architecture') has been created and you (the AI Agent executing this task) have incorporated the user's initial round of feedback and revisions for that specific draft, you will then 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 draft before moving on. The user can select an action by number, or choose to skip this and proceed.</critical_rule>
"We've refined the draft for the current architecture section: [Specific Architecture Section/Component]. To ensure its robustness, explore alternatives, and consider all angles, I can perform one of the following actions. Please choose a number, or let me know if you're ready to move on:
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
{Instruction for AI Agent: Just 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 outlined for an Architect's context.}
1. **Critical Self-Review & Requirements Alignment**
2. **Generate & Evaluate Alternative Architectural Approaches**
3. **Resilience, Scalability & Performance Stress Test (Conceptual)**
4. **Deep Dive into Technical Assumptions, Constraints & Dependencies**
5. **Security & Risk Assessment Review & Probing Questions**
6. **Collaborative Design Brainstorming & Pattern Exploration**
7. **Elicit 'Unforeseen Implications' & Future-Proofing Questions**
8. **Proceed to the Next [Architectural Section/Task].**
After I perform the selected action, we can discuss the outcome and decide on any further revisions.
When you're satisfied with the current draft of this section, we can move directly to [the next logical step, e.g., 'the next architectural component,' or if all sections are drafted, 'Step 5: Identify Missing Technical Stories / Refine Epics' or 'Step 6: Validate Architecture Against Checklist & Finalize Output']."
- **Seek Approval:** Obtain explicit user approval for the section before moving to the next, or for the entire artifact if drafted holistically (in YOLO mode).
- **Incorporate Feedback:** Discuss the draft with the user, incorporate their feedback, and iterate as needed.
- [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)
- **Seek Approval:** Obtain explicit user approval for the section before moving to the next, or for the entire artifact if drafted holistically (in YOLO mode).
5. **Identify Missing Technical Stories / Refine Epics (Interactive):**
@@ -452,6 +432,31 @@ To generate a masterful, comprehensive, and optimized prompt that can be used wi
- A completed `architect-checklist` (or a summary of its validation).
- Optionally, if UI components are involved and the user agrees: A prompt for a "Design Architect" appended to the main architecture document, summarizing relevant UI considerations and outlining the Design Architect's next steps.
## 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)
==================== END: create-architecture ====================
@@ -604,25 +609,7 @@ To define the technical architecture for the frontend application. This includes
- **a. Explain Purpose & Draft Section:** Explain the purpose of the section and present a draft for that section.
- **b. Initial Discussion & Feedback:** Discuss the draft with the user, incorporate their feedback, and iterate as needed for initial revisions.
- **c. Offer Advanced Reflective & Elicitation Options:**
<critical_rule>After incorporating the user's initial round of feedback on the drafted frontend architecture section, you will then 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 draft 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.</critical_rule>
"We've incorporated your initial feedback into the draft for the current frontend architecture section: **[Specific Frontend Architecture Section Name]**. To ensure its robustness, explore alternatives, and consider all angles, I can perform one of the following actions. Please choose a number, or let me know if you're ready to finalize this section:
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
{Instruction for AI Agent: Just 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 a Frontend Architecture context.}
1. **Critical Self-Review & Requirements Alignment**
2. **Generate & Evaluate Alternative Architectural Approaches**
3. **Resilience, Scalability & Performance Stress Test (Conceptual)**
4. **Deep Dive into Technical Assumptions, Constraints & Dependencies**
5. **Maintainability & Testability Audit Review & Probing Questions**
6. **Collaborative Design Brainstorming & Pattern/Tech Exploration**
7. **Elicit 'Unforeseen Implications' & Future-Proofing 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."
- **c. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
- **d. Final Approval & Documentation:** Obtain explicit user approval for the section. Ensure all placeholder links and references are correctly noted within each section. Then proceed to the next section.
@@ -656,6 +643,31 @@ To define the technical architecture for the frontend application. This includes
- A brief note on any significant discussions or changes made as a result of the checklist review.
- The goal is to ensure the `front-end-architecture` is a complete and actionable document.
## 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)
==================== END: create-frontend-architecture ====================
@@ -782,7 +794,7 @@ Remember as you follow the upcoming instructions:
## Instructions
### Define Project Workflow Context
### 1. Define Project Workflow Context
- Before PRD generation, ask the user to choose their intended workflow:
@@ -792,44 +804,50 @@ Remember as you follow the upcoming instructions:
- Explain this choice sets a default detail level, which can be fine-tuned later per story/epic.
### 2\. Determine Interaction Mode (for PRD Structure & Detail)
### 2. Determine Interaction Mode (for PRD Structure & Detail)
- 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\. Review inputs provided
### 3. Review inputs provided
Review the inputs provided so far, such as a project brief, any research, and user input and ideas.
### 4\. Process PRD Sections
### 4. Process PRD Sections
\<important_note\>The interaction mode chosen in step 2 above (Incremental or YOLO) will determine how the following PRD sectioning and epic/story generation steps are handled.\</important_note\>
Inform the user we will work through the PRD sections in order 1 at a time (if not YOLO) - the template contains your instructions for each section.
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)
\<important_note\>When working on the "Technical Assumptions" section of the PRD, explicitly guide the user through discussing and deciding on the repository structure (Monorepo vs. Polyrepo) and the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo). Emphasize that this is a critical decision point that will be formally documented here with its rationale, impacting MVP scope and informing the Architect. Ensure this decision is captured in the PRD's `Technical Assumptions` and then reiterated in the `Initial Architect Prompt` section of the PRD.\</important_note\>
<important_note>When working on the "Technical Assumptions" section of the PRD, explicitly guide the user through discussing and deciding on the repository structure (Monorepo vs. Polyrepo) and the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo). Emphasize that this is a critical decision point that will be formally documented here with its rationale, impacting MVP scope and informing the Architect. Ensure this decision is captured in the PRD's `Technical Assumptions` and then reiterated in the `Initial Architect Prompt` section of the PRD.</important_note>
\<important_note\>Specifically for "Simplified PM-to-Development Workflow":
<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.
When doing so, first check if a `technical-preferences` file exists. 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:
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:
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.\</important_note\>
This section should be collaboratively filled and updated as needed if subsequent epic/story discussions reveal new requirements or constraints.
\<important_note\>Note: For the Epic and Story Section (if in Incremental mode for these), prepare in memory what you think the initial epic and story list so we can work through this incrementally, use all of the information you have learned that has been provided thus far to follow the guidelines in the section below [Guiding Principles for Epic and User Story Generation](https://www.google.com/search?q=%23guiding-principles-for-epic-and-user-story-generation).\</important_note\>
</important_note\>
<important_note>
For the Epic and Story Section (if in Incremental mode for these), prepare in memory what you think the initial epic and story list so we can work through this incrementally, use all of the information you have learned that has been provided thus far to follow the guidelines in the section below [Guiding Principles for Epic and User Story Generation](https://www.google.com/search?q=%23guiding-principles-for-epic-and-user-story-generation).
</important_note>
#### 4A. Epic Presentation and Drafting Strategy
(If Incremental Mode for Epics) You will first present the user with the epic titles and descriptions, so that the user can determine if it is correct and what is expected, or if there is a major epic missing.
(If YOLO Mode) You will draft all epics and stories as part of the larger PRD draft.
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.
#### 4B. Story Generation and Review within Epics (Incremental Mode)
\<critical_rule\>(If Incremental Mode for Stories, following Epic approval) Once the Epic List is approved, THEN for each Epic, you will proceed as follows:\</critical_rule\>
**Once the Epic List is approved, THEN for each Epic, you will proceed as follows:**
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.
@@ -840,29 +858,8 @@ 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. \<critical_rule\>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.\</critical_rule\>
##### 4B1. Offer Advanced Self-Refinement & Elicitation Options
Before concluding work on the current Epic/Story set or PRD section and moving to the next, you (the AI Agent executing this task) will present the user with the following list of advanced actions. The user can select one by number to trigger it.
{Instruction for AI Agent: Just display the title of each numbered item below. Explain the selected action to the user if they ask what it is, based on the detailed descriptions previously defined for these actions.}
"We've refined the draft for [specific Epic/Story/Section]. To ensure its quality, explore it further, or expand on our ideas, I can perform one of the following actions. Please choose a number, or let me know if you're ready to move on:
**Advanced Refinement, Elicitation & Brainstorming Actions I Can Take:**
1. **Critical Self-Review & Goal Alignment with the Guiding Principles for Epic and User Story Generation**
2. **Generate & Evaluate Alternatives**
3. **Conceptual Scenario & Edge Case Simulation**
4. **Deep Dive into Assumptions & Dependencies**
5. **'Devil's Advocate' Review & Probing Questions**
6. **Guided Brainstorming & Idea Expansion**
7. **Elicit 'Unasked Questions' & Hidden Requirements**
8. **Proceed to the Next [Logical Group, eg Epic]**
After I perform the selected action, we can discuss the outcome and decide on any further revisions or if we should proceed.
When you're satisfied with the current draft as is, we can move directly to [the next logical step, e.g., 'the next Epic,' 'the Checklist Assessment,' etc.]."
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)
#### 4C. Present Complete Draft
@@ -890,7 +887,7 @@ Produce the PRD with PM Prompt per the `prd-tmpl` utilizing the following guidan
- 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\>
<important_note>
**Next Steps for UI/UX Specification (If Applicable):**
- If the product described in this PRD includes a user interface:
@@ -925,7 +922,7 @@ Produce the PRD with PM Prompt per the `prd-tmpl` utilizing the following guidan
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\>
</important_note>
## Guiding Principles for Epic and User Story Generation
@@ -985,6 +982,31 @@ Your aim is to ensure User Stories remain focused on delivering measurable user
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)
==================== END: create-prd ====================
@@ -993,12 +1015,12 @@ Confirm "Ready" State: Before considering an Epic's stories complete, ensure eac
## Purpose
To collaboratively work with the user to define and document the User Interface (UI) and User Experience (UX) specifications for the project. This involves understanding user needs, defining information architecture, outlining user flows, and ensuring a solid foundation for visual design and frontend development. The output will populate the `front-end-spec-tmpl` template.
To collaboratively work with the user to define and document the User Interface (UI) and User Experience (UX) specifications for the project. This involves understanding user needs, defining information architecture, outlining user flows, and ensuring a solid foundation for visual design and frontend development. The output will populate a new document called `front-end-spec.md` following the `front-end-spec-tmpl` template.
## Inputs
- Project Brief (`project-brief-tmpl` or equivalent)
- Product Requirements Document (PRD) (`prd-tmpl` or equivalent)
- Project Brief (`project-brief.md` or equivalent)
- Product Requirements Document (PRD) (`prd.md` or equivalent)
- User feedback or research (if available)
## Key Activities & Instructions
@@ -1057,29 +1079,33 @@ To collaboratively work with the user to define and document the User Interface
### 10. Output Generation & Iterative Refinement (Guided by `front-end-spec-tmpl`)
- **a. Draft Section:** Incrementally populate one logical section of the `front-end-spec-tmpl` file based on your discussions.
- **b. Present & Incorporate Initial Feedback:** Present the drafted section to the user for review. Discuss and incorporate their initial feedback and revisions directly.
- **c. Offer Advanced Reflective & Elicitation Options:**
<critical_rule>Once the initial draft of a UI/UX specification section (e.g., 'Information Architecture', 'Key User Flows', 'Accessibility Requirements') has been created and you have incorporated the user's initial round of feedback, you will then 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 draft 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.</critical_rule>
- **b. Present & Incorporate Initial Feedback:** Present the drafted section to the user for review. Discuss, explain and incorporate their initial feedback and revisions directly.
- **c. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
"We've refined the draft for the current UI/UX section: **[Specific UI/UX Section Name]**. To ensure its robustness, explore alternatives, and consider all angles, I can perform one of the following actions. Please choose a number, or let me know if you're ready to finalize this section:
## Offer Advanced Self-Refinement & Elicitation Options
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
(This section is called when needed prior to this)
{Instruction for AI Agent: Just 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 a UI/UX context.}
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.
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.**
"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):
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
- **d. Finalize Section:** Once the user is satisfied (either after reflective actions or if they skipped them), confirm that this section of the `front-end-spec-tmpl` is considered complete for now.
- **e. Repeat for all sections:** Ensure all placeholder links and references are correctly noted as you complete each section.
{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)
==================== END: create-uxui-spec ====================
@@ -1087,88 +1113,55 @@ To collaboratively work with the user to define and document the User Interface
==================== START: doc-sharding-task ====================
# Doc Sharding Task
You are now operating as a Technical Documentation Librarian tasked with granulating large project documents into smaller, organized files. Your goal is to transform monolithic documentation into a well-structured, easily navigable documentation system.
You are a Technical Documentation Librarian tasked with granulating large project documents into smaller, organized files. Your goal is to transform monolithic documentation into a well-structured, navigable documentation system.
## Your Task
Transform large project documents into smaller, granular files within the `docs/` directory by following the `doc-sharding-tmpl.txt` plan. You will create and maintain `docs/index.md` as a central catalog, facilitating easier reference and context injection for other agents and stakeholders. You will only process the documents and specific sections within them as requested by the user and detailed in the sharding plan.
Transform large project documents into smaller, granular files within the `docs/` directory following the `doc-sharding-tmpl.txt` plan. Create and maintain `docs/index.md` as a central catalog for easier reference and context injection.
## Your Approach
## Execution Process
1. First, ask the user to specify which of the available source documents (PRD, Main Architecture, Front-End Architecture) they wish to process in this session.
2. Next, confirm:
1. If not provided, ask the user which source documents they wish to process (PRD, Main Architecture, Front-End Architecture)
2. Validate prerequisites:
- Access to `doc-sharding-tmpl.txt`.
- Location of the source documents the user wants to process.
- Write access to the `docs/` directory.
- If any prerequisites are missing for the selected documents, request them before proceeding.
- Provided `doc-sharding-tmpl.txt` or access to `bmad-agent/doc-sharding-tmpl.txt`
- Location of source documents to process
- Write access to the `docs/` directory
- Output method (file system or chat interface)
3. For each _selected_ document granulation:
3. For each selected document:
- Follow the structure defined in `doc-sharding-tmpl.txt`, processing only the sections relevant to the specific document type.
- Extract content verbatim - no summarization or reinterpretation
- Create self-contained markdown files
- Add Standard Description: At the beginning of each created file, immediately after the main H1 heading (which is typically derived from the source section title), add a blockquote with the following format:
```markdown
> This document is a granulated shard from the main "[Original Source Document Title/Filename]" focusing on "[Primary Topic of the Shard]".
```
- _[Original Source Document Title/Filename]_ should be the name or path of the source document being processed (e.g., "Main Architecture Document" or `3-architecture.md`).
- _[Primary Topic of the Shard]_ should be a concise description of the shard's content, ideally derived from the first item in the "Source Section(s) to Copy" field in the `doc-sharding-tmpl.txt` for that shard, or a descriptive name based on the target filename (e.g., "API Reference", "Epic 1 User Stories", "Frontend State Management").
- Maintain information integrity
- Use clear, consistent file naming as specified in the plan
- Follow the structure in `doc-sharding-tmpl.txt`, processing only relevant sections
- Extract content verbatim without summarization or reinterpretation
- Create self-contained markdown files for each section or output to chat
- Use consistent file naming as specified in the plan
4. For `docs/index.md`:
4. For `docs/index.md` when working with the file system:
- Create if absent
- Add descriptive titles and relative markdown links for each granular file
- Organize content logically
- Include brief descriptions where helpful
- Ensure comprehensive cataloging
- Create if absent
- Add descriptive titles with relative markdown links
- Organize content logically with brief descriptions
- Ensure comprehensive cataloging
5. Optional enhancements:
- Add cross-references between related granular documents
- Implement any additional organization specified in the sharding template
5. Maintain creation log and provide final report
## Rules of Operation
## Rules
1. NEVER modify source content during extraction
1. Never modify source content during extraction
2. Create files exactly as specified in the sharding plan
3. Prepend Standard Description: Ensure every generated shard file includes the standard description blockquote immediately after its H1 heading as specified in the "Approach" section.
4. If consolidating content from multiple sources, preview and seek approval
5. Maintain all original context and meaning
6. Keep file names and paths consistent with the plan
7. Update `index.md` for every new file created
3. Seek approval when consolidating content from multiple sources
4. Maintain original context and meaning
5. Keep file names consistent with the plan
6. Update `index.md` for every new file
## Required Input
Please provide:
1. **Source Document Paths** - Path to document(s) to process (PRD, Architecture, or Front-End Architecture)
2. **Documents to Process** - Which documents to shard in this session
3. **Sharding Plan** - Confirm `docs/templates/doc-sharding-tmpl.txt` exists or `doc-sharding-tmpl.txt` has been provided
4. **Output Location** - Confirm Target directory (default: `docs/`) and index.md or in memory chat output
1. **Source Document Paths:**
- Path to the Product Requirements Document (PRD) (e.g., `project/docs/PRD.md` or `../8-prd-po-updated.md`), if you want to process it.
- Path to the main Architecture Document (e.g., `project/docs/architecture.md` or `../3-architecture.md`), if you want to process it.
- Path to the Front-End Architecture Document (e.g., `project/docs/frontend-architecture.md` or `../5-front-end-architecture.txt`), if you want to process it.
2. **Documents to Process:**
- Clearly state which of the provided documents you want me to shard in this session (e.g., "Process only the PRD," or "Process the Main Architecture and Front-End Architecture documents," or "Process all provided documents").
3. **Sharding Plan Confirmation:**
- Confirmation that `docs/templates/doc-sharding-tmpl.txt` exists, is populated, and reflects your desired sharding strategy.
4. **Output Directory & Index Confirmation:**
- The target directory for the sharded markdown files. (Default: `docs/` relative to the workspace or project root).
- Confirmation that an `index.md` file should be created or updated in this target directory to catalog the sharded files.
5. **Write Access:**
- Confirmation of write access to the specified output directory.
## Process Steps
1. I will first ask you to specify which source documents you want me to process.
2. Then, I will validate access to `docs/templates/doc-sharding-tmpl.txt` and the source documents you've selected.
3. I will confirm the output directory for sharded files and the plan to create/update `index.md` there.
4. For each _selected_ source document:
- I will identify sections as per the sharding plan, relevant to that document type.
- Show you the proposed granulation structure for that document.
5. I will maintain a log of all created files
6. I will provide a final report of all changes made
Would you like to proceed with document granulation? Please provide the required input above.
Would you like to proceed with document sharding? Please provide the required input.
==================== END: doc-sharding-task ====================

2
web-build-sample/templates.txt
View File

@@ -386,7 +386,7 @@ This plan directs the agent on how to break down large source documents into sma
## 1. Source Document: PRD (Project Requirements Document)
- **Note to Agent:** Confirm the exact filename of the PRD with the user (e.g., `PRD.md`, `ProjectRequirements.md`, `8-prd-po-updated.md`).
- **Note to Agent:** Confirm the exact filename of the PRD with the user (e.g., `PRD.md`, `ProjectRequirements.md`, `prdx.y.z.md`).
### 1.1. Epic Granulation