style: standardize quote formatting and indentation in template files
This commit is contained in:
manjaroblack
40
dist/agents/pm.txt
vendored
40
dist/agents/pm.txt
vendored
@@ -1210,7 +1210,7 @@ sections:
|
||||
condition: PRD has UX/UI requirements
|
||||
instruction: |
|
||||
Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
|
||||
|
||||
|
||||
1. Pre-fill all subsections with educated guesses based on project context
|
||||
2. Present the complete rendered section to user
|
||||
3. Clearly let the user know where assumptions were made
|
||||
@@ -1252,7 +1252,7 @@ sections:
|
||||
title: Technical Assumptions
|
||||
instruction: |
|
||||
Gather technical decisions that will guide the Architect. Steps:
|
||||
|
||||
|
||||
1. Check if .bmad-core/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
|
||||
2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
|
||||
3. For unknowns, offer guidance based on project goals and MVP scope
|
||||
@@ -1280,9 +1280,9 @@ sections:
|
||||
title: Epic List
|
||||
instruction: |
|
||||
Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
|
||||
|
||||
|
||||
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 - 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
|
||||
@@ -1301,11 +1301,11 @@ sections:
|
||||
repeatable: true
|
||||
instruction: |
|
||||
After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
|
||||
|
||||
|
||||
For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
|
||||
|
||||
|
||||
CRITICAL STORY SEQUENCING REQUIREMENTS:
|
||||
|
||||
|
||||
- Stories within each epic MUST be logically sequential
|
||||
- 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
|
||||
@@ -1333,7 +1333,7 @@ sections:
|
||||
repeatable: true
|
||||
instruction: |
|
||||
Define clear, comprehensive, and testable acceptance criteria that:
|
||||
|
||||
|
||||
- Precisely define what "done" means from a functional perspective
|
||||
- Are unambiguous and serve as basis for verification
|
||||
- Include any critical non-functional requirements from the PRD
|
||||
@@ -1375,19 +1375,19 @@ sections:
|
||||
title: Intro Project Analysis and Context
|
||||
instruction: |
|
||||
IMPORTANT - SCOPE ASSESSMENT REQUIRED:
|
||||
|
||||
|
||||
This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
|
||||
|
||||
|
||||
1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
|
||||
|
||||
|
||||
2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
|
||||
|
||||
|
||||
3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.
|
||||
|
||||
|
||||
Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
|
||||
|
||||
|
||||
CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
|
||||
|
||||
|
||||
Do not proceed with any recommendations until the user has validated your understanding of the existing system.
|
||||
sections:
|
||||
- id: existing-project-overview
|
||||
@@ -1413,7 +1413,7 @@ sections:
|
||||
- Note: "Document-project analysis available - using existing technical documentation"
|
||||
- List key documents created by document-project
|
||||
- Skip the missing documentation check below
|
||||
|
||||
|
||||
Otherwise, check for existing documentation:
|
||||
sections:
|
||||
- id: available-docs
|
||||
@@ -1537,7 +1537,7 @@ sections:
|
||||
If document-project output available:
|
||||
- Extract from "Actual Tech Stack" table in High Level Architecture section
|
||||
- Include version numbers and any noted constraints
|
||||
|
||||
|
||||
Otherwise, document the current technology stack:
|
||||
template: |
|
||||
**Languages**: {{languages}}
|
||||
@@ -1576,7 +1576,7 @@ sections:
|
||||
- Reference "Technical Debt and Known Issues" section
|
||||
- Include "Workarounds and Gotchas" that might impact enhancement
|
||||
- Note any identified constraints from "Critical Technical Debt"
|
||||
|
||||
|
||||
Build risk assessment incorporating existing known issues:
|
||||
template: |
|
||||
**Technical Risks**: {{technical_risks}}
|
||||
@@ -1599,7 +1599,7 @@ sections:
|
||||
title: "Epic 1: {{enhancement_title}}"
|
||||
instruction: |
|
||||
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
|
||||
|
||||
|
||||
CRITICAL STORY SEQUENCING FOR BROWNFIELD:
|
||||
- Stories must ensure existing functionality remains intact
|
||||
- Each story should include verification that existing features still work
|
||||
@@ -1612,7 +1612,7 @@ sections:
|
||||
- Each story must deliver value while maintaining system integrity
|
||||
template: |
|
||||
**Epic Goal**: {{epic_goal}}
|
||||
|
||||
|
||||
**Integration Requirements**: {{integration_requirements}}
|
||||
sections:
|
||||
- id: story
|
||||
|
||||
Reference in New Issue
Block a user