fix: correct YAML indentation and template references, rebuild dist
- Fixed YAML indentation error in dev.md (coding_standards_awareness) - Fixed template reference: projectbrief-tmpl.yaml → project-brief-tmpl.yaml - Updated in analyst.md - Updated in bmad-orchestrator.md - Rebuilt dist/ folder with all updates from previous commit This ensures the web bundles are synchronized with all the framework enhancements including Memory Bank, ADRs, Sprint workflows, and new data files. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lucas C
parent
ded53af686
commit
7cd0dd61a3
|
|
@ -84,7 +84,7 @@ dependencies:
|
|||
- market-research-tmpl.yaml
|
||||
- competitor-analysis-tmpl.yaml
|
||||
- brainstorming-output-tmpl.yaml
|
||||
- projectbrief-tmpl.yaml
|
||||
- project-brief-tmpl.yaml
|
||||
- productContext-tmpl.yaml
|
||||
data:
|
||||
- bmad-kb.md
|
||||
|
|
|
|||
|
|
@ -179,7 +179,7 @@ dependencies:
|
|||
templates:
|
||||
- adr-tmpl.yaml
|
||||
- dev-journal-tmpl.yaml
|
||||
- projectbrief-tmpl.yaml
|
||||
- project-brief-tmpl.yaml
|
||||
- productContext-tmpl.yaml
|
||||
- systemPatterns-tmpl.yaml
|
||||
- techContext-tmpl.yaml
|
||||
|
|
|
|||
|
|
@ -64,6 +64,7 @@ core_principles:
|
|||
- Numbered Options - Always use numbered lists when presenting choices to the user
|
||||
- Session Documentation - Create dev journal entries for significant development sessions
|
||||
- Knowledge Preservation - Document decisions, patterns, and learnings for future reference
|
||||
|
||||
coding_standards_awareness:
|
||||
- Apply all coding standards from data/coding-standards.md
|
||||
- Follow security principles [SFT], [IV], [RL], [RLS] by default
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -73,6 +73,13 @@ persona:
|
|||
- Risk-Based Testing - Prioritize testing based on risk and critical areas
|
||||
- Continuous Improvement - Balance perfection with pragmatism
|
||||
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
|
||||
coding_standards_awareness:
|
||||
- Apply all coding standards from data/coding-standards.md during reviews
|
||||
- Enforce security principles [SFT], [IV], [RL], [RLS] in all code
|
||||
- Verify code quality standards [DRY], [SF], [RP], [CA] are met
|
||||
- Check for proper error handling [REH] and resource management [RM]
|
||||
- Ensure twelve-factor principles compliance for cloud-native apps
|
||||
- Validate testing standards [TDT] and test coverage
|
||||
story-file-permissions:
|
||||
- CRITICAL: When reviewing stories, you are ONLY authorized to update the "QA Results" section of story files
|
||||
- CRITICAL: DO NOT modify any other sections including Status, Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Testing, Dev Agent Record, Change Log, or any other sections
|
||||
|
|
@ -80,13 +87,14 @@ story-file-permissions:
|
|||
commands:
|
||||
- help: Show numbered list of the following commands to allow selection
|
||||
- review {story}: execute the task review-story for the highest sequence story in docs/stories unless another is specified - keep any specified technical-preferences in mind as needed
|
||||
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
|
||||
- exit: Say goodbye as the QA Engineer, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
tasks:
|
||||
- review-story.md
|
||||
data:
|
||||
- technical-preferences.md
|
||||
- coding-standards.md
|
||||
- twelve-factor-principles.md
|
||||
templates:
|
||||
- story-tmpl.yaml
|
||||
```
|
||||
|
|
@ -381,7 +389,264 @@ sections:
|
|||
==================== END: .bmad-core/templates/story-tmpl.yaml ====================
|
||||
|
||||
==================== START: .bmad-core/data/technical-preferences.md ====================
|
||||
# User-Defined Preferred Patterns and Preferences
|
||||
# Technical Preferences and Architectural Principles
|
||||
|
||||
## Core Principles References
|
||||
|
||||
The following technical principles and standards apply to all BMAD projects:
|
||||
|
||||
### 1. Coding Standards
|
||||
- **Reference:** `coding-standards.md`
|
||||
- **Purpose:** Fundamental coding principles, security practices, and quality standards
|
||||
- **Key Areas:** Code simplicity, dependency management, security, testing, commit standards
|
||||
|
||||
### 2. Twelve-Factor App Principles
|
||||
- **Reference:** `twelve-factor-principles.md`
|
||||
- **Purpose:** Cloud-native application development principles
|
||||
- **Key Areas:** Codebase management, dependencies, config, backing services, build/release/run
|
||||
|
||||
### 3. Microservice Patterns
|
||||
- **Reference:** `microservice-patterns.md`
|
||||
- **Purpose:** Patterns for distributed system architecture
|
||||
- **Key Areas:** Service decomposition, communication patterns, data management, resilience
|
||||
|
||||
## Application Guidelines
|
||||
|
||||
1. **During Architecture Design:**
|
||||
- Apply twelve-factor principles for cloud-native applications
|
||||
- Consider microservice patterns for complex distributed systems
|
||||
- Document pattern choices in Architecture Decision Records (ADRs)
|
||||
|
||||
2. **During Implementation:**
|
||||
- Follow coding standards for all code generation
|
||||
- Apply security principles by default
|
||||
- Ensure testability and maintainability
|
||||
|
||||
3. **Technology Selection:**
|
||||
- Prefer simple, proven solutions over complex ones
|
||||
- Minimize dependencies unless explicitly justified
|
||||
- Consider operational complexity alongside technical capabilities
|
||||
|
||||
## User-Defined Preferences
|
||||
|
||||
_Add project-specific technical preferences below:_
|
||||
|
||||
None Listed
|
||||
==================== END: .bmad-core/data/technical-preferences.md ====================
|
||||
|
||||
==================== START: .bmad-core/data/coding-standards.md ====================
|
||||
# Coding Standards and Principles
|
||||
|
||||
> **Purpose:** This document defines the core coding standards and principles that apply to all development work in BMAD projects. These are fundamental rules of software craftsmanship that ensure consistency, quality, and maintainability.
|
||||
|
||||
## Core Coding Principles
|
||||
|
||||
### Simplicity and Readability
|
||||
- **[SF] Simplicity First:** Always choose the simplest viable solution. Complex patterns require explicit justification.
|
||||
- **[RP] Readability Priority:** Code must be immediately understandable by both humans and AI.
|
||||
- **[CA] Clean Architecture:** Generate cleanly formatted, logically structured code with consistent patterns.
|
||||
|
||||
### Dependency Management
|
||||
- **[DM] Dependency Minimalism:** No new libraries without explicit request or compelling justification.
|
||||
- **[DM-1] Security Reviews:** Review third-party dependencies for vulnerabilities quarterly.
|
||||
- **[DM-2] Package Verification:** Prefer signed or verified packages.
|
||||
- **[DM-3] Cleanup:** Remove unused or outdated dependencies promptly.
|
||||
- **[DM-4] Documentation:** Document dependency updates in changelog.
|
||||
|
||||
### Development Workflow
|
||||
- **[WF-FOCUS] Task Focus:** Focus on areas of code relevant to the task.
|
||||
- **[WF-SCOPE] Scope Control:** Do not touch code unrelated to the task.
|
||||
- **[WF-TEST] Testing:** Write thorough tests for all major functionality.
|
||||
- **[WF-ARCH] Architecture Stability:** Avoid major changes to working patterns unless explicitly requested.
|
||||
- **[WF-IMPACT] Impact Analysis:** Consider effects on other methods and code areas.
|
||||
|
||||
### Code Quality Standards
|
||||
- **[DRY] DRY Principle:** No duplicate code. Reuse or extend existing functionality.
|
||||
- **[REH] Error Handling:** Robust error handling for all edge cases and external interactions.
|
||||
- **[CSD] Code Smell Detection:** Proactively identify and refactor:
|
||||
- Functions exceeding 30 lines
|
||||
- Files exceeding 300 lines
|
||||
- Nested conditionals beyond 2 levels
|
||||
- Classes with more than 5 public methods
|
||||
|
||||
### Security Principles
|
||||
- **[IV] Input Validation:** All external data must be validated before processing.
|
||||
- **[SFT] Security-First:** Implement proper authentication, authorization, and data protection.
|
||||
- **[RL] Rate Limiting:** Rate limit all API endpoints.
|
||||
- **[RLS] Row-Level Security:** Use row-level security always.
|
||||
- **[CAP] Captcha Protection:** Captcha on all auth routes/signup pages.
|
||||
- **[WAF] WAF Protection:** Enable attack challenge on hosting WAF when available.
|
||||
- **[SEC-1] Sensitive Files:** DO NOT read or modify without prior approval:
|
||||
- .env files
|
||||
- */config/secrets.*
|
||||
- Any file containing API keys or credentials
|
||||
|
||||
### Performance and Resources
|
||||
- **[PA] Performance Awareness:** Consider computational complexity and resource usage.
|
||||
- **[RM] Resource Management:** Close connections and free resources appropriately.
|
||||
- **[CMV] Constants Over Magic Values:** No magic strings or numbers. Use named constants.
|
||||
|
||||
### Commit Standards
|
||||
- **[AC] Atomic Changes:** Make small, self-contained modifications.
|
||||
- **[CD] Commit Discipline:** Use conventional commit format:
|
||||
```
|
||||
type(scope): concise description
|
||||
|
||||
[optional body with details]
|
||||
|
||||
[optional footer with breaking changes/issue references]
|
||||
```
|
||||
Types: feat, fix, docs, style, refactor, perf, test, chore
|
||||
|
||||
### Testing Standards
|
||||
- **[TDT] Test-Driven Thinking:** Design all code to be easily testable from inception.
|
||||
- **[ISA] Industry Standards:** Follow established conventions for the language and tech stack.
|
||||
|
||||
## Application to AI Development
|
||||
|
||||
### Communication Guidelines
|
||||
- **[RAT] Rule Application Tracking:** Tag rule applications with abbreviations (e.g., [SF], [DRY]).
|
||||
- **[EDC] Explanation Depth Control:** Scale explanation detail based on complexity.
|
||||
- **[AS] Alternative Suggestions:** Offer alternative approaches with pros/cons when relevant.
|
||||
- **[KBT] Knowledge Boundary Transparency:** Clearly communicate capability limits.
|
||||
|
||||
### Context Management
|
||||
- **[TR] Transparent Reasoning:** Explicitly reference which rules influenced decisions.
|
||||
- **[CWM] Context Window Management:** Be mindful of AI context limitations.
|
||||
- **[SD] Strategic Documentation:** Comment only complex logic or critical functions.
|
||||
|
||||
## Integration with BMAD Workflows
|
||||
|
||||
These coding standards should be:
|
||||
1. Referenced during architecture design decisions
|
||||
2. Applied during story implementation
|
||||
3. Validated during code reviews
|
||||
4. Enforced through automated tooling where possible
|
||||
5. Updated based on team learnings and retrospectives
|
||||
==================== END: .bmad-core/data/coding-standards.md ====================
|
||||
|
||||
==================== START: .bmad-core/data/twelve-factor-principles.md ====================
|
||||
# Twelve-Factor App Principles
|
||||
|
||||
> **Purpose:** This document provides the definitive set of rules based on the Twelve-Factor App methodology. These principles are mandatory for ensuring applications are built as scalable, resilient, and maintainable cloud-native services.
|
||||
|
||||
## The Twelve Factors
|
||||
|
||||
### I. Codebase
|
||||
- A single, version-controlled codebase must represent one application
|
||||
- All code for a specific application belongs to this single codebase
|
||||
- Shared functionality must be factored into versioned libraries
|
||||
- One codebase produces multiple deploys (development, staging, production)
|
||||
|
||||
### II. Dependencies
|
||||
- Explicitly declare all dependencies via manifest files (e.g., package.json, requirements.txt)
|
||||
- Never rely on implicit existence of system-wide packages
|
||||
- Application must run in isolated environment with only declared dependencies
|
||||
|
||||
### III. Config
|
||||
- Strict separation between code and configuration
|
||||
- All deploy-varying config must be read from environment variables
|
||||
- Never hardcode environment-specific values in source code
|
||||
- Codebase must be runnable anywhere with correct environment variables
|
||||
|
||||
### IV. Backing Services
|
||||
- Treat all backing services as attached, swappable resources
|
||||
- Connect via locators/credentials stored in environment variables
|
||||
- Code must be agnostic to whether service is local or third-party
|
||||
- Examples: databases, message queues, caches, external APIs
|
||||
|
||||
### V. Build, Release, Run
|
||||
Maintain strict three-stage separation:
|
||||
- **Build:** Convert code repo into executable bundle
|
||||
- **Release:** Combine build with environment-specific config
|
||||
- **Run:** Execute release in target environment
|
||||
- Releases must be immutable with unique IDs
|
||||
- Any change requires new release
|
||||
|
||||
### VI. Processes
|
||||
- Execute as stateless, share-nothing processes
|
||||
- Persistent data must be stored in stateful backing service
|
||||
- Never assume local memory/disk state available across requests
|
||||
- Process state is ephemeral
|
||||
|
||||
### VII. Port Binding
|
||||
- Application must be self-contained
|
||||
- Export services by binding to port specified via configuration
|
||||
- Do not rely on runtime injection of webserver
|
||||
- Application brings its own webserver library
|
||||
|
||||
### VIII. Concurrency
|
||||
- Scale out horizontally by adding concurrent processes
|
||||
- Assign different workload types to different process types
|
||||
- Use process manager for lifecycle management
|
||||
- Design for horizontal scaling from the start
|
||||
|
||||
### IX. Disposability
|
||||
- Processes must be disposable (start/stop quickly)
|
||||
- Minimize startup time for fast elastic scaling
|
||||
- Graceful shutdown on SIGTERM
|
||||
- Robust against sudden death (crash-only design)
|
||||
|
||||
### X. Dev/Prod Parity
|
||||
Keep environments as similar as possible:
|
||||
- Same programming language versions
|
||||
- Same system tooling
|
||||
- Same backing service types and versions
|
||||
- Minimize time, personnel, and tool gaps
|
||||
|
||||
### XI. Logs
|
||||
- Treat logs as event streams
|
||||
- Never write to or manage log files directly
|
||||
- Write unbuffered to stdout
|
||||
- Execution environment handles collection and routing
|
||||
|
||||
### XII. Admin Processes
|
||||
- Run admin tasks as one-off processes
|
||||
- Use identical environment as long-running processes
|
||||
- Ship admin scripts with application code
|
||||
- Use same dependency and config management
|
||||
|
||||
## Additional Cloud-Native Principles
|
||||
|
||||
### Containerization
|
||||
- **[SVC] Service as Container:** Package services as container images
|
||||
- Encapsulate technology stack in containers
|
||||
- Ensure consistent deployment across environments
|
||||
|
||||
### Serverless Options
|
||||
- **[SRL] Serverless Deployment:** Consider serverless platforms when appropriate
|
||||
- Abstract away infrastructure management
|
||||
- Focus on business logic over infrastructure
|
||||
|
||||
### Observability
|
||||
- Implement comprehensive monitoring and metrics
|
||||
- Use distributed tracing for microservices
|
||||
- Ensure all services are observable by default
|
||||
|
||||
### Security
|
||||
- Security must be built-in, not bolted-on
|
||||
- Use principle of least privilege
|
||||
- Implement defense in depth
|
||||
- Regular security audits and updates
|
||||
|
||||
## AI/Agent Safeguards
|
||||
- All AI-generated code must be reviewed before production
|
||||
- Escalate ambiguous or risky decisions for approval
|
||||
- Log all significant AI-suggested changes
|
||||
- Never overwrite .env files without confirmation
|
||||
|
||||
## Environmental Sustainability
|
||||
- Optimize compute resources
|
||||
- Minimize infrastructure waste
|
||||
- Prefer energy-efficient solutions
|
||||
- Consider environmental impact in technical decisions
|
||||
|
||||
## Integration with BMAD
|
||||
|
||||
These principles should be:
|
||||
1. Applied during architecture design
|
||||
2. Validated during implementation
|
||||
3. Enforced through CI/CD pipelines
|
||||
4. Reviewed during architectural decision records (ADRs)
|
||||
5. Considered in all technical decisions
|
||||
==================== END: .bmad-core/data/twelve-factor-principles.md ====================
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -73,15 +73,12 @@ persona:
|
|||
- You can craft effective prompts for AI UI generation tools like v0, or Lovable.
|
||||
commands:
|
||||
- help: Show numbered list of the following commands to allow selection
|
||||
- create-doc {template}: execute task create-doc (no template = ONLY show available templates listed under dependencies/templates below)
|
||||
- generate-ui-prompt: Create AI frontend generation prompt
|
||||
- research {topic}: Execute create-deep-research-prompt task to generate a prompt to init UX deep research
|
||||
- execute-checklist {checklist}: Run task execute-checklist (default->po-master-checklist)
|
||||
- create-front-end-spec: run task create-doc.md with template front-end-spec-tmpl.yaml
|
||||
- generate-ui-prompt: Run task generate-ai-frontend-prompt.md
|
||||
- exit: Say goodbye as the UX Expert, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
tasks:
|
||||
- generate-ai-frontend-prompt.md
|
||||
- create-deep-research-prompt.md
|
||||
- create-doc.md
|
||||
- execute-checklist.md
|
||||
templates:
|
||||
|
|
@ -145,298 +142,6 @@ You will now synthesize the inputs and the above principles into a final, compre
|
|||
- <important_note>Conclude by reminding the user that all AI-generated code will require careful human review, testing, and refinement to be considered production-ready.</important_note>
|
||||
==================== END: .bmad-core/tasks/generate-ai-frontend-prompt.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/create-deep-research-prompt.md ====================
|
||||
# Create Deep Research Prompt Task
|
||||
|
||||
This task helps create comprehensive research prompts for various types of deep analysis. It can process inputs from brainstorming sessions, project briefs, market research, or specific research questions to generate targeted prompts for deeper investigation.
|
||||
|
||||
## Purpose
|
||||
|
||||
Generate well-structured research prompts that:
|
||||
|
||||
- Define clear research objectives and scope
|
||||
- Specify appropriate research methodologies
|
||||
- Outline expected deliverables and formats
|
||||
- Guide systematic investigation of complex topics
|
||||
- Ensure actionable insights are captured
|
||||
|
||||
## Research Type Selection
|
||||
|
||||
CRITICAL: First, help the user select the most appropriate research focus based on their needs and any input documents they've provided.
|
||||
|
||||
### 1. Research Focus Options
|
||||
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
|
||||
### 2. Input Processing
|
||||
|
||||
**If Project Brief provided:**
|
||||
|
||||
- Extract key product concepts and goals
|
||||
- Identify target users and use cases
|
||||
- Note technical constraints and preferences
|
||||
- Highlight uncertainties and assumptions
|
||||
|
||||
**If Brainstorming Results provided:**
|
||||
|
||||
- Synthesize main ideas and themes
|
||||
- Identify areas needing validation
|
||||
- Extract hypotheses to test
|
||||
- Note creative directions to explore
|
||||
|
||||
**If Market Research provided:**
|
||||
|
||||
- Build on identified opportunities
|
||||
- Deepen specific market insights
|
||||
- Validate initial findings
|
||||
- Explore adjacent possibilities
|
||||
|
||||
**If Starting Fresh:**
|
||||
|
||||
- Gather essential context through questions
|
||||
- Define the problem space
|
||||
- Clarify research objectives
|
||||
- Establish success criteria
|
||||
|
||||
## Process
|
||||
|
||||
### 3. Research Prompt Structure
|
||||
|
||||
CRITICAL: collaboratively develop a comprehensive research prompt with these components.
|
||||
|
||||
#### A. Research Objectives
|
||||
|
||||
CRITICAL: collaborate with the user to articulate clear, specific objectives for the research.
|
||||
|
||||
- Primary research goal and purpose
|
||||
- Key decisions the research will inform
|
||||
- Success criteria for the research
|
||||
- Constraints and boundaries
|
||||
|
||||
#### B. Research Questions
|
||||
|
||||
CRITICAL: collaborate with the user to develop specific, actionable research questions organized by theme.
|
||||
|
||||
**Core Questions:**
|
||||
|
||||
- Central questions that must be answered
|
||||
- Priority ranking of questions
|
||||
- Dependencies between questions
|
||||
|
||||
**Supporting Questions:**
|
||||
|
||||
- Additional context-building questions
|
||||
- Nice-to-have insights
|
||||
- Future-looking considerations
|
||||
|
||||
#### C. Research Methodology
|
||||
|
||||
**Data Collection Methods:**
|
||||
|
||||
- Secondary research sources
|
||||
- Primary research approaches (if applicable)
|
||||
- Data quality requirements
|
||||
- Source credibility criteria
|
||||
|
||||
**Analysis Frameworks:**
|
||||
|
||||
- Specific frameworks to apply
|
||||
- Comparison criteria
|
||||
- Evaluation methodologies
|
||||
- Synthesis approaches
|
||||
|
||||
#### D. Output Requirements
|
||||
|
||||
**Format Specifications:**
|
||||
|
||||
- Executive summary requirements
|
||||
- Detailed findings structure
|
||||
- Visual/tabular presentations
|
||||
- Supporting documentation
|
||||
|
||||
**Key Deliverables:**
|
||||
|
||||
- Must-have sections and insights
|
||||
- Decision-support elements
|
||||
- Action-oriented recommendations
|
||||
- Risk and uncertainty documentation
|
||||
|
||||
### 4. Prompt Generation
|
||||
|
||||
**Research Prompt Template:**
|
||||
|
||||
```markdown
|
||||
## Research Objective
|
||||
|
||||
[Clear statement of what this research aims to achieve]
|
||||
|
||||
## Background Context
|
||||
|
||||
[Relevant information from project brief, brainstorming, or other inputs]
|
||||
|
||||
## Research Questions
|
||||
|
||||
### Primary Questions (Must Answer)
|
||||
|
||||
1. [Specific, actionable question]
|
||||
2. [Specific, actionable question]
|
||||
...
|
||||
|
||||
### Secondary Questions (Nice to Have)
|
||||
|
||||
1. [Supporting question]
|
||||
2. [Supporting question]
|
||||
...
|
||||
|
||||
## Research Methodology
|
||||
|
||||
### Information Sources
|
||||
|
||||
- [Specific source types and priorities]
|
||||
|
||||
### Analysis Frameworks
|
||||
|
||||
- [Specific frameworks to apply]
|
||||
|
||||
### Data Requirements
|
||||
|
||||
- [Quality, recency, credibility needs]
|
||||
|
||||
## Expected Deliverables
|
||||
|
||||
### Executive Summary
|
||||
|
||||
- Key findings and insights
|
||||
- Critical implications
|
||||
- Recommended actions
|
||||
|
||||
### Detailed Analysis
|
||||
|
||||
[Specific sections needed based on research type]
|
||||
|
||||
### Supporting Materials
|
||||
|
||||
- Data tables
|
||||
- Comparison matrices
|
||||
- Source documentation
|
||||
|
||||
## Success Criteria
|
||||
|
||||
[How to evaluate if research achieved its objectives]
|
||||
|
||||
## Timeline and Priority
|
||||
|
||||
[If applicable, any time constraints or phasing]
|
||||
```
|
||||
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
- Are output requirements sufficient?
|
||||
|
||||
3. **Refine as Needed**
|
||||
- Incorporate user feedback
|
||||
- Adjust scope or focus
|
||||
- Add missing elements
|
||||
- Clarify ambiguities
|
||||
|
||||
### 6. Next Steps Guidance
|
||||
|
||||
**Execution Options:**
|
||||
|
||||
1. **Use with AI Research Assistant**: Provide this prompt to an AI model with research capabilities
|
||||
2. **Guide Human Research**: Use as a framework for manual research efforts
|
||||
3. **Hybrid Approach**: Combine AI and human research using this structure
|
||||
|
||||
**Integration Points:**
|
||||
|
||||
- How findings will feed into next phases
|
||||
- Which team members should review results
|
||||
- How to validate findings
|
||||
- When to revisit or expand research
|
||||
|
||||
## Important Notes
|
||||
|
||||
- The quality of the research prompt directly impacts the quality of insights gathered
|
||||
- Be specific rather than general in research questions
|
||||
- Consider both current state and future implications
|
||||
- Balance comprehensiveness with focus
|
||||
- Document assumptions and limitations clearly
|
||||
- Plan for iterative refinement based on initial findings
|
||||
==================== END: .bmad-core/tasks/create-deep-research-prompt.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/create-doc.md ====================
|
||||
# Create Document from Template (YAML Driven)
|
||||
|
||||
|
|
@ -990,7 +695,47 @@ sections:
|
|||
==================== END: .bmad-core/templates/front-end-spec-tmpl.yaml ====================
|
||||
|
||||
==================== START: .bmad-core/data/technical-preferences.md ====================
|
||||
# User-Defined Preferred Patterns and Preferences
|
||||
# Technical Preferences and Architectural Principles
|
||||
|
||||
## Core Principles References
|
||||
|
||||
The following technical principles and standards apply to all BMAD projects:
|
||||
|
||||
### 1. Coding Standards
|
||||
- **Reference:** `coding-standards.md`
|
||||
- **Purpose:** Fundamental coding principles, security practices, and quality standards
|
||||
- **Key Areas:** Code simplicity, dependency management, security, testing, commit standards
|
||||
|
||||
### 2. Twelve-Factor App Principles
|
||||
- **Reference:** `twelve-factor-principles.md`
|
||||
- **Purpose:** Cloud-native application development principles
|
||||
- **Key Areas:** Codebase management, dependencies, config, backing services, build/release/run
|
||||
|
||||
### 3. Microservice Patterns
|
||||
- **Reference:** `microservice-patterns.md`
|
||||
- **Purpose:** Patterns for distributed system architecture
|
||||
- **Key Areas:** Service decomposition, communication patterns, data management, resilience
|
||||
|
||||
## Application Guidelines
|
||||
|
||||
1. **During Architecture Design:**
|
||||
- Apply twelve-factor principles for cloud-native applications
|
||||
- Consider microservice patterns for complex distributed systems
|
||||
- Document pattern choices in Architecture Decision Records (ADRs)
|
||||
|
||||
2. **During Implementation:**
|
||||
- Follow coding standards for all code generation
|
||||
- Apply security principles by default
|
||||
- Ensure testability and maintainability
|
||||
|
||||
3. **Technology Selection:**
|
||||
- Prefer simple, proven solutions over complex ones
|
||||
- Minimize dependencies unless explicitly justified
|
||||
- Consider operational complexity alongside technical capabilities
|
||||
|
||||
## User-Defined Preferences
|
||||
|
||||
_Add project-specific technical preferences below:_
|
||||
|
||||
None Listed
|
||||
==================== END: .bmad-core/data/technical-preferences.md ====================
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -2071,7 +2071,47 @@ This checklist serves as a comprehensive framework for validating infrastructure
|
|||
==================== END: .bmad-infrastructure-devops/checklists/infrastructure-checklist.md ====================
|
||||
|
||||
==================== START: .bmad-infrastructure-devops/data/technical-preferences.md ====================
|
||||
# User-Defined Preferred Patterns and Preferences
|
||||
# Technical Preferences and Architectural Principles
|
||||
|
||||
## Core Principles References
|
||||
|
||||
The following technical principles and standards apply to all BMAD projects:
|
||||
|
||||
### 1. Coding Standards
|
||||
- **Reference:** `coding-standards.md`
|
||||
- **Purpose:** Fundamental coding principles, security practices, and quality standards
|
||||
- **Key Areas:** Code simplicity, dependency management, security, testing, commit standards
|
||||
|
||||
### 2. Twelve-Factor App Principles
|
||||
- **Reference:** `twelve-factor-principles.md`
|
||||
- **Purpose:** Cloud-native application development principles
|
||||
- **Key Areas:** Codebase management, dependencies, config, backing services, build/release/run
|
||||
|
||||
### 3. Microservice Patterns
|
||||
- **Reference:** `microservice-patterns.md`
|
||||
- **Purpose:** Patterns for distributed system architecture
|
||||
- **Key Areas:** Service decomposition, communication patterns, data management, resilience
|
||||
|
||||
## Application Guidelines
|
||||
|
||||
1. **During Architecture Design:**
|
||||
- Apply twelve-factor principles for cloud-native applications
|
||||
- Consider microservice patterns for complex distributed systems
|
||||
- Document pattern choices in Architecture Decision Records (ADRs)
|
||||
|
||||
2. **During Implementation:**
|
||||
- Follow coding standards for all code generation
|
||||
- Apply security principles by default
|
||||
- Ensure testability and maintainability
|
||||
|
||||
3. **Technology Selection:**
|
||||
- Prefer simple, proven solutions over complex ones
|
||||
- Minimize dependencies unless explicitly justified
|
||||
- Consider operational complexity alongside technical capabilities
|
||||
|
||||
## User-Defined Preferences
|
||||
|
||||
_Add project-specific technical preferences below:_
|
||||
|
||||
None Listed
|
||||
==================== END: .bmad-infrastructure-devops/data/technical-preferences.md ====================
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue