build updates
This commit is contained in:
Brian Madison
22
README.md
22
README.md
@@ -1,24 +1,10 @@
|
||||
# The BMAD-Method 3.1 (Breakthrough Method of Agile (ai-driven) Development)
|
||||
# The BMAD-Method V4.0 (Breakthrough Method of AgileAI Driven Development)
|
||||
|
||||
## Old Versions
|
||||
|
||||
Old Versions:
|
||||
[Prior Version 1](https://github.com/bmadcode/BMAD-METHOD/tree/V1)
|
||||
[Prior Version 2](https://github.com/bmadcode/BMAD-METHOD/tree/V2)
|
||||
|
||||
## Do This First, and all will make sense
|
||||
|
||||
There are lots of docs here, but I HIGHLY suggest you just try the Web Agent - it takes just a few minutes to set up in Gemini - and you can use the BMad Agent to explain how this method works, how to set up in the IDE, how to set up in the Web, what should be done in the web or ide (although you can choose your own path also!) - all just by talking to the bmad agent!
|
||||
|
||||
### Web Quickstart Project Setup (Recommended)
|
||||
|
||||
Orchestrator Uber BMad Agent that does it all - already pre-compiled in the `web-build-sample` folder.
|
||||
|
||||
- The contents of [Agent Prompt Sample](web-build-sample/agent-prompt.txt) text get pasted into the Gemini Gem, or ChatPGT customGPT 'Instructions' field.
|
||||
- The remaining files in that same folder folder just need to be attached as shown in the screenshot below. Give it a name (such as BMad Agent) and save it, and you now have the BMad Agent available to help you brainstorm, research, plan, execute on your vision, or understand how this all even works!
|
||||
- Once its running, start with typing `/help`, and then type option `2` when it presents 3 options to learn about the method!
|
||||
|
||||
|
||||
|
||||
[More Documentation, Explanations, and IDE Specifics](docs/readme.md) available here!
|
||||
[Prior Version 3](https://github.com/bmadcode/BMAD-METHOD/tree/V3)
|
||||
|
||||
## End Matter
|
||||
|
||||
|
||||
@@ -8,10 +8,8 @@ agent:
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-doc-from-template
|
||||
- create-architecture
|
||||
- create-infrastructure-architecture
|
||||
- create-next-story-task
|
||||
- doc-sharding-task
|
||||
- create-next-story
|
||||
- shard-doc
|
||||
- create-deep-research-prompt
|
||||
templates:
|
||||
- architecture-tmpl
|
||||
|
||||
@@ -8,9 +8,7 @@ agent:
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-doc-from-template
|
||||
- create-frontend-architecture
|
||||
- create-ai-frontend-prompt
|
||||
- create-uxui-spec
|
||||
- generate-ai-frontend-prompt
|
||||
templates:
|
||||
- front-end-architecture-tmpl
|
||||
- front-end-spec-tmpl
|
||||
|
||||
@@ -9,8 +9,8 @@ agent:
|
||||
customize: ""
|
||||
dependencies:
|
||||
tasks:
|
||||
- checklist-run-task
|
||||
- doc-sharding-task
|
||||
- execute-checklist
|
||||
- shard-doc
|
||||
- correct-course
|
||||
templates:
|
||||
- story-tmpl
|
||||
|
||||
@@ -8,7 +8,8 @@ agent:
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-doc-from-template
|
||||
- create-next-story-task
|
||||
- create-next-story
|
||||
- index-docs
|
||||
templates:
|
||||
- story-tmpl
|
||||
checklists:
|
||||
|
||||
@@ -129,7 +129,7 @@ Effective use of the BMAD Method relies on understanding where key tools, config
|
||||
- `ide-bmad-orchestrator.md`: Main prompt/definition of the IDE Orchestrator agent.
|
||||
- **Task Files:**
|
||||
- Located in `bmad-agent/tasks/` (and sometimes `bmad-agent/checklists/` for checklist-like tasks).
|
||||
- Self-contained instruction sets for specific jobs (e.g., `create-prd.md`, `checklist-run-task.md`).
|
||||
- Self-contained instruction sets for specific jobs (e.g., `create-prd.md`, `execute-checklist.md`).
|
||||
- Reduce agent bloat and provide on-demand functionality for any capable agent.
|
||||
- **Core Agent Definitions (Personas):**
|
||||
- Files (typically `.md`) defining core personalities and instructions for different agents.
|
||||
@@ -219,27 +219,27 @@ Understanding the distinct roles and responsibilities of each agent is key to ef
|
||||
|
||||
- **Function:** Designs system architecture, handles technical design, and ensures technical feasibility.
|
||||
- **Web Persona:** `Architect (Fred)` with persona `personas#architect`. Uses `checklists#architect-checklist` and `templates#architecture-tmpl`. Tasks include `tasks#create-architecture` and `tasks#create-deep-research-prompt`.
|
||||
- **IDE Persona:** `Architect (Mo)` with persona `architect.md`. Customized to be "Cold, Calculating, Brains behind the agent crew." Generates architecture (`create-architecture.md` task), helps plan stories (`create-next-story-task.md`), and can update PO-level epics/stories (`doc-sharding-task.md`).
|
||||
- **IDE Persona:** `Architect (Mo)` with persona `architect.md`. Customized to be "Cold, Calculating, Brains behind the agent crew." Generates architecture (`create-architecture.md` task), helps plan stories (`create-next-story.md`), and can update PO-level epics/stories (`shard-doc.md`).
|
||||
- **Output:** `Architecture Document`.
|
||||
|
||||
- **Design Architect:**
|
||||
|
||||
- **Function:** Focuses on UI/UX specifications, front-end technical architecture, and can generate prompts for AI UI generation services.
|
||||
- **Web Persona:** `Design Architect (Jane)` with persona `personas#design-architect`. Uses `checklists#frontend-architecture-checklist`, `templates#front-end-architecture-tmpl` (for FE architecture), and `templates#front-end-spec-tmpl` (for UX/UI Spec). Tasks: `tasks#create-frontend-architecture`, `tasks#create-ai-frontend-prompt`, `tasks#create-uxui-spec`.
|
||||
- **IDE Persona:** `Design Architect (Millie)` with persona `design-architect.md`. Customized to be "Fun and carefree, but a frontend design master." Helps design web apps, produces UI generation prompts (`create-ai-frontend-prompt.md` task), plans FE architecture (`create-frontend-architecture.md` task), and creates UX/UI specs (`create-uxui-spec.md` task).
|
||||
- **Web Persona:** `Design Architect (Jane)` with persona `personas#design-architect`. Uses `checklists#frontend-architecture-checklist`, `templates#front-end-architecture-tmpl` (for FE architecture), and `templates#front-end-spec-tmpl` (for UX/UI Spec). Tasks: `tasks#create-frontend-architecture`, `tasks#generate-ai-frontend-prompt`, `tasks#create-uxui-spec`.
|
||||
- **IDE Persona:** `Design Architect (Millie)` with persona `design-architect.md`. Customized to be "Fun and carefree, but a frontend design master." Helps design web apps, produces UI generation prompts (`generate-ai-frontend-prompt.md` task), plans FE architecture (`create-frontend-architecture.md` task), and creates UX/UI specs (`create-uxui-spec.md` task).
|
||||
- **Output:** `UX/UI Specification`, `Front-end Architecture Plan`, AI UI generation prompts.
|
||||
|
||||
- **Product Owner (PO):**
|
||||
|
||||
- **Function:** Agile Product Owner responsible for validating documents, ensuring development sequencing, managing the product backlog, running master checklists, handling mid-sprint re-planning, and drafting user stories.
|
||||
- **Web Persona:** `PO (Sarah)` with persona `personas#po`. Uses `checklists#po-master-checklist`, `checklists#story-draft-checklist`, `checklists#change-checklist`, and `templates#story-tmpl`. Tasks include `tasks#story-draft-task`, `tasks#doc-sharding-task` (extracts epics and shards architecture), and `tasks#correct-course`.
|
||||
- **IDE Persona:** `Product Owner AKA PO (Curly)` with persona `po.md`. Described as a "Jack of many trades." Tasks include `create-prd.md`, `create-next-story-task.md`, `doc-sharding-task.md`, and `correct-course.md`.
|
||||
- **Web Persona:** `PO (Sarah)` with persona `personas#po`. Uses `checklists#po-master-checklist`, `checklists#story-draft-checklist`, `checklists#change-checklist`, and `templates#story-tmpl`. Tasks include `tasks#story-draft-task`, `tasks#shard-doc` (extracts epics and shards architecture), and `tasks#correct-course`.
|
||||
- **IDE Persona:** `Product Owner AKA PO (Curly)` with persona `po.md`. Described as a "Jack of many trades." Tasks include `create-prd.md`, `create-next-story.md`, `shard-doc.md`, and `correct-course.md`.
|
||||
- **Output:** User Stories, managed PRD/Backlog.
|
||||
|
||||
- **Scrum Master (SM):**
|
||||
|
||||
- **Function:** A technical role focused on helping the team run the Scrum process, facilitating development, and often involved in story generation and refinement.
|
||||
- **Web Persona:** `SM (Bob)` with persona `personas#sm`. Described as "A very Technical Scrum Master." Uses `checklists#change-checklist`, `checklists#story-dod-checklist`, `checklists#story-draft-checklist`, and `templates#story-tmpl`. Tasks: `tasks#checklist-run-task`, `tasks#correct-course`, `tasks#story-draft-task`.
|
||||
- **Web Persona:** `SM (Bob)` with persona `personas#sm`. Described as "A very Technical Scrum Master." Uses `checklists#change-checklist`, `checklists#story-dod-checklist`, `checklists#story-draft-checklist`, and `templates#story-tmpl`. Tasks: `tasks#execute-checklist`, `tasks#correct-course`, `tasks#story-draft-task`.
|
||||
- **IDE Persona:** `Scrum Master: SM (SallySM)` with persona `sm.ide.md`. Described as "Super Technical and Detail Oriented," specialized in "Next Story Generation" (likely leveraging the `sm.ide.md` persona's capabilities).
|
||||
|
||||
- **Developer Agents (DEV):**
|
||||
@@ -295,13 +295,13 @@ Once an AI agent (like those in Gemini or ChatGPT) has generated a document (e.g
|
||||
|
||||
### Document Sharding
|
||||
|
||||
Large documents like PRDs or Architecture Documents can become unwieldy for AI agents to process efficiently, especially in environments with context window limitations. The `doc-sharding-task.md` is designed to break these down:
|
||||
Large documents like PRDs or Architecture Documents can become unwieldy for AI agents to process efficiently, especially in environments with context window limitations. The `shard-doc.md` is designed to break these down:
|
||||
|
||||
- **Purpose:** The sharding task splits a large document (e.g., PRD, Architecture, Front-End Architecture) into smaller, more granular sections or individual user stories. This makes it easier for subsequent agents, like the SM (Scrum Master) or Dev Agents, to work with specific parts of the document without needing to process the entire thing.
|
||||
- **How to Use:**
|
||||
1. Ensure the large document you want to shard (e.g., `prd.md`, `architecture.md`) exists in your project's `docs` folder.
|
||||
2. Instruct your active IDE agent (e.g., PO, SM, or the BMAD Orchestrator embodying one of these roles) to run the `doc-sharding-task.md`.
|
||||
3. You will typically specify the _source file_ to be sharded. For example: "Run the `doc-sharding-task.md` against `docs/prd.md`."
|
||||
2. Instruct your active IDE agent (e.g., PO, SM, or the BMAD Orchestrator embodying one of these roles) to run the `shard-doc.md`.
|
||||
3. You will typically specify the _source file_ to be sharded. For example: "Run the `shard-doc.md` against `docs/prd.md`."
|
||||
4. The task will guide the agent to break down the document. The output might be new smaller files or instructions on how the document is logically segmented.
|
||||
|
||||
### Utilizing Dedicated IDE Agents (SM and Dev)
|
||||
@@ -394,7 +394,7 @@ Understanding key files helps in navigating and customizing the BMAD process:
|
||||
- `web-bmad-orchestrator-agent.cfg.md`: Configuration for the web orchestrator agent.
|
||||
- `web-bmad-orchestrator-agent.md`: Definition of the web orchestrator agent.
|
||||
- **Task Definitions:**
|
||||
- Files in `bmad-agent/tasks/` or `bmad-agent/checklists/` (e.g., `checklist-run-task.md`): Reusable prompts for specific actions and also used by agents to keep agent persona files lean.
|
||||
- Files in `bmad-agent/tasks/` or `bmad-agent/checklists/` (e.g., `execute-checklist.md`): Reusable prompts for specific actions and also used by agents to keep agent persona files lean.
|
||||
- **Agent Personas & Templates:**
|
||||
- Files in `bmad-agent/personas/`: Define the core behaviors of different agents.
|
||||
- Files in `bmad-agent/templates/`: Standard formats for documents like Project Briefs, PRDs that the agents will use to populate instances of these documents.
|
||||
@@ -410,7 +410,7 @@ Understanding key files helps in navigating and customizing the BMAD process:
|
||||
### PURPOSE OF IDE TASKS
|
||||
|
||||
- **Reduce Agent Bloat:** Avoid adding numerous, rarely used instructions to primary IDE agent modes (Dev Agent, SM Agent) or even the Orchestrator's base prompt. Keeps agents lean, beneficial for IDEs with limits on custom agent complexity/numbers.
|
||||
- **On-Demand Functionality:** Instruct an active IDE agent (standalone or an embodied persona within the IDE Orchestrator) to perform a task by providing the content of the relevant task file (e.g., from `bmad-agent/tasks/checklist-run-task.md`) as a prompt, or by referencing it if the agent is configured to find it (as with the IDE Orchestrator).
|
||||
- **On-Demand Functionality:** Instruct an active IDE agent (standalone or an embodied persona within the IDE Orchestrator) to perform a task by providing the content of the relevant task file (e.g., from `bmad-agent/tasks/execute-checklist.md`) as a prompt, or by referencing it if the agent is configured to find it (as with the IDE Orchestrator).
|
||||
- **Versatility:** Any sufficiently capable agent can be asked to execute a task. Tasks can handle specific functions like running checklists, creating stories, sharding documents, indexing libraries, etc. They are self-contained instruction sets.
|
||||
|
||||
### EXAMPLES OF TASK FUNCTIONALITY
|
||||
@@ -420,14 +420,14 @@ Understanding key files helps in navigating and customizing the BMAD process:
|
||||
Here are some examples of functionalities provided by tasks found in `bmad-agent/tasks/`:
|
||||
|
||||
- **`create-prd.md`:** Guides the generation of a Product Requirements Document.
|
||||
- **`create-next-story-task.md`:** Helps in defining and creating the next user story for development.
|
||||
- **`create-next-story.md`:** Helps in defining and creating the next user story for development.
|
||||
- **`create-architecture.md`:** Assists in outlining the technical architecture for a project.
|
||||
- **`create-frontend-architecture.md`:** Focuses specifically on designing the front-end architecture.
|
||||
- **`create-uxui-spec.md`:** Facilitates the creation of a UX/UI Specification document.
|
||||
- **`create-ai-frontend-prompt.md`:** Helps in drafting a prompt for an AI service to generate UI/frontend elements.
|
||||
- **`doc-sharding-task.md`:** Provides a process for breaking down large documents into smaller, manageable parts.
|
||||
- **`generate-ai-frontend-prompt.md`:** Helps in drafting a prompt for an AI service to generate UI/frontend elements.
|
||||
- **`shard-doc.md`:** Provides a process for breaking down large documents into smaller, manageable parts.
|
||||
- **`library-indexing-task.md`:** Assists in creating an index or overview of a code library.
|
||||
- **`checklist-run-task.md`:** Executes a predefined checklist (likely using `checklist-mappings.yml`).
|
||||
- **`execute-checklist.md`:** Executes a predefined checklist (likely using `checklist-mappings.yml`).
|
||||
- **`correct-course.md`:** Provides guidance or steps for when a project needs to adjust its direction.
|
||||
- **`create-deep-research-prompt.md`:** Helps formulate prompts for conducting in-depth research on a topic.
|
||||
|
||||
|
||||
@@ -39,3 +39,4 @@ When activated:
|
||||
- `*create-prd` - Create a Product Requirements Document using the `default-template` unless another is provided
|
||||
- `*create {template-name}` - Create a document using the specified template (e.g., `*create project-brief-tmpl`)
|
||||
- `*list-templates` - Show available `templates`
|
||||
- `*index-docs` - Run the index-docs task to update the documentation index in `/docs/index.md`
|
||||
|
||||
@@ -42,3 +42,4 @@ When activated:
|
||||
- `*validate-all` - Run validation against all key documents
|
||||
- `*list-templates` - Show all available templates
|
||||
- `*list-checklists` - Show available validation checklists
|
||||
- `*index-docs` - Run the index-docs task to update the documentation index in `/docs/index.md`
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## File References
|
||||
|
||||
`Create Next Story Task`: `bmad-core/tasks/create-next-story-task.md`
|
||||
`Create Next Story Task`: `bmad-core/tasks/create-next-story.md`
|
||||
|
||||
## Persona
|
||||
|
||||
@@ -40,4 +40,5 @@
|
||||
- `*checklist`
|
||||
- list numbered list of `bmad-agent/checklists/{checklists}` and allow user to select one
|
||||
- execute the selected checklist
|
||||
- `*doc-shard` {PRD|Architecture|Other} - execute `bmad-agent/tasks/doc-sharding-task` task
|
||||
- `*doc-shard` {PRD|Architecture|Other} - execute `bmad-agent/tasks/shard-doc` task
|
||||
- `*index-docs` - Run the index-docs task to update the documentation index in `/docs/index.md`
|
||||
|
||||
@@ -18,15 +18,17 @@
|
||||
8. **Guidance on Agent Selection:** Proactively help users choose the most appropriate specialist agent if they are unsure or if their request implies a specific agent's capabilities.
|
||||
9. **Resource Awareness:** Maintain and utilize knowledge of the location and purpose of all key BMAD resources, including personas, tasks, templates, and the knowledge base, resolving paths as per configuration.
|
||||
10. **Adaptive Support & Safety:** Provide support based on the BMAD knowledge. Adhere to safety protocols regarding persona switching, defaulting to new chat recommendations unless explicitly overridden. (Reflects Core Orchestrator Principle #3 & #4)
|
||||
11. **Command Processing:** Process all slash commands (/) according to `utils#orchestrator-commands`, enabling quick navigation, mode switching, and agent selection throughout the session.
|
||||
|
||||
## Critical Start-Up & Operational Workflow (High-Level Persona Awareness)
|
||||
|
||||
_This persona is the embodiment of the orchestrator logic described in the main `ide-bmad-orchestrator-cfg.md` or equivalent web configuration._
|
||||
|
||||
1. **Initialization:** Operates based on a loaded and parsed configuration file that defines available personas, tasks, and resource paths. If this configuration is missing or unparsable, it cannot function effectively and would guide the user to address this.
|
||||
1. **Initialization:**
|
||||
- Operates based on a loaded and parsed configuration file that defines available personas, tasks, and resource paths. If this configuration is missing or unparsable, it cannot function effectively and would guide the user to address this.
|
||||
- Load and apply `utils#orchestrator-commands` to enable slash commands like `/help`, `/agent-list`, `/yolo`, and agent switching commands.
|
||||
2. **User Interaction Prompt:**
|
||||
- Greets the user and confirms operational readiness (e.g., "BMAD IDE Orchestrator ready. Config loaded.").
|
||||
- If the user's initial prompt is unclear or requests options: Lists available specialist personas (Title, Name, Description) and their configured Tasks, prompting: "Which persona shall I become, and what task should it perform?"
|
||||
3. **Persona Activation:** Upon user selection, activates the chosen persona by loading its definition and applying any specified customizations. It then fully embodies the loaded persona, and its own Orchestrator persona becomes dormant until the specialized persona's task is complete or a persona switch is initiated.
|
||||
- If the user's initial prompt is unclear or requests options: List a numbered list of available specialist personas (Title, Name, Description) prompting: "Which persona shall I become"
|
||||
- Mention that `/help` is available for commands and guidance.
|
||||
3. **Persona Activation:** Upon user selection, activates the chosen persona by loading its definition and applying any specified customizations. It then fully embodies the loaded persona, and this bmad persona becomes dormant until the specialized persona's task is complete or a persona switch is initiated.
|
||||
4. **Task Execution (as Orchestrator):** Can execute general tasks not specific to a specialist persona, such as providing information about the BMAD method itself or listing available personas/tasks.
|
||||
5. **Handling Persona Change Requests:** If a user requests a different persona while one is active, it follows the defined protocol (recommend new chat or require explicit override).
|
||||
|
||||
@@ -1,95 +0,0 @@
|
||||
# Create UI/UX Specification Task
|
||||
|
||||
## 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 a new document called `front-end-spec.md` following the `front-end-spec-tmpl` template.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Project Brief (`project-brief.md` or equivalent)
|
||||
- Product Requirements Document (PRD) (`prd.md` or equivalent)
|
||||
- User feedback or research (if available)
|
||||
|
||||
## Key Activities & Instructions
|
||||
|
||||
### 1. Understand Core Requirements
|
||||
|
||||
- Review Project Brief and PRD to grasp project goals, target audience, key features, and any existing constraints.
|
||||
- Ask clarifying questions about user needs, pain points, and desired outcomes.
|
||||
|
||||
### 2. Define Overall UX Goals & Principles (for `front-end-spec-tmpl`)
|
||||
|
||||
- Collaboratively establish and document:
|
||||
- Target User Personas (elicit details or confirm existing ones).
|
||||
- Key Usability Goals.
|
||||
- Core Design Principles for the project.
|
||||
|
||||
### 3. Develop Information Architecture (IA) (for `front-end-spec-tmpl`)
|
||||
|
||||
- Work with the user to create a Site Map or Screen Inventory.
|
||||
- Define the primary and secondary Navigation Structure.
|
||||
- Use Mermaid diagrams or lists as appropriate for the template.
|
||||
|
||||
### 4. Outline Key User Flows (for `front-end-spec-tmpl`)
|
||||
|
||||
- Identify critical user tasks from the PRD/brief.
|
||||
- For each flow:
|
||||
- Define the user's goal.
|
||||
- Collaboratively map out the steps (use Mermaid diagrams or detailed step-by-step descriptions).
|
||||
- Consider edge cases and error states.
|
||||
|
||||
### 5. Discuss Wireframes & Mockups Strategy (for `front-end-spec-tmpl`)
|
||||
|
||||
- Clarify where detailed visual designs will be created (e.g., Figma, Sketch) and ensure the `front-end-spec-tmpl` correctly links to these primary design files.
|
||||
- If low-fidelity wireframes are needed first, offer to help conceptualize layouts for key screens.
|
||||
|
||||
### 6. Define Component Library / Design System Approach (for `front-end-spec-tmpl`)
|
||||
|
||||
- Discuss if an existing design system will be used or if a new one needs to be developed.
|
||||
- If new, identify a few foundational components to start with (e.g., Button, Input, Card) and their key states/behaviors at a high level. Detailed technical specs will be in `front-end-architecture`.
|
||||
|
||||
### 7. Establish Branding & Style Guide Basics (for `front-end-spec-tmpl`)
|
||||
|
||||
- If a style guide exists, link to it.
|
||||
- If not, collaboratively define placeholders for: Color Palette, Typography, Iconography, Spacing.
|
||||
|
||||
### 8. Specify Accessibility (AX) Requirements (for `front-end-spec-tmpl`)
|
||||
|
||||
- Determine the target compliance level (e.g., WCAG 2.1 AA).
|
||||
- List any known specific AX requirements.
|
||||
|
||||
### 9. Define Responsiveness Strategy (for `front-end-spec-tmpl`)
|
||||
|
||||
- Discuss and document key Breakpoints.
|
||||
- Describe the general Adaptation Strategy.
|
||||
|
||||
### 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, explain and incorporate their initial feedback and revisions directly.
|
||||
- **c. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
|
||||
|
||||
## 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)
|
||||
@@ -1,12 +1,12 @@
|
||||
# Library Indexing Task
|
||||
# Index Documentation Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task maintains the integrity and completeness of the `docs/index.md` file by scanning all documentation files and ensuring they are properly indexed with descriptions.
|
||||
This task maintains the integrity and completeness of the `docs/index.md` file by scanning all documentation files and ensuring they are properly indexed with descriptions. It handles both root-level documents and documents within subfolders, organizing them hierarchically.
|
||||
|
||||
## Task Instructions
|
||||
|
||||
You are now operating as a Documentation Indexer. Your goal is to ensure all documentation files are properly cataloged in the central index.
|
||||
You are now operating as a Documentation Indexer. Your goal is to ensure all documentation files are properly cataloged in the central index with proper organization for subfolders.
|
||||
|
||||
### Required Steps
|
||||
|
||||
@@ -15,6 +15,7 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
- The `docs/` directory and all subdirectories
|
||||
- The existing `docs/index.md` file (create if absent)
|
||||
- All markdown (`.md`) and text (`.txt`) files in the documentation structure
|
||||
- Note the folder structure for hierarchical organization
|
||||
|
||||
2. For the existing `docs/index.md`:
|
||||
|
||||
@@ -22,6 +23,7 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
- Note existing file references and descriptions
|
||||
- Identify any broken links or missing files
|
||||
- Keep track of already-indexed content
|
||||
- Preserve existing folder sections
|
||||
|
||||
3. For each documentation file found:
|
||||
|
||||
@@ -29,6 +31,7 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
- Generate a brief description by analyzing the content
|
||||
- Create a relative markdown link to the file
|
||||
- Check if it's already in the index
|
||||
- Note which folder it belongs to (if in a subfolder)
|
||||
- If missing or outdated, prepare an update
|
||||
|
||||
4. For any missing or non-existent files found in index:
|
||||
@@ -42,14 +45,54 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
|
||||
5. Update `docs/index.md`:
|
||||
- Maintain existing structure and organization
|
||||
- Create level 2 sections (`##`) for each subfolder
|
||||
- List root-level documents first
|
||||
- Add missing entries with descriptions
|
||||
- Update outdated entries
|
||||
- Remove only entries that were confirmed for removal
|
||||
- Ensure consistent formatting throughout
|
||||
|
||||
### Index Structure Format
|
||||
|
||||
The index should be organized as follows:
|
||||
|
||||
```markdown
|
||||
# Documentation Index
|
||||
|
||||
## Root Documents
|
||||
|
||||
### [Document Title](./document.md)
|
||||
|
||||
Brief description of the document's purpose and contents.
|
||||
|
||||
### [Another Document](./another.md)
|
||||
|
||||
Description here.
|
||||
|
||||
## Folder Name
|
||||
|
||||
Documents within the `folder-name/` directory:
|
||||
|
||||
### [Document in Folder](./folder-name/document.md)
|
||||
|
||||
Description of this document.
|
||||
|
||||
### [Another in Folder](./folder-name/another.md)
|
||||
|
||||
Description here.
|
||||
|
||||
## Another Folder
|
||||
|
||||
Documents within the `another-folder/` directory:
|
||||
|
||||
### [Nested Document](./another-folder/document.md)
|
||||
|
||||
Description of nested document.
|
||||
```
|
||||
|
||||
### Index Entry Format
|
||||
|
||||
Each entry in `docs/index.md` should follow this format:
|
||||
Each entry should follow this format:
|
||||
|
||||
```markdown
|
||||
### [Document Title](relative/path/to/file.md)
|
||||
@@ -62,24 +105,28 @@ Brief description of the document's purpose and contents.
|
||||
1. NEVER modify the content of indexed files
|
||||
2. Preserve existing descriptions in index.md when they are adequate
|
||||
3. Maintain any existing categorization or grouping in the index
|
||||
4. Use relative paths for all links
|
||||
4. Use relative paths for all links (starting with `./`)
|
||||
5. Ensure descriptions are concise but informative
|
||||
6. NEVER remove entries without explicit confirmation
|
||||
7. Report any broken links or inconsistencies found
|
||||
8. Allow path updates for moved files before considering removal
|
||||
9. Create folder sections using level 2 headings (`##`)
|
||||
10. Sort folders alphabetically, with root documents listed first
|
||||
11. Within each section, sort documents alphabetically by title
|
||||
|
||||
### Process Output
|
||||
|
||||
The task will provide:
|
||||
|
||||
1. A summary of changes made to index.md
|
||||
2. List of newly indexed files
|
||||
2. List of newly indexed files (organized by folder)
|
||||
3. List of updated entries
|
||||
4. List of entries presented for removal and their status:
|
||||
- Confirmed removals
|
||||
- Updated paths
|
||||
- Kept despite missing file
|
||||
5. Any other issues or inconsistencies found
|
||||
5. Any new folders discovered
|
||||
6. Any other issues or inconsistencies found
|
||||
|
||||
### Handling Missing Files
|
||||
|
||||
@@ -92,6 +139,7 @@ For each file referenced in the index but not found in the filesystem:
|
||||
Title: [Document Title]
|
||||
Path: relative/path/to/file.md
|
||||
Description: Existing description
|
||||
Section: [Root Documents | Folder Name]
|
||||
|
||||
Options:
|
||||
|
||||
@@ -105,13 +153,25 @@ For each file referenced in the index but not found in the filesystem:
|
||||
2. Wait for user confirmation before taking any action
|
||||
3. Log the decision for the final report
|
||||
|
||||
### Special Cases
|
||||
|
||||
1. **Sharded Documents**: If a folder contains an `index.md` file, treat it as a sharded document:
|
||||
- Use the folder's `index.md` title as the section title
|
||||
- List the folder's documents as subsections
|
||||
- Note in the description that this is a multi-part document
|
||||
|
||||
2. **README files**: Convert `README.md` to more descriptive titles based on content
|
||||
|
||||
3. **Nested Subfolders**: For deeply nested folders, maintain the hierarchy but limit to 2 levels in the main index. Deeper structures should have their own index files.
|
||||
|
||||
## Required Input
|
||||
|
||||
Please provide:
|
||||
|
||||
1. Location of the `docs/` directory
|
||||
1. Location of the `docs/` directory (default: `./docs`)
|
||||
2. Confirmation of write access to `docs/index.md`
|
||||
3. Any specific categorization preferences
|
||||
4. Any files or directories to exclude from indexing
|
||||
4. Any files or directories to exclude from indexing (e.g., `.git`, `node_modules`)
|
||||
5. Whether to include hidden files/folders (starting with `.`)
|
||||
|
||||
Would you like to proceed with library indexing? Please provide the required input above.
|
||||
Would you like to proceed with documentation indexing? Please provide the required input above.
|
||||
@@ -1,87 +1,393 @@
|
||||
# {Project Name} UI/UX Specification
|
||||
# {{Project Name}} UI/UX Specification
|
||||
|
||||
[[LLM: Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.]]
|
||||
|
||||
## Introduction
|
||||
|
||||
{State the purpose - to define the user experience goals, information architecture, user flows, and visual design specifications for the project's user interface.}
|
||||
[[LLM: Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.]]
|
||||
|
||||
This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{Project Name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
|
||||
|
||||
## Overall UX Goals & Principles
|
||||
|
||||
- **Target User Personas:** {Reference personas or briefly describe key user types and their goals.}
|
||||
- **Usability Goals:** {e.g., Ease of learning, efficiency of use, error prevention.}
|
||||
- **Design Principles:** {List 3-5 core principles guiding the UI/UX design - e.g., "Clarity over cleverness", "Consistency", "Provide feedback".}
|
||||
[[LLM: Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
|
||||
|
||||
1. Target User Personas - elicit details or confirm existing ones from PRD
|
||||
2. Key Usability Goals - understand what success looks like for users
|
||||
3. Core Design Principles - establish 3-5 guiding principles
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Target User Personas
|
||||
|
||||
{{persona_descriptions}}
|
||||
|
||||
@{example: personas}
|
||||
- **Power User:** Technical professionals who need advanced features and efficiency
|
||||
- **Casual User:** Occasional users who prioritize ease of use and clear guidance
|
||||
- **Administrator:** System managers who need control and oversight capabilities
|
||||
@{/example}
|
||||
|
||||
### Usability Goals
|
||||
|
||||
{{usability_goals}}
|
||||
|
||||
@{example: usability_goals}
|
||||
- Ease of learning: New users can complete core tasks within 5 minutes
|
||||
- Efficiency of use: Power users can complete frequent tasks with minimal clicks
|
||||
- Error prevention: Clear validation and confirmation for destructive actions
|
||||
- Memorability: Infrequent users can return without relearning
|
||||
@{/example}
|
||||
|
||||
### Design Principles
|
||||
|
||||
{{design_principles}}
|
||||
|
||||
@{example: design_principles}
|
||||
1. **Clarity over cleverness** - Prioritize clear communication over aesthetic innovation
|
||||
2. **Progressive disclosure** - Show only what's needed, when it's needed
|
||||
3. **Consistent patterns** - Use familiar UI patterns throughout the application
|
||||
4. **Immediate feedback** - Every action should have a clear, immediate response
|
||||
5. **Accessible by default** - Design for all users from the start
|
||||
@{/example}
|
||||
|
||||
## Information Architecture (IA)
|
||||
|
||||
- **Site Map / Screen Inventory:**
|
||||
[[LLM: Collaborate with the user to create a comprehensive information architecture:
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Homepage] --> B(Dashboard);
|
||||
A --> C{Settings};
|
||||
B --> D[View Details];
|
||||
C --> E[Profile Settings];
|
||||
C --> F[Notification Settings];
|
||||
```
|
||||
1. Build a Site Map or Screen Inventory showing all major areas
|
||||
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
|
||||
3. Use Mermaid diagrams for visual representation
|
||||
4. Consider user mental models and expected groupings
|
||||
|
||||
_(Or provide a list of all screens/pages)_
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
- **Navigation Structure:** {Describe primary navigation (e.g., top bar, sidebar), secondary navigation, breadcrumbs, etc.}
|
||||
### Site Map / Screen Inventory
|
||||
|
||||
```mermaid
|
||||
{{sitemap_diagram}}
|
||||
```
|
||||
|
||||
@{example: sitemap}
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Homepage] --> B[Dashboard]
|
||||
A --> C[Products]
|
||||
A --> D[Account]
|
||||
B --> B1[Analytics]
|
||||
B --> B2[Recent Activity]
|
||||
C --> C1[Browse]
|
||||
C --> C2[Search]
|
||||
C --> C3[Product Details]
|
||||
D --> D1[Profile]
|
||||
D --> D2[Settings]
|
||||
D --> D3[Billing]
|
||||
```
|
||||
@{/example}
|
||||
|
||||
### Navigation Structure
|
||||
|
||||
**Primary Navigation:** {{primary_nav_description}}
|
||||
|
||||
**Secondary Navigation:** {{secondary_nav_description}}
|
||||
|
||||
**Breadcrumb Strategy:** {{breadcrumb_strategy}}
|
||||
|
||||
## User Flows
|
||||
|
||||
{Detail key user tasks. Use diagrams or descriptions.}
|
||||
[[LLM: For each critical user task identified in the PRD:
|
||||
|
||||
### {User Flow Name, e.g., User Login}
|
||||
1. Define the user's goal clearly
|
||||
2. Map out all steps including decision points
|
||||
3. Consider edge cases and error states
|
||||
4. Use Mermaid flow diagrams for clarity
|
||||
5. Link to external tools (Figma/Miro) if detailed flows exist there
|
||||
|
||||
- **Goal:** {What the user wants to achieve.}
|
||||
- **Steps / Diagram:**
|
||||
Create subsections for each major flow. After presenting all flows, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```mermaid
|
||||
<<REPEAT: user_flow>>
|
||||
### {{flow_name}}
|
||||
|
||||
graph TD
|
||||
Start --> EnterCredentials[Enter Email/Password];
|
||||
EnterCredentials --> ClickLogin[Click Login Button];
|
||||
ClickLogin --> CheckAuth{Auth OK?};
|
||||
CheckAuth -- Yes --> Dashboard;
|
||||
CheckAuth -- No --> ShowError[Show Error Message];
|
||||
ShowError --> EnterCredentials;
|
||||
```
|
||||
**User Goal:** {{flow_goal}}
|
||||
|
||||
_(Or: Link to specific flow diagram in Figma/Miro)_
|
||||
**Entry Points:** {{entry_points}}
|
||||
|
||||
### {Another User Flow Name}
|
||||
**Success Criteria:** {{success_criteria}}
|
||||
|
||||
{...}
|
||||
#### Flow Diagram
|
||||
|
||||
```mermaid
|
||||
{{flow_diagram}}
|
||||
```
|
||||
|
||||
**Edge Cases & Error Handling:**
|
||||
- {{edge_case_1}}
|
||||
- {{edge_case_2}}
|
||||
|
||||
**Notes:** {{flow_notes}}
|
||||
<</REPEAT>>
|
||||
|
||||
@{example: user_flow}
|
||||
### User Registration
|
||||
|
||||
**User Goal:** Create a new account to access the platform
|
||||
|
||||
**Entry Points:** Homepage CTA, Login page link, Marketing landing pages
|
||||
|
||||
**Success Criteria:** User successfully creates account and reaches dashboard
|
||||
|
||||
#### Flow Diagram
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
Start[Landing Page] --> Click[Click Sign Up]
|
||||
Click --> Form[Registration Form]
|
||||
Form --> Fill[Fill Required Fields]
|
||||
Fill --> Submit[Submit Form]
|
||||
Submit --> Validate{Valid?}
|
||||
Validate -->|No| Error[Show Errors]
|
||||
Error --> Form
|
||||
Validate -->|Yes| Verify[Email Verification]
|
||||
Verify --> Complete[Account Created]
|
||||
Complete --> Dashboard[Redirect to Dashboard]
|
||||
```
|
||||
|
||||
**Edge Cases & Error Handling:**
|
||||
- Duplicate email: Show inline error with password recovery option
|
||||
- Weak password: Real-time feedback on password strength
|
||||
- Network error: Preserve form data and show retry option
|
||||
@{/example}
|
||||
|
||||
## Wireframes & Mockups
|
||||
|
||||
{Reference the main design file link above. Optionally embed key mockups or describe main screen layouts.}
|
||||
[[LLM: Clarify where detailed visual designs will be created (Figma, Sketch, etc.) and how to reference them. If low-fidelity wireframes are needed, offer to help conceptualize layouts for key screens.
|
||||
|
||||
- **Screen / View Name 1:** {Description of layout and key elements. Link to specific Figma frame/page.}
|
||||
- **Screen / View Name 2:** {...}
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
## Component Library / Design System Reference
|
||||
**Primary Design Files:** {{design_tool_link}}
|
||||
|
||||
## Branding & Style Guide Reference
|
||||
### Key Screen Layouts
|
||||
|
||||
{Link to the primary source or define key elements here.}
|
||||
<<REPEAT: screen_layout>>
|
||||
#### {{screen_name}}
|
||||
|
||||
- **Color Palette:** {Primary, Secondary, Accent, Feedback colors (hex codes).}
|
||||
- **Typography:** {Font families, sizes, weights for headings, body, etc.}
|
||||
- **Iconography:** {Link to icon set, usage notes.}
|
||||
- **Spacing & Grid:** {Define margins, padding, grid system rules.}
|
||||
**Purpose:** {{screen_purpose}}
|
||||
|
||||
## Accessibility (AX) Requirements
|
||||
**Key Elements:**
|
||||
- {{element_1}}
|
||||
- {{element_2}}
|
||||
- {{element_3}}
|
||||
|
||||
- **Target Compliance:** {e.g., WCAG 2.1 AA}
|
||||
- **Specific Requirements:** {Keyboard navigation patterns, ARIA landmarks/attributes for complex components, color contrast minimums.}
|
||||
**Interaction Notes:** {{interaction_notes}}
|
||||
|
||||
## Responsiveness
|
||||
**Design File Reference:** {{specific_frame_link}}
|
||||
<</REPEAT>>
|
||||
|
||||
- **Breakpoints:** {Define pixel values for mobile, tablet, desktop, etc.}
|
||||
- **Adaptation Strategy:** {Describe how layout and components adapt across breakpoints. Reference designs.}
|
||||
## Component Library / Design System
|
||||
|
||||
[[LLM: Discuss whether to use an existing design system or create a new one. If creating new, identify foundational components and their key states. Note that detailed technical specs belong in front-end-architecture.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
**Design System Approach:** {{design_system_approach}}
|
||||
|
||||
### Core Components
|
||||
|
||||
<<REPEAT: component>>
|
||||
#### {{component_name}}
|
||||
|
||||
**Purpose:** {{component_purpose}}
|
||||
|
||||
**Variants:** {{component_variants}}
|
||||
|
||||
**States:** {{component_states}}
|
||||
|
||||
**Usage Guidelines:** {{usage_guidelines}}
|
||||
<</REPEAT>>
|
||||
|
||||
@{example: component}
|
||||
#### Button
|
||||
|
||||
**Purpose:** Primary interaction element for user actions
|
||||
|
||||
**Variants:** Primary, Secondary, Tertiary, Destructive
|
||||
|
||||
**States:** Default, Hover, Active, Disabled, Loading
|
||||
|
||||
**Usage Guidelines:**
|
||||
- Use Primary for main CTAs (one per view)
|
||||
- Secondary for supporting actions
|
||||
- Destructive only for permanent deletions with confirmation
|
||||
@{/example}
|
||||
|
||||
## Branding & Style Guide
|
||||
|
||||
[[LLM: Link to existing style guide or define key brand elements. Ensure consistency with company brand guidelines if they exist.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Visual Identity
|
||||
|
||||
**Brand Guidelines:** {{brand_guidelines_link}}
|
||||
|
||||
### Color Palette
|
||||
|
||||
| Color Type | Hex Code | Usage |
|
||||
|:-----------|:---------|:------|
|
||||
| **Primary** | {{primary_color}} | {{primary_usage}} |
|
||||
| **Secondary** | {{secondary_color}} | {{secondary_usage}} |
|
||||
| **Accent** | {{accent_color}} | {{accent_usage}} |
|
||||
| **Success** | {{success_color}} | Positive feedback, confirmations |
|
||||
| **Warning** | {{warning_color}} | Cautions, important notices |
|
||||
| **Error** | {{error_color}} | Errors, destructive actions |
|
||||
| **Neutral** | {{neutral_colors}} | Text, borders, backgrounds |
|
||||
|
||||
### Typography
|
||||
|
||||
**Font Families:**
|
||||
- **Primary:** {{primary_font}}
|
||||
- **Secondary:** {{secondary_font}}
|
||||
- **Monospace:** {{mono_font}}
|
||||
|
||||
**Type Scale:**
|
||||
| Element | Size | Weight | Line Height |
|
||||
|:--------|:-----|:-------|:------------|
|
||||
| H1 | {{h1_size}} | {{h1_weight}} | {{h1_line}} |
|
||||
| H2 | {{h2_size}} | {{h2_weight}} | {{h2_line}} |
|
||||
| H3 | {{h3_size}} | {{h3_weight}} | {{h3_line}} |
|
||||
| Body | {{body_size}} | {{body_weight}} | {{body_line}} |
|
||||
| Small | {{small_size}} | {{small_weight}} | {{small_line}} |
|
||||
|
||||
### Iconography
|
||||
|
||||
**Icon Library:** {{icon_library}}
|
||||
|
||||
**Usage Guidelines:** {{icon_guidelines}}
|
||||
|
||||
### Spacing & Layout
|
||||
|
||||
**Grid System:** {{grid_system}}
|
||||
|
||||
**Spacing Scale:** {{spacing_scale}}
|
||||
|
||||
## Accessibility Requirements
|
||||
|
||||
[[LLM: Define specific accessibility requirements based on target compliance level and user needs. Be comprehensive but practical.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Compliance Target
|
||||
|
||||
**Standard:** {{compliance_standard}}
|
||||
|
||||
### Key Requirements
|
||||
|
||||
**Visual:**
|
||||
- Color contrast ratios: {{contrast_requirements}}
|
||||
- Focus indicators: {{focus_requirements}}
|
||||
- Text sizing: {{text_requirements}}
|
||||
|
||||
**Interaction:**
|
||||
- Keyboard navigation: {{keyboard_requirements}}
|
||||
- Screen reader support: {{screen_reader_requirements}}
|
||||
- Touch targets: {{touch_requirements}}
|
||||
|
||||
**Content:**
|
||||
- Alternative text: {{alt_text_requirements}}
|
||||
- Heading structure: {{heading_requirements}}
|
||||
- Form labels: {{form_requirements}}
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
{{accessibility_testing}}
|
||||
|
||||
## Responsiveness Strategy
|
||||
|
||||
[[LLM: Define breakpoints and adaptation strategies for different device sizes. Consider both technical constraints and user contexts.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Breakpoints
|
||||
|
||||
| Breakpoint | Min Width | Max Width | Target Devices |
|
||||
|:-----------|:----------|:----------|:---------------|
|
||||
| Mobile | {{mobile_min}} | {{mobile_max}} | {{mobile_devices}} |
|
||||
| Tablet | {{tablet_min}} | {{tablet_max}} | {{tablet_devices}} |
|
||||
| Desktop | {{desktop_min}} | {{desktop_max}} | {{desktop_devices}} |
|
||||
| Wide | {{wide_min}} | - | {{wide_devices}} |
|
||||
|
||||
### Adaptation Patterns
|
||||
|
||||
**Layout Changes:** {{layout_adaptations}}
|
||||
|
||||
**Navigation Changes:** {{nav_adaptations}}
|
||||
|
||||
**Content Priority:** {{content_adaptations}}
|
||||
|
||||
**Interaction Changes:** {{interaction_adaptations}}
|
||||
|
||||
## Animation & Micro-interactions
|
||||
|
||||
[[LLM: Define motion design principles and key interactions. Keep performance and accessibility in mind.
|
||||
|
||||
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
### Motion Principles
|
||||
|
||||
{{motion_principles}}
|
||||
|
||||
### Key Animations
|
||||
|
||||
<<REPEAT: animation>>
|
||||
- **{{animation_name}}:** {{animation_description}} (Duration: {{duration}}, Easing: {{easing}})
|
||||
<</REPEAT>>
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
[[LLM: Define performance goals and strategies that impact UX design decisions.]]
|
||||
|
||||
### Performance Goals
|
||||
|
||||
- **Page Load:** {{load_time_goal}}
|
||||
- **Interaction Response:** {{interaction_goal}}
|
||||
- **Animation FPS:** {{animation_goal}}
|
||||
|
||||
### Design Strategies
|
||||
|
||||
{{performance_strategies}}
|
||||
|
||||
## Next Steps
|
||||
|
||||
[[LLM: After completing the UI/UX specification:
|
||||
|
||||
1. Recommend review with stakeholders
|
||||
2. Suggest creating/updating visual designs in design tool
|
||||
3. Prepare for handoff to Design Architect for frontend architecture
|
||||
4. Note any open questions or decisions needed]]
|
||||
|
||||
### Immediate Actions
|
||||
|
||||
1. {{next_step_1}}
|
||||
2. {{next_step_2}}
|
||||
3. {{next_step_3}}
|
||||
|
||||
### Design Handoff Checklist
|
||||
|
||||
- [ ] All user flows documented
|
||||
- [ ] Component inventory complete
|
||||
- [ ] Accessibility requirements defined
|
||||
- [ ] Responsive strategy clear
|
||||
- [ ] Brand guidelines incorporated
|
||||
- [ ] Performance goals established
|
||||
|
||||
## Change Log
|
||||
|
||||
| Change | Date | Version | Description | Author |
|
||||
| ------ | ---- | ------- | ----------- | ------ |
|
||||
| Date | Version | Description | Author |
|
||||
|:-----|:--------|:------------|:-------|
|
||||
| {{date}} | 1.0.0 | Initial UI/UX specification | {{author}} |
|
||||
|
||||
---
|
||||
|
||||
## Checklist Results
|
||||
|
||||
[[LLM: If a UI/UX checklist exists, run it against this document and report results here.]]
|
||||
@@ -22,9 +22,10 @@ class WebBuilder {
|
||||
* Build all web bundles
|
||||
*/
|
||||
async buildAll() {
|
||||
console.log('🚀 Building all web bundles...');
|
||||
console.log('🚀 Building all bundles...');
|
||||
|
||||
const results = {
|
||||
teams: [],
|
||||
bundles: [],
|
||||
agents: [],
|
||||
errors: []
|
||||
@@ -39,11 +40,20 @@ class WebBuilder {
|
||||
for (const config of bundleConfigs) {
|
||||
try {
|
||||
const result = await this.buildBundle(config);
|
||||
const isTeamBundle = config.name.toLowerCase().includes('team');
|
||||
if (isTeamBundle) {
|
||||
results.teams.push(result);
|
||||
} else {
|
||||
results.bundles.push(result);
|
||||
console.log(`✅ Built bundle: ${config.name}`);
|
||||
}
|
||||
const bundleType = isTeamBundle ? 'team bundle' : 'bundle';
|
||||
console.log(`✅ Built ${bundleType}: ${config.name}`);
|
||||
} catch (error) {
|
||||
console.error(`❌ Failed to build bundle ${config.name}:`, error.message);
|
||||
results.errors.push({ type: 'bundle', name: config.name, error: error.message });
|
||||
const isTeamBundle = config.name.toLowerCase().includes('team');
|
||||
const bundleType = isTeamBundle ? 'team bundle' : 'bundle';
|
||||
const errorType = isTeamBundle ? 'team' : 'bundle';
|
||||
console.error(`❌ Failed to build ${bundleType} ${config.name}:`, error.message);
|
||||
results.errors.push({ type: errorType, name: config.name, error: error.message });
|
||||
}
|
||||
}
|
||||
|
||||
@@ -78,7 +88,10 @@ class WebBuilder {
|
||||
}
|
||||
|
||||
console.log(`\n📊 Build Summary:`);
|
||||
console.log(` Teams: ${results.teams.length} built, ${results.errors.filter(e => e.type === 'team').length} failed`);
|
||||
if (results.bundles.length > 0 || results.errors.filter(e => e.type === 'bundle').length > 0) {
|
||||
console.log(` Bundles: ${results.bundles.length} built, ${results.errors.filter(e => e.type === 'bundle').length} failed`);
|
||||
}
|
||||
console.log(` Agents: ${results.agents.length} built, ${results.errors.filter(e => e.type === 'agent').length} failed`);
|
||||
|
||||
return results;
|
||||
@@ -93,7 +106,10 @@ class WebBuilder {
|
||||
* Build a specific bundle
|
||||
*/
|
||||
async buildBundle(bundleConfig) {
|
||||
console.log(`📦 Building bundle: ${bundleConfig.name}`);
|
||||
const isTeamBundle = bundleConfig.name.toLowerCase().includes('team');
|
||||
const emoji = isTeamBundle ? '👥' : '📦';
|
||||
const bundleType = isTeamBundle ? 'team bundle' : 'bundle';
|
||||
console.log(`${emoji} Building ${bundleType}: ${bundleConfig.name}`);
|
||||
|
||||
// Ensure agents is an array of strings
|
||||
const agentIds = Array.isArray(bundleConfig.agents) ? bundleConfig.agents : [];
|
||||
@@ -189,7 +205,7 @@ class WebBuilder {
|
||||
content += `==================== START: agent-config ====================\n`;
|
||||
content += yaml.dump({
|
||||
name: bundle.metadata.name,
|
||||
version: bundle.metadata.version,
|
||||
version: bundle.metadata.version || '1.0.0',
|
||||
agents: bundle.agents,
|
||||
commands: config.output?.orchestrator_commands || []
|
||||
});
|
||||
@@ -213,7 +229,7 @@ class WebBuilder {
|
||||
// Create agent-config.txt
|
||||
const agentConfigContent = yaml.dump({
|
||||
name: bundle.metadata.name,
|
||||
version: bundle.metadata.version,
|
||||
version: bundle.metadata.version || '1.0.0',
|
||||
environment: bundle.metadata.environment,
|
||||
agents: bundle.agents,
|
||||
commands: config.output?.orchestrator_commands || [],
|
||||
@@ -251,20 +267,30 @@ class WebBuilder {
|
||||
* Create orchestrator prompt content
|
||||
*/
|
||||
createOrchestratorPrompt(bundle, config) {
|
||||
// Use the actual BMAD orchestrator agent prompt
|
||||
const orchestratorPaths = [
|
||||
path.join(this.rootPath, '_old', 'web-bmad-orchestrator-agent.md'),
|
||||
path.join(this.rootPath, 'bmad-agent', 'web-bmad-orchestrator-agent.md')
|
||||
];
|
||||
// Try to use the bmad persona as the orchestrator base
|
||||
const bmadPersonaPath = path.join(this.rootPath, 'bmad-core', 'personas', 'bmad.md');
|
||||
|
||||
for (const orchestratorPath of orchestratorPaths) {
|
||||
if (fs.existsSync(orchestratorPath)) {
|
||||
return fs.readFileSync(orchestratorPath, 'utf8');
|
||||
if (fs.existsSync(bmadPersonaPath)) {
|
||||
const bmadContent = fs.readFileSync(bmadPersonaPath, 'utf8');
|
||||
// Append bundle-specific agent information
|
||||
let prompt = bmadContent + '\n\n';
|
||||
prompt += `## Available Agents in ${bundle.metadata.name}\n\n`;
|
||||
|
||||
Object.entries(bundle.agents).forEach(([id, agent]) => {
|
||||
const command = config.output?.orchestrator_commands?.find(cmd => cmd.includes(id)) || `/${id}`;
|
||||
prompt += `### ${agent.name} (${command})\n`;
|
||||
prompt += `- **Role:** ${agent.title}\n`;
|
||||
prompt += `- **Description:** ${agent.description}\n`;
|
||||
if (agent.customize) {
|
||||
prompt += `- **Customization:** ${agent.customize}\n`;
|
||||
}
|
||||
prompt += '\n';
|
||||
});
|
||||
|
||||
return prompt;
|
||||
}
|
||||
|
||||
// Fallback to basic prompt if orchestrator file not found
|
||||
console.warn('Warning: web-bmad-orchestrator-agent.md not found, using fallback prompt');
|
||||
// Fallback to basic prompt if bmad persona not found
|
||||
|
||||
let prompt = `# BMAD ${bundle.metadata.name} Orchestrator\n\n`;
|
||||
prompt += `You are the BMAD orchestrator for the ${bundle.metadata.name}. `;
|
||||
@@ -273,7 +299,12 @@ class WebBuilder {
|
||||
// List available agents
|
||||
Object.entries(bundle.agents).forEach(([id, agent]) => {
|
||||
prompt += `## ${agent.name} (${config.output?.orchestrator_commands?.find(cmd => cmd.includes(id)) || `/${id}`})\n`;
|
||||
prompt += `${agent.description}\n\n`;
|
||||
prompt += `**Role:** ${agent.title}\n`;
|
||||
prompt += `${agent.description}\n`;
|
||||
if (agent.customize) {
|
||||
prompt += `**Customization:** ${agent.customize}\n`;
|
||||
}
|
||||
prompt += '\n';
|
||||
if (agent.capabilities && agent.capabilities.length > 0) {
|
||||
prompt += `**Capabilities:**\n`;
|
||||
agent.capabilities.forEach(cap => prompt += `- ${cap}\n`);
|
||||
|
||||
@@ -19,7 +19,8 @@ program
|
||||
|
||||
// Build all web bundles and agents
|
||||
program
|
||||
.command('build:web')
|
||||
.command('build')
|
||||
.alias('build:web')
|
||||
.description('Build all web bundles and standalone agents')
|
||||
.action(async () => {
|
||||
try {
|
||||
|
||||
@@ -42,7 +42,10 @@ class BundleOptimizer {
|
||||
optimizedBundle.agents[agentDep.agent] = {
|
||||
name: agentDep.config.name,
|
||||
id: agentDep.config.id,
|
||||
title: agentDep.config.title,
|
||||
description: agentDep.config.description,
|
||||
persona: agentDep.config.persona,
|
||||
customize: agentDep.config.customize || '',
|
||||
capabilities: agentDep.config.capabilities || [],
|
||||
workflow: agentDep.config.workflow || []
|
||||
};
|
||||
@@ -172,7 +175,7 @@ class BundleOptimizer {
|
||||
const agentDep = resolver.resolveAgentDependencies(agentId, environment);
|
||||
const bundleConfig = {
|
||||
name: `${agentDep.config.name} Standalone`,
|
||||
version: agentDep.config.version,
|
||||
version: agentDep.config.version || '1.0.0',
|
||||
target_environment: environment,
|
||||
optimize: true
|
||||
};
|
||||
|
||||
@@ -51,7 +51,7 @@ class DependencyResolver {
|
||||
* Validate agent configuration structure
|
||||
*/
|
||||
validateAgentConfig(config, agentId) {
|
||||
const required = ['name', 'id', 'version'];
|
||||
const required = ['name', 'id'];
|
||||
|
||||
for (const field of required) {
|
||||
if (!config[field]) {
|
||||
|
||||
@@ -23,6 +23,7 @@ node build/cli.js build:bundle --name "planning"
|
||||
```
|
||||
|
||||
**Key Resources:**
|
||||
|
||||
- `bmad-core/`: Portable resources for copying to your projects
|
||||
- `agents/`: Individual agent configurations
|
||||
- `bundles/`: Bundle configurations for different use cases
|
||||
@@ -206,7 +207,7 @@ A powerful alternative is the `ide-bmad-orchestrator.md`. This agent provides th
|
||||
- Persona: "po.md"
|
||||
- Tasks:
|
||||
- [Create PRD](create-prd.md)
|
||||
- [Create Next Story](create-next-story-task.md)
|
||||
- [Create Next Story](create-next-story.md)
|
||||
```
|
||||
|
||||
2. **Operational Workflow (inside `ide-bmad-orchestrator.md`):**
|
||||
|
||||
@@ -7,10 +7,7 @@
|
||||
"bmad-build": "build/cli.js"
|
||||
},
|
||||
"scripts": {
|
||||
"build": "node build/cli.js build:web",
|
||||
"build:web": "node build/cli.js build:web",
|
||||
"build:bundle": "node build/cli.js build:bundle",
|
||||
"build:agent": "node build/cli.js build:agent",
|
||||
"build": "node build/cli.js build",
|
||||
"list:agents": "node build/cli.js list:agents",
|
||||
"analyze:deps": "node build/cli.js analyze:deps",
|
||||
"validate": "node build/cli.js validate",
|
||||
@@ -31,7 +28,7 @@
|
||||
"agents",
|
||||
"bmad"
|
||||
],
|
||||
"author": "BMAD Development Team",
|
||||
"author": "Brian (BMad) Madison",
|
||||
"license": "MIT",
|
||||
"repository": {
|
||||
"type": "git",
|
||||
|
||||
Reference in New Issue
Block a user