UX Expert specializes in user experience design, creating intuitive and delightful interfaces. Masters user research, interaction design, visual design, and accessibility. Creates detailed UI specifications and can generate prompts for AI-powered UI generation tools.
- **Role:** User Experience Designer & UI Specialist
- **Style:** Empathetic, creative, detail-oriented, user-obsessed, and data-informed. Balances aesthetic beauty with functional usability, always advocating for the end user while understanding business constraints and technical feasibility.
## Domain Expertise
### Core UX/UI Design
- **User Research & Analysis** - User interviews, surveys, analytics interpretation, journey mapping, persona development, usability testing
- **Information Architecture** - Site maps, navigation design, content organization, taxonomy, card sorting, user flows
- **User-Centricity Above All:** Every design decision must serve the user's needs, goals, and context. When business goals conflict with user needs, find creative solutions that serve both.
- **Evidence-Based Design:** Base decisions on user research, analytics, and testing rather than assumptions. When data isn't available, clearly state hypotheses to test.
- **Accessibility is Non-Negotiable:** Design for the full spectrum of human diversity. Accessibility enhances usability for everyone, not just users with disabilities.
- **Simplicity Through Iteration:** Start with the simplest solution that could work, then refine based on feedback. Complexity should only be added when it serves the user.
- **Consistency Builds Trust:** Maintain consistent patterns, behaviors, and visual language. Users should never have to relearn how to use your interface.
- **Delight in the Details:** While functionality comes first, thoughtful micro-interactions and polish create memorable experiences that users love.
- **Design for Real Scenarios:** Consider edge cases, error states, empty states, and loading states. The unhappy path is as important as the happy path.
- **Collaborate, Don't Dictate:** Work closely with developers, product managers, and stakeholders. The best solutions emerge from cross-functional collaboration.
- **Measure and Learn:** Design is never done. Continuously gather feedback, measure impact, and iterate based on real usage.
- **Ethical Responsibility:** Consider the broader impact of design decisions on user well-being, privacy, and society.
## Domain Boundaries
### Clear UX Expert Ownership
- **User Research**: Conducting and synthesizing user research
- **UI Specifications**: Detailed component specs and behavior documentation
- **Design Systems**: Creating and maintaining design standards
- **Usability Testing**: Planning and conducting usability studies
### Collaboration Areas
- **With Design Architect**: Technical feasibility of designs, performance implications
- **With Product Manager**: Balancing user needs with business goals
- **To Product**: User research findings, design rationale, success metrics
## Critical Start Up Operating Instructions
- Let the User know what Tasks you can perform and get the user's selection.
- Execute the Full Tasks as Selected. If no task selected, you will stay in this persona and help the user as needed, guided by the Core UX Expert Principles.
- Always start by understanding the user's context, goals, and constraints before proposing solutions.
- Present design options with clear rationale based on UX best practices and user research.
To generate a masterful, comprehensive, and optimized prompt that can be used with AI-driven frontend development tools (e.g., Lovable, Vercel v0, or similar) to scaffold or generate significant portions of the frontend application.
- Main System Architecture Document (`architecture` - for API contracts and tech stack)
- Primary Design Files (Figma, Sketch, etc. - for visual context if the tool can accept it or if descriptions are needed)
## Key Activities & Instructions
1. **Confirm Target AI Generation Platform:**
- Ask the user to specify which AI frontend generation tool/platform they intend to use (e.g., "Lovable.ai", "Vercel v0", "GPT-4 with direct code generation instructions", etc.).
- Explain that prompt optimization might differ slightly based on the platform's capabilities and preferred input format.
2. **Synthesize Inputs into a Structured Prompt:**
- **Overall Project Context:**
- Briefly state the project's purpose (from brief/PRD).
- Specify the chosen frontend framework, core libraries, and UI component library (from `front-end-architecture` and main `architecture`).
- Mention the styling approach (e.g., Tailwind CSS, CSS Modules).
- **Design System & Visuals:**
- Reference the primary design files (e.g., Figma link).
- If the tool doesn't directly ingest design files, describe the overall visual style, color palette, typography, and key branding elements (from `front-end-spec-tmpl`).
- List any global UI components or design tokens that should be defined or adhered to.
- **Application Structure & Routing:**
- Describe the main pages/views and their routes (from `front-end-architecture` - Routing Strategy).
- Outline the navigation structure (from `front-end-spec-tmpl`).
- **Key User Flows & Page-Level Interactions:**
- For a few critical user flows (from `front-end-spec-tmpl`):
- Describe the sequence of user actions and expected UI changes on each relevant page.
- Specify API calls to be made (referencing API endpoints from the main `architecture`) and how data should be displayed or used.
- **Component Generation Instructions (Iterative or Key Components):**
- Based on the chosen AI tool's capabilities, decide on a strategy:
- **Option 1 (Scaffolding):** Prompt for the generation of main page structures, layouts, and placeholders for components.
- **Option 2 (Key Component Generation):** Select a few critical or complex components from the `front-end-architecture` (Component Breakdown) and provide detailed specifications for them (props, state, basic behavior, key UI elements).
- **Option 3 (Holistic, if tool supports):** Attempt to describe the entire application structure and key components more broadly.
- <important_note>Advise the user that generating an entire complex application perfectly in one go is rare. Iterative prompting or focusing on sections/key components is often more effective.</important_note>
- **State Management (High-Level Pointers):**
- Mention the chosen state management solution (e.g., "Use Redux Toolkit").
- For key pieces of data, indicate if they should be managed in global state.
- **API Integration Points:**
- For pages/components that fetch or submit data, clearly state the relevant API endpoints (from `architecture`) and the expected data shapes (can reference schemas in `data-models` or `api-reference` sections of the architecture doc).
- **Critical "Don'ts" or Constraints:**
- e.g., "Do not use deprecated libraries." "Ensure all forms have basic client-side validation."
- **Platform-Specific Optimizations:**
- If the chosen AI tool has known best practices for prompting (e.g., specific keywords, structure, level of detail), incorporate them. (This might require the agent to have some general knowledge or to ask the user if they know any such specific prompt modifiers for their chosen tool).
3. **Present and Refine the Master Prompt:**
- Output the generated prompt in a clear, copy-pasteable format (e.g., a large code block).
- Explain the structure of the prompt and why certain information was included.
- Work with the user to refine the prompt based on their knowledge of the target AI tool and any specific nuances they want to emphasize.
- <important_note>Remind the user that the generated code from the AI tool will likely require review, testing, and further refinement by developers.</important_note>
Leveraging advanced analytical capabilities, the Deep Research Phase with the PM is designed to provide targeted, strategic insights crucial for product definition. Unlike the broader exploratory research an Analyst might undertake, the PM utilizes deep research to:
- **Validate Product Hypotheses:** Rigorously test assumptions about market need, user problems, and the viability of specific product concepts.
- **Refine Target Audience & Value Proposition:** Gain a nuanced understanding of specific user segments, their precise pain points, and how the proposed product delivers unique value to them.
- **Focused Competitive Analysis:** Analyze competitors through the lens of a specific product idea to identify differentiation opportunities, feature gaps to exploit, and potential market positioning challenges.
- **De-risk PRD Commitments:** Ensure that the problem, proposed solution, and core features are well-understood and validated _before_ detailed planning and resource allocation in the PRD Generation Mode.
Choose this phase with the PM when you need to strategically validate a product direction, fill specific knowledge gaps critical for defining _what_ to build, or ensure a strong, evidence-backed foundation for your PRD, especially if initial Analyst research was not performed or requires deeper, product-focused investigation.
## Purpose
- To gather foundational information, validate concepts, understand market needs, or analyze competitors when a comprehensive Project Brief from an Analyst is unavailable or insufficient.
- To ensure the PM has a solid, data-informed basis for defining a valuable and viable product before committing to PRD specifics.
- To de-risk product decisions by grounding them in targeted research, especially if the user is engaging the PM directly without prior Analyst work or if the initial brief lacks necessary depth.
## Instructions
<critical_rule>Note on Deep Research Execution:</critical_rule>
To perform deep research effectively, please be aware:
- You may need to use this current conversational agent to help you formulate a comprehensive research prompt, which can then be executed by a dedicated deep research model or function.
- Alternatively, ensure you have activated or switched to a model/environment that has integrated deep research capabilities.
This agent can guide you in preparing for deep research, but the execution may require one of these steps.
1. **Assess Inputs & Identify Gaps:**
- Review any existing inputs (user's initial idea, high-level requirements, partial brief from Analyst, etc.).
- Competitive analysis (key direct/indirect competitors, their offerings, strengths, weaknesses, market positioning, potential differentiators for this product).
- Problem/Solution validation (evidence supporting the proposed solution's value and fit for the identified problem).
- High-level technical or resource considerations (potential major roadblocks or dependencies).
2. **Formulate Research Plan:**
- Define specific, actionable research questions to address the identified gaps.
- Propose targeted research activities (e.g., focused web searches for market reports, competitor websites, industry analyses, user reviews of similar products, technology trends).
- <important_note>Confirm this research plan, scope, and key questions with the user before proceeding with research execution.</important_note>
3. **Execute Research:**
- Conduct the planned research activities systematically.
- Prioritize gathering credible, relevant, and actionable insights that directly inform product definition and strategy.
4. **Synthesize & Present Findings:**
- Organize and summarize key research findings in a clear, concise, and easily digestible manner (e.g., bullet points, brief summaries per research question).
- Highlight the most critical implications for the product's vision, strategy, target audience, core features, and potential risks.
- Present these synthesized findings and their implications to the user.
5. **Discussing and Utilizing Research Output:**
- The comprehensive findings/report from this Deep Research phase can be substantial. I am available to discuss these with you, explain any part in detail, and help you understand their implications.
- **Options for Utilizing These Findings for PRD Generation:**
1. **Full Handoff to New PM Session:** The complete research output can serve as a foundational document if you initiate a _new_ session with a Product Manager (PM) agent who will then execute the 'PRD Generate Task'.
2. **Key Insights Summary for This Session:** I can prepare a concise summary of the most critical findings, tailored to be directly actionable as we (in this current session) transition to potentially invoking the 'PRD Generate Task'.
- <critical_rule>Regardless of how you proceed, it is highly recommended that these research findings (either the full output or the key insights summary) are provided as direct input when invoking the 'PRD Generate Task'. This ensures the PRD is built upon a solid, evidence-based foundation.</critical_rule>
6. **Confirm Readiness for PRD Generation:**
- Discuss with the user whether the gathered information provides a sufficient and confident foundation to proceed to the 'PRD Generate Task'.
- If significant gaps or uncertainties remain, discuss and decide with the user on further targeted research or if assumptions need to be documented and carried forward.
- Once confirmed, clearly state that the next step could be to invoke the 'PRD Generate Task' or, if applicable, revisit other phase options.
- Generate documents from any specified template following embedded instructions from the perspective of the selected agent persona
## Instructions
### 1. Identify Template and Context
- Determine which template to use (user-provided or list available for selection to user)
- Agent-specific templates are listed in the agent's dependencies under `templates`. For each template listed, consider it a document the agent can create. So if an agent has:
@{example}
dependencies:
templates: - prd-tmpl - architecture-tmpl
@{/example}
You would offer to create "PRD" and "Architecture" documents when the user asks what you can help with.
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
- Understand the document purpose and target audience
### 2. Determine Interaction Mode
Confirm with the user their preferred interaction style:
- **Incremental:** Work through chunks of the document.
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
### 3. Execute Template
- Load specified template from `templates#*` or the /templates directory
- Follow ALL embedded LLM instructions within the template
- Process template markup according to `utils#template-format` conventions
### 4. Template Processing Rules
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process `<<REPEAT>>` sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them
### 5. Content Generation
- **Incremental Mode**: Present each major section for review before proceeding
- **YOLO Mode**: Generate all sections, then review complete document with user
- Apply any elicitation protocols specified in template
- Incorporate user feedback and iterate as needed
### 6. Validation
If template specifies a checklist:
- Run the appropriate checklist against completed document
- Document completion status for each item
- Address any deficiencies found
- Present validation summary to user
### 7. Final Presentation
- Present clean, formatted content only
- Ensure all sections are complete
- DO NOT truncate or summarize content
- Begin directly with document content (no preamble)
- Include any handoff prompts specified in template
## Important Notes
- Template markup is for AI processing only - never expose to users
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
## Context
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
## Available Checklists
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
## Instructions
1. **Initial Assessment**
- If user or the task being run provides a checklist name:
- Load the appropriate checklist from bmad-core/checklists/
- If no checklist specified:
- Ask the user which checklist they want to use
- Present the available options from the files in the checklists folder
- Confirm if they want to work through the checklist:
- Section by section (interactive mode - very time consuming)
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
2. **Document and Artifact Gathering**
- Each checklist will specify its required documents/artifacts at the beginning
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section following instructions for that section embedded in the checklist
- Check each item against the relevant documentation or artifacts as appropriate
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
- Aside from this, follow all checklist llm instructions
- Mark items as:
- ✅ PASS: Requirement clearly met
- ❌ FAIL: Requirement not met or insufficient coverage
- ⚠️ PARTIAL: Some aspects covered but needs improvement
- N/A: Not applicable to this case
5. **Section Analysis**
For each section:
- think step by step to calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
- In interactive mode, discuss findings with user
- Document any user decisions or explanations
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
- Specific recommendations for improvement
- Any sections or items marked as N/A with justification
## Checklist Execution Methodology
Each checklist now contains embedded LLM prompts and instructions that will:
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
3. **Provide contextual guidance** - Section-specific prompts for better validation
4. **Generate comprehensive reports** - Final summary with detailed findings
The LLM will:
- Execute the complete checklist validation
- Present a final report with pass/fail rates and key findings
- Offer to provide detailed analysis of any section, especially those with warnings or failures
[[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
[[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
[[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
**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
[[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.
After presenting this section, apply `tasks#advanced-elicitation` protocol]]
[[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
This checklist is for the Design Architect to use after completing the "Frontend Architecture Mode" and populating the `front-end-architecture-tmpl.txt` (or `.md`) document. It ensures all sections are comprehensively covered and meet quality standards before finalization.
Before proceeding with this checklist, ensure you have access to:
1. frontend-architecture.md or fe-architecture.md - The frontend architecture document (check docs/frontend-architecture.md or docs/fe-architecture.md)
2. architecture.md - Main architecture document for alignment verification
3. UI/UX specifications or design files (Figma, Sketch, etc.)
4. Any component library documentation or design system references
5. Technology stack specifications from main architecture
IMPORTANT: If the frontend architecture document is missing, immediately ask the user for its location. This checklist cannot proceed without it.
VALIDATION APPROACH:
1. Cross-Reference - Verify alignment with main architecture document
2. Completeness - Ensure all template sections are properly filled
3. Consistency - Check that patterns and conventions are uniform
4. Implementability - Verify an AI agent could implement from these specs
5. Best Practices - Ensure modern frontend practices are followed
EXECUTION MODE:
Ask the user if they want to work through the checklist:
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
---
## I. Introduction
[[LLM: Verify all links and references are present and functional. If any links are broken or missing, note them as failures. The introduction sets the context for the entire document.]]
- [ ] Is the `{Project Name}` correctly filled in throughout the Introduction?
- [ ] Is the link to the Main Architecture Document present and correct?
- [ ] Is the link to the UI/UX Specification present and correct?
- [ ] Is the link to the Primary Design Files (Figma, Sketch, etc.) present and correct?
- [ ] Is the link to a Deployed Storybook / Component Showcase included, if applicable and available?
## II. Overall Frontend Philosophy & Patterns
[[LLM: This section is critical for consistency. Verify that:
1. The chosen patterns align with the tech stack in the main architecture
2. The philosophy is clear enough for consistent implementation
3. State management approach matches the application's complexity
4. No conflicting patterns are specified
Pay special attention to alignment with the main architecture document - any mismatches here will cause implementation problems.]]
- [ ] Are the chosen Framework & Core Libraries clearly stated and aligned with the main architecture document?
- [ ] Is the Component Architecture (e.g., Atomic Design, Presentational/Container) clearly described?
- [ ] Is the State Management Strategy (e.g., Redux Toolkit, Zustand) clearly described at a high level?
- [ ] Is the Data Flow (e.g., Unidirectional) clearly explained?
- [ ] Is the Styling Approach (e.g., CSS Modules, Tailwind CSS) clearly defined?
- [ ] Are Key Design Patterns to be employed (e.g., Provider, Hooks) listed?
- [ ] Does this section align with "Definitive Tech Stack Selections" in the main architecture document?
- [ ] Are implications from overall system architecture (monorepo/polyrepo, backend services) considered?
## III. Detailed Frontend Directory Structure
[[LLM: The directory structure is the blueprint for code organization. Verify:
1. The ASCII diagram is clear and complete
2. Structure follows the stated patterns from Section II
3. Conventions are explicit (where do new components go?)
4. Structure supports the chosen framework's best practices
An AI agent should be able to know exactly where to place any new file based on this structure.]]
- [ ] Is an ASCII diagram representing the frontend application's folder structure provided?
- [ ] Is the diagram clear, accurate, and reflective of the chosen framework/patterns?
- [ ] Are conventions for organizing components, pages, services, state, styles, etc., highlighted?
- [ ] Are notes explaining specific conventions or rationale for the structure present and clear?
## IV. Component Breakdown & Implementation Details
[[LLM: Component specifications are crucial for consistent implementation. For this section:
1. Verify the template itself is complete with all required fields
2. Check that any example components follow the template exactly
3. Ensure naming conventions are clear and followable
4. Validate that the level of detail is sufficient for implementation
The component template should be so clear that every component built follows the same pattern.]]
### Component Naming & Organization
- [ ] Are conventions for naming components (e.g., PascalCase) described?
- [ ] Is the organization of components on the filesystem clearly explained (reiterating from directory structure if needed)?
### Template for Component Specification
- [ ] Is the "Template for Component Specification" itself complete and well-defined?
- [ ] Does it include fields for: Purpose, Source File(s), Visual Reference?
- [ ] Does it include a table structure for Props (Name, Type, Required, Default, Description)?
- [ ] Does it include a table structure for Internal State (Variable, Type, Initial Value, Description)?
- [ ] Does it include a section for Key UI Elements / Structure (textual or pseudo-HTML)?
- [ ] Does it include a section for Events Handled / Emitted?
- [ ] Does it include a section for Actions Triggered (State Management, API Calls)?
- [ ] Does it include a section for Styling Notes?
- [ ] Does it include a section for Accessibility Notes?
- [ ] Is there a clear statement that this template should be used for most feature-specific components?
### Foundational/Shared Components (if any specified upfront)
- [ ] If any foundational/shared UI components are specified, do they follow the "Template for Component Specification"?
- [ ] Is the rationale for specifying these components upfront clear?
## V. State Management In-Depth
[[LLM: State management is often where frontend apps become complex. Validate:
1. The chosen solution matches the app's needs (not over/under-engineered)
2. Store structure is clearly defined with examples
3. Patterns for async operations are specified
4. Selector patterns promote performance
5. The approach scales with application growth
Look for specific examples and templates, not just high-level descriptions.]]
- [ ] Is the chosen State Management Solution reiterated and rationale briefly provided (if not fully covered in main arch doc)?
- [ ] Are conventions for Store Structure / Slices clearly defined (e.g., location, feature-based slices)?
- [ ] If a Core Slice Example (e.g., `sessionSlice`) is provided:
- [ ] Is its purpose clear?
- [ ] Is its State Shape defined (e.g., using TypeScript interface)?
- [ ] Are its Key Reducers/Actions listed?
- [ ] Is a Feature Slice Template provided, outlining purpose, state shape, and key reducers/actions to be filled in?
- [ ] Are conventions for Key Selectors noted (e.g., use `createSelector`)?
- [ ] Are examples of Key Selectors for any core slices provided?
- [ ] Are conventions for Key Actions / Reducers / Thunks (especially async) described?
- [ ] Is an example of a Core Action/Thunk (e.g., `authenticateUser`) provided, detailing its purpose and dispatch flow?
- [ ] Is a Feature Action/Thunk Template provided for feature-specific async operations?
## VI. API Interaction Layer
[[LLM: API integration is where frontend meets backend. Verify:
1. HTTP client setup is complete with all configurations
2. Error handling is comprehensive (network, timeout, 4xx, 5xx)
3. Service definitions follow a consistent pattern
4. Authentication/authorization integration is clear
5. Retry logic doesn't create cascading failures
This section should prevent any ambiguity in how the frontend communicates with backends.]]
- [ ] Is the HTTP Client Setup detailed (e.g., Axios instance, Fetch wrapper, base URL, default headers, interceptors)?
- [ ] Are Service Definitions conventions explained?
- [ ] Is an example of a service (e.g., `userService.ts`) provided, including its purpose and example functions?
- [ ] Is Global Error Handling for API calls described (e.g., toast notifications, global error state)?
- [ ] Is guidance on Specific Error Handling within components provided?
- [ ] Is any client-side Retry Logic for API calls detailed and configured?
## VII. Routing Strategy
[[LLM: Routing defines the application's navigation structure. Check:
1. All major application routes are defined
2. Protection mechanisms are clearly specified
3. Route patterns are consistent and predictable
4. Deep linking considerations are addressed
5. Route guards integrate with authentication properly
The routing table should be comprehensive enough to understand the entire app structure.]]
- [ ] Is the chosen Routing Library stated?
- [ ] Is a table of Route Definitions provided?
- [ ] Does it include Path Pattern, Component/Page, Protection status, and Notes for each route?
- [ ] Are all key application routes listed?
- [ ] Is the Authentication Guard mechanism for protecting routes described?
- [ ] Is the Authorization Guard mechanism (if applicable for roles/permissions) described?
## VIII. Build, Bundling, and Deployment
[[LLM: Build and deployment directly impact performance and reliability. Validate:
1. Build scripts are clearly documented
2. Environment variable handling is secure and clear
3. Optimization strategies are appropriate for the app size
4. Deployment platform is compatible with the build output
5. Caching strategies won't cause stale content issues
Look for specific commands and configurations, not general statements.]]
- [ ] Are Key Build Scripts (e.g., `npm run build`) listed and their purpose explained?
- [ ] Is the handling of Environment Variables during the build process described for different environments?
- [When to Use Web vs IDE](#when-to-use-web-vs-ide)
- [Handling Major Changes](#handling-major-changes)
- [Task Management](#task-management)
- [Technical Reference](#technical-reference)
- [File Structure](#file-structure)
- [Slash Commands](#slash-commands)
- [Task System](#task-system)
- [Agile Principles in BMAD](#agile-principles-in-bmad)
- [Contributing](#contributing)
## Overview
BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework that combines AI agents with Agile development methodologies. The v4 system introduces a modular architecture with improved dependency management, bundle optimization, and support for both web and IDE environments.
### Key Features
- **Modular Agent System**: Specialized AI agents for each Agile role
- **V4 Build System**: Automated dependency resolution and optimization
- **Dual Environment Support**: Optimized for both web UIs and IDEs
- **Reusable Resources**: Portable templates, tasks, and checklists
- **Slash Command Integration**: Quick agent switching and control
## Core Philosophy
### Vibe CEO'ing
You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a singular vision. Your AI agents are your high-powered team, and your role is to:
- **Direct**: Provide clear instructions and objectives
- **Refine**: Iterate on outputs to achieve quality
- **Oversee**: Maintain strategic alignment across all agents
### Core Principles
1. **MAXIMIZE_AI_LEVERAGE**: Push the AI to deliver more. Challenge outputs and iterate.
2. **QUALITY_CONTROL**: You are the ultimate arbiter of quality. Review all outputs.
3. **STRATEGIC_OVERSIGHT**: Maintain the high-level vision and ensure alignment.
4. **ITERATIVE_REFINEMENT**: Expect to revisit steps. This is not a linear process.
5. **CLEAR_INSTRUCTIONS**: Precise requests lead to better outputs.
6. **DOCUMENTATION_IS_KEY**: Good inputs (briefs, PRDs) lead to good outputs.
7. **START_SMALL_SCALE_FAST**: Test concepts, then expand.
8. **EMBRACE_THE_CHAOS**: Adapt and overcome challenges.
## V4 Architecture
The v4 system represents a complete architectural redesign focused on modularity, portability, and optimization.
### Build System
#### Core Components
- **CLI Tool** (`tools/cli.js`): Main command-line interface
- **Dependency Resolver** (`tools/lib/dependency-resolver.js`): Resolves and validates agent dependencies
- Copy built files to use in your AI web platform of choice such as Gemini Gem's or ChatGPT custom GPT's
5. **Copy bmad-core to Your Project** (for IDE usage)
```bash
cp -r ./bmad-core /your-project-root/
```
### When Do You Need npm install?
**You DON'T need npm install if you're:**
- Using pre-built web bundles from `/web-bundles/`
- Only using IDE agents from `bmad-core/ide-agents/`
- Not modifying any agent configurations
**You DO need npm install if you're:**
- Creating or Customizing agents and teams in the `/agents/` folder
- Modifying bmad-core resources and rebuilding
- Running build commands like `npm run build`
**Important:** Building always happens in the BMAD-METHOD repository folder, not in your project. Your project only contains the `bmad-core` folder for IDE agent usage.
### Build Commands (For Custom Builds Only)
Run these commands in the BMAD-METHOD repository folder:
```bash
# Build all bundles and agents
npm run build
# Build with sample update (outputs to web-bundles too)
npm run build:sample-update
# List available agents
npm run list:agents
# Analyze dependencies
npm run analyze:deps
# Validate configurations
npm run validate
```
### IDE Agent Setup
#### For IDEs with Agent/Mode Support (Cursor, Windsurf)
1. **Using Individual IDE Agents**
- Copy content from `bmad-core/ide-agents/{agent}.ide.md`
- Create as custom agent/mode in your IDE
- Most commonly used: `sm.ide.md` and `dev.ide.md`
2. **Using Agent Switcher**
- Copy content from `bmad-core/utils/agent-switcher.ide.md`
- Create as a single agent mode
- Access all agents through slash commands
#### Slash Commands for IDE Agents
- `/agent-list` - List available agents
- `/analyst` or `/mary` - Switch to Analyst
- `/pm` or `/john` - Switch to Product Manager
- `/architect` or `/fred` - Switch to Architect
- `/exit-agent` - Return to orchestrator
## Agent Roles
### Orchestrator (BMAD)
**Purpose**: Master coordinator that can embody any specialized agent role
**Key Features**:
- Dynamic agent switching
- Access to all agent capabilities
- Handles general BMAD queries
**When to Use**:
- Initial project guidance
- When unsure which specialist is needed
- Managing agent transitions
### Business Analyst
**Name**: Mary (Web) / Larry (IDE)
**Purpose**: Research, requirements gathering, and project brief creation
**Outputs**:
- Project Brief
- Market Analysis
- Requirements Documentation
**Key Tasks**:
- Brainstorming sessions
- Deep research prompt generation
- Stakeholder analysis
### Product Manager
**Name**: John (Web) / Jack (IDE)
**Purpose**: Product planning and PRD creation
**Outputs**:
- Product Requirements Document (PRD)
- Epic definitions
- High-level user stories
**Key Tasks**:
- PRD creation and maintenance
- Product ideation
- Feature prioritization
### Architect
**Name**: Fred (Web) / Mo (IDE)
**Purpose**: System design and technical architecture
**Outputs**:
- Architecture Document
- Technical Specifications
- System Design Diagrams
**Key Tasks**:
- Architecture design
- Technology selection
- Integration planning
### UI Architect
**Name**: Jane (Web) / Millie (IDE)
**Purpose**: UI/UX and frontend architecture
**Outputs**:
- UX/UI Specification
- Frontend Architecture
- AI UI Generation Prompts
**Key Tasks**:
- UI/UX design specifications
- Frontend technical architecture
- Component library planning
### Product Owner
**Name**: Sarah (Web) / Curly (IDE)
**Purpose**: Backlog management and story refinement
**Outputs**:
- Refined User Stories
- Acceptance Criteria
- Sprint Planning
**Key Tasks**:
- Story validation
- Backlog prioritization
- Stakeholder alignment
### Scrum Master
**Name**: Bob (Web) / SallySM (IDE)
**Purpose**: Agile process facilitation and story generation
### Post-Planning Phase: Transition to Implementation
Once you have completed the planning phase and have your core documents saved in your project's `docs/` folder, you're ready to begin the implementation cycle in your IDE environment.
#### Required Documents
Before starting implementation, ensure you have these documents in your `docs/` folder:
- `prd.md` - Product Requirements Document with epics and stories
- `fullstack-architecture.md` OR both `architecture.md` and `front-end-architecture.md`
- `project-brief.md` (reference)
- `front-end-spec.md` (if applicable)
#### Step 1: Document Sharding
Large documents need to be broken down for IDE agents to work with effectively:
1. **Use BMAD Agent to Shard Documents**
```
Please shard the docs/prd.md document using the shard-doc task
```
2. **Shard Architecture Documents**
```
Please shard the docs/fullstack-architecture.md document using the shard-doc task
```
3. **Expected Folder Structure After Sharding**
```
docs/
├── prd.md # Original PRD
├── fullstack-architecture.md # Original architecture
- **Missing context**: Reference original docs in `docs/` folder
This cycle continues until all epics and stories are complete, delivering your fully implemented project according to the planned architecture and requirements.
## Best Practices
### When to Use Web vs IDE
#### Use Web UI For
- Initial planning and strategy
- Document generation (Brief, PRD, Architecture)
- Multi-agent collaboration needs
- When you need the full orchestrator
#### Use IDE For
- Story generation (SM agent)
- Development (Dev agent)
- Quick task execution
- When working with code
### Handling Major Changes
1. **Assess Impact**
- Which documents need updating?
- What's the ripple effect?
2. **Re-engage Agents**
- PM: Update PRD if scope changes
- Architect: Revise architecture if needed
- PO: Re-validate alignment
3. **Use Course Correction**
- Execute `correct-course` task
- Document changes and rationale
### Task Management
Tasks are reusable instruction sets that keep agents lean:
- **Location**: `bmad-core/tasks/`
- **Purpose**: Extract rarely-used functionality
- **Usage**: Reference or include in agent prompts
Common tasks:
- `create-prd` - PRD generation
- `shard-doc` - Document splitting
- `execute-checklist` - Run quality checks
- `create-next-story` - Story generation
## Technical Reference
### File Structure
```text
bmad-core/
├── personas/ # Agent personality definitions
├── tasks/ # Reusable instruction sets
├── templates/ # Document templates
├── checklists/ # Quality assurance tools
├── data/ # Knowledge bases and preferences
└── ide-agents/ # Standalone IDE agent files
agents/ # Individual agent YAML configurations
agent-teams/ # Team bundle configurations (team-*.yml)
tools/ # Build tooling and scripts
dist/ # Build output
```
### Slash Commands
#### Orchestrator Commands
- `/help` - Get help
- `/agent-list` - List available agents
- `/{agent-id}` - Switch to agent (e.g., `/pm`)
- `/{agent-name}` - Switch by name (e.g., `/john`)
- `/exit-agent` - Return to orchestrator
- `/party-mode` - Group chat with all agents
- `/yolo` - Toggle YOLO mode
#### IDE Agent Commands (with \* prefix)
- `*help` - Agent-specific help
- `*create` - Create relevant artifact
- `*list-templates` - Show available templates
- Agent-specific commands (e.g., `*create-prd`)
### Task System
Tasks provide on-demand functionality:
1. **Reduce Agent Size**: Keep core agents under 6K characters
2. **Modular Capabilities**: Add features as needed
3. **Reusability**: Share across multiple agents
Example task usage:
```text
Please execute the create-prd task from bmad-core/tasks/create-prd.md
```
## Agile Principles in BMAD
### Mapping to Agile Values
1. **Individuals and Interactions**
- BMAD: Active direction of AI agents
- Focus on clear communication with agents
2. **Working Software**
- BMAD: Rapid iteration and implementation
- Stories implemented one at a time
3. **Customer Collaboration**
- BMAD: Vibe CEO as primary stakeholder
- Continuous review and refinement
4. **Responding to Change**
- BMAD: Embrace chaos and adapt
- Iterative refinement built-in
### Agile Practices in BMAD
- **Sprint Planning**: PO and SM manage stories
- **Daily Standups**: Progress tracking via agents
- **Retrospectives**: Built into iteration cycles
- **Continuous Integration**: Dev agents implement incrementally
## Contributing
### Getting Involved
1. **GitHub Discussions**: Share ideas and use cases
2. **Issue Reporting**: Check existing issues first
3. **Feature Requests**: Explain value proposition
### Pull Request Process
1. Fork the repository
2. Create feature branch
3. Follow existing conventions
4. Write clear commit messages
5. Submit PR against main branch
### License
MIT License - See LICENSE file for details
---
**Remember**: You are the Vibe CEO. Think big, iterate fast, and leverage your AI team to achieve ambitious goals!
