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

V2 Frozen

Browse Source
This commit is contained in:
Brian Madison
2025-06-04 22:16:41 -05:00
parent cffbb59941
commit f7d6a4d2b5
186 changed files with 7 additions and 16118 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
docs/CONTRIBUTING.md
View File

@@ -1,45 +0,0 @@
# Contributing to this project
Thank you for considering contributing to this project! This document outlines the process for contributing and some guidelines to follow.
Also note, we use the discussions feature in GitHub to have a community to discuss potential ideas, uses, additions and enhancements.
## Code of Conduct
By participating in this project, you agree to abide by our Code of Conduct. Please read it before participating.
## How to Contribute
### Reporting Bugs
- Check if the bug has already been reported in the Issues section
- Include detailed steps to reproduce the bug
- Include any relevant logs or screenshots
### Suggesting Features
- Check if the feature has already been suggested in the Issues section, and consider using the discussions tab in GitHub also. Explain the feature in detail and why it would be valuable.
### Pull Request Process
1. Fork the repository
2. Create a new branch (`git checkout -b feature/your-feature-name`)
3. Make your changes
4. Run any tests or linting to ensure quality
5. Commit your changes with clear, descriptive messages following our commit message convention
6. Push to your branch (`git push origin feature/your-feature-name`)
7. Open a Pull Request against the main branch
## Commit Message Convention
[Commit Convention](./docs/commit.md)
## Code Style
- Follow the existing code style and conventions
- Write clear comments for complex logic
- Ensure all tests pass before submitting
## License
By contributing to this project, you agree that your contributions will be licensed under the same license as the project.

21
docs/LICENSE
View File

@@ -1,21 +0,0 @@
MIT License
Copyright (c) 2025 Brian AKA BMad AKA Bmad Code
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

123
docs/ide-setup.md
View File

@@ -1,123 +0,0 @@
# IDE Instructions for Agent Configuration
The Uber Orchestrating BMad Agent is mainly recommended for use in Gemini Web, especially for working on the brief, PRD, high level Epics, Stories, Web Deign and Prompt Output. BUT - Everything can also be done in the IDE if desired, see the BMad Agent setup section below.
## Single Agent
Create a custom mode following the docs, and paste in any of the agents that end with .ide.md from the personas folder.
## Tasks
As cursor currently limits the total number of allowed custom modes - you can utilize tasks to handle 1 off actions you might want an agent to perform. Just drag the task into any agent chat window and ask the agent to complete the task.
## BMad Agent
The BMad Agent requires the full bmad agent folder to be at the root of your project. Set up of the orchestrator simply requires copy of the markdown content of ide-bmad-orchestrator.md the same way you would do the Single Agent.
## Setting Up Custom Modes in Cursor
To use custom agent modes - review the docs here: https://docs.cursor.com/chat/custom-modes.
- Specifically you will need to enable Custom Modes in: Settings → Features → Chat → Custom modes
- Custom Agents can be created and configured with specific tools, models, and custom prompts
- Cursor allows creating custom agents through a GUI interface
NOTE from Cursor: "We’re considering adding a .cursor/modes.json file to your project to make it easier to create and share custom modes."
## Windsurf
### Setting Up Custom Modes in Windsurf
1. **Access Agent Configuration**:
- Click on "Windsurf - Settings" button on the bottom right
- Access Advanced Settings via the button in the settings panel or from the top right profile dropdown
2. **Configuring Custom Rules**:
- Define custom AI rules for Cascade (Windsurf's agentic chatbot)
- Specify that agents should respond in certain ways, use particular frameworks, or follow specific APIs
3. **Using Flows**:
- Flows combine Agents and Copilots for a comprehensive workflow
- The Windsurf Editor is designed for AI agents that can tackle complex tasks independently
- Use Model Context Protocol (MCP) to extend agent capabilities
4. **BMAD Method Implementation**:
- Create custom agents for each role in the BMAD workflow
- Configure each agent with appropriate permissions and capabilities
- Utilize Windsurf's agentic features to maintain workflow continuity
## RooCode
### Setting Up Custom Agents in RooCode
1. **Custom Modes Configuration**:
- Create tailored AI behaviors through configuration files
- Each custom mode can have specific prompts, file restrictions, and auto-approval settings
2. **Creating BMAD Method Agents**:
- Create distinct modes for each BMAD role (Analyst, PM, Architect, Design Architect, PO, SM, Dev, etc...)
- Customize each mode with tailored prompts specific to their role
- Configure file restrictions appropriate to each role (e.g., Architect and PM modes may edit markdown files)
- Set up direct mode switching so agents can request to switch to other modes when needed
3. **Model Configuration**:
- Configure different models per mode (e.g., advanced model for architecture vs. cheaper model for daily coding tasks)
- RooCode supports multiple API providers including OpenRouter, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, and local models
4. **Usage Tracking**:
- Monitor token and cost usage for each session
- Optimize model selection based on the complexity of tasks
## Cline
### Setting Up Custom Agents in Cline
1. **Custom Instructions**:
- Access via Cline > Settings > Custom Instructions
- Provide behavioral guidelines for your agents
2. **Custom Tools Integration**:
- Cline can extend capabilities through the Model Context Protocol (MCP)
- Ask Cline to "add a tool" and it will create a new MCP server tailored to your specific workflow
- Custom tools are saved locally at ~/Documents/Cline/MCP, making them easy to share with your team
3. **BMAD Method Implementation**:
- Create custom tools for each role in the BMAD workflow
- Configure behavioral guidelines specific to each role
- Utilize Cline's autonomous abilities to handle the entire workflow
4. **Model Selection**:
- Configure Cline to use different models based on the role and task complexity
## GitHub Copilot
### Custom Agent Configuration (Coming Soon)
https://github.com/microsoft/vscode-copilot-release/issues/9452
GitHub Copilot is currently developing its Copilot Extensions system, which will allow for custom agent/mode creation:
1. **Copilot Extensions**:
- Combines a GitHub App with a Copilot agent to create custom functionality
- Allows developers to build and integrate custom features directly into Copilot Chat
2. **Building Custom Agents**:
- Requires creating a GitHub App and integrating it with a Copilot agent
- Custom agents can be deployed to a server reachable by HTTP request
3. **Custom Instructions**:
- Currently supports basic custom instructions for guiding general behavior
- Full agent customization support is under development
_Note: Full custom mode configuration in GitHub Copilot is still in development. Check GitHub's documentation for the latest updates._

BIN
docs/images/gem-setup.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 99 KiB

231
docs/instruction.md
View File

@@ -1,231 +0,0 @@
# Instructions
- [Setting up Web Agent Orchestrator](#setting-up-web-agent-orchestrator)
- [IDE Agent Setup and Usage](#ide-agent-setup-and-usage)
- [Tasks Setup and Usage](#tasks)
## Setting up Web Agent Orchestrator
The Agent Orchestrator in V3 utilizes a build script to package various agent assets (personas, tasks, templates, etc.) into a structured format, primarily for use with web-based orchestrator agents that can leverage large context windows. This process involves consolidating files from specified source directories into bundled text files and preparing a main agent prompt.
### Overview
The build process is managed by the `build-bmad-orchestrator.js` Node.js script. This script reads its configuration from `build-web-agent.cfg.js`, processes files from an asset directory, and outputs the bundled assets into a designated build directory.
Quickstart: see [this below](#running-the-build-script)
### Prerequisites
- **Node.js**: Ensure you have Node.js installed to run the build script. Python version coming soon...
### Configuration (`build-web-agent.cfg.js`)
The build process is configured via `build-web-agent.cfg.js`. Key parameters include:
- `orchestrator_agent_prompt`: Specifies the path to the main prompt file for the orchestrator agent, such as `bmad-agent/web-bmad-orchestrator-agent.md`. This file will be copied to `agent-prompt.txt` in the build directory.
- Example: `./bmad-agent/web-bmad-orchestrator-agent.md`
- `asset_root`: Defines the root directory where your agent assets are stored. The script will look for subdirectories within this path.
- Example: `./bmad-agent/` meaning it will look for folders like `personas`, `tasks` inside `bmad-agent/`)
- `build_dir`: Specifies the directory where the bundled output files and the `agent-prompt.txt` will be created.
- Example: `./bmad-agent/build/`
- `agent_cfg`: Specifies the path to the md cfg file that defines the agents the Orchestrator can embody.
- Example: `./bmad-agent/web-bmad-orchestrator-agent.cfg.md`
Paths in the configuration file (`build-web-agent.cfg.js`) are relative to the `bmad-agent` directory (where `build-web-agent.cfg.js` and the build script `build-bmad-orchestrator.js` are located).
### Asset Directory Structure
The script expects a specific structure within the `asset_root` directory:
1. **Subdirectories**: Create subdirectories directly under `asset_root` for each category of assets. Based on the `bmad-agent/` folder, these would be:
- `checklists/`
- `data/`
- `personas/`
- `tasks/`
- `templates/`
2. **Asset Files**: Place your individual asset files (e.g., `.md`, `.txt`) within these subdirectories.
- For example, persona definition files would go into `asset_root/personas/`, task files into `asset_root/tasks/`, etc.
3. **Filename Uniqueness**: Within each subdirectory, ensure that all files have unique base names (i.e., the filename without its final extension). For example, having `my-persona.md` and `my-persona.txt` in the _same_ subdirectory (e.g., `personas/`) will cause the script to halt with an error. However, `my-persona.md` and `another-persona.md` is fine.
### Running the Build Script
NOTE the build will skip any files with the `.ide.<extension>` - so you can have ide specific agents or files also that do not make sense for the web, such as `dev.ide.md` - or a specific ide `sm.ide.md`.
1. ```cmd
node build-web-agent.js
```
The script will log its progress, including discovered source directories, any issues found (like duplicate base filenames), and the output files being generated.
### Output
After running the script, the `build_dir` (e.g., `bmad-agent/build/`) will contain:
1. **Bundled Asset Files**: For each subdirectory processed in `asset_root`, a corresponding `.txt` file will be created in `build_dir`. Each file concatenates the content of all files from its source subdirectory.
- Example: Files from `asset_root/personas/` will be bundled into `build_dir/personas.txt`.
- Each original file's content within the bundle is demarcated by `==================== START: [base_filename] ====================` and `==================== END: [base_filename] ====================`.
2. **`agent-prompt.txt`**: This file is a copy of the bmad orchestrator prompt specified by `orchestrator_agent_prompt` in the configuration.
3. **`agent-config.txt**: This is the key file so the orchestrator knows what agents and tasks are configured, and how to find the specific instructions and tasks for the agent in the compiled build assets
These bundled files and the agent prompt are then ready to be used by the Agent Orchestrator.
### Gemini Gem or GPT Setup
The text in agent-prompt.txt gets entered into the window of the main custom web agent instruction set. The other files in the build folder all need to be attached as files for the Gem or GPT.
### Orchestrator Agent Configuration (e.g., `bmad-agent/web-bmad-orchestrator-agent.cfg.md`)
While `build-bmad-orchestrator.js` packages assets, the Orchestrator's core behavior, agent definitions, and personality are defined in a Markdown configuration file. An example is `bmad-agent/web-bmad-orchestrator-agent.cfg.md` (path relative to `bmad-agent/`, specified in `build-web-agent.cfg.js` via `agent_cfg`). This file is key to the Orchestrator's adaptability.
**Key Features and Configurability:**
- **Agent Definitions**: The Markdown configuration file lists specialized agents. Each agent's definition typically starts with a level 2 Markdown heading for its `Title` (e.g., `## Title: Product Manager`). Attributes are then listed:
- `Name`: (e.g., `- Name: John`) - The agent's specific name.
- `Description`: (e.g., `- Description: "Details..."`) - A brief of the agent's purpose.
- `Persona`: (e.g., `- Persona: "personas#pm"`) - A reference (e.g., to `pm` section in `personas.txt`) defining core personality and instructions.
- `Customize`: (e.g., `- Customize: "Behavior details..."`) - For specific personality traits or overrides. This field's content takes precedence over the base `Persona` if conflicts arise, as detailed in `bmad-agent/web-bmad-orchestrator-agent.md`.
`checklists`, `templates`, `data`, `tasks`: These keys introduce lists of resources the agent will have access to. Each item is a Markdown link under the respective key, for example:
For `checklists`:
```markdown
- checklists:
- [Pm Checklist](checklists#pm-checklist)
- [Another Checklist](checklists#another-one)
```
For `tasks`:
```markdown
- tasks:
- [Create Prd](tasks#create-prd)
```
These references (e.g., `checklists#pm-checklist` or `tasks#create-prd`) point to sections in bundled asset files, providing the agent with its knowledge and tools. Note: `data` is used (not `data_sources`), and `tasks` is used (not `available_tasks` from older documentation styles).
- `Operating Modes`: (e.g., `- Operating Modes:
- "Mode1"
- "Mode2"`) - Defines operational modes/phases.
- `Interaction Modes`: (e.g., `- Interaction Modes:
- "Interactive"
- "YOLO"`) - Specifies interaction styles.
**How it Works (Conceptual Flow from `orchestrator-agent.md`):**
1. The Orchestrator (initially BMad) loads and parses the Markdown agent configuration file (e.g., `web-bmad-orchestrator-agent.cfg.md`).
2. When a user request matches an agent's `title`, `name`, `description`, or `classification_label`, the Orchestrator identifies the target agent.
3. It then loads the agent's `persona` and any associated `templates`, `checklists`, `data_sources`, and `tasks` by:
- Identifying the correct bundled `.txt` file (e.g., `personas.txt` for `personas#pm`).
- Extracting the specific content block (e.g., the `pm` section from `personas.txt`).
4. The `Customize` instructions from the Markdown configuration are applied, potentially modifying the agent's behavior.
5. The Orchestrator then _becomes_ that agent, adopting its complete persona, knowledge, and operational parameters defined in the Markdown configuration and the loaded asset sections.
This system makes the Agent Orchestrator highly adaptable. You can easily define new agents, modify existing ones, tweak personalities with the `Customize` field (in the Markdown agent configuration file like `web-bmad-orchestrator-agent.cfg.md`), or change their knowledge base, main prompt, and asset paths (in `build-web-agent.cfg.js` and the corresponding asset files), then re-running the build script if asset content was changed.
## IDE Agent Setup and Usage
The IDE Agents in V3 are designed for optimal performance within IDE environments like Windsurf and Cursor, with a focus on smaller agent sizes and efficient context management.
### Standalone IDE Agents
You can use specialized standalone IDE agents, such as the `sm.ide.md` (Scrum Master) and `dev.ide.md` (Developer), for specific roles like story generation or development tasks. These, or any general IDE agent, can also directly reference and execute tasks by providing the agent with the task definition from your `docs/tasks/` folder.
### IDE Agent Orchestrator (`ide-bmad-orchestrator.md`)
A powerful alternative is the `ide-bmad-orchestrator.md`. This agent provides the flexibility of the web orchestrator—allowing a single IDE agent to embody multiple personas—but **without requiring any build step.** It dynamically loads its configuration and all associated resources.
#### How the IDE Orchestrator Works
1. **Configuration (`ide-bmad-orchestrator.cfg.md`):**
The orchestrator's behavior is primarily driven by a Markdown configuration file (e.g., `bmad-agent/ide-bmad-orchestrator.cfg.md`, the path to which is specified within the `ide-bmad-orchestrator.md` itself). This config file has two main parts:
- **Data Resolution:**
Located at the top of the config file, this section defines key-value pairs for base paths. These paths tell the orchestrator where to find different types of asset files (personas, tasks, checklists, templates, data).
```markdown
# Configuration for IDE Agents
## Data Resolution
agent-root: (project-root)/bmad-agent
checklists: (agent-root)/checklists
data: (agent-root)/data
personas: (agent-root)/personas
tasks: (agent-root)/tasks
templates: (agent-root)/templates
NOTE: All Persona references and task markdown style links assume these data resolution paths unless a specific path is given.
Example: If above cfg has `agent-root: root/foo/` and `tasks: (agent-root)/tasks`, then below [Create PRD](create-prd.md) would resolve to `root/foo/tasks/create-prd.md`
```
The `(project-root)` placeholder is typically interpreted as the root of your current workspace.
- **Agent Definitions:**
Following the `Data Resolution` section, the file lists definitions for each specialized agent the orchestrator can become. Each agent is typically introduced with a `## Title:` Markdown heading.
Key attributes for each agent include:
- `Name`: The specific name of the agent (e.g., `- Name: Larry`).
- `Customize`: A string providing specific personality traits or behavioral overrides for the agent (e.g., `- Customize: "You are a bit of a know-it-all..."`).
- `Description`: A brief summary of the agent's role and capabilities.
- `Persona`: The filename of the Markdown file containing the agent's core persona definition (e.g., `- Persona: "analyst.md"`). This file is located using the `personas:` path from the `Data Resolution` section.
- `Tasks`: A list of tasks the agent can perform. Each task is a Markdown link:
- The link text is the user-friendly task name (e.g., `[Create PRD]`).
- The link target is either a Markdown filename for an external task definition (e.g., `(create-prd.md)`), resolved using the `tasks:` path, or a special string like `(In Analyst Memory Already)` indicating the task logic is part of the persona's main definition.
Example:
```markdown
## Title: Product Owner AKA PO
- Name: Curly
- Persona: "po.md"
- Tasks:
- [Create PRD](create-prd.md)
- [Create Next Story](create-next-story-task.md)
```
2. **Operational Workflow (inside `ide-bmad-orchestrator.md`):**
- **Initialization:** Upon activation in your IDE, the `ide-bmad-orchestrator.md` first loads and parses its specified configuration file (`ide-bmad-orchestrator.cfg.md`). If this fails, it will inform you and halt.
- **Greeting & Persona Listing:** It will greet you. If your initial instruction isn't clear or if you ask, it will list the available specialist personas (by `Title`, `Name`, and `Description`) and the `Tasks` each can perform, all derived from the loaded configuration.
- **Persona Activation:** When you request a specific persona (e.g., "Become the Analyst" or "I need Larry to help with research"), the orchestrator:
- Finds the persona in its configuration.
- Loads the corresponding persona file (e.g., `analyst.md`).
- Applies any `Customize:` instructions.
- Announces the activation (e.g., "Activating Analyst (Larry)...").
- **The orchestrator then fully embodies the chosen agent.** Its original orchestrator persona becomes dormant.
- **Task Execution:** Once a persona is active, it will try to match your request to one of its configured `Tasks`.
- If the task references an external file (e.g., `create-prd.md`), that file is loaded and its instructions are followed. The active persona will use the `Data Resolution` paths from the main config to find any dependent files like templates or checklists mentioned in the task file.
- If a task is marked as "In Memory" (or similar), the active persona executes it based on its internal definition.
- **Context and Persona Switching:** The orchestrator embodies only one persona at a time. If you ask to switch to a different persona while one is active, it will typically advise starting a new chat session to maintain clear context. However, it allows an explicit "override safety protocol" command if you insist on switching personas within the same chat. This terminates the current persona and re-initializes with the new one.
#### Usage Instructions for IDE Orchestrator
1. **Set up your configuration (`ide-bmad-orchestrator.cfg.md`):**
- Ensure you have an `ide-bmad-orchestrator.cfg.md` file. You can use the one located in `bmad-agent/` as a template or starting point.
- Verify that the `Data Resolution` paths at the top correctly point to your asset folders (personas, tasks, templates, checklists, data) relative to your project structure.
- Define your desired agents with their `Title`, `Name`, `Customize` instructions, `Persona` file, and `Tasks`. Ensure the referenced persona and task files exist in the locations specified by your `Data Resolution` paths.
2. **Set up your persona and task files:**
- Create the Markdown files for each persona (e.g., `analyst.md`, `po.md`) in your `personas` directory.
- Create the Markdown files for each task (e.g., `create-prd.md`) in your `tasks` directory.
3. **Activate the Orchestrator:**
- In your IDE (e.g., Cursor), select the `ide-bmad-orchestrator.md` file/agent as your active AI assistant.
4. **Interact with the Orchestrator:**
- **Initial Interaction:**
- The orchestrator will greet you and confirm it has loaded its configuration.
- You can ask: "What agents are available?" or "List personas and tasks."
- **Activating a Persona:**
- Tell the orchestrator which persona you want: "I want to work with the Product Owner," or "Activate Curly," or "Become the PO."
- **Performing a Task:**
- Once a persona is active, state the task: "Create a PRD," or if the persona is "Curly" (the PO), you might say "Curly, create the next story."
- You can also combine persona activation and task request: "Curly, I need you to create a PRD."
- **Switching Personas:**
- If you need to switch: "I need to talk to the Architect now."
- The orchestrator will advise a new chat. If you want to switch in the current chat, you'll need to give an explicit override command when prompted (e.g., "Override safety protocol and switch to Architect").
- **Follow Persona Instructions:** Once a persona is active, it will guide you based on its definition and the task it's performing. Remember that resource files like templates or checklists referenced by a task will be resolved using the global `Data Resolution` paths in the `ide-bmad-orchestrator.cfg.md`.
This setup allows for a highly flexible and dynamically configured multi-persona agent directly within your IDE, streamlining various development and project management workflows.
## Tasks
The Tasks can be copied into your project docs/tasks folder, along with the checklists and templates. The tasks are meant to reduce the amount of 1 off IDE agents - you can just drop a task into chat with any agent and it will perform the 1 off task. There will be full workflow + task coming post V3 that will expand on this - but tasks and workflows are a powerful concept that will allow us to build in a lot of capabilities for our agents, without having to bloat their overall programming and context in the IDE - especially useful for tasks that are not used frequently - similar to seldom used ide rules files.

68
docs/readme.md
View File

@@ -1,68 +0,0 @@
# Expanded Documentation
If you got here and did not set up the web agent yet already - highlight suggest doing that and talking to the web agent, much easier than reading these yawn inducing docs.
## IDE Project Quickstart
After you clone the project to your local machine, you can copy the `bmad-agent` folder to your project root. This will put the templates, checklists, and other assets the local agents will need to use the agents from your IDE instead of the Web Agent. Minimally to build your project you will want the sm.ide.md and dev.ide.md so you can draft and build your project incrementally.
Here are the more [Setup and Usage Instructions](./instruction.md) for IDE, WEB and Task setup.
Starting with the latest version of the BMad Agents for the BMad Method is very easy - all you need to do is copy `bmad-agent` folder to your project. The dedicated dev and sm that existing in previous versions are still available and are in the `bmad-agent/personas` folder with the .ide.md extension. Copy and paste the contents into your specific IDE's method of configuring a custom agent mode. The dev and sm both are configured for architecture and prd artifacts to be in (project-root)/docs and stories will be generated and developed in/from your (project-root)/docs/stories.
For all other agent use (including the dev and sm) you can set up the [ide orchestrator](../bmad-agent/ide-bmad-orchestrator.md) - you can ask the orchestrator bmad to become any agent you have [configured](../bmad-agent/ide-bmad-orchestrator.cfg.md).
[General IDE Custom Mode Setup](../docs/ide-setup.md).
## Advancing AI-Driven Development
Welcome to the latest and most advanced yet easy to use version of the Web and IDE Agent Agile Workflow! This new version, called BMad Agent version V3, represents a significant evolution that builds upon previous versions.
## What's New?
All IDE Agents are now optimized to be under 6K characters, so they will work with windsurf's file limit restrictions.
The method now has an uber Orchestrator called BMAD - this agent will take your web or ide usage to the next level - this agent can morph and become the specific agent you want to work with! This makes Web usage super easy to use and set up. And in the IDE - you do not have to set up so many different agents if you do not want to!
There have been drastic improvements to the generation of documents and artifacts and the agents are now programmed to really help you build the best possible plans. Advanced LLM prompting techniques have been incorporated and programmed to help you help the agents produce amazing accurate artifacts, unlike anything seen before. Additionally agents are now configurable in what they can and cannot do - so you can accept the defaults, or set which personas are able to do what tasks. If you think the PO should be the one generating PRDs and the Scrum Master should be your course corrector - its all possible now! **Define agile the BMad way - or your way!**
While this is very powerful - you can get started with the default recommended set up as is in this repo, and basically use the agents as they are envisioned and will be explained. Detailed configuration and usage is outlined in the [Instructions](./instruction.md)
## What is the BMad Method?
The BMad Method is a revolutionary approach that elevates "vibe coding" to advanced project planning to ensure your developer agents can start and completed advanced projects with very explicit guidance. It provides a structured yet flexible framework to plan, execute, and manage software projects using a team of specialized AI agents.
This method and tooling is so much more than just a task runner - this is a refined tool that will help you bring out your best ideas, define what you really are to build, and execute on it! From ideation, to PRD creation, to the technical decision making - this will help you do it all with the power of advanced LLM guidance.
The method is designed to be tool-agnostic in principle, with agent instructions and workflows adaptable to various AI platforms and IDEs.
## Agile Agents
Agents are programmed either directly self contained to drop right into an agent config in the ide - or they can be configured as programmable entities the orchestrating agent can become.
### Web Agents
Gemini 2.5 or Open AI customGPTs are created by running the node build script to generate output to a build folder. This output is the full package to create the orchestrator web agent.
See the detailed [Web Orchestration Setup and Usage Instructions](./instruction.md#setting-up-web-agent-orchestrator)
### IDE Agents
There are dedicated self contained agents that are stand alone, and also an IDE version of an orchestrator. For there standalone, there are:
- [Dev IDE Agent](../bmad-agent/personas/dev.ide.md)
- [Story Generating SM Agent](../bmad-agent/personas/sm.ide.md)
If you want to use the other agents, you can use the other agents from that folder - but some will be larger than Windsurf allows - and there are many agents. So its recommended to either use 1 off tasks - OR even better - use the IDE Orchestrator Agent. See these [set up and Usage instructions for IDE Orchestrator](./instruction.md#ide-agent-setup-and-usage).
## Tasks
Located in `bmad-agent/tasks/`, these self-contained instruction sets allow IDE agents or the orchestrators configured agents to perform specific jobs. These also can be used as one off commands with a vanilla agent in the ide by just referencing the task and asking the agent to perform it.
**Purpose:**
- **Reduce Agent Bloat:** Avoid adding rarely used instructions to primary agents.
- **On-Demand Functionality:** Instruct any capable IDE agent to execute a task by providing the task file content.
- **Versatility:** Handles specific functions like running checklists, creating stories, sharding documents, indexing libraries, etc.
Think of tasks as specialized mini-agents callable by your main IDE agents.

19
docs/recommended-ide-plugins.md
View File

@@ -1,19 +0,0 @@
# Recommended plugins for VSCode/Windsurf/Cursor
These are plugins that I use (mostly as a typescript developer) but not exhaustive:
- Cline
- Code Spell Checker
- CodeMetrics
- Docker
- ESLint
- Foam (video about this one soon)
- Jest Runner (firstris)
- Markdown Preview Mermaid Support
- Monokai Charcoal high contrast (love these themes!)
- Playwright Test for VSCode (if using Playwright for e2e)
- Prettier - Code formatter
- Prettier - ESLint
- SQLite
I also use plugins when using GoLang, Python, and C#

71
docs/templates/api-reference.md vendored Normal file
View File

@@ -0,0 +1,71 @@
# {Project Name} API Reference
## External APIs Consumed
{Repeat this section for each external API the system interacts with.}
### {External Service Name} API
- **Purpose:** {Why does the system use this API?}
- **Base URL(s):**
- Production: `{URL}`
- Staging/Dev: `{URL}`
- **Authentication:** {Describe method - e.g., API Key in Header (Header Name: `X-API-Key`), OAuth 2.0 Client Credentials, Basic Auth. Reference `docs/environment-vars.md` for key names.}
- **Key Endpoints Used:**
- **`{HTTP Method} {/path/to/endpoint}`:**
- Description: {What does this endpoint do?}
- Request Parameters: {Query params, path params}
- Request Body Schema: {Provide JSON schema or link to `docs/data-models.md`}
- Example Request: `{Code block}`
- Success Response Schema (Code: `200 OK`): {JSON schema or link}
- Error Response Schema(s) (Codes: `4xx`, `5xx`): {JSON schema or link}
- Example Response: `{Code block}`
- **`{HTTP Method} {/another/endpoint}`:** {...}
- **Rate Limits:** {If known}
- **Link to Official Docs:** {URL}
### {Another External Service Name} API
{...}
## Internal APIs Provided (If Applicable)
{If the system exposes its own APIs (e.g., in a microservices architecture or for a UI frontend). Repeat for each API.}
### {Internal API / Service Name} API
- **Purpose:** {What service does this API provide?}
- **Base URL(s):** {e.g., `/api/v1/...`}
- **Authentication/Authorization:** {Describe how access is controlled.}
- **Endpoints:**
- **`{HTTP Method} {/path/to/endpoint}`:**
- Description: {What does this endpoint do?}
- Request Parameters: {...}
- Request Body Schema: {...}
- Success Response Schema (Code: `200 OK`): {...}
- Error Response Schema(s) (Codes: `4xx`, `5xx`): {...}
- **`{HTTP Method} {/another/endpoint}`:** {...}
## AWS Service SDK Usage (or other Cloud Providers)
{Detail interactions with cloud provider services via SDKs.}
### {AWS Service Name, e.g., S3}
- **Purpose:** {Why is this service used?}
- **SDK Package:** {e.g., `@aws-sdk/client-s3`}
- **Key Operations Used:** {e.g., `GetObjectCommand`, `PutObjectCommand`}
- Operation 1: {Brief description of usage context}
- Operation 2: {...}
- **Key Resource Identifiers:** {e.g., Bucket names, Table names - reference `docs/environment-vars.md`}
### {Another AWS Service Name, e.g., SES}
{...}
## 5. Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft | {Agent/Person} |
| ... | ... | ... | ... | ... |

259
docs/templates/architect-checklist.md vendored Normal file
View File

@@ -0,0 +1,259 @@
# Architect Solution Validation Checklist
This checklist serves as a comprehensive framework for the Architect to validate the technical design and architecture before development execution. The Architect should systematically work through each item, ensuring the architecture is robust, scalable, secure, and aligned with the product requirements.
## 1. REQUIREMENTS ALIGNMENT
### 1.1 Functional Requirements Coverage
- [ ] Architecture supports all functional requirements in the PRD
- [ ] Technical approaches for all epics and stories are addressed
- [ ] Edge cases and performance scenarios are considered
- [ ] All required integrations are accounted for
- [ ] User journeys are supported by the technical architecture
### 1.2 Non-Functional Requirements Alignment
- [ ] Performance requirements are addressed with specific solutions
- [ ] Scalability considerations are documented with approach
- [ ] Security requirements have corresponding technical controls
- [ ] Reliability and resilience approaches are defined
- [ ] Compliance requirements have technical implementations
### 1.3 Technical Constraints Adherence
- [ ] All technical constraints from PRD are satisfied
- [ ] Platform/language requirements are followed
- [ ] Infrastructure constraints are accommodated
- [ ] Third-party service constraints are addressed
- [ ] Organizational technical standards are followed
## 2. ARCHITECTURE FUNDAMENTALS
### 2.1 Architecture Clarity
- [ ] Architecture is documented with clear diagrams
- [ ] Major components and their responsibilities are defined
- [ ] Component interactions and dependencies are mapped
- [ ] Data flows are clearly illustrated
- [ ] Technology choices for each component are specified
### 2.2 Separation of Concerns
- [ ] Clear boundaries between UI, business logic, and data layers
- [ ] Responsibilities are cleanly divided between components
- [ ] Interfaces between components are well-defined
- [ ] Components adhere to single responsibility principle
- [ ] Cross-cutting concerns (logging, auth, etc.) are properly addressed
### 2.3 Design Patterns & Best Practices
- [ ] Appropriate design patterns are employed
- [ ] Industry best practices are followed
- [ ] Anti-patterns are avoided
- [ ] Consistent architectural style throughout
- [ ] Pattern usage is documented and explained
### 2.4 Modularity & Maintainability
- [ ] System is divided into cohesive, loosely-coupled modules
- [ ] Components can be developed and tested independently
- [ ] Changes can be localized to specific components
- [ ] Code organization promotes discoverability
- [ ] Architecture specifically designed for AI agent implementation
## 3. TECHNICAL STACK & DECISIONS
### 3.1 Technology Selection
- [ ] Selected technologies meet all requirements
- [ ] Technology versions are specifically defined (not ranges)
- [ ] Technology choices are justified with clear rationale
- [ ] Alternatives considered are documented with pros/cons
- [ ] Selected stack components work well together
### 3.2 Frontend Architecture
- [ ] UI framework and libraries are specifically selected
- [ ] State management approach is defined
- [ ] Component structure and organization is specified
- [ ] Responsive/adaptive design approach is outlined
- [ ] Build and bundling strategy is determined
### 3.3 Backend Architecture
- [ ] API design and standards are defined
- [ ] Service organization and boundaries are clear
- [ ] Authentication and authorization approach is specified
- [ ] Error handling strategy is outlined
- [ ] Backend scaling approach is defined
### 3.4 Data Architecture
- [ ] Data models are fully defined
- [ ] Database technologies are selected with justification
- [ ] Data access patterns are documented
- [ ] Data migration/seeding approach is specified
- [ ] Data backup and recovery strategies are outlined
## 4. RESILIENCE & OPERATIONAL READINESS
### 4.1 Error Handling & Resilience
- [ ] Error handling strategy is comprehensive
- [ ] Retry policies are defined where appropriate
- [ ] Circuit breakers or fallbacks are specified for critical services
- [ ] Graceful degradation approaches are defined
- [ ] System can recover from partial failures
### 4.2 Monitoring & Observability
- [ ] Logging strategy is defined
- [ ] Monitoring approach is specified
- [ ] Key metrics for system health are identified
- [ ] Alerting thresholds and strategies are outlined
- [ ] Debugging and troubleshooting capabilities are built in
### 4.3 Performance & Scaling
- [ ] Performance bottlenecks are identified and addressed
- [ ] Caching strategy is defined where appropriate
- [ ] Load balancing approach is specified
- [ ] Horizontal and vertical scaling strategies are outlined
- [ ] Resource sizing recommendations are provided
### 4.4 Deployment & DevOps
- [ ] Deployment strategy is defined
- [ ] CI/CD pipeline approach is outlined
- [ ] Environment strategy (dev, staging, prod) is specified
- [ ] Infrastructure as Code approach is defined
- [ ] Rollback and recovery procedures are outlined
## 5. SECURITY & COMPLIANCE
### 5.1 Authentication & Authorization
- [ ] Authentication mechanism is clearly defined
- [ ] Authorization model is specified
- [ ] Role-based access control is outlined if required
- [ ] Session management approach is defined
- [ ] Credential management is addressed
### 5.2 Data Security
- [ ] Data encryption approach (at rest and in transit) is specified
- [ ] Sensitive data handling procedures are defined
- [ ] Data retention and purging policies are outlined
- [ ] Backup encryption is addressed if required
- [ ] Data access audit trails are specified if required
### 5.3 API & Service Security
- [ ] API security controls are defined
- [ ] Rate limiting and throttling approaches are specified
- [ ] Input validation strategy is outlined
- [ ] CSRF/XSS prevention measures are addressed
- [ ] Secure communication protocols are specified
### 5.4 Infrastructure Security
- [ ] Network security design is outlined
- [ ] Firewall and security group configurations are specified
- [ ] Service isolation approach is defined
- [ ] Least privilege principle is applied
- [ ] Security monitoring strategy is outlined
## 6. IMPLEMENTATION GUIDANCE
### 6.1 Coding Standards & Practices
- [ ] Coding standards are defined
- [ ] Documentation requirements are specified
- [ ] Testing expectations are outlined
- [ ] Code organization principles are defined
- [ ] Naming conventions are specified
### 6.2 Testing Strategy
- [ ] Unit testing approach is defined
- [ ] Integration testing strategy is outlined
- [ ] E2E testing approach is specified
- [ ] Performance testing requirements are outlined
- [ ] Security testing approach is defined
### 6.3 Development Environment
- [ ] Local development environment setup is documented
- [ ] Required tools and configurations are specified
- [ ] Development workflows are outlined
- [ ] Source control practices are defined
- [ ] Dependency management approach is specified
### 6.4 Technical Documentation
- [ ] API documentation standards are defined
- [ ] Architecture documentation requirements are specified
- [ ] Code documentation expectations are outlined
- [ ] System diagrams and visualizations are included
- [ ] Decision records for key choices are included
## 7. DEPENDENCY & INTEGRATION MANAGEMENT
### 7.1 External Dependencies
- [ ] All external dependencies are identified
- [ ] Versioning strategy for dependencies is defined
- [ ] Fallback approaches for critical dependencies are specified
- [ ] Licensing implications are addressed
- [ ] Update and patching strategy is outlined
### 7.2 Internal Dependencies
- [ ] Component dependencies are clearly mapped
- [ ] Build order dependencies are addressed
- [ ] Shared services and utilities are identified
- [ ] Circular dependencies are eliminated
- [ ] Versioning strategy for internal components is defined
### 7.3 Third-Party Integrations
- [ ] All third-party integrations are identified
- [ ] Integration approaches are defined
- [ ] Authentication with third parties is addressed
- [ ] Error handling for integration failures is specified
- [ ] Rate limits and quotas are considered
## 8. AI AGENT IMPLEMENTATION SUITABILITY
### 8.1 Modularity for AI Agents
- [ ] Components are sized appropriately for AI agent implementation
- [ ] Dependencies between components are minimized
- [ ] Clear interfaces between components are defined
- [ ] Components have singular, well-defined responsibilities
- [ ] File and code organization optimized for AI agent understanding
### 8.2 Clarity & Predictability
- [ ] Patterns are consistent and predictable
- [ ] Complex logic is broken down into simpler steps
- [ ] Architecture avoids overly clever or obscure approaches
- [ ] Examples are provided for unfamiliar patterns
- [ ] Component responsibilities are explicit and clear
### 8.3 Implementation Guidance
- [ ] Detailed implementation guidance is provided
- [ ] Code structure templates are defined
- [ ] Specific implementation patterns are documented
- [ ] Common pitfalls are identified with solutions
- [ ] References to similar implementations are provided when helpful
### 8.4 Error Prevention & Handling
- [ ] Design reduces opportunities for implementation errors
- [ ] Validation and error checking approaches are defined
- [ ] Self-healing mechanisms are incorporated where possible
- [ ] Testing patterns are clearly defined
- [ ] Debugging guidance is provided

69
docs/templates/architecture.md vendored Normal file
View File

@@ -0,0 +1,69 @@
# {Project Name} Architecture Document
## Technical Summary
{Provide a brief (1-2 paragraph) overview of the system's architecture, key components, technology choices, and architectural patterns used. Reference the goals from the PRD.}
## High-Level Overview
{Describe the main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven). Explain the primary user interaction or data flow at a conceptual level.}
```mermaid
{Insert high-level system context or interaction diagram here - e.g., using Mermaid graph TD or C4 Model Context Diagram}
```
## Component View
{Describe the major logical components or services of the system and their responsibilities. Explain how they collaborate.}
```mermaid
{Insert component diagram here - e.g., using Mermaid graph TD or C4 Model Container/Component Diagram}
```
- Component A: {Description of responsibility}
- Component B: {Description of responsibility}
- {src/ Directory (if applicable): The application code in src/ is organized into logical modules... (briefly describe key subdirectories like clients, core, services, etc., referencing docs/project-structure.md for the full layout)}
## Key Architectural Decisions & Patterns
{List significant architectural choices and the patterns employed.}
- Pattern/Decision 1: {e.g., Choice of Database, Message Queue Usage, Authentication Strategy, API Design Style (REST/GraphQL)} - Justification: {...}
- Pattern/Decision 2: {...} - Justification: {...}
- (See docs/coding-standards.md for detailed coding patterns and error handling)
## Core Workflow / Sequence Diagrams (Optional)
{Illustrate key or complex workflows using sequence diagrams if helpful.}
## Infrastructure and Deployment Overview
- Cloud Provider(s): {e.g., AWS, Azure, GCP, On-premise}
- Core Services Used: {List key managed services - e.g., Lambda, S3, Kubernetes Engine, RDS, Kafka}
- Infrastructure as Code (IaC): {Tool used - e.g., AWS CDK, Terraform, Pulumi, ARM Templates} - Location: {Link to IaC code repo/directory}
- Deployment Strategy: {e.g., CI/CD pipeline, Manual deployment steps, Blue/Green, Canary} - Tools: {e.g., Jenkins, GitHub Actions, GitLab CI}
- Environments: {List environments - e.g., Development, Staging, Production}
- (See docs/environment-vars.md for configuration details)
## Key Reference Documents
{Link to other relevant documents in the docs/ folder.}
- docs/prd.md
- docs/epicN.md files
- docs/tech-stack.md
- docs/project-structure.md
- docs/coding-standards.md
- docs/api-reference.md
- docs/data-models.md
- docs/environment-vars.md
- docs/testing-strategy.md
- docs/ui-ux-spec.md (if applicable)
- ... (other relevant docs)
## Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ---------------------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft based on brief | {Agent/Person} |
| ... | ... | ... | ... | ... |

56
docs/templates/coding-standards.md vendored Normal file
View File

@@ -0,0 +1,56 @@
# {Project Name} Coding Standards and Patterns
## Architectural / Design Patterns Adopted
{List the key high-level patterns chosen in the architecture document.}
- **Pattern 1:** {e.g., Serverless, Event-Driven, Microservices, CQRS} - _Rationale/Reference:_ {Briefly why, or link to `docs/architecture.md` section}
- **Pattern 2:** {e.g., Dependency Injection, Repository Pattern, Module Pattern} - _Rationale/Reference:_ {...}
- **Pattern N:** {...}
## Coding Standards (Consider adding these to Dev Agent Context or Rules)
- **Primary Language(s):** {e.g., TypeScript 5.x, Python 3.11, Go 1.2x}
- **Primary Runtime(s):** {e.g., Node.js 22.x, Python Runtime for Lambda}
- **Style Guide & Linter:** {e.g., ESLint with Airbnb config, Prettier; Black, Flake8; Go fmt} - _Configuration:_ {Link to config files or describe setup}
- **Naming Conventions:**
- Variables: `{e.g., camelCase}`
- Functions: `{e.g., camelCase}`
- Classes/Types/Interfaces: `{e.g., PascalCase}`
- Constants: `{e.g., UPPER_SNAKE_CASE}`
- Files: `{e.g., kebab-case.ts, snake_case.py}`
- **File Structure:** Adhere to the layout defined in `docs/project-structure.md`.
- **Asynchronous Operations:** {e.g., Use `async`/`await` in TypeScript/Python, Goroutines/Channels in Go.}
- **Type Safety:** {e.g., Leverage TypeScript strict mode, Python type hints, Go static typing.} - _Type Definitions:_ {Location, e.g., `src/common/types.ts`}
- **Comments & Documentation:** {Expectations for code comments, docstrings, READMEs.}
- **Dependency Management:** {Tool used - e.g., npm, pip, Go modules. Policy on adding dependencies.}
## Error Handling Strategy
- **General Approach:** {e.g., Use exceptions, return error codes/tuples, specific error types.}
- **Logging:**
- Library/Method: {e.g., `console.log/error`, Python `logging` module, dedicated logging library}
- Format: {e.g., JSON, plain text}
- Levels: {e.g., DEBUG, INFO, WARN, ERROR}
- Context: {What contextual information should be included?}
- **Specific Handling Patterns:**
- External API Calls: {e.g., Use `try/catch`, check response codes, implement retries with backoff for transient errors?}
- Input Validation: {Where and how is input validated?}
- Graceful Degradation vs. Critical Failure: {Define criteria for when to continue vs. halt.}
## Security Best Practices
{Outline key security considerations relevant to the codebase.}
- Input Sanitization/Validation: {...}
- Secrets Management: {How are secrets handled in code? Reference `docs/environment-vars.md` regarding storage.}
- Dependency Security: {Policy on checking for vulnerable dependencies.}
- Authentication/Authorization Checks: {Where should these be enforced?}
- {Other relevant practices...}
## Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft | {Agent/Person} |
| ... | ... | ... | ... | ... |

101
docs/templates/data-models.md vendored Normal file
View File

@@ -0,0 +1,101 @@
# {Project Name} Data Models
## 2. Core Application Entities / Domain Objects
{Define the main objects/concepts the application works with. Repeat subsection for each key entity.}
### {Entity Name, e.g., User, Order, Product}
- **Description:** {What does this entity represent?}
- **Schema / Interface Definition:**
```typescript
// Example using TypeScript Interface
export interface {EntityName} {
id: string; // {Description, e.g., Unique identifier}
propertyName: string; // {Description}
optionalProperty?: number; // {Description}
// ... other properties
}
```
_(Alternatively, use JSON Schema, class definitions, or other relevant format)_
- **Validation Rules:** {List any specific validation rules beyond basic types - e.g., max length, format, range.}
### {Another Entity Name}
{...}
## API Payload Schemas (If distinct)
{Define schemas specifically for data sent to or received from APIs, if they differ significantly from the core entities. Reference `docs/api-reference.md`.}
### {API Endpoint / Purpose, e.g., Create Order Request}
- **Schema / Interface Definition:**
```typescript
// Example
export interface CreateOrderRequest {
customerId: string;
items: { productId: string; quantity: number }[];
// ...
}
```
### {Another API Payload}
{...}
## Database Schemas (If applicable)
{If using a database, define table structures or document database schemas.}
### {Table / Collection Name}
- **Purpose:** {What data does this table store?}
- **Schema Definition:**
```sql
-- Example SQL
CREATE TABLE {TableName} (
id VARCHAR(36) PRIMARY KEY,
column_name VARCHAR(255) NOT NULL,
numeric_column DECIMAL(10, 2),
-- ... other columns, indexes, constraints
);
```
_(Alternatively, use ORM model definitions, NoSQL document structure, etc.)_
### {Another Table / Collection Name}
{...}
## State File Schemas (If applicable)
{If the application uses files for persisting state.}
### {State File Name / Purpose, e.g., processed_items.json}
- **Purpose:** {What state does this file track?}
- **Format:** {e.g., JSON}
- **Schema Definition:**
```json
{
"type": "object",
"properties": {
"processedIds": {
"type": "array",
"items": {
"type": "string"
},
"description": "List of IDs that have been processed."
}
// ... other state properties
},
"required": ["processedIds"]
}
```
## Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft | {Agent/Person} |
| ... | ... | ... | ... | ... |

1
docs/templates/deep-research-report-BA.md vendored Normal file
View File

@@ -0,0 +1 @@
{replace with relevant report}

1
docs/templates/deep-research-report-architecture.md vendored Normal file
View File

@@ -0,0 +1 @@
{replace with relevant report}

1
docs/templates/deep-research-report-prd.md vendored Normal file
View File

@@ -0,0 +1 @@
{replace with relevant report}

36
docs/templates/environment-vars.md vendored Normal file
View File

@@ -0,0 +1,36 @@
# {Project Name} Environment Variables
## Configuration Loading Mechanism
{Describe how environment variables are loaded into the application.}
- **Local Development:** {e.g., Using `.env` file with `dotenv` library.}
- **Deployment (e.g., AWS Lambda, Kubernetes):** {e.g., Set via Lambda function configuration, Kubernetes Secrets/ConfigMaps.}
## Required Variables
{List all environment variables used by the application.}
| Variable Name | Description | Example / Default Value | Required? (Yes/No) | Sensitive? (Yes/No) |
| :------------------- | :---------------------------------------------- | :------------------------------------ | :----------------- | :------------------ |
| `NODE_ENV` | Runtime environment | `development` / `production` | Yes | No |
| `PORT` | Port the application listens on (if applicable) | `8080` | No | No |
| `DATABASE_URL` | Connection string for the primary database | `postgresql://user:pass@host:port/db` | Yes | Yes |
| `EXTERNAL_API_KEY` | API Key for {External Service Name} | `sk_...` | Yes | Yes |
| `S3_BUCKET_NAME` | Name of the S3 bucket for {Purpose} | `my-app-data-bucket-...` | Yes | No |
| `FEATURE_FLAG_X` | Enables/disables experimental feature X | `false` | No | No |
| `{ANOTHER_VARIABLE}` | {Description} | {Example} | {Yes/No} | {Yes/No} |
| ... | ... | ... | ... | ... |
## Notes
- **Secrets Management:** {Explain how sensitive variables (API Keys, passwords) should be handled, especially in production (e.g., "Use AWS Secrets Manager", "Inject via CI/CD pipeline").}
- **`.env.example`:** {Mention that an `.env.example` file should be maintained in the repository with placeholder values for developers.}
- **Validation:** {Is there code that validates the presence or format of these variables at startup?}
## Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft | {Agent/Person} |
| ... | ... | ... | ... | ... |

63
docs/templates/epicN.md vendored Normal file
View File

@@ -0,0 +1,63 @@
# Epic {N}: {Epic Title}
**Goal:** {State the overall goal this epic aims to achieve, linking back to the PRD goals.}
**Deployability:** {Explain how this epic builds on previous epics and what makes it independently deployable. For Epic 1, describe how it establishes the foundation for future epics.}
## Epic-Specific Technical Context
{For Epic 1, include necessary setup requirements such as project scaffolding, infrastructure setup, third-party accounts, or other prerequisites. For subsequent epics, describe any new technical components being introduced and how they build upon the foundation established in earlier epics.}
## Local Testability & Command-Line Access
{If the user has indicated this is important, describe how the functionality in this epic can be tested locally and/or through command-line tools. Include:}
- **Local Development:** {How can developers run and test this functionality in their local environment?}
- **Command-Line Testing:** {What utility scripts or commands should be provided for testing the functionality?}
- **Environment Testing:** {How can the functionality be tested across different environments (local, dev, staging, production)?}
- **Testing Prerequisites:** {What needs to be set up or available to enable effective testing?}
{If this section is not applicable based on user preferences, you may remove it.}
## Story List
{List all stories within this epic. Repeat the structure below for each story.}
### Story {N}.{M}: {Story Title}
- **User Story / Goal:** {Describe the story goal, ideally in "As a [role], I want [action], so that [benefit]" format, or clearly state the technical goal.}
- **Detailed Requirements:**
- {Bulleted list explaining the specific functionalities, behaviors, or tasks required for this story.}
- {Reference other documents for context if needed, e.g., "Handle data according to `docs/data-models.md#EntityName`".}
- {Include any technical constraints or details identified during refinement - added by Architect/PM/Tech SM.}
- **Acceptance Criteria (ACs):**
- AC1: {Specific, verifiable condition that must be met.}
- AC2: {Another verifiable condition.}
- ACN: {...}
- **Tasks (Optional Initial Breakdown):**
- [ ] {High-level task 1}
- [ ] {High-level task 2}
- **Dependencies:** {List any dependencies on other stories or epics. Note if this story builds on functionality from previous epics.}
---
### Story {N}.{M+1}: {Story Title}
- **User Story / Goal:** {...}
- **Detailed Requirements:**
- {...}
- **Acceptance Criteria (ACs):**
- AC1: {...}
- AC2: {...}
- **Tasks (Optional Initial Breakdown):**
- [ ] {...}
- **Dependencies:** {List dependencies, if any}
---
{... Add more stories ...}
## Change Log
| Change | Date | Version | Description | Author |
| ------ | ---- | ------- | ----------- | ------ |

266
docs/templates/pm-checklist.md vendored Normal file
View File

@@ -0,0 +1,266 @@
# Product Manager (PM) Requirements Checklist
This checklist serves as a comprehensive framework to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development. The PM should systematically work through each item during the product definition process.
## 1. PROBLEM DEFINITION & CONTEXT
### 1.1 Problem Statement
- [ ] Clear articulation of the problem being solved
- [ ] Identification of who experiences the problem
- [ ] Explanation of why solving this problem matters
- [ ] Quantification of problem impact (if possible)
- [ ] Differentiation from existing solutions
### 1.2 Business Goals & Success Metrics
- [ ] Specific, measurable business objectives defined
- [ ] Clear success metrics and KPIs established
- [ ] Metrics are tied to user and business value
- [ ] Baseline measurements identified (if applicable)
- [ ] Timeframe for achieving goals specified
### 1.3 User Research & Insights
- [ ] Target user personas clearly defined
- [ ] User needs and pain points documented
- [ ] User research findings summarized (if available)
- [ ] Competitive analysis included
- [ ] Market context provided
## 2. MVP SCOPE DEFINITION
### 2.1 Core Functionality
- [ ] Essential features clearly distinguished from nice-to-haves
- [ ] Features directly address defined problem statement
- [ ] Each feature ties back to specific user needs
- [ ] Features are described from user perspective
- [ ] Minimum requirements for success defined
### 2.2 Scope Boundaries
- [ ] Clear articulation of what is OUT of scope
- [ ] Future enhancements section included
- [ ] Rationale for scope decisions documented
- [ ] MVP minimizes functionality while maximizing learning
- [ ] Scope has been reviewed and refined multiple times
### 2.3 MVP Validation Approach
- [ ] Method for testing MVP success defined
- [ ] Initial user feedback mechanisms planned
- [ ] Criteria for moving beyond MVP specified
- [ ] Learning goals for MVP articulated
- [ ] Timeline expectations set
## 3. USER EXPERIENCE REQUIREMENTS
### 3.1 User Journeys & Flows
- [ ] Primary user flows documented
- [ ] Entry and exit points for each flow identified
- [ ] Decision points and branches mapped
- [ ] Critical path highlighted
- [ ] Edge cases considered
### 3.2 Usability Requirements
- [ ] Accessibility considerations documented
- [ ] Platform/device compatibility specified
- [ ] Performance expectations from user perspective defined
- [ ] Error handling and recovery approaches outlined
- [ ] User feedback mechanisms identified
### 3.3 UI Requirements
- [ ] Information architecture outlined
- [ ] Critical UI components identified
- [ ] Visual design guidelines referenced (if applicable)
- [ ] Content requirements specified
- [ ] High-level navigation structure defined
## 4. FUNCTIONAL REQUIREMENTS
### 4.1 Feature Completeness
- [ ] All required features for MVP documented
- [ ] Features have clear, user-focused descriptions
- [ ] Feature priority/criticality indicated
- [ ] Requirements are testable and verifiable
- [ ] Dependencies between features identified
### 4.2 Requirements Quality
- [ ] Requirements are specific and unambiguous
- [ ] Requirements focus on WHAT not HOW
- [ ] Requirements use consistent terminology
- [ ] Complex requirements broken into simpler parts
- [ ] Technical jargon minimized or explained
### 4.3 User Stories & Acceptance Criteria
- [ ] Stories follow consistent format
- [ ] Acceptance criteria are testable
- [ ] Stories are sized appropriately (not too large)
- [ ] Stories are independent where possible
- [ ] Stories include necessary context
## 5. NON-FUNCTIONAL REQUIREMENTS
### 5.1 Performance Requirements
- [ ] Response time expectations defined
- [ ] Throughput/capacity requirements specified
- [ ] Scalability needs documented
- [ ] Resource utilization constraints identified
- [ ] Load handling expectations set
### 5.2 Security & Compliance
- [ ] Data protection requirements specified
- [ ] Authentication/authorization needs defined
- [ ] Compliance requirements documented
- [ ] Security testing requirements outlined
- [ ] Privacy considerations addressed
### 5.3 Reliability & Resilience
- [ ] Availability requirements defined
- [ ] Backup and recovery needs documented
- [ ] Fault tolerance expectations set
- [ ] Error handling requirements specified
- [ ] Maintenance and support considerations included
### 5.4 Technical Constraints
- [ ] Platform/technology constraints documented
- [ ] Integration requirements outlined
- [ ] Third-party service dependencies identified
- [ ] Infrastructure requirements specified
- [ ] Development environment needs identified
## 6. EPIC & STORY STRUCTURE
### 6.1 Epic Definition
- [ ] Epics represent cohesive units of functionality
- [ ] Epics focus on user/business value delivery
- [ ] Epic goals clearly articulated
- [ ] Epics are sized appropriately for incremental delivery
- [ ] Epic sequence and dependencies identified
### 6.2 Story Breakdown
- [ ] Stories are broken down to appropriate size
- [ ] Stories have clear, independent value
- [ ] Stories include appropriate acceptance criteria
- [ ] Story dependencies and sequence documented
- [ ] Stories aligned with epic goals
### 6.3 First Epic Completeness
- [ ] First epic includes all necessary setup steps
- [ ] Project scaffolding and initialization addressed
- [ ] Core infrastructure setup included
- [ ] Development environment setup addressed
- [ ] Local testability established early
## 7. TECHNICAL GUIDANCE
### 7.1 Architecture Guidance
- [ ] Initial architecture direction provided
- [ ] Technical constraints clearly communicated
- [ ] Integration points identified
- [ ] Performance considerations highlighted
- [ ] Security requirements articulated
### 7.2 Technical Decision Framework
- [ ] Decision criteria for technical choices provided
- [ ] Trade-offs articulated for key decisions
- [ ] Non-negotiable technical requirements highlighted
- [ ] Areas requiring technical investigation identified
- [ ] Guidance on technical debt approach provided
### 7.3 Implementation Considerations
- [ ] Development approach guidance provided
- [ ] Testing requirements articulated
- [ ] Deployment expectations set
- [ ] Monitoring needs identified
- [ ] Documentation requirements specified
## 8. CROSS-FUNCTIONAL REQUIREMENTS
### 8.1 Data Requirements
- [ ] Data entities and relationships identified
- [ ] Data storage requirements specified
- [ ] Data quality requirements defined
- [ ] Data retention policies identified
- [ ] Data migration needs addressed (if applicable)
### 8.2 Integration Requirements
- [ ] External system integrations identified
- [ ] API requirements documented
- [ ] Authentication for integrations specified
- [ ] Data exchange formats defined
- [ ] Integration testing requirements outlined
### 8.3 Operational Requirements
- [ ] Deployment frequency expectations set
- [ ] Environment requirements defined
- [ ] Monitoring and alerting needs identified
- [ ] Support requirements documented
- [ ] Performance monitoring approach specified
## 9. CLARITY & COMMUNICATION
### 9.1 Documentation Quality
- [ ] Documents use clear, consistent language
- [ ] Documents are well-structured and organized
- [ ] Technical terms are defined where necessary
- [ ] Diagrams/visuals included where helpful
- [ ] Documentation is versioned appropriately
### 9.2 Stakeholder Alignment
- [ ] Key stakeholders identified
- [ ] Stakeholder input incorporated
- [ ] Potential areas of disagreement addressed
- [ ] Communication plan for updates established
- [ ] Approval process defined
## PRD & EPIC VALIDATION SUMMARY
### Category Statuses
| Category | Status | Critical Issues |
| -------------------------------- | ----------------- | --------------- |
| 1. Problem Definition & Context | PASS/FAIL/PARTIAL | |
| 2. MVP Scope Definition | PASS/FAIL/PARTIAL | |
| 3. User Experience Requirements | PASS/FAIL/PARTIAL | |
| 4. Functional Requirements | PASS/FAIL/PARTIAL | |
| 5. Non-Functional Requirements | PASS/FAIL/PARTIAL | |
| 6. Epic & Story Structure | PASS/FAIL/PARTIAL | |
| 7. Technical Guidance | PASS/FAIL/PARTIAL | |
| 8. Cross-Functional Requirements | PASS/FAIL/PARTIAL | |
| 9. Clarity & Communication | PASS/FAIL/PARTIAL | |
### Critical Deficiencies
- List all critical issues that must be addressed before handoff to Architect
### Recommendations
- Provide specific recommendations for addressing each deficiency
### Final Decision
- **READY FOR ARCHITECT**: The PRD and epics are comprehensive, properly structured, and ready for architectural design.
- **NEEDS REFINEMENT**: The requirements documentation requires additional work to address the identified deficiencies.

229
docs/templates/po-checklist.md vendored Normal file
View File

@@ -0,0 +1,229 @@
# Product Owner (PO) Validation Checklist
This checklist serves as a comprehensive framework for the Product Owner to validate the complete MVP plan before development execution. The PO should systematically work through each item, documenting compliance status and noting any deficiencies.
## 1. PROJECT SETUP & INITIALIZATION
### 1.1 Project Scaffolding
- [ ] Epic 1 includes explicit steps for project creation/initialization
- [ ] If using a starter template, steps for cloning/setup are included
- [ ] If building from scratch, all necessary scaffolding steps are defined
- [ ] Initial README or documentation setup is included
- [ ] Repository setup and initial commit processes are defined (if applicable)
### 1.2 Development Environment
- [ ] Local development environment setup is clearly defined
- [ ] Required tools and versions are specified (Node.js, Python, etc.)
- [ ] Steps for installing dependencies are included
- [ ] Configuration files (dotenv, config files, etc.) are addressed
- [ ] Development server setup is included
### 1.3 Core Dependencies
- [ ] All critical packages/libraries are installed early in the process
- [ ] Package management (npm, pip, etc.) is properly addressed
- [ ] Version specifications are appropriately defined
- [ ] Dependency conflicts or special requirements are noted
## 2. INFRASTRUCTURE & DEPLOYMENT SEQUENCING
### 2.1 Database & Data Store Setup
- [ ] Database selection/setup occurs before any database operations
- [ ] Schema definitions are created before data operations
- [ ] Migration strategies are defined if applicable
- [ ] Seed data or initial data setup is included if needed
- [ ] Database access patterns and security are established early
### 2.2 API & Service Configuration
- [ ] API frameworks are set up before implementing endpoints
- [ ] Service architecture is established before implementing services
- [ ] Authentication framework is set up before protected routes
- [ ] Middleware and common utilities are created before use
### 2.3 Deployment Pipeline
- [ ] CI/CD pipeline is established before any deployment actions
- [ ] Infrastructure as Code (IaC) is set up before use
- [ ] Environment configurations (dev, staging, prod) are defined early
- [ ] Deployment strategies are defined before implementation
- [ ] Rollback procedures or considerations are addressed
### 2.4 Testing Infrastructure
- [ ] Testing frameworks are installed before writing tests
- [ ] Test environment setup precedes test implementation
- [ ] Mock services or data are defined before testing
- [ ] Test utilities or helpers are created before use
## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
### 3.1 Third-Party Services
- [ ] Account creation steps are identified for required services
- [ ] API key acquisition processes are defined
- [ ] Steps for securely storing credentials are included
- [ ] Fallback or offline development options are considered
### 3.2 External APIs
- [ ] Integration points with external APIs are clearly identified
- [ ] Authentication with external services is properly sequenced
- [ ] API limits or constraints are acknowledged
- [ ] Backup strategies for API failures are considered
### 3.3 Infrastructure Services
- [ ] Cloud resource provisioning is properly sequenced
- [ ] DNS or domain registration needs are identified
- [ ] Email or messaging service setup is included if needed
- [ ] CDN or static asset hosting setup precedes their use
## 4. USER/AGENT RESPONSIBILITY DELINEATION
### 4.1 User Actions
- [ ] User responsibilities are limited to only what requires human intervention
- [ ] Account creation on external services is properly assigned to users
- [ ] Purchasing or payment actions are correctly assigned to users
- [ ] Credential provision is appropriately assigned to users
### 4.2 Developer Agent Actions
- [ ] All code-related tasks are assigned to developer agents
- [ ] Automated processes are correctly identified as agent responsibilities
- [ ] Configuration management is properly assigned
- [ ] Testing and validation are assigned to appropriate agents
## 5. FEATURE SEQUENCING & DEPENDENCIES
### 5.1 Functional Dependencies
- [ ] Features that depend on other features are sequenced correctly
- [ ] Shared components are built before their use
- [ ] User flows follow a logical progression
- [ ] Authentication features precede protected routes/features
### 5.2 Technical Dependencies
- [ ] Lower-level services are built before higher-level ones
- [ ] Libraries and utilities are created before their use
- [ ] Data models are defined before operations on them
- [ ] API endpoints are defined before client consumption
### 5.3 Cross-Epic Dependencies
- [ ] Later epics build upon functionality from earlier epics
- [ ] No epic requires functionality from later epics
- [ ] Infrastructure established in early epics is utilized consistently
- [ ] Incremental value delivery is maintained
## 6. MVP SCOPE ALIGNMENT
### 6.1 PRD Goals Alignment
- [ ] All core goals defined in the PRD are addressed in epics/stories
- [ ] Features directly support the defined MVP goals
- [ ] No extraneous features beyond MVP scope are included
- [ ] Critical features are prioritized appropriately
### 6.2 User Journey Completeness
- [ ] All critical user journeys are fully implemented
- [ ] Edge cases and error scenarios are addressed
- [ ] User experience considerations are included
- [ ] Accessibility requirements are incorporated if specified
### 6.3 Technical Requirements Satisfaction
- [ ] All technical constraints from the PRD are addressed
- [ ] Non-functional requirements are incorporated
- [ ] Architecture decisions align with specified constraints
- [ ] Performance considerations are appropriately addressed
## 7. RISK MANAGEMENT & PRACTICALITY
### 7.1 Technical Risk Mitigation
- [ ] Complex or unfamiliar technologies have appropriate learning/prototyping stories
- [ ] High-risk components have explicit validation steps
- [ ] Fallback strategies exist for risky integrations
- [ ] Performance concerns have explicit testing/validation
### 7.2 External Dependency Risks
- [ ] Risks with third-party services are acknowledged and mitigated
- [ ] API limits or constraints are addressed
- [ ] Backup strategies exist for critical external services
- [ ] Cost implications of external services are considered
### 7.3 Timeline Practicality
- [ ] Story complexity and sequencing suggest a realistic timeline
- [ ] Dependencies on external factors are minimized or managed
- [ ] Parallel work is enabled where possible
- [ ] Critical path is identified and optimized
## 8. DOCUMENTATION & HANDOFF
### 8.1 Developer Documentation
- [ ] API documentation is created alongside implementation
- [ ] Setup instructions are comprehensive
- [ ] Architecture decisions are documented
- [ ] Patterns and conventions are documented
### 8.2 User Documentation
- [ ] User guides or help documentation is included if required
- [ ] Error messages and user feedback are considered
- [ ] Onboarding flows are fully specified
- [ ] Support processes are defined if applicable
## 9. POST-MVP CONSIDERATIONS
### 9.1 Future Enhancements
- [ ] Clear separation between MVP and future features
- [ ] Architecture supports planned future enhancements
- [ ] Technical debt considerations are documented
- [ ] Extensibility points are identified
### 9.2 Feedback Mechanisms
- [ ] Analytics or usage tracking is included if required
- [ ] User feedback collection is considered
- [ ] Monitoring and alerting are addressed
- [ ] Performance measurement is incorporated
## VALIDATION SUMMARY
### Category Statuses
| Category | Status | Critical Issues |
| ----------------------------------------- | ----------------- | --------------- |
| 1. Project Setup & Initialization | PASS/FAIL/PARTIAL | |
| 2. Infrastructure & Deployment Sequencing | PASS/FAIL/PARTIAL | |
| 3. External Dependencies & Integrations | PASS/FAIL/PARTIAL | |
| 4. User/Agent Responsibility Delineation | PASS/FAIL/PARTIAL | |
| 5. Feature Sequencing & Dependencies | PASS/FAIL/PARTIAL | |
| 6. MVP Scope Alignment | PASS/FAIL/PARTIAL | |
| 7. Risk Management & Practicality | PASS/FAIL/PARTIAL | |
| 8. Documentation & Handoff | PASS/FAIL/PARTIAL | |
| 9. Post-MVP Considerations | PASS/FAIL/PARTIAL | |
### Critical Deficiencies
- List all critical issues that must be addressed before approval
### Recommendations
- Provide specific recommendations for addressing each deficiency
### Final Decision
- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
- **REJECTED**: The plan requires revision to address the identified deficiencies.

128
docs/templates/prd.md vendored Normal file
View File

@@ -0,0 +1,128 @@
# {Project Name} Product Requirements Document (PRD)
## Intro
{Short 1-2 paragraph describing the what and why of the product/system being built for this version/MVP, referencing the `project-brief.md`.}
## Goals and Context
- **Project Objectives:** {Summarize the key business/user objectives this product/MVP aims to achieve. Refine goals from the Project Brief.}
- **Measurable Outcomes:** {How will success be tangibly measured? Define specific outcomes.}
- **Success Criteria:** {What conditions must be met for the MVP/release to be considered successful?}
- **Key Performance Indicators (KPIs):** {List the specific metrics that will be tracked.}
## Scope and Requirements (MVP / Current Version)
### Functional Requirements (High-Level)
{List the major capabilities the system must have. Describe _what_ the system does, not _how_. Group related requirements.}
- Capability 1: ...
- Capability 2: ...
### Non-Functional Requirements (NFRs)
{List key quality attributes and constraints.}
- **Performance:** {e.g., Response times, load capacity}
- **Scalability:** {e.g., Ability to handle growth}
- **Reliability/Availability:** {e.g., Uptime requirements, error handling expectations}
- **Security:** {e.g., Authentication, authorization, data protection, compliance}
- **Maintainability:** {e.g., Code quality standards, documentation needs}
- **Usability/Accessibility:** {High-level goals; details in UI/UX Spec if applicable}
- **Other Constraints:** {e.g., Technology constraints, budget, timeline}
### User Experience (UX) Requirements (High-Level)
{Describe the key aspects of the desired user experience. If a UI exists, link to `docs/ui-ux-spec.md` for details.}
- UX Goal 1: ...
- UX Goal 2: ...
### Integration Requirements (High-Level)
{List key external systems or services this product needs to interact with.}
- Integration Point 1: {e.g., Payment Gateway, External API X, Internal Service Y}
- Integration Point 2: ...
- _(See `docs/api-reference.md` for technical details)_
### Testing Requirements (High-Level)
{Briefly outline the overall expectation for testing - as the details will be in the testing strategy doc.}
- {e.g., "Comprehensive unit, integration, and E2E tests are required.", "Specific performance testing is needed for component X."}
- _(See `docs/testing-strategy.md` for details)_
## Epic Overview (MVP / Current Version)
{List the major epics that break down the work for the MVP. Include a brief goal for each epic. Detailed stories reside in `docs/epicN.md` files.}
- **Epic 1: {Epic Title}** - Goal: {...}
- **Epic 2: {Epic Title}** - Goal: {...}
- **Epic N: {Epic Title}** - Goal: {...}
## Key Reference Documents
{Link to other relevant documents in the `docs/` folder.}
- `docs/project-brief.md`
- `docs/architecture.md`
- `docs/epic1.md`, `docs/epic2.md`, ...
- `docs/tech-stack.md`
- `docs/api-reference.md`
- `docs/testing-strategy.md`
- `docs/ui-ux-spec.md` (if applicable)
- ... (other relevant docs)
## Post-MVP / Future Enhancements
{List ideas or planned features for future versions beyond the scope of the current PRD.}
- Idea 1: ...
- Idea 2: ...
## Change Log
| Change | Date | Version | Description | Author |
| ------ | ---- | ------- | ----------- | ------ |
## Initial Architect Prompt
{Provide a comprehensive summary of technical infrastructure decisions, constraints, and considerations for the Architect to reference when designing the system architecture. Include:}
### Technical Infrastructure
- **Starter Project/Template:** {Information about any starter projects, templates, or existing codebases that should be used}
- **Hosting/Cloud Provider:** {Specified cloud platform (AWS, Azure, GCP, etc.) or hosting requirements}
- **Frontend Platform:** {Framework/library preferences or requirements (React, Angular, Vue, etc.)}
- **Backend Platform:** {Framework/language preferences or requirements (Node.js, Python/Django, etc.)}
- **Database Requirements:** {Relational, NoSQL, specific products or services preferred}
### Technical Constraints
- {List any technical constraints that impact architecture decisions}
- {Include any mandatory technologies, services, or platforms}
- {Note any integration requirements with specific technical implications}
### Deployment Considerations
- {Deployment frequency expectations}
- {CI/CD requirements}
- {Environment requirements (dev, staging, production)}
### Local Development & Testing Requirements
{Include this section only if the user has indicated these capabilities are important. If not applicable based on user preferences, you may remove this section.}
- {Requirements for local development environment}
- {Expectations for command-line testing capabilities}
- {Needs for testing across different environments}
- {Utility scripts or tools that should be provided}
- {Any specific testability requirements for components}
### Other Technical Considerations
- {Security requirements with technical implications}
- {Scalability needs with architectural impact}
- {Any other technical context the Architect should consider}

38
docs/templates/project-brief.md vendored Normal file
View File

@@ -0,0 +1,38 @@
# Project Brief: {Project Name}
## Introduction / Problem Statement
{Describe the core idea, the problem being solved, or the opportunity being addressed. Why is this project needed?}
## Vision & Goals
- **Vision:** {Describe the high-level desired future state or impact of this project.}
- **Primary Goals:** {List 2-5 specific, measurable, achievable, relevant, time-bound (SMART) goals for the Minimum Viable Product (MVP).}
- Goal 1: ...
- Goal 2: ...
- **Success Metrics (Initial Ideas):** {How will we measure if the project/MVP is successful? List potential KPIs.}
## Target Audience / Users
{Describe the primary users of this product/system. Who are they? What are their key characteristics or needs relevant to this project?}
## Key Features / Scope (High-Level Ideas for MVP)
{List the core functionalities or features envisioned for the MVP. Keep this high-level; details will go in the PRD/Epics.}
- Feature Idea 1: ...
- Feature Idea 2: ...
- Feature Idea N: ...
## Known Technical Constraints or Preferences
- **Constraints:** {List any known limitations and technical mandates or preferences - e.g., budget, timeline, specific technology mandates, required integrations, compliance needs.}
- **Risks:** {Identify potential risks - e.g., technical challenges, resource availability, market acceptance, dependencies.}
## Relevant Research (Optional)
{Link to or summarize findings from any initial research conducted (e.g., `deep-research-report-BA.md`).}
## PM Prompt
{The Prompt that will be used with the PM agent to initiate the PRD creation process}

70
docs/templates/project-structure.md vendored Normal file
View File

@@ -0,0 +1,70 @@
# {Project Name} Project Structure
{Provide an ASCII or Mermaid diagram representing the project's folder structure such as the following example.}
```plaintext
{project-root}/
├── .github/ # CI/CD workflows (e.g., GitHub Actions)
│ └── workflows/
│ └── main.yml
├── .vscode/ # VSCode settings (optional)
│ └── settings.json
├── build/ # Compiled output (if applicable, often git-ignored)
├── config/ # Static configuration files (if any)
├── docs/ # Project documentation (PRD, Arch, etc.)
│ ├── index.md
│ └── ... (other .md files)
├── infra/ # Infrastructure as Code (e.g., CDK, Terraform)
│ └── lib/
│ └── bin/
├── node_modules/ # Project dependencies (git-ignored)
├── scripts/ # Utility scripts (build, deploy helpers, etc.)
├── src/ # Application source code
│ ├── common/ # Shared utilities, types, constants
│ ├── components/ # Reusable UI components (if UI exists)
│ ├── features/ # Feature-specific modules (alternative structure)
│ │ └── feature-a/
│ ├── core/ # Core business logic
│ ├── clients/ # External API/Service clients
│ ├── services/ # Internal services / Cloud SDK wrappers
│ ├── pages/ / routes/ # UI pages or API route definitions
│ └── main.ts / index.ts / app.ts # Application entry point
├── stories/ # Generated story files for development (optional)
│ └── epic1/
├── test/ # Automated tests
│ ├── unit/ # Unit tests (mirroring src structure)
│ ├── integration/ # Integration tests
│ └── e2e/ # End-to-end tests
├── .env.example # Example environment variables
├── .gitignore # Git ignore rules
├── package.json # Project manifest and dependencies
├── tsconfig.json # TypeScript configuration (if applicable)
├── Dockerfile # Docker build instructions (if applicable)
└── README.md # Project overview and setup instructions
```
(Adjust the example tree based on the actual project type - e.g., Python would have requirements.txt, etc.)
## Key Directory Descriptions
docs/: Contains all project planning and reference documentation.
infra/: Holds the Infrastructure as Code definitions (e.g., AWS CDK, Terraform).
src/: Contains the main application source code.
common/: Code shared across multiple modules (utilities, types, constants). Avoid business logic here.
core/ / domain/: Core business logic, entities, use cases, independent of frameworks/external services.
clients/: Modules responsible for communicating with external APIs or services.
services/ / adapters/ / infrastructure/: Implementation details, interactions with databases, cloud SDKs, frameworks.
routes/ / controllers/ / pages/: Entry points for API requests or UI views.
test/: Contains all automated tests, mirroring the src/ structure where applicable.
scripts/: Helper scripts for build, deployment, database migrations, etc.
## Notes
{Mention any specific build output paths, compiler configuration pointers, or other relevant structural notes.}
## Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft | {Agent/Person} |
| ... | ... | ... | ... | ... |

57
docs/templates/story-draft-checklist.md vendored Normal file
View File

@@ -0,0 +1,57 @@
# Story Draft Checklist
The Scrum Master should use this checklist to validate that each story contains sufficient context for a developer agent to implement it successfully, while assuming the dev agent has reasonable capabilities to figure things out.
## 1. GOAL & CONTEXT CLARITY
- [ ] Story goal/purpose is clearly stated
- [ ] Relationship to epic goals is evident
- [ ] How the story fits into overall system flow is explained
- [ ] Dependencies on previous stories are identified (if applicable)
- [ ] Business context and value are clear
## 2. TECHNICAL IMPLEMENTATION GUIDANCE
- [ ] Key files to create/modify are identified (not necessarily exhaustive)
- [ ] Technologies specifically needed for this story are mentioned
- [ ] Critical APIs or interfaces are sufficiently described
- [ ] Necessary data models or structures are referenced
- [ ] Required environment variables are listed (if applicable)
- [ ] Any exceptions to standard coding patterns are noted
## 3. REFERENCE EFFECTIVENESS
- [ ] References to external documents point to specific relevant sections
- [ ] Critical information from previous stories is summarized (not just referenced)
- [ ] Context is provided for why references are relevant
- [ ] References use consistent format (e.g., `docs/filename.md#section`)
## 4. SELF-CONTAINMENT ASSESSMENT
- [ ] Core information needed is included (not overly reliant on external docs)
- [ ] Implicit assumptions are made explicit
- [ ] Domain-specific terms or concepts are explained
- [ ] Edge cases or error scenarios are addressed
## 5. TESTING GUIDANCE
- [ ] Required testing approach is outlined
- [ ] Key test scenarios are identified
- [ ] Success criteria are defined
- [ ] Special testing considerations are noted (if applicable)
## VALIDATION RESULT
| Category | Status | Issues |
| ------------------------------------ | ----------------- | ------ |
| 1. Goal & Context Clarity | PASS/FAIL/PARTIAL | |
| 2. Technical Implementation Guidance | PASS/FAIL/PARTIAL | |
| 3. Reference Effectiveness | PASS/FAIL/PARTIAL | |
| 4. Self-Containment Assessment | PASS/FAIL/PARTIAL | |
| 5. Testing Guidance | PASS/FAIL/PARTIAL | |
**Final Assessment:**
- READY: The story provides sufficient context for implementation
- NEEDS REVISION: The story requires updates (see issues)
- BLOCKED: External information required (specify what information)

82
docs/templates/story-template.md vendored Normal file
View File

@@ -0,0 +1,82 @@
# Story {EpicNum}.{StoryNum}: {Short Title Copied from Epic File}
**Status:** Draft | In-Progress | Complete
## Goal & Context
**User Story:** {As a [role], I want [action], so that [benefit] - Copied or derived from Epic file}
**Context:** {Briefly explain how this story fits into the Epic's goal and the overall workflow. Mention the previous story's outcome if relevant. Example: "This story builds upon the project setup (Story 1.1) by defining the S3 resource needed for state persistence..."}
## Detailed Requirements
{Copy the specific requirements/description for this story directly from the corresponding `docs/epicN.md` file.}
## Acceptance Criteria (ACs)
{Copy the Acceptance Criteria for this story directly from the corresponding `docs/epicN.md` file.}
- AC1: ...
- AC2: ...
- ACN: ...
## Technical Implementation Context
**Guidance:** Use the following details for implementation. Developer agent is expected to follow project standards in `docs/coding-standards.md` and understand the project structure in `docs/project-structure.md`. Only story-specific details are included below.
- **Relevant Files:**
- Files to Create: {e.g., `src/services/s3-service.ts`, `test/unit/services/s3-service.test.ts`}
- Files to Modify: {e.g., `lib/hacker-news-briefing-stack.ts`, `src/common/types.ts`}
- **Key Technologies:**
- {Include only technologies directly used in this specific story, not the entire tech stack}
- {If a UI story, mention specific frontend libraries/framework features needed for this story}
- **API Interactions / SDK Usage:**
- {Include only the specific API endpoints or services relevant to this story}
- {e.g., "Use `@aws-sdk/client-s3`: `S3Client`, `GetObjectCommand`, `PutObjectCommand`"}
- **UI/UX Notes:** {ONLY IF THIS IS A UI Focused Epic or Story - include only relevant mockups/flows}
- **Data Structures:**
- {Include only the specific data models/entities used in this story, not all models}
- {e.g., "Define/Use `AppState` interface: `{ processedStoryIds: string[] }`"}
- **Environment Variables:**
- {Include only the specific environment variables needed for this story}
- {e.g., `S3_BUCKET_NAME` (Read via `config.ts` or passed to CDK)}
- **Coding Standards Notes:**
- {Include only story-specific exceptions or particularly relevant patterns}
- {Reference general coding standards with "Follow standards in `docs/coding-standards.md`"}
## Testing Requirements
**Guidance:** Verify implementation against the ACs using the following tests. Follow general testing approach in `docs/testing-strategy.md`.
- **Unit Tests:** {Include only specific testing requirements for this story, not the general testing strategy}
- **Integration Tests:** {Only if needed for this specific story}
- **Manual/CLI Verification:** {Only if specific verification steps are needed for this story}
## Tasks / Subtasks
{Copy the initial task breakdown from the corresponding `docs/epicN.md` file and expand or clarify as needed to ensure the agent can complete all AC. The agent can check these off as it proceeds. Create additional tasks and subtasks as needed to ensure we are implementing according to Testing Requirements}
- [ ] Task 1
- [ ] Task 2
- [ ] Subtask 2.1
- [ ] Task 3
## Story Wrap Up (Agent Populates After Execution)
- **Agent Model Used:** `<Agent Model Name/Version>`
- **Completion Notes:** {Any notes about implementation choices, difficulties, or follow-up needed}
- **Change Log:** {Track changes _within this specific story file_ if iterations occur}
- Initial Draft
- ...

33
docs/templates/tech-stack.md vendored Normal file
View File

@@ -0,0 +1,33 @@
# {Project Name} Technology Stack
## Technology Choices
| Category | Technology | Version / Details | Description / Purpose | Justification (Optional) |
| :------------------- | :---------------------- | :---------------- | :-------------------------------------- | :----------------------- |
| **Languages** | {e.g., TypeScript} | {e.g., 5.x} | {Primary language for backend/frontend} | {Why this language?} |
| | {e.g., Python} | {e.g., 3.11} | {Used for data processing, ML} | {...} |
| **Runtime** | {e.g., Node.js} | {e.g., 22.x} | {Server-side execution environment} | {...} |
| **Frameworks** | {e.g., NestJS} | {e.g., 10.x} | {Backend API framework} | {Why this framework?} |
| | {e.g., React} | {e.g., 18.x} | {Frontend UI library} | {...} |
| **Databases** | {e.g., PostgreSQL} | {e.g., 15} | {Primary relational data store} | {...} |
| | {e.g., Redis} | {e.g., 7.x} | {Caching, session storage} | {...} |
| **Cloud Platform** | {e.g., AWS} | {N/A} | {Primary cloud provider} | {...} |
| **Cloud Services** | {e.g., AWS Lambda} | {N/A} | {Serverless compute} | {...} |
| | {e.g., AWS S3} | {N/A} | {Object storage for assets/state} | {...} |
| | {e.g., AWS EventBridge} | {N/A} | {Event bus / scheduled tasks} | {...} |
| **Infrastructure** | {e.g., AWS CDK} | {e.g., Latest} | {Infrastructure as Code tool} | {...} |
| | {e.g., Docker} | {e.g., Latest} | {Containerization} | {...} |
| **UI Libraries** | {e.g., Material UI} | {e.g., 5.x} | {React component library} | {...} |
| **State Management** | {e.g., Redux Toolkit} | {e.g., Latest} | {Frontend state management} | {...} |
| **Testing** | {e.g., Jest} | {e.g., Latest} | {Unit/Integration testing framework} | {...} |
| | {e.g., Playwright} | {e.g., Latest} | {End-to-end testing framework} | {...} |
| **CI/CD** | {e.g., GitHub Actions} | {N/A} | {Continuous Integration/Deployment} | {...} |
| **Other Tools** | {e.g., LangChain.js} | {e.g., Latest} | {LLM interaction library} | {...} |
| | {e.g., Cheerio} | {e.g., Latest} | {HTML parsing/scraping} | {...} |
## Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft | {Agent/Person} |
| ... | ... | ... | ... |

76
docs/templates/testing-strategy.md vendored Normal file
View File

@@ -0,0 +1,76 @@
# {Project Name} Testing Strategy
## Overall Philosophy & Goals
{Describe the high-level approach. e.g., "Follow the Testing Pyramid/Trophy principle.", "Automate extensively.", "Focus on testing business logic and key integrations.", "Ensure tests run efficiently in CI/CD."}
- Goal 1: {e.g., Achieve X% code coverage for critical modules.}
- Goal 2: {e.g., Prevent regressions in core functionality.}
- Goal 3: {e.g., Enable confident refactoring.}
## Testing Levels
### Unit Tests
- **Scope:** Test individual functions, methods, or components in isolation. Focus on business logic, calculations, and conditional paths within a single module.
- **Tools:** {e.g., Jest, Pytest, Go testing package, JUnit, NUnit}
- **Mocking/Stubbing:** {How are dependencies mocked? e.g., Jest mocks, Mockito, Go interfaces}
- **Location:** {e.g., `test/unit/`, alongside source files (`*.test.ts`)}
- **Expectations:** {e.g., Should cover all significant logic paths. Fast execution.}
### Integration Tests
- **Scope:** Verify the interaction and collaboration between multiple internal components or modules. Test the flow of data and control within a specific feature or workflow slice. May involve mocking external APIs or databases, or using test containers.
- **Tools:** {e.g., Jest, Pytest, Go testing package, Testcontainers, Supertest (for APIs)}
- **Location:** {e.g., `test/integration/`}
- **Expectations:** {e.g., Focus on module boundaries and contracts. Slower than unit tests.}
### End-to-End (E2E) / Acceptance Tests
- **Scope:** Test the entire system flow from an end-user perspective. Interact with the application through its external interfaces (UI or API). Validate complete user journeys or business processes against real or near-real dependencies.
- **Tools:** {e.g., Playwright, Cypress, Selenium (for UI); Postman/Newman, K6 (for API)}
- **Environment:** {Run against deployed environments (e.g., Staging) or a locally composed setup (Docker Compose).}
- **Location:** {e.g., `test/e2e/`}
- **Expectations:** {Cover critical user paths. Slower, potentially flaky, run less frequently (e.g., pre-release, nightly).}
### Manual / Exploratory Testing (Optional)
- **Scope:** {Where is manual testing still required? e.g., Exploratory testing for usability, testing complex edge cases.}
- **Process:** {How is it performed and tracked?}
## Specialized Testing Types (Add sections as needed)
### Performance Testing
- **Scope & Goals:** {What needs performance testing? What are the targets (latency, throughput)?}
- **Tools:** {e.g., K6, JMeter, Locust}
### Security Testing
- **Scope & Goals:** {e.g., Dependency scanning, SAST, DAST, penetration testing requirements.}
- **Tools:** {e.g., Snyk, OWASP ZAP, Dependabot}
### Accessibility Testing (UI)
- **Scope & Goals:** {Target WCAG level, key areas.}
- **Tools:** {e.g., Axe, Lighthouse, manual checks}
### Visual Regression Testing (UI)
- **Scope & Goals:** {Prevent unintended visual changes.}
- **Tools:** {e.g., Percy, Applitools Eyes, Playwright visual comparisons}
## Test Data Management
{How is test data generated, managed, and reset for different testing levels?}
## CI/CD Integration
{How and when are tests executed in the CI/CD pipeline? What constitutes a pipeline failure?}
## Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft | {Agent/Person} |
| ... | ... | ... | ... | ... |

99
docs/templates/ui-ux-spec.md vendored Normal file
View File

@@ -0,0 +1,99 @@
# {Project Name} UI/UX 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.}
- **Link to Primary Design Files:** {e.g., Figma, Sketch, Adobe XD URL}
- **Link to Deployed Storybook / Design System:** {URL, if applicable}
## 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".}
## Information Architecture (IA)
- **Site Map / Screen Inventory:**
```mermaid
graph TD
A[Homepage] --> B(Dashboard);
A --> C{Settings};
B --> D[View Details];
C --> E[Profile Settings];
C --> F[Notification Settings];
```
_(Or provide a list of all screens/pages)_
- **Navigation Structure:** {Describe primary navigation (e.g., top bar, sidebar), secondary navigation, breadcrumbs, etc.}
## User Flows
{Detail key user tasks. Use diagrams or descriptions.}
### {User Flow Name, e.g., User Login}
- **Goal:** {What the user wants to achieve.}
- **Steps / Diagram:**
```mermaid
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;
```
_(Or: Link to specific flow diagram in Figma/Miro)_
### {Another User Flow Name}
{...}
## Wireframes & Mockups
{Reference the main design file link above. Optionally embed key mockups or describe main screen layouts.}
- **Screen / View Name 1:** {Description of layout and key elements. Link to specific Figma frame/page.}
- **Screen / View Name 2:** {...}
## Component Library / Design System Reference
{Link to the primary source (Storybook, Figma Library). If none exists, define key components here.}
### {Component Name, e.g., Primary Button}
- **Appearance:** {Reference mockup or describe styles.}
- **States:** {Default, Hover, Active, Disabled, Loading.}
- **Behavior:** {Interaction details.}
### {Another Component Name}
{...}
## Branding & Style Guide Reference
{Link to the primary source or define key elements here.}
- **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.}
## Accessibility (AX) Requirements
- **Target Compliance:** {e.g., WCAG 2.1 AA}
- **Specific Requirements:** {Keyboard navigation patterns, ARIA landmarks/attributes for complex components, color contrast minimums.}
## Responsiveness
- **Breakpoints:** {Define pixel values for mobile, tablet, desktop, etc.}
- **Adaptation Strategy:** {Describe how layout and components adapt across breakpoints. Reference designs.}
## Change Log
| Change | Date | Version | Description | Author |
| ------------- | ---------- | ------- | ------------------- | -------------- |
| Initial draft | YYYY-MM-DD | 0.1 | Initial draft | {Agent/Person} |
| Added Flow X | YYYY-MM-DD | 0.2 | Defined user flow X | {Agent/Person} |
| ... | ... | ... | ... | ... |

135
docs/templates/workflow-diagram.md vendored Normal file
View File

@@ -0,0 +1,135 @@
```mermaid
flowchart TD
subgraph subGraph0["Phase 0: Ideation (Optional)"]
A1["BA / Researcher"]
A0["User Idea"]
A2["project-brief"]
A3["DR: BA"]
end
subgraph subGraph1["Phase 1: Product Definition"]
B1["Product Manager"]
B2["prd"]
B3["epicN (Functional Draft)"]
B4["DR: PRD"]
end
subgraph subGraph2["Phase 2: Technical Design"]
C1["Architect"]
C2["architecture"]
C3["Reference Files"]
C4["DR: Architecture"]
end
subgraph subGraph3["Phase 3: Refinement, Validation & Approval"]
R1{"Refine & Validate Plan"}
R2["PM + Architect + Tech SM"]
R3["PO Validation"]
R4{"Final Approval?"}
R5["Approved Docs Finalized"]
R6["index"]
end
subgraph subGraph4["Phase 4: Story Generation"]
E1["Technical Scrum Master"]
E2["story-template"]
E3["story_X_Y"]
end
subgraph subGraph5["Phase 5: Development"]
F1["Developer Agent"]
F2["Code + Tests Committed"]
F3["Story File Updated"]
end
subgraph subGraph6["Phase 6: Review & Acceptance"]
G1{"Review Code & Functionality"}
G1_1["Tech SM / Architect"]
G1_2["User / QA Agent"]
G2{"Story Done?"}
G3["Story Done"]
end
subgraph subGraph7["Phase 7: Deployment"]
H1("Developer Agent")
H2@{ label: "Run IaC Deploy Command (e.g., `cdk deploy`)" }
H3["Deployed Update"]
end
A0 -- PO Input on Value --> A1
A1 --> A2 & A3
A2 --> B1
A3 --> B1
B4 <--> B1
B1 --> B2 & B3
B2 --> C1 & R1
B3 <-- Functional Req --> C1
C4 -.-> C1
C1 --> C2 & C3
B3 --> R1
C2 --> R1
C3 --> R1
R1 -- Collaboration --> R2
R2 -- Technical Input --> B3
R1 -- Refined Plan --> R3
R3 -- "Checks: <br>1. Scope/Value OK?<br>2. Story Sequence/Deps OK?<br>3. Holistic PRD Alignment OK?" --> R4
R4 -- Yes --> R5
R4 -- No --> R1
R5 --> R6 & E1
B3 -- Uses Refined Version --> E1
C3 -- Uses Approved Version --> E1
E1 -- Uses --> E2
E1 --> E3
E3 --> F1
F1 --> F2 & F3
F2 --> G1
F3 --> G1
G1 -- Code Review --> G1_1
G1 -- Functional Review --> G1_2
G1_1 -- Feedback --> F1
G1_2 -- Feedback --> F1
G1_1 -- Code OK --> G2
G1_2 -- Functionality OK --> G2
G2 -- Yes --> G3
G3 --> H1
H1 --> H2
H2 --> H3
H3 --> E1
H2@{ shape: rect}
A0:::default
A1:::agent
A2:::doc
A3:::doc
B1:::default
B2:::doc
B3:::doc
B4:::doc
C1:::default
C2:::doc
C3:::doc
C4:::doc
F2:::default
F3:::doc
H3:::default
R1:::process
R2:::agent
R3:::agent
R4:::process
R5:::default
R6:::doc
E1:::agent
E2:::doc
E3:::doc
F1:::agent
G1:::process
G1_1:::agent
G1_2:::agent
G2:::process
G3:::process
H1:::agent
H2:::process
classDef agent fill:#1a73e8,stroke:#0d47a1,stroke-width:2px,color:white,font-size:14px
classDef doc fill:#43a047,stroke:#1b5e20,stroke-width:1px,color:white,font-size:14px
classDef process fill:#ff9800,stroke:#e65100,stroke-width:1px,color:white,font-size:14px
classDef default fill:#333333,color:white,stroke:#999999,stroke-width:1px,font-size:14px
%% Styling for subgraphs
classDef subGraphStyle font-size:16px,font-weight:bold
class subGraph0,subGraph1,subGraph2,subGraph3,subGraph4,subGraph5,subGraph6,subGraph7 subGraphStyle
%% Styling for edge labels
linkStyle default font-size:12px
```

83
docs/workflow-diagram.md
View File

@@ -1,83 +0,0 @@
```mermaid
flowchart TD
%% Phase 0: BA
subgraph BA["Phase 0: Business Analyst"]
BA_B["Mode 1: Brainstorming"]
BA_R["Mode 2: Deep Research"]
BA_P["Mode 3: Project Briefing"]
BA_B --> BA_P
BA_R --> BA_P
end
%% Phase 1: PM
subgraph PM["Phase 1: Product Manager"]
PM_D["Mode 2: Deep Research"]
PM_M["Mode 1: Initial Product Def."]
PM_C["PM Checklist Verification"]
PM_PRD["PRD Complete"]
PM_D --> PM_M
PM_M --> PM_C
PM_C --> PM_PRD
end
%% Phase 2: Architect
subgraph ARCH["Phase 2: Architect"]
ARCH_P["Architecture Package Creation"]
ARCH_C["Architect Checklist Verification"]
ARCH_D["PRD+Architecture and Artifacts"]
ARCH_P --> ARCH_C
ARCH_C --> ARCH_D
end
%% Phase 3: PO
subgraph PO["Phase 3: Product Owner"]
PO_C["PO Checklist Verification"]
PO_A["Approval"]
end
%% Phase 4: SM
subgraph SM["Phase 4: Scrum Master"]
SM_S["Draft Next Story"]
SM_A["User Story Approval"]
end
%% Phase 5: Developer
subgraph DEV["Phase 5: Developer"]
DEV_I["Implement Story"]
DEV_T["Test"]
DEV_D["Deploy"]
DEV_A["User Approval"]
DEV_I --> DEV_T
DEV_T --> DEV_D
DEV_D --> DEV_A
end
%% Connections between phases
BA_P --> PM_M
User_Input[/"User Direct Input"/] --> PM_M
PM_PRD --> ARCH_P
ARCH_D --> PO_C
PO_C --> PO_A
PO_A --> SM_S
SM_S --> SM_A
SM_A --> DEV_I
DEV_A --> SM_S
%% Completion condition
DEV_A -- "All stories complete" --> DONE["Project Complete"]
%% Styling
classDef phase fill:#1a73e8,stroke:#0d47a1,stroke-width:2px,color:white,font-size:14px
classDef artifact fill:#43a047,stroke:#1b5e20,stroke-width:1px,color:white,font-size:14px
classDef process fill:#ff9800,stroke:#e65100,stroke-width:1px,color:white,font-size:14px
classDef approval fill:#d81b60,stroke:#880e4f,stroke-width:1px,color:white,font-size:14px
class BA,PM,ARCH,PO,SM,DEV phase
class BA_P,PM_PRD,ARCH_D artifact
class BA_B,BA_R,PM_D,PM_M,ARCH_P,SM_S,DEV_I,DEV_T,DEV_D process
class PM_C,ARCH_C,PO_C,PO_A,SM_A,DEV_A approval
```