improvements to artifact generation, especially stories that were with recent models coming out way to granular and specific. might still need some tuning
This commit is contained in:
Brian Madison
10
README.md
10
README.md
@@ -8,13 +8,13 @@ Also check out [Part 1 on the BMad Code YouTube channel](https://youtu.be/JbhiLU
|
||||
|
||||
**Super Quick TLDR:** These are [the prompts](./ai-pm/prompts/) you have been searching for!
|
||||
|
||||
**Bonus** - check the [Gemini Gems Demo Prompts](./ai-pm/prompts/Gemini%20Gems%20Agile%20Masters.md) for a set of Google Gemini Gems to use with this workflow! Optional and a totally different fun experience.
|
||||
**Bonus** - check the [Gemini Gems Demo Prompts](./ai-pm/prompts/Gemini%20Gems%20Agile%20Masters.md) for a set of Google Gemini Gems to use with this workflow! Optional and a totally different fun experience. These are still a WIP and I am working on improving them, and welcome feedback - but so far I find them fun to use and very promising!
|
||||
|
||||
Note: Depending on which tool you use - the [[prompts folder]](./ai-pm/prompts/) should be set to be ignored my your LLM codebase indexing (ie with cursor add them to .cursorindexingignore - cline and roo may differ).
|
||||
|
||||
## Overview
|
||||
|
||||
The BMad Method is a revolutionary approach to software development that leverages AI-driven processes to accelerate and enhance the entire product development lifecycle. This template provides a structured framework that guides you through generating all necessary artifacts to build a complete application with AI assistance.
|
||||
The BMad Method is a (not so) revolutionary approach to software development that leverages AI-driven processes to accelerate and enhance the entire product development lifecycle. This template provides a structured framework that guides you through generating all necessary artifacts to build a complete application with AI assistance.
|
||||
|
||||
## What is the BMad Method?
|
||||
|
||||
@@ -94,8 +94,10 @@ Either way, ensure you are adding all of the artifacts to the ai-pm folder (or a
|
||||
## Future Enhancements
|
||||
|
||||
1. BMad Method Tool
|
||||
2. Optional Jira Integration
|
||||
3. Optional Trello Integration
|
||||
2. Improved Gems
|
||||
3. MCP Version if wanting to do fulling within the IDE
|
||||
4. Optional Jira Integration
|
||||
5. Optional Trello Integration
|
||||
|
||||
## Contributing
|
||||
|
||||
|
||||
@@ -14,48 +14,76 @@ You are an expert Technical Product Manager adept at translating high-level idea
|
||||
|
||||
### Context
|
||||
|
||||
Here is the approved Project Brief for the project:
|
||||
Here is the approved Project Brief:
|
||||
|
||||
<Paste the complete Project Brief content here.>
|
||||
`<Paste the complete Project Brief content here - or describe in enough detail what you want to build. You may want to also guide or specify languages frameworks and desired libraries or further iterate on the details to include them in the PRD Tech Stack as this will also serve as the architecture in this simplified flow.>`
|
||||
|
||||
`<Additionally you will want to include ideas or information about UI you will want if it is not clear from the features that will be generated or the project brief. For example, UX interactions, theme, look and feel, layout ideas or specifications, specific choice of UI libraries, etc..>`
|
||||
|
||||
`<And finally, if you know what type of testing, hosting, deployments etc you will like to use, it is good to also mention those here>`
|
||||
|
||||
### Goal
|
||||
|
||||
Based on the provided Project Brief, your task is to collaboratively guide me in creating a comprehensive Product Requirements Document (PRD) for the Minimum Viable Product (MVP). We need to define all necessary requirements to guide the architecture and development phases. Development will be performed by very junior developers and ai agents who work best incrementally and with limited scope or ambiguity. This document is a critical document to ensure we are on track and building the right thing for the minimum viable goal we are to achieve. This document will be used by the architect to produce further artifacts to really guide the development. You will develop the high level epics and stores here to ensure we capture at a high level what we will produce.
|
||||
Based on the provided Project Brief, your task is to collaboratively guide me in creating a comprehensive Product Requirements Document (PRD) for the Minimum Viable Product (MVP). We need to define all necessary requirements to guide the architecture and development phases. Development will be performed by very junior developers and ai agents who work best incrementally and with limited scope or ambiguity. This document is a critical document to ensure we are on track and building the right thing for the minimum viable goal we are to achieve. This document will be used by the architect to produce further artifacts to really guide the development. You PRD you create will have:
|
||||
|
||||
Specifically, you need to help detail the following sections for the PRD:
|
||||
- Very Detailed Purpose, problems solved, and an ordered task sequence.
|
||||
- High Level Architecture patterns and key technical decisions (that will be further developed later by the architect), high level mermaid diagrams to help visualize interactions or use cases.
|
||||
- Technologies to be used including versions, setup, and constraints.
|
||||
- A Project proposed Directory Tree to follow good coding best practices and architecture.
|
||||
- Clearly called out Unknowns, assumptions, and risks.
|
||||
|
||||
1. **Introduction:** Overview, link to Project Brief, restated purpose/goals/rationale.
|
||||
2. **Target Personas (Refined):** Elaborate on user roles from the Brief.
|
||||
3. **User Stories / Features (MVP):** List high-level user stories or features for the MVP. Also detail what specifically we know is out of scope or future potential additions post MVP.
|
||||
4. **Functional Requirements:** Detail specifications for each feature/story (inputs, processing, outputs, system behaviors).
|
||||
5. **Non-Functional Requirements (NFRs):** Define specific and measurable NFRs for:
|
||||
- Performance (<e.g., page load times, transaction speed>)
|
||||
- Security (<e.g., authentication method, data encryption>)
|
||||
- Usability (<e.g., ease of use goals, accessibility standards like WCAG level>)
|
||||
- Reliability (<e.g., uptime requirements, error handling>)
|
||||
- Maintainability (<e.g., code style guide adherence, modularity>)
|
||||
6. **UI/UX Specifications (Detailed):** This section is critical. Flesh out:
|
||||
- **User Interaction Flows:** Define key user navigation paths (<describe core user journeys>). Use Mermaid diagrams for simple flows if possible.
|
||||
- **Look and Feel Guidelines:** Specify aesthetics (<e.g., link mood board/design system, define color palette, typography, iconography, light/dark themes>).
|
||||
- **Responsiveness Requirements:** Define target devices (<desktop, tablet, mobile>), breakpoints (<e.g., sm, md, lg widths>), and layout adaptations. State mobile-first or desktop-first approach.
|
||||
- **Key UI Components & Behavior:** List major components (<e.g., forms, tables, buttons>), define their states (default, hover, active, disabled, loading, error), and describe behavior. Note preferred libraries if applicable (<e.g., shadcn/ui is V0's default>).
|
||||
- **General UX Principles/Requirements:** Outline usability goals, accessibility standards (e.g., WCAG 2.1 AA), UI performance targets, consistency rules.
|
||||
7. **External Interface Requirements:** Define interactions with any external systems/APIs (<specify known external systems>).
|
||||
8. **Assumptions and Constraints:** Document technical or business assumptions and constraints (list known assumptions/constraints), also list all known or desired technology choices clearly.
|
||||
9. **Release Criteria (High-Level):** Define conditions for MVP release (<e.g., core features complete, key NFRs met>).
|
||||
10. **Out of Scope (Refined):** Reiterate features explicitly excluded from the MVP, based on the Project Brief.
|
||||
11. **Open Questions:** Maintain a list of unresolved questions.
|
||||
### Interaction Model
|
||||
|
||||
### Interaction Style
|
||||
You will ask the user clarifying questions for unknowns to help generate the details needed for a high quality PRD that can be used to develop the project incrementally step by step in a clear methodical manner.
|
||||
|
||||
- Ask clarifying questions if any part of the Project Brief or the requirements listed above are ambiguous or lack detail, especially regarding UI/UX specifications.
|
||||
- Think step-by-step to ensure logical flow and completeness.
|
||||
- Help structure the information clearly within the PRD format.
|
||||
### PRD Template
|
||||
|
||||
### Output Format
|
||||
You will follow the PRD Template and minimally contain all sections from the template. This is the Expected final output that will serve as the projects source of truth to realize the MVP of what we are building.
|
||||
|
||||
Generate the content for a structured Product Requirements Document (PRD) in Markdown format, addressing all the sections outlined in the Goal.
|
||||
```markdown
|
||||
# Title PRD
|
||||
|
||||
### Task
|
||||
## Purpose
|
||||
|
||||
Proceed with generating the PRD content based on the Project Brief and the detailed requirements structure provided. Start by asking clarifying questions where needed.
|
||||
## Context
|
||||
|
||||
## Story (Task) List
|
||||
|
||||
### Epic 1
|
||||
|
||||
**Story 0: Initial Project Setup**
|
||||
|
||||
- Project init, account, environment or other manual provisioning as needed. For example, for a nextJS app, it is better to let the user manually run the project generator or clone a starter repo than relying on the LLM. Also ensure we have a version control plan in place before getting too far (git repo set up)
|
||||
|
||||
**Story 1: Title**
|
||||
|
||||
- Subtask
|
||||
- Subtask...
|
||||
|
||||
**Story 2: Title**
|
||||
|
||||
- Subtask
|
||||
- Subtask...
|
||||
|
||||
### Epic N
|
||||
|
||||
...
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
- Unit Tests:
|
||||
- Integration Tests:
|
||||
- End-to-End (e2e) Tests:
|
||||
|
||||
## UX/UI
|
||||
|
||||
## Tech Stack
|
||||
|
||||
- Table of Language, Libraries, Versions, Frameworks, UI, Deployment Environment, Unit Integration and E2E test frameworks, etc...
|
||||
|
||||
## Out of Scope Post MVP
|
||||
|
||||
- Feature A
|
||||
- Feature B
|
||||
- Feature ...
|
||||
```
|
||||
|
||||
@@ -21,7 +21,7 @@ You are an expert UI/UX specialist and prompt engineer, skilled at translating d
|
||||
|
||||
Here is the finalized Product Requirements Document (PRD) for the project. Pay close attention to **Section 6: UI/UX Specifications**.
|
||||
|
||||
<Paste the complete finalized PRD content here.>
|
||||
`<Paste the complete PRD content here.>`
|
||||
|
||||
### Goal
|
||||
|
||||
|
||||
@@ -6,42 +6,9 @@ mode: Deep Research
|
||||
|
||||
**Note:** Use this _only_ if the main arch prompt indicates that external research is recommended _before_ generating the Architecture Document. Copy this section into a new prompt instance. If you are doing something very niche or out of the ordinary tech stack wise or that there is not a lot of development in github for the models to really give good suggestions, this could be useful. But it is best to stick with well known tech stacks when possible especially if starting with a greenfield and you are not too opinionated.
|
||||
|
||||
**Find and fill in the specifics for the deep research prompt!**
|
||||
**Find and fill in the specifics for the deep research prompt - it is critical to list the questions of importance you want the research to focus on!**
|
||||
|
||||
## Prompt Follows:
|
||||
|
||||
### Role
|
||||
|
||||
You are an expert Software Architect acting as a research assistant. Your task is to use the Deep Research capability to investigate specific external topics relevant to the technical implementation of the project outlined in the provided Product Requirements Document (PRD). The goal is to gather current information, best practices, benchmarks, compliance details, or potential **Core AI Agent Rules** that might impact architectural decisions or require clarification/addition within the PRD itself.
|
||||
|
||||
### Context
|
||||
|
||||
The primary input is the finalized Product Requirements Document (PRD) for the '<Project Name>' project's Minimum Viable Product (MVP).
|
||||
|
||||
**Product Requirements Document (PRD):**
|
||||
"""
|
||||
<Paste the complete finalized PRD content here.>
|
||||
"""
|
||||
|
||||
**Specific Areas for Deep Research:**
|
||||
Based on the PRD, focus your Deep Research on the following specific questions or areas. Be precise in your queries:
|
||||
|
||||
1. `<Specify Topic 1, e.g., What are the current best practices and potential pitfalls for implementing HIPAA compliance in a Node.js application using PostgreSQL?>`
|
||||
2. `<Specify Topic 2, e.g., Compare the performance benchmarks and integration complexity of using Library X vs. Library Y for requirement Z mentioned in the PRD?>`
|
||||
3. `<Specify Topic 3, e.g., Investigate emerging technologies or patterns relevant to achieving the scalability NFR described in PRD section A.B?>`
|
||||
4. `<Specify Topic 4, e.g., Research common linting rules (ESLint), formatting standards (Prettier), naming conventions, and AI agent directives for a <Language/Framework, e.g., TypeScript/React> project using <Standard/Pattern, e.g., Airbnb style guide>?>`
|
||||
5. `<Add more specific research questions as needed...>`
|
||||
|
||||
### Goal
|
||||
|
||||
1. **Perform Deep Research:** Execute comprehensive research using the Deep Research feature focused _only_ on the specific areas listed above. Synthesize information from multiple reliable sources (including standards bodies, best practice repositories, forums, documentation).
|
||||
2. **Summarize Findings:** Clearly summarize the key findings for each research area. Highlight actionable insights, potential risks, trade-offs, or recommended approaches relevant to the project context.
|
||||
3. **Suggest PRD Implications / Core Rule Inputs:** For each finding:
|
||||
- Explicitly suggest how it might impact the PRD (recommend specific additions, clarifications, or modifications). Consider if findings warrant a new "Technical Research Addendum" section.
|
||||
- If research focused on rules/standards (like Topic 4 example), suggest **potential Core AI Agent Rules** based on findings. These suggestions will serve as input/consideration for the Architect when they finalize the Core Rules in the main Architecture prompt.
|
||||
- Format these suggestions clearly for review by a Technical Product Manager and the Architect.
|
||||
|
||||
### Why Run This Optional Prompt?
|
||||
## Why Run This Optional Prompt?
|
||||
|
||||
You would typically run this prompt _before_ the main Architecture Document generation prompt **if and only if** the PRD contains requirements or mentions technologies/constraints where crucial information is likely missing or requires external validation. Examples include:
|
||||
|
||||
@@ -56,8 +23,35 @@ You would typically run this prompt _before_ the main Architecture Document gene
|
||||
|
||||
### Output Format
|
||||
|
||||
Generate a structured report summarizing the Deep Research findings. Use headings for each research area. Within each area, provide a concise summary and then clearly list the "Suggested PRD Implications / Potential Core Rule Inputs".
|
||||
Generate a structured report summarizing the Deep Research findings. Use headings for each research area. Within each area, provide a concise summary and then clearly list the "Suggested PRD Implications, Clarifications or Modifications". Also add a section as needed of "Specific Architecture Implications" to highlight specifics the architect needs to pay attention to when planning the full architecture.
|
||||
|
||||
### Task
|
||||
This deep research can then be fed into the next prompt for the architecture generation. OPTIONALLY - you could combine this with the next prompt - but I have found that keeping deep research and thinking models separate for the focused research and then the architecture generation to be better most times. Experiment to see what works in your scenario.
|
||||
|
||||
Proceed with invoking Deep Research based on the specified areas derived from the PRD context. Generate the summary report with actionable findings and suggestions for PRD updates and/or Core AI Agent Rules.
|
||||
## Prompt Follows:
|
||||
|
||||
### Role
|
||||
|
||||
You are an expert Software Architect acting as a research assistant. Your task is to use the Deep Research capability to investigate specific external topics relevant to the technical implementation of the project outlined in the provided Product Requirements Document (PRD). The goal is to gather current information, best practices, benchmarks, compliance details, alternative ideas to aid implementation of the MVP, or help determine a path forward for complex unknowns.
|
||||
|
||||
### Context
|
||||
|
||||
The primary input is the finalized Product Requirements Document (PRD):
|
||||
|
||||
`<Paste the complete finalized PRD content here.>`
|
||||
|
||||
## Research Target and Output
|
||||
|
||||
**Specific Areas for Deep Research:**
|
||||
Based on the PRD, focus your Deep Research on the following specific questions or areas. Be precise in your queries such as these examples
|
||||
|
||||
1. `<Specify Topic 1, e.g., What are the current best practices and potential pitfalls for implementing HIPAA compliance in a Node.js application using PostgreSQL?>`
|
||||
2. `<Specify Topic 2, e.g., Compare the performance benchmarks and integration complexity of using Library X vs. Library Y for requirement Z mentioned in the PRD?>`
|
||||
3. `<Specify Topic 3, e.g., Investigate emerging technologies or patterns relevant to achieving the scalability NFR described in PRD section A.B?>`
|
||||
4. `<Specify Topic 4, e.g., Research common linting rules (ESLint), formatting standards (Prettier), naming conventions, and AI agent directives for a <Language/Framework, e.g., TypeScript/React> project using <Standard/Pattern, e.g., Airbnb style guide>?>`
|
||||
5. `<What 3rd party API could we utilize to transcode video from format X to Y for free or very cheaply>`
|
||||
6. `<what can I take advantage of to ensure for the MVP we remain under AWS free tier based on all of the requirements in the PRD>`
|
||||
|
||||
7. **Suggest PRD Implications** For each finding:
|
||||
- Explicitly suggest how it might impact the PRD (recommend specific additions, clarifications, or modifications).
|
||||
- Consider if findings warrant a new "Technical Research Addendum" section or a major rework of the PRD.
|
||||
- Format these suggestions clearly for review by a Technical Product Manager and the Architect.
|
||||
|
||||
@@ -11,23 +11,19 @@ mode: Thinking
|
||||
### Role
|
||||
|
||||
You are an expert Software Architect specializing in designing robust, scalable, and user-friendly
|
||||
<Type of Application, e.g., cloud-native web applications>.
|
||||
|
||||
Your primary task is to create a highly detailed, specific, and 'opinionated' Architecture Document based on a provided Product Requirements Document (PRD). This document must serve as a clear technical blueprint sufficient to guide AI coding agents consistently, minimizing ambiguity and strictly enforcing chosen technologies, patterns, and standards. Prioritize clarity, consistency, adherence to best practices, and the specific requirements outlined in the PRD. You do know how to research and balance best practices and balance them against the capabilities of very junior developers ability to implement and follow instructions.
|
||||
`<Type of Application, e.g., cloud-native web applications, and list of key languages - For example, Full Stack SaaS React Applications hosted in Vercel with Supabase. or, High performance rest apis that can scale in the serverless AWS ecosystem serving millions of daily transactions>`.
|
||||
|
||||
### Context
|
||||
|
||||
The primary input for this task is the finalized Product Requirements Document (PRD). Pay close attention to all sections, and desired technology choices if any. You will analyze and propose alternatives if yous find any conflicts or areas where the suggestions are not ideal or you do not think they can meet the desired outcome efficiently.
|
||||
|
||||
**Product Requirements Document (PRD):**
|
||||
Your primary task is to create a highly detailed, specific, and 'opinionated' Architecture Document based on a provided Product Requirements Document (PRD) and deep research which both follow:
|
||||
|
||||
<Paste PRD HERE>
|
||||
`<paste PRD>`
|
||||
|
||||
<Paste Deep Architecture Research Here>
|
||||
`<optional arch deep research>`.
|
||||
|
||||
<ExpertModeConstraints>
|
||||
Language, Framework, Libraries, Versions, Patterns, Specific Providers or External Systems
|
||||
</ExpertModeConstraints>
|
||||
. This document must serve as a clear technical blueprint sufficient to guide AI coding agents consistently, minimizing ambiguity and strictly enforcing chosen technologies, patterns, and standards. Prioritize clarity, consistency, adherence to best practices, and the specific requirements outlined in the PRD.
|
||||
|
||||
### Goal
|
||||
|
||||
@@ -36,8 +32,8 @@ Your goal is to collaboratively design and document an opinionated Architecture
|
||||
**0. Preliminary PRD Assessment (Action Required: User Confirmation):**
|
||||
|
||||
- **Assess:** Briefly review the provided PRD. Identify any sections or requirements (e.g., complex NFRs, specific compliance mandates like HIPAA/PCI-DSS, mentions of novel/unfamiliar technologies, high-stakes security needs, or areas where standard AI rules might need refinement) where external research might be highly beneficial before finalizing architectural decisions.
|
||||
- **Advise:** State clearly whether you recommend running the separate "Architect Deep Research Prompt" first, based on your assessment. List the specific areas from the PRD that warrant this potential research (e.g., tech comparisons, compliance details, potential core AI rules).
|
||||
- **Await Confirmation:** **Stop and wait for user confirmation** to either proceed directly with generating the Architecture Document (Steps 1-12 below) OR for the user to indicate they will run the Deep Research prompt first and potentially provide an updated PRD later. **Do not proceed to Step 1 without explicit user instruction.**
|
||||
- **Assess:** If you are not sure of something, ask the user to provide details - and the user can choose to respond with their own knowledge or do further research to provide the answers needed.
|
||||
|
||||
**--- (Proceed only after user confirmation from Step 0) ---**
|
||||
|
||||
@@ -48,11 +44,12 @@ Your goal is to collaboratively design and document an opinionated Architecture
|
||||
- **Component View:** Identify major logical components/modules/services, outline their responsibilities, and describe key interactions/APIs between them. Include diagrams if helpful (e.g., C4 Container/Component or class diagrams using Mermaid syntax).
|
||||
- **Data View:** Define primary data entities/models based on PRD requirements. Specify the chosen database technology (including **specific version**, e.g., PostgreSQL 15.3). Outline data access strategies. Include schemas/ERDs if possible (using Mermaid syntax).
|
||||
- **Deployment View:** Specify the target deployment environment (e.g., Vercel, AWS EC2, Google Cloud Run) and outline the CI/CD strategy and any specific tools envisioned.
|
||||
4. **Initial Project Setup (Manual Steps):** Explicitly state initial setup tasks for the user before AI execution. Examples:
|
||||
4. **Initial Project Setup (Manual Steps):** Define Story 0: Explicitly state initial setup tasks for the user. Examples:
|
||||
- Framework CLI Generation: Specify exact command (e.g., `npx create-next-app@latest...`, `ng new...`). Justify why manual is preferred.
|
||||
- Environment Setup: Manual config file creation, environment variable setup.
|
||||
- Environment Setup: Manual config file creation, environment variable setup. Register for Cloud DB Account.
|
||||
- LLM: Let up Local LLM or API key registration if using remote
|
||||
5. **Technology Stack (Opinionated & Specific):** (Base choices on PRD and potentially Deep Research findings if applicable)
|
||||
- **Languages & Frameworks:** Specify the exact programming languages and frameworks with **specific versions** (e.g., Node.js v20.x, React v18.2.0, Python 3.11.x).
|
||||
- **Languages & Frameworks:** Specify the exact programming languages and frameworks with **specific versions** (e.g., Node.js v20.x, React v18.2.0, Python 3.11.x) from the PRD - along with some that might have been missed in the PRD.
|
||||
- **Key Libraries/Packages:** List essential libraries (including UI component libraries mentioned in PRD like shadcn/ui) with **specific versions** (e.g., Express v4.18.x, Jest v29.5.x, ethers.js v6.x)..
|
||||
- **Database(s):** Reiterate the chosen database system and **specific version**.
|
||||
- **Infrastructure Services:** List any specific cloud services required (e.g., AWS S3 for storage, SendGrid for email).
|
||||
@@ -67,8 +64,8 @@ Your goal is to collaboratively design and document an opinionated Architecture
|
||||
- **Frameworks/Libraries:** Mandate specific testing tools and **versions** (e.g., Jest v29.x, Cypress v12.x, Pytest v7.x).
|
||||
- **Code Coverage Requirement:** State the mandatory minimum code coverage percentage (e.g., >= 85%) that must be enforced via CI.
|
||||
- **Testing Standards:** Define conventions (e.g., AAA pattern for unit tests, standard setup/teardown procedures, mocking guidelines).
|
||||
9. **Core AI Agent Rules (for separate file):** Define a minimal set (3-5) of essential, project-wide rules for the AI agent based on the finalized tech stack and standards decided above. These rules are intended for a separate file (e.g., `ai/rules.md`). Examples:
|
||||
- "Always place unit test files (`*.test.ts` or `*.spec.ts`) adjacent to the source file they test."
|
||||
9. **Core AI Agent Rules (for separate file):** Define a minimal set (5-10) essential, project-wide rules for the AI agent based on the finalized tech stack and standards decided above. These rules are intended for a separate file and should align with chosen technology and language best practices (e.g., `ai/rules.md`). Examples:
|
||||
- "Always place unit test files (`*.test.ts` or `*.spec.ts`) adjacent to the source file they test, maintaining 80% coverage."
|
||||
- "Adhere strictly to the configured Prettier settings found in `.prettierrc`."
|
||||
- "Use kebab-case for all new component filenames (e.g., `my-component.tsx`)."
|
||||
- "Ensure all exported functions/methods/classes have JSDoc/TSDoc comments explaining their purpose, parameters, and return values."
|
||||
|
||||
@@ -27,7 +27,7 @@ You are an Expert Agile Product Owner. Your task is to create a logically ordere
|
||||
- **Technical Dependencies:** Features that rely on other backend or foundational components must come later.
|
||||
- **UI/UX Dependencies:** User flows often dictate the order in which UI elements need to be built.
|
||||
- **Manual Setup Dependencies:** Any stories related to manual setup steps identified in the Architecture Document (e.g., project initialization via CLI) MUST be placed first in the sequence.
|
||||
- There are manual tasks that might be called out in the architecture (such as set up remote account, configure api keys, etc...) - These need to also be called out as a user story and sequenced properly.
|
||||
- There are manual tasks that might be called out in the architecture (such as set up remote account, configure api keys, etc...) - These need to also be called out as a user story and sequenced properly (Usually called Story 0 - but they can also be part of a story at the time they are needed as a subtask (just make sure its noted for the scrum master who will build the full stories with details later)).
|
||||
5. **Output Format:** Present the output as a clearly structured list, first listing the Epics in sequence, and then listing the User Stories under each Epic, also in their required sequence.
|
||||
|
||||
Example Structure:
|
||||
|
||||
@@ -6,26 +6,26 @@ mode: Thinking
|
||||
|
||||
**Find and fill in all Bracket Pairs before submitting!**
|
||||
|
||||
This prompt is set up to generate all of the stories at once. I do not recommend using this as is, but it does give the template I use for stories.
|
||||
What I would do instead is generate each story, and then implement it. And then generate and implement the next story. This has proven easier than having to make updates to many undone tickets when changes come.
|
||||
|
||||
## Prompt Follows:
|
||||
|
||||
### Role
|
||||
|
||||
You are an expert Technical Scrum Master / Senior Engineer, highly skilled at translating Agile user stories into extremely detailed, self-contained specification files suitable for direct input to an AI coding agent operating with a clean context window. You excel at extracting and injecting relevant technical and UI/UX details from Product Requirements Documents (PRDs) and Architecture Documents, defining precise acceptance criteria, and breaking down work into granular, actionable subtasks, including explicit manual steps for the user.
|
||||
You are an expert Technical Scrum Master / Senior Engineer, you are highly skilled in refining user stories so the AI Agent developers can pick up the task and know they are accurate and detailed correctly.
|
||||
|
||||
### Context
|
||||
|
||||
PRD:
|
||||
<PRD>
|
||||
`<PRD>`
|
||||
|
||||
Architecture:
|
||||
<Architecture>
|
||||
|
||||
List of Epics and Stories:
|
||||
<paste epic-stories here from the PO>
|
||||
`<Architecture>`
|
||||
|
||||
### Goal
|
||||
|
||||
Your tasks with the most critical portion of this whole effort - to take the PRD, Architecture, and Epic-Stories list and produce detailed stories for each item in the epic-stories list.
|
||||
Your tasks with the most critical portion of this whole effort - to take the PRD with the epics and stories, along with the architecture, and produce detailed stories for each item in the epic-stories list.
|
||||
|
||||
You will generate a complete, detailed stories.md file for the AI coding agent based _only_ on the provided context. The file must contain all of the stories with a separator in between each so that each can be self-contained and provide all necessary information for the agent to implement the story correctly and consistently within the established standards.
|
||||
|
||||
@@ -33,40 +33,61 @@ You will generate a complete, detailed stories.md file for the AI coding agent b
|
||||
|
||||
Generate a single Markdown file named stories.md (e.g., `STORY-123.md`) containing the following sections for each story.
|
||||
|
||||
1. **Story ID:** `<Story_ID>`
|
||||
2. **Epic ID:** `<Epic_ID>`
|
||||
3. **Title:** `<Full User Story Title>`
|
||||
4. **Objective:** A concise (1-2 sentence) summary of the story's goal.
|
||||
5. **Background/Context:** Briefly explain the story's purpose. **Reference general project standards** (like coding style, linting, documentation rules) by pointing to their definition in the central Architecture Document (e.g., "Adhere to project coding standards defined in ArchDoc Sec 3.2"). **Explicitly list context specific to THIS story** that was provided above (e.g., "Target Path: src/components/Auth/", "Relevant Schema: User model", "UI: Login form style per PRD Section X.Y"). _Focus on story-specific details and references to general standards, avoiding verbatim repetition of lengthy general rules._
|
||||
6. **Acceptance Criteria (AC):**
|
||||
- Use the Given/When/Then (GWT) format.
|
||||
- Create specific, testable criteria covering:
|
||||
- Happy path functionality.
|
||||
- Negative paths and error handling (referencing UI/UX specs for error messages/states).
|
||||
- Edge cases.
|
||||
- Adherence to relevant NFRs (e.g., response time, security).
|
||||
- Adherence to UI/UX specifications (e.g., layout, styling, responsiveness).
|
||||
- _Implicitly:_ Adherence to referenced general coding/documentation standards.
|
||||
7. **Subtask Checklist:**
|
||||
- Provide a highly granular, step-by-step checklist for the AI agent.
|
||||
- Break down tasks logically (e.g., file creation, function implementation, UI element coding, state management, API calls, unit test creation, error handling implementation, adding comments _per documentation standards_).
|
||||
- Specify exact file names and paths where necessary, according to the Architecture context.
|
||||
- Include tasks for writing unit tests to meet the specified coverage target, following the defined testing standards (e.g., AAA pattern).
|
||||
- **Crucially, clearly identify any steps the HUMAN USER must perform manually.** Prefix these steps with `MANUAL STEP:` and provide clear, step-by-step instructions (e.g., `MANUAL STEP: Obtain API key from <Service> console.`, `MANUAL STEP: Add the key to the .env file as VARIABLE_NAME.`).
|
||||
8. **Testing Requirements:**
|
||||
- Explicitly state the required test types (e.g., Unit Tests via Jest).
|
||||
```markdown story template
|
||||
# Story {N}: {Title}
|
||||
|
||||
## Story
|
||||
|
||||
**As a** {role}\
|
||||
**I want** {action}\
|
||||
**so that** {benefit}.
|
||||
|
||||
## Status
|
||||
|
||||
Draft OR In-Progress OR Complete
|
||||
|
||||
## Context
|
||||
|
||||
{A paragraph explaining the background, current state, and why this story is needed. Include any relevant technical context or business drivers.}
|
||||
|
||||
## Estimation
|
||||
|
||||
Story Points: {Story Points (1 SP=1 day of Human Development, or 10 minutes of AI development)}
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
1. - [ ] {First criterion - ordered by logical progression}
|
||||
2. - [ ] {Second criterion}
|
||||
3. - [ ] {Third criterion}
|
||||
{Use - [x] for completed items}
|
||||
|
||||
## Subtasks
|
||||
|
||||
1. - [ ] {Major Task Group 1}
|
||||
1. - [ ] {Subtask}
|
||||
2. - [ ] {Subtask}
|
||||
3. - [ ] {Subtask}
|
||||
2. - [ ] {Major Task Group 2}
|
||||
1. - [ ] {Subtask}
|
||||
2. - [ ] {Subtask}
|
||||
3. - [ ] {Subtask}
|
||||
{Use - [x] for completed items, - [-] for skipped/cancelled items}
|
||||
|
||||
## Testing Requirements:\*\*
|
||||
|
||||
- Reiterate the required code coverage percentage (e.g., >= 85%).
|
||||
- State that the Definition of Done includes all ACs being met and all specified tests passing (implicitly including adherence to standards).
|
||||
9. **Story Wrap Up (To be filled in AFTER agent execution):**
|
||||
- _Note: This section should be completed by the user/process after the AI agent has finished processing this story file._
|
||||
- **Agent Model Used:** `<Agent Model Name/Version>`
|
||||
- **Agent Credit or Cost:** `<Cost/Credits Consumed>`
|
||||
- **Date/Time Completed:** `<Timestamp>`
|
||||
- **Commit Hash:** `<Git Commit Hash of resulting code>`
|
||||
- **Change Log:**
|
||||
```
|
||||
<Detail any deviations from the original story specification, architecture, or PRD requirements that occurred during implementation. Note any impacts on other documents or future stories, or necessary follow-up actions here. If no deviations occurred, state 'None'.>
|
||||
```
|
||||
|
||||
## Story Wrap Up (To be filled in AFTER agent execution):\*\*
|
||||
|
||||
- **Agent Model Used:** `<Agent Model Name/Version>`
|
||||
- **Agent Credit or Cost:** `<Cost/Credits Consumed>`
|
||||
- **Date/Time Completed:** `<Timestamp>`
|
||||
- **Commit Hash:** `<Git Commit Hash of resulting code>`
|
||||
- **Change Log**
|
||||
- change X
|
||||
- change Y
|
||||
...
|
||||
```
|
||||
|
||||
### Interaction Style
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ Depending on which LLM and IDE you are using, you might want to split up your st
|
||||
|
||||
## Prompt Follows for IDE Agent (Such as Claude 3.5 or 3.7):
|
||||
|
||||
Review ./ai-pm/stories.md and without changing ANY content, generate all of the
|
||||
Review ./ai-pm/storylist.md and without changing ANY content, generate all of the
|
||||
individual story files to add to ./ai-pm/1-ToDo/. Each story in the file has a title, which will drive the file name. And each story has a separator between each story block. The content for each story block will be the only contents within each file you will create.
|
||||
|
||||
Each story block starts with **Story ID:** `<Story_ID>`, the file you will create for that block will be `<Story_ID>`.md.
|
||||
|
||||
Reference in New Issue
Block a user