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

more template fixes from botched husky job

Browse Source
This commit is contained in:
Brian Madison
2025-06-17 22:13:07 -05:00
parent b03aece79e
commit 7ecf47f8cf
3 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
bmad-core/templates/front-end-spec-tmpl.md
View File

@@ -131,7 +131,7 @@ Create subsections for each major flow. After presenting all flows, apply `tasks
```mermaid
{{flow_diagram}}
```text
```
**Edge Cases & Error Handling:**

6
bmad-core/templates/fullstack-architecture-tmpl.md
View File

@@ -84,7 +84,7 @@ Document the choice and key services that will be used.]]
### Repository Structure
[[LLM: Define the repository approach based on PRD requirements and platform choice:
[[LLM: Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask quetsions to the user if unsure:
1. For modern fullstack apps, monorepo is often preferred
2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces)
@@ -262,7 +262,7 @@ interface UserProfile {
bio?: string;
preferences: Record<string, any>;
}
```text
```
**Relationships:**
@@ -508,7 +508,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
```text
{{route_structure}}
```text
```
**Protected Route Pattern:**

4
bmad-core/templates/prd-tmpl.md
View File

@@ -116,7 +116,7 @@
CRITICAL: Epics MUST be logically sequential following agile best practices:
- Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
- Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page
- Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic!
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
- Not every project needs multiple epics, an epic needs to deliver value. For example, an API completed can deliver value even if a UI is not complete and planned for a separate epic.
- Err on the side of less epics, but let the user know your rationale and offer options for splitting them if it seems some are too large or focused on disparate things.
@@ -148,7 +148,7 @@ CRITICAL: Epics MUST be logically sequential following agile best practices:
[[LLM: CRITICAL STORY SEQUENCING REQUIREMENTS:
- Stories within each epic MUST be logically sequential
- Each story should be a "vertical slice" delivering complete functionality
- Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
- No story should depend on work from a later story or epic
- Identify and note any direct prerequisite stories
- Focus on "what" and "why" not "how" (leave technical implementation to Architect) yet be precise enough to support a logical sequential order of operations from story to story.