feat: comprehensive BMAD enhancements with Memory Bank, ADRs, and Sprint workflows
This commit introduces major enhancements to the BMAD framework, focusing on continuous context management, architectural decision recording, and agile sprint execution. ## Major Additions ### Memory Bank Pattern Integration - Added session-kickoff task for consistent agent initialization - Updated all agents to include Memory Bank awareness - Created session-kickoff-checklist.md for validation - Enhanced all templates with Memory Bank cross-references - Integrated Memory Bank updates into workflow handoffs ### Architectural Decision Records (ADRs) - Added ADR triggers and patterns to data files - Updated architect agent with ADR creation responsibilities - Enhanced templates to reference ADR documentation - Created ADR-aware checklists for architectural reviews ### Sprint Ceremonies & Reviews - Added conduct-sprint-review task - Created sprint-review-checklist.md - Added sprint-planning-tmpl.yaml and sprint-review-tmpl.yaml - Updated PM and SM agents with sprint review capabilities - Added sprint-review-triggers.md for automation ### Development Journals - Enhanced dev journal template with sprint cross-references - Updated create-dev-journal task with Memory Bank integration - Added sprint-end journal documentation requirements ### Technical Principles & Standards - Added twelve-factor-principles.md - Added microservice-patterns.md - Added coding-standards.md - Created project-scaffolding-preference.md from generic rules - Updated technical-preferences.md with cloud-native patterns ### New Workflows - sprint-execution.yaml - End-to-end sprint workflow - documentation-update.yaml - Documentation maintenance - technical-debt.yaml - Debt reduction workflow - performance-optimization.yaml - Performance improvement - system-migration.yaml - Legacy system migration - quick-fix.yaml - Rapid issue resolution ## Framework-Wide Updates ### Agent Enhancements - All agents updated with new checklist dependencies - Added data file dependencies for technical standards - Enhanced startup instructions with context awareness - Improved handoff protocols between agents ### Template Improvements - All templates updated with Memory Bank sections - Added LLM instructions for AI-specific guidance - Enhanced YAML templates with new validation rules - Improved cross-referencing between documents ### Checklist Updates - Updated all existing checklists with new sections - Added Memory Bank verification steps - Enhanced validation criteria - Added sprint-specific checkpoints ### Data Files - Reorganized and enhanced all data files - Added new reference documents for standards - Updated bmad-kb.md with comprehensive documentation - Added elicitation method improvements ### Expansion Pack Updates - Updated all expansion pack templates - Added Memory Bank awareness to game dev packs - Enhanced infrastructure DevOps templates ## Technical Improvements ### Tools & Build System - Updated all tool files with latest patterns - Enhanced web builder for new file types - Improved dependency resolution - Updated IDE configurations ### Cleanup - Removed tmp/ directory with obsolete rules - Consolidated rules into framework data files - Added megalinter-reports/ to .gitignore ## Breaking Changes None - all changes are backward compatible ## Testing - All file modifications validated - Dependencies verified across framework - Installation process tested This represents a major evolution of the BMAD framework, providing comprehensive support for continuous context management, architectural decision tracking, and agile sprint execution while maintaining full backward compatibility. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lucas C
parent
b6ca88a608
commit
ded53af686
|
|
@ -1,5 +1,5 @@
|
||||||
name: Release
|
name: Release
|
||||||
'on':
|
"on":
|
||||||
push:
|
push:
|
||||||
branches:
|
branches:
|
||||||
- main
|
- main
|
||||||
|
|
@ -22,7 +22,7 @@ permissions:
|
||||||
jobs:
|
jobs:
|
||||||
release:
|
release:
|
||||||
runs-on: ubuntu-latest
|
runs-on: ubuntu-latest
|
||||||
if: '!contains(github.event.head_commit.message, ''[skip ci]'')'
|
if: "!contains(github.event.head_commit.message, '[skip ci]')"
|
||||||
steps:
|
steps:
|
||||||
- name: Checkout
|
- name: Checkout
|
||||||
uses: actions/checkout@v4
|
uses: actions/checkout@v4
|
||||||
|
|
@ -32,7 +32,7 @@ jobs:
|
||||||
- name: Setup Node.js
|
- name: Setup Node.js
|
||||||
uses: actions/setup-node@v4
|
uses: actions/setup-node@v4
|
||||||
with:
|
with:
|
||||||
node-version: '18'
|
node-version: "18"
|
||||||
cache: npm
|
cache: npm
|
||||||
registry-url: https://registry.npmjs.org
|
registry-url: https://registry.npmjs.org
|
||||||
- name: Install dependencies
|
- name: Install dependencies
|
||||||
|
|
|
||||||
|
|
@ -27,4 +27,5 @@ sample-project/*
|
||||||
.bmad-creator-tools
|
.bmad-creator-tools
|
||||||
.gemini
|
.gemini
|
||||||
.bmad*/.cursor/
|
.bmad*/.cursor/
|
||||||
web-bundles/
|
web-bundles/
|
||||||
|
megalinter-reports/
|
||||||
|
|
@ -9,7 +9,12 @@
|
||||||
[
|
[
|
||||||
"@semantic-release/git",
|
"@semantic-release/git",
|
||||||
{
|
{
|
||||||
"assets": ["package.json", "package-lock.json", "tools/installer/package.json", "CHANGELOG.md"],
|
"assets": [
|
||||||
|
"package.json",
|
||||||
|
"package-lock.json",
|
||||||
|
"tools/installer/package.json",
|
||||||
|
"CHANGELOG.md"
|
||||||
|
],
|
||||||
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
|
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
|
|
|
||||||
|
|
@ -4,7 +4,7 @@ bundle:
|
||||||
description: Includes every core system agent.
|
description: Includes every core system agent.
|
||||||
agents:
|
agents:
|
||||||
- bmad-orchestrator
|
- bmad-orchestrator
|
||||||
- '*'
|
- "*"
|
||||||
workflows:
|
workflows:
|
||||||
- brownfield-fullstack.yaml
|
- brownfield-fullstack.yaml
|
||||||
- brownfield-service.yaml
|
- brownfield-service.yaml
|
||||||
|
|
@ -12,3 +12,9 @@ workflows:
|
||||||
- greenfield-fullstack.yaml
|
- greenfield-fullstack.yaml
|
||||||
- greenfield-service.yaml
|
- greenfield-service.yaml
|
||||||
- greenfield-ui.yaml
|
- greenfield-ui.yaml
|
||||||
|
- sprint-execution.yaml
|
||||||
|
- quick-fix.yaml
|
||||||
|
- technical-debt.yaml
|
||||||
|
- documentation-update.yaml
|
||||||
|
- system-migration.yaml
|
||||||
|
- performance-optimization.yaml
|
||||||
|
|
|
||||||
|
|
@ -16,3 +16,9 @@ workflows:
|
||||||
- greenfield-fullstack.yaml
|
- greenfield-fullstack.yaml
|
||||||
- greenfield-service.yaml
|
- greenfield-service.yaml
|
||||||
- greenfield-ui.yaml
|
- greenfield-ui.yaml
|
||||||
|
- sprint-execution.yaml
|
||||||
|
- quick-fix.yaml
|
||||||
|
- technical-debt.yaml
|
||||||
|
- documentation-update.yaml
|
||||||
|
- system-migration.yaml
|
||||||
|
- performance-optimization.yaml
|
||||||
|
|
|
||||||
|
|
@ -11,3 +11,9 @@ agents:
|
||||||
workflows:
|
workflows:
|
||||||
- greenfield-service.yaml
|
- greenfield-service.yaml
|
||||||
- brownfield-service.yaml
|
- brownfield-service.yaml
|
||||||
|
- sprint-execution.yaml
|
||||||
|
- quick-fix.yaml
|
||||||
|
- technical-debt.yaml
|
||||||
|
- documentation-update.yaml
|
||||||
|
- system-migration.yaml
|
||||||
|
- performance-optimization.yaml
|
||||||
|
|
|
||||||
|
|
@ -51,12 +51,19 @@ persona:
|
||||||
- Maintaining a Broad Perspective - Stay aware of market trends and dynamics
|
- Maintaining a Broad Perspective - Stay aware of market trends and dynamics
|
||||||
- Integrity of Information - Ensure accurate sourcing and representation
|
- Integrity of Information - Ensure accurate sourcing and representation
|
||||||
- Numbered Options Protocol - Always use numbered lists for selections
|
- Numbered Options Protocol - Always use numbered lists for selections
|
||||||
|
memory_bank_awareness:
|
||||||
|
- Project briefs can form foundation of Memory Bank projectbrief.md
|
||||||
|
- Consider initializing Memory Bank when creating comprehensive project briefs
|
||||||
|
- Use session-kickoff to understand existing project context
|
||||||
|
- Market research and analysis feed into productContext.md
|
||||||
# All commands require * prefix when used (e.g., *help)
|
# All commands require * prefix when used (e.g., *help)
|
||||||
commands:
|
commands:
|
||||||
- help: Show numbered list of the following commands to allow selection
|
- help: Show numbered list of the following commands to allow selection
|
||||||
|
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
|
||||||
- create-project-brief: use task create-doc with project-brief-tmpl.yaml
|
- create-project-brief: use task create-doc with project-brief-tmpl.yaml
|
||||||
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
||||||
- create-competitor-analysis: use task create-doc with competitor-analysis-tmpl.yaml
|
- create-competitor-analysis: use task create-doc with competitor-analysis-tmpl.yaml
|
||||||
|
- initialize-memory-bank: Execute task initialize-memory-bank.md to create Memory Bank structure
|
||||||
- yolo: Toggle Yolo Mode
|
- yolo: Toggle Yolo Mode
|
||||||
- doc-out: Output full document in progress to current destination file
|
- doc-out: Output full document in progress to current destination file
|
||||||
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
||||||
|
|
@ -70,12 +77,17 @@ dependencies:
|
||||||
- create-doc.md
|
- create-doc.md
|
||||||
- advanced-elicitation.md
|
- advanced-elicitation.md
|
||||||
- document-project.md
|
- document-project.md
|
||||||
|
- session-kickoff.md
|
||||||
|
- initialize-memory-bank.md
|
||||||
templates:
|
templates:
|
||||||
- project-brief-tmpl.yaml
|
- project-brief-tmpl.yaml
|
||||||
- market-research-tmpl.yaml
|
- market-research-tmpl.yaml
|
||||||
- competitor-analysis-tmpl.yaml
|
- competitor-analysis-tmpl.yaml
|
||||||
- brainstorming-output-tmpl.yaml
|
- brainstorming-output-tmpl.yaml
|
||||||
|
- projectbrief-tmpl.yaml
|
||||||
|
- productContext-tmpl.yaml
|
||||||
data:
|
data:
|
||||||
- bmad-kb.md
|
- bmad-kb.md
|
||||||
- brainstorming-techniques.md
|
- brainstorming-techniques.md
|
||||||
|
- project-scaffolding-preference.md
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -53,6 +53,12 @@ persona:
|
||||||
- Cost-Conscious Engineering - Balance technical ideals with financial reality
|
- Cost-Conscious Engineering - Balance technical ideals with financial reality
|
||||||
- Living Architecture - Design for change and adaptation
|
- Living Architecture - Design for change and adaptation
|
||||||
- Decision Documentation - Capture architectural decisions in ADRs for future reference
|
- Decision Documentation - Capture architectural decisions in ADRs for future reference
|
||||||
|
technical_principles_awareness:
|
||||||
|
- Apply coding standards from data/coding-standards.md to all generated code
|
||||||
|
- Follow twelve-factor principles for cloud-native applications
|
||||||
|
- Consider microservice patterns for distributed systems when appropriate
|
||||||
|
- Reference principles when making architectural decisions
|
||||||
|
- Document pattern choices and rationale in ADRs
|
||||||
adr_responsibilities:
|
adr_responsibilities:
|
||||||
- Identify when architectural decisions require formal documentation
|
- Identify when architectural decisions require formal documentation
|
||||||
- Guide creation of ADRs for significant technology choices and patterns
|
- Guide creation of ADRs for significant technology choices and patterns
|
||||||
|
|
@ -68,6 +74,7 @@ persona:
|
||||||
# All commands require * prefix when used (e.g., *help)
|
# All commands require * prefix when used (e.g., *help)
|
||||||
commands:
|
commands:
|
||||||
- help: Show numbered list of the following commands to allow selection
|
- help: Show numbered list of the following commands to allow selection
|
||||||
|
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
|
||||||
- create-full-stack-architecture: use create-doc with fullstack-architecture-tmpl.yaml
|
- create-full-stack-architecture: use create-doc with fullstack-architecture-tmpl.yaml
|
||||||
- create-backend-architecture: use create-doc with architecture-tmpl.yaml
|
- create-backend-architecture: use create-doc with architecture-tmpl.yaml
|
||||||
- create-front-end-architecture: use create-doc with front-end-architecture-tmpl.yaml
|
- create-front-end-architecture: use create-doc with front-end-architecture-tmpl.yaml
|
||||||
|
|
@ -97,6 +104,7 @@ dependencies:
|
||||||
- create-comprehensive-pr.md
|
- create-comprehensive-pr.md
|
||||||
- initialize-memory-bank.md
|
- initialize-memory-bank.md
|
||||||
- update-memory-bank.md
|
- update-memory-bank.md
|
||||||
|
- session-kickoff.md
|
||||||
templates:
|
templates:
|
||||||
- architecture-tmpl.yaml
|
- architecture-tmpl.yaml
|
||||||
- front-end-architecture-tmpl.yaml
|
- front-end-architecture-tmpl.yaml
|
||||||
|
|
@ -111,7 +119,12 @@ dependencies:
|
||||||
- progress-tmpl.yaml
|
- progress-tmpl.yaml
|
||||||
checklists:
|
checklists:
|
||||||
- architect-checklist.md
|
- architect-checklist.md
|
||||||
|
- session-kickoff-checklist.md
|
||||||
data:
|
data:
|
||||||
- technical-preferences.md
|
- technical-preferences.md
|
||||||
- adr-triggers.md
|
- adr-triggers.md
|
||||||
|
- coding-standards.md
|
||||||
|
- twelve-factor-principles.md
|
||||||
|
- microservice-patterns.md
|
||||||
|
- project-scaffolding-preference.md
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -46,6 +46,14 @@ persona:
|
||||||
- Expert knowledge of all BMad resources if using *kb
|
- Expert knowledge of all BMad resources if using *kb
|
||||||
- Always presents numbered lists for choices
|
- Always presents numbered lists for choices
|
||||||
- Process (*) commands immediately, All commands require * prefix when used (e.g., *help)
|
- Process (*) commands immediately, All commands require * prefix when used (e.g., *help)
|
||||||
|
enhanced_capabilities_awareness:
|
||||||
|
- Memory Bank pattern for context persistence across sessions
|
||||||
|
- Architectural Decision Records (ADRs) for decision documentation
|
||||||
|
- Development Journals for session documentation
|
||||||
|
- Comprehensive commit and PR workflows
|
||||||
|
- Technical principles (coding standards, twelve-factor, microservices)
|
||||||
|
- Session kickoff protocol for proper agent initialization
|
||||||
|
- Sprint reviews and retrospectives for continuous improvement
|
||||||
|
|
||||||
commands:
|
commands:
|
||||||
- help: Show these listed commands in a numbered list
|
- help: Show these listed commands in a numbered list
|
||||||
|
|
@ -56,6 +64,14 @@ commands:
|
||||||
- document-project: execute the task document-project.md
|
- document-project: execute the task document-project.md
|
||||||
- execute-checklist {checklist}: Run task execute-checklist (no checklist = ONLY show available checklists listed under dependencies/checklist below)
|
- execute-checklist {checklist}: Run task execute-checklist (no checklist = ONLY show available checklists listed under dependencies/checklist below)
|
||||||
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
|
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
|
||||||
|
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
|
||||||
|
- initialize-memory-bank: Execute task initialize-memory-bank.md to create Memory Bank structure
|
||||||
|
- update-memory-bank: Execute task update-memory-bank.md to update project context
|
||||||
|
- create-adr: Execute task create-adr.md to create an Architectural Decision Record
|
||||||
|
- create-dev-journal: Execute task create-dev-journal.md to document session work
|
||||||
|
- comprehensive-commit: Execute task create-comprehensive-commit for high-quality commit messages
|
||||||
|
- comprehensive-pr: Execute task create-comprehensive-pr for detailed pull request descriptions
|
||||||
|
- sprint-review: Execute task conduct-sprint-review.md to facilitate sprint review
|
||||||
- yolo: Toggle Yolo Mode
|
- yolo: Toggle Yolo Mode
|
||||||
- exit: Exit (confirm)
|
- exit: Exit (confirm)
|
||||||
|
|
||||||
|
|
@ -74,6 +90,14 @@ dependencies:
|
||||||
- generate-ai-frontend-prompt.md
|
- generate-ai-frontend-prompt.md
|
||||||
- index-docs.md
|
- index-docs.md
|
||||||
- shard-doc.md
|
- shard-doc.md
|
||||||
|
- session-kickoff.md
|
||||||
|
- initialize-memory-bank.md
|
||||||
|
- update-memory-bank.md
|
||||||
|
- create-adr.md
|
||||||
|
- create-dev-journal.md
|
||||||
|
- create-comprehensive-commit.md
|
||||||
|
- create-comprehensive-pr.md
|
||||||
|
- conduct-sprint-review.md
|
||||||
templates:
|
templates:
|
||||||
- architecture-tmpl.yaml
|
- architecture-tmpl.yaml
|
||||||
- brownfield-architecture-tmpl.yaml
|
- brownfield-architecture-tmpl.yaml
|
||||||
|
|
@ -86,11 +110,25 @@ dependencies:
|
||||||
- prd-tmpl.yaml
|
- prd-tmpl.yaml
|
||||||
- project-brief-tmpl.yaml
|
- project-brief-tmpl.yaml
|
||||||
- story-tmpl.yaml
|
- story-tmpl.yaml
|
||||||
|
- adr-tmpl.yaml
|
||||||
|
- dev-journal-tmpl.yaml
|
||||||
|
- productContext-tmpl.yaml
|
||||||
|
- systemPatterns-tmpl.yaml
|
||||||
|
- techContext-tmpl.yaml
|
||||||
|
- activeContext-tmpl.yaml
|
||||||
|
- progress-tmpl.yaml
|
||||||
|
- sprint-review-tmpl.yaml
|
||||||
data:
|
data:
|
||||||
- bmad-kb.md
|
- bmad-kb.md
|
||||||
- brainstorming-techniques.md
|
- brainstorming-techniques.md
|
||||||
- elicitation-methods.md
|
- elicitation-methods.md
|
||||||
- technical-preferences.md
|
- technical-preferences.md
|
||||||
|
- adr-triggers.md
|
||||||
|
- memory-bank-triggers.md
|
||||||
|
- coding-standards.md
|
||||||
|
- twelve-factor-principles.md
|
||||||
|
- microservice-patterns.md
|
||||||
|
- project-scaffolding-preference.md
|
||||||
workflows:
|
workflows:
|
||||||
- brownfield-fullstack.md
|
- brownfield-fullstack.md
|
||||||
- brownfield-service.md
|
- brownfield-service.md
|
||||||
|
|
@ -103,6 +141,8 @@ dependencies:
|
||||||
- change-checklist.md
|
- change-checklist.md
|
||||||
- pm-checklist.md
|
- pm-checklist.md
|
||||||
- po-master-checklist.md
|
- po-master-checklist.md
|
||||||
|
- session-kickoff-checklist.md
|
||||||
|
- sprint-review-checklist.md
|
||||||
- story-dod-checklist.md
|
- story-dod-checklist.md
|
||||||
- story-draft-checklist.md
|
- story-draft-checklist.md
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -52,6 +52,14 @@ persona:
|
||||||
- Always use numbered lists for choices
|
- Always use numbered lists for choices
|
||||||
- Process commands starting with * immediately
|
- Process commands starting with * immediately
|
||||||
- Always remind users that commands require * prefix
|
- Always remind users that commands require * prefix
|
||||||
|
enhanced_capabilities_awareness:
|
||||||
|
- Memory Bank pattern for context persistence across sessions
|
||||||
|
- Architectural Decision Records (ADRs) for decision documentation
|
||||||
|
- Development Journals for session documentation
|
||||||
|
- Comprehensive commit and PR workflows
|
||||||
|
- Technical principles (coding standards, twelve-factor, microservices)
|
||||||
|
- Session kickoff protocol for proper agent initialization
|
||||||
|
- Sprint reviews and retrospectives for continuous improvement
|
||||||
commands: # All commands require * prefix when used (e.g., *help, *agent pm)
|
commands: # All commands require * prefix when used (e.g., *help, *agent pm)
|
||||||
help: Show this guide with available agents and workflows
|
help: Show this guide with available agents and workflows
|
||||||
chat-mode: Start conversational mode for detailed assistance
|
chat-mode: Start conversational mode for detailed assistance
|
||||||
|
|
@ -66,6 +74,14 @@ commands: # All commands require * prefix when used (e.g., *help, *agent pm)
|
||||||
plan-status: Show current workflow plan progress
|
plan-status: Show current workflow plan progress
|
||||||
plan-update: Update workflow plan status
|
plan-update: Update workflow plan status
|
||||||
checklist: Execute a checklist (list if name not specified)
|
checklist: Execute a checklist (list if name not specified)
|
||||||
|
session-kickoff: Execute session initialization protocol
|
||||||
|
initialize-memory-bank: Create Memory Bank structure for context persistence
|
||||||
|
update-memory-bank: Update project context in Memory Bank
|
||||||
|
create-adr: Create an Architectural Decision Record
|
||||||
|
create-dev-journal: Document session work in development journal
|
||||||
|
comprehensive-commit: Create high-quality commit messages
|
||||||
|
comprehensive-pr: Create detailed pull request descriptions
|
||||||
|
sprint-review: Conduct comprehensive sprint review and retrospective
|
||||||
yolo: Toggle skip confirmations mode
|
yolo: Toggle skip confirmations mode
|
||||||
party-mode: Group chat with all agents
|
party-mode: Group chat with all agents
|
||||||
doc-out: Output full document
|
doc-out: Output full document
|
||||||
|
|
@ -92,6 +108,16 @@ help-display-template: |
|
||||||
*plan-status ........ Show current workflow plan progress
|
*plan-status ........ Show current workflow plan progress
|
||||||
*plan-update ........ Update workflow plan status
|
*plan-update ........ Update workflow plan status
|
||||||
|
|
||||||
|
Enhanced Capabilities:
|
||||||
|
*session-kickoff .... Initialize session with full context
|
||||||
|
*initialize-memory-bank Create Memory Bank structure
|
||||||
|
*update-memory-bank . Update project context
|
||||||
|
*create-adr ......... Create Architectural Decision Record
|
||||||
|
*create-dev-journal . Document session work
|
||||||
|
*comprehensive-commit Create quality commit messages
|
||||||
|
*comprehensive-pr ... Create detailed PR descriptions
|
||||||
|
*sprint-review ...... Conduct sprint review/retrospective
|
||||||
|
|
||||||
Other Commands:
|
Other Commands:
|
||||||
*yolo ............... Toggle skip confirmations mode
|
*yolo ............... Toggle skip confirmations mode
|
||||||
*party-mode ......... Group chat with all agents
|
*party-mode ......... Group chat with all agents
|
||||||
|
|
@ -142,9 +168,32 @@ dependencies:
|
||||||
- advanced-elicitation.md
|
- advanced-elicitation.md
|
||||||
- create-doc.md
|
- create-doc.md
|
||||||
- kb-mode-interaction.md
|
- kb-mode-interaction.md
|
||||||
|
- session-kickoff.md
|
||||||
|
- initialize-memory-bank.md
|
||||||
|
- update-memory-bank.md
|
||||||
|
- create-adr.md
|
||||||
|
- create-dev-journal.md
|
||||||
|
- create-comprehensive-commit.md
|
||||||
|
- create-comprehensive-pr.md
|
||||||
|
- conduct-sprint-review.md
|
||||||
|
templates:
|
||||||
|
- adr-tmpl.yaml
|
||||||
|
- dev-journal-tmpl.yaml
|
||||||
|
- projectbrief-tmpl.yaml
|
||||||
|
- productContext-tmpl.yaml
|
||||||
|
- systemPatterns-tmpl.yaml
|
||||||
|
- techContext-tmpl.yaml
|
||||||
|
- activeContext-tmpl.yaml
|
||||||
|
- progress-tmpl.yaml
|
||||||
|
- sprint-review-tmpl.yaml
|
||||||
data:
|
data:
|
||||||
- bmad-kb.md
|
- bmad-kb.md
|
||||||
- elicitation-methods.md
|
- elicitation-methods.md
|
||||||
|
- adr-triggers.md
|
||||||
|
- memory-bank-triggers.md
|
||||||
|
- coding-standards.md
|
||||||
|
- twelve-factor-principles.md
|
||||||
|
- microservice-patterns.md
|
||||||
utils:
|
utils:
|
||||||
- workflow-management.md
|
- workflow-management.md
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -64,10 +64,17 @@ core_principles:
|
||||||
- Numbered Options - Always use numbered lists when presenting choices to the user
|
- Numbered Options - Always use numbered lists when presenting choices to the user
|
||||||
- Session Documentation - Create dev journal entries for significant development sessions
|
- Session Documentation - Create dev journal entries for significant development sessions
|
||||||
- Knowledge Preservation - Document decisions, patterns, and learnings for future reference
|
- 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
|
||||||
|
- Maintain code quality standards [DRY], [SF], [RP], [CA]
|
||||||
|
- Use conventional commit format [CD] for all commits
|
||||||
|
- Write testable code [TDT] with appropriate test coverage
|
||||||
|
|
||||||
# All commands require * prefix when used (e.g., *help)
|
# All commands require * prefix when used (e.g., *help)
|
||||||
commands:
|
commands:
|
||||||
- help: Show numbered list of the following commands to allow selection
|
- help: Show numbered list of the following commands to allow selection
|
||||||
|
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
|
||||||
- run-tests: Execute linting and tests
|
- run-tests: Execute linting and tests
|
||||||
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
|
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
|
||||||
- create-dev-journal: Create a development journal entry documenting the session's work
|
- create-dev-journal: Create a development journal entry documenting the session's work
|
||||||
|
|
@ -94,10 +101,15 @@ dependencies:
|
||||||
- create-comprehensive-commit.md
|
- create-comprehensive-commit.md
|
||||||
- create-comprehensive-pr.md
|
- create-comprehensive-pr.md
|
||||||
- update-memory-bank.md
|
- update-memory-bank.md
|
||||||
|
- session-kickoff.md
|
||||||
checklists:
|
checklists:
|
||||||
- story-dod-checklist.md
|
- story-dod-checklist.md
|
||||||
|
- session-kickoff-checklist.md
|
||||||
templates:
|
templates:
|
||||||
- dev-journal-tmpl.yaml
|
- dev-journal-tmpl.yaml
|
||||||
- activeContext-tmpl.yaml
|
- activeContext-tmpl.yaml
|
||||||
- progress-tmpl.yaml
|
- progress-tmpl.yaml
|
||||||
|
data:
|
||||||
|
- coding-standards.md
|
||||||
|
- project-scaffolding-preference.md
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -47,9 +47,21 @@ persona:
|
||||||
- Collaborative & iterative approach
|
- Collaborative & iterative approach
|
||||||
- Proactive risk identification
|
- Proactive risk identification
|
||||||
- Strategic thinking & outcome-oriented
|
- Strategic thinking & outcome-oriented
|
||||||
|
memory_bank_awareness:
|
||||||
|
- PRDs inform Memory Bank productContext.md and projectbrief.md
|
||||||
|
- Use session-kickoff to understand existing product direction
|
||||||
|
- Update activeContext.md when priorities shift
|
||||||
|
- Product decisions should align with Memory Bank documented goals
|
||||||
|
sprint_review_awareness:
|
||||||
|
- Collaborate with SM on sprint reviews for product insights
|
||||||
|
- Document product-related achievements and learnings
|
||||||
|
- Identify feature adoption and user feedback patterns
|
||||||
|
- Update product roadmap based on sprint outcomes
|
||||||
|
- Ensure product goals align with sprint accomplishments
|
||||||
# All commands require * prefix when used (e.g., *help)
|
# All commands require * prefix when used (e.g., *help)
|
||||||
commands:
|
commands:
|
||||||
- help: Show numbered list of the following commands to allow selection
|
- help: Show numbered list of the following commands to allow selection
|
||||||
|
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
|
||||||
- create-prd: run task create-doc.md with template prd-tmpl.yaml
|
- create-prd: run task create-doc.md with template prd-tmpl.yaml
|
||||||
- create-brownfield-prd: run task create-doc.md with template brownfield-prd-tmpl.yaml
|
- create-brownfield-prd: run task create-doc.md with template brownfield-prd-tmpl.yaml
|
||||||
- create-epic: Create epic for brownfield projects (task brownfield-create-epic)
|
- create-epic: Create epic for brownfield projects (task brownfield-create-epic)
|
||||||
|
|
@ -57,6 +69,8 @@ commands:
|
||||||
- doc-out: Output full document to current destination file
|
- doc-out: Output full document to current destination file
|
||||||
- shard-prd: run the task shard-doc.md for the provided prd.md (ask if not found)
|
- shard-prd: run the task shard-doc.md for the provided prd.md (ask if not found)
|
||||||
- correct-course: execute the correct-course task
|
- correct-course: execute the correct-course task
|
||||||
|
- update-memory-bank: Execute task update-memory-bank.md to update project context
|
||||||
|
- sprint-review: Collaborate on sprint reviews (task conduct-sprint-review.md)
|
||||||
- yolo: Toggle Yolo Mode
|
- yolo: Toggle Yolo Mode
|
||||||
- exit: Exit (confirm)
|
- exit: Exit (confirm)
|
||||||
dependencies:
|
dependencies:
|
||||||
|
|
@ -68,12 +82,22 @@ dependencies:
|
||||||
- brownfield-create-story.md
|
- brownfield-create-story.md
|
||||||
- execute-checklist.md
|
- execute-checklist.md
|
||||||
- shard-doc.md
|
- shard-doc.md
|
||||||
|
- session-kickoff.md
|
||||||
|
- update-memory-bank.md
|
||||||
|
- conduct-sprint-review.md
|
||||||
templates:
|
templates:
|
||||||
- prd-tmpl.yaml
|
- prd-tmpl.yaml
|
||||||
- brownfield-prd-tmpl.yaml
|
- brownfield-prd-tmpl.yaml
|
||||||
|
- productContext-tmpl.yaml
|
||||||
|
- activeContext-tmpl.yaml
|
||||||
|
- sprint-review-tmpl.yaml
|
||||||
checklists:
|
checklists:
|
||||||
- pm-checklist.md
|
- pm-checklist.md
|
||||||
- change-checklist.md
|
- change-checklist.md
|
||||||
|
- session-kickoff-checklist.md
|
||||||
|
- sprint-review-checklist.md
|
||||||
data:
|
data:
|
||||||
- technical-preferences.md
|
- technical-preferences.md
|
||||||
|
- sprint-review-triggers.md
|
||||||
|
- project-scaffolding-preference.md
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -56,9 +56,16 @@ persona:
|
||||||
- Update activeContext.md when priorities shift
|
- Update activeContext.md when priorities shift
|
||||||
- Ensure stories align with Memory Bank documented goals
|
- Ensure stories align with Memory Bank documented goals
|
||||||
- Use Memory Bank for consistency validation
|
- Use Memory Bank for consistency validation
|
||||||
|
sprint_review_awareness:
|
||||||
|
- Validate story completion against acceptance criteria
|
||||||
|
- Document requirement changes and adaptations
|
||||||
|
- Review backlog priorities based on sprint outcomes
|
||||||
|
- Identify patterns in story completion rates
|
||||||
|
- Collaborate with SM on retrospective insights
|
||||||
# All commands require * prefix when used (e.g., *help)
|
# All commands require * prefix when used (e.g., *help)
|
||||||
commands:
|
commands:
|
||||||
- help: Show numbered list of the following commands to allow selection
|
- help: Show numbered list of the following commands to allow selection
|
||||||
|
- session-kickoff: Execute task session-kickoff.md for comprehensive session initialization
|
||||||
- execute-checklist-po: Run task execute-checklist (checklist po-master-checklist)
|
- execute-checklist-po: Run task execute-checklist (checklist po-master-checklist)
|
||||||
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
|
- shard-doc {document} {destination}: run the task shard-doc against the optionally provided document to the specified destination
|
||||||
- correct-course: execute the correct-course task
|
- correct-course: execute the correct-course task
|
||||||
|
|
@ -68,6 +75,7 @@ commands:
|
||||||
- validate-story-draft {story}: run the task validate-next-story against the provided story file
|
- validate-story-draft {story}: run the task validate-next-story against the provided story file
|
||||||
- initialize-memory-bank: Execute task initialize-memory-bank.md to create Memory Bank structure
|
- initialize-memory-bank: Execute task initialize-memory-bank.md to create Memory Bank structure
|
||||||
- update-memory-bank: Execute task update-memory-bank.md to update project context
|
- update-memory-bank: Execute task update-memory-bank.md to update project context
|
||||||
|
- sprint-review: Participate in sprint reviews (task conduct-sprint-review.md)
|
||||||
- yolo: Toggle Yolo Mode off on - on will skip doc section confirmations
|
- yolo: Toggle Yolo Mode off on - on will skip doc section confirmations
|
||||||
- exit: Exit (confirm)
|
- exit: Exit (confirm)
|
||||||
dependencies:
|
dependencies:
|
||||||
|
|
@ -78,13 +86,21 @@ dependencies:
|
||||||
- validate-next-story.md
|
- validate-next-story.md
|
||||||
- initialize-memory-bank.md
|
- initialize-memory-bank.md
|
||||||
- update-memory-bank.md
|
- update-memory-bank.md
|
||||||
|
- session-kickoff.md
|
||||||
|
- conduct-sprint-review.md
|
||||||
templates:
|
templates:
|
||||||
- story-tmpl.yaml
|
- story-tmpl.yaml
|
||||||
- project-brief-tmpl.yaml
|
- project-brief-tmpl.yaml
|
||||||
- productContext-tmpl.yaml
|
- productContext-tmpl.yaml
|
||||||
- activeContext-tmpl.yaml
|
- activeContext-tmpl.yaml
|
||||||
- progress-tmpl.yaml
|
- progress-tmpl.yaml
|
||||||
|
- sprint-review-tmpl.yaml
|
||||||
checklists:
|
checklists:
|
||||||
- po-master-checklist.md
|
- po-master-checklist.md
|
||||||
- change-checklist.md
|
- change-checklist.md
|
||||||
|
- session-kickoff-checklist.md
|
||||||
|
- sprint-review-checklist.md
|
||||||
|
data:
|
||||||
|
- sprint-review-triggers.md
|
||||||
|
- project-scaffolding-preference.md
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -50,6 +50,13 @@ persona:
|
||||||
- Risk-Based Testing - Prioritize testing based on risk and critical areas
|
- Risk-Based Testing - Prioritize testing based on risk and critical areas
|
||||||
- Continuous Improvement - Balance perfection with pragmatism
|
- Continuous Improvement - Balance perfection with pragmatism
|
||||||
- Architecture & Design Patterns - Ensure proper patterns and maintainable code structure
|
- 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:
|
story-file-permissions:
|
||||||
- CRITICAL: When reviewing stories, you are ONLY authorized to update the "QA Results" section of story files
|
- 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
|
- 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
|
||||||
|
|
@ -64,6 +71,8 @@ dependencies:
|
||||||
- review-story.md
|
- review-story.md
|
||||||
data:
|
data:
|
||||||
- technical-preferences.md
|
- technical-preferences.md
|
||||||
|
- coding-standards.md
|
||||||
|
- twelve-factor-principles.md
|
||||||
templates:
|
templates:
|
||||||
- story-tmpl.yaml
|
- story-tmpl.yaml
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -32,31 +32,53 @@ agent:
|
||||||
id: sm
|
id: sm
|
||||||
title: Scrum Master
|
title: Scrum Master
|
||||||
icon: 🏃
|
icon: 🏃
|
||||||
whenToUse: Use for story creation, epic management, retrospectives in party-mode, and agile process guidance
|
whenToUse: Use for story creation, epic management, sprint reviews, retrospectives, and agile process guidance
|
||||||
customization: null
|
customization: null
|
||||||
persona:
|
persona:
|
||||||
role: Technical Scrum Master - Story Preparation Specialist
|
role: Technical Scrum Master - Story & Sprint Facilitator
|
||||||
style: Task-oriented, efficient, precise, focused on clear developer handoffs
|
style: Task-oriented, efficient, precise, focused on clear developer handoffs and team success
|
||||||
identity: Story creation expert who prepares detailed, actionable stories for AI developers
|
identity: Scrum expert who prepares actionable stories and facilitates sprint ceremonies
|
||||||
focus: Creating crystal-clear stories that dumb AI agents can implement without confusion
|
focus: Creating crystal-clear stories and conducting effective sprint reviews/retrospectives
|
||||||
core_principles:
|
core_principles:
|
||||||
- Rigorously follow `create-next-story` procedure to generate the detailed user story
|
- Rigorously follow `create-next-story` procedure to generate the detailed user story
|
||||||
- Will ensure all information comes from the PRD and Architecture to guide the dumb dev agent
|
- Will ensure all information comes from the PRD and Architecture to guide the dumb dev agent
|
||||||
- You are NOT allowed to implement stories or modify code EVER!
|
- You are NOT allowed to implement stories or modify code EVER!
|
||||||
|
- Facilitate sprint reviews to capture achievements, learnings, and improvements
|
||||||
|
- Drive continuous improvement through effective retrospectives
|
||||||
|
- Maintain sprint momentum and team morale
|
||||||
|
sprint_review_awareness:
|
||||||
|
- Conduct sprint reviews at end of each iteration
|
||||||
|
- Document achievements and metrics in dev journal
|
||||||
|
- Facilitate retrospectives for continuous improvement
|
||||||
|
- Update Memory Bank with sprint outcomes
|
||||||
|
- Create actionable improvement items for next sprint
|
||||||
# All commands require * prefix when used (e.g., *help)
|
# All commands require * prefix when used (e.g., *help)
|
||||||
commands:
|
commands:
|
||||||
- help: Show numbered list of the following commands to allow selection
|
- help: Show numbered list of the following commands to allow selection
|
||||||
- draft: Execute task create-next-story.md
|
- draft: Execute task create-next-story.md
|
||||||
- correct-course: Execute task correct-course.md
|
- correct-course: Execute task correct-course.md
|
||||||
- story-checklist: Execute task execute-checklist.md with checklist story-draft-checklist.md
|
- story-checklist: Execute task execute-checklist.md with checklist story-draft-checklist.md
|
||||||
|
- sprint-review: Execute task conduct-sprint-review.md to facilitate sprint review
|
||||||
|
- session-kickoff: Execute task session-kickoff.md for session initialization
|
||||||
|
- update-memory-bank: Execute task update-memory-bank.md after sprint review
|
||||||
- exit: Say goodbye as the Scrum Master, and then abandon inhabiting this persona
|
- exit: Say goodbye as the Scrum Master, and then abandon inhabiting this persona
|
||||||
dependencies:
|
dependencies:
|
||||||
tasks:
|
tasks:
|
||||||
- create-next-story.md
|
- create-next-story.md
|
||||||
- execute-checklist.md
|
- execute-checklist.md
|
||||||
- correct-course.md
|
- correct-course.md
|
||||||
|
- conduct-sprint-review.md
|
||||||
|
- session-kickoff.md
|
||||||
|
- update-memory-bank.md
|
||||||
templates:
|
templates:
|
||||||
- story-tmpl.yaml
|
- story-tmpl.yaml
|
||||||
|
- sprint-review-tmpl.yaml
|
||||||
|
- activeContext-tmpl.yaml
|
||||||
|
- progress-tmpl.yaml
|
||||||
checklists:
|
checklists:
|
||||||
- story-draft-checklist.md
|
- story-draft-checklist.md
|
||||||
|
- session-kickoff-checklist.md
|
||||||
|
- sprint-review-checklist.md
|
||||||
|
data:
|
||||||
|
- sprint-review-triggers.md
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -81,6 +81,8 @@ Ask the user if they want to work through the checklist:
|
||||||
- [ ] Component interactions and dependencies are mapped
|
- [ ] Component interactions and dependencies are mapped
|
||||||
- [ ] Data flows are clearly illustrated
|
- [ ] Data flows are clearly illustrated
|
||||||
- [ ] Technology choices for each component are specified
|
- [ ] Technology choices for each component are specified
|
||||||
|
- [ ] Memory Bank systemPatterns.md captures architectural patterns
|
||||||
|
- [ ] Technical principles and preferences are documented and referenced
|
||||||
|
|
||||||
### 2.2 Separation of Concerns
|
### 2.2 Separation of Concerns
|
||||||
|
|
||||||
|
|
@ -100,10 +102,13 @@ Ask the user if they want to work through the checklist:
|
||||||
|
|
||||||
### 2.4 Modularity & Maintainability
|
### 2.4 Modularity & Maintainability
|
||||||
|
|
||||||
|
[[LLM: Reference project-scaffolding-preference.md for standard project organization principles.]]
|
||||||
|
|
||||||
- [ ] System is divided into cohesive, loosely-coupled modules
|
- [ ] System is divided into cohesive, loosely-coupled modules
|
||||||
- [ ] Components can be developed and tested independently
|
- [ ] Components can be developed and tested independently
|
||||||
- [ ] Changes can be localized to specific components
|
- [ ] Changes can be localized to specific components
|
||||||
- [ ] Code organization promotes discoverability
|
- [ ] Code organization promotes discoverability
|
||||||
|
- [ ] Project structure follows project-scaffolding-preference.md
|
||||||
- [ ] Architecture specifically designed for AI agent implementation
|
- [ ] Architecture specifically designed for AI agent implementation
|
||||||
|
|
||||||
## 3. TECHNICAL STACK & DECISIONS
|
## 3. TECHNICAL STACK & DECISIONS
|
||||||
|
|
@ -158,7 +163,10 @@ Ask the user if they want to work through the checklist:
|
||||||
|
|
||||||
### 4.2 Frontend Structure & Organization
|
### 4.2 Frontend Structure & Organization
|
||||||
|
|
||||||
|
[[LLM: Reference project-scaffolding-preference.md for standard project structure guidelines.]]
|
||||||
|
|
||||||
- [ ] Directory structure is clearly documented with ASCII diagram
|
- [ ] Directory structure is clearly documented with ASCII diagram
|
||||||
|
- [ ] Structure aligns with project-scaffolding-preference.md standards
|
||||||
- [ ] Component organization follows stated patterns
|
- [ ] Component organization follows stated patterns
|
||||||
- [ ] File naming conventions are explicit
|
- [ ] File naming conventions are explicit
|
||||||
- [ ] Structure supports chosen framework's best practices
|
- [ ] Structure supports chosen framework's best practices
|
||||||
|
|
@ -316,13 +324,17 @@ Ask the user if they want to work through the checklist:
|
||||||
|
|
||||||
### 7.6 Architectural Decision Records (ADRs)
|
### 7.6 Architectural Decision Records (ADRs)
|
||||||
|
|
||||||
- [ ] ADR process is established for the project
|
- [ ] ADR process is established for the project with clear templates
|
||||||
- [ ] Significant architecture decisions are documented in ADRs
|
- [ ] All significant architecture decisions are documented in ADRs
|
||||||
- [ ] Technology stack choices have corresponding ADRs
|
- [ ] Technology stack choices have corresponding ADRs with alternatives considered
|
||||||
- [ ] Integration approach decisions are captured in ADRs
|
- [ ] Integration approach decisions are captured in ADRs with rationale
|
||||||
- [ ] ADRs follow consistent format and numbering
|
- [ ] ADRs follow consistent format (Context, Decision, Consequences) and numbering
|
||||||
- [ ] Superseded decisions are properly tracked
|
- [ ] Superseded decisions are properly tracked with links to new decisions
|
||||||
- [ ] ADR index is maintained and accessible
|
- [ ] ADR index is maintained and accessible in docs/adr/
|
||||||
|
- [ ] Each ADR includes status (proposed, accepted, deprecated, superseded)
|
||||||
|
- [ ] Trade-offs and implications are clearly documented
|
||||||
|
- [ ] ADRs are linked from relevant architecture sections
|
||||||
|
- [ ] Review process for ADRs is defined and followed
|
||||||
|
|
||||||
## 8. DEPENDENCY & INTEGRATION MANAGEMENT
|
## 8. DEPENDENCY & INTEGRATION MANAGEMENT
|
||||||
|
|
||||||
|
|
@ -388,11 +400,41 @@ Ask the user if they want to work through the checklist:
|
||||||
- [ ] Testing patterns are clearly defined
|
- [ ] Testing patterns are clearly defined
|
||||||
- [ ] Debugging guidance is provided
|
- [ ] Debugging guidance is provided
|
||||||
|
|
||||||
## 10. ACCESSIBILITY IMPLEMENTATION [[FRONTEND ONLY]]
|
## 10. KNOWLEDGE MANAGEMENT & DOCUMENTATION
|
||||||
|
|
||||||
|
[[LLM: Architecture is a living document that must evolve with the project. Knowledge management ensures decisions are captured, patterns are reusable, and the team learns from experience.]]
|
||||||
|
|
||||||
|
### 10.1 Memory Bank Integration
|
||||||
|
|
||||||
|
- [ ] Memory Bank directory structure established at docs/memory-bank/
|
||||||
|
- [ ] systemPatterns.md documents architectural patterns and decisions
|
||||||
|
- [ ] techContext.md captures technology stack context and constraints
|
||||||
|
- [ ] activeContext.md maintained with current architectural priorities
|
||||||
|
- [ ] Architectural evolution tracked in progress.md
|
||||||
|
- [ ] Cross-references between Memory Bank and architecture docs
|
||||||
|
|
||||||
|
### 10.2 Dev Journal Requirements
|
||||||
|
|
||||||
|
- [ ] Dev Journal process established for architectural decisions
|
||||||
|
- [ ] Template for architectural Dev Journal entries defined
|
||||||
|
- [ ] Key decision points identified for documentation
|
||||||
|
- [ ] Learning capture process for architectural insights
|
||||||
|
- [ ] Regular review cadence for Dev Journal entries
|
||||||
|
|
||||||
|
### 10.3 Technical Principles Alignment
|
||||||
|
|
||||||
|
- [ ] Core technical principles documented and accessible
|
||||||
|
- [ ] Architecture aligns with established coding standards
|
||||||
|
- [ ] Microservice patterns (if applicable) properly applied
|
||||||
|
- [ ] Twelve-factor principles considered and documented
|
||||||
|
- [ ] Security and performance principles integrated
|
||||||
|
- [ ] Deviations from principles justified in ADRs
|
||||||
|
|
||||||
|
## 11. ACCESSIBILITY IMPLEMENTATION [[FRONTEND ONLY]]
|
||||||
|
|
||||||
[[LLM: Skip this section for backend-only projects. Accessibility is a core requirement for any user interface.]]
|
[[LLM: Skip this section for backend-only projects. Accessibility is a core requirement for any user interface.]]
|
||||||
|
|
||||||
### 10.1 Accessibility Standards
|
### 11.1 Accessibility Standards
|
||||||
|
|
||||||
- [ ] Semantic HTML usage is emphasized
|
- [ ] Semantic HTML usage is emphasized
|
||||||
- [ ] ARIA implementation guidelines provided
|
- [ ] ARIA implementation guidelines provided
|
||||||
|
|
@ -400,7 +442,7 @@ Ask the user if they want to work through the checklist:
|
||||||
- [ ] Focus management approach specified
|
- [ ] Focus management approach specified
|
||||||
- [ ] Screen reader compatibility addressed
|
- [ ] Screen reader compatibility addressed
|
||||||
|
|
||||||
### 10.2 Accessibility Testing
|
### 11.2 Accessibility Testing
|
||||||
|
|
||||||
- [ ] Accessibility testing tools identified
|
- [ ] Accessibility testing tools identified
|
||||||
- [ ] Testing process integrated into workflow
|
- [ ] Testing process integrated into workflow
|
||||||
|
|
|
||||||
|
|
@ -93,6 +93,8 @@ Be thorough - missed conflicts cause future problems.]]
|
||||||
- [ ] Does the technology list need updating?
|
- [ ] Does the technology list need updating?
|
||||||
- [ ] Do data models or schemas need revision?
|
- [ ] Do data models or schemas need revision?
|
||||||
- [ ] Are external API integrations affected?
|
- [ ] Are external API integrations affected?
|
||||||
|
- [ ] Do existing ADRs need to be superseded or updated?
|
||||||
|
- [ ] Is a new ADR required to document the technical change decision?
|
||||||
- [ ] **Review Frontend Spec (if applicable):**
|
- [ ] **Review Frontend Spec (if applicable):**
|
||||||
- [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
|
- [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
|
||||||
- [ ] Are specific FE components or user flows impacted?
|
- [ ] Are specific FE components or user flows impacted?
|
||||||
|
|
@ -151,6 +153,8 @@ This proposal guides all subsequent work.]]
|
||||||
- [ ] **PRD MVP Impact:** Changes to scope/goals (if any).
|
- [ ] **PRD MVP Impact:** Changes to scope/goals (if any).
|
||||||
- [ ] **High-Level Action Plan:** Next steps for stories/updates.
|
- [ ] **High-Level Action Plan:** Next steps for stories/updates.
|
||||||
- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
|
- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
|
||||||
|
- [ ] **Memory Bank Updates Required:** Which Memory Bank files need updating (activeContext, systemPatterns, etc.).
|
||||||
|
- [ ] **Dev Journal Entry Plan:** Key decisions and rationale to document.
|
||||||
|
|
||||||
## 6. Final Review & Handoff
|
## 6. Final Review & Handoff
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -218,11 +218,14 @@ Ask the user if they want to work through the checklist:
|
||||||
|
|
||||||
### 6.3 First Epic Completeness
|
### 6.3 First Epic Completeness
|
||||||
|
|
||||||
|
[[LLM: Reference project-scaffolding-preference.md for comprehensive project structure and initialization guidelines.]]
|
||||||
|
|
||||||
- [ ] First epic includes all necessary setup steps
|
- [ ] First epic includes all necessary setup steps
|
||||||
- [ ] Project scaffolding and initialization addressed
|
- [ ] Project scaffolding follows project-scaffolding-preference.md
|
||||||
- [ ] Core infrastructure setup included
|
- [ ] Core infrastructure setup included
|
||||||
- [ ] Development environment setup addressed
|
- [ ] Development environment setup addressed
|
||||||
- [ ] Local testability established early
|
- [ ] Local testability established early
|
||||||
|
- [ ] BMAD-specific directories included in setup (Memory Bank, ADRs, Dev Journals)
|
||||||
|
|
||||||
## 7. TECHNICAL GUIDANCE
|
## 7. TECHNICAL GUIDANCE
|
||||||
|
|
||||||
|
|
@ -234,6 +237,7 @@ Ask the user if they want to work through the checklist:
|
||||||
- [ ] Performance considerations highlighted
|
- [ ] Performance considerations highlighted
|
||||||
- [ ] Security requirements articulated
|
- [ ] Security requirements articulated
|
||||||
- [ ] Known areas of high complexity or technical risk flagged for architectural deep-dive
|
- [ ] Known areas of high complexity or technical risk flagged for architectural deep-dive
|
||||||
|
- [ ] ADR (Architecture Decision Record) templates prepared for key decisions
|
||||||
|
|
||||||
### 7.2 Technical Decision Framework
|
### 7.2 Technical Decision Framework
|
||||||
|
|
||||||
|
|
@ -243,6 +247,8 @@ Ask the user if they want to work through the checklist:
|
||||||
- [ ] Non-negotiable technical requirements highlighted
|
- [ ] Non-negotiable technical requirements highlighted
|
||||||
- [ ] Areas requiring technical investigation identified
|
- [ ] Areas requiring technical investigation identified
|
||||||
- [ ] Guidance on technical debt approach provided
|
- [ ] Guidance on technical debt approach provided
|
||||||
|
- [ ] ADR creation process integrated into decision-making
|
||||||
|
- [ ] Technical principles and preferences aligned with project goals
|
||||||
|
|
||||||
### 7.3 Implementation Considerations
|
### 7.3 Implementation Considerations
|
||||||
|
|
||||||
|
|
@ -288,6 +294,7 @@ Ask the user if they want to work through the checklist:
|
||||||
- [ ] Technical terms are defined where necessary
|
- [ ] Technical terms are defined where necessary
|
||||||
- [ ] Diagrams/visuals included where helpful
|
- [ ] Diagrams/visuals included where helpful
|
||||||
- [ ] Documentation is versioned appropriately
|
- [ ] Documentation is versioned appropriately
|
||||||
|
- [ ] Technical principles clearly documented for team reference
|
||||||
|
|
||||||
### 9.2 Stakeholder Alignment
|
### 9.2 Stakeholder Alignment
|
||||||
|
|
||||||
|
|
@ -296,6 +303,16 @@ Ask the user if they want to work through the checklist:
|
||||||
- [ ] Potential areas of disagreement addressed
|
- [ ] Potential areas of disagreement addressed
|
||||||
- [ ] Communication plan for updates established
|
- [ ] Communication plan for updates established
|
||||||
- [ ] Approval process defined
|
- [ ] Approval process defined
|
||||||
|
- [ ] Sprint Review cadence and format agreed upon
|
||||||
|
|
||||||
|
### 9.3 Sprint Review Planning
|
||||||
|
|
||||||
|
- [ ] Sprint Review schedule established and communicated
|
||||||
|
- [ ] Review format aligned with stakeholder preferences
|
||||||
|
- [ ] Success metrics for sprint defined
|
||||||
|
- [ ] Demo scenarios planned for completed features
|
||||||
|
- [ ] Retrospective process integrated into sprint planning
|
||||||
|
- [ ] Documentation updates planned for sprint outcomes
|
||||||
|
|
||||||
## PRD & EPIC VALIDATION SUMMARY
|
## PRD & EPIC VALIDATION SUMMARY
|
||||||
|
|
||||||
|
|
@ -350,7 +367,7 @@ After presenting the report, ask if the user wants:
|
||||||
### Category Statuses
|
### Category Statuses
|
||||||
|
|
||||||
| Category | Status | Critical Issues |
|
| Category | Status | Critical Issues |
|
||||||
| -------------------------------- | ------ | --------------- |
|
|----------------------------------|--------|-----------------|
|
||||||
| 1. Problem Definition & Context | _TBD_ | |
|
| 1. Problem Definition & Context | _TBD_ | |
|
||||||
| 2. MVP Scope Definition | _TBD_ | |
|
| 2. MVP Scope Definition | _TBD_ | |
|
||||||
| 3. User Experience Requirements | _TBD_ | |
|
| 3. User Experience Requirements | _TBD_ | |
|
||||||
|
|
|
||||||
|
|
@ -59,17 +59,51 @@ Ask the user if they want to work through the checklist:
|
||||||
- Section by section (interactive mode) - Review each section, get confirmation before proceeding
|
- Section by section (interactive mode) - Review each section, get confirmation before proceeding
|
||||||
- All at once (comprehensive mode) - Complete full analysis and present report at end]]
|
- All at once (comprehensive mode) - Complete full analysis and present report at end]]
|
||||||
|
|
||||||
|
## 0. SESSION INITIALIZATION & CONTEXT
|
||||||
|
|
||||||
|
[[LLM: Before any validation, ensure complete project understanding through systematic session kickoff. This prevents context gaps that lead to suboptimal decisions.]]
|
||||||
|
|
||||||
|
### 0.1 Session Kickoff Completion
|
||||||
|
|
||||||
|
- [ ] Session kickoff task completed to establish project context
|
||||||
|
- [ ] Memory Bank files reviewed (if they exist)
|
||||||
|
- [ ] Recent Dev Journal entries reviewed for current state
|
||||||
|
- [ ] Architecture documentation reviewed and understood
|
||||||
|
- [ ] Git status and recent commits analyzed
|
||||||
|
- [ ] Documentation inconsistencies identified and noted
|
||||||
|
|
||||||
|
### 0.2 Memory Bank Initialization [[NEW PROJECT]]
|
||||||
|
|
||||||
|
- [ ] Memory Bank directory structure created at `docs/memory-bank/`
|
||||||
|
- [ ] Initial `projectbrief.md` created with project foundation
|
||||||
|
- [ ] `activeContext.md` initialized with current priorities
|
||||||
|
- [ ] `progress.md` started to track project state
|
||||||
|
- [ ] `systemPatterns.md` prepared for architecture decisions
|
||||||
|
- [ ] `techContext.md` and `productContext.md` initialized
|
||||||
|
|
||||||
|
### 0.3 Technical Principles Alignment
|
||||||
|
|
||||||
|
- [ ] Technical principles and preferences documented
|
||||||
|
- [ ] Coding standards established and referenced
|
||||||
|
- [ ] Microservice patterns (if applicable) documented
|
||||||
|
- [ ] Twelve-factor principles considered and applied
|
||||||
|
- [ ] Security and performance standards defined
|
||||||
|
|
||||||
## 1. PROJECT SETUP & INITIALIZATION
|
## 1. PROJECT SETUP & INITIALIZATION
|
||||||
|
|
||||||
[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
|
[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
|
||||||
|
|
||||||
### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
|
### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
|
||||||
|
|
||||||
|
[[LLM: Reference project-scaffolding-preference.md in data dependencies for comprehensive project structure guidelines. Ensure project follows standardized directory structure and documentation practices.]]
|
||||||
|
|
||||||
- [ ] Epic 1 includes explicit steps for project creation/initialization
|
- [ ] Epic 1 includes explicit steps for project creation/initialization
|
||||||
|
- [ ] Project structure follows project-scaffolding-preference.md guidelines
|
||||||
- [ ] If using a starter template, steps for cloning/setup are included
|
- [ ] If using a starter template, steps for cloning/setup are included
|
||||||
- [ ] If building from scratch, all necessary scaffolding steps are defined
|
- [ ] If building from scratch, all necessary scaffolding steps are defined
|
||||||
- [ ] Initial README or documentation setup is included
|
- [ ] Initial README or documentation setup is included
|
||||||
- [ ] Repository setup and initial commit processes are defined
|
- [ ] Repository setup and initial commit processes are defined
|
||||||
|
- [ ] BMAD-specific directories created (docs/memory-bank, docs/adr, docs/devJournal)
|
||||||
|
|
||||||
### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
|
### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
|
||||||
|
|
||||||
|
|
@ -295,14 +329,15 @@ Ask the user if they want to work through the checklist:
|
||||||
|
|
||||||
## 9. DOCUMENTATION & HANDOFF
|
## 9. DOCUMENTATION & HANDOFF
|
||||||
|
|
||||||
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
|
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical. Include Dev Journal and Sprint Review processes.]]
|
||||||
|
|
||||||
### 9.1 Developer Documentation
|
### 9.1 Developer Documentation
|
||||||
|
|
||||||
- [ ] API documentation created alongside implementation
|
- [ ] API documentation created alongside implementation
|
||||||
- [ ] Setup instructions are comprehensive
|
- [ ] Setup instructions are comprehensive
|
||||||
- [ ] Architecture decisions documented
|
- [ ] Architecture decisions documented with ADRs
|
||||||
- [ ] Patterns and conventions documented
|
- [ ] Patterns and conventions documented
|
||||||
|
- [ ] Dev Journal maintained with daily/weekly updates
|
||||||
- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
|
- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
|
||||||
|
|
||||||
### 9.2 User Documentation
|
### 9.2 User Documentation
|
||||||
|
|
@ -314,11 +349,22 @@ Ask the user if they want to work through the checklist:
|
||||||
|
|
||||||
### 9.3 Knowledge Transfer
|
### 9.3 Knowledge Transfer
|
||||||
|
|
||||||
|
- [ ] Dev Journal entries capture key decisions and learnings
|
||||||
|
- [ ] Sprint Review documentation prepared for stakeholders
|
||||||
- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
|
- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
|
||||||
- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
|
- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
|
||||||
- [ ] Code review knowledge sharing planned
|
- [ ] Code review knowledge sharing planned
|
||||||
- [ ] Deployment knowledge transferred to operations
|
- [ ] Deployment knowledge transferred to operations
|
||||||
- [ ] Historical context preserved
|
- [ ] Historical context preserved in Memory Bank
|
||||||
|
|
||||||
|
### 9.4 Sprint Review Preparation
|
||||||
|
|
||||||
|
- [ ] Sprint objectives and completion status documented
|
||||||
|
- [ ] Key achievements and blockers identified
|
||||||
|
- [ ] Technical decisions and their rationale captured
|
||||||
|
- [ ] Lessons learned documented for future sprints
|
||||||
|
- [ ] Next sprint priorities aligned with project goals
|
||||||
|
- [ ] Memory Bank updated with sprint outcomes
|
||||||
|
|
||||||
## 10. POST-MVP CONSIDERATIONS
|
## 10. POST-MVP CONSIDERATIONS
|
||||||
|
|
||||||
|
|
@ -414,7 +460,8 @@ After presenting the report, ask if the user wants:
|
||||||
### Category Statuses
|
### Category Statuses
|
||||||
|
|
||||||
| Category | Status | Critical Issues |
|
| Category | Status | Critical Issues |
|
||||||
| --------------------------------------- | ------ | --------------- |
|
|-----------------------------------------|--------|-----------------|
|
||||||
|
| 0. Session Initialization & Context | _TBD_ | |
|
||||||
| 1. Project Setup & Initialization | _TBD_ | |
|
| 1. Project Setup & Initialization | _TBD_ | |
|
||||||
| 2. Infrastructure & Deployment | _TBD_ | |
|
| 2. Infrastructure & Deployment | _TBD_ | |
|
||||||
| 3. External Dependencies & Integrations | _TBD_ | |
|
| 3. External Dependencies & Integrations | _TBD_ | |
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,267 @@
|
||||||
|
# Session Kickoff Checklist
|
||||||
|
|
||||||
|
This checklist ensures AI agents have complete project context and understanding before starting work. It provides systematic session initialization across all agent types.
|
||||||
|
|
||||||
|
[[LLM: INITIALIZATION INSTRUCTIONS - SESSION KICKOFF
|
||||||
|
|
||||||
|
This is the FIRST checklist to run when starting any new AI agent session. It prevents context gaps, reduces mistakes, and ensures efficient work.
|
||||||
|
|
||||||
|
IMPORTANT: This checklist is mandatory for:
|
||||||
|
- New AI sessions on existing projects
|
||||||
|
- After significant time gaps (>24 hours)
|
||||||
|
- When switching between major project areas
|
||||||
|
- After major changes or pivots
|
||||||
|
- When onboarding new team members
|
||||||
|
|
||||||
|
The goal is to establish complete context BEFORE any work begins.]]
|
||||||
|
|
||||||
|
## 1. MEMORY BANK REVIEW
|
||||||
|
|
||||||
|
[[LLM: Memory Bank is the primary source of project truth. Review systematically, noting dates and potential staleness.]]
|
||||||
|
|
||||||
|
### 1.1 Core Memory Bank Files
|
||||||
|
|
||||||
|
- [ ] **projectbrief.md** reviewed - Project foundation, goals, and scope understood
|
||||||
|
- [ ] **activeContext.md** reviewed - Current priorities and immediate work identified
|
||||||
|
- [ ] **progress.md** reviewed - Project state and completed features understood
|
||||||
|
- [ ] **systemPatterns.md** reviewed - Architecture patterns and decisions noted
|
||||||
|
- [ ] **techContext.md** reviewed - Technology stack and constraints clear
|
||||||
|
- [ ] **productContext.md** reviewed - Problem space and user needs understood
|
||||||
|
- [ ] Last update timestamps noted for each file
|
||||||
|
- [ ] Potential inconsistencies between files identified
|
||||||
|
|
||||||
|
### 1.2 Memory Bank Health Assessment
|
||||||
|
|
||||||
|
- [ ] Files exist and are accessible
|
||||||
|
- [ ] Information appears current (updated within last sprint)
|
||||||
|
- [ ] No major gaps in documentation identified
|
||||||
|
- [ ] Cross-references between files are consistent
|
||||||
|
- [ ] Action items for updates noted if needed
|
||||||
|
|
||||||
|
### 1.3 Project Structure Verification
|
||||||
|
|
||||||
|
[[LLM: Reference project-scaffolding-preference.md for standard project structure. Verify actual structure aligns with BMAD conventions.]]
|
||||||
|
|
||||||
|
- [ ] Project follows standard directory structure
|
||||||
|
- [ ] BMAD-specific directories exist (docs/memory-bank, docs/adr, docs/devJournal)
|
||||||
|
- [ ] Documentation directories properly organized
|
||||||
|
- [ ] Source code organization follows conventions
|
||||||
|
- [ ] Test structure aligns with project type
|
||||||
|
|
||||||
|
## 2. ARCHITECTURE DOCUMENTATION
|
||||||
|
|
||||||
|
[[LLM: Architecture drives implementation. Understand the system design thoroughly.]]
|
||||||
|
|
||||||
|
### 2.1 Architecture Documents
|
||||||
|
|
||||||
|
- [ ] Primary architecture document located and reviewed
|
||||||
|
- [ ] Document type identified (greenfield, brownfield, frontend, fullstack)
|
||||||
|
- [ ] Core architectural decisions understood
|
||||||
|
- [ ] System components and relationships clear
|
||||||
|
- [ ] Technology choices and versions noted
|
||||||
|
- [ ] API documentation reviewed if exists
|
||||||
|
- [ ] Database schemas understood if applicable
|
||||||
|
|
||||||
|
### 2.2 Architecture Alignment
|
||||||
|
|
||||||
|
- [ ] Architecture aligns with Memory Bank information
|
||||||
|
- [ ] Recent changes or updates identified
|
||||||
|
- [ ] ADRs reviewed for architectural decisions
|
||||||
|
- [ ] Integration points clearly understood
|
||||||
|
- [ ] Deployment architecture reviewed
|
||||||
|
|
||||||
|
## 3. DEVELOPMENT HISTORY
|
||||||
|
|
||||||
|
[[LLM: Recent history provides context for current work and challenges.]]
|
||||||
|
|
||||||
|
### 3.1 Dev Journal Review
|
||||||
|
|
||||||
|
- [ ] Located Dev Journal entries (last 3-5)
|
||||||
|
- [ ] Recent work and decisions understood
|
||||||
|
- [ ] Challenges and blockers identified
|
||||||
|
- [ ] Technical debt or issues noted
|
||||||
|
- [ ] Patterns in development identified
|
||||||
|
- [ ] Key learnings extracted
|
||||||
|
|
||||||
|
### 3.2 ADR Review
|
||||||
|
|
||||||
|
- [ ] Recent ADRs reviewed (last 3-5)
|
||||||
|
- [ ] Current architectural decisions understood
|
||||||
|
- [ ] Superseded decisions noted
|
||||||
|
- [ ] Pending decisions identified
|
||||||
|
- [ ] ADR alignment with architecture verified
|
||||||
|
|
||||||
|
## 4. CURRENT PROJECT STATE
|
||||||
|
|
||||||
|
[[LLM: Understanding the current state prevents duplicate work and conflicts.]]
|
||||||
|
|
||||||
|
### 4.1 Git Status Check
|
||||||
|
|
||||||
|
- [ ] Current branch identified
|
||||||
|
- [ ] Clean working directory confirmed
|
||||||
|
- [ ] Recent commits reviewed (last 10)
|
||||||
|
- [ ] Outstanding changes understood
|
||||||
|
- [ ] Merge conflicts checked
|
||||||
|
- [ ] Remote synchronization status
|
||||||
|
|
||||||
|
### 4.2 Project Health
|
||||||
|
|
||||||
|
- [ ] Build status checked
|
||||||
|
- [ ] Test suite status verified
|
||||||
|
- [ ] Known failing tests documented
|
||||||
|
- [ ] Blocking issues identified
|
||||||
|
- [ ] Dependencies up to date
|
||||||
|
- [ ] Security vulnerabilities checked
|
||||||
|
|
||||||
|
## 5. SPRINT/ITERATION CONTEXT
|
||||||
|
|
||||||
|
[[LLM: Align work with current sprint goals and priorities.]]
|
||||||
|
|
||||||
|
### 5.1 Sprint Status
|
||||||
|
|
||||||
|
- [ ] Current sprint identified
|
||||||
|
- [ ] Sprint goals understood
|
||||||
|
- [ ] User stories in progress identified
|
||||||
|
- [ ] Completed stories this sprint noted
|
||||||
|
- [ ] Sprint timeline clear
|
||||||
|
- [ ] Team velocity understood
|
||||||
|
|
||||||
|
### 5.2 Priority Alignment
|
||||||
|
|
||||||
|
- [ ] Immediate priorities identified
|
||||||
|
- [ ] Blockers and dependencies clear
|
||||||
|
- [ ] Next planned work understood
|
||||||
|
- [ ] Risk areas identified
|
||||||
|
- [ ] Resource constraints noted
|
||||||
|
|
||||||
|
## 6. CONSISTENCY VALIDATION
|
||||||
|
|
||||||
|
[[LLM: Inconsistencies cause confusion and errors. Identify and flag them.]]
|
||||||
|
|
||||||
|
### 6.1 Cross-Reference Check
|
||||||
|
|
||||||
|
- [ ] Memory Bank aligns with codebase reality
|
||||||
|
- [ ] Architecture matches implementation
|
||||||
|
- [ ] ADRs reflected in current code
|
||||||
|
- [ ] Dev Journal matches git history
|
||||||
|
- [ ] Documentation current with changes
|
||||||
|
|
||||||
|
### 6.2 Gap Identification
|
||||||
|
|
||||||
|
- [ ] Missing documentation identified
|
||||||
|
- [ ] Outdated sections flagged
|
||||||
|
- [ ] Undocumented decisions noted
|
||||||
|
- [ ] Knowledge gaps listed
|
||||||
|
- [ ] Update requirements documented
|
||||||
|
|
||||||
|
## 7. AGENT-SPECIFIC CONTEXT
|
||||||
|
|
||||||
|
[[LLM: Different agents need different context emphasis.]]
|
||||||
|
|
||||||
|
### 7.1 Role-Based Focus
|
||||||
|
|
||||||
|
**For Architect:**
|
||||||
|
- [ ] Architectural decisions and rationale clear
|
||||||
|
- [ ] Technical debt understood
|
||||||
|
- [ ] Scalability considerations reviewed
|
||||||
|
- [ ] System boundaries defined
|
||||||
|
|
||||||
|
**For Developer:**
|
||||||
|
- [ ] Current implementation tasks clear
|
||||||
|
- [ ] Coding patterns understood
|
||||||
|
- [ ] Testing requirements known
|
||||||
|
- [ ] Local setup verified
|
||||||
|
|
||||||
|
**For PM/PO:**
|
||||||
|
- [ ] Requirements alignment verified
|
||||||
|
- [ ] User stories prioritized
|
||||||
|
- [ ] Stakeholder needs understood
|
||||||
|
- [ ] Timeline constraints clear
|
||||||
|
|
||||||
|
**For QA:**
|
||||||
|
- [ ] Test coverage understood
|
||||||
|
- [ ] Quality gates defined
|
||||||
|
- [ ] Known issues documented
|
||||||
|
- [ ] Testing strategy clear
|
||||||
|
|
||||||
|
### 7.2 Handoff Context
|
||||||
|
|
||||||
|
- [ ] Previous agent's work understood
|
||||||
|
- [ ] Pending decisions identified
|
||||||
|
- [ ] Open questions documented
|
||||||
|
- [ ] Next steps clear
|
||||||
|
|
||||||
|
## 8. RECOMMENDED ACTIONS
|
||||||
|
|
||||||
|
[[LLM: Based on the review, what should happen next?]]
|
||||||
|
|
||||||
|
### 8.1 Immediate Actions
|
||||||
|
|
||||||
|
- [ ] Most urgent task identified
|
||||||
|
- [ ] Blockers that need resolution listed
|
||||||
|
- [ ] Quick wins available noted
|
||||||
|
- [ ] Risk mitigation needed specified
|
||||||
|
|
||||||
|
### 8.2 Documentation Updates
|
||||||
|
|
||||||
|
- [ ] Memory Bank updates needed listed
|
||||||
|
- [ ] Architecture updates required noted
|
||||||
|
- [ ] ADRs to be created identified
|
||||||
|
- [ ] Dev Journal entries planned
|
||||||
|
|
||||||
|
### 8.3 Strategic Considerations
|
||||||
|
|
||||||
|
- [ ] Technical debt to address
|
||||||
|
- [ ] Architectural improvements needed
|
||||||
|
- [ ] Process improvements suggested
|
||||||
|
- [ ] Knowledge gaps to fill
|
||||||
|
|
||||||
|
## SESSION KICKOFF SUMMARY
|
||||||
|
|
||||||
|
[[LLM: Generate a concise summary report with:
|
||||||
|
|
||||||
|
1. **Project Context**
|
||||||
|
- Project name and purpose
|
||||||
|
- Current phase/sprint
|
||||||
|
- Key technologies
|
||||||
|
|
||||||
|
2. **Documentation Health**
|
||||||
|
- Memory Bank status (Current/Outdated/Missing)
|
||||||
|
- Architecture status
|
||||||
|
- Overall documentation quality
|
||||||
|
|
||||||
|
3. **Current State**
|
||||||
|
- Active work items
|
||||||
|
- Recent completions
|
||||||
|
- Immediate blockers
|
||||||
|
|
||||||
|
4. **Inconsistencies Found**
|
||||||
|
- List any misalignments
|
||||||
|
- Documentation gaps
|
||||||
|
- Update requirements
|
||||||
|
|
||||||
|
5. **Recommended Next Steps**
|
||||||
|
- Priority order
|
||||||
|
- Estimated effort
|
||||||
|
- Dependencies
|
||||||
|
|
||||||
|
Keep it action-oriented and concise.]]
|
||||||
|
|
||||||
|
### Summary Report
|
||||||
|
|
||||||
|
**Status:** [Complete/Partial/Blocked]
|
||||||
|
|
||||||
|
**Key Findings:**
|
||||||
|
- Documentation Health: [Good/Fair/Poor]
|
||||||
|
- Project State: [On Track/At Risk/Blocked]
|
||||||
|
- Context Quality: [Complete/Adequate/Insufficient]
|
||||||
|
|
||||||
|
**Priority Actions:**
|
||||||
|
1. [Most urgent action]
|
||||||
|
2. [Second priority]
|
||||||
|
3. [Third priority]
|
||||||
|
|
||||||
|
**Blockers:**
|
||||||
|
- [List any blocking issues]
|
||||||
|
|
||||||
|
**Agent Ready:** [Yes/No - with reason if No]
|
||||||
|
|
@ -0,0 +1,363 @@
|
||||||
|
# Sprint Review Checklist
|
||||||
|
|
||||||
|
This checklist guides teams through conducting effective sprint reviews that capture achievements, learnings, and set up the next sprint for success.
|
||||||
|
|
||||||
|
[[LLM: INITIALIZATION INSTRUCTIONS - SPRINT REVIEW
|
||||||
|
|
||||||
|
Sprint Reviews are critical ceremonies for:
|
||||||
|
- Demonstrating completed work to stakeholders
|
||||||
|
- Capturing lessons learned
|
||||||
|
- Adjusting project direction based on feedback
|
||||||
|
- Planning upcoming work
|
||||||
|
- Updating project documentation
|
||||||
|
|
||||||
|
This checklist should be used:
|
||||||
|
- At the end of each sprint/iteration
|
||||||
|
- Before major milestone reviews
|
||||||
|
- When significant changes occur
|
||||||
|
- For handoffs between teams
|
||||||
|
|
||||||
|
The goal is to create a comprehensive record of progress and decisions.]]
|
||||||
|
|
||||||
|
## 1. PRE-REVIEW PREPARATION
|
||||||
|
|
||||||
|
[[LLM: Good preparation ensures productive reviews. Complete these items 1-2 days before the review.]]
|
||||||
|
|
||||||
|
### 1.1 Sprint Metrics Collection
|
||||||
|
|
||||||
|
- [ ] Sprint goals documented and assessed
|
||||||
|
- [ ] User stories completed vs planned tallied
|
||||||
|
- [ ] Story points delivered calculated
|
||||||
|
- [ ] Velocity compared to previous sprints
|
||||||
|
- [ ] Burndown/burnup charts prepared
|
||||||
|
- [ ] Blockers and impediments listed
|
||||||
|
|
||||||
|
### 1.2 Demo Preparation
|
||||||
|
|
||||||
|
- [ ] Completed features identified for demo
|
||||||
|
- [ ] Demo environment prepared and tested
|
||||||
|
- [ ] Demo scripts/scenarios written
|
||||||
|
- [ ] Demo order determined (highest value first)
|
||||||
|
- [ ] Presenters assigned for each feature
|
||||||
|
- [ ] Backup plans for demo failures prepared
|
||||||
|
|
||||||
|
### 1.3 Documentation Review
|
||||||
|
|
||||||
|
- [ ] Dev Journal entries for sprint compiled
|
||||||
|
- [ ] ADRs created during sprint listed
|
||||||
|
- [ ] Memory Bank updates identified
|
||||||
|
- [ ] Architecture changes documented
|
||||||
|
- [ ] Technical debt items logged
|
||||||
|
|
||||||
|
## 2. STAKEHOLDER COORDINATION
|
||||||
|
|
||||||
|
[[LLM: Effective reviews require the right people with the right information.]]
|
||||||
|
|
||||||
|
### 2.1 Attendee Management
|
||||||
|
|
||||||
|
- [ ] Required stakeholders identified and invited
|
||||||
|
- [ ] Product Owner availability confirmed
|
||||||
|
- [ ] Technical team members scheduled
|
||||||
|
- [ ] Optional attendees invited
|
||||||
|
- [ ] Meeting logistics communicated
|
||||||
|
- [ ] Pre-read materials distributed
|
||||||
|
|
||||||
|
### 2.2 Agenda Creation
|
||||||
|
|
||||||
|
- [ ] Review objectives defined
|
||||||
|
- [ ] Time allocated per demo/topic
|
||||||
|
- [ ] Q&A time built in
|
||||||
|
- [ ] Feedback collection method determined
|
||||||
|
- [ ] Next steps discussion included
|
||||||
|
- [ ] Time for retrospective insights
|
||||||
|
|
||||||
|
## 3. SPRINT ACCOMPLISHMENTS
|
||||||
|
|
||||||
|
[[LLM: Focus on value delivered and outcomes achieved, not just features built.]]
|
||||||
|
|
||||||
|
### 3.1 Completed Work
|
||||||
|
|
||||||
|
- [ ] All completed user stories listed
|
||||||
|
- [ ] Business value of each story articulated
|
||||||
|
- [ ] Technical achievements highlighted
|
||||||
|
- [ ] Infrastructure improvements noted
|
||||||
|
- [ ] Bug fixes and issues resolved documented
|
||||||
|
- [ ] Performance improvements quantified
|
||||||
|
|
||||||
|
### 3.2 Partial/Incomplete Work
|
||||||
|
|
||||||
|
- [ ] In-progress stories status documented
|
||||||
|
- [ ] Reasons for incompletion analyzed
|
||||||
|
- [ ] Carry-over plan determined
|
||||||
|
- [ ] Re-estimation completed if needed
|
||||||
|
- [ ] Dependencies identified
|
||||||
|
- [ ] Risk mitigation planned
|
||||||
|
|
||||||
|
### 3.3 Unplanned Work
|
||||||
|
|
||||||
|
- [ ] Emergency fixes documented
|
||||||
|
- [ ] Scope changes captured
|
||||||
|
- [ ] Technical discoveries noted
|
||||||
|
- [ ] Time impact assessed
|
||||||
|
- [ ] Process improvements identified
|
||||||
|
- [ ] Prevention strategies discussed
|
||||||
|
|
||||||
|
## 4. TECHNICAL DECISIONS & LEARNINGS
|
||||||
|
|
||||||
|
[[LLM: Capture the "why" behind decisions for future reference.]]
|
||||||
|
|
||||||
|
### 4.1 Architectural Decisions
|
||||||
|
|
||||||
|
- [ ] Key technical decisions documented
|
||||||
|
- [ ] ADRs created or referenced
|
||||||
|
- [ ] Trade-offs explained
|
||||||
|
- [ ] Alternative approaches noted
|
||||||
|
- [ ] Impact on future work assessed
|
||||||
|
- [ ] Technical debt created/resolved
|
||||||
|
|
||||||
|
### 4.2 Process Learnings
|
||||||
|
|
||||||
|
- [ ] What worked well identified
|
||||||
|
- [ ] What didn't work documented
|
||||||
|
- [ ] Process improvements suggested
|
||||||
|
- [ ] Tool effectiveness evaluated
|
||||||
|
- [ ] Communication gaps noted
|
||||||
|
- [ ] Team dynamics assessed
|
||||||
|
|
||||||
|
### 4.3 Technical Learnings
|
||||||
|
|
||||||
|
- [ ] New technologies evaluated
|
||||||
|
- [ ] Performance insights gained
|
||||||
|
- [ ] Security findings documented
|
||||||
|
- [ ] Integration challenges noted
|
||||||
|
- [ ] Best practices identified
|
||||||
|
- [ ] Anti-patterns discovered
|
||||||
|
|
||||||
|
## 5. STAKEHOLDER FEEDBACK
|
||||||
|
|
||||||
|
[[LLM: Stakeholder input shapes future direction. Capture it systematically.]]
|
||||||
|
|
||||||
|
### 5.1 Feature Feedback
|
||||||
|
|
||||||
|
- [ ] User reactions to demos captured
|
||||||
|
- [ ] Feature requests documented
|
||||||
|
- [ ] Priority changes noted
|
||||||
|
- [ ] Usability concerns raised
|
||||||
|
- [ ] Performance feedback received
|
||||||
|
- [ ] Gap analysis completed
|
||||||
|
|
||||||
|
### 5.2 Strategic Feedback
|
||||||
|
|
||||||
|
- [ ] Alignment with business goals verified
|
||||||
|
- [ ] Market changes discussed
|
||||||
|
- [ ] Competitive insights shared
|
||||||
|
- [ ] Resource concerns raised
|
||||||
|
- [ ] Timeline adjustments proposed
|
||||||
|
- [ ] Success metrics validated
|
||||||
|
|
||||||
|
## 6. NEXT SPRINT PLANNING
|
||||||
|
|
||||||
|
[[LLM: Use review insights to plan effectively for the next sprint.]]
|
||||||
|
|
||||||
|
### 6.1 Backlog Refinement
|
||||||
|
|
||||||
|
- [ ] Backlog prioritization updated
|
||||||
|
- [ ] New stories created from feedback
|
||||||
|
- [ ] Technical debt items prioritized
|
||||||
|
- [ ] Dependencies identified
|
||||||
|
- [ ] Estimation needs noted
|
||||||
|
- [ ] Spike stories defined
|
||||||
|
|
||||||
|
### 6.2 Sprint Goal Setting
|
||||||
|
|
||||||
|
- [ ] Next sprint theme determined
|
||||||
|
- [ ] Specific goals articulated
|
||||||
|
- [ ] Success criteria defined
|
||||||
|
- [ ] Risks identified
|
||||||
|
- [ ] Capacity confirmed
|
||||||
|
- [ ] Commitment level agreed
|
||||||
|
|
||||||
|
### 6.3 Process Adjustments
|
||||||
|
|
||||||
|
- [ ] Retrospective actions incorporated
|
||||||
|
- [ ] Process improvements planned
|
||||||
|
- [ ] Tool changes identified
|
||||||
|
- [ ] Communication plans updated
|
||||||
|
- [ ] Meeting cadence adjusted
|
||||||
|
- [ ] Team agreements updated
|
||||||
|
|
||||||
|
## 7. DOCUMENTATION UPDATES
|
||||||
|
|
||||||
|
[[LLM: Keep project documentation current with sprint outcomes.]]
|
||||||
|
|
||||||
|
### 7.1 Memory Bank Updates
|
||||||
|
|
||||||
|
- [ ] progress.md updated with completions
|
||||||
|
- [ ] activeContext.md refreshed for next sprint
|
||||||
|
- [ ] systemPatterns.md updated with new patterns
|
||||||
|
- [ ] techContext.md updated if stack changed
|
||||||
|
- [ ] productContext.md adjusted based on feedback
|
||||||
|
- [ ] All updates committed and pushed
|
||||||
|
|
||||||
|
### 7.2 Project Documentation
|
||||||
|
|
||||||
|
- [ ] README updated if needed
|
||||||
|
- [ ] CHANGELOG updated with sprint changes
|
||||||
|
- [ ] Architecture docs updated
|
||||||
|
- [ ] API documentation current
|
||||||
|
- [ ] Deployment guides updated
|
||||||
|
- [ ] User documentation refreshed
|
||||||
|
|
||||||
|
### 7.3 Knowledge Sharing
|
||||||
|
|
||||||
|
- [ ] Dev Journal entries completed
|
||||||
|
- [ ] Key decisions documented in ADRs
|
||||||
|
- [ ] Lessons learned captured
|
||||||
|
- [ ] Best practices documented
|
||||||
|
- [ ] Team wiki updated
|
||||||
|
- [ ] Knowledge gaps identified
|
||||||
|
|
||||||
|
## 8. METRICS & REPORTING
|
||||||
|
|
||||||
|
[[LLM: Data-driven insights improve future performance.]]
|
||||||
|
|
||||||
|
### 8.1 Sprint Metrics
|
||||||
|
|
||||||
|
- [ ] Velocity calculated and tracked
|
||||||
|
- [ ] Cycle time measured
|
||||||
|
- [ ] Defect rates analyzed
|
||||||
|
- [ ] Test coverage reported
|
||||||
|
- [ ] Performance metrics captured
|
||||||
|
- [ ] Technical debt quantified
|
||||||
|
|
||||||
|
### 8.2 Quality Metrics
|
||||||
|
|
||||||
|
- [ ] Code review effectiveness assessed
|
||||||
|
- [ ] Test automation coverage measured
|
||||||
|
- [ ] Security scan results reviewed
|
||||||
|
- [ ] Performance benchmarks compared
|
||||||
|
- [ ] User satisfaction gathered
|
||||||
|
- [ ] Stability metrics tracked
|
||||||
|
|
||||||
|
### 8.3 Trend Analysis
|
||||||
|
|
||||||
|
- [ ] Velocity trends analyzed
|
||||||
|
- [ ] Quality trends identified
|
||||||
|
- [ ] Estimation accuracy reviewed
|
||||||
|
- [ ] Bottlenecks identified
|
||||||
|
- [ ] Improvement areas prioritized
|
||||||
|
- [ ] Predictions for next sprint
|
||||||
|
|
||||||
|
## 9. ACTION ITEMS
|
||||||
|
|
||||||
|
[[LLM: Reviews without follow-through waste time. Ensure actions are specific and assigned.]]
|
||||||
|
|
||||||
|
### 9.1 Immediate Actions
|
||||||
|
|
||||||
|
- [ ] Critical fixes identified and assigned
|
||||||
|
- [ ] Blocker resolution planned
|
||||||
|
- [ ] Documentation updates assigned
|
||||||
|
- [ ] Communication tasks defined
|
||||||
|
- [ ] Tool/access issues addressed
|
||||||
|
- [ ] Quick wins identified
|
||||||
|
|
||||||
|
### 9.2 Short-term Actions (Next Sprint)
|
||||||
|
|
||||||
|
- [ ] Process improvements scheduled
|
||||||
|
- [ ] Technical debt items planned
|
||||||
|
- [ ] Training needs addressed
|
||||||
|
- [ ] Tool implementations planned
|
||||||
|
- [ ] Architecture updates scheduled
|
||||||
|
- [ ] Team changes coordinated
|
||||||
|
|
||||||
|
### 9.3 Long-term Actions
|
||||||
|
|
||||||
|
- [ ] Strategic changes documented
|
||||||
|
- [ ] Major refactoring planned
|
||||||
|
- [ ] Platform migrations scheduled
|
||||||
|
- [ ] Team scaling addressed
|
||||||
|
- [ ] Skill development planned
|
||||||
|
- [ ] Innovation initiatives defined
|
||||||
|
|
||||||
|
## SPRINT REVIEW SUMMARY
|
||||||
|
|
||||||
|
[[LLM: Generate a comprehensive but concise summary for stakeholders and team records.
|
||||||
|
|
||||||
|
Include:
|
||||||
|
|
||||||
|
1. **Sprint Overview**
|
||||||
|
- Sprint number/name
|
||||||
|
- Duration
|
||||||
|
- Team composition
|
||||||
|
- Overall outcome (successful/challenged/failed)
|
||||||
|
|
||||||
|
2. **Achievements**
|
||||||
|
- Stories completed vs planned
|
||||||
|
- Value delivered
|
||||||
|
- Technical accomplishments
|
||||||
|
- Quality improvements
|
||||||
|
|
||||||
|
3. **Challenges**
|
||||||
|
- Major blockers faced
|
||||||
|
- Incomplete work
|
||||||
|
- Technical difficulties
|
||||||
|
- Process issues
|
||||||
|
|
||||||
|
4. **Key Decisions**
|
||||||
|
- Technical choices made
|
||||||
|
- Priority changes
|
||||||
|
- Process adjustments
|
||||||
|
- Resource changes
|
||||||
|
|
||||||
|
5. **Stakeholder Feedback**
|
||||||
|
- Satisfaction level
|
||||||
|
- Major concerns
|
||||||
|
- Feature requests
|
||||||
|
- Priority shifts
|
||||||
|
|
||||||
|
6. **Next Sprint Focus**
|
||||||
|
- Primary goals
|
||||||
|
- Key risks
|
||||||
|
- Dependencies
|
||||||
|
- Success metrics
|
||||||
|
|
||||||
|
7. **Action Items**
|
||||||
|
- Owner, action, due date
|
||||||
|
- Priority level
|
||||||
|
- Dependencies
|
||||||
|
|
||||||
|
Keep it scannable and action-oriented.]]
|
||||||
|
|
||||||
|
### Review Summary Template
|
||||||
|
|
||||||
|
**Sprint:** [Number/Name]
|
||||||
|
**Date:** [Review Date]
|
||||||
|
**Duration:** [Sprint Length]
|
||||||
|
**Attendees:** [List Key Attendees]
|
||||||
|
|
||||||
|
**Overall Assessment:** [Green/Yellow/Red]
|
||||||
|
|
||||||
|
**Completed:**
|
||||||
|
- X of Y stories (Z story points)
|
||||||
|
- Key features: [List]
|
||||||
|
- Technical achievements: [List]
|
||||||
|
|
||||||
|
**Incomplete:**
|
||||||
|
- X stories carried over
|
||||||
|
- Reasons: [Brief explanation]
|
||||||
|
|
||||||
|
**Key Feedback:**
|
||||||
|
|
||||||
|
**Next Sprint Focus:**
|
||||||
|
1. [Primary goal]
|
||||||
|
2. [Secondary goal]
|
||||||
|
3. [Technical focus]
|
||||||
|
|
||||||
|
**Critical Actions:**
|
||||||
|
|
||||||
|
| Action | Owner | Due Date |
|
||||||
|
|----------|--------|----------|
|
||||||
|
| [Action] | [Name] | [Date] |
|
||||||
|
|
||||||
|
**Review Completed By:** [Name]
|
||||||
|
**Documentation Updated:** [Yes/No]
|
||||||
|
|
@ -59,11 +59,15 @@ The goal is quality delivery, not just checking boxes.]]
|
||||||
|
|
||||||
5. **Story Administration:**
|
5. **Story Administration:**
|
||||||
|
|
||||||
[[LLM: Documentation helps the next developer. What should they know?]]
|
[[LLM: Documentation helps the next developer. What should they know? Update Memory Bank and Dev Journal]]
|
||||||
|
|
||||||
- [ ] All tasks within the story file are marked as complete.
|
- [ ] All tasks within the story file are marked as complete.
|
||||||
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
|
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
|
||||||
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
|
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
|
||||||
|
- [ ] Dev Journal entry created documenting implementation decisions and challenges
|
||||||
|
- [ ] Memory Bank updated with new patterns, decisions, or technical context
|
||||||
|
- [ ] ADR created if significant architectural decisions were made
|
||||||
|
- [ ] Comprehensive commit workflow followed with descriptive commit messages
|
||||||
|
|
||||||
6. **Dependencies, Build & Configuration:**
|
6. **Dependencies, Build & Configuration:**
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -38,13 +38,17 @@ We're checking for SUFFICIENT guidance, not exhaustive detail.]]
|
||||||
2. The business value or user benefit is clear
|
2. The business value or user benefit is clear
|
||||||
3. How this fits into the larger epic/product is explained
|
3. How this fits into the larger epic/product is explained
|
||||||
4. Dependencies are explicit ("requires Story X to be complete")
|
4. Dependencies are explicit ("requires Story X to be complete")
|
||||||
5. Success looks like something specific, not vague]]
|
5. Success looks like something specific, not vague
|
||||||
|
6. Memory Bank context has been considered
|
||||||
|
7. Technical principles alignment is clear]]
|
||||||
|
|
||||||
- [ ] Story goal/purpose is clearly stated
|
- [ ] Story goal/purpose is clearly stated
|
||||||
- [ ] Relationship to epic goals is evident
|
- [ ] Relationship to epic goals is evident
|
||||||
- [ ] How the story fits into overall system flow is explained
|
- [ ] How the story fits into overall system flow is explained
|
||||||
- [ ] Dependencies on previous stories are identified (if applicable)
|
- [ ] Dependencies on previous stories are identified (if applicable)
|
||||||
- [ ] Business context and value are clear
|
- [ ] Business context and value are clear
|
||||||
|
- [ ] Memory Bank context referenced where relevant
|
||||||
|
- [ ] Technical principles and preferences considered
|
||||||
|
|
||||||
## 2. TECHNICAL IMPLEMENTATION GUIDANCE
|
## 2. TECHNICAL IMPLEMENTATION GUIDANCE
|
||||||
|
|
||||||
|
|
@ -79,6 +83,8 @@ Note: We don't need every file listed - just the important ones.]]
|
||||||
- [ ] Critical information from previous stories is summarized (not just referenced)
|
- [ ] Critical information from previous stories is summarized (not just referenced)
|
||||||
- [ ] Context is provided for why references are relevant
|
- [ ] Context is provided for why references are relevant
|
||||||
- [ ] References use consistent format (e.g., `docs/filename.md#section`)
|
- [ ] References use consistent format (e.g., `docs/filename.md#section`)
|
||||||
|
- [ ] ADR references included where architectural decisions apply
|
||||||
|
- [ ] Memory Bank files referenced appropriately (activeContext, systemPatterns, etc.)
|
||||||
|
|
||||||
## 4. SELF-CONTAINMENT ASSESSMENT
|
## 4. SELF-CONTAINMENT ASSESSMENT
|
||||||
|
|
||||||
|
|
@ -142,7 +148,7 @@ Generate a concise validation report:
|
||||||
Be pragmatic - perfect documentation doesn't exist, but it must be enough to provide the extreme context a dev agent needs to get the work down and not create a mess.]]
|
Be pragmatic - perfect documentation doesn't exist, but it must be enough to provide the extreme context a dev agent needs to get the work down and not create a mess.]]
|
||||||
|
|
||||||
| Category | Status | Issues |
|
| Category | Status | Issues |
|
||||||
| ------------------------------------ | ------ | ------ |
|
|--------------------------------------|--------|--------|
|
||||||
| 1. Goal & Context Clarity | _TBD_ | |
|
| 1. Goal & Context Clarity | _TBD_ | |
|
||||||
| 2. Technical Implementation Guidance | _TBD_ | |
|
| 2. Technical Implementation Guidance | _TBD_ | |
|
||||||
| 3. Reference Effectiveness | _TBD_ | |
|
| 3. Reference Effectiveness | _TBD_ | |
|
||||||
|
|
|
||||||
|
|
@ -18,3 +18,32 @@ devLoadAlwaysFiles:
|
||||||
devDebugLog: .ai/debug-log.md
|
devDebugLog: .ai/debug-log.md
|
||||||
devStoryLocation: docs/stories
|
devStoryLocation: docs/stories
|
||||||
slashPrefix: BMad
|
slashPrefix: BMad
|
||||||
|
# Memory Bank configuration
|
||||||
|
memoryBank:
|
||||||
|
location: docs/memory-bank
|
||||||
|
autoLoadOnSessionStart: true
|
||||||
|
files:
|
||||||
|
- projectbrief.md
|
||||||
|
- productContext.md
|
||||||
|
- systemPatterns.md
|
||||||
|
- techContext.md
|
||||||
|
- activeContext.md
|
||||||
|
- progress.md
|
||||||
|
# Development Journal configuration
|
||||||
|
devJournal:
|
||||||
|
location: docs/devJournal
|
||||||
|
namePattern: YYYYMMDD-NN.md
|
||||||
|
autoCreateAfterSession: true
|
||||||
|
includeInMemoryBank: true
|
||||||
|
# Architectural Decision Records configuration
|
||||||
|
adr:
|
||||||
|
location: docs/adr
|
||||||
|
namePattern: adr-NNNN.md
|
||||||
|
templateFile: templates/adr-tmpl.md
|
||||||
|
autoLinkToMemoryBank: true
|
||||||
|
# Sprint Management configuration
|
||||||
|
sprint:
|
||||||
|
reviewChecklistPath: checklists/sprint-review-checklist.md
|
||||||
|
sessionKickoffChecklistPath: checklists/session-kickoff-checklist.md
|
||||||
|
enableSprintPlanning: true
|
||||||
|
sprintPlanningTemplate: templates/sprint-planning-tmpl.yaml
|
||||||
|
|
|
||||||
|
|
@ -65,7 +65,7 @@
|
||||||
- **Feature Flags**: Implementation approach
|
- **Feature Flags**: Implementation approach
|
||||||
- **Backward Compatibility**: Version strategy
|
- **Backward Compatibility**: Version strategy
|
||||||
|
|
||||||
## Red Flags - Always Create an ADR When:
|
## Red Flags - Always Create an ADR When
|
||||||
|
|
||||||
1. **Multiple Valid Options Exist**: The team is debating between approaches
|
1. **Multiple Valid Options Exist**: The team is debating between approaches
|
||||||
2. **Significant Cost Implications**: The decision impacts budget substantially
|
2. **Significant Cost Implications**: The decision impacts budget substantially
|
||||||
|
|
@ -76,7 +76,7 @@
|
||||||
7. **Performance Critical**: Decision significantly impacts system performance
|
7. **Performance Critical**: Decision significantly impacts system performance
|
||||||
8. **Security Implications**: Decision affects system security posture
|
8. **Security Implications**: Decision affects system security posture
|
||||||
|
|
||||||
## When NOT to Create an ADR:
|
## When NOT to Create an ADR
|
||||||
|
|
||||||
1. **Implementation Details**: How to name a variable or structure a small module
|
1. **Implementation Details**: How to name a variable or structure a small module
|
||||||
2. **Temporary Solutions**: Quick fixes that will be replaced soon
|
2. **Temporary Solutions**: Quick fixes that will be replaced soon
|
||||||
|
|
@ -84,5 +84,5 @@
|
||||||
4. **Tool Configuration**: Minor tool settings that are easily changeable
|
4. **Tool Configuration**: Minor tool settings that are easily changeable
|
||||||
5. **Obvious Choices**: When there's only one reasonable option
|
5. **Obvious Choices**: When there's only one reasonable option
|
||||||
|
|
||||||
## Remember:
|
## Remember
|
||||||
> "If someone might ask 'Why did we do it this way?' in 6 months, you need an ADR."
|
> "If someone might ask 'Why did we do it this way?' in 6 months, you need an ADR."
|
||||||
|
|
@ -273,7 +273,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
|
||||||
### Core Development Team
|
### Core Development Team
|
||||||
|
|
||||||
| Agent | Role | Primary Functions | When to Use |
|
| Agent | Role | Primary Functions | When to Use |
|
||||||
| ----------- | ------------------ | --------------------------------------- | -------------------------------------- |
|
|-------------|--------------------|-----------------------------------------|----------------------------------------|
|
||||||
| `analyst` | Business Analyst | Market research, requirements gathering | Project planning, competitive analysis |
|
| `analyst` | Business Analyst | Market research, requirements gathering | Project planning, competitive analysis |
|
||||||
| `pm` | Product Manager | PRD creation, feature prioritization | Strategic planning, roadmaps |
|
| `pm` | Product Manager | PRD creation, feature prioritization | Strategic planning, roadmaps |
|
||||||
| `architect` | Solution Architect | System design, technical architecture | Complex systems, scalability planning |
|
| `architect` | Solution Architect | System design, technical architecture | Complex systems, scalability planning |
|
||||||
|
|
@ -286,7 +286,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
|
||||||
### Meta Agents
|
### Meta Agents
|
||||||
|
|
||||||
| Agent | Role | Primary Functions | When to Use |
|
| Agent | Role | Primary Functions | When to Use |
|
||||||
| ------------------- | ---------------- | ------------------------------------- | --------------------------------- |
|
|---------------------|------------------|---------------------------------------|-----------------------------------|
|
||||||
| `bmad-orchestrator` | Team Coordinator | Multi-agent workflows, role switching | Complex multi-role tasks |
|
| `bmad-orchestrator` | Team Coordinator | Multi-agent workflows, role switching | Complex multi-role tasks |
|
||||||
| `bmad-master` | Universal Expert | All capabilities without switching | Single-session comprehensive work |
|
| `bmad-master` | Universal Expert | All capabilities without switching | Single-session comprehensive work |
|
||||||
|
|
||||||
|
|
@ -349,6 +349,104 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
|
||||||
- **Use Case**: Backend services, APIs, system development
|
- **Use Case**: Backend services, APIs, system development
|
||||||
- **Bundle**: `team-no-ui.txt`
|
- **Bundle**: `team-no-ui.txt`
|
||||||
|
|
||||||
|
## Recent Enhancements (Quad Damage)
|
||||||
|
|
||||||
|
### Memory Bank Pattern
|
||||||
|
|
||||||
|
The Memory Bank provides persistent context across AI sessions, ensuring continuity when AI memory resets:
|
||||||
|
|
||||||
|
**Core Files** (in `docs/memory-bank/`):
|
||||||
|
- `projectbrief.md` - Project foundation and goals
|
||||||
|
- `productContext.md` - Problem space and user needs
|
||||||
|
- `systemPatterns.md` - Architecture and technical decisions
|
||||||
|
- `techContext.md` - Technology stack and constraints
|
||||||
|
- `activeContext.md` - Current work and priorities
|
||||||
|
- `progress.md` - Features completed and status
|
||||||
|
|
||||||
|
**Key Features**:
|
||||||
|
- Session initialization with `session-kickoff` task
|
||||||
|
- Automatic updates through `update-memory-bank` task
|
||||||
|
- Integration with dev journals and ADRs
|
||||||
|
- All agents have Memory Bank awareness
|
||||||
|
|
||||||
|
### Architectural Decision Records (ADRs)
|
||||||
|
|
||||||
|
Formal documentation of significant architectural decisions:
|
||||||
|
|
||||||
|
**Features**:
|
||||||
|
- Michael Nygard format in `docs/adr/`
|
||||||
|
- Numbered sequence (0001, 0002, etc.)
|
||||||
|
- Comprehensive template with alternatives analysis
|
||||||
|
- Integration with architect agent
|
||||||
|
- Triggers documented for when to create ADRs
|
||||||
|
|
||||||
|
### Development Journals
|
||||||
|
|
||||||
|
Session documentation for knowledge sharing:
|
||||||
|
|
||||||
|
**Features**:
|
||||||
|
- Daily entries in `docs/devJournal/`
|
||||||
|
- Comprehensive session narratives
|
||||||
|
- Work stream tracking
|
||||||
|
- Technical decision documentation
|
||||||
|
- Anti-tunnel vision mechanisms
|
||||||
|
|
||||||
|
### Enhanced Commit and PR Workflows
|
||||||
|
|
||||||
|
Professional git workflows with comprehensive context:
|
||||||
|
|
||||||
|
**Features**:
|
||||||
|
- Multi-stream commit synthesis
|
||||||
|
- Conventional Commits 1.0 standard
|
||||||
|
- Anti-tunnel vision checks
|
||||||
|
- Comprehensive PR descriptions
|
||||||
|
- Cross-reference integration
|
||||||
|
|
||||||
|
### Technical Principles Integration
|
||||||
|
|
||||||
|
Three sets of architectural and coding principles:
|
||||||
|
|
||||||
|
**1. Coding Standards** (`data/coding-standards.md`):
|
||||||
|
- Core principles with tags ([SF], [DRY], etc.)
|
||||||
|
- Security best practices
|
||||||
|
- Testing standards
|
||||||
|
- Commit conventions
|
||||||
|
|
||||||
|
**2. Twelve-Factor Principles** (`data/twelve-factor-principles.md`):
|
||||||
|
- Cloud-native application design
|
||||||
|
- Environment parity
|
||||||
|
- Stateless processes
|
||||||
|
- Configuration management
|
||||||
|
|
||||||
|
**3. Microservice Patterns** (`data/microservice-patterns.md`):
|
||||||
|
- Service decomposition strategies
|
||||||
|
- Communication patterns
|
||||||
|
- Data management approaches
|
||||||
|
- Testing and deployment patterns
|
||||||
|
|
||||||
|
### Session Kickoff Protocol
|
||||||
|
|
||||||
|
Universal initialization for all agents:
|
||||||
|
|
||||||
|
**Process**:
|
||||||
|
1. Memory Bank review
|
||||||
|
2. Architecture documentation scan
|
||||||
|
3. Dev journal history check
|
||||||
|
4. ADR review
|
||||||
|
5. Current state assessment
|
||||||
|
6. Consistency validation
|
||||||
|
7. Next steps recommendation
|
||||||
|
|
||||||
|
**Usage**: Run `*session-kickoff` at start of any agent session
|
||||||
|
|
||||||
|
### Integration Points
|
||||||
|
|
||||||
|
All enhancements work together:
|
||||||
|
- Memory Bank ← Dev Journals ← ADRs ← Code Changes
|
||||||
|
- Session Kickoff → Memory Bank → Agent Context
|
||||||
|
- Technical Principles → Architecture Decisions → ADRs
|
||||||
|
- Commit/PR Workflows → Dev Journals → Memory Bank
|
||||||
|
|
||||||
## Core Architecture
|
## Core Architecture
|
||||||
|
|
||||||
### System Overview
|
### System Overview
|
||||||
|
|
@ -381,7 +479,7 @@ The BMad-Method is built around a modular architecture centered on the `bmad-cor
|
||||||
- **Templates** (`bmad-core/templates/`): Markdown templates for PRDs, architecture specs, user stories
|
- **Templates** (`bmad-core/templates/`): Markdown templates for PRDs, architecture specs, user stories
|
||||||
- **Tasks** (`bmad-core/tasks/`): Instructions for specific repeatable actions like "shard-doc" or "create-next-story"
|
- **Tasks** (`bmad-core/tasks/`): Instructions for specific repeatable actions like "shard-doc" or "create-next-story"
|
||||||
- **Checklists** (`bmad-core/checklists/`): Quality assurance checklists for validation and review
|
- **Checklists** (`bmad-core/checklists/`): Quality assurance checklists for validation and review
|
||||||
- **Data** (`bmad-core/data/`): Core knowledge base and technical preferences
|
- **Data** (`bmad-core/data/`): Core knowledge base, technical preferences, and project scaffolding guidelines
|
||||||
|
|
||||||
### Dual Environment Architecture
|
### Dual Environment Architecture
|
||||||
|
|
||||||
|
|
@ -409,13 +507,20 @@ BMad employs a sophisticated template system with three key components:
|
||||||
|
|
||||||
### Technical Preferences Integration
|
### Technical Preferences Integration
|
||||||
|
|
||||||
The `technical-preferences.md` file serves as a persistent technical profile that:
|
The framework includes two key preference files:
|
||||||
|
|
||||||
|
**`technical-preferences.md`** - Technology choices and patterns:
|
||||||
- Ensures consistency across all agents and projects
|
- Ensures consistency across all agents and projects
|
||||||
- Eliminates repetitive technology specification
|
- Eliminates repetitive technology specification
|
||||||
- Provides personalized recommendations aligned with user preferences
|
- Provides personalized recommendations aligned with user preferences
|
||||||
- Evolves over time with lessons learned
|
- Evolves over time with lessons learned
|
||||||
|
|
||||||
|
**`project-scaffolding-preference.md`** - Project structure and organization:
|
||||||
|
- Defines standard directory structure for all projects
|
||||||
|
- Provides technology-agnostic scaffolding guidelines
|
||||||
|
- Ensures consistency in documentation organization
|
||||||
|
- Supports BMAD-specific structures (Memory Bank, ADRs, Dev Journals)
|
||||||
|
|
||||||
### Build and Delivery Process
|
### Build and Delivery Process
|
||||||
|
|
||||||
The `web-builder.js` tool creates web-ready bundles by:
|
The `web-builder.js` tool creates web-ready bundles by:
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,88 @@
|
||||||
|
# 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
|
||||||
|
|
@ -1,5 +1,20 @@
|
||||||
# Elicitation Methods Data
|
# Elicitation Methods Data
|
||||||
|
|
||||||
|
## Context-Aware Elicitation
|
||||||
|
|
||||||
|
**Memory Bank Integration**
|
||||||
|
- Begin elicitation with Memory Bank context review
|
||||||
|
- Reference `activeContext.md` for current state understanding
|
||||||
|
- Check `systemPatterns.md` for established conventions
|
||||||
|
- Validate against `progress.md` for completed work
|
||||||
|
- Ensure consistency with historical decisions in ADRs
|
||||||
|
|
||||||
|
**Session Kickoff Prerequisite**
|
||||||
|
- Ensure `*session-kickoff` completed before deep elicitation
|
||||||
|
- Load relevant Dev Journal entries for recent context
|
||||||
|
- Review technical principles and coding standards
|
||||||
|
- Establish shared understanding of project state
|
||||||
|
|
||||||
## Core Reflective Methods
|
## Core Reflective Methods
|
||||||
|
|
||||||
**Expand or Contract for Audience**
|
**Expand or Contract for Audience**
|
||||||
|
|
@ -24,12 +39,20 @@
|
||||||
- Check internal consistency and coherence
|
- Check internal consistency and coherence
|
||||||
- Identify and validate dependencies between elements
|
- Identify and validate dependencies between elements
|
||||||
- Confirm effective ordering and sequencing
|
- Confirm effective ordering and sequencing
|
||||||
|
- Cross-reference with Memory Bank patterns for consistency
|
||||||
|
|
||||||
**Assess Alignment with Overall Goals**
|
**Assess Alignment with Overall Goals**
|
||||||
- Evaluate content contribution to stated objectives
|
- Evaluate content contribution to stated objectives
|
||||||
- Identify any misalignments or gaps
|
- Identify any misalignments or gaps
|
||||||
- Interpret alignment from specific role's perspective
|
- Interpret alignment from specific role's perspective
|
||||||
- Suggest adjustments to better serve goals
|
- Suggest adjustments to better serve goals
|
||||||
|
- Validate against `projectbrief.md` for mission alignment
|
||||||
|
|
||||||
|
**Memory Bank Pattern Validation**
|
||||||
|
- Compare proposed approaches with documented patterns
|
||||||
|
- Identify deviations from established conventions
|
||||||
|
- Assess if new patterns should be documented
|
||||||
|
- Update `systemPatterns.md` with validated approaches
|
||||||
|
|
||||||
## Risk and Challenge Methods
|
## Risk and Challenge Methods
|
||||||
|
|
||||||
|
|
@ -126,9 +149,36 @@
|
||||||
- Identify minimum viable approach
|
- Identify minimum viable approach
|
||||||
- Discover innovative workarounds and optimizations
|
- Discover innovative workarounds and optimizations
|
||||||
|
|
||||||
|
## Memory Bank Elicitation Methods
|
||||||
|
|
||||||
|
**Historical Context Mining**
|
||||||
|
- Extract insights from Dev Journal entries
|
||||||
|
- Identify recurring patterns across sessions
|
||||||
|
- Discover implicit knowledge in past decisions
|
||||||
|
- Build on previous architectural choices
|
||||||
|
|
||||||
|
**Progressive Context Building**
|
||||||
|
- Start with `projectbrief.md` for foundation
|
||||||
|
- Layer in `techContext.md` for technical constraints
|
||||||
|
- Add `systemPatterns.md` for design conventions
|
||||||
|
- Integrate `activeContext.md` for current state
|
||||||
|
|
||||||
|
**ADR-Driven Discovery**
|
||||||
|
- Review ADRs for decision rationale
|
||||||
|
- Identify constraints from past choices
|
||||||
|
- Understand trade-offs already considered
|
||||||
|
- Build on established architectural principles
|
||||||
|
|
||||||
|
**Sprint Context Elicitation**
|
||||||
|
- Review sprint goals from planning documents
|
||||||
|
- Check progress against sprint commitments
|
||||||
|
- Identify blockers from Dev Journals
|
||||||
|
- Align new work with sprint objectives
|
||||||
|
|
||||||
## Process Control
|
## Process Control
|
||||||
|
|
||||||
**Proceed / No Further Actions**
|
**Proceed / No Further Actions**
|
||||||
- Acknowledge choice to finalize current work
|
- Acknowledge choice to finalize current work
|
||||||
- Accept output as-is or move to next step
|
- Accept output as-is or move to next step
|
||||||
- Prepare to continue without additional elicitation
|
- Prepare to continue without additional elicitation
|
||||||
|
- Update Memory Bank with elicitation outcomes
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,125 @@
|
||||||
|
# Microservice Architecture Patterns
|
||||||
|
|
||||||
|
> **Purpose:** This document outlines specific patterns and strategies for implementing Microservice-Oriented Architecture, based on Chris Richardson's "Microservices Patterns". It provides detailed guidance for service design, decomposition, communication, and data management.
|
||||||
|
|
||||||
|
## Core Architecture Patterns
|
||||||
|
|
||||||
|
### Foundation Patterns
|
||||||
|
- **[MON] Monolithic Architecture:** Single deployable unit. Good for simple applications, becomes "monolithic hell" as complexity grows.
|
||||||
|
- **[MSA] Microservice Architecture:** Collection of small, autonomous, loosely coupled services. Core pattern for complex systems.
|
||||||
|
|
||||||
|
### Service Decomposition
|
||||||
|
- **[DBC] Decompose by Business Capability:** Define services based on business capabilities (e.g., Order Management, Inventory).
|
||||||
|
- **[DSD] Decompose by Subdomain:** Use Domain-Driven Design to define services around problem subdomains.
|
||||||
|
|
||||||
|
## Communication Patterns
|
||||||
|
|
||||||
|
### Synchronous Communication
|
||||||
|
- **[RPI] Remote Procedure Invocation:** Synchronous request/response (REST, gRPC). Simple but creates coupling.
|
||||||
|
- **[CBR] Circuit Breaker:** Prevent cascading failures. Trip after consecutive failures, fail fast.
|
||||||
|
|
||||||
|
### Asynchronous Communication
|
||||||
|
- **[MSG] Messaging:** Services communicate via message broker. Promotes loose coupling and resilience.
|
||||||
|
- **[DME] Domain Events:** Aggregates publish events when state changes. Foundation for event-driven architecture.
|
||||||
|
|
||||||
|
### Service Discovery
|
||||||
|
- **[SDC] Service Discovery:** Patterns for finding service instances in dynamic cloud environments:
|
||||||
|
- Client-side discovery
|
||||||
|
- Server-side discovery
|
||||||
|
- Service registry patterns
|
||||||
|
|
||||||
|
## Data Management Patterns
|
||||||
|
|
||||||
|
### Data Architecture
|
||||||
|
- **[DPS] Database per Service:** Each service owns its data. Fundamental to loose coupling.
|
||||||
|
- **[AGG] Aggregate:** Cluster of domain objects as single unit. Transactions only create/update single aggregate.
|
||||||
|
|
||||||
|
### Data Consistency
|
||||||
|
- **[SAG] Saga:** Manage data consistency across services without distributed transactions:
|
||||||
|
- Sequence of local transactions
|
||||||
|
- Event/message triggered
|
||||||
|
- Compensating transactions on failure
|
||||||
|
|
||||||
|
### Event Patterns
|
||||||
|
- **[EVS] Event Sourcing:** Store state-changing events rather than current state. Provides audit log.
|
||||||
|
- **[OUT] Transactional Outbox:** Reliably publish messages as part of local database transaction.
|
||||||
|
|
||||||
|
### Query Patterns
|
||||||
|
- **[APC] API Composition:** Client retrieves and joins data from multiple services. Simple but inefficient for complex queries.
|
||||||
|
- **[CQR] CQRS:** Separate command (write) and query (read) models. Maintain denormalized read views.
|
||||||
|
|
||||||
|
## API Patterns
|
||||||
|
|
||||||
|
### Gateway Patterns
|
||||||
|
- **[APG] API Gateway:** Single entry point for all clients. Routes requests, handles cross-cutting concerns.
|
||||||
|
- **[BFF] Backends for Frontends:** Separate API gateway for each client type (mobile, web).
|
||||||
|
|
||||||
|
## Domain Modeling
|
||||||
|
|
||||||
|
### Design Approaches
|
||||||
|
- **[DOM] Domain Model:** Object-oriented with state and behavior. Preferred for complex logic.
|
||||||
|
- **[TSF] Transaction Script:** Procedural approach. Simpler but unmanageable for complex logic.
|
||||||
|
|
||||||
|
## Testing Patterns
|
||||||
|
|
||||||
|
### Service Testing
|
||||||
|
- **[CDC] Consumer-Driven Contract Test:** Consumer writes tests to verify provider meets expectations.
|
||||||
|
- **[SCT] Service Component Test:** Acceptance test for single service with stubbed dependencies.
|
||||||
|
|
||||||
|
## Deployment Patterns
|
||||||
|
|
||||||
|
### Container Patterns
|
||||||
|
- **[SVC] Service as Container:** Package service as container image to encapsulate technology stack.
|
||||||
|
- **[SRL] Serverless Deployment:** Deploy using serverless platform (e.g., AWS Lambda).
|
||||||
|
|
||||||
|
### Infrastructure Patterns
|
||||||
|
- **[MSC] Microservice Chassis:** Framework handling cross-cutting concerns (config, health, metrics).
|
||||||
|
- **[SMH] Service Mesh:** Infrastructure layer for inter-service communication (Istio, Linkerd).
|
||||||
|
|
||||||
|
## Migration Patterns
|
||||||
|
|
||||||
|
### Legacy Modernization
|
||||||
|
- **[STR] Strangler Application:** Incrementally build microservices around monolith. Gradual replacement.
|
||||||
|
|
||||||
|
## Best Practices
|
||||||
|
|
||||||
|
### Service Design
|
||||||
|
1. Services should be loosely coupled and highly cohesive
|
||||||
|
2. Own their data and business logic
|
||||||
|
3. Communicate through well-defined interfaces
|
||||||
|
4. Be independently deployable
|
||||||
|
|
||||||
|
### Transaction Management
|
||||||
|
1. Avoid distributed transactions
|
||||||
|
2. Use saga pattern for cross-service consistency
|
||||||
|
3. Design for eventual consistency
|
||||||
|
4. Implement idempotency
|
||||||
|
|
||||||
|
### Resilience
|
||||||
|
1. Implement circuit breakers
|
||||||
|
2. Use timeouts and retries wisely
|
||||||
|
3. Design for failure
|
||||||
|
4. Implement health checks
|
||||||
|
|
||||||
|
### Observability
|
||||||
|
1. Distributed tracing across services
|
||||||
|
2. Centralized logging
|
||||||
|
3. Service-level metrics
|
||||||
|
4. Business metrics
|
||||||
|
|
||||||
|
## Anti-Patterns to Avoid
|
||||||
|
|
||||||
|
1. **Distributed Monolith:** Microservices that must be deployed together
|
||||||
|
2. **Chatty Services:** Excessive inter-service communication
|
||||||
|
3. **Shared Database:** Multiple services accessing same database
|
||||||
|
4. **Synchronous Communication Everywhere:** Over-reliance on RPI
|
||||||
|
5. **Missing Service Boundaries:** Services that don't align with business capabilities
|
||||||
|
|
||||||
|
## Integration with BMAD
|
||||||
|
|
||||||
|
These patterns should be:
|
||||||
|
1. Considered during architecture design phase
|
||||||
|
2. Documented in Architecture Decision Records (ADRs)
|
||||||
|
3. Applied based on specific project requirements
|
||||||
|
4. Validated against twelve-factor principles
|
||||||
|
5. Reviewed for applicability to project scale and complexity
|
||||||
|
|
@ -0,0 +1,264 @@
|
||||||
|
# Project Scaffolding Preferences
|
||||||
|
|
||||||
|
This document defines generic, technology-agnostic project scaffolding preferences that can be applied to any software project. These preferences promote consistency, maintainability, and best practices across different technology stacks.
|
||||||
|
|
||||||
|
## Documentation Structure
|
||||||
|
|
||||||
|
### Core Documentation
|
||||||
|
- **README**: Primary project documentation with setup instructions, architecture overview, and contribution guidelines
|
||||||
|
- **CHANGELOG**: Maintain detailed changelog following semantic versioning principles
|
||||||
|
- **LICENSE**: Clear licensing information for the project
|
||||||
|
- **Contributing Guidelines**: How to contribute, code standards, and review process
|
||||||
|
|
||||||
|
### BMAD Documentation Structure
|
||||||
|
- **Product Requirements Document (PRD)**:
|
||||||
|
- Single source file: `docs/prd.md`
|
||||||
|
- Can be sharded into `docs/prd/` directory by level 2 sections
|
||||||
|
- Contains epics, stories, requirements
|
||||||
|
|
||||||
|
- **Architecture Documentation**:
|
||||||
|
- Single source file: `docs/architecture.md` or `docs/brownfield-architecture.md`
|
||||||
|
- Can be sharded into `docs/architecture/` directory
|
||||||
|
- For brownfield: Document actual state including technical debt
|
||||||
|
|
||||||
|
- **Memory Bank** (AI Context Persistence):
|
||||||
|
- Location: `docs/memory-bank/`
|
||||||
|
- Core files: projectbrief.md, productContext.md, systemPatterns.md, techContext.md, activeContext.md, progress.md
|
||||||
|
- Provides persistent context across AI sessions
|
||||||
|
|
||||||
|
### Architectural Documentation
|
||||||
|
- **Architecture Decision Records (ADRs)**: Document significant architectural decisions
|
||||||
|
- Location: `docs/adr/`
|
||||||
|
- When to create: Major dependency changes, pattern changes, integration approaches, schema modifications
|
||||||
|
- Follow consistent ADR template (e.g., Michael Nygard format)
|
||||||
|
- Number sequentially (e.g., adr-0001.md)
|
||||||
|
- Maintain an index
|
||||||
|
|
||||||
|
### Development Documentation
|
||||||
|
- **Development Journals**: Track daily/session work, decisions, and challenges
|
||||||
|
- Location: `docs/devJournal/`
|
||||||
|
- Named with date format: `YYYYMMDD-NN.md`
|
||||||
|
- Include work completed, decisions made, blockers encountered
|
||||||
|
- Reference relevant ADRs and feature documentation
|
||||||
|
- Create after significant work sessions
|
||||||
|
|
||||||
|
### Feature Documentation
|
||||||
|
- **Roadmap**: High-level project direction and planned features
|
||||||
|
- Location: `docs/roadmap/`
|
||||||
|
- Feature details in `docs/roadmap/features/`
|
||||||
|
- **Epics and Stories**:
|
||||||
|
- Epics extracted from PRD to `docs/epics/`
|
||||||
|
- Stories created from epics to `docs/stories/`
|
||||||
|
- Follow naming: `epic-N-story-M.md`
|
||||||
|
|
||||||
|
## Source Code Organization
|
||||||
|
|
||||||
|
### Separation of Concerns
|
||||||
|
- **Frontend/UI**: Dedicated location for user interface components
|
||||||
|
- **Backend/API**: Separate backend logic and API implementations
|
||||||
|
- **Shared Utilities**: Common functionality used across layers
|
||||||
|
- **Configuration**: Centralized configuration management
|
||||||
|
- **Scripts**: Automation and utility scripts
|
||||||
|
|
||||||
|
### Testing Structure
|
||||||
|
- **Unit Tests**: Close to source code or in dedicated test directories
|
||||||
|
- **Integration Tests**: Test component interactions
|
||||||
|
- **End-to-End Tests**: Full workflow testing
|
||||||
|
- **Test Utilities**: Shared test helpers and fixtures
|
||||||
|
- **Test Documentation**: How to run tests, test strategies
|
||||||
|
|
||||||
|
## Project Root Structure
|
||||||
|
|
||||||
|
### Essential Files
|
||||||
|
- Version control ignore files (e.g., .gitignore)
|
||||||
|
- Editor/IDE configuration files
|
||||||
|
- Dependency management files
|
||||||
|
- Build/deployment configuration
|
||||||
|
- Environment configuration templates (never commit actual secrets)
|
||||||
|
|
||||||
|
### Standard Directories
|
||||||
|
```
|
||||||
|
/docs
|
||||||
|
/adr # Architecture Decision Records
|
||||||
|
/devJournal # Development journals
|
||||||
|
/memory-bank # Persistent AI context (BMAD-specific)
|
||||||
|
/prd # Sharded Product Requirements Documents
|
||||||
|
/architecture # Sharded Architecture Documents
|
||||||
|
/stories # User stories (from epics)
|
||||||
|
/epics # Epic documents
|
||||||
|
/api # API documentation
|
||||||
|
/roadmap # Project roadmap and features
|
||||||
|
|
||||||
|
/src
|
||||||
|
/[frontend] # UI/frontend code
|
||||||
|
/[backend] # Backend/API code
|
||||||
|
/[shared] # Shared utilities
|
||||||
|
/[config] # Configuration
|
||||||
|
|
||||||
|
/tests
|
||||||
|
/unit # Unit tests
|
||||||
|
/integration # Integration tests
|
||||||
|
/e2e # End-to-end tests
|
||||||
|
|
||||||
|
/scripts # Build, deployment, utility scripts
|
||||||
|
/tools # Development tools and utilities
|
||||||
|
/.bmad # BMAD-specific configuration and overrides
|
||||||
|
```
|
||||||
|
|
||||||
|
## Development Practices
|
||||||
|
|
||||||
|
### Code Organization
|
||||||
|
- Keep files focused and manageable (typically under 300 lines)
|
||||||
|
- Prefer composition over inheritance
|
||||||
|
- Avoid code duplication - check for existing implementations
|
||||||
|
- Use clear, consistent naming conventions throughout
|
||||||
|
- Document complex logic and non-obvious decisions
|
||||||
|
|
||||||
|
### Documentation Discipline
|
||||||
|
- Update documentation alongside code changes
|
||||||
|
- Document the "why" not just the "what"
|
||||||
|
- Keep examples current and working
|
||||||
|
- Review documentation in code reviews
|
||||||
|
- Maintain templates for consistency
|
||||||
|
|
||||||
|
### Security Considerations
|
||||||
|
- Never commit secrets or credentials
|
||||||
|
- Use environment variables for configuration
|
||||||
|
- Implement proper input validation
|
||||||
|
- Manage resources appropriately (close connections, free memory)
|
||||||
|
- Follow principle of least privilege
|
||||||
|
- Document security considerations
|
||||||
|
|
||||||
|
### Quality Standards
|
||||||
|
- All code must pass linting and formatting checks
|
||||||
|
- Automated testing at multiple levels
|
||||||
|
- Code review required before merging
|
||||||
|
- Continuous integration for all changes
|
||||||
|
- Regular dependency updates
|
||||||
|
|
||||||
|
## Accessibility & Inclusion
|
||||||
|
|
||||||
|
### Universal Design
|
||||||
|
- Consider accessibility from the start
|
||||||
|
- Follow established accessibility standards (e.g., WCAG)
|
||||||
|
- Ensure keyboard navigation support
|
||||||
|
- Provide appropriate text alternatives
|
||||||
|
- Test with assistive technologies
|
||||||
|
|
||||||
|
### Inclusive Practices
|
||||||
|
- Use clear, inclusive language in documentation
|
||||||
|
- Consider diverse user needs and contexts
|
||||||
|
- Document accessibility requirements
|
||||||
|
- Include accessibility in testing
|
||||||
|
|
||||||
|
## Database/Data Management
|
||||||
|
|
||||||
|
### Schema Management
|
||||||
|
- Version control all schema changes
|
||||||
|
- Use migration tools for consistency
|
||||||
|
- Document schema decisions in ADRs
|
||||||
|
- Maintain data dictionary
|
||||||
|
- Never make manual production changes
|
||||||
|
|
||||||
|
### Data Documentation
|
||||||
|
- Maintain current entity relationship diagrams
|
||||||
|
- Document data flows and dependencies
|
||||||
|
- Explain business rules and constraints
|
||||||
|
- Keep sample data separate from production
|
||||||
|
|
||||||
|
## Environment Management
|
||||||
|
|
||||||
|
### Environment Parity
|
||||||
|
- Development, test, and production should be as similar as possible
|
||||||
|
- Use same deployment process across environments
|
||||||
|
- Configuration through environment variables
|
||||||
|
- Document environment-specific settings
|
||||||
|
- Automate environment setup
|
||||||
|
|
||||||
|
### Local Development
|
||||||
|
- Provide scripted setup process
|
||||||
|
- Document all prerequisites
|
||||||
|
- Include reset/cleanup scripts
|
||||||
|
- Maintain environment templates
|
||||||
|
- Support multiple development environments
|
||||||
|
|
||||||
|
## Branching & Release Strategy
|
||||||
|
|
||||||
|
### Version Control
|
||||||
|
- Define clear branching strategy
|
||||||
|
- Use semantic versioning
|
||||||
|
- Tag all releases
|
||||||
|
- Maintain release notes
|
||||||
|
- Document hotfix procedures
|
||||||
|
|
||||||
|
### Release Process
|
||||||
|
- Automated build and deployment
|
||||||
|
- Staged rollout capabilities
|
||||||
|
- Rollback procedures documented
|
||||||
|
- Release communication plan
|
||||||
|
- Post-release verification
|
||||||
|
|
||||||
|
## Incident Management
|
||||||
|
|
||||||
|
### Incident Response
|
||||||
|
- Maintain incident log
|
||||||
|
- Document root cause analyses
|
||||||
|
- Update runbooks based on incidents
|
||||||
|
- Conduct retrospectives
|
||||||
|
- Share learnings across team
|
||||||
|
|
||||||
|
### Monitoring & Observability
|
||||||
|
- Define key metrics
|
||||||
|
- Implement appropriate logging
|
||||||
|
- Set up alerting thresholds
|
||||||
|
- Document troubleshooting guides
|
||||||
|
- Regular review of metrics
|
||||||
|
|
||||||
|
## Compliance & Governance
|
||||||
|
|
||||||
|
### Data Privacy
|
||||||
|
- Document data handling practices
|
||||||
|
- Implement privacy by design
|
||||||
|
- Regular compliance reviews
|
||||||
|
- Clear data retention policies
|
||||||
|
- User consent management
|
||||||
|
|
||||||
|
### Audit Trail
|
||||||
|
- Maintain change history
|
||||||
|
- Document decision rationale
|
||||||
|
- Track access and modifications
|
||||||
|
- Regular security reviews
|
||||||
|
- Compliance documentation
|
||||||
|
|
||||||
|
## BMAD-Specific Considerations
|
||||||
|
|
||||||
|
### Session Management
|
||||||
|
- **Session Kickoff**: Always start new AI sessions with proper context initialization
|
||||||
|
- **Memory Bank Maintenance**: Keep context files current throughout development
|
||||||
|
- **Dev Journal Creation**: Document significant work sessions
|
||||||
|
- **Sprint Reviews**: Regular quality and progress assessments
|
||||||
|
|
||||||
|
### Document Sharding
|
||||||
|
- **When to Shard**: Large PRDs and architecture documents (>1000 lines)
|
||||||
|
- **How to Shard**: By level 2 sections, maintaining index.md
|
||||||
|
- **Naming Convention**: Convert section headings to lowercase-dash-case
|
||||||
|
- **Tool Support**: Use markdown-tree-parser when available
|
||||||
|
|
||||||
|
### Brownfield vs Greenfield
|
||||||
|
- **Greenfield**: Start with PRD → Architecture → Implementation
|
||||||
|
- **Brownfield**: Document existing → Create focused PRD → Enhance
|
||||||
|
- **Documentation Focus**: Brownfield docs capture actual state, not ideal
|
||||||
|
- **Technical Debt**: Always document workarounds and constraints
|
||||||
|
|
||||||
|
## Best Practices Summary
|
||||||
|
|
||||||
|
1. **Simplicity First**: Choose the simplest solution that works
|
||||||
|
2. **Documentation as Code**: Treat documentation with same rigor as code
|
||||||
|
3. **Automate Everything**: If it's done twice, automate it
|
||||||
|
4. **Security by Default**: Consider security implications in every decision
|
||||||
|
5. **Test Early and Often**: Multiple levels of testing for confidence
|
||||||
|
6. **Continuous Improvement**: Regular retrospectives and improvements
|
||||||
|
7. **Accessibility Always**: Build inclusive solutions from the start
|
||||||
|
8. **Clean as You Go**: Maintain code quality continuously
|
||||||
|
9. **Context Persistence**: Maintain Memory Bank for AI continuity
|
||||||
|
10. **Reality Over Ideals**: Document what exists, not what should be
|
||||||
|
|
@ -0,0 +1,128 @@
|
||||||
|
# Sprint Review Triggers
|
||||||
|
|
||||||
|
This document outlines when and how to conduct sprint reviews within the BMAD framework.
|
||||||
|
|
||||||
|
## When to Conduct Sprint Reviews
|
||||||
|
|
||||||
|
### Regular Cadence
|
||||||
|
- **End of Sprint**: Always conduct at the conclusion of each defined sprint period
|
||||||
|
- **Weekly/Bi-weekly**: Based on your sprint duration
|
||||||
|
- **After Major Milestones**: When significant features or phases complete
|
||||||
|
|
||||||
|
### Event-Based Triggers
|
||||||
|
- **Epic Completion**: When all stories in an epic are done
|
||||||
|
- **Release Preparation**: Before any production release
|
||||||
|
- **Team Changes**: When team composition changes significantly
|
||||||
|
- **Process Issues**: When recurring blockers or challenges arise
|
||||||
|
- **Client Reviews**: Before or after stakeholder demonstrations
|
||||||
|
|
||||||
|
## Sprint Review Components
|
||||||
|
|
||||||
|
### 1. **Metrics Gathering** (Automated)
|
||||||
|
- Git commit analysis
|
||||||
|
- PR merge tracking
|
||||||
|
- Issue closure rates
|
||||||
|
- Test coverage changes
|
||||||
|
- Build/deployment success rates
|
||||||
|
|
||||||
|
### 2. **Achievement Documentation**
|
||||||
|
- Feature completions with evidence
|
||||||
|
- Technical improvements made
|
||||||
|
- Documentation updates
|
||||||
|
- Bug fixes and resolutions
|
||||||
|
|
||||||
|
### 3. **Retrospective Elements**
|
||||||
|
- What went well (celebrate successes)
|
||||||
|
- What didn't go well (identify issues)
|
||||||
|
- What we learned (capture insights)
|
||||||
|
- What we'll try next (action items)
|
||||||
|
|
||||||
|
### 4. **Memory Bank Updates**
|
||||||
|
- Update progress.md with completed features
|
||||||
|
- Update activeContext.md with current state
|
||||||
|
- Document new patterns in systemPatterns.md
|
||||||
|
- Reflect on technical decisions
|
||||||
|
|
||||||
|
## Sprint Review Best Practices
|
||||||
|
|
||||||
|
### Preparation
|
||||||
|
- Schedule review 1-2 days before sprint end
|
||||||
|
- Gather metrics using git commands beforehand
|
||||||
|
- Review dev journals from the sprint
|
||||||
|
- Prepare demo materials if applicable
|
||||||
|
|
||||||
|
### Facilitation
|
||||||
|
- Keep to 60-90 minutes maximum
|
||||||
|
- Encourage all team members to contribute
|
||||||
|
- Focus on facts and evidence
|
||||||
|
- Balance positive and improvement areas
|
||||||
|
- Make action items specific and assignable
|
||||||
|
|
||||||
|
### Documentation
|
||||||
|
- Use consistent naming: `YYYYMMDD-sprint-review.md`
|
||||||
|
- Place in `docs/devJournal/` directory
|
||||||
|
- Link to relevant PRs, issues, and commits
|
||||||
|
- Include screenshots or recordings when helpful
|
||||||
|
|
||||||
|
### Follow-up
|
||||||
|
- Assign owners to all action items
|
||||||
|
- Set deadlines for improvements
|
||||||
|
- Review previous sprint's action items
|
||||||
|
- Update project Memory Bank
|
||||||
|
- Share outcomes with stakeholders
|
||||||
|
|
||||||
|
## Integration with BMAD Workflow
|
||||||
|
|
||||||
|
### Before Sprint Review
|
||||||
|
1. Complete all story reviews
|
||||||
|
2. Update CHANGELOG.md
|
||||||
|
3. Ensure dev journals are current
|
||||||
|
4. Close completed issues/PRs
|
||||||
|
|
||||||
|
### During Sprint Review
|
||||||
|
1. Use `*sprint-review` command as Scrum Master
|
||||||
|
2. Follow the guided template
|
||||||
|
3. Gather team input actively
|
||||||
|
4. Document honestly and thoroughly
|
||||||
|
|
||||||
|
### After Sprint Review
|
||||||
|
1. Update Memory Bank (`*update-memory-bank`)
|
||||||
|
2. Create next sprint's initial backlog
|
||||||
|
3. Communicate outcomes to stakeholders
|
||||||
|
4. Schedule action item check-ins
|
||||||
|
5. Archive sprint artifacts
|
||||||
|
|
||||||
|
## Anti-Patterns to Avoid
|
||||||
|
|
||||||
|
- **Skipping Reviews**: Even failed sprints need reviews
|
||||||
|
- **Solo Reviews**: Include the whole team when possible
|
||||||
|
- **Blame Sessions**: Focus on process, not people
|
||||||
|
- **No Action Items**: Every review should produce improvements
|
||||||
|
- **Lost Knowledge**: Always document in standard location
|
||||||
|
- **Metrics Without Context**: Numbers need interpretation
|
||||||
|
|
||||||
|
## Quick Reference
|
||||||
|
|
||||||
|
### Git Commands for Metrics
|
||||||
|
```bash
|
||||||
|
# Commits in sprint
|
||||||
|
git log --since="2024-01-01" --until="2024-01-14" --oneline | wc -l
|
||||||
|
|
||||||
|
# PRs merged
|
||||||
|
git log --merges --since="2024-01-01" --until="2024-01-14" --oneline
|
||||||
|
|
||||||
|
# Issues closed
|
||||||
|
git log --since="2024-01-01" --until="2024-01-14" --grep="close[sd]\|fixe[sd]" --oneline
|
||||||
|
|
||||||
|
# Active branches
|
||||||
|
git branch --format='%(refname:short) %(creatordate:short)' | grep '2024-01'
|
||||||
|
```
|
||||||
|
|
||||||
|
### Review Checklist
|
||||||
|
- [ ] Sprint dates and goal documented
|
||||||
|
- [ ] All metrics gathered
|
||||||
|
- [ ] Features linked to PRs
|
||||||
|
- [ ] Retrospective completed
|
||||||
|
- [ ] Action items assigned
|
||||||
|
- [ ] Memory Bank updated
|
||||||
|
- [ ] Next sprint prepared
|
||||||
|
|
@ -1,3 +1,43 @@
|
||||||
# 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
|
None Listed
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,123 @@
|
||||||
|
# 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
|
||||||
|
|
@ -0,0 +1,170 @@
|
||||||
|
# Conduct Sprint Review
|
||||||
|
|
||||||
|
This task guides the Scrum Master through conducting a comprehensive sprint review and retrospective at the end of each sprint or major iteration.
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
- Document sprint achievements and deliverables
|
||||||
|
- Analyze sprint metrics and goal completion
|
||||||
|
- Facilitate team retrospective
|
||||||
|
- Capture learnings and action items
|
||||||
|
- Update Memory Bank with sprint outcomes
|
||||||
|
|
||||||
|
## Process
|
||||||
|
|
||||||
|
### 1. Gather Sprint Context
|
||||||
|
|
||||||
|
Before starting the review, collect:
|
||||||
|
|
||||||
|
**Sprint Information**:
|
||||||
|
- Sprint dates (start and end)
|
||||||
|
- Sprint goal/theme
|
||||||
|
- Team participants
|
||||||
|
- Active branches/releases
|
||||||
|
|
||||||
|
**Metrics** (use git commands):
|
||||||
|
```bash
|
||||||
|
# Commits during sprint
|
||||||
|
git log --since="YYYY-MM-DD" --until="YYYY-MM-DD" --oneline | wc -l
|
||||||
|
|
||||||
|
# PRs merged
|
||||||
|
git log --merges --since="YYYY-MM-DD" --until="YYYY-MM-DD" --oneline | wc -l
|
||||||
|
|
||||||
|
# Issues closed
|
||||||
|
git log --since="YYYY-MM-DD" --until="YYYY-MM-DD" --grep="close[sd]\|fixe[sd]" --oneline | wc -l
|
||||||
|
|
||||||
|
# Branches created
|
||||||
|
git branch --format='%(refname:short) %(creatordate:short)' | grep 'YYYY-MM'
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Review Dev Journals
|
||||||
|
|
||||||
|
Scan recent dev journal entries to identify:
|
||||||
|
- Major features completed
|
||||||
|
- Technical challenges overcome
|
||||||
|
- Patterns established
|
||||||
|
- Decisions made
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ls -la docs/devJournal/*.md | tail -10
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Review ADRs
|
||||||
|
|
||||||
|
Check for new architectural decisions:
|
||||||
|
```bash
|
||||||
|
ls -la docs/adr/*.md | tail -5
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. Create Sprint Review Document
|
||||||
|
|
||||||
|
Create file: `docs/devJournal/YYYYMMDD-sprint-review.md`
|
||||||
|
|
||||||
|
Use the sprint-review-tmpl.yaml template (or create manually) covering:
|
||||||
|
|
||||||
|
#### Essential Sections
|
||||||
|
|
||||||
|
**1. Sprint Overview**
|
||||||
|
- Sprint dates and goal
|
||||||
|
- Participants and roles
|
||||||
|
- Branch/release information
|
||||||
|
|
||||||
|
**2. Achievements & Deliverables**
|
||||||
|
- Major features completed (with PR links)
|
||||||
|
- Technical milestones reached
|
||||||
|
- Documentation updates
|
||||||
|
- Testing improvements
|
||||||
|
|
||||||
|
**3. Sprint Metrics**
|
||||||
|
- Commit count
|
||||||
|
- PRs merged (with details)
|
||||||
|
- Issues closed
|
||||||
|
- Test coverage changes
|
||||||
|
|
||||||
|
**4. Goal Review**
|
||||||
|
- What was planned vs achieved
|
||||||
|
- Items not completed (with reasons)
|
||||||
|
- Goal completion percentage
|
||||||
|
|
||||||
|
**5. Demo & Walkthrough**
|
||||||
|
- Screenshots/videos if available
|
||||||
|
- Instructions for reviewing features
|
||||||
|
|
||||||
|
**6. Retrospective**
|
||||||
|
- **What Went Well**: Successes and effective practices
|
||||||
|
- **What Didn't Go Well**: Blockers and pain points
|
||||||
|
- **What We Learned**: Technical and process insights
|
||||||
|
- **What We'll Try Next**: Improvement experiments
|
||||||
|
|
||||||
|
**7. Action Items**
|
||||||
|
- Concrete actions with owners
|
||||||
|
- Deadlines for next sprint
|
||||||
|
- Process improvements to implement
|
||||||
|
|
||||||
|
**8. References**
|
||||||
|
- Dev journal entries from sprint
|
||||||
|
- New/updated ADRs
|
||||||
|
- CHANGELOG updates
|
||||||
|
- Memory Bank updates
|
||||||
|
|
||||||
|
### 5. Update Memory Bank
|
||||||
|
|
||||||
|
After sprint review, update:
|
||||||
|
|
||||||
|
**activeContext.md**:
|
||||||
|
- Current sprint outcomes
|
||||||
|
- Next sprint priorities
|
||||||
|
- Active action items
|
||||||
|
|
||||||
|
**progress.md**:
|
||||||
|
- Features completed this sprint
|
||||||
|
- Overall project progress
|
||||||
|
- Velocity trends
|
||||||
|
|
||||||
|
**systemPatterns.md** (if applicable):
|
||||||
|
- New patterns adopted
|
||||||
|
- Technical decisions from retrospective
|
||||||
|
|
||||||
|
### 6. Facilitate Team Discussion
|
||||||
|
|
||||||
|
If in party-mode or team setting:
|
||||||
|
- Share sprint review with team
|
||||||
|
- Gather additional feedback
|
||||||
|
- Refine action items collaboratively
|
||||||
|
- Celebrate achievements
|
||||||
|
|
||||||
|
### 7. Prepare for Next Sprint
|
||||||
|
|
||||||
|
Based on review outcomes:
|
||||||
|
- Update backlog priorities
|
||||||
|
- Create next sprint goal
|
||||||
|
- Schedule action item follow-ups
|
||||||
|
- Communicate decisions to stakeholders
|
||||||
|
|
||||||
|
## Quality Checklist
|
||||||
|
|
||||||
|
- [ ] All sprint metrics gathered and documented
|
||||||
|
- [ ] Achievements clearly linked to sprint goal
|
||||||
|
- [ ] Honest assessment of what wasn't completed
|
||||||
|
- [ ] Retrospective captures diverse perspectives
|
||||||
|
- [ ] Action items are specific and assigned
|
||||||
|
- [ ] Memory Bank updated with outcomes
|
||||||
|
- [ ] Document follows naming convention
|
||||||
|
- [ ] References to related documentation included
|
||||||
|
|
||||||
|
## Output
|
||||||
|
|
||||||
|
The sprint review document serves as:
|
||||||
|
- Historical record of sprint progress
|
||||||
|
- Input for project reporting
|
||||||
|
- Source for continuous improvement
|
||||||
|
- Knowledge transfer for future sprints
|
||||||
|
- Update source for Memory Bank
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
|
||||||
|
- Conduct reviews even for partial sprints
|
||||||
|
- Include both technical and process perspectives
|
||||||
|
- Be honest about challenges and failures
|
||||||
|
- Focus on actionable improvements
|
||||||
|
- Link to specific evidence (PRs, commits, journals)
|
||||||
|
|
@ -4,6 +4,8 @@ This task guides the creation of an ADR to document significant architectural de
|
||||||
|
|
||||||
## Initial Setup (if needed)
|
## Initial Setup (if needed)
|
||||||
|
|
||||||
|
[[LLM: The ADR location follows the standard defined in project-scaffolding-preference.md]]
|
||||||
|
|
||||||
If the /docs/adr directory doesn't exist in the project:
|
If the /docs/adr directory doesn't exist in the project:
|
||||||
1. Create the directory: `mkdir -p docs/adr`
|
1. Create the directory: `mkdir -p docs/adr`
|
||||||
2. Create a README.md explaining ADR purpose and structure
|
2. Create a README.md explaining ADR purpose and structure
|
||||||
|
|
|
||||||
|
|
@ -6,6 +6,9 @@ This task guides the creation of a development journal entry to document the ses
|
||||||
- Have git access to review commits and changes
|
- Have git access to review commits and changes
|
||||||
|
|
||||||
## Initial Setup (if needed)
|
## Initial Setup (if needed)
|
||||||
|
|
||||||
|
[[LLM: The Dev Journal location follows the standard defined in project-scaffolding-preference.md]]
|
||||||
|
|
||||||
If the /docs/devJournal directory doesn't exist in the project:
|
If the /docs/devJournal directory doesn't exist in the project:
|
||||||
1. Create the directory: `mkdir -p docs/devJournal`
|
1. Create the directory: `mkdir -p docs/devJournal`
|
||||||
2. Create a README.md in that directory explaining its purpose
|
2. Create a README.md in that directory explaining its purpose
|
||||||
|
|
@ -33,14 +36,16 @@ Check existing entries: `ls docs/devJournal/YYYYMMDD-*.md`
|
||||||
|
|
||||||
Use the dev-journal-tmpl.yaml template to create a comprehensive entry covering:
|
Use the dev-journal-tmpl.yaml template to create a comprehensive entry covering:
|
||||||
|
|
||||||
#### Essential Sections:
|
#### Essential Sections
|
||||||
1. **Session Overview** - Brief summary of accomplishments
|
1. **Session Overview** - Brief summary of accomplishments
|
||||||
2. **Work Streams** - Detailed breakdown of each area of work
|
2. **Work Streams** - Detailed breakdown of each area of work
|
||||||
3. **Implementation Details** - Key code changes and decisions
|
3. **Implementation Details** - Key code changes and decisions
|
||||||
4. **Validation & Testing** - What was tested and verified
|
4. **Validation & Testing** - What was tested and verified
|
||||||
5. **Current State & Next Steps** - Where we are and what's next
|
5. **Current State & Next Steps** - Where we are and what's next
|
||||||
|
|
||||||
#### Evidence Gathering:
|
**Sprint Journal Entries**: For end-of-sprint dev journal entries, cross-reference with `sprint-review-checklist.md` to ensure all sprint accomplishments and learnings are captured.
|
||||||
|
|
||||||
|
#### Evidence Gathering
|
||||||
- Review all commits made during session
|
- Review all commits made during session
|
||||||
- Check modified files by functional area
|
- Check modified files by functional area
|
||||||
- Note any new patterns or architectural decisions
|
- Note any new patterns or architectural decisions
|
||||||
|
|
@ -68,6 +73,7 @@ Before finalizing, ensure:
|
||||||
- Include enough detail for context without overwhelming
|
- Include enough detail for context without overwhelming
|
||||||
- Cross-reference related stories, ADRs, or PRs
|
- Cross-reference related stories, ADRs, or PRs
|
||||||
- Use British English for consistency
|
- Use British English for consistency
|
||||||
|
- For sprint-end entries, ensure alignment with sprint review documentation using `sprint-review-checklist.md`
|
||||||
|
|
||||||
## Memory Bank Integration
|
## Memory Bank Integration
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -4,6 +4,12 @@
|
||||||
|
|
||||||
To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research or finding its own context.
|
To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research or finding its own context.
|
||||||
|
|
||||||
|
## Prerequisites
|
||||||
|
|
||||||
|
Before creating stories, ensure proper session context:
|
||||||
|
- **Session Kickoff**: If this is a new session or after significant time gap (>24 hours), first run the `session-kickoff` task to establish complete project context
|
||||||
|
- **Memory Bank**: Verify Memory Bank files are current for accurate story creation
|
||||||
|
|
||||||
## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
|
## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
|
||||||
|
|
||||||
### 0. Load Core Configuration and Check Workflow
|
### 0. Load Core Configuration and Check Workflow
|
||||||
|
|
|
||||||
|
|
@ -4,6 +4,12 @@
|
||||||
|
|
||||||
Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
|
Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
|
||||||
|
|
||||||
|
## Prerequisites
|
||||||
|
|
||||||
|
Before documenting a project, ensure proper session context:
|
||||||
|
- **Session Kickoff**: If this is a new session or after significant time gap (>24 hours), first run the `session-kickoff` task to establish complete project context
|
||||||
|
- **Memory Bank Review**: Check if Memory Bank exists to understand project history and context
|
||||||
|
|
||||||
## Task Instructions
|
## Task Instructions
|
||||||
|
|
||||||
### 1. Initial Project Analysis
|
### 1. Initial Project Analysis
|
||||||
|
|
@ -111,9 +117,9 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||||
|
|
||||||
### Change Log
|
### Change Log
|
||||||
|
|
||||||
| Date | Version | Description | Author |
|
| Date | Version | Description | Author |
|
||||||
|------|---------|-------------|--------|
|
|--------|---------|-----------------------------|-----------|
|
||||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||||
|
|
||||||
## Quick Reference - Key Files and Entry Points
|
## Quick Reference - Key Files and Entry Points
|
||||||
|
|
||||||
|
|
@ -136,11 +142,11 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||||
|
|
||||||
### Actual Tech Stack (from package.json/requirements.txt)
|
### Actual Tech Stack (from package.json/requirements.txt)
|
||||||
|
|
||||||
| Category | Technology | Version | Notes |
|
| Category | Technology | Version | Notes |
|
||||||
|----------|------------|---------|--------|
|
|-----------|------------|---------|----------------------------|
|
||||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||||
|
|
||||||
etc...
|
etc...
|
||||||
|
|
||||||
|
|
@ -208,10 +214,10 @@ Instead of duplicating, reference actual model files:
|
||||||
|
|
||||||
### External Services
|
### External Services
|
||||||
|
|
||||||
| Service | Purpose | Integration Type | Key Files |
|
| Service | Purpose | Integration Type | Key Files |
|
||||||
|---------|---------|------------------|-----------|
|
|----------|----------|------------------|--------------------------------|
|
||||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||||
|
|
||||||
etc...
|
etc...
|
||||||
|
|
||||||
|
|
@ -335,13 +341,14 @@ Apply the advanced elicitation task after major sections to refine based on user
|
||||||
## Memory Bank Integration
|
## Memory Bank Integration
|
||||||
|
|
||||||
After documenting a project:
|
After documenting a project:
|
||||||
1. Consider initializing Memory Bank if not exists (`initialize-memory-bank` task)
|
1. Ensure proper session context via `session-kickoff` task (references `session-kickoff-checklist.md`)
|
||||||
2. Use the brownfield architecture document to populate:
|
2. Consider initializing Memory Bank if not exists (`initialize-memory-bank` task)
|
||||||
|
3. Use the brownfield architecture document to populate:
|
||||||
- `projectbrief.md` - Extract project goals and constraints
|
- `projectbrief.md` - Extract project goals and constraints
|
||||||
- `systemPatterns.md` - Document architecture and patterns
|
- `systemPatterns.md` - Document architecture and patterns
|
||||||
- `techContext.md` - Capture technology stack and environment
|
- `techContext.md` - Capture technology stack and environment
|
||||||
- `progress.md` - Note current state and technical debt
|
- `progress.md` - Note current state and technical debt
|
||||||
3. This provides AI agents with both detailed architecture docs and quick-reference Memory Bank
|
4. This provides AI agents with both detailed architecture docs and quick-reference Memory Bank
|
||||||
|
|
||||||
## Notes
|
## Notes
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -15,6 +15,8 @@ The Memory Bank serves as persistent memory for AI agents, containing:
|
||||||
|
|
||||||
### 1. Create Directory Structure
|
### 1. Create Directory Structure
|
||||||
|
|
||||||
|
[[LLM: The Memory Bank location follows the standard defined in project-scaffolding-preference.md]]
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
mkdir -p docs/memory-bank
|
mkdir -p docs/memory-bank
|
||||||
```
|
```
|
||||||
|
|
@ -157,11 +159,13 @@ The Memory Bank integrates with:
|
||||||
- [ ] Next steps clearly defined
|
- [ ] Next steps clearly defined
|
||||||
- [ ] Technical decisions documented
|
- [ ] Technical decisions documented
|
||||||
- [ ] Progress accurately reflected
|
- [ ] Progress accurately reflected
|
||||||
|
- [ ] Verified against session-kickoff-checklist.md requirements
|
||||||
|
|
||||||
## Notes
|
## Notes
|
||||||
|
|
||||||
- Memory Bank is the foundation for AI continuity
|
- Memory Bank is the foundation for AI continuity
|
||||||
- Must be updated regularly to maintain value
|
- Must be updated regularly to maintain value
|
||||||
- All agents should read before starting work
|
- All agents should read before starting work (via session-kickoff task)
|
||||||
- Updates should be comprehensive but concise
|
- Updates should be comprehensive but concise
|
||||||
- British English for consistency
|
- British English for consistency
|
||||||
|
- Use session-kickoff-checklist.md to verify proper initialization
|
||||||
|
|
@ -0,0 +1,219 @@
|
||||||
|
# Session Kickoff
|
||||||
|
|
||||||
|
This task ensures AI agents have complete project context and understanding before starting work. It provides systematic session initialization across all agent types.
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
- Establish comprehensive project understanding
|
||||||
|
- Validate documentation consistency
|
||||||
|
- Identify current project state and priorities
|
||||||
|
- Recommend next steps based on evidence
|
||||||
|
- Prevent context gaps that lead to suboptimal decisions
|
||||||
|
|
||||||
|
## Process
|
||||||
|
|
||||||
|
### 1. Memory Bank Review (Primary Context)
|
||||||
|
|
||||||
|
**Priority Order**:
|
||||||
|
1. **Memory Bank Files** (if they exist): `docs/memory-bank/`
|
||||||
|
- `projectbrief.md` - Project foundation and scope
|
||||||
|
- `activeContext.md` - Current work and immediate priorities
|
||||||
|
- `progress.md` - Project state and completed features
|
||||||
|
- `systemPatterns.md` - Architecture and technical decisions
|
||||||
|
- `techContext.md` - Technology stack and constraints
|
||||||
|
- `productContext.md` - Problem space and user needs
|
||||||
|
|
||||||
|
**Analysis Required**:
|
||||||
|
- When were these last updated?
|
||||||
|
- Is information current and accurate?
|
||||||
|
- Any apparent inconsistencies between files?
|
||||||
|
|
||||||
|
### 2. Architecture Documentation Review
|
||||||
|
|
||||||
|
**Primary References** (check which exists):
|
||||||
|
- `/docs/architecture.md` - General backend/system architecture (greenfield)
|
||||||
|
- `/docs/brownfield-architecture.md` - Enhancement architecture for existing systems
|
||||||
|
- `/docs/frontend-architecture.md` - Frontend-specific architecture
|
||||||
|
- `/docs/fullstack-architecture.md` - Complete full-stack architecture
|
||||||
|
|
||||||
|
**Key Elements to Review**:
|
||||||
|
- Core architectural decisions and patterns
|
||||||
|
- System design and component relationships
|
||||||
|
- Technology choices and constraints
|
||||||
|
- Integration points and data flows
|
||||||
|
- API documentation
|
||||||
|
- Database schemas
|
||||||
|
|
||||||
|
### 3. Development History Review
|
||||||
|
|
||||||
|
**Recent Dev Journals**: `docs/devJournal/`
|
||||||
|
- Read last 3-5 entries to understand recent work
|
||||||
|
- Identify patterns in challenges and decisions
|
||||||
|
- Note any unresolved issues or technical debt
|
||||||
|
- Understand development velocity and blockers
|
||||||
|
|
||||||
|
**Current ADRs**: `docs/adr/`
|
||||||
|
- Review recent architectural decisions
|
||||||
|
- Check for pending or superseded decisions
|
||||||
|
- Validate alignment with current architecture
|
||||||
|
- Skip archived ADRs (consolidated in architecture docs)
|
||||||
|
|
||||||
|
### 4. Project Documentation Scan
|
||||||
|
|
||||||
|
**Core Documentation**:
|
||||||
|
- `README.md` - Project overview and setup
|
||||||
|
- `CHANGELOG.md` - Recent changes and releases
|
||||||
|
- Package manifests (`package.json`, `requirements.txt`, etc.)
|
||||||
|
- Configuration files
|
||||||
|
|
||||||
|
**Additional Context**:
|
||||||
|
- Issue trackers or project boards
|
||||||
|
- Recent commits and branches
|
||||||
|
- Test results and coverage reports
|
||||||
|
|
||||||
|
### 5. Current State Assessment
|
||||||
|
|
||||||
|
**Development Environment**:
|
||||||
|
```bash
|
||||||
|
# Check git status
|
||||||
|
git status
|
||||||
|
git log --oneline -10
|
||||||
|
|
||||||
|
# Check current branch and commits
|
||||||
|
git branch -v
|
||||||
|
|
||||||
|
# Review recent changes
|
||||||
|
git diff --name-status HEAD~5
|
||||||
|
```
|
||||||
|
|
||||||
|
**Project Health**:
|
||||||
|
- Are there failing tests or builds?
|
||||||
|
- Any urgent issues or blockers?
|
||||||
|
- Current sprint/iteration status
|
||||||
|
- Outstanding pull requests
|
||||||
|
|
||||||
|
### 6. Consistency Validation
|
||||||
|
|
||||||
|
**Cross-Reference Checks**:
|
||||||
|
- Does Memory Bank align with actual codebase?
|
||||||
|
- Are ADRs reflected in current architecture?
|
||||||
|
- Do dev journals match git history?
|
||||||
|
- Is documentation current with recent changes?
|
||||||
|
|
||||||
|
**Identify Gaps**:
|
||||||
|
- Missing or outdated documentation
|
||||||
|
- Undocumented architectural decisions
|
||||||
|
- Inconsistencies between sources
|
||||||
|
- Knowledge gaps requiring clarification
|
||||||
|
|
||||||
|
### 7. Agent-Specific Context
|
||||||
|
|
||||||
|
**For Architect Agent**:
|
||||||
|
- Focus on architectural decisions and system design
|
||||||
|
- Review technical debt and improvement opportunities
|
||||||
|
- Assess scalability and performance considerations
|
||||||
|
|
||||||
|
**For Developer Agent**:
|
||||||
|
- Focus on current work items and immediate tasks
|
||||||
|
- Review recent implementation patterns
|
||||||
|
- Understand testing and deployment processes
|
||||||
|
|
||||||
|
**For Product Owner Agent**:
|
||||||
|
- Focus on requirements and user stories
|
||||||
|
- Review product roadmap and priorities
|
||||||
|
- Assess feature completion and user feedback
|
||||||
|
|
||||||
|
### 8. Next Steps Recommendation
|
||||||
|
|
||||||
|
**Based on Evidence**:
|
||||||
|
- What are the most urgent priorities?
|
||||||
|
- Are there any blockers or dependencies?
|
||||||
|
- What documentation needs updating?
|
||||||
|
- What architectural decisions are pending?
|
||||||
|
|
||||||
|
**Recommended Actions**:
|
||||||
|
1. **Immediate Tasks** - Ready to start now
|
||||||
|
2. **Dependency Resolution** - What needs clarification
|
||||||
|
3. **Documentation Updates** - What needs to be updated
|
||||||
|
4. **Strategic Items** - Longer-term considerations
|
||||||
|
|
||||||
|
## Quality Checklist
|
||||||
|
|
||||||
|
- [ ] Memory Bank reviewed (or noted if missing)
|
||||||
|
- [ ] Architecture documentation understood
|
||||||
|
- [ ] Recent development history reviewed
|
||||||
|
- [ ] Current project state assessed
|
||||||
|
- [ ] Documentation inconsistencies identified
|
||||||
|
- [ ] Agent-specific context established
|
||||||
|
- [ ] Next steps clearly recommended
|
||||||
|
- [ ] Any urgent issues flagged
|
||||||
|
|
||||||
|
## Output Template
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Session Kickoff Summary
|
||||||
|
|
||||||
|
## Project Understanding
|
||||||
|
- **Project**: [Name and core purpose]
|
||||||
|
- **Current Phase**: [Development stage]
|
||||||
|
- **Last Updated**: [When Memory Bank was last updated]
|
||||||
|
|
||||||
|
## Documentation Health
|
||||||
|
- **Memory Bank**: [Exists/Missing/Outdated]
|
||||||
|
- **Architecture Docs**: [Current/Needs Update]
|
||||||
|
- **Dev Journals**: [Last entry date]
|
||||||
|
- **ADRs**: [Recent decisions noted]
|
||||||
|
|
||||||
|
## Current State
|
||||||
|
- **Active Branch**: [Git branch]
|
||||||
|
- **Recent Work**: [Summary from dev journals]
|
||||||
|
- **Project Health**: [Green/Yellow/Red with reasons]
|
||||||
|
- **Immediate Blockers**: [Any urgent issues]
|
||||||
|
|
||||||
|
## Inconsistencies Found
|
||||||
|
[List any documentation inconsistencies or gaps]
|
||||||
|
|
||||||
|
## Agent-Specific Context
|
||||||
|
[Relevant context for current agent role]
|
||||||
|
|
||||||
|
## Recommended Next Steps
|
||||||
|
1. [Most urgent priority]
|
||||||
|
2. [Secondary priority]
|
||||||
|
3. [Documentation updates needed]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Integration Points
|
||||||
|
|
||||||
|
This task integrates with:
|
||||||
|
- **Memory Bank**: Primary source of project context
|
||||||
|
- **All Agents**: Universal session initialization
|
||||||
|
- **Document Project**: Can trigger if documentation missing
|
||||||
|
- **Update Memory Bank**: Can trigger if information outdated
|
||||||
|
- **Agent Activation**: Called at start of agent sessions
|
||||||
|
|
||||||
|
## Usage Patterns
|
||||||
|
|
||||||
|
**New Agent Session**:
|
||||||
|
1. Agent activates
|
||||||
|
2. Runs `session-kickoff` task
|
||||||
|
3. Reviews output and confirms understanding
|
||||||
|
4. Proceeds with informed context
|
||||||
|
|
||||||
|
**Project Handoff**:
|
||||||
|
1. New team member or AI session
|
||||||
|
2. Runs comprehensive kickoff
|
||||||
|
3. Identifies knowledge gaps
|
||||||
|
4. Updates documentation as needed
|
||||||
|
|
||||||
|
**Quality Gate**:
|
||||||
|
1. Before major feature work
|
||||||
|
2. After significant time gap
|
||||||
|
3. When context seems incomplete
|
||||||
|
4. As part of regular project health checks
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
|
||||||
|
- This task should be lightweight for daily use but comprehensive for major handoffs
|
||||||
|
- Adapt depth based on project complexity and available time
|
||||||
|
- Can be automated as part of agent startup routines
|
||||||
|
- Helps prevent tunnel vision and context loss
|
||||||
|
|
@ -134,6 +134,8 @@ Triggered by:
|
||||||
- Significant project pivot
|
- Significant project pivot
|
||||||
- Before major feature work
|
- Before major feature work
|
||||||
|
|
||||||
|
**Sprint Review Integration**: For sprint-end updates, use the `sprint-review-checklist.md` to ensure all sprint accomplishments, learnings, and technical decisions are captured in the Memory Bank.
|
||||||
|
|
||||||
## Quality Checklist
|
## Quality Checklist
|
||||||
|
|
||||||
- [ ] All recent dev journals reviewed
|
- [ ] All recent dev journals reviewed
|
||||||
|
|
@ -151,8 +153,9 @@ This task integrates with:
|
||||||
- **Dev Journal Creation**: Triggers selective activeContext update
|
- **Dev Journal Creation**: Triggers selective activeContext update
|
||||||
- **ADR Creation**: Triggers systemPatterns update
|
- **ADR Creation**: Triggers systemPatterns update
|
||||||
- **Story Completion**: Triggers progress update
|
- **Story Completion**: Triggers progress update
|
||||||
- **Sprint End**: Triggers comprehensive update
|
- **Sprint End**: Triggers comprehensive update (use `sprint-review-checklist.md`)
|
||||||
- **Architecture Changes**: Triggers multiple file updates
|
- **Architecture Changes**: Triggers multiple file updates
|
||||||
|
- **Sprint Reviews**: Reference `sprint-review-checklist.md` to ensure comprehensive capture of sprint outcomes
|
||||||
|
|
||||||
## Example Update Flow
|
## Example Update Flow
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -102,7 +102,7 @@ sections:
|
||||||
- Example: {{this.example}}
|
- Example: {{this.example}}
|
||||||
{{/if}}
|
{{/if}}
|
||||||
- When to use: {{this.usage_guidance}}
|
- When to use: {{this.usage_guidance}}
|
||||||
|
|
||||||
{{/each}}
|
{{/each}}
|
||||||
|
|
||||||
### Team Preferences
|
### Team Preferences
|
||||||
|
|
@ -263,4 +263,4 @@ prompts:
|
||||||
gotchas: "Things to remember/watch out for"
|
gotchas: "Things to remember/watch out for"
|
||||||
dependencies_check: "What to verify first"
|
dependencies_check: "What to verify first"
|
||||||
recent_messages: "Important recent communications"
|
recent_messages: "Important recent communications"
|
||||||
pending_communications: "Who needs to be informed about what"
|
pending_communications: "Who needs to be informed about what"
|
||||||
|
|
|
||||||
|
|
@ -24,11 +24,11 @@ sections:
|
||||||
# {{adr_number}}. {{adr_title}}
|
# {{adr_number}}. {{adr_title}}
|
||||||
|
|
||||||
**Date**: {{decision_date}}
|
**Date**: {{decision_date}}
|
||||||
|
|
||||||
**Status**: {{status}}
|
**Status**: {{status}}
|
||||||
|
|
||||||
**Deciders**: {{deciders}}
|
**Deciders**: {{deciders}}
|
||||||
|
|
||||||
**Technical Story**: {{technical_story}}
|
**Technical Story**: {{technical_story}}
|
||||||
|
|
||||||
- id: context
|
- id: context
|
||||||
|
|
@ -60,23 +60,23 @@ sections:
|
||||||
|
|
||||||
{{#each alternatives}}
|
{{#each alternatives}}
|
||||||
### {{this.name}}
|
### {{this.name}}
|
||||||
|
|
||||||
**Description**: {{this.description}}
|
**Description**: {{this.description}}
|
||||||
|
|
||||||
**Pros**:
|
**Pros**:
|
||||||
{{#each this.pros}}
|
{{#each this.pros}}
|
||||||
- {{this}}
|
- {{this}}
|
||||||
{{/each}}
|
{{/each}}
|
||||||
|
|
||||||
**Cons**:
|
**Cons**:
|
||||||
{{#each this.cons}}
|
{{#each this.cons}}
|
||||||
- {{this}}
|
- {{this}}
|
||||||
{{/each}}
|
{{/each}}
|
||||||
|
|
||||||
{{#if this.cost}}
|
{{#if this.cost}}
|
||||||
**Cost**: {{this.cost}}
|
**Cost**: {{this.cost}}
|
||||||
{{/if}}
|
{{/if}}
|
||||||
|
|
||||||
{{#if this.complexity}}
|
{{#if this.complexity}}
|
||||||
**Complexity**: {{this.complexity}}
|
**Complexity**: {{this.complexity}}
|
||||||
{{/if}}
|
{{/if}}
|
||||||
|
|
@ -242,4 +242,4 @@ prompts:
|
||||||
related_adrs: "Links to related ADRs"
|
related_adrs: "Links to related ADRs"
|
||||||
references: "Links to supporting documentation"
|
references: "Links to supporting documentation"
|
||||||
superseded_by: "If superseded, link to newer ADR"
|
superseded_by: "If superseded, link to newer ADR"
|
||||||
supersedes: "If this supersedes others, list them"
|
supersedes: "If this supersedes others, list them"
|
||||||
|
|
|
||||||
|
|
@ -20,20 +20,22 @@ sections:
|
||||||
- id: intro-content
|
- id: intro-content
|
||||||
content: |
|
content: |
|
||||||
This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies.
|
This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies.
|
||||||
|
|
||||||
**Relationship to Frontend Architecture:**
|
**Relationship to Frontend Architecture:**
|
||||||
If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components.
|
If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components.
|
||||||
- id: starter-template
|
- id: starter-template
|
||||||
title: Starter Template or Existing Project
|
title: Starter Template or Existing Project
|
||||||
instruction: |
|
instruction: |
|
||||||
Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase:
|
Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase:
|
||||||
|
|
||||||
1. Review the PRD and brainstorming brief for any mentions of:
|
1. Review the PRD and brainstorming brief for any mentions of:
|
||||||
- Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.)
|
- Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.)
|
||||||
- Existing projects or codebases being used as a foundation
|
- Existing projects or codebases being used as a foundation
|
||||||
- Boilerplate projects or scaffolding tools
|
- Boilerplate projects or scaffolding tools
|
||||||
- Previous projects to be cloned or adapted
|
- Previous projects to be cloned or adapted
|
||||||
|
|
||||||
|
NOTE: Reference project-scaffolding-preference.md for standard project structure guidelines regardless of starter template choice.
|
||||||
|
|
||||||
2. If a starter template or existing project is mentioned:
|
2. If a starter template or existing project is mentioned:
|
||||||
- Ask the user to provide access via one of these methods:
|
- Ask the user to provide access via one of these methods:
|
||||||
- Link to the starter template documentation
|
- Link to the starter template documentation
|
||||||
|
|
@ -46,16 +48,16 @@ sections:
|
||||||
- Existing architectural patterns and conventions
|
- Existing architectural patterns and conventions
|
||||||
- Any limitations or constraints imposed by the starter
|
- Any limitations or constraints imposed by the starter
|
||||||
- Use this analysis to inform and align your architecture decisions
|
- Use this analysis to inform and align your architecture decisions
|
||||||
|
|
||||||
3. If no starter template is mentioned but this is a greenfield project:
|
3. If no starter template is mentioned but this is a greenfield project:
|
||||||
- Suggest appropriate starter templates based on the tech stack preferences
|
- Suggest appropriate starter templates based on the tech stack preferences
|
||||||
- Explain the benefits (faster setup, best practices, community support)
|
- Explain the benefits (faster setup, best practices, community support)
|
||||||
- Let the user decide whether to use one
|
- Let the user decide whether to use one
|
||||||
|
|
||||||
4. If the user confirms no starter template will be used:
|
4. If the user confirms no starter template will be used:
|
||||||
- Proceed with architecture design from scratch
|
- Proceed with architecture design from scratch
|
||||||
- Note that manual setup will be required for all tooling and configuration
|
- Note that manual setup will be required for all tooling and configuration
|
||||||
|
|
||||||
Document the decision here before proceeding with the architecture design. If none, just say N/A
|
Document the decision here before proceeding with the architecture design. If none, just say N/A
|
||||||
elicit: true
|
elicit: true
|
||||||
- id: changelog
|
- id: changelog
|
||||||
|
|
@ -83,7 +85,7 @@ sections:
|
||||||
title: High Level Overview
|
title: High Level Overview
|
||||||
instruction: |
|
instruction: |
|
||||||
Based on the PRD's Technical Assumptions section, describe:
|
Based on the PRD's Technical Assumptions section, describe:
|
||||||
|
|
||||||
1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven)
|
1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven)
|
||||||
2. Repository structure decision from PRD (Monorepo/Polyrepo)
|
2. Repository structure decision from PRD (Monorepo/Polyrepo)
|
||||||
3. Service architecture decision from PRD
|
3. Service architecture decision from PRD
|
||||||
|
|
@ -100,17 +102,17 @@ sections:
|
||||||
- Data flow directions
|
- Data flow directions
|
||||||
- External integrations
|
- External integrations
|
||||||
- User entry points
|
- User entry points
|
||||||
|
|
||||||
- id: architectural-patterns
|
- id: architectural-patterns
|
||||||
title: Architectural and Design Patterns
|
title: Architectural and Design Patterns
|
||||||
instruction: |
|
instruction: |
|
||||||
List the key high-level patterns that will guide the architecture. For each pattern:
|
List the key high-level patterns that will guide the architecture. For each pattern:
|
||||||
|
|
||||||
1. Present 2-3 viable options if multiple exist
|
1. Present 2-3 viable options if multiple exist
|
||||||
2. Provide your recommendation with clear rationale
|
2. Provide your recommendation with clear rationale
|
||||||
3. Get user confirmation before finalizing
|
3. Get user confirmation before finalizing
|
||||||
4. These patterns should align with the PRD's technical assumptions and project goals
|
4. These patterns should align with the PRD's technical assumptions and project goals
|
||||||
|
|
||||||
Common patterns to consider:
|
Common patterns to consider:
|
||||||
- Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal)
|
- Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal)
|
||||||
- Code organization patterns (Dependency Injection, Repository, Module, Factory)
|
- Code organization patterns (Dependency Injection, Repository, Module, Factory)
|
||||||
|
|
@ -126,23 +128,23 @@ sections:
|
||||||
title: Tech Stack
|
title: Tech Stack
|
||||||
instruction: |
|
instruction: |
|
||||||
This is the DEFINITIVE technology selection section. Work with the user to make specific choices:
|
This is the DEFINITIVE technology selection section. Work with the user to make specific choices:
|
||||||
|
|
||||||
1. Review PRD technical assumptions and any preferences from {root}/data/technical-preferences.yaml or an attached technical-preferences
|
1. Review PRD technical assumptions and any preferences from {root}/data/technical-preferences.yaml or an attached technical-preferences
|
||||||
2. For each category, present 2-3 viable options with pros/cons
|
2. For each category, present 2-3 viable options with pros/cons
|
||||||
3. Make a clear recommendation based on project needs
|
3. Make a clear recommendation based on project needs
|
||||||
4. Get explicit user approval for each selection
|
4. Get explicit user approval for each selection
|
||||||
5. Document exact versions (avoid "latest" - pin specific versions)
|
5. Document exact versions (avoid "latest" - pin specific versions)
|
||||||
6. This table is the single source of truth - all other docs must reference these choices
|
6. This table is the single source of truth - all other docs must reference these choices
|
||||||
|
|
||||||
Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale:
|
Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale:
|
||||||
|
|
||||||
- Starter templates (if any)
|
- Starter templates (if any)
|
||||||
- Languages and runtimes with exact versions
|
- Languages and runtimes with exact versions
|
||||||
- Frameworks and libraries / packages
|
- Frameworks and libraries / packages
|
||||||
- Cloud provider and key services choices
|
- Cloud provider and key services choices
|
||||||
- Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion
|
- Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion
|
||||||
- Development tools
|
- Development tools
|
||||||
|
|
||||||
Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input.
|
Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input.
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -166,13 +168,13 @@ sections:
|
||||||
title: Data Models
|
title: Data Models
|
||||||
instruction: |
|
instruction: |
|
||||||
Define the core data models/entities:
|
Define the core data models/entities:
|
||||||
|
|
||||||
1. Review PRD requirements and identify key business entities
|
1. Review PRD requirements and identify key business entities
|
||||||
2. For each model, explain its purpose and relationships
|
2. For each model, explain its purpose and relationships
|
||||||
3. Include key attributes and data types
|
3. Include key attributes and data types
|
||||||
4. Show relationships between models
|
4. Show relationships between models
|
||||||
5. Discuss design decisions with user
|
5. Discuss design decisions with user
|
||||||
|
|
||||||
Create a clear conceptual model before moving to database schema.
|
Create a clear conceptual model before moving to database schema.
|
||||||
elicit: true
|
elicit: true
|
||||||
repeatable: true
|
repeatable: true
|
||||||
|
|
@ -181,11 +183,11 @@ sections:
|
||||||
title: "{{model_name}}"
|
title: "{{model_name}}"
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** {{model_purpose}}
|
**Purpose:** {{model_purpose}}
|
||||||
|
|
||||||
**Key Attributes:**
|
**Key Attributes:**
|
||||||
- {{attribute_1}}: {{type_1}} - {{description_1}}
|
- {{attribute_1}}: {{type_1}} - {{description_1}}
|
||||||
- {{attribute_2}}: {{type_2}} - {{description_2}}
|
- {{attribute_2}}: {{type_2}} - {{description_2}}
|
||||||
|
|
||||||
**Relationships:**
|
**Relationships:**
|
||||||
- {{relationship_1}}
|
- {{relationship_1}}
|
||||||
- {{relationship_2}}
|
- {{relationship_2}}
|
||||||
|
|
@ -194,7 +196,7 @@ sections:
|
||||||
title: Components
|
title: Components
|
||||||
instruction: |
|
instruction: |
|
||||||
Based on the architectural patterns, tech stack, and data models from above:
|
Based on the architectural patterns, tech stack, and data models from above:
|
||||||
|
|
||||||
1. Identify major logical components/services and their responsibilities
|
1. Identify major logical components/services and their responsibilities
|
||||||
2. Consider the repository structure (monorepo/polyrepo) from PRD
|
2. Consider the repository structure (monorepo/polyrepo) from PRD
|
||||||
3. Define clear boundaries and interfaces between components
|
3. Define clear boundaries and interfaces between components
|
||||||
|
|
@ -203,7 +205,7 @@ sections:
|
||||||
- Key interfaces/APIs exposed
|
- Key interfaces/APIs exposed
|
||||||
- Dependencies on other components
|
- Dependencies on other components
|
||||||
- Technology specifics based on tech stack choices
|
- Technology specifics based on tech stack choices
|
||||||
|
|
||||||
5. Create component diagrams where helpful
|
5. Create component diagrams where helpful
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -212,13 +214,13 @@ sections:
|
||||||
title: "{{component_name}}"
|
title: "{{component_name}}"
|
||||||
template: |
|
template: |
|
||||||
**Responsibility:** {{component_description}}
|
**Responsibility:** {{component_description}}
|
||||||
|
|
||||||
**Key Interfaces:**
|
**Key Interfaces:**
|
||||||
- {{interface_1}}
|
- {{interface_1}}
|
||||||
- {{interface_2}}
|
- {{interface_2}}
|
||||||
|
|
||||||
**Dependencies:** {{dependencies}}
|
**Dependencies:** {{dependencies}}
|
||||||
|
|
||||||
**Technology Stack:** {{component_tech_details}}
|
**Technology Stack:** {{component_tech_details}}
|
||||||
- id: component-diagrams
|
- id: component-diagrams
|
||||||
title: Component Diagrams
|
title: Component Diagrams
|
||||||
|
|
@ -235,13 +237,13 @@ sections:
|
||||||
condition: Project requires external API integrations
|
condition: Project requires external API integrations
|
||||||
instruction: |
|
instruction: |
|
||||||
For each external service integration:
|
For each external service integration:
|
||||||
|
|
||||||
1. Identify APIs needed based on PRD requirements and component design
|
1. Identify APIs needed based on PRD requirements and component design
|
||||||
2. If documentation URLs are unknown, ask user for specifics
|
2. If documentation URLs are unknown, ask user for specifics
|
||||||
3. Document authentication methods and security considerations
|
3. Document authentication methods and security considerations
|
||||||
4. List specific endpoints that will be used
|
4. List specific endpoints that will be used
|
||||||
5. Note any rate limits or usage constraints
|
5. Note any rate limits or usage constraints
|
||||||
|
|
||||||
If no external APIs are needed, state this explicitly and skip to next section.
|
If no external APIs are needed, state this explicitly and skip to next section.
|
||||||
elicit: true
|
elicit: true
|
||||||
repeatable: true
|
repeatable: true
|
||||||
|
|
@ -254,10 +256,10 @@ sections:
|
||||||
- **Base URL(s):** {{api_base_url}}
|
- **Base URL(s):** {{api_base_url}}
|
||||||
- **Authentication:** {{auth_method}}
|
- **Authentication:** {{auth_method}}
|
||||||
- **Rate Limits:** {{rate_limits}}
|
- **Rate Limits:** {{rate_limits}}
|
||||||
|
|
||||||
**Key Endpoints Used:**
|
**Key Endpoints Used:**
|
||||||
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
|
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
|
||||||
|
|
||||||
**Integration Notes:** {{integration_considerations}}
|
**Integration Notes:** {{integration_considerations}}
|
||||||
|
|
||||||
- id: core-workflows
|
- id: core-workflows
|
||||||
|
|
@ -266,13 +268,13 @@ sections:
|
||||||
mermaid_type: sequence
|
mermaid_type: sequence
|
||||||
instruction: |
|
instruction: |
|
||||||
Illustrate key system workflows using sequence diagrams:
|
Illustrate key system workflows using sequence diagrams:
|
||||||
|
|
||||||
1. Identify critical user journeys from PRD
|
1. Identify critical user journeys from PRD
|
||||||
2. Show component interactions including external APIs
|
2. Show component interactions including external APIs
|
||||||
3. Include error handling paths
|
3. Include error handling paths
|
||||||
4. Document async operations
|
4. Document async operations
|
||||||
5. Create both high-level and detailed diagrams as needed
|
5. Create both high-level and detailed diagrams as needed
|
||||||
|
|
||||||
Focus on workflows that clarify architecture decisions or complex interactions.
|
Focus on workflows that clarify architecture decisions or complex interactions.
|
||||||
elicit: true
|
elicit: true
|
||||||
|
|
||||||
|
|
@ -283,13 +285,13 @@ sections:
|
||||||
language: yaml
|
language: yaml
|
||||||
instruction: |
|
instruction: |
|
||||||
If the project includes a REST API:
|
If the project includes a REST API:
|
||||||
|
|
||||||
1. Create an OpenAPI 3.0 specification
|
1. Create an OpenAPI 3.0 specification
|
||||||
2. Include all endpoints from epics/stories
|
2. Include all endpoints from epics/stories
|
||||||
3. Define request/response schemas based on data models
|
3. Define request/response schemas based on data models
|
||||||
4. Document authentication requirements
|
4. Document authentication requirements
|
||||||
5. Include example requests/responses
|
5. Include example requests/responses
|
||||||
|
|
||||||
Use YAML format for better readability. If no REST API, skip this section.
|
Use YAML format for better readability. If no REST API, skip this section.
|
||||||
elicit: true
|
elicit: true
|
||||||
template: |
|
template: |
|
||||||
|
|
@ -306,13 +308,13 @@ sections:
|
||||||
title: Database Schema
|
title: Database Schema
|
||||||
instruction: |
|
instruction: |
|
||||||
Transform the conceptual data models into concrete database schemas:
|
Transform the conceptual data models into concrete database schemas:
|
||||||
|
|
||||||
1. Use the database type(s) selected in Tech Stack
|
1. Use the database type(s) selected in Tech Stack
|
||||||
2. Create schema definitions using appropriate notation
|
2. Create schema definitions using appropriate notation
|
||||||
3. Include indexes, constraints, and relationships
|
3. Include indexes, constraints, and relationships
|
||||||
4. Consider performance and scalability
|
4. Consider performance and scalability
|
||||||
5. For NoSQL, show document structures
|
5. For NoSQL, show document structures
|
||||||
|
|
||||||
Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
|
Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
|
||||||
elicit: true
|
elicit: true
|
||||||
|
|
||||||
|
|
@ -322,14 +324,14 @@ sections:
|
||||||
language: plaintext
|
language: plaintext
|
||||||
instruction: |
|
instruction: |
|
||||||
Create a project folder structure that reflects:
|
Create a project folder structure that reflects:
|
||||||
|
|
||||||
1. The chosen repository structure (monorepo/polyrepo)
|
1. The chosen repository structure (monorepo/polyrepo)
|
||||||
2. The service architecture (monolith/microservices/serverless)
|
2. The service architecture (monolith/microservices/serverless)
|
||||||
3. The selected tech stack and languages
|
3. The selected tech stack and languages
|
||||||
4. Component organization from above
|
4. Component organization from above
|
||||||
5. Best practices for the chosen frameworks
|
5. Best practices for the chosen frameworks
|
||||||
6. Clear separation of concerns
|
6. Clear separation of concerns
|
||||||
|
|
||||||
Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions.
|
Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions.
|
||||||
elicit: true
|
elicit: true
|
||||||
examples:
|
examples:
|
||||||
|
|
@ -347,13 +349,13 @@ sections:
|
||||||
title: Infrastructure and Deployment
|
title: Infrastructure and Deployment
|
||||||
instruction: |
|
instruction: |
|
||||||
Define the deployment architecture and practices:
|
Define the deployment architecture and practices:
|
||||||
|
|
||||||
1. Use IaC tool selected in Tech Stack
|
1. Use IaC tool selected in Tech Stack
|
||||||
2. Choose deployment strategy appropriate for the architecture
|
2. Choose deployment strategy appropriate for the architecture
|
||||||
3. Define environments and promotion flow
|
3. Define environments and promotion flow
|
||||||
4. Establish rollback procedures
|
4. Establish rollback procedures
|
||||||
5. Consider security, monitoring, and cost optimization
|
5. Consider security, monitoring, and cost optimization
|
||||||
|
|
||||||
Get user input on deployment preferences and CI/CD tool choices.
|
Get user input on deployment preferences and CI/CD tool choices.
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -389,13 +391,13 @@ sections:
|
||||||
title: Error Handling Strategy
|
title: Error Handling Strategy
|
||||||
instruction: |
|
instruction: |
|
||||||
Define comprehensive error handling approach:
|
Define comprehensive error handling approach:
|
||||||
|
|
||||||
1. Choose appropriate patterns for the language/framework from Tech Stack
|
1. Choose appropriate patterns for the language/framework from Tech Stack
|
||||||
2. Define logging standards and tools
|
2. Define logging standards and tools
|
||||||
3. Establish error categories and handling rules
|
3. Establish error categories and handling rules
|
||||||
4. Consider observability and debugging needs
|
4. Consider observability and debugging needs
|
||||||
5. Ensure security (no sensitive data in logs)
|
5. Ensure security (no sensitive data in logs)
|
||||||
|
|
||||||
This section guides both AI and human developers in consistent error handling.
|
This section guides both AI and human developers in consistent error handling.
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -442,13 +444,13 @@ sections:
|
||||||
title: Coding Standards
|
title: Coding Standards
|
||||||
instruction: |
|
instruction: |
|
||||||
These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that:
|
These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that:
|
||||||
|
|
||||||
1. This section directly controls AI developer behavior
|
1. This section directly controls AI developer behavior
|
||||||
2. Keep it minimal - assume AI knows general best practices
|
2. Keep it minimal - assume AI knows general best practices
|
||||||
3. Focus on project-specific conventions and gotchas
|
3. Focus on project-specific conventions and gotchas
|
||||||
4. Overly detailed standards bloat context and slow development
|
4. Overly detailed standards bloat context and slow development
|
||||||
5. Standards will be extracted to separate file for dev agent use
|
5. Standards will be extracted to separate file for dev agent use
|
||||||
|
|
||||||
For each standard, get explicit user confirmation it's necessary.
|
For each standard, get explicit user confirmation it's necessary.
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -470,7 +472,7 @@ sections:
|
||||||
- "Never use console.log in production code - use logger"
|
- "Never use console.log in production code - use logger"
|
||||||
- "All API responses must use ApiResponse wrapper type"
|
- "All API responses must use ApiResponse wrapper type"
|
||||||
- "Database queries must use repository pattern, never direct ORM"
|
- "Database queries must use repository pattern, never direct ORM"
|
||||||
|
|
||||||
Avoid obvious rules like "use SOLID principles" or "write clean code"
|
Avoid obvious rules like "use SOLID principles" or "write clean code"
|
||||||
repeatable: true
|
repeatable: true
|
||||||
template: "- **{{rule_name}}:** {{rule_description}}"
|
template: "- **{{rule_name}}:** {{rule_description}}"
|
||||||
|
|
@ -488,14 +490,14 @@ sections:
|
||||||
title: Test Strategy and Standards
|
title: Test Strategy and Standards
|
||||||
instruction: |
|
instruction: |
|
||||||
Work with user to define comprehensive test strategy:
|
Work with user to define comprehensive test strategy:
|
||||||
|
|
||||||
1. Use test frameworks from Tech Stack
|
1. Use test frameworks from Tech Stack
|
||||||
2. Decide on TDD vs test-after approach
|
2. Decide on TDD vs test-after approach
|
||||||
3. Define test organization and naming
|
3. Define test organization and naming
|
||||||
4. Establish coverage goals
|
4. Establish coverage goals
|
||||||
5. Determine integration test infrastructure
|
5. Determine integration test infrastructure
|
||||||
6. Plan for test data and external dependencies
|
6. Plan for test data and external dependencies
|
||||||
|
|
||||||
Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference.
|
Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference.
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -516,7 +518,7 @@ sections:
|
||||||
- **Location:** {{unit_test_location}}
|
- **Location:** {{unit_test_location}}
|
||||||
- **Mocking Library:** {{mocking_library}}
|
- **Mocking Library:** {{mocking_library}}
|
||||||
- **Coverage Requirement:** {{unit_coverage}}
|
- **Coverage Requirement:** {{unit_coverage}}
|
||||||
|
|
||||||
**AI Agent Requirements:**
|
**AI Agent Requirements:**
|
||||||
- Generate tests for all public methods
|
- Generate tests for all public methods
|
||||||
- Cover edge cases and error conditions
|
- Cover edge cases and error conditions
|
||||||
|
|
@ -558,7 +560,7 @@ sections:
|
||||||
title: Security
|
title: Security
|
||||||
instruction: |
|
instruction: |
|
||||||
Define MANDATORY security requirements for AI and human developers:
|
Define MANDATORY security requirements for AI and human developers:
|
||||||
|
|
||||||
1. Focus on implementation-specific rules
|
1. Focus on implementation-specific rules
|
||||||
2. Reference security tools from Tech Stack
|
2. Reference security tools from Tech Stack
|
||||||
3. Define clear patterns for common scenarios
|
3. Define clear patterns for common scenarios
|
||||||
|
|
@ -627,16 +629,16 @@ sections:
|
||||||
title: Next Steps
|
title: Next Steps
|
||||||
instruction: |
|
instruction: |
|
||||||
After completing the architecture:
|
After completing the architecture:
|
||||||
|
|
||||||
1. If project has UI components:
|
1. If project has UI components:
|
||||||
- Use "Frontend Architecture Mode"
|
- Use "Frontend Architecture Mode"
|
||||||
- Provide this document as input
|
- Provide this document as input
|
||||||
|
|
||||||
2. For all projects:
|
2. For all projects:
|
||||||
- Review with Product Owner
|
- Review with Product Owner
|
||||||
- Begin story implementation with Dev agent
|
- Begin story implementation with Dev agent
|
||||||
- Set up infrastructure with DevOps agent
|
- Set up infrastructure with DevOps agent
|
||||||
|
|
||||||
3. Include specific prompts for next agents if needed
|
3. Include specific prompts for next agents if needed
|
||||||
sections:
|
sections:
|
||||||
- id: architect-prompt
|
- id: architect-prompt
|
||||||
|
|
|
||||||
|
|
@ -23,11 +23,11 @@ sections:
|
||||||
- id: summary-details
|
- id: summary-details
|
||||||
template: |
|
template: |
|
||||||
**Topic:** {{session_topic}}
|
**Topic:** {{session_topic}}
|
||||||
|
|
||||||
**Session Goals:** {{stated_goals}}
|
**Session Goals:** {{stated_goals}}
|
||||||
|
|
||||||
**Techniques Used:** {{techniques_list}}
|
**Techniques Used:** {{techniques_list}}
|
||||||
|
|
||||||
**Total Ideas Generated:** {{total_ideas}}
|
**Total Ideas Generated:** {{total_ideas}}
|
||||||
- id: key-themes
|
- id: key-themes
|
||||||
title: "Key Themes Identified:"
|
title: "Key Themes Identified:"
|
||||||
|
|
@ -152,5 +152,5 @@ sections:
|
||||||
- id: footer
|
- id: footer
|
||||||
content: |
|
content: |
|
||||||
---
|
---
|
||||||
|
|
||||||
*Session facilitated using the BMAD-METHOD brainstorming framework*
|
*Session facilitated using the BMAD-METHOD brainstorming framework*
|
||||||
|
|
|
||||||
|
|
@ -16,40 +16,40 @@ sections:
|
||||||
title: Introduction
|
title: Introduction
|
||||||
instruction: |
|
instruction: |
|
||||||
IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
|
IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
|
||||||
|
|
||||||
This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
|
This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
|
||||||
|
|
||||||
1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
|
1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
|
||||||
|
|
||||||
2. **REQUIRED INPUTS**:
|
2. **REQUIRED INPUTS**:
|
||||||
- Completed brownfield-prd.md
|
- Completed brownfield-prd.md
|
||||||
- Existing project technical documentation (from docs folder or user-provided)
|
- Existing project technical documentation (from docs folder or user-provided)
|
||||||
- Access to existing project structure (IDE or uploaded files)
|
- Access to existing project structure (IDE or uploaded files)
|
||||||
|
|
||||||
3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
|
3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
|
||||||
|
|
||||||
4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
|
4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
|
||||||
|
|
||||||
If any required inputs are missing, request them before proceeding.
|
If any required inputs are missing, request them before proceeding.
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
- id: intro-content
|
- id: intro-content
|
||||||
content: |
|
content: |
|
||||||
This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
|
This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
|
||||||
|
|
||||||
**Relationship to Existing Architecture:**
|
**Relationship to Existing Architecture:**
|
||||||
This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements.
|
This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements.
|
||||||
- id: existing-project-analysis
|
- id: existing-project-analysis
|
||||||
title: Existing Project Analysis
|
title: Existing Project Analysis
|
||||||
instruction: |
|
instruction: |
|
||||||
Analyze the existing project structure and architecture:
|
Analyze the existing project structure and architecture:
|
||||||
|
|
||||||
1. Review existing documentation in docs folder
|
1. Review existing documentation in docs folder
|
||||||
2. Examine current technology stack and versions
|
2. Examine current technology stack and versions
|
||||||
3. Identify existing architectural patterns and conventions
|
3. Identify existing architectural patterns and conventions
|
||||||
4. Note current deployment and infrastructure setup
|
4. Note current deployment and infrastructure setup
|
||||||
5. Document any constraints or limitations
|
5. Document any constraints or limitations
|
||||||
|
|
||||||
CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
|
CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -78,12 +78,12 @@ sections:
|
||||||
title: Enhancement Scope and Integration Strategy
|
title: Enhancement Scope and Integration Strategy
|
||||||
instruction: |
|
instruction: |
|
||||||
Define how the enhancement will integrate with the existing system:
|
Define how the enhancement will integrate with the existing system:
|
||||||
|
|
||||||
1. Review the brownfield PRD enhancement scope
|
1. Review the brownfield PRD enhancement scope
|
||||||
2. Identify integration points with existing code
|
2. Identify integration points with existing code
|
||||||
3. Define boundaries between new and existing functionality
|
3. Define boundaries between new and existing functionality
|
||||||
4. Establish compatibility requirements
|
4. Establish compatibility requirements
|
||||||
|
|
||||||
VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
|
VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -112,7 +112,7 @@ sections:
|
||||||
title: Tech Stack Alignment
|
title: Tech Stack Alignment
|
||||||
instruction: |
|
instruction: |
|
||||||
Ensure new components align with existing technology choices:
|
Ensure new components align with existing technology choices:
|
||||||
|
|
||||||
1. Use existing technology stack as the foundation
|
1. Use existing technology stack as the foundation
|
||||||
2. Only introduce new technologies if absolutely necessary
|
2. Only introduce new technologies if absolutely necessary
|
||||||
3. Justify any new additions with clear rationale
|
3. Justify any new additions with clear rationale
|
||||||
|
|
@ -135,7 +135,7 @@ sections:
|
||||||
title: Data Models and Schema Changes
|
title: Data Models and Schema Changes
|
||||||
instruction: |
|
instruction: |
|
||||||
Define new data models and how they integrate with existing schema:
|
Define new data models and how they integrate with existing schema:
|
||||||
|
|
||||||
1. Identify new entities required for the enhancement
|
1. Identify new entities required for the enhancement
|
||||||
2. Define relationships with existing data models
|
2. Define relationships with existing data models
|
||||||
3. Plan database schema changes (additions, modifications)
|
3. Plan database schema changes (additions, modifications)
|
||||||
|
|
@ -151,11 +151,11 @@ sections:
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** {{model_purpose}}
|
**Purpose:** {{model_purpose}}
|
||||||
**Integration:** {{integration_with_existing}}
|
**Integration:** {{integration_with_existing}}
|
||||||
|
|
||||||
**Key Attributes:**
|
**Key Attributes:**
|
||||||
- {{attribute_1}}: {{type_1}} - {{description_1}}
|
- {{attribute_1}}: {{type_1}} - {{description_1}}
|
||||||
- {{attribute_2}}: {{type_2}} - {{description_2}}
|
- {{attribute_2}}: {{type_2}} - {{description_2}}
|
||||||
|
|
||||||
**Relationships:**
|
**Relationships:**
|
||||||
- **With Existing:** {{existing_relationships}}
|
- **With Existing:** {{existing_relationships}}
|
||||||
- **With New:** {{new_relationships}}
|
- **With New:** {{new_relationships}}
|
||||||
|
|
@ -167,7 +167,7 @@ sections:
|
||||||
- **Modified Tables:** {{modified_tables_list}}
|
- **Modified Tables:** {{modified_tables_list}}
|
||||||
- **New Indexes:** {{new_indexes_list}}
|
- **New Indexes:** {{new_indexes_list}}
|
||||||
- **Migration Strategy:** {{migration_approach}}
|
- **Migration Strategy:** {{migration_approach}}
|
||||||
|
|
||||||
**Backward Compatibility:**
|
**Backward Compatibility:**
|
||||||
- {{compatibility_measure_1}}
|
- {{compatibility_measure_1}}
|
||||||
- {{compatibility_measure_2}}
|
- {{compatibility_measure_2}}
|
||||||
|
|
@ -176,12 +176,12 @@ sections:
|
||||||
title: Component Architecture
|
title: Component Architecture
|
||||||
instruction: |
|
instruction: |
|
||||||
Define new components and their integration with existing architecture:
|
Define new components and their integration with existing architecture:
|
||||||
|
|
||||||
1. Identify new components required for the enhancement
|
1. Identify new components required for the enhancement
|
||||||
2. Define interfaces with existing components
|
2. Define interfaces with existing components
|
||||||
3. Establish clear boundaries and responsibilities
|
3. Establish clear boundaries and responsibilities
|
||||||
4. Plan integration points and data flow
|
4. Plan integration points and data flow
|
||||||
|
|
||||||
MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?"
|
MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?"
|
||||||
elicit: true
|
elicit: true
|
||||||
sections:
|
sections:
|
||||||
|
|
@ -194,15 +194,15 @@ sections:
|
||||||
template: |
|
template: |
|
||||||
**Responsibility:** {{component_description}}
|
**Responsibility:** {{component_description}}
|
||||||
**Integration Points:** {{integration_points}}
|
**Integration Points:** {{integration_points}}
|
||||||
|
|
||||||
**Key Interfaces:**
|
**Key Interfaces:**
|
||||||
- {{interface_1}}
|
- {{interface_1}}
|
||||||
- {{interface_2}}
|
- {{interface_2}}
|
||||||
|
|
||||||
**Dependencies:**
|
**Dependencies:**
|
||||||
- **Existing Components:** {{existing_dependencies}}
|
- **Existing Components:** {{existing_dependencies}}
|
||||||
- **New Components:** {{new_dependencies}}
|
- **New Components:** {{new_dependencies}}
|
||||||
|
|
||||||
**Technology Stack:** {{component_tech_details}}
|
**Technology Stack:** {{component_tech_details}}
|
||||||
- id: interaction-diagram
|
- id: interaction-diagram
|
||||||
title: Component Interaction Diagram
|
title: Component Interaction Diagram
|
||||||
|
|
@ -215,7 +215,7 @@ sections:
|
||||||
condition: Enhancement requires API changes
|
condition: Enhancement requires API changes
|
||||||
instruction: |
|
instruction: |
|
||||||
Define new API endpoints and integration with existing APIs:
|
Define new API endpoints and integration with existing APIs:
|
||||||
|
|
||||||
1. Plan new API endpoints required for the enhancement
|
1. Plan new API endpoints required for the enhancement
|
||||||
2. Ensure consistency with existing API patterns
|
2. Ensure consistency with existing API patterns
|
||||||
3. Define authentication and authorization integration
|
3. Define authentication and authorization integration
|
||||||
|
|
@ -265,17 +265,17 @@ sections:
|
||||||
- **Base URL:** {{api_base_url}}
|
- **Base URL:** {{api_base_url}}
|
||||||
- **Authentication:** {{auth_method}}
|
- **Authentication:** {{auth_method}}
|
||||||
- **Integration Method:** {{integration_approach}}
|
- **Integration Method:** {{integration_approach}}
|
||||||
|
|
||||||
**Key Endpoints Used:**
|
**Key Endpoints Used:**
|
||||||
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
|
- `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
|
||||||
|
|
||||||
**Error Handling:** {{error_handling_strategy}}
|
**Error Handling:** {{error_handling_strategy}}
|
||||||
|
|
||||||
- id: source-tree-integration
|
- id: source-tree-integration
|
||||||
title: Source Tree Integration
|
title: Source Tree Integration
|
||||||
instruction: |
|
instruction: |
|
||||||
Define how new code will integrate with existing project structure:
|
Define how new code will integrate with existing project structure:
|
||||||
|
|
||||||
1. Follow existing project organization patterns
|
1. Follow existing project organization patterns
|
||||||
2. Identify where new files/folders will be placed
|
2. Identify where new files/folders will be placed
|
||||||
3. Ensure consistency with existing naming conventions
|
3. Ensure consistency with existing naming conventions
|
||||||
|
|
@ -314,7 +314,7 @@ sections:
|
||||||
title: Infrastructure and Deployment Integration
|
title: Infrastructure and Deployment Integration
|
||||||
instruction: |
|
instruction: |
|
||||||
Define how the enhancement will be deployed alongside existing infrastructure:
|
Define how the enhancement will be deployed alongside existing infrastructure:
|
||||||
|
|
||||||
1. Use existing deployment pipeline and infrastructure
|
1. Use existing deployment pipeline and infrastructure
|
||||||
2. Identify any infrastructure changes needed
|
2. Identify any infrastructure changes needed
|
||||||
3. Plan deployment strategy to minimize risk
|
3. Plan deployment strategy to minimize risk
|
||||||
|
|
@ -344,7 +344,7 @@ sections:
|
||||||
title: Coding Standards and Conventions
|
title: Coding Standards and Conventions
|
||||||
instruction: |
|
instruction: |
|
||||||
Ensure new code follows existing project conventions:
|
Ensure new code follows existing project conventions:
|
||||||
|
|
||||||
1. Document existing coding standards from project analysis
|
1. Document existing coding standards from project analysis
|
||||||
2. Identify any enhancement-specific requirements
|
2. Identify any enhancement-specific requirements
|
||||||
3. Ensure consistency with existing codebase patterns
|
3. Ensure consistency with existing codebase patterns
|
||||||
|
|
@ -375,7 +375,7 @@ sections:
|
||||||
title: Testing Strategy
|
title: Testing Strategy
|
||||||
instruction: |
|
instruction: |
|
||||||
Define testing approach for the enhancement:
|
Define testing approach for the enhancement:
|
||||||
|
|
||||||
1. Integrate with existing test suite
|
1. Integrate with existing test suite
|
||||||
2. Ensure existing functionality remains intact
|
2. Ensure existing functionality remains intact
|
||||||
3. Plan for testing new features
|
3. Plan for testing new features
|
||||||
|
|
@ -415,7 +415,7 @@ sections:
|
||||||
title: Security Integration
|
title: Security Integration
|
||||||
instruction: |
|
instruction: |
|
||||||
Ensure security consistency with existing system:
|
Ensure security consistency with existing system:
|
||||||
|
|
||||||
1. Follow existing security patterns and tools
|
1. Follow existing security patterns and tools
|
||||||
2. Ensure new features don't introduce vulnerabilities
|
2. Ensure new features don't introduce vulnerabilities
|
||||||
3. Maintain existing security posture
|
3. Maintain existing security posture
|
||||||
|
|
@ -450,7 +450,7 @@ sections:
|
||||||
title: Next Steps
|
title: Next Steps
|
||||||
instruction: |
|
instruction: |
|
||||||
After completing the brownfield architecture:
|
After completing the brownfield architecture:
|
||||||
|
|
||||||
1. Review integration points with existing system
|
1. Review integration points with existing system
|
||||||
2. Begin story implementation with Dev agent
|
2. Begin story implementation with Dev agent
|
||||||
3. Set up deployment pipeline integration
|
3. Set up deployment pipeline integration
|
||||||
|
|
@ -473,4 +473,4 @@ sections:
|
||||||
- Integration requirements with existing codebase validated with user
|
- Integration requirements with existing codebase validated with user
|
||||||
- Key technical decisions based on real project constraints
|
- Key technical decisions based on real project constraints
|
||||||
- Existing system compatibility requirements with specific verification steps
|
- Existing system compatibility requirements with specific verification steps
|
||||||
- Clear sequencing of implementation to minimize risk to existing functionality
|
- Clear sequencing of implementation to minimize risk to existing functionality
|
||||||
|
|
|
||||||
|
|
@ -16,19 +16,19 @@ sections:
|
||||||
title: Intro Project Analysis and Context
|
title: Intro Project Analysis and Context
|
||||||
instruction: |
|
instruction: |
|
||||||
IMPORTANT - SCOPE ASSESSMENT REQUIRED:
|
IMPORTANT - SCOPE ASSESSMENT REQUIRED:
|
||||||
|
|
||||||
This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
|
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."
|
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.
|
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.
|
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.
|
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?"
|
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.
|
Do not proceed with any recommendations until the user has validated your understanding of the existing system.
|
||||||
sections:
|
sections:
|
||||||
- id: existing-project-overview
|
- id: existing-project-overview
|
||||||
|
|
@ -54,7 +54,7 @@ sections:
|
||||||
- Note: "Document-project analysis available - using existing technical documentation"
|
- Note: "Document-project analysis available - using existing technical documentation"
|
||||||
- List key documents created by document-project
|
- List key documents created by document-project
|
||||||
- Skip the missing documentation check below
|
- Skip the missing documentation check below
|
||||||
|
|
||||||
Otherwise, check for existing documentation:
|
Otherwise, check for existing documentation:
|
||||||
sections:
|
sections:
|
||||||
- id: available-docs
|
- id: available-docs
|
||||||
|
|
@ -178,7 +178,7 @@ sections:
|
||||||
If document-project output available:
|
If document-project output available:
|
||||||
- Extract from "Actual Tech Stack" table in High Level Architecture section
|
- Extract from "Actual Tech Stack" table in High Level Architecture section
|
||||||
- Include version numbers and any noted constraints
|
- Include version numbers and any noted constraints
|
||||||
|
|
||||||
Otherwise, document the current technology stack:
|
Otherwise, document the current technology stack:
|
||||||
template: |
|
template: |
|
||||||
**Languages**: {{languages}}
|
**Languages**: {{languages}}
|
||||||
|
|
@ -217,7 +217,7 @@ sections:
|
||||||
- Reference "Technical Debt and Known Issues" section
|
- Reference "Technical Debt and Known Issues" section
|
||||||
- Include "Workarounds and Gotchas" that might impact enhancement
|
- Include "Workarounds and Gotchas" that might impact enhancement
|
||||||
- Note any identified constraints from "Critical Technical Debt"
|
- Note any identified constraints from "Critical Technical Debt"
|
||||||
|
|
||||||
Build risk assessment incorporating existing known issues:
|
Build risk assessment incorporating existing known issues:
|
||||||
template: |
|
template: |
|
||||||
**Technical Risks**: {{technical_risks}}
|
**Technical Risks**: {{technical_risks}}
|
||||||
|
|
@ -240,7 +240,7 @@ sections:
|
||||||
title: "Epic 1: {{enhancement_title}}"
|
title: "Epic 1: {{enhancement_title}}"
|
||||||
instruction: |
|
instruction: |
|
||||||
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
|
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
|
||||||
|
|
||||||
CRITICAL STORY SEQUENCING FOR BROWNFIELD:
|
CRITICAL STORY SEQUENCING FOR BROWNFIELD:
|
||||||
- Stories must ensure existing functionality remains intact
|
- Stories must ensure existing functionality remains intact
|
||||||
- Each story should include verification that existing features still work
|
- Each story should include verification that existing features still work
|
||||||
|
|
@ -253,7 +253,7 @@ sections:
|
||||||
- Each story must deliver value while maintaining system integrity
|
- Each story must deliver value while maintaining system integrity
|
||||||
template: |
|
template: |
|
||||||
**Epic Goal**: {{epic_goal}}
|
**Epic Goal**: {{epic_goal}}
|
||||||
|
|
||||||
**Integration Requirements**: {{integration_requirements}}
|
**Integration Requirements**: {{integration_requirements}}
|
||||||
sections:
|
sections:
|
||||||
- id: story
|
- id: story
|
||||||
|
|
@ -277,4 +277,4 @@ sections:
|
||||||
items:
|
items:
|
||||||
- template: "IV1: {{existing_functionality_verification}}"
|
- template: "IV1: {{existing_functionality_verification}}"
|
||||||
- template: "IV2: {{integration_point_verification}}"
|
- template: "IV2: {{integration_point_verification}}"
|
||||||
- template: "IV3: {{performance_impact_verification}}"
|
- template: "IV3: {{performance_impact_verification}}"
|
||||||
|
|
|
||||||
|
|
@ -76,7 +76,7 @@ sections:
|
||||||
title: Competitor Prioritization Matrix
|
title: Competitor Prioritization Matrix
|
||||||
instruction: |
|
instruction: |
|
||||||
Help categorize competitors by market share and strategic threat level
|
Help categorize competitors by market share and strategic threat level
|
||||||
|
|
||||||
Create a 2x2 matrix:
|
Create a 2x2 matrix:
|
||||||
- Priority 1 (Core Competitors): High Market Share + High Threat
|
- Priority 1 (Core Competitors): High Market Share + High Threat
|
||||||
- Priority 2 (Emerging Threats): Low Market Share + High Threat
|
- Priority 2 (Emerging Threats): Low Market Share + High Threat
|
||||||
|
|
@ -141,7 +141,14 @@ sections:
|
||||||
title: Feature Comparison Matrix
|
title: Feature Comparison Matrix
|
||||||
instruction: Create a detailed comparison table of key features across competitors
|
instruction: Create a detailed comparison table of key features across competitors
|
||||||
type: table
|
type: table
|
||||||
columns: ["Feature Category", "{{your_company}}", "{{competitor_1}}", "{{competitor_2}}", "{{competitor_3}}"]
|
columns:
|
||||||
|
[
|
||||||
|
"Feature Category",
|
||||||
|
"{{your_company}}",
|
||||||
|
"{{competitor_1}}",
|
||||||
|
"{{competitor_2}}",
|
||||||
|
"{{competitor_3}}",
|
||||||
|
]
|
||||||
rows:
|
rows:
|
||||||
- category: "Core Functionality"
|
- category: "Core Functionality"
|
||||||
items:
|
items:
|
||||||
|
|
@ -153,7 +160,13 @@ sections:
|
||||||
- ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
|
- ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
|
||||||
- category: "Integration & Ecosystem"
|
- category: "Integration & Ecosystem"
|
||||||
items:
|
items:
|
||||||
- ["API Availability", "{{availability}}", "{{availability}}", "{{availability}}", "{{availability}}"]
|
- [
|
||||||
|
"API Availability",
|
||||||
|
"{{availability}}",
|
||||||
|
"{{availability}}",
|
||||||
|
"{{availability}}",
|
||||||
|
"{{availability}}",
|
||||||
|
]
|
||||||
- ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
|
- ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
|
||||||
- category: "Pricing & Plans"
|
- category: "Pricing & Plans"
|
||||||
items:
|
items:
|
||||||
|
|
@ -180,7 +193,7 @@ sections:
|
||||||
title: Positioning Map
|
title: Positioning Map
|
||||||
instruction: |
|
instruction: |
|
||||||
Describe competitor positions on key dimensions
|
Describe competitor positions on key dimensions
|
||||||
|
|
||||||
Create a positioning description using 2 key dimensions relevant to the market, such as:
|
Create a positioning description using 2 key dimensions relevant to the market, such as:
|
||||||
- Price vs. Features
|
- Price vs. Features
|
||||||
- Ease of Use vs. Power
|
- Ease of Use vs. Power
|
||||||
|
|
@ -215,7 +228,7 @@ sections:
|
||||||
title: Blue Ocean Opportunities
|
title: Blue Ocean Opportunities
|
||||||
instruction: |
|
instruction: |
|
||||||
Identify uncontested market spaces
|
Identify uncontested market spaces
|
||||||
|
|
||||||
List opportunities to create new market space:
|
List opportunities to create new market space:
|
||||||
- Underserved segments
|
- Underserved segments
|
||||||
- Unaddressed use cases
|
- Unaddressed use cases
|
||||||
|
|
@ -290,4 +303,4 @@ sections:
|
||||||
Recommended review schedule:
|
Recommended review schedule:
|
||||||
- Weekly: {{weekly_items}}
|
- Weekly: {{weekly_items}}
|
||||||
- Monthly: {{monthly_items}}
|
- Monthly: {{monthly_items}}
|
||||||
- Quarterly: {{quarterly_analysis}}
|
- Quarterly: {{quarterly_analysis}}
|
||||||
|
|
|
||||||
|
|
@ -305,62 +305,62 @@ prompts:
|
||||||
git_branch: "Git branch worked on"
|
git_branch: "Git branch worked on"
|
||||||
developer_name: "Developer name (agent or human)"
|
developer_name: "Developer name (agent or human)"
|
||||||
session_type: "Session type (Implementation, Bug Fix, Refactoring, Feature Development, Investigation)"
|
session_type: "Session type (Implementation, Bug Fix, Refactoring, Feature Development, Investigation)"
|
||||||
|
|
||||||
# Session overview
|
# Session overview
|
||||||
session_summary: "Brief 2-3 sentence summary of session accomplishments"
|
session_summary: "Brief 2-3 sentence summary of session accomplishments"
|
||||||
starting_state: "State of the project at session start"
|
starting_state: "State of the project at session start"
|
||||||
session_goals: "List session objectives"
|
session_goals: "List session objectives"
|
||||||
previous_entry: "Link to previous journal entry (if applicable)"
|
previous_entry: "Link to previous journal entry (if applicable)"
|
||||||
|
|
||||||
# Work details
|
# Work details
|
||||||
initial_problem: "Initial request, problem, or task description"
|
initial_problem: "Initial request, problem, or task description"
|
||||||
investigation_process: "Detail exploration process, tools used, dead ends"
|
investigation_process: "Detail exploration process, tools used, dead ends"
|
||||||
work_streams: "List work streams with details (name, type, files, changes, rationale, impact)"
|
work_streams: "List work streams with details (name, type, files, changes, rationale, impact)"
|
||||||
breakthroughs: "Key discoveries and decisions with context and resolution"
|
breakthroughs: "Key discoveries and decisions with context and resolution"
|
||||||
|
|
||||||
# Implementation
|
# Implementation
|
||||||
code_changes_summary: "Summary of significant code changes"
|
code_changes_summary: "Summary of significant code changes"
|
||||||
architecture_changes: "New patterns or architectural decisions"
|
architecture_changes: "New patterns or architectural decisions"
|
||||||
config_updates: "Environment variables, build configs, dependencies"
|
config_updates: "Environment variables, build configs, dependencies"
|
||||||
|
|
||||||
# Testing
|
# Testing
|
||||||
tests_modified: "List test files created or updated"
|
tests_modified: "List test files created or updated"
|
||||||
manual_testing: "User flows and edge cases tested"
|
manual_testing: "User flows and edge cases tested"
|
||||||
validation_working: "What was confirmed working"
|
validation_working: "What was confirmed working"
|
||||||
remaining_issues: "Any remaining issues"
|
remaining_issues: "Any remaining issues"
|
||||||
|
|
||||||
# Documentation
|
# Documentation
|
||||||
code_documentation: "Inline comments, JSDoc updates"
|
code_documentation: "Inline comments, JSDoc updates"
|
||||||
project_documentation: "README, Wiki, API docs updated"
|
project_documentation: "README, Wiki, API docs updated"
|
||||||
adr_updates: "ADRs created or updated"
|
adr_updates: "ADRs created or updated"
|
||||||
|
|
||||||
# Git activity
|
# Git activity
|
||||||
commits: "List commits with hash and message"
|
commits: "List commits with hash and message"
|
||||||
files_added: "Number of files added"
|
files_added: "Number of files added"
|
||||||
files_modified: "Number of files modified"
|
files_modified: "Number of files modified"
|
||||||
files_deleted: "Number of files deleted"
|
files_deleted: "Number of files deleted"
|
||||||
|
|
||||||
# Learning
|
# Learning
|
||||||
challenges: "List challenges and how overcome"
|
challenges: "List challenges and how overcome"
|
||||||
learnings: "Technical insights or patterns discovered"
|
learnings: "Technical insights or patterns discovered"
|
||||||
patterns_established: "New coding patterns or conventions"
|
patterns_established: "New coding patterns or conventions"
|
||||||
|
|
||||||
# State and next steps
|
# State and next steps
|
||||||
working_features: "Completed features or fixes that are functional"
|
working_features: "Completed features or fixes that are functional"
|
||||||
known_issues: "Bugs or limitations discovered but not resolved"
|
known_issues: "Bugs or limitations discovered but not resolved"
|
||||||
technical_debt: "Shortcuts taken that need future attention"
|
technical_debt: "Shortcuts taken that need future attention"
|
||||||
immediate_next_steps: "Most urgent tasks for next session"
|
immediate_next_steps: "Most urgent tasks for next session"
|
||||||
future_considerations: "Longer-term improvements or refactoring needs"
|
future_considerations: "Longer-term improvements or refactoring needs"
|
||||||
|
|
||||||
# Metrics
|
# Metrics
|
||||||
story_tasks_completed: "Number of story tasks completed (X of Y)"
|
story_tasks_completed: "Number of story tasks completed (X of Y)"
|
||||||
tests_written: "Number of tests written"
|
tests_written: "Number of tests written"
|
||||||
code_coverage: "Code coverage percentage (if measured)"
|
code_coverage: "Code coverage percentage (if measured)"
|
||||||
performance_impact: "Performance impact (if relevant)"
|
performance_impact: "Performance impact (if relevant)"
|
||||||
|
|
||||||
# References
|
# References
|
||||||
future_session_notes: "Important context, gotchas, or reminders"
|
future_session_notes: "Important context, gotchas, or reminders"
|
||||||
related_stories: "Story IDs or links"
|
related_stories: "Story IDs or links"
|
||||||
related_adrs: "ADR numbers if applicable"
|
related_adrs: "ADR numbers if applicable"
|
||||||
related_prs: "Pull request references"
|
related_prs: "Pull request references"
|
||||||
external_resources: "Helpful links or documentation consulted"
|
external_resources: "Helpful links or documentation consulted"
|
||||||
|
|
|
||||||
|
|
@ -16,16 +16,16 @@ sections:
|
||||||
title: Template and Framework Selection
|
title: Template and Framework Selection
|
||||||
instruction: |
|
instruction: |
|
||||||
Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided.
|
Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided.
|
||||||
|
|
||||||
Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase:
|
Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase:
|
||||||
|
|
||||||
1. Review the PRD, main architecture document, and brainstorming brief for mentions of:
|
1. Review the PRD, main architecture document, and brainstorming brief for mentions of:
|
||||||
- Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.)
|
- Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.)
|
||||||
- UI kit or component library starters
|
- UI kit or component library starters
|
||||||
- Existing frontend projects being used as a foundation
|
- Existing frontend projects being used as a foundation
|
||||||
- Admin dashboard templates or other specialized starters
|
- Admin dashboard templates or other specialized starters
|
||||||
- Design system implementations
|
- Design system implementations
|
||||||
|
|
||||||
2. If a frontend starter template or existing project is mentioned:
|
2. If a frontend starter template or existing project is mentioned:
|
||||||
- Ask the user to provide access via one of these methods:
|
- Ask the user to provide access via one of these methods:
|
||||||
- Link to the starter template documentation
|
- Link to the starter template documentation
|
||||||
|
|
@ -41,7 +41,7 @@ sections:
|
||||||
- Testing setup and patterns
|
- Testing setup and patterns
|
||||||
- Build and development scripts
|
- Build and development scripts
|
||||||
- Use this analysis to ensure your frontend architecture aligns with the starter's patterns
|
- Use this analysis to ensure your frontend architecture aligns with the starter's patterns
|
||||||
|
|
||||||
3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is:
|
3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is:
|
||||||
- Based on the framework choice, suggest appropriate starters:
|
- Based on the framework choice, suggest appropriate starters:
|
||||||
- React: Create React App, Next.js, Vite + React
|
- React: Create React App, Next.js, Vite + React
|
||||||
|
|
@ -49,11 +49,11 @@ sections:
|
||||||
- Angular: Angular CLI
|
- Angular: Angular CLI
|
||||||
- Or suggest popular UI templates if applicable
|
- Or suggest popular UI templates if applicable
|
||||||
- Explain benefits specific to frontend development
|
- Explain benefits specific to frontend development
|
||||||
|
|
||||||
4. If the user confirms no starter template will be used:
|
4. If the user confirms no starter template will be used:
|
||||||
- Note that all tooling, bundling, and configuration will need manual setup
|
- Note that all tooling, bundling, and configuration will need manual setup
|
||||||
- Proceed with frontend architecture from scratch
|
- Proceed with frontend architecture from scratch
|
||||||
|
|
||||||
Document the starter template decision and any constraints it imposes before proceeding.
|
Document the starter template decision and any constraints it imposes before proceeding.
|
||||||
sections:
|
sections:
|
||||||
- id: changelog
|
- id: changelog
|
||||||
|
|
@ -75,19 +75,34 @@ sections:
|
||||||
rows:
|
rows:
|
||||||
- ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
- ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
- ["State Management", "{{state_management}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- [
|
||||||
|
"State Management",
|
||||||
|
"{{state_management}}",
|
||||||
|
"{{version}}",
|
||||||
|
"{{purpose}}",
|
||||||
|
"{{why_chosen}}",
|
||||||
|
]
|
||||||
- ["Routing", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["Routing", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
- ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
- ["Styling", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["Styling", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
- ["Testing", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["Testing", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
- ["Component Library", "{{component_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- [
|
||||||
|
"Component Library",
|
||||||
|
"{{component_lib}}",
|
||||||
|
"{{version}}",
|
||||||
|
"{{purpose}}",
|
||||||
|
"{{why_chosen}}",
|
||||||
|
]
|
||||||
- ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
- ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
- ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
- ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
|
||||||
|
|
||||||
- id: project-structure
|
- id: project-structure
|
||||||
title: Project Structure
|
title: Project Structure
|
||||||
instruction: Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions.
|
instruction: |
|
||||||
|
Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions.
|
||||||
|
|
||||||
|
NOTE: Reference project-scaffolding-preference.md for standard project structure guidelines. Ensure to include BMAD-specific directories (docs/memory-bank, docs/adr, docs/devJournal) in addition to frontend-specific structure.
|
||||||
elicit: true
|
elicit: true
|
||||||
type: code
|
type: code
|
||||||
language: plaintext
|
language: plaintext
|
||||||
|
|
@ -203,4 +218,4 @@ sections:
|
||||||
- Common commands (dev server, build, test)
|
- Common commands (dev server, build, test)
|
||||||
- Key import patterns
|
- Key import patterns
|
||||||
- File naming conventions
|
- File naming conventions
|
||||||
- Project-specific patterns and utilities
|
- Project-specific patterns and utilities
|
||||||
|
|
|
||||||
|
|
@ -16,7 +16,7 @@ sections:
|
||||||
title: Introduction
|
title: Introduction
|
||||||
instruction: |
|
instruction: |
|
||||||
Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.
|
Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.
|
||||||
|
|
||||||
Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
|
Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
|
||||||
content: |
|
content: |
|
||||||
This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
|
This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
|
||||||
|
|
@ -25,7 +25,7 @@ sections:
|
||||||
title: Overall UX Goals & Principles
|
title: Overall UX Goals & Principles
|
||||||
instruction: |
|
instruction: |
|
||||||
Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
|
Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
|
||||||
|
|
||||||
1. Target User Personas - elicit details or confirm existing ones from PRD
|
1. Target User Personas - elicit details or confirm existing ones from PRD
|
||||||
2. Key Usability Goals - understand what success looks like for users
|
2. Key Usability Goals - understand what success looks like for users
|
||||||
3. Core Design Principles - establish 3-5 guiding principles
|
3. Core Design Principles - establish 3-5 guiding principles
|
||||||
|
|
@ -66,7 +66,7 @@ sections:
|
||||||
title: Information Architecture (IA)
|
title: Information Architecture (IA)
|
||||||
instruction: |
|
instruction: |
|
||||||
Collaborate with the user to create a comprehensive information architecture:
|
Collaborate with the user to create a comprehensive information architecture:
|
||||||
|
|
||||||
1. Build a Site Map or Screen Inventory showing all major areas
|
1. Build a Site Map or Screen Inventory showing all major areas
|
||||||
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
|
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
|
||||||
3. Use Mermaid diagrams for visual representation
|
3. Use Mermaid diagrams for visual representation
|
||||||
|
|
@ -96,22 +96,22 @@ sections:
|
||||||
title: Navigation Structure
|
title: Navigation Structure
|
||||||
template: |
|
template: |
|
||||||
**Primary Navigation:** {{primary_nav_description}}
|
**Primary Navigation:** {{primary_nav_description}}
|
||||||
|
|
||||||
**Secondary Navigation:** {{secondary_nav_description}}
|
**Secondary Navigation:** {{secondary_nav_description}}
|
||||||
|
|
||||||
**Breadcrumb Strategy:** {{breadcrumb_strategy}}
|
**Breadcrumb Strategy:** {{breadcrumb_strategy}}
|
||||||
|
|
||||||
- id: user-flows
|
- id: user-flows
|
||||||
title: User Flows
|
title: User Flows
|
||||||
instruction: |
|
instruction: |
|
||||||
For each critical user task identified in the PRD:
|
For each critical user task identified in the PRD:
|
||||||
|
|
||||||
1. Define the user's goal clearly
|
1. Define the user's goal clearly
|
||||||
2. Map out all steps including decision points
|
2. Map out all steps including decision points
|
||||||
3. Consider edge cases and error states
|
3. Consider edge cases and error states
|
||||||
4. Use Mermaid flow diagrams for clarity
|
4. Use Mermaid flow diagrams for clarity
|
||||||
5. Link to external tools (Figma/Miro) if detailed flows exist there
|
5. Link to external tools (Figma/Miro) if detailed flows exist there
|
||||||
|
|
||||||
Create subsections for each major flow.
|
Create subsections for each major flow.
|
||||||
elicit: true
|
elicit: true
|
||||||
repeatable: true
|
repeatable: true
|
||||||
|
|
@ -120,9 +120,9 @@ sections:
|
||||||
title: "{{flow_name}}"
|
title: "{{flow_name}}"
|
||||||
template: |
|
template: |
|
||||||
**User Goal:** {{flow_goal}}
|
**User Goal:** {{flow_goal}}
|
||||||
|
|
||||||
**Entry Points:** {{entry_points}}
|
**Entry Points:** {{entry_points}}
|
||||||
|
|
||||||
**Success Criteria:** {{success_criteria}}
|
**Success Criteria:** {{success_criteria}}
|
||||||
sections:
|
sections:
|
||||||
- id: flow-diagram
|
- id: flow-diagram
|
||||||
|
|
@ -153,14 +153,14 @@ sections:
|
||||||
title: "{{screen_name}}"
|
title: "{{screen_name}}"
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** {{screen_purpose}}
|
**Purpose:** {{screen_purpose}}
|
||||||
|
|
||||||
**Key Elements:**
|
**Key Elements:**
|
||||||
- {{element_1}}
|
- {{element_1}}
|
||||||
- {{element_2}}
|
- {{element_2}}
|
||||||
- {{element_3}}
|
- {{element_3}}
|
||||||
|
|
||||||
**Interaction Notes:** {{interaction_notes}}
|
**Interaction Notes:** {{interaction_notes}}
|
||||||
|
|
||||||
**Design File Reference:** {{specific_frame_link}}
|
**Design File Reference:** {{specific_frame_link}}
|
||||||
|
|
||||||
- id: component-library
|
- id: component-library
|
||||||
|
|
@ -179,11 +179,11 @@ sections:
|
||||||
title: "{{component_name}}"
|
title: "{{component_name}}"
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** {{component_purpose}}
|
**Purpose:** {{component_purpose}}
|
||||||
|
|
||||||
**Variants:** {{component_variants}}
|
**Variants:** {{component_variants}}
|
||||||
|
|
||||||
**States:** {{component_states}}
|
**States:** {{component_states}}
|
||||||
|
|
||||||
**Usage Guidelines:** {{usage_guidelines}}
|
**Usage Guidelines:** {{usage_guidelines}}
|
||||||
|
|
||||||
- id: branding-style
|
- id: branding-style
|
||||||
|
|
@ -229,13 +229,13 @@ sections:
|
||||||
title: Iconography
|
title: Iconography
|
||||||
template: |
|
template: |
|
||||||
**Icon Library:** {{icon_library}}
|
**Icon Library:** {{icon_library}}
|
||||||
|
|
||||||
**Usage Guidelines:** {{icon_guidelines}}
|
**Usage Guidelines:** {{icon_guidelines}}
|
||||||
- id: spacing-layout
|
- id: spacing-layout
|
||||||
title: Spacing & Layout
|
title: Spacing & Layout
|
||||||
template: |
|
template: |
|
||||||
**Grid System:** {{grid_system}}
|
**Grid System:** {{grid_system}}
|
||||||
|
|
||||||
**Spacing Scale:** {{spacing_scale}}
|
**Spacing Scale:** {{spacing_scale}}
|
||||||
|
|
||||||
- id: accessibility
|
- id: accessibility
|
||||||
|
|
@ -253,12 +253,12 @@ sections:
|
||||||
- Color contrast ratios: {{contrast_requirements}}
|
- Color contrast ratios: {{contrast_requirements}}
|
||||||
- Focus indicators: {{focus_requirements}}
|
- Focus indicators: {{focus_requirements}}
|
||||||
- Text sizing: {{text_requirements}}
|
- Text sizing: {{text_requirements}}
|
||||||
|
|
||||||
**Interaction:**
|
**Interaction:**
|
||||||
- Keyboard navigation: {{keyboard_requirements}}
|
- Keyboard navigation: {{keyboard_requirements}}
|
||||||
- Screen reader support: {{screen_reader_requirements}}
|
- Screen reader support: {{screen_reader_requirements}}
|
||||||
- Touch targets: {{touch_requirements}}
|
- Touch targets: {{touch_requirements}}
|
||||||
|
|
||||||
**Content:**
|
**Content:**
|
||||||
- Alternative text: {{alt_text_requirements}}
|
- Alternative text: {{alt_text_requirements}}
|
||||||
- Heading structure: {{heading_requirements}}
|
- Heading structure: {{heading_requirements}}
|
||||||
|
|
@ -285,11 +285,11 @@ sections:
|
||||||
title: Adaptation Patterns
|
title: Adaptation Patterns
|
||||||
template: |
|
template: |
|
||||||
**Layout Changes:** {{layout_adaptations}}
|
**Layout Changes:** {{layout_adaptations}}
|
||||||
|
|
||||||
**Navigation Changes:** {{nav_adaptations}}
|
**Navigation Changes:** {{nav_adaptations}}
|
||||||
|
|
||||||
**Content Priority:** {{content_adaptations}}
|
**Content Priority:** {{content_adaptations}}
|
||||||
|
|
||||||
**Interaction Changes:** {{interaction_adaptations}}
|
**Interaction Changes:** {{interaction_adaptations}}
|
||||||
|
|
||||||
- id: animation
|
- id: animation
|
||||||
|
|
@ -323,7 +323,7 @@ sections:
|
||||||
title: Next Steps
|
title: Next Steps
|
||||||
instruction: |
|
instruction: |
|
||||||
After completing the UI/UX specification:
|
After completing the UI/UX specification:
|
||||||
|
|
||||||
1. Recommend review with stakeholders
|
1. Recommend review with stakeholders
|
||||||
2. Suggest creating/updating visual designs in design tool
|
2. Suggest creating/updating visual designs in design tool
|
||||||
3. Prepare for handoff to Design Architect for frontend architecture
|
3. Prepare for handoff to Design Architect for frontend architecture
|
||||||
|
|
@ -346,4 +346,4 @@ sections:
|
||||||
|
|
||||||
- id: checklist-results
|
- id: checklist-results
|
||||||
title: Checklist Results
|
title: Checklist Results
|
||||||
instruction: If a UI/UX checklist exists, run it against this document and report results here.
|
instruction: If a UI/UX checklist exists, run it against this document and report results here.
|
||||||
|
|
|
||||||
|
|
@ -483,7 +483,10 @@ sections:
|
||||||
|
|
||||||
- id: unified-project-structure
|
- id: unified-project-structure
|
||||||
title: Unified Project Structure
|
title: Unified Project Structure
|
||||||
instruction: Create a monorepo structure that accommodates both frontend and backend. Adapt based on chosen tools and frameworks.
|
instruction: |
|
||||||
|
Create a monorepo structure that accommodates both frontend and backend. Adapt based on chosen tools and frameworks.
|
||||||
|
|
||||||
|
NOTE: Reference project-scaffolding-preference.md for standard project structure guidelines and ensure alignment with BMAD conventions including docs/memory-bank, docs/adr, and docs/devJournal directories.
|
||||||
elicit: true
|
elicit: true
|
||||||
type: code
|
type: code
|
||||||
language: plaintext
|
language: plaintext
|
||||||
|
|
|
||||||
|
|
@ -130,7 +130,7 @@ sections:
|
||||||
instruction: Map the end-to-end customer experience for primary segments
|
instruction: Map the end-to-end customer experience for primary segments
|
||||||
template: |
|
template: |
|
||||||
For primary customer segment:
|
For primary customer segment:
|
||||||
|
|
||||||
1. **Awareness:** {{discovery_process}}
|
1. **Awareness:** {{discovery_process}}
|
||||||
2. **Consideration:** {{evaluation_criteria}}
|
2. **Consideration:** {{evaluation_criteria}}
|
||||||
3. **Purchase:** {{decision_triggers}}
|
3. **Purchase:** {{decision_triggers}}
|
||||||
|
|
@ -249,4 +249,4 @@ sections:
|
||||||
instruction: Include any complex calculations or models
|
instruction: Include any complex calculations or models
|
||||||
- id: additional-analysis
|
- id: additional-analysis
|
||||||
title: C. Additional Analysis
|
title: C. Additional Analysis
|
||||||
instruction: Any supplementary analysis not included in main body
|
instruction: Any supplementary analysis not included in main body
|
||||||
|
|
|
||||||
|
|
@ -56,7 +56,7 @@ sections:
|
||||||
condition: PRD has UX/UI requirements
|
condition: PRD has UX/UI requirements
|
||||||
instruction: |
|
instruction: |
|
||||||
Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
|
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
|
1. Pre-fill all subsections with educated guesses based on project context
|
||||||
2. Present the complete rendered section to user
|
2. Present the complete rendered section to user
|
||||||
3. Clearly let the user know where assumptions were made
|
3. Clearly let the user know where assumptions were made
|
||||||
|
|
@ -98,7 +98,7 @@ sections:
|
||||||
title: Technical Assumptions
|
title: Technical Assumptions
|
||||||
instruction: |
|
instruction: |
|
||||||
Gather technical decisions that will guide the Architect. Steps:
|
Gather technical decisions that will guide the Architect. Steps:
|
||||||
|
|
||||||
1. Check if {root}/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
|
1. Check if {root}/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
|
2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
|
||||||
3. For unknowns, offer guidance based on project goals and MVP scope
|
3. For unknowns, offer guidance based on project goals and MVP scope
|
||||||
|
|
@ -126,9 +126,9 @@ sections:
|
||||||
title: Epic List
|
title: Epic List
|
||||||
instruction: |
|
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.
|
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:
|
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
|
- 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!
|
- 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
|
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
|
||||||
|
|
@ -147,11 +147,11 @@ sections:
|
||||||
repeatable: true
|
repeatable: true
|
||||||
instruction: |
|
instruction: |
|
||||||
After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
|
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).
|
For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
|
||||||
|
|
||||||
CRITICAL STORY SEQUENCING REQUIREMENTS:
|
CRITICAL STORY SEQUENCING REQUIREMENTS:
|
||||||
|
|
||||||
- Stories within each epic MUST be logically sequential
|
- 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
|
- 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
|
- No story should depend on work from a later story or epic
|
||||||
|
|
@ -179,7 +179,7 @@ sections:
|
||||||
repeatable: true
|
repeatable: true
|
||||||
instruction: |
|
instruction: |
|
||||||
Define clear, comprehensive, and testable acceptance criteria that:
|
Define clear, comprehensive, and testable acceptance criteria that:
|
||||||
|
|
||||||
- Precisely define what "done" means from a functional perspective
|
- Precisely define what "done" means from a functional perspective
|
||||||
- Are unambiguous and serve as basis for verification
|
- Are unambiguous and serve as basis for verification
|
||||||
- Include any critical non-functional requirements from the PRD
|
- Include any critical non-functional requirements from the PRD
|
||||||
|
|
@ -199,4 +199,4 @@ sections:
|
||||||
instruction: This section will contain the prompt for the UX Expert, keep it short and to the point to initiate create architecture mode using this document as input.
|
instruction: This section will contain the prompt for the UX Expert, keep it short and to the point to initiate create architecture mode using this document as input.
|
||||||
- id: architect-prompt
|
- id: architect-prompt
|
||||||
title: Architect Prompt
|
title: Architect Prompt
|
||||||
instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.
|
instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.
|
||||||
|
|
|
||||||
|
|
@ -189,4 +189,4 @@ prompts:
|
||||||
validation_plans: "How will each assumption be tested?"
|
validation_plans: "How will each assumption be tested?"
|
||||||
upstream_dependencies: "What systems/processes feed into ours?"
|
upstream_dependencies: "What systems/processes feed into ours?"
|
||||||
downstream_impacts: "What systems/processes are affected by our solution?"
|
downstream_impacts: "What systems/processes are affected by our solution?"
|
||||||
partner_integrations: "What third-party services/APIs are needed?"
|
partner_integrations: "What third-party services/APIs are needed?"
|
||||||
|
|
|
||||||
|
|
@ -238,4 +238,4 @@ prompts:
|
||||||
successes: "What practices/decisions are working well?"
|
successes: "What practices/decisions are working well?"
|
||||||
improvements_needed: "What challenges need to be addressed?"
|
improvements_needed: "What challenges need to be addressed?"
|
||||||
mitigated_risks: "Risks that have been successfully mitigated"
|
mitigated_risks: "Risks that have been successfully mitigated"
|
||||||
active_risks: "Current risks being tracked"
|
active_risks: "Current risks being tracked"
|
||||||
|
|
|
||||||
|
|
@ -16,7 +16,7 @@ workflow:
|
||||||
mode_selection:
|
mode_selection:
|
||||||
instruction: |
|
instruction: |
|
||||||
Choose the workflow mode that best fits your needs:
|
Choose the workflow mode that best fits your needs:
|
||||||
|
|
||||||
1. **Comprehensive Mode** - Full product development brief with guided elicitation
|
1. **Comprehensive Mode** - Full product development brief with guided elicitation
|
||||||
Output: docs/brief.md
|
Output: docs/brief.md
|
||||||
|
|
||||||
|
|
@ -25,7 +25,7 @@ workflow:
|
||||||
|
|
||||||
3. **Rapid Mode** - Quick project documentation with structured prompts
|
3. **Rapid Mode** - Quick project documentation with structured prompts
|
||||||
Output: docs/brief.md
|
Output: docs/brief.md
|
||||||
|
|
||||||
elicitation: advanced-elicitation
|
elicitation: advanced-elicitation
|
||||||
custom_elicitation:
|
custom_elicitation:
|
||||||
title: "Project Brief Enhancement Actions"
|
title: "Project Brief Enhancement Actions"
|
||||||
|
|
@ -314,7 +314,7 @@ prompts:
|
||||||
success_criteria: "Define 3-5 measurable success criteria"
|
success_criteria: "Define 3-5 measurable success criteria"
|
||||||
in_scope: "What is IN scope for this project?"
|
in_scope: "What is IN scope for this project?"
|
||||||
out_scope: "What is explicitly OUT of scope?"
|
out_scope: "What is explicitly OUT of scope?"
|
||||||
|
|
||||||
# User-related prompts
|
# User-related prompts
|
||||||
primary_user_type: "Describe the primary user type"
|
primary_user_type: "Describe the primary user type"
|
||||||
primary_user_needs: "What do primary users need from this system?"
|
primary_user_needs: "What do primary users need from this system?"
|
||||||
|
|
@ -323,14 +323,14 @@ prompts:
|
||||||
secondary_user_type: "Describe secondary user types (if any)"
|
secondary_user_type: "Describe secondary user types (if any)"
|
||||||
secondary_user_needs: "What do secondary users need?"
|
secondary_user_needs: "What do secondary users need?"
|
||||||
secondary_user_description: "Detailed description of secondary users"
|
secondary_user_description: "Detailed description of secondary users"
|
||||||
|
|
||||||
# Comprehensive mode prompts
|
# Comprehensive mode prompts
|
||||||
executive_summary_content: "Create executive summary (product concept, problem, target market, value proposition)"
|
executive_summary_content: "Create executive summary (product concept, problem, target market, value proposition)"
|
||||||
detailed_problem_description: "Detailed problem statement with evidence and impact"
|
detailed_problem_description: "Detailed problem statement with evidence and impact"
|
||||||
solution_description: "Describe the solution approach and key differentiators"
|
solution_description: "Describe the solution approach and key differentiators"
|
||||||
mvp_scope: "Define MVP scope - what's the minimum viable product?"
|
mvp_scope: "Define MVP scope - what's the minimum viable product?"
|
||||||
kpis: "List key performance indicators"
|
kpis: "List key performance indicators"
|
||||||
|
|
||||||
# Technical prompts
|
# Technical prompts
|
||||||
technical_constraints: "List technical constraints"
|
technical_constraints: "List technical constraints"
|
||||||
business_constraints: "List business constraints"
|
business_constraints: "List business constraints"
|
||||||
|
|
@ -340,13 +340,13 @@ prompts:
|
||||||
security_requirements: "Define security requirements"
|
security_requirements: "Define security requirements"
|
||||||
scalability_requirements: "Define scalability expectations"
|
scalability_requirements: "Define scalability expectations"
|
||||||
reliability_requirements: "Define reliability/uptime requirements"
|
reliability_requirements: "Define reliability/uptime requirements"
|
||||||
|
|
||||||
# Stakeholder prompts (memory bank mode)
|
# Stakeholder prompts (memory bank mode)
|
||||||
stakeholders: "List primary stakeholders with roles and interests"
|
stakeholders: "List primary stakeholders with roles and interests"
|
||||||
decision_makers: "List key decision makers and what they decide"
|
decision_makers: "List key decision makers and what they decide"
|
||||||
milestones: "Define major milestones with dates and descriptions"
|
milestones: "Define major milestones with dates and descriptions"
|
||||||
current_phase_description: "Describe the current project phase"
|
current_phase_description: "Describe the current project phase"
|
||||||
|
|
||||||
# Risk and planning prompts (comprehensive mode)
|
# Risk and planning prompts (comprehensive mode)
|
||||||
assumptions: "List key assumptions"
|
assumptions: "List key assumptions"
|
||||||
risks: "List primary risks with impact and mitigation"
|
risks: "List primary risks with impact and mitigation"
|
||||||
|
|
@ -354,12 +354,12 @@ prompts:
|
||||||
technical_architecture_notes: "Technical architecture considerations"
|
technical_architecture_notes: "Technical architecture considerations"
|
||||||
phase2_features: "Features planned for Phase 2"
|
phase2_features: "Features planned for Phase 2"
|
||||||
long_term_vision: "Long-term vision for the product"
|
long_term_vision: "Long-term vision for the product"
|
||||||
|
|
||||||
# Support prompts
|
# Support prompts
|
||||||
references: "List links to supporting documentation"
|
references: "List links to supporting documentation"
|
||||||
research_summary: "Summary of research conducted"
|
research_summary: "Summary of research conducted"
|
||||||
competitive_analysis: "Competitive analysis findings"
|
competitive_analysis: "Competitive analysis findings"
|
||||||
|
|
||||||
# Mode selection
|
# Mode selection
|
||||||
workflow_mode: "Choose workflow mode: comprehensive, memory_bank, or rapid"
|
workflow_mode: "Choose workflow mode: comprehensive, memory_bank, or rapid"
|
||||||
output_path: "Output file path (auto-set based on mode if not specified)"
|
output_path: "Output file path (auto-set based on mode if not specified)"
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,240 @@
|
||||||
|
template:
|
||||||
|
type: document
|
||||||
|
id: sprint-planning-tmpl
|
||||||
|
name: Sprint Planning Template
|
||||||
|
version: 1.0.0
|
||||||
|
description: >-
|
||||||
|
Template for sprint planning sessions. Documents sprint goals, selected stories,
|
||||||
|
capacity planning, risk assessment, and success criteria. Integrates with Memory Bank
|
||||||
|
for context and creates Dev Journal entries for tracking.
|
||||||
|
category: planning
|
||||||
|
|
||||||
|
sections:
|
||||||
|
- id: sprint-overview
|
||||||
|
name: Sprint Overview
|
||||||
|
content: |
|
||||||
|
# Sprint [Number] Planning
|
||||||
|
|
||||||
|
## Sprint Information
|
||||||
|
- **Sprint Number**: [X]
|
||||||
|
- **Sprint Name**: [Descriptive name]
|
||||||
|
- **Start Date**: [YYYY-MM-DD]
|
||||||
|
- **End Date**: [YYYY-MM-DD]
|
||||||
|
- **Duration**: [X weeks]
|
||||||
|
- **Team**: [Team name/composition]
|
||||||
|
|
||||||
|
## Sprint Theme
|
||||||
|
[Brief description of the sprint's primary focus or theme]
|
||||||
|
|
||||||
|
- id: context-review
|
||||||
|
name: Context Review
|
||||||
|
content: |
|
||||||
|
## Context from Previous Sprint
|
||||||
|
|
||||||
|
### Previous Sprint Outcomes
|
||||||
|
[Summary of what was completed in the previous sprint]
|
||||||
|
|
||||||
|
### Carried Over Items
|
||||||
|
- [ ] [Story/task carried from previous sprint]
|
||||||
|
- [ ] [Technical debt item]
|
||||||
|
|
||||||
|
### Memory Bank Context
|
||||||
|
- **Active Context**: [Key points from activeContext.md]
|
||||||
|
- **Recent Patterns**: [Relevant patterns from systemPatterns.md]
|
||||||
|
- **Progress Status**: [Current state from progress.md]
|
||||||
|
|
||||||
|
### Recent Dev Journal Insights
|
||||||
|
[Key learnings or decisions from recent dev journals]
|
||||||
|
|
||||||
|
- id: sprint-goals
|
||||||
|
name: Sprint Goals
|
||||||
|
content: |
|
||||||
|
## Sprint Goals
|
||||||
|
|
||||||
|
### Primary Goal
|
||||||
|
[Main objective for this sprint - should be achievable and measurable]
|
||||||
|
|
||||||
|
### Secondary Goals
|
||||||
|
1. [Secondary objective 1]
|
||||||
|
2. [Secondary objective 2]
|
||||||
|
3. [Secondary objective 3]
|
||||||
|
|
||||||
|
### Success Criteria
|
||||||
|
- [ ] [Specific measurable outcome 1]
|
||||||
|
- [ ] [Specific measurable outcome 2]
|
||||||
|
- [ ] [Specific measurable outcome 3]
|
||||||
|
|
||||||
|
### Definition of Done
|
||||||
|
- [ ] All code reviewed and approved
|
||||||
|
- [ ] All tests passing (unit, integration, E2E)
|
||||||
|
- [ ] Documentation updated
|
||||||
|
- [ ] Memory Bank updated with progress
|
||||||
|
- [ ] Dev Journal entry created
|
||||||
|
|
||||||
|
- id: capacity-planning
|
||||||
|
name: Capacity Planning
|
||||||
|
content: |
|
||||||
|
## Team Capacity
|
||||||
|
|
||||||
|
### Available Hours
|
||||||
|
| Team Member | Role | Available Hours | Planned Time Off |
|
||||||
|
|-------------|------|-----------------|------------------|
|
||||||
|
| [Name] | [Role] | [Hours] | [Dates if any] |
|
||||||
|
|
||||||
|
### Velocity Reference
|
||||||
|
- **Previous Sprint Velocity**: [Story points]
|
||||||
|
- **3-Sprint Average**: [Story points]
|
||||||
|
- **Target Velocity**: [Story points]
|
||||||
|
|
||||||
|
### Capacity Allocation
|
||||||
|
- **Feature Development**: [X]%
|
||||||
|
- **Bug Fixes**: [X]%
|
||||||
|
- **Technical Debt**: [X]%
|
||||||
|
- **Meetings/Ceremonies**: [X]%
|
||||||
|
- **Buffer**: [X]%
|
||||||
|
|
||||||
|
- id: selected-stories
|
||||||
|
name: Selected Stories
|
||||||
|
content: |
|
||||||
|
## Selected User Stories
|
||||||
|
|
||||||
|
### Committed Stories
|
||||||
|
| Story ID | Title | Points | Assignee | Dependencies |
|
||||||
|
|----------|-------|--------|----------|--------------|
|
||||||
|
| [ID] | [Title] | [Points] | [Name] | [Dependencies] |
|
||||||
|
|
||||||
|
### Total Story Points: [X]
|
||||||
|
|
||||||
|
### Story Details
|
||||||
|
#### [Story ID]: [Story Title]
|
||||||
|
- **Acceptance Criteria**:
|
||||||
|
- [ ] [Criterion 1]
|
||||||
|
- [ ] [Criterion 2]
|
||||||
|
- **Technical Considerations**: [Notes]
|
||||||
|
- **Integration Points**: [Systems/APIs]
|
||||||
|
- **Testing Strategy**: [Approach]
|
||||||
|
|
||||||
|
- id: technical-planning
|
||||||
|
name: Technical Planning
|
||||||
|
content: |
|
||||||
|
## Technical Considerations
|
||||||
|
|
||||||
|
### Architecture Impacts
|
||||||
|
- [ ] [Component/system that will be modified]
|
||||||
|
- [ ] [New integrations required]
|
||||||
|
- [ ] [Database changes needed]
|
||||||
|
|
||||||
|
### Technical Dependencies
|
||||||
|
| Dependency | Status | Owner | Due Date |
|
||||||
|
|------------|--------|-------|----------|
|
||||||
|
| [Item] | [Status] | [Name] | [Date] |
|
||||||
|
|
||||||
|
### Technical Debt Items
|
||||||
|
- [ ] [Debt item to address this sprint]
|
||||||
|
- [ ] [Refactoring opportunity]
|
||||||
|
|
||||||
|
### Performance Considerations
|
||||||
|
- [Performance impacts to monitor]
|
||||||
|
- [Optimization opportunities]
|
||||||
|
|
||||||
|
- id: risk-assessment
|
||||||
|
name: Risk Assessment
|
||||||
|
content: |
|
||||||
|
## Risk Assessment
|
||||||
|
|
||||||
|
### Identified Risks
|
||||||
|
| Risk | Probability | Impact | Mitigation Strategy | Owner |
|
||||||
|
|------|-------------|--------|---------------------|-------|
|
||||||
|
| [Risk description] | High/Med/Low | High/Med/Low | [Strategy] | [Name] |
|
||||||
|
|
||||||
|
### Dependencies on External Teams
|
||||||
|
- **Team**: [External team name]
|
||||||
|
- **Dependency**: [What we need]
|
||||||
|
- **Status**: [Current status]
|
||||||
|
- **Fallback**: [Plan B if blocked]
|
||||||
|
|
||||||
|
### Technical Risks
|
||||||
|
- [ ] [Complex integration risk]
|
||||||
|
- [ ] [Performance risk]
|
||||||
|
- [ ] [Security consideration]
|
||||||
|
|
||||||
|
- id: communication-plan
|
||||||
|
name: Communication Plan
|
||||||
|
content: |
|
||||||
|
## Communication Plan
|
||||||
|
|
||||||
|
### Sprint Ceremonies
|
||||||
|
- **Daily Standup**: [Time] @ [Location/Link]
|
||||||
|
- **Sprint Review**: [Date/Time] @ [Location/Link]
|
||||||
|
- **Retrospective**: [Date/Time] @ [Location/Link]
|
||||||
|
|
||||||
|
### Stakeholder Updates
|
||||||
|
- **Format**: [Email/Slack/Meeting]
|
||||||
|
- **Frequency**: [Daily/Weekly]
|
||||||
|
- **Recipients**: [List of stakeholders]
|
||||||
|
|
||||||
|
### Escalation Path
|
||||||
|
1. [First level - e.g., Scrum Master]
|
||||||
|
2. [Second level - e.g., Product Owner]
|
||||||
|
3. [Third level - e.g., Engineering Manager]
|
||||||
|
|
||||||
|
- id: sprint-backlog
|
||||||
|
name: Sprint Backlog
|
||||||
|
content: |
|
||||||
|
## Sprint Backlog
|
||||||
|
|
||||||
|
### Ready for Development
|
||||||
|
- [ ] [Task ready to start]
|
||||||
|
- [ ] [Another task]
|
||||||
|
|
||||||
|
### In Progress
|
||||||
|
- [ ] [Task being worked on]
|
||||||
|
|
||||||
|
### Stretch Goals
|
||||||
|
- [ ] [Additional story if capacity allows]
|
||||||
|
- [ ] [Nice-to-have feature]
|
||||||
|
|
||||||
|
### Not Selected (Documented for Next Sprint)
|
||||||
|
- [Story/task deferred with reason]
|
||||||
|
- [Another deferred item]
|
||||||
|
|
||||||
|
- id: acceptance-criteria
|
||||||
|
name: Sprint Acceptance Criteria
|
||||||
|
content: |
|
||||||
|
## Sprint Acceptance Criteria
|
||||||
|
|
||||||
|
### Must Complete
|
||||||
|
- [ ] All committed stories meet Definition of Done
|
||||||
|
- [ ] No critical bugs in production
|
||||||
|
- [ ] Memory Bank updated with sprint progress
|
||||||
|
- [ ] Dev Journals document key decisions
|
||||||
|
- [ ] All integration tests passing
|
||||||
|
|
||||||
|
### Should Complete
|
||||||
|
- [ ] Technical debt items addressed
|
||||||
|
- [ ] Documentation updated
|
||||||
|
- [ ] Performance benchmarks met
|
||||||
|
|
||||||
|
### Sprint Review Preparation
|
||||||
|
- [ ] Demo environment ready
|
||||||
|
- [ ] Demo script prepared
|
||||||
|
- [ ] Metrics collected
|
||||||
|
- [ ] Stakeholder invites sent
|
||||||
|
|
||||||
|
usage:
|
||||||
|
instructions: |
|
||||||
|
This template should be used at the beginning of each sprint during sprint planning.
|
||||||
|
|
||||||
|
1. Review previous sprint outcomes and Memory Bank context
|
||||||
|
2. Define clear, measurable sprint goals
|
||||||
|
3. Assess team capacity realistically
|
||||||
|
4. Select stories that align with goals and capacity
|
||||||
|
5. Identify and plan for risks
|
||||||
|
6. Establish clear communication plans
|
||||||
|
7. Document all decisions in Dev Journal
|
||||||
|
|
||||||
|
integration:
|
||||||
|
- memory-bank: Update activeContext.md with sprint goals
|
||||||
|
- dev-journal: Create sprint planning entry
|
||||||
|
- workflows: Referenced by sprint-execution workflow
|
||||||
|
- checklists: Links to sprint-review-checklist for end of sprint
|
||||||
|
|
@ -0,0 +1,256 @@
|
||||||
|
template:
|
||||||
|
id: sprint-review-template-v1
|
||||||
|
name: Sprint Review & Retrospective
|
||||||
|
version: 1.0
|
||||||
|
output:
|
||||||
|
format: markdown
|
||||||
|
filename: docs/devJournal/{{sprint_end_date}}-sprint-review.md
|
||||||
|
title: "Sprint Review: {{sprint_start_date}} - {{sprint_end_date}}"
|
||||||
|
description: |
|
||||||
|
Template for conducting comprehensive sprint reviews and retrospectives,
|
||||||
|
capturing achievements, learnings, and action items for continuous improvement.
|
||||||
|
|
||||||
|
workflow:
|
||||||
|
mode: guided
|
||||||
|
instruction: |
|
||||||
|
Conduct a thorough sprint review by gathering metrics, reviewing achievements,
|
||||||
|
facilitating retrospective, and planning improvements. Use git commands to
|
||||||
|
gather accurate metrics before starting.
|
||||||
|
|
||||||
|
sections:
|
||||||
|
- id: header
|
||||||
|
title: Sprint Review Header
|
||||||
|
instruction: Capture sprint metadata
|
||||||
|
template: |
|
||||||
|
# Sprint Review: {{sprint_start_date}} - {{sprint_end_date}}
|
||||||
|
|
||||||
|
**Sprint Name:** {{sprint_name}}
|
||||||
|
**Sprint Goal:** {{sprint_goal}}
|
||||||
|
**Duration:** {{sprint_duration}} weeks
|
||||||
|
**Date of Review:** {{review_date}}
|
||||||
|
|
||||||
|
- id: overview
|
||||||
|
title: Sprint Overview
|
||||||
|
instruction: Summarize the sprint context
|
||||||
|
template: |
|
||||||
|
## 1. Sprint Overview
|
||||||
|
|
||||||
|
- **Sprint Dates:** {{sprint_start_date}} – {{sprint_end_date}}
|
||||||
|
- **Sprint Goal:** {{sprint_goal_detailed}}
|
||||||
|
- **Participants:** {{participants}}
|
||||||
|
- **Branch/Release:** {{branch_release}}
|
||||||
|
|
||||||
|
- id: achievements
|
||||||
|
title: Achievements & Deliverables
|
||||||
|
instruction: Document what was accomplished
|
||||||
|
template: |
|
||||||
|
## 2. Achievements & Deliverables
|
||||||
|
|
||||||
|
### Major Features Completed
|
||||||
|
{{#each features_completed}}
|
||||||
|
- {{this.feature}} ({{this.pr_link}})
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### Technical Milestones
|
||||||
|
{{#each technical_milestones}}
|
||||||
|
- {{this}}
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### Documentation Updates
|
||||||
|
{{#each documentation_updates}}
|
||||||
|
- {{this}}
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### Testing & Quality
|
||||||
|
- **Tests Added:** {{tests_added}}
|
||||||
|
- **Coverage Change:** {{coverage_change}}
|
||||||
|
- **Bugs Fixed:** {{bugs_fixed}}
|
||||||
|
|
||||||
|
- id: metrics
|
||||||
|
title: Sprint Metrics
|
||||||
|
instruction: Present quantitative sprint data
|
||||||
|
template: |
|
||||||
|
## 3. Sprint Metrics
|
||||||
|
|
||||||
|
| Metric | Count | Details |
|
||||||
|
|--------|-------|---------|
|
||||||
|
| Commits | {{commit_count}} | {{commit_details}} |
|
||||||
|
| PRs Merged | {{pr_count}} | {{pr_details}} |
|
||||||
|
| Issues Closed | {{issues_closed}} | {{issue_details}} |
|
||||||
|
| Story Points Completed | {{story_points}} | {{velocity_trend}} |
|
||||||
|
|
||||||
|
### Git Activity Summary
|
||||||
|
```
|
||||||
|
{{git_summary}}
|
||||||
|
```
|
||||||
|
|
||||||
|
- id: goal-review
|
||||||
|
title: Review of Sprint Goals
|
||||||
|
instruction: Assess goal completion honestly
|
||||||
|
template: |
|
||||||
|
## 4. Review of Sprint Goals
|
||||||
|
|
||||||
|
### What Was Planned
|
||||||
|
{{sprint_planned}}
|
||||||
|
|
||||||
|
### What Was Achieved
|
||||||
|
{{sprint_achieved}}
|
||||||
|
|
||||||
|
### What Was Not Completed
|
||||||
|
{{#each incomplete_items}}
|
||||||
|
- **{{this.item}}**: {{this.reason}}
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
**Goal Completion:** {{completion_percentage}}%
|
||||||
|
|
||||||
|
- id: demo
|
||||||
|
title: Demo & Walkthrough
|
||||||
|
instruction: Provide demonstration materials if available
|
||||||
|
template: |
|
||||||
|
## 5. Demo & Walkthrough
|
||||||
|
|
||||||
|
{{#if has_screenshots}}
|
||||||
|
### Screenshots/Videos
|
||||||
|
{{demo_links}}
|
||||||
|
{{/if}}
|
||||||
|
|
||||||
|
### How to Review Features
|
||||||
|
{{review_instructions}}
|
||||||
|
|
||||||
|
- id: retrospective
|
||||||
|
title: Retrospective
|
||||||
|
instruction: Facilitate honest team reflection
|
||||||
|
template: |
|
||||||
|
## 6. Retrospective
|
||||||
|
|
||||||
|
### What Went Well 🎉
|
||||||
|
{{#each went_well}}
|
||||||
|
- {{this}}
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### What Didn't Go Well 😔
|
||||||
|
{{#each didnt_go_well}}
|
||||||
|
- {{this}}
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### What We Learned 💡
|
||||||
|
{{#each learnings}}
|
||||||
|
- {{this}}
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### What We'll Try Next 🚀
|
||||||
|
{{#each improvements}}
|
||||||
|
- {{this}}
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
- id: action-items
|
||||||
|
title: Action Items & Next Steps
|
||||||
|
instruction: Define concrete improvements
|
||||||
|
template: |
|
||||||
|
## 7. Action Items & Next Steps
|
||||||
|
|
||||||
|
| Action | Owner | Deadline | Priority |
|
||||||
|
|--------|-------|----------|----------|
|
||||||
|
{{#each action_items}}
|
||||||
|
| {{this.action}} | {{this.owner}} | {{this.deadline}} | {{this.priority}} |
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### Next Sprint Preparation
|
||||||
|
- **Next Sprint Goal:** {{next_sprint_goal}}
|
||||||
|
- **Key Focus Areas:** {{next_focus_areas}}
|
||||||
|
|
||||||
|
- id: references
|
||||||
|
title: References
|
||||||
|
instruction: Link to supporting documentation
|
||||||
|
template: |
|
||||||
|
## 8. References
|
||||||
|
|
||||||
|
### Dev Journal Entries
|
||||||
|
{{#each dev_journals}}
|
||||||
|
- [{{this.date}}]({{this.path}}) - {{this.summary}}
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### ADRs Created/Updated
|
||||||
|
{{#each adrs}}
|
||||||
|
- [{{this.number}} - {{this.title}}]({{this.path}})
|
||||||
|
{{/each}}
|
||||||
|
|
||||||
|
### Other Documentation
|
||||||
|
- [CHANGELOG.md](../../CHANGELOG.md) - {{changelog_summary}}
|
||||||
|
- [Memory Bank - Progress](../memory-bank/progress.md) - Updated with sprint outcomes
|
||||||
|
- [Memory Bank - Active Context](../memory-bank/activeContext.md) - Updated with current state
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Sprint review conducted by {{facilitator}} on {{review_date}}*
|
||||||
|
|
||||||
|
validation:
|
||||||
|
required_fields:
|
||||||
|
- sprint_start_date
|
||||||
|
- sprint_end_date
|
||||||
|
- sprint_goal
|
||||||
|
- participants
|
||||||
|
- features_completed
|
||||||
|
- went_well
|
||||||
|
- didnt_go_well
|
||||||
|
- learnings
|
||||||
|
- action_items
|
||||||
|
|
||||||
|
prompts:
|
||||||
|
# Sprint metadata
|
||||||
|
sprint_start_date: "Sprint start date (YYYY-MM-DD)"
|
||||||
|
sprint_end_date: "Sprint end date (YYYY-MM-DD)"
|
||||||
|
sprint_name: "Sprint name or number"
|
||||||
|
sprint_goal: "Brief sprint goal"
|
||||||
|
sprint_goal_detailed: "Detailed sprint goal description"
|
||||||
|
sprint_duration: "Sprint duration in weeks"
|
||||||
|
review_date: "Date of this review"
|
||||||
|
participants: "List of sprint participants"
|
||||||
|
branch_release: "Active branches or release tags"
|
||||||
|
|
||||||
|
# Achievements
|
||||||
|
features_completed: "List major features completed with PR links"
|
||||||
|
technical_milestones: "List technical achievements"
|
||||||
|
documentation_updates: "List documentation improvements"
|
||||||
|
tests_added: "Number of tests added"
|
||||||
|
coverage_change: "Test coverage change (e.g., +5%)"
|
||||||
|
bugs_fixed: "Number of bugs fixed"
|
||||||
|
|
||||||
|
# Metrics
|
||||||
|
commit_count: "Total commits in sprint"
|
||||||
|
commit_details: "Brief summary of commit types"
|
||||||
|
pr_count: "Number of PRs merged"
|
||||||
|
pr_details: "Notable PRs"
|
||||||
|
issues_closed: "Number of issues closed"
|
||||||
|
issue_details: "Types of issues resolved"
|
||||||
|
story_points: "Story points completed"
|
||||||
|
velocity_trend: "Velocity compared to previous sprints"
|
||||||
|
git_summary: "Git log summary or statistics"
|
||||||
|
|
||||||
|
# Goal review
|
||||||
|
sprint_planned: "What was originally planned for the sprint"
|
||||||
|
sprint_achieved: "Summary of what was actually achieved"
|
||||||
|
incomplete_items: "List items not completed with reasons"
|
||||||
|
completion_percentage: "Estimated percentage of goal completion"
|
||||||
|
|
||||||
|
# Demo
|
||||||
|
has_screenshots: "Are there screenshots or videos? (true/false)"
|
||||||
|
demo_links: "Links to demo materials"
|
||||||
|
review_instructions: "How to test or review the new features"
|
||||||
|
|
||||||
|
# Retrospective
|
||||||
|
went_well: "List what went well during the sprint"
|
||||||
|
didnt_go_well: "List challenges and issues"
|
||||||
|
learnings: "List key learnings and insights"
|
||||||
|
improvements: "List experiments for next sprint"
|
||||||
|
|
||||||
|
# Action items
|
||||||
|
action_items: "List action items with owner, deadline, priority"
|
||||||
|
next_sprint_goal: "Proposed goal for next sprint"
|
||||||
|
next_focus_areas: "Key areas to focus on"
|
||||||
|
|
||||||
|
# References
|
||||||
|
dev_journals: "List relevant dev journal entries"
|
||||||
|
adrs: "List ADRs created or updated"
|
||||||
|
changelog_summary: "Brief summary of CHANGELOG updates"
|
||||||
|
facilitator: "Person facilitating this review"
|
||||||
|
|
@ -12,7 +12,7 @@ workflow:
|
||||||
elicitation: advanced-elicitation
|
elicitation: advanced-elicitation
|
||||||
|
|
||||||
agent_config:
|
agent_config:
|
||||||
editable_sections:
|
editable_sections:
|
||||||
- Status
|
- Status
|
||||||
- Story
|
- Story
|
||||||
- Acceptance Criteria
|
- Acceptance Criteria
|
||||||
|
|
@ -29,7 +29,7 @@ sections:
|
||||||
instruction: Select the current status of the story
|
instruction: Select the current status of the story
|
||||||
owner: scrum-master
|
owner: scrum-master
|
||||||
editors: [scrum-master, dev-agent]
|
editors: [scrum-master, dev-agent]
|
||||||
|
|
||||||
- id: story
|
- id: story
|
||||||
title: Story
|
title: Story
|
||||||
type: template-text
|
type: template-text
|
||||||
|
|
@ -41,7 +41,7 @@ sections:
|
||||||
elicit: true
|
elicit: true
|
||||||
owner: scrum-master
|
owner: scrum-master
|
||||||
editors: [scrum-master]
|
editors: [scrum-master]
|
||||||
|
|
||||||
- id: acceptance-criteria
|
- id: acceptance-criteria
|
||||||
title: Acceptance Criteria
|
title: Acceptance Criteria
|
||||||
type: numbered-list
|
type: numbered-list
|
||||||
|
|
@ -49,7 +49,7 @@ sections:
|
||||||
elicit: true
|
elicit: true
|
||||||
owner: scrum-master
|
owner: scrum-master
|
||||||
editors: [scrum-master]
|
editors: [scrum-master]
|
||||||
|
|
||||||
- id: tasks-subtasks
|
- id: tasks-subtasks
|
||||||
title: Tasks / Subtasks
|
title: Tasks / Subtasks
|
||||||
type: bullet-list
|
type: bullet-list
|
||||||
|
|
@ -66,7 +66,7 @@ sections:
|
||||||
elicit: true
|
elicit: true
|
||||||
owner: scrum-master
|
owner: scrum-master
|
||||||
editors: [scrum-master, dev-agent]
|
editors: [scrum-master, dev-agent]
|
||||||
|
|
||||||
- id: dev-notes
|
- id: dev-notes
|
||||||
title: Dev Notes
|
title: Dev Notes
|
||||||
instruction: |
|
instruction: |
|
||||||
|
|
@ -90,7 +90,7 @@ sections:
|
||||||
elicit: true
|
elicit: true
|
||||||
owner: scrum-master
|
owner: scrum-master
|
||||||
editors: [scrum-master]
|
editors: [scrum-master]
|
||||||
|
|
||||||
- id: change-log
|
- id: change-log
|
||||||
title: Change Log
|
title: Change Log
|
||||||
type: table
|
type: table
|
||||||
|
|
@ -98,7 +98,7 @@ sections:
|
||||||
instruction: Track changes made to this story document
|
instruction: Track changes made to this story document
|
||||||
owner: scrum-master
|
owner: scrum-master
|
||||||
editors: [scrum-master, dev-agent, qa-agent]
|
editors: [scrum-master, dev-agent, qa-agent]
|
||||||
|
|
||||||
- id: dev-agent-record
|
- id: dev-agent-record
|
||||||
title: Dev Agent Record
|
title: Dev Agent Record
|
||||||
instruction: This section is populated by the development agent during implementation
|
instruction: This section is populated by the development agent during implementation
|
||||||
|
|
@ -111,27 +111,27 @@ sections:
|
||||||
instruction: Record the specific AI agent model and version used for development
|
instruction: Record the specific AI agent model and version used for development
|
||||||
owner: dev-agent
|
owner: dev-agent
|
||||||
editors: [dev-agent]
|
editors: [dev-agent]
|
||||||
|
|
||||||
- id: debug-log-references
|
- id: debug-log-references
|
||||||
title: Debug Log References
|
title: Debug Log References
|
||||||
instruction: Reference any debug logs or traces generated during development
|
instruction: Reference any debug logs or traces generated during development
|
||||||
owner: dev-agent
|
owner: dev-agent
|
||||||
editors: [dev-agent]
|
editors: [dev-agent]
|
||||||
|
|
||||||
- id: completion-notes
|
- id: completion-notes
|
||||||
title: Completion Notes List
|
title: Completion Notes List
|
||||||
instruction: Notes about the completion of tasks and any issues encountered
|
instruction: Notes about the completion of tasks and any issues encountered
|
||||||
owner: dev-agent
|
owner: dev-agent
|
||||||
editors: [dev-agent]
|
editors: [dev-agent]
|
||||||
|
|
||||||
- id: file-list
|
- id: file-list
|
||||||
title: File List
|
title: File List
|
||||||
instruction: List all files created, modified, or affected during story implementation
|
instruction: List all files created, modified, or affected during story implementation
|
||||||
owner: dev-agent
|
owner: dev-agent
|
||||||
editors: [dev-agent]
|
editors: [dev-agent]
|
||||||
|
|
||||||
- id: qa-results
|
- id: qa-results
|
||||||
title: QA Results
|
title: QA Results
|
||||||
instruction: Results from QA Agent QA review of the completed story implementation
|
instruction: Results from QA Agent QA review of the completed story implementation
|
||||||
owner: qa-agent
|
owner: qa-agent
|
||||||
editors: [qa-agent]
|
editors: [qa-agent]
|
||||||
|
|
|
||||||
|
|
@ -242,4 +242,4 @@ prompts:
|
||||||
sli_slo: "Service level indicators and objectives"
|
sli_slo: "Service level indicators and objectives"
|
||||||
log_levels: "When to use each log level"
|
log_levels: "When to use each log level"
|
||||||
structured_logging_format: "Log format and fields"
|
structured_logging_format: "Log format and fields"
|
||||||
log_retention: "How long are logs kept?"
|
log_retention: "How long are logs kept?"
|
||||||
|
|
|
||||||
|
|
@ -261,4 +261,4 @@ prompts:
|
||||||
db_maintenance_tasks: "Database maintenance tasks"
|
db_maintenance_tasks: "Database maintenance tasks"
|
||||||
log_rotation_policy: "Log rotation policy"
|
log_rotation_policy: "Log rotation policy"
|
||||||
monitoring_alerts: "List monitoring alerts with thresholds"
|
monitoring_alerts: "List monitoring alerts with thresholds"
|
||||||
limitations: "List known limitations and workarounds"
|
limitations: "List known limitations and workarounds"
|
||||||
|
|
|
||||||
|
|
@ -238,6 +238,98 @@ You will want to verify from sharding your architecture that these documents exi
|
||||||
|
|
||||||
As your project grows and the code starts to build consistent patterns, coding standards should be reduced to just the items that the agent makes mistakes at still - must with the better models, they will look at surrounding code in files and not need a rule from that file to guide them.
|
As your project grows and the code starts to build consistent patterns, coding standards should be reduced to just the items that the agent makes mistakes at still - must with the better models, they will look at surrounding code in files and not need a rule from that file to guide them.
|
||||||
|
|
||||||
|
## Enhanced BMad Features
|
||||||
|
|
||||||
|
### Session Kickoff Protocol
|
||||||
|
|
||||||
|
Every new AI session should begin with proper context initialization:
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[New Session Start] --> B[bmad-master: session-kickoff]
|
||||||
|
B --> C[Review Memory Bank]
|
||||||
|
C --> D[Check Dev Journals]
|
||||||
|
D --> E[Review Recent ADRs]
|
||||||
|
E --> F[Load Technical Principles]
|
||||||
|
F --> G[Session Ready]
|
||||||
|
|
||||||
|
style A fill:#f5f5f5
|
||||||
|
style B fill:#FF6B6B
|
||||||
|
style C fill:#DDA0DD
|
||||||
|
style D fill:#FFE4B5
|
||||||
|
style E fill:#ADD8E6
|
||||||
|
style F fill:#98FB98
|
||||||
|
style G fill:#90EE90
|
||||||
|
```
|
||||||
|
|
||||||
|
**When to use**: Start of any new session, after 24+ hour gaps, or when switching contexts.
|
||||||
|
|
||||||
|
### Memory Bank Pattern
|
||||||
|
|
||||||
|
The Memory Bank provides persistent context across AI sessions:
|
||||||
|
|
||||||
|
- **Location**: `docs/memory-bank/`
|
||||||
|
- **Core Files**:
|
||||||
|
- `projectbrief.md` - Project foundation and goals
|
||||||
|
- `productContext.md` - User needs and problems
|
||||||
|
- `systemPatterns.md` - Architecture and patterns
|
||||||
|
- `techContext.md` - Technology stack
|
||||||
|
- `activeContext.md` - Current work state
|
||||||
|
- `progress.md` - Completed features and status
|
||||||
|
|
||||||
|
**Integration**: All agents automatically reference Memory Bank during session kickoff.
|
||||||
|
|
||||||
|
### Development Journals
|
||||||
|
|
||||||
|
Track session work and decisions:
|
||||||
|
|
||||||
|
- **Location**: `docs/devJournal/`
|
||||||
|
- **Format**: `YYYYMMDD-NN.md` (e.g., `20240115-01.md`)
|
||||||
|
- **Created**: After significant work sessions
|
||||||
|
- **Contents**: Work completed, decisions made, challenges faced
|
||||||
|
|
||||||
|
### Architectural Decision Records (ADRs)
|
||||||
|
|
||||||
|
Document significant technical decisions:
|
||||||
|
|
||||||
|
- **Location**: `docs/adr/`
|
||||||
|
- **Format**: Michael Nygard ADR format
|
||||||
|
- **Triggers**: Major architecture changes, new patterns, technology choices
|
||||||
|
- **Integration**: Automatically referenced in Memory Bank
|
||||||
|
|
||||||
|
### Sprint Ceremonies
|
||||||
|
|
||||||
|
BMad now includes full sprint support:
|
||||||
|
|
||||||
|
1. **Sprint Planning**: Integrated into all workflows after validation
|
||||||
|
2. **Daily Development**: Tracked through dev journals
|
||||||
|
3. **Sprint Review**: Comprehensive review using `sprint-review-checklist.md`
|
||||||
|
4. **Retrospectives**: Optional but recommended for continuous improvement
|
||||||
|
|
||||||
|
### New Specialized Workflows
|
||||||
|
|
||||||
|
Beyond the standard development workflows, BMad now includes:
|
||||||
|
|
||||||
|
- **sprint-execution.yaml**: Full sprint-based agile development
|
||||||
|
- **quick-fix.yaml**: Streamlined hotfix process
|
||||||
|
- **technical-debt.yaml**: Systematic debt reduction
|
||||||
|
- **documentation-update.yaml**: Documentation maintenance
|
||||||
|
- **system-migration.yaml**: Platform and technology migrations
|
||||||
|
- **performance-optimization.yaml**: Performance improvement cycles
|
||||||
|
|
||||||
|
### Quality Gates
|
||||||
|
|
||||||
|
All workflows now include 8-step validation:
|
||||||
|
|
||||||
|
1. Syntax validation
|
||||||
|
2. Type checking
|
||||||
|
3. Linting
|
||||||
|
4. Security scanning
|
||||||
|
5. Test execution
|
||||||
|
6. Performance validation
|
||||||
|
7. Documentation checks
|
||||||
|
8. Integration testing
|
||||||
|
|
||||||
## Getting Help
|
## Getting Help
|
||||||
|
|
||||||
- **Discord Community**: [Join Discord](https://discord.gg/gk8jAdXWmj)
|
- **Discord Community**: [Join Discord](https://discord.gg/gk8jAdXWmj)
|
||||||
|
|
|
||||||
|
|
@ -12,6 +12,18 @@ workflow:
|
||||||
- integration-enhancement
|
- integration-enhancement
|
||||||
|
|
||||||
sequence:
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Initialize AI session context:
|
||||||
|
- Review Memory Bank if exists
|
||||||
|
- Understand project state and technical principles
|
||||||
|
- Check recent dev journals and ADRs
|
||||||
|
- Review sprint context if applicable
|
||||||
|
Required for new sessions or after 24+ hour gaps
|
||||||
|
|
||||||
- step: enhancement_classification
|
- step: enhancement_classification
|
||||||
agent: analyst
|
agent: analyst
|
||||||
action: classify enhancement scope
|
action: classify enhancement scope
|
||||||
|
|
@ -20,7 +32,7 @@ workflow:
|
||||||
- Single story (< 4 hours) → Use brownfield-create-story task
|
- Single story (< 4 hours) → Use brownfield-create-story task
|
||||||
- Small feature (1-3 stories) → Use brownfield-create-epic task
|
- Small feature (1-3 stories) → Use brownfield-create-epic task
|
||||||
- Major enhancement (multiple epics) → Continue with full workflow
|
- Major enhancement (multiple epics) → Continue with full workflow
|
||||||
|
|
||||||
Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?"
|
Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?"
|
||||||
|
|
||||||
- step: routing_decision
|
- step: routing_decision
|
||||||
|
|
@ -93,6 +105,17 @@ workflow:
|
||||||
condition: po_checklist_issues
|
condition: po_checklist_issues
|
||||||
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||||
|
|
||||||
|
- step: sprint_planning_check
|
||||||
|
agent: sm
|
||||||
|
action: verify_sprint_context
|
||||||
|
condition: development_ready
|
||||||
|
notes: |
|
||||||
|
If part of sprint:
|
||||||
|
- Align with sprint goals
|
||||||
|
- Update sprint backlog
|
||||||
|
- Plan for sprint review
|
||||||
|
- Create ADRs for significant decisions
|
||||||
|
|
||||||
- agent: po
|
- agent: po
|
||||||
action: shard_documents
|
action: shard_documents
|
||||||
creates: sharded_docs
|
creates: sharded_docs
|
||||||
|
|
@ -159,6 +182,19 @@ workflow:
|
||||||
- Dev Agent (New Chat): Address remaining items
|
- Dev Agent (New Chat): Address remaining items
|
||||||
- Return to QA for final approval
|
- Return to QA for final approval
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_session_work
|
||||||
|
uses: create-dev-journal
|
||||||
|
condition: significant_work_completed
|
||||||
|
notes: |
|
||||||
|
Create dev journal for:
|
||||||
|
- Major feature completion
|
||||||
|
- Complex problem solutions
|
||||||
|
- Architectural decisions (trigger ADR creation)
|
||||||
|
- End of work session
|
||||||
|
Updates Memory Bank activeContext
|
||||||
|
|
||||||
- repeat_development_cycle:
|
- repeat_development_cycle:
|
||||||
action: continue_for_all_stories
|
action: continue_for_all_stories
|
||||||
notes: |
|
notes: |
|
||||||
|
|
@ -176,18 +212,32 @@ workflow:
|
||||||
- Validate epic was completed correctly
|
- Validate epic was completed correctly
|
||||||
- Document learnings and improvements
|
- Document learnings and improvements
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: conduct_sprint_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
condition: sprint_boundary
|
||||||
|
notes: |
|
||||||
|
At sprint end:
|
||||||
|
- Review accomplishments using sprint-review-checklist
|
||||||
|
- Document learnings and technical decisions
|
||||||
|
- Update Memory Bank comprehensively
|
||||||
|
- Create sprint summary documentation
|
||||||
|
- Plan next sprint priorities
|
||||||
|
|
||||||
- workflow_end:
|
- workflow_end:
|
||||||
action: project_complete
|
action: project_complete
|
||||||
notes: |
|
notes: |
|
||||||
All stories implemented and reviewed!
|
All stories implemented and reviewed!
|
||||||
Project development phase complete.
|
Project development phase complete.
|
||||||
|
Memory Bank and documentation updated.
|
||||||
|
|
||||||
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
||||||
|
|
||||||
flow_diagram: |
|
flow_diagram: |
|
||||||
```mermaid
|
```mermaid
|
||||||
graph TD
|
graph TD
|
||||||
A[Start: Brownfield Enhancement] --> B[analyst: classify enhancement scope]
|
A[Start: Brownfield Enhancement] --> A1[bmad-master: session kickoff]
|
||||||
|
A1 --> B[analyst: classify enhancement scope]
|
||||||
B --> C{Enhancement Size?}
|
B --> C{Enhancement Size?}
|
||||||
|
|
||||||
C -->|Single Story| D[pm: brownfield-create-story]
|
C -->|Single Story| D[pm: brownfield-create-story]
|
||||||
|
|
@ -209,8 +259,9 @@ workflow:
|
||||||
|
|
||||||
L --> M{PO finds issues?}
|
L --> M{PO finds issues?}
|
||||||
M -->|Yes| N[Fix issues]
|
M -->|Yes| N[Fix issues]
|
||||||
M -->|No| O[po: shard documents]
|
M -->|No| SP[sm: sprint planning]
|
||||||
N --> L
|
N --> L
|
||||||
|
SP --> O[po: shard documents]
|
||||||
|
|
||||||
O --> P[sm: create story]
|
O --> P[sm: create story]
|
||||||
P --> Q{Story Type?}
|
P --> Q{Story Type?}
|
||||||
|
|
@ -231,10 +282,14 @@ workflow:
|
||||||
Z -->|No| Y
|
Z -->|No| Y
|
||||||
AA --> X
|
AA --> X
|
||||||
Y -->|Yes| P
|
Y -->|Yes| P
|
||||||
Y -->|No| AB{Retrospective?}
|
Y -->|No| DJ[dev: dev journal]
|
||||||
|
DJ --> AB{Retrospective?}
|
||||||
AB -->|Yes| AC[po: retrospective]
|
AB -->|Yes| AC[po: retrospective]
|
||||||
AB -->|No| AD[Complete]
|
AB -->|No| SR{Sprint boundary?}
|
||||||
AC --> AD
|
AC --> SR
|
||||||
|
SR -->|Yes| SRV[sm: sprint review]
|
||||||
|
SR -->|No| AD[Complete]
|
||||||
|
SRV --> AD
|
||||||
|
|
||||||
style AD fill:#90EE90
|
style AD fill:#90EE90
|
||||||
style END1 fill:#90EE90
|
style END1 fill:#90EE90
|
||||||
|
|
@ -265,33 +320,33 @@ workflow:
|
||||||
{{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation.
|
{{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation.
|
||||||
{{if small_feature}}: Creating focused epic with brownfield-create-epic task.
|
{{if small_feature}}: Creating focused epic with brownfield-create-epic task.
|
||||||
{{if major_enhancement}}: Continuing with comprehensive planning workflow.
|
{{if major_enhancement}}: Continuing with comprehensive planning workflow.
|
||||||
|
|
||||||
documentation_assessment: |
|
documentation_assessment: |
|
||||||
Documentation assessment complete:
|
Documentation assessment complete:
|
||||||
{{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation.
|
{{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation.
|
||||||
{{if inadequate}}: Running document-project to capture current system state before PRD.
|
{{if inadequate}}: Running document-project to capture current system state before PRD.
|
||||||
|
|
||||||
document_project_to_pm: |
|
document_project_to_pm: |
|
||||||
Project analysis complete. Key findings documented in:
|
Project analysis complete. Key findings documented in:
|
||||||
- {{document_list}}
|
- {{document_list}}
|
||||||
Use these findings to inform PRD creation and avoid re-analyzing the same aspects.
|
Use these findings to inform PRD creation and avoid re-analyzing the same aspects.
|
||||||
|
|
||||||
pm_to_architect_decision: |
|
pm_to_architect_decision: |
|
||||||
PRD complete and saved as docs/prd.md.
|
PRD complete and saved as docs/prd.md.
|
||||||
Architectural changes identified: {{yes/no}}
|
Architectural changes identified: {{yes/no}}
|
||||||
{{if yes}}: Proceeding to create architecture document for: {{specific_changes}}
|
{{if yes}}: Proceeding to create architecture document for: {{specific_changes}}
|
||||||
{{if no}}: No architectural changes needed. Proceeding to validation.
|
{{if no}}: No architectural changes needed. Proceeding to validation.
|
||||||
|
|
||||||
architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety."
|
architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety."
|
||||||
|
|
||||||
po_to_sm: |
|
po_to_sm: |
|
||||||
All artifacts validated.
|
All artifacts validated.
|
||||||
Documentation type available: {{sharded_prd / brownfield_docs}}
|
Documentation type available: {{sharded_prd / brownfield_docs}}
|
||||||
{{if sharded}}: Use standard create-next-story task.
|
{{if sharded}}: Use standard create-next-story task.
|
||||||
{{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats.
|
{{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats.
|
||||||
|
|
||||||
sm_story_creation: |
|
sm_story_creation: |
|
||||||
Creating story from {{documentation_type}}.
|
Creating story from {{documentation_type}}.
|
||||||
{{if missing_context}}: May need to gather additional context from user during story creation.
|
{{if missing_context}}: May need to gather additional context from user during story creation.
|
||||||
|
|
||||||
complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format."
|
complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format."
|
||||||
|
|
|
||||||
|
|
@ -13,6 +13,18 @@ workflow:
|
||||||
- integration-enhancement
|
- integration-enhancement
|
||||||
|
|
||||||
sequence:
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Initialize AI session context:
|
||||||
|
- Review Memory Bank if exists
|
||||||
|
- Understand service architecture and dependencies
|
||||||
|
- Check recent dev journals and ADRs
|
||||||
|
- Review technical principles and patterns
|
||||||
|
Required for new sessions or after 24+ hour gaps
|
||||||
|
|
||||||
- step: service_analysis
|
- step: service_analysis
|
||||||
agent: architect
|
agent: architect
|
||||||
action: analyze existing project and use task document-project
|
action: analyze existing project and use task document-project
|
||||||
|
|
@ -41,6 +53,17 @@ workflow:
|
||||||
condition: po_checklist_issues
|
condition: po_checklist_issues
|
||||||
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||||
|
|
||||||
|
- step: sprint_planning_check
|
||||||
|
agent: sm
|
||||||
|
action: verify_sprint_context
|
||||||
|
condition: development_ready
|
||||||
|
notes: |
|
||||||
|
If part of sprint:
|
||||||
|
- Align service enhancements with sprint goals
|
||||||
|
- Update sprint backlog
|
||||||
|
- Plan for sprint review
|
||||||
|
- Create ADRs for API changes
|
||||||
|
|
||||||
- agent: po
|
- agent: po
|
||||||
action: shard_documents
|
action: shard_documents
|
||||||
creates: sharded_docs
|
creates: sharded_docs
|
||||||
|
|
@ -105,6 +128,19 @@ workflow:
|
||||||
- Dev Agent (New Chat): Address remaining items
|
- Dev Agent (New Chat): Address remaining items
|
||||||
- Return to QA for final approval
|
- Return to QA for final approval
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_session_work
|
||||||
|
uses: create-dev-journal
|
||||||
|
condition: significant_work_completed
|
||||||
|
notes: |
|
||||||
|
Create dev journal for:
|
||||||
|
- API changes and integration updates
|
||||||
|
- Performance improvements
|
||||||
|
- Service architecture decisions (trigger ADR)
|
||||||
|
- End of work session
|
||||||
|
Updates Memory Bank systemPatterns
|
||||||
|
|
||||||
- repeat_development_cycle:
|
- repeat_development_cycle:
|
||||||
action: continue_for_all_stories
|
action: continue_for_all_stories
|
||||||
notes: |
|
notes: |
|
||||||
|
|
@ -122,25 +158,40 @@ workflow:
|
||||||
- Validate epic was completed correctly
|
- Validate epic was completed correctly
|
||||||
- Document learnings and improvements
|
- Document learnings and improvements
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: conduct_sprint_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
condition: sprint_boundary
|
||||||
|
notes: |
|
||||||
|
At sprint end:
|
||||||
|
- Review service enhancements and API changes
|
||||||
|
- Document performance improvements
|
||||||
|
- Update Memory Bank with architectural decisions
|
||||||
|
- Create sprint summary with metrics
|
||||||
|
- Plan next sprint priorities
|
||||||
|
|
||||||
- workflow_end:
|
- workflow_end:
|
||||||
action: project_complete
|
action: project_complete
|
||||||
notes: |
|
notes: |
|
||||||
All stories implemented and reviewed!
|
All stories implemented and reviewed!
|
||||||
Project development phase complete.
|
Service development phase complete.
|
||||||
|
Memory Bank and API documentation updated.
|
||||||
|
|
||||||
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
||||||
|
|
||||||
flow_diagram: |
|
flow_diagram: |
|
||||||
```mermaid
|
```mermaid
|
||||||
graph TD
|
graph TD
|
||||||
A[Start: Service Enhancement] --> B[analyst: analyze existing service]
|
A[Start: Service Enhancement] --> A1[bmad-master: session kickoff]
|
||||||
|
A1 --> B[architect: analyze existing service]
|
||||||
B --> C[pm: prd.md]
|
B --> C[pm: prd.md]
|
||||||
C --> D[architect: architecture.md]
|
C --> D[architect: architecture.md]
|
||||||
D --> E[po: validate with po-master-checklist]
|
D --> E[po: validate with po-master-checklist]
|
||||||
E --> F{PO finds issues?}
|
E --> F{PO finds issues?}
|
||||||
F -->|Yes| G[Return to relevant agent for fixes]
|
F -->|Yes| G[Return to relevant agent for fixes]
|
||||||
F -->|No| H[po: shard documents]
|
F -->|No| SP[sm: sprint planning]
|
||||||
G --> E
|
G --> E
|
||||||
|
SP --> H[po: shard documents]
|
||||||
|
|
||||||
H --> I[sm: create story]
|
H --> I[sm: create story]
|
||||||
I --> J{Review draft story?}
|
I --> J{Review draft story?}
|
||||||
|
|
@ -155,10 +206,14 @@ workflow:
|
||||||
P -->|No| O
|
P -->|No| O
|
||||||
Q --> N
|
Q --> N
|
||||||
O -->|Yes| I
|
O -->|Yes| I
|
||||||
O -->|No| R{Epic retrospective?}
|
O -->|No| DJ[dev: dev journal]
|
||||||
|
DJ --> R{Epic retrospective?}
|
||||||
R -->|Yes| S[po: epic retrospective]
|
R -->|Yes| S[po: epic retrospective]
|
||||||
R -->|No| T[Project Complete]
|
R -->|No| SR{Sprint boundary?}
|
||||||
S --> T
|
S --> SR
|
||||||
|
SR -->|Yes| SRV[sm: sprint review]
|
||||||
|
SR -->|No| T[Project Complete]
|
||||||
|
SRV --> T
|
||||||
|
|
||||||
style T fill:#90EE90
|
style T fill:#90EE90
|
||||||
style H fill:#ADD8E6
|
style H fill:#ADD8E6
|
||||||
|
|
|
||||||
|
|
@ -12,6 +12,18 @@ workflow:
|
||||||
- frontend-enhancement
|
- frontend-enhancement
|
||||||
|
|
||||||
sequence:
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Initialize AI session context:
|
||||||
|
- Review Memory Bank if exists
|
||||||
|
- Understand project state and technical principles
|
||||||
|
- Check recent dev journals and ADRs
|
||||||
|
- Review sprint context if applicable
|
||||||
|
Required for new sessions or after 24+ hour gaps
|
||||||
|
|
||||||
- step: ui_analysis
|
- step: ui_analysis
|
||||||
agent: architect
|
agent: architect
|
||||||
action: analyze existing project and use task document-project
|
action: analyze existing project and use task document-project
|
||||||
|
|
@ -48,6 +60,17 @@ workflow:
|
||||||
condition: po_checklist_issues
|
condition: po_checklist_issues
|
||||||
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||||
|
|
||||||
|
- step: sprint_planning_check
|
||||||
|
agent: sm
|
||||||
|
action: verify_sprint_context
|
||||||
|
condition: development_ready
|
||||||
|
notes: |
|
||||||
|
If part of sprint:
|
||||||
|
- Align with sprint goals
|
||||||
|
- Update sprint backlog
|
||||||
|
- Plan for sprint review
|
||||||
|
- Create ADRs for significant UI/UX decisions
|
||||||
|
|
||||||
- agent: po
|
- agent: po
|
||||||
action: shard_documents
|
action: shard_documents
|
||||||
creates: sharded_docs
|
creates: sharded_docs
|
||||||
|
|
@ -112,6 +135,19 @@ workflow:
|
||||||
- Dev Agent (New Chat): Address remaining items
|
- Dev Agent (New Chat): Address remaining items
|
||||||
- Return to QA for final approval
|
- Return to QA for final approval
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_session_work
|
||||||
|
uses: create-dev-journal
|
||||||
|
condition: significant_work_completed
|
||||||
|
notes: |
|
||||||
|
Create dev journal for:
|
||||||
|
- Major UI component completion
|
||||||
|
- Complex frontend problem solutions
|
||||||
|
- UI/UX architectural decisions (trigger ADR creation)
|
||||||
|
- End of work session
|
||||||
|
Updates Memory Bank activeContext
|
||||||
|
|
||||||
- repeat_development_cycle:
|
- repeat_development_cycle:
|
||||||
action: continue_for_all_stories
|
action: continue_for_all_stories
|
||||||
notes: |
|
notes: |
|
||||||
|
|
@ -129,26 +165,40 @@ workflow:
|
||||||
- Validate epic was completed correctly
|
- Validate epic was completed correctly
|
||||||
- Document learnings and improvements
|
- Document learnings and improvements
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: conduct_sprint_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
condition: sprint_boundary
|
||||||
|
notes: |
|
||||||
|
At sprint end:
|
||||||
|
- Review UI enhancement accomplishments using sprint-review-checklist
|
||||||
|
- Document UI/UX learnings and design decisions
|
||||||
|
- Update Memory Bank comprehensively
|
||||||
|
- Create sprint summary documentation
|
||||||
|
- Plan next sprint UI priorities
|
||||||
|
|
||||||
- workflow_end:
|
- workflow_end:
|
||||||
action: project_complete
|
action: project_complete
|
||||||
notes: |
|
notes: |
|
||||||
All stories implemented and reviewed!
|
All stories implemented and reviewed!
|
||||||
Project development phase complete.
|
Project development phase complete.
|
||||||
|
|
||||||
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
||||||
|
|
||||||
flow_diagram: |
|
flow_diagram: |
|
||||||
```mermaid
|
```mermaid
|
||||||
graph TD
|
graph TD
|
||||||
A[Start: UI Enhancement] --> B[analyst: analyze existing UI]
|
A[Start: UI Enhancement] --> A1[bmad-master: session kickoff]
|
||||||
|
A1 --> B[analyst: analyze existing UI]
|
||||||
B --> C[pm: prd.md]
|
B --> C[pm: prd.md]
|
||||||
C --> D[ux-expert: front-end-spec.md]
|
C --> D[ux-expert: front-end-spec.md]
|
||||||
D --> E[architect: architecture.md]
|
D --> E[architect: architecture.md]
|
||||||
E --> F[po: validate with po-master-checklist]
|
E --> F[po: validate with po-master-checklist]
|
||||||
F --> G{PO finds issues?}
|
F --> G{PO finds issues?}
|
||||||
G -->|Yes| H[Return to relevant agent for fixes]
|
G -->|Yes| H[Return to relevant agent for fixes]
|
||||||
G -->|No| I[po: shard documents]
|
G -->|No| SP[sm: sprint planning]
|
||||||
H --> F
|
H --> F
|
||||||
|
SP --> I[po: shard documents]
|
||||||
|
|
||||||
I --> J[sm: create story]
|
I --> J[sm: create story]
|
||||||
J --> K{Review draft story?}
|
J --> K{Review draft story?}
|
||||||
|
|
@ -157,16 +207,20 @@ workflow:
|
||||||
L --> M
|
L --> M
|
||||||
M --> N{QA review?}
|
M --> N{QA review?}
|
||||||
N -->|Yes| O[qa: review implementation]
|
N -->|Yes| O[qa: review implementation]
|
||||||
N -->|No| P{More stories?}
|
N -->|No| DJ[dev: dev journal]
|
||||||
O --> Q{QA found issues?}
|
O --> Q{QA found issues?}
|
||||||
Q -->|Yes| R[dev: address QA feedback]
|
Q -->|Yes| R[dev: address QA feedback]
|
||||||
Q -->|No| P
|
Q -->|No| DJ
|
||||||
R --> O
|
R --> O
|
||||||
|
DJ --> P{More stories?}
|
||||||
P -->|Yes| J
|
P -->|Yes| J
|
||||||
P -->|No| S{Epic retrospective?}
|
P -->|No| S{Epic retrospective?}
|
||||||
S -->|Yes| T[po: epic retrospective]
|
S -->|Yes| T[po: epic retrospective]
|
||||||
S -->|No| U[Project Complete]
|
S -->|No| SR{Sprint boundary?}
|
||||||
T --> U
|
T --> SR
|
||||||
|
SR -->|Yes| SRV[sm: sprint review]
|
||||||
|
SR -->|No| U[Project Complete]
|
||||||
|
SRV --> U
|
||||||
|
|
||||||
style U fill:#90EE90
|
style U fill:#90EE90
|
||||||
style I fill:#ADD8E6
|
style I fill:#ADD8E6
|
||||||
|
|
@ -178,6 +232,10 @@ workflow:
|
||||||
style L fill:#F0E68C
|
style L fill:#F0E68C
|
||||||
style O fill:#F0E68C
|
style O fill:#F0E68C
|
||||||
style T fill:#F0E68C
|
style T fill:#F0E68C
|
||||||
|
style A1 fill:#E6E6FA
|
||||||
|
style SP fill:#E6E6FA
|
||||||
|
style DJ fill:#E6E6FA
|
||||||
|
style SRV fill:#E6E6FA
|
||||||
```
|
```
|
||||||
|
|
||||||
decision_guidance:
|
decision_guidance:
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,287 @@
|
||||||
|
workflow:
|
||||||
|
id: documentation-update
|
||||||
|
name: Documentation Update Workflow
|
||||||
|
description: >-
|
||||||
|
Agent workflow for systematic documentation creation and updates. Handles
|
||||||
|
API documentation, user guides, architectural documentation, and knowledge
|
||||||
|
base maintenance with focus on accuracy and completeness.
|
||||||
|
type: documentation
|
||||||
|
project_types:
|
||||||
|
- api-documentation
|
||||||
|
- user-guides
|
||||||
|
- developer-docs
|
||||||
|
- architecture-docs
|
||||||
|
- knowledge-base
|
||||||
|
|
||||||
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Documentation context initialization:
|
||||||
|
- Review Memory Bank for current state
|
||||||
|
- Check existing documentation
|
||||||
|
- Understand system architecture
|
||||||
|
- Review recent changes
|
||||||
|
- Identify documentation standards
|
||||||
|
|
||||||
|
- agent: analyst
|
||||||
|
action: documentation_audit
|
||||||
|
creates: doc-audit-report.md
|
||||||
|
notes: |
|
||||||
|
Comprehensive documentation audit:
|
||||||
|
- Inventory existing documentation
|
||||||
|
- Identify gaps and outdated content
|
||||||
|
- Check accuracy against current code
|
||||||
|
- Review user feedback on docs
|
||||||
|
- Assess documentation coverage
|
||||||
|
- List priority areas
|
||||||
|
|
||||||
|
- agent: pm
|
||||||
|
action: documentation_planning
|
||||||
|
creates: doc-update-plan.md
|
||||||
|
requires: doc-audit-report.md
|
||||||
|
notes: |
|
||||||
|
Create documentation plan:
|
||||||
|
- Prioritize documentation needs
|
||||||
|
- Define target audiences
|
||||||
|
- Set documentation standards
|
||||||
|
- Create content outline
|
||||||
|
- Estimate effort required
|
||||||
|
- Plan review cycles
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: technical_content_planning
|
||||||
|
creates: technical-doc-outline.md
|
||||||
|
condition: technical_documentation
|
||||||
|
notes: |
|
||||||
|
Technical documentation planning:
|
||||||
|
- Architecture diagrams needed
|
||||||
|
- API specifications to document
|
||||||
|
- Integration guides required
|
||||||
|
- Performance documentation
|
||||||
|
- Security documentation
|
||||||
|
- Deployment guides
|
||||||
|
|
||||||
|
- agent: ux-expert
|
||||||
|
action: user_documentation_planning
|
||||||
|
creates: user-doc-outline.md
|
||||||
|
condition: user_documentation
|
||||||
|
notes: |
|
||||||
|
User documentation planning:
|
||||||
|
- User journey mapping
|
||||||
|
- Tutorial structure
|
||||||
|
- FAQ compilation
|
||||||
|
- Troubleshooting guides
|
||||||
|
- Quick start guides
|
||||||
|
- Video script outlines
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
validates: documentation_plan
|
||||||
|
notes: |
|
||||||
|
Validate documentation approach:
|
||||||
|
- Confirm priorities align
|
||||||
|
- Approve resource allocation
|
||||||
|
- Sign off on timelines
|
||||||
|
- Verify compliance needs
|
||||||
|
|
||||||
|
- documentation_cycle:
|
||||||
|
repeats: for_each_doc_section
|
||||||
|
sequence:
|
||||||
|
- agent: scribe
|
||||||
|
action: create_documentation
|
||||||
|
creates: documentation_files
|
||||||
|
notes: |
|
||||||
|
Content creation:
|
||||||
|
- Write clear, concise content
|
||||||
|
- Follow style guide
|
||||||
|
- Include code examples
|
||||||
|
- Add diagrams where helpful
|
||||||
|
- Ensure accuracy
|
||||||
|
- Consider localization
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: technical_review
|
||||||
|
validates: technical_accuracy
|
||||||
|
condition: technical_content
|
||||||
|
notes: |
|
||||||
|
Technical validation:
|
||||||
|
- Verify code examples work
|
||||||
|
- Check API accuracy
|
||||||
|
- Validate architecture diagrams
|
||||||
|
- Ensure version compatibility
|
||||||
|
- Review security implications
|
||||||
|
|
||||||
|
- agent: qa
|
||||||
|
action: documentation_testing
|
||||||
|
validates: documentation_usability
|
||||||
|
notes: |
|
||||||
|
Documentation QA:
|
||||||
|
- Test all code examples
|
||||||
|
- Verify links work
|
||||||
|
- Check formatting
|
||||||
|
- Validate screenshots
|
||||||
|
- Test tutorials end-to-end
|
||||||
|
- Accessibility review
|
||||||
|
|
||||||
|
- agent: mentor
|
||||||
|
action: educational_review
|
||||||
|
validates: learning_effectiveness
|
||||||
|
optional: true
|
||||||
|
notes: |
|
||||||
|
Educational quality:
|
||||||
|
- Check clarity for beginners
|
||||||
|
- Verify learning progression
|
||||||
|
- Assess completeness
|
||||||
|
- Review examples
|
||||||
|
- Suggest improvements
|
||||||
|
|
||||||
|
- agent: scribe
|
||||||
|
action: create_documentation_index
|
||||||
|
creates: documentation-index.md
|
||||||
|
notes: |
|
||||||
|
Create navigation aids:
|
||||||
|
- Table of contents
|
||||||
|
- Cross-references
|
||||||
|
- Search keywords
|
||||||
|
- Category tags
|
||||||
|
- Version mapping
|
||||||
|
- Related resources
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: integrate_documentation
|
||||||
|
updates: project_documentation
|
||||||
|
notes: |
|
||||||
|
Documentation integration:
|
||||||
|
- Update README files
|
||||||
|
- Link from code comments
|
||||||
|
- Update help systems
|
||||||
|
- Deploy to doc sites
|
||||||
|
- Configure search
|
||||||
|
- Set up redirects
|
||||||
|
|
||||||
|
- agent: scribe
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_doc_updates
|
||||||
|
uses: create-dev-journal
|
||||||
|
notes: |
|
||||||
|
Document the documentation:
|
||||||
|
- What was updated and why
|
||||||
|
- Major changes made
|
||||||
|
- Known gaps remaining
|
||||||
|
- Feedback incorporated
|
||||||
|
- Update Memory Bank
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
action: documentation_acceptance
|
||||||
|
validates: final_documentation
|
||||||
|
notes: |
|
||||||
|
Final documentation review:
|
||||||
|
- Verify completeness
|
||||||
|
- Check quality standards
|
||||||
|
- Approve for publication
|
||||||
|
- Sign off on release
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: documentation_release
|
||||||
|
creates: doc-release-notes.md
|
||||||
|
notes: |
|
||||||
|
Documentation release:
|
||||||
|
- Publish updates
|
||||||
|
- Notify stakeholders
|
||||||
|
- Update version notes
|
||||||
|
- Plan maintenance cycle
|
||||||
|
- Schedule next review
|
||||||
|
|
||||||
|
- workflow_end:
|
||||||
|
action: documentation_complete
|
||||||
|
notes: |
|
||||||
|
Documentation updated!
|
||||||
|
- All sections complete
|
||||||
|
- Quality validated
|
||||||
|
- Published and indexed
|
||||||
|
- Memory Bank updated
|
||||||
|
- Maintenance scheduled
|
||||||
|
|
||||||
|
flow_diagram: |
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[Start: Documentation] --> B[bmad-master: session init]
|
||||||
|
B --> C[analyst: audit docs]
|
||||||
|
C --> D[pm: create plan]
|
||||||
|
D --> E{Technical docs?}
|
||||||
|
E -->|Yes| F[architect: tech outline]
|
||||||
|
E -->|No| G{User docs?}
|
||||||
|
F --> G
|
||||||
|
G -->|Yes| H[ux-expert: user outline]
|
||||||
|
G -->|No| I[po: validate plan]
|
||||||
|
H --> I
|
||||||
|
|
||||||
|
I --> J[Documentation Cycle]
|
||||||
|
J --> K[scribe: create content]
|
||||||
|
K --> L{Technical content?}
|
||||||
|
L -->|Yes| M[architect: tech review]
|
||||||
|
L -->|No| N[qa: test docs]
|
||||||
|
M --> N
|
||||||
|
N --> O{Educational review?}
|
||||||
|
O -->|Yes| P[mentor: review]
|
||||||
|
O -->|No| Q{More sections?}
|
||||||
|
P --> Q
|
||||||
|
Q -->|Yes| J
|
||||||
|
Q -->|No| R[scribe: create index]
|
||||||
|
|
||||||
|
R --> S[dev: integrate docs]
|
||||||
|
S --> T[scribe: document updates]
|
||||||
|
T --> U[po: final acceptance]
|
||||||
|
U --> V[sm: release docs]
|
||||||
|
V --> W[Documentation Complete]
|
||||||
|
|
||||||
|
style W fill:#90EE90
|
||||||
|
style B fill:#DDA0DD
|
||||||
|
style K fill:#FFE4B5
|
||||||
|
style M fill:#ADD8E6
|
||||||
|
style N fill:#ADD8E6
|
||||||
|
style T fill:#FFE4B5
|
||||||
|
style V fill:#98FB98
|
||||||
|
```
|
||||||
|
|
||||||
|
decision_guidance:
|
||||||
|
when_to_use:
|
||||||
|
- Major feature releases
|
||||||
|
- API changes
|
||||||
|
- User complaints about docs
|
||||||
|
- Onboarding difficulties
|
||||||
|
- Compliance requirements
|
||||||
|
- Regular documentation maintenance
|
||||||
|
|
||||||
|
handoff_prompts:
|
||||||
|
audit_complete: |
|
||||||
|
Documentation audit complete:
|
||||||
|
- Total pages: {{page_count}}
|
||||||
|
- Outdated sections: {{outdated_count}}
|
||||||
|
- Missing topics: {{gap_count}}
|
||||||
|
- Priority updates: {{priority_count}}
|
||||||
|
|
||||||
|
plan_ready: |
|
||||||
|
Documentation plan created:
|
||||||
|
- Sections to update: {{section_count}}
|
||||||
|
- New content needed: {{new_count}} pages
|
||||||
|
- Estimated effort: {{effort_hours}} hours
|
||||||
|
- Target completion: {{target_date}}
|
||||||
|
|
||||||
|
section_complete: |
|
||||||
|
Documentation section "{{section_name}}" complete:
|
||||||
|
- Pages created/updated: {{page_count}}
|
||||||
|
- Code examples: {{example_count}}
|
||||||
|
- Diagrams added: {{diagram_count}}
|
||||||
|
- Review status: {{review_status}}
|
||||||
|
|
||||||
|
release_ready: |
|
||||||
|
Documentation release ready:
|
||||||
|
- Total updates: {{update_count}}
|
||||||
|
- Quality score: {{quality_score}}/100
|
||||||
|
- Coverage improvement: {{coverage_increase}}%
|
||||||
|
- Ready for publication
|
||||||
|
|
||||||
|
complete: "Documentation update complete. {{total_pages}} pages updated. Next review scheduled for {{next_review_date}}."
|
||||||
|
|
@ -13,6 +13,18 @@ workflow:
|
||||||
- mvp
|
- mvp
|
||||||
|
|
||||||
sequence:
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Initialize AI session context:
|
||||||
|
- Review Memory Bank if exists
|
||||||
|
- Understand project state and technical principles
|
||||||
|
- Check recent dev journals and ADRs
|
||||||
|
- Review sprint context if applicable
|
||||||
|
Required for new sessions or after 24+ hour gaps
|
||||||
|
|
||||||
- agent: analyst
|
- agent: analyst
|
||||||
creates: project-brief.md
|
creates: project-brief.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
|
|
@ -64,6 +76,17 @@ workflow:
|
||||||
condition: po_checklist_issues
|
condition: po_checklist_issues
|
||||||
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||||
|
|
||||||
|
- step: sprint_planning_check
|
||||||
|
agent: sm
|
||||||
|
action: verify_sprint_context
|
||||||
|
condition: development_ready
|
||||||
|
notes: |
|
||||||
|
If part of sprint:
|
||||||
|
- Align with sprint goals
|
||||||
|
- Update sprint backlog
|
||||||
|
- Plan for sprint review
|
||||||
|
- Create ADRs for significant architectural decisions
|
||||||
|
|
||||||
- project_setup_guidance:
|
- project_setup_guidance:
|
||||||
action: guide_project_structure
|
action: guide_project_structure
|
||||||
condition: user_has_generated_ui
|
condition: user_has_generated_ui
|
||||||
|
|
@ -137,6 +160,19 @@ workflow:
|
||||||
- Dev Agent (New Chat): Address remaining items
|
- Dev Agent (New Chat): Address remaining items
|
||||||
- Return to QA for final approval
|
- Return to QA for final approval
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_session_work
|
||||||
|
uses: create-dev-journal
|
||||||
|
condition: significant_work_completed
|
||||||
|
notes: |
|
||||||
|
Create dev journal for:
|
||||||
|
- Major full-stack feature completion
|
||||||
|
- Complex integration solutions
|
||||||
|
- Architectural decisions (trigger ADR creation)
|
||||||
|
- End of work session
|
||||||
|
Updates Memory Bank activeContext
|
||||||
|
|
||||||
- repeat_development_cycle:
|
- repeat_development_cycle:
|
||||||
action: continue_for_all_stories
|
action: continue_for_all_stories
|
||||||
notes: |
|
notes: |
|
||||||
|
|
@ -154,18 +190,31 @@ workflow:
|
||||||
- Validate epic was completed correctly
|
- Validate epic was completed correctly
|
||||||
- Document learnings and improvements
|
- Document learnings and improvements
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: conduct_sprint_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
condition: sprint_boundary
|
||||||
|
notes: |
|
||||||
|
At sprint end:
|
||||||
|
- Review full-stack accomplishments using sprint-review-checklist
|
||||||
|
- Document integration learnings and technical decisions
|
||||||
|
- Update Memory Bank comprehensively
|
||||||
|
- Create sprint summary documentation
|
||||||
|
- Plan next sprint priorities
|
||||||
|
|
||||||
- workflow_end:
|
- workflow_end:
|
||||||
action: project_complete
|
action: project_complete
|
||||||
notes: |
|
notes: |
|
||||||
All stories implemented and reviewed!
|
All stories implemented and reviewed!
|
||||||
Project development phase complete.
|
Project development phase complete.
|
||||||
|
|
||||||
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
||||||
|
|
||||||
flow_diagram: |
|
flow_diagram: |
|
||||||
```mermaid
|
```mermaid
|
||||||
graph TD
|
graph TD
|
||||||
A[Start: Greenfield Project] --> B[analyst: project-brief.md]
|
A[Start: Greenfield Project] --> A1[bmad-master: session kickoff]
|
||||||
|
A1 --> B[analyst: project-brief.md]
|
||||||
B --> C[pm: prd.md]
|
B --> C[pm: prd.md]
|
||||||
C --> D[ux-expert: front-end-spec.md]
|
C --> D[ux-expert: front-end-spec.md]
|
||||||
D --> D2{Generate v0 prompt?}
|
D --> D2{Generate v0 prompt?}
|
||||||
|
|
@ -179,8 +228,9 @@ workflow:
|
||||||
G --> H
|
G --> H
|
||||||
H --> I{PO finds issues?}
|
H --> I{PO finds issues?}
|
||||||
I -->|Yes| J[Return to relevant agent for fixes]
|
I -->|Yes| J[Return to relevant agent for fixes]
|
||||||
I -->|No| K[po: shard documents]
|
I -->|No| SP[sm: sprint planning]
|
||||||
J --> H
|
J --> H
|
||||||
|
SP --> K[po: shard documents]
|
||||||
|
|
||||||
K --> L[sm: create story]
|
K --> L[sm: create story]
|
||||||
L --> M{Review draft story?}
|
L --> M{Review draft story?}
|
||||||
|
|
@ -189,16 +239,20 @@ workflow:
|
||||||
N --> O
|
N --> O
|
||||||
O --> P{QA review?}
|
O --> P{QA review?}
|
||||||
P -->|Yes| Q[qa: review implementation]
|
P -->|Yes| Q[qa: review implementation]
|
||||||
P -->|No| R{More stories?}
|
P -->|No| DJ[dev: dev journal]
|
||||||
Q --> S{QA found issues?}
|
Q --> S{QA found issues?}
|
||||||
S -->|Yes| T[dev: address QA feedback]
|
S -->|Yes| T[dev: address QA feedback]
|
||||||
S -->|No| R
|
S -->|No| DJ
|
||||||
T --> Q
|
T --> Q
|
||||||
|
DJ --> R{More stories?}
|
||||||
R -->|Yes| L
|
R -->|Yes| L
|
||||||
R -->|No| U{Epic retrospective?}
|
R -->|No| U{Epic retrospective?}
|
||||||
U -->|Yes| V[po: epic retrospective]
|
U -->|Yes| V[po: epic retrospective]
|
||||||
U -->|No| W[Project Complete]
|
U -->|No| SR{Sprint boundary?}
|
||||||
V --> W
|
V --> SR
|
||||||
|
SR -->|Yes| SRV[sm: sprint review]
|
||||||
|
SR -->|No| W[Project Complete]
|
||||||
|
SRV --> W
|
||||||
|
|
||||||
B -.-> B1[Optional: brainstorming]
|
B -.-> B1[Optional: brainstorming]
|
||||||
B -.-> B2[Optional: market research]
|
B -.-> B2[Optional: market research]
|
||||||
|
|
@ -218,6 +272,10 @@ workflow:
|
||||||
style N fill:#F0E68C
|
style N fill:#F0E68C
|
||||||
style Q fill:#F0E68C
|
style Q fill:#F0E68C
|
||||||
style V fill:#F0E68C
|
style V fill:#F0E68C
|
||||||
|
style A1 fill:#E6E6FA
|
||||||
|
style SP fill:#E6E6FA
|
||||||
|
style DJ fill:#E6E6FA
|
||||||
|
style SRV fill:#E6E6FA
|
||||||
```
|
```
|
||||||
|
|
||||||
decision_guidance:
|
decision_guidance:
|
||||||
|
|
|
||||||
|
|
@ -14,6 +14,18 @@ workflow:
|
||||||
- simple-service
|
- simple-service
|
||||||
|
|
||||||
sequence:
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Initialize AI session context:
|
||||||
|
- Review Memory Bank if exists
|
||||||
|
- Understand project state and technical principles
|
||||||
|
- Check recent dev journals and ADRs
|
||||||
|
- Review sprint context if applicable
|
||||||
|
Required for new sessions or after 24+ hour gaps
|
||||||
|
|
||||||
- agent: analyst
|
- agent: analyst
|
||||||
creates: project-brief.md
|
creates: project-brief.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
|
|
@ -49,6 +61,17 @@ workflow:
|
||||||
condition: po_checklist_issues
|
condition: po_checklist_issues
|
||||||
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
notes: "If PO finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||||
|
|
||||||
|
- step: sprint_planning_check
|
||||||
|
agent: sm
|
||||||
|
action: verify_sprint_context
|
||||||
|
condition: development_ready
|
||||||
|
notes: |
|
||||||
|
If part of sprint:
|
||||||
|
- Align with sprint goals
|
||||||
|
- Update sprint backlog
|
||||||
|
- Plan for sprint review
|
||||||
|
- Create ADRs for significant API/service decisions
|
||||||
|
|
||||||
- agent: po
|
- agent: po
|
||||||
action: shard_documents
|
action: shard_documents
|
||||||
creates: sharded_docs
|
creates: sharded_docs
|
||||||
|
|
@ -113,6 +136,19 @@ workflow:
|
||||||
- Dev Agent (New Chat): Address remaining items
|
- Dev Agent (New Chat): Address remaining items
|
||||||
- Return to QA for final approval
|
- Return to QA for final approval
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_session_work
|
||||||
|
uses: create-dev-journal
|
||||||
|
condition: significant_work_completed
|
||||||
|
notes: |
|
||||||
|
Create dev journal for:
|
||||||
|
- Major API/service endpoint completion
|
||||||
|
- Complex backend problem solutions
|
||||||
|
- Service architectural decisions (trigger ADR creation)
|
||||||
|
- End of work session
|
||||||
|
Updates Memory Bank activeContext
|
||||||
|
|
||||||
- repeat_development_cycle:
|
- repeat_development_cycle:
|
||||||
action: continue_for_all_stories
|
action: continue_for_all_stories
|
||||||
notes: |
|
notes: |
|
||||||
|
|
@ -130,12 +166,24 @@ workflow:
|
||||||
- Validate epic was completed correctly
|
- Validate epic was completed correctly
|
||||||
- Document learnings and improvements
|
- Document learnings and improvements
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: conduct_sprint_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
condition: sprint_boundary
|
||||||
|
notes: |
|
||||||
|
At sprint end:
|
||||||
|
- Review service/API accomplishments using sprint-review-checklist
|
||||||
|
- Document backend learnings and technical decisions
|
||||||
|
- Update Memory Bank comprehensively
|
||||||
|
- Create sprint summary documentation
|
||||||
|
- Plan next sprint service priorities
|
||||||
|
|
||||||
- workflow_end:
|
- workflow_end:
|
||||||
action: project_complete
|
action: project_complete
|
||||||
notes: |
|
notes: |
|
||||||
All stories implemented and reviewed!
|
All stories implemented and reviewed!
|
||||||
Service development phase complete.
|
Service development phase complete.
|
||||||
|
|
||||||
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
||||||
|
|
||||||
flow_diagram: |
|
flow_diagram: |
|
||||||
|
|
|
||||||
|
|
@ -14,6 +14,18 @@ workflow:
|
||||||
- simple-interface
|
- simple-interface
|
||||||
|
|
||||||
sequence:
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Initialize AI session context:
|
||||||
|
- Review Memory Bank if exists
|
||||||
|
- Understand project state and technical principles
|
||||||
|
- Check recent dev journals and ADRs
|
||||||
|
- Review sprint context if applicable
|
||||||
|
Required for new sessions or after 24+ hour gaps
|
||||||
|
|
||||||
- agent: analyst
|
- agent: analyst
|
||||||
creates: project-brief.md
|
creates: project-brief.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
|
|
@ -68,6 +80,17 @@ workflow:
|
||||||
condition: user_has_generated_ui
|
condition: user_has_generated_ui
|
||||||
notes: "If user generated UI with v0/Lovable: For polyrepo setup, place downloaded project in separate frontend repo. For monorepo, place in apps/web or frontend/ directory. Review architecture document for specific guidance."
|
notes: "If user generated UI with v0/Lovable: For polyrepo setup, place downloaded project in separate frontend repo. For monorepo, place in apps/web or frontend/ directory. Review architecture document for specific guidance."
|
||||||
|
|
||||||
|
- step: sprint_planning_check
|
||||||
|
agent: sm
|
||||||
|
action: verify_sprint_context
|
||||||
|
condition: development_ready
|
||||||
|
notes: |
|
||||||
|
If part of sprint:
|
||||||
|
- Align UI development with sprint goals
|
||||||
|
- Update sprint backlog
|
||||||
|
- Plan for sprint review
|
||||||
|
- Create ADRs for significant UI decisions
|
||||||
|
|
||||||
- agent: po
|
- agent: po
|
||||||
action: shard_documents
|
action: shard_documents
|
||||||
creates: sharded_docs
|
creates: sharded_docs
|
||||||
|
|
@ -132,6 +155,19 @@ workflow:
|
||||||
- Dev Agent (New Chat): Address remaining items
|
- Dev Agent (New Chat): Address remaining items
|
||||||
- Return to QA for final approval
|
- Return to QA for final approval
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_session_work
|
||||||
|
uses: create-dev-journal
|
||||||
|
condition: significant_work_completed
|
||||||
|
notes: |
|
||||||
|
Create dev journal for:
|
||||||
|
- UI component completion
|
||||||
|
- Complex frontend solutions
|
||||||
|
- Design pattern decisions (trigger ADR)
|
||||||
|
- End of work session
|
||||||
|
Updates Memory Bank activeContext
|
||||||
|
|
||||||
- repeat_development_cycle:
|
- repeat_development_cycle:
|
||||||
action: continue_for_all_stories
|
action: continue_for_all_stories
|
||||||
notes: |
|
notes: |
|
||||||
|
|
@ -149,18 +185,32 @@ workflow:
|
||||||
- Validate epic was completed correctly
|
- Validate epic was completed correctly
|
||||||
- Document learnings and improvements
|
- Document learnings and improvements
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: conduct_sprint_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
condition: sprint_boundary
|
||||||
|
notes: |
|
||||||
|
At sprint end:
|
||||||
|
- Review UI components and features delivered
|
||||||
|
- Document design decisions and patterns
|
||||||
|
- Update Memory Bank with UI patterns
|
||||||
|
- Create sprint summary with visual samples
|
||||||
|
- Plan next sprint UI priorities
|
||||||
|
|
||||||
- workflow_end:
|
- workflow_end:
|
||||||
action: project_complete
|
action: project_complete
|
||||||
notes: |
|
notes: |
|
||||||
All stories implemented and reviewed!
|
All stories implemented and reviewed!
|
||||||
Project development phase complete.
|
UI development phase complete.
|
||||||
|
Memory Bank and design documentation updated.
|
||||||
|
|
||||||
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
||||||
|
|
||||||
flow_diagram: |
|
flow_diagram: |
|
||||||
```mermaid
|
```mermaid
|
||||||
graph TD
|
graph TD
|
||||||
A[Start: UI Development] --> B[analyst: project-brief.md]
|
A[Start: UI Development] --> A1[bmad-master: session kickoff]
|
||||||
|
A1 --> B[analyst: project-brief.md]
|
||||||
B --> C[pm: prd.md]
|
B --> C[pm: prd.md]
|
||||||
C --> D[ux-expert: front-end-spec.md]
|
C --> D[ux-expert: front-end-spec.md]
|
||||||
D --> D2{Generate v0 prompt?}
|
D --> D2{Generate v0 prompt?}
|
||||||
|
|
@ -174,8 +224,9 @@ workflow:
|
||||||
G --> H
|
G --> H
|
||||||
H --> I{PO finds issues?}
|
H --> I{PO finds issues?}
|
||||||
I -->|Yes| J[Return to relevant agent for fixes]
|
I -->|Yes| J[Return to relevant agent for fixes]
|
||||||
I -->|No| K[po: shard documents]
|
I -->|No| SP[sm: sprint planning]
|
||||||
J --> H
|
J --> H
|
||||||
|
SP --> K[po: shard documents]
|
||||||
|
|
||||||
K --> L[sm: create story]
|
K --> L[sm: create story]
|
||||||
L --> M{Review draft story?}
|
L --> M{Review draft story?}
|
||||||
|
|
@ -190,10 +241,14 @@ workflow:
|
||||||
S -->|No| R
|
S -->|No| R
|
||||||
T --> Q
|
T --> Q
|
||||||
R -->|Yes| L
|
R -->|Yes| L
|
||||||
R -->|No| U{Epic retrospective?}
|
R -->|No| DJ[dev: dev journal]
|
||||||
|
DJ --> U{Epic retrospective?}
|
||||||
U -->|Yes| V[po: epic retrospective]
|
U -->|Yes| V[po: epic retrospective]
|
||||||
U -->|No| W[Project Complete]
|
U -->|No| SR{Sprint boundary?}
|
||||||
V --> W
|
V --> SR
|
||||||
|
SR -->|Yes| SRV[sm: sprint review]
|
||||||
|
SR -->|No| W[Project Complete]
|
||||||
|
SRV --> W
|
||||||
|
|
||||||
B -.-> B1[Optional: brainstorming]
|
B -.-> B1[Optional: brainstorming]
|
||||||
B -.-> B2[Optional: market research]
|
B -.-> B2[Optional: market research]
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,300 @@
|
||||||
|
workflow:
|
||||||
|
id: performance-optimization
|
||||||
|
name: Performance Optimization Workflow
|
||||||
|
description: >-
|
||||||
|
Agent workflow for systematic performance improvements. Focuses on identifying
|
||||||
|
bottlenecks, implementing optimizations, and validating improvements through
|
||||||
|
benchmarking and monitoring.
|
||||||
|
type: optimization
|
||||||
|
project_types:
|
||||||
|
- performance-tuning
|
||||||
|
- scalability-improvement
|
||||||
|
- response-time-optimization
|
||||||
|
- resource-optimization
|
||||||
|
- throughput-enhancement
|
||||||
|
|
||||||
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Performance-focused initialization:
|
||||||
|
- Review Memory Bank for known issues
|
||||||
|
- Check previous optimization efforts
|
||||||
|
- Review performance requirements
|
||||||
|
- Understand system architecture
|
||||||
|
- Check monitoring setup
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: performance_assessment
|
||||||
|
creates: performance-baseline.md
|
||||||
|
notes: |
|
||||||
|
Establish performance baseline:
|
||||||
|
- Current performance metrics
|
||||||
|
- Resource utilization patterns
|
||||||
|
- Response time distribution
|
||||||
|
- Throughput measurements
|
||||||
|
- Error rates
|
||||||
|
- User experience metrics
|
||||||
|
|
||||||
|
- agent: analyst
|
||||||
|
action: bottleneck_analysis
|
||||||
|
creates: bottleneck-analysis.md
|
||||||
|
requires: performance-baseline.md
|
||||||
|
notes: |
|
||||||
|
Identify performance bottlenecks:
|
||||||
|
- Profile application code
|
||||||
|
- Analyze database queries
|
||||||
|
- Review network latency
|
||||||
|
- Check resource constraints
|
||||||
|
- Identify hot paths
|
||||||
|
- Memory leak detection
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: optimization_strategy
|
||||||
|
creates: optimization-strategy.md
|
||||||
|
requires: bottleneck-analysis.md
|
||||||
|
notes: |
|
||||||
|
Design optimization approach:
|
||||||
|
- Quick wins identification
|
||||||
|
- Architectural improvements
|
||||||
|
- Caching strategies
|
||||||
|
- Query optimization plans
|
||||||
|
- Resource scaling options
|
||||||
|
- Code optimization targets
|
||||||
|
|
||||||
|
- agent: pm
|
||||||
|
creates: optimization-plan.md
|
||||||
|
action: prioritize_optimizations
|
||||||
|
requires: optimization-strategy.md
|
||||||
|
notes: |
|
||||||
|
Create optimization plan:
|
||||||
|
- Impact vs effort matrix
|
||||||
|
- Implementation sequence
|
||||||
|
- Performance targets
|
||||||
|
- Risk assessment
|
||||||
|
- Testing requirements
|
||||||
|
- Rollback procedures
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
validates: optimization_plan
|
||||||
|
notes: |
|
||||||
|
Validate approach:
|
||||||
|
- Confirm performance goals
|
||||||
|
- Approve resource usage
|
||||||
|
- Accept risk levels
|
||||||
|
- Sign off on timeline
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: setup_benchmarks
|
||||||
|
creates: benchmark-suite/
|
||||||
|
notes: |
|
||||||
|
Create benchmark suite:
|
||||||
|
- Micro-benchmarks for hot paths
|
||||||
|
- Load testing scenarios
|
||||||
|
- Real-world usage patterns
|
||||||
|
- Stress test configurations
|
||||||
|
- Monitoring dashboards
|
||||||
|
- Automated performance tests
|
||||||
|
|
||||||
|
- optimization_cycle:
|
||||||
|
repeats: for_each_optimization
|
||||||
|
sequence:
|
||||||
|
- agent: dev
|
||||||
|
action: implement_optimization
|
||||||
|
updates: optimized_code
|
||||||
|
notes: |
|
||||||
|
Careful implementation:
|
||||||
|
- Apply optimization
|
||||||
|
- Maintain functionality
|
||||||
|
- Add performance tests
|
||||||
|
- Document changes
|
||||||
|
- Update monitoring
|
||||||
|
|
||||||
|
- agent: qa
|
||||||
|
action: performance_testing
|
||||||
|
validates: optimization_impact
|
||||||
|
notes: |
|
||||||
|
Comprehensive testing:
|
||||||
|
- Run benchmark suite
|
||||||
|
- Load testing
|
||||||
|
- Stress testing
|
||||||
|
- Regression testing
|
||||||
|
- Real-world scenarios
|
||||||
|
- Monitor resource usage
|
||||||
|
|
||||||
|
- agent: analyst
|
||||||
|
action: measure_improvement
|
||||||
|
creates: improvement-metrics.md
|
||||||
|
notes: |
|
||||||
|
Quantify improvements:
|
||||||
|
- Before/after comparison
|
||||||
|
- Statistical significance
|
||||||
|
- Resource usage delta
|
||||||
|
- Cost analysis
|
||||||
|
- User impact assessment
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
creates: adr.md
|
||||||
|
action: document_optimization
|
||||||
|
condition: significant_change
|
||||||
|
notes: |
|
||||||
|
Document decisions:
|
||||||
|
- Optimization rationale
|
||||||
|
- Trade-offs made
|
||||||
|
- Implementation details
|
||||||
|
- Performance gains
|
||||||
|
- Side effects
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: production_monitoring
|
||||||
|
updates: monitoring_configuration
|
||||||
|
notes: |
|
||||||
|
Enhanced monitoring:
|
||||||
|
- Add performance metrics
|
||||||
|
- Set up alerts
|
||||||
|
- Create dashboards
|
||||||
|
- Configure profiling
|
||||||
|
- Enable tracing
|
||||||
|
- Set SLO targets
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_optimizations
|
||||||
|
uses: create-dev-journal
|
||||||
|
notes: |
|
||||||
|
Document optimization work:
|
||||||
|
- Optimizations applied
|
||||||
|
- Performance improvements
|
||||||
|
- Lessons learned
|
||||||
|
- Monitoring setup
|
||||||
|
- Update Memory Bank
|
||||||
|
|
||||||
|
- agent: analyst
|
||||||
|
action: final_performance_report
|
||||||
|
creates: performance-report.md
|
||||||
|
notes: |
|
||||||
|
Comprehensive performance report:
|
||||||
|
- Overall improvements
|
||||||
|
- Individual optimization impacts
|
||||||
|
- Resource usage changes
|
||||||
|
- Cost implications
|
||||||
|
- User experience improvements
|
||||||
|
- Recommendations
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: optimization_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
creates: optimization-review.md
|
||||||
|
notes: |
|
||||||
|
Review optimization results:
|
||||||
|
- Present improvements
|
||||||
|
- Demonstrate benchmarks
|
||||||
|
- Show monitoring dashboards
|
||||||
|
- Discuss next steps
|
||||||
|
- Plan maintenance
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: update_performance_docs
|
||||||
|
updates: architecture_documentation
|
||||||
|
notes: |
|
||||||
|
Update documentation:
|
||||||
|
- Performance characteristics
|
||||||
|
- Scaling guidelines
|
||||||
|
- Optimization patterns
|
||||||
|
- Monitoring requirements
|
||||||
|
- Troubleshooting guides
|
||||||
|
|
||||||
|
- workflow_end:
|
||||||
|
action: optimization_complete
|
||||||
|
notes: |
|
||||||
|
Performance optimization complete!
|
||||||
|
- Targets achieved
|
||||||
|
- Monitoring active
|
||||||
|
- Documentation updated
|
||||||
|
- Team trained
|
||||||
|
- Maintenance planned
|
||||||
|
|
||||||
|
flow_diagram: |
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[Start: Performance] --> B[bmad-master: session init]
|
||||||
|
B --> C[architect: baseline assessment]
|
||||||
|
C --> D[analyst: bottleneck analysis]
|
||||||
|
D --> E[architect: optimization strategy]
|
||||||
|
E --> F[pm: prioritize optimizations]
|
||||||
|
F --> G[po: validate plan]
|
||||||
|
|
||||||
|
G --> H[dev: setup benchmarks]
|
||||||
|
H --> I[Optimization Cycle]
|
||||||
|
I --> J[dev: implement optimization]
|
||||||
|
J --> K[qa: performance testing]
|
||||||
|
K --> L[analyst: measure improvement]
|
||||||
|
L --> M{Significant change?}
|
||||||
|
M -->|Yes| N[architect: create ADR]
|
||||||
|
M -->|No| O{More optimizations?}
|
||||||
|
N --> O
|
||||||
|
O -->|Yes| I
|
||||||
|
O -->|No| P[dev: production monitoring]
|
||||||
|
|
||||||
|
P --> Q[dev: document work]
|
||||||
|
Q --> R[analyst: final report]
|
||||||
|
R --> S[sm: optimization review]
|
||||||
|
S --> T[architect: update docs]
|
||||||
|
T --> U[Optimization Complete]
|
||||||
|
|
||||||
|
style U fill:#90EE90
|
||||||
|
style B fill:#DDA0DD
|
||||||
|
style C fill:#FFB6C1
|
||||||
|
style D fill:#FFB6C1
|
||||||
|
style L fill:#98FB98
|
||||||
|
style K fill:#FFA500
|
||||||
|
style R fill:#98FB98
|
||||||
|
style S fill:#ADD8E6
|
||||||
|
```
|
||||||
|
|
||||||
|
decision_guidance:
|
||||||
|
when_to_use:
|
||||||
|
- User complaints about speed
|
||||||
|
- System not meeting SLOs
|
||||||
|
- Scaling issues
|
||||||
|
- High infrastructure costs
|
||||||
|
- Before major traffic events
|
||||||
|
- Regular performance maintenance
|
||||||
|
|
||||||
|
handoff_prompts:
|
||||||
|
baseline_complete: |
|
||||||
|
Performance baseline established:
|
||||||
|
- P95 response time: {{p95_response}}ms
|
||||||
|
- Throughput: {{throughput}} req/s
|
||||||
|
- Error rate: {{error_rate}}%
|
||||||
|
- Resource usage: CPU {{cpu}}%, Memory {{memory}}%
|
||||||
|
|
||||||
|
bottlenecks_found: |
|
||||||
|
Top bottlenecks identified:
|
||||||
|
1. {{bottleneck_1}}: {{impact_1}}% impact
|
||||||
|
2. {{bottleneck_2}}: {{impact_2}}% impact
|
||||||
|
3. {{bottleneck_3}}: {{impact_3}}% impact
|
||||||
|
Total optimization potential: {{total_potential}}%
|
||||||
|
|
||||||
|
optimization_complete: |
|
||||||
|
Optimization "{{optimization_name}}" complete:
|
||||||
|
- Performance gain: {{improvement}}%
|
||||||
|
- Response time: {{old_time}}ms → {{new_time}}ms
|
||||||
|
- Resource reduction: {{resource_saving}}%
|
||||||
|
- Tests passing: {{test_status}}
|
||||||
|
|
||||||
|
final_report: |
|
||||||
|
Performance optimization summary:
|
||||||
|
- Overall improvement: {{total_improvement}}%
|
||||||
|
- P95 reduced by: {{p95_reduction}}ms
|
||||||
|
- Throughput increased: {{throughput_increase}}%
|
||||||
|
- Cost savings: ${{monthly_savings}}/month
|
||||||
|
|
||||||
|
complete: |
|
||||||
|
Performance optimization complete!
|
||||||
|
- All targets met: {{targets_met}}
|
||||||
|
- SLO compliance: {{slo_compliance}}%
|
||||||
|
- Monitoring active: {{monitoring_status}}
|
||||||
|
- Next review: {{next_review_date}}
|
||||||
|
|
@ -0,0 +1,220 @@
|
||||||
|
workflow:
|
||||||
|
id: quick-fix
|
||||||
|
name: Quick Fix / Hotfix Workflow
|
||||||
|
description: >-
|
||||||
|
Agent workflow for urgent production fixes and hotfixes. Streamlined process
|
||||||
|
for critical issues that need immediate attention with minimal overhead
|
||||||
|
while maintaining quality and documentation standards.
|
||||||
|
type: hotfix
|
||||||
|
project_types:
|
||||||
|
- production-fix
|
||||||
|
- security-patch
|
||||||
|
- critical-bug
|
||||||
|
- emergency-update
|
||||||
|
- hotfix
|
||||||
|
|
||||||
|
sequence:
|
||||||
|
- step: abbreviated_session_init
|
||||||
|
agent: bmad-master
|
||||||
|
action: quick_context_load
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Abbreviated initialization:
|
||||||
|
- Quick Memory Bank scan
|
||||||
|
- Focus on affected system areas
|
||||||
|
- Review recent deployments
|
||||||
|
- Check related ADRs
|
||||||
|
Priority: Speed over comprehensive review
|
||||||
|
|
||||||
|
- step: issue_triage
|
||||||
|
agent: analyst
|
||||||
|
action: analyze_issue
|
||||||
|
creates: issue-analysis.md
|
||||||
|
notes: |
|
||||||
|
Rapid issue analysis:
|
||||||
|
- Reproduce the issue
|
||||||
|
- Identify root cause
|
||||||
|
- Assess impact severity
|
||||||
|
- Determine affected components
|
||||||
|
- Estimate fix complexity
|
||||||
|
Time box: 30 minutes max
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: quick_solution_design
|
||||||
|
creates: fix-approach.md
|
||||||
|
condition: complex_fix
|
||||||
|
optional: true
|
||||||
|
notes: |
|
||||||
|
For complex fixes only:
|
||||||
|
- Design minimal viable fix
|
||||||
|
- Consider rollback strategy
|
||||||
|
- Identify testing requirements
|
||||||
|
- Note any technical debt incurred
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: implement_fix
|
||||||
|
creates: fix_implementation
|
||||||
|
notes: |
|
||||||
|
Rapid implementation:
|
||||||
|
- Minimal code changes
|
||||||
|
- Focus on fixing issue only
|
||||||
|
- Add regression test
|
||||||
|
- Comment code thoroughly
|
||||||
|
- Update affected documentation
|
||||||
|
|
||||||
|
- agent: qa
|
||||||
|
action: targeted_testing
|
||||||
|
validates: fix_implementation
|
||||||
|
notes: |
|
||||||
|
Focused testing:
|
||||||
|
- Test the specific fix
|
||||||
|
- Verify no regressions
|
||||||
|
- Check edge cases
|
||||||
|
- Performance impact check
|
||||||
|
- Security implications review
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: address_test_issues
|
||||||
|
updates: fix_implementation
|
||||||
|
condition: qa_finds_issues
|
||||||
|
notes: |
|
||||||
|
Quick iteration:
|
||||||
|
- Fix identified issues
|
||||||
|
- Re-test specific areas
|
||||||
|
- Update fix if needed
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
creates: adr-hotfix.md
|
||||||
|
action: document_emergency_decision
|
||||||
|
notes: |
|
||||||
|
Document fix decision:
|
||||||
|
- Why this approach was chosen
|
||||||
|
- Trade-offs accepted
|
||||||
|
- Technical debt created
|
||||||
|
- Future improvement notes
|
||||||
|
Quick ADR format acceptable
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: deployment-notes.md
|
||||||
|
action: prepare_deployment
|
||||||
|
notes: |
|
||||||
|
Deployment preparation:
|
||||||
|
- Create deployment checklist
|
||||||
|
- Document rollback procedure
|
||||||
|
- List configuration changes
|
||||||
|
- Note monitoring requirements
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_hotfix
|
||||||
|
uses: create-dev-journal
|
||||||
|
notes: |
|
||||||
|
Quick documentation:
|
||||||
|
- Issue description and impact
|
||||||
|
- Fix approach and rationale
|
||||||
|
- Deployment details
|
||||||
|
- Lessons learned
|
||||||
|
Updates Memory Bank activeContext
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
action: approve_emergency_release
|
||||||
|
validates: fix_and_documentation
|
||||||
|
notes: |
|
||||||
|
Emergency approval:
|
||||||
|
- Verify fix addresses issue
|
||||||
|
- Accept documentation level
|
||||||
|
- Approve for deployment
|
||||||
|
- Sign off on risk acceptance
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: post_mortem_planning
|
||||||
|
creates: post-mortem-plan.md
|
||||||
|
optional: true
|
||||||
|
notes: |
|
||||||
|
Schedule follow-up:
|
||||||
|
- Plan full post-mortem
|
||||||
|
- Schedule debt paydown
|
||||||
|
- Identify process improvements
|
||||||
|
- Add to next sprint backlog
|
||||||
|
|
||||||
|
- workflow_end:
|
||||||
|
action: hotfix_complete
|
||||||
|
notes: |
|
||||||
|
Hotfix deployed!
|
||||||
|
- Issue resolved
|
||||||
|
- Basic documentation complete
|
||||||
|
- Post-mortem scheduled
|
||||||
|
- Technical debt logged
|
||||||
|
|
||||||
|
flow_diagram: |
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[Start: Critical Issue] --> B[bmad-master: quick init]
|
||||||
|
B --> C[analyst: triage issue]
|
||||||
|
C --> D{Complex fix?}
|
||||||
|
|
||||||
|
D -->|Yes| E[architect: design approach]
|
||||||
|
D -->|No| F[dev: implement fix]
|
||||||
|
E --> F
|
||||||
|
|
||||||
|
F --> G[qa: targeted testing]
|
||||||
|
G --> H{Issues found?}
|
||||||
|
H -->|Yes| I[dev: fix issues]
|
||||||
|
H -->|No| J[architect: quick ADR]
|
||||||
|
I --> G
|
||||||
|
|
||||||
|
J --> K[dev: deployment prep]
|
||||||
|
K --> L[dev: document hotfix]
|
||||||
|
L --> M[po: emergency approval]
|
||||||
|
M --> N{Post-mortem needed?}
|
||||||
|
N -->|Yes| O[sm: schedule post-mortem]
|
||||||
|
N -->|No| P[Hotfix Complete]
|
||||||
|
O --> P
|
||||||
|
|
||||||
|
style P fill:#90EE90
|
||||||
|
style B fill:#FF6B6B
|
||||||
|
style C fill:#FF6B6B
|
||||||
|
style F fill:#FFA500
|
||||||
|
style G fill:#FFA500
|
||||||
|
style M fill:#FFD700
|
||||||
|
```
|
||||||
|
|
||||||
|
decision_guidance:
|
||||||
|
when_to_use:
|
||||||
|
- Production system is down
|
||||||
|
- Security vulnerability discovered
|
||||||
|
- Critical bug affecting users
|
||||||
|
- Regulatory compliance issue
|
||||||
|
- Revenue-impacting problem
|
||||||
|
|
||||||
|
when_not_to_use:
|
||||||
|
- Non-critical improvements
|
||||||
|
- Feature requests
|
||||||
|
- Technical debt cleanup
|
||||||
|
- Performance optimizations (non-critical)
|
||||||
|
|
||||||
|
handoff_prompts:
|
||||||
|
triage_complete: |
|
||||||
|
Issue analysis complete:
|
||||||
|
- Severity: {{severity_level}}
|
||||||
|
- Impact: {{affected_users}} users affected
|
||||||
|
- Root cause: {{root_cause}}
|
||||||
|
- Fix complexity: {{complexity_estimate}}
|
||||||
|
|
||||||
|
fix_ready: "Fix implemented in {{time_taken}}. Ready for emergency testing."
|
||||||
|
|
||||||
|
testing_complete: "Fix verified. {{test_count}} tests passed. No regressions found."
|
||||||
|
|
||||||
|
approval_request: |
|
||||||
|
Emergency release request:
|
||||||
|
- Issue: {{issue_description}}
|
||||||
|
- Fix: {{fix_summary}}
|
||||||
|
- Risk: {{risk_level}}
|
||||||
|
- Rollback available: {{yes/no}}
|
||||||
|
|
||||||
|
complete: |
|
||||||
|
Hotfix deployed successfully.
|
||||||
|
- Deployment time: {{deployment_time}}
|
||||||
|
- Issue resolved: {{confirmation}}
|
||||||
|
- Post-mortem scheduled: {{date/time or N/A}}
|
||||||
|
- Technical debt ticket: {{ticket_id}}
|
||||||
|
|
@ -0,0 +1,249 @@
|
||||||
|
workflow:
|
||||||
|
id: sprint-execution
|
||||||
|
name: Sprint-Based Development Workflow
|
||||||
|
description: >-
|
||||||
|
Agent workflow for sprint-based agile development. Handles sprint planning,
|
||||||
|
daily development cycles, mid-sprint adjustments, sprint reviews, and retrospectives.
|
||||||
|
Integrates Memory Bank updates and continuous documentation.
|
||||||
|
type: sprint
|
||||||
|
project_types:
|
||||||
|
- agile-development
|
||||||
|
- scrum-sprint
|
||||||
|
- iterative-delivery
|
||||||
|
- continuous-improvement
|
||||||
|
|
||||||
|
sequence:
|
||||||
|
- step: sprint_kickoff
|
||||||
|
agent: bmad-master
|
||||||
|
action: initialize_sprint_context
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Sprint initialization:
|
||||||
|
- Review Memory Bank for project state
|
||||||
|
- Check previous sprint outcomes
|
||||||
|
- Review product backlog
|
||||||
|
- Understand technical context
|
||||||
|
- Review team velocity and capacity
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: sprint_planning
|
||||||
|
creates: sprint-plan.md
|
||||||
|
uses: sprint-planning-tmpl
|
||||||
|
notes: |
|
||||||
|
Sprint planning session:
|
||||||
|
- Define sprint goals
|
||||||
|
- Select stories from backlog
|
||||||
|
- Estimate story points
|
||||||
|
- Assign initial priorities
|
||||||
|
- Create sprint backlog
|
||||||
|
- Document in sprint-plan.md
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
validates: sprint_plan
|
||||||
|
action: approve_sprint_scope
|
||||||
|
notes: |
|
||||||
|
Validate sprint plan:
|
||||||
|
- Confirm goals align with product vision
|
||||||
|
- Verify story selection
|
||||||
|
- Approve priorities
|
||||||
|
- Sign off on sprint commitment
|
||||||
|
|
||||||
|
- daily_development_cycle:
|
||||||
|
repeats: for_each_sprint_day
|
||||||
|
sequence:
|
||||||
|
- agent: sm
|
||||||
|
action: daily_standup
|
||||||
|
creates: daily-status.md
|
||||||
|
notes: |
|
||||||
|
Daily coordination:
|
||||||
|
- Review yesterday's progress
|
||||||
|
- Plan today's work
|
||||||
|
- Identify blockers
|
||||||
|
- Update sprint burndown
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: implement_daily_work
|
||||||
|
updates: implementation_files
|
||||||
|
notes: |
|
||||||
|
Development work:
|
||||||
|
- Work on assigned stories
|
||||||
|
- Follow coding standards
|
||||||
|
- Create unit tests
|
||||||
|
- Update story status
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_daily_progress
|
||||||
|
uses: create-dev-journal
|
||||||
|
condition: end_of_day
|
||||||
|
notes: |
|
||||||
|
Daily documentation:
|
||||||
|
- Document work completed
|
||||||
|
- Note challenges faced
|
||||||
|
- Record decisions made
|
||||||
|
- Update Memory Bank activeContext
|
||||||
|
|
||||||
|
- step: mid_sprint_check
|
||||||
|
agent: sm
|
||||||
|
action: assess_sprint_health
|
||||||
|
condition: sprint_midpoint
|
||||||
|
notes: |
|
||||||
|
Mid-sprint assessment:
|
||||||
|
- Review burndown chart
|
||||||
|
- Assess story completion rate
|
||||||
|
- Identify at-risk items
|
||||||
|
- Plan adjustments if needed
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
action: mid_sprint_adjustment
|
||||||
|
condition: scope_change_needed
|
||||||
|
optional: true
|
||||||
|
notes: |
|
||||||
|
Sprint adjustment:
|
||||||
|
- Review proposed changes
|
||||||
|
- Approve scope modifications
|
||||||
|
- Update sprint goals if needed
|
||||||
|
- Communicate changes
|
||||||
|
|
||||||
|
- agent: qa
|
||||||
|
action: continuous_testing
|
||||||
|
updates: test_results
|
||||||
|
repeats: as_stories_complete
|
||||||
|
notes: |
|
||||||
|
Ongoing quality assurance:
|
||||||
|
- Test completed stories
|
||||||
|
- Report issues immediately
|
||||||
|
- Verify acceptance criteria
|
||||||
|
- Update story status
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
creates: adr.md
|
||||||
|
action: document_decisions
|
||||||
|
condition: architectural_decision_made
|
||||||
|
notes: |
|
||||||
|
ADR creation:
|
||||||
|
- Document significant decisions
|
||||||
|
- Record context and rationale
|
||||||
|
- Update Memory Bank systemPatterns
|
||||||
|
- Link to related stories
|
||||||
|
|
||||||
|
- step: sprint_review_preparation
|
||||||
|
agent: sm
|
||||||
|
action: prepare_review_materials
|
||||||
|
creates: sprint-review-prep.md
|
||||||
|
condition: sprint_final_day
|
||||||
|
notes: |
|
||||||
|
Review preparation:
|
||||||
|
- Compile completed stories
|
||||||
|
- Prepare demonstration materials
|
||||||
|
- Document impediments
|
||||||
|
- Calculate velocity metrics
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: conduct_sprint_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
creates: sprint-review-summary.md
|
||||||
|
notes: |
|
||||||
|
Sprint review meeting:
|
||||||
|
- Demonstrate completed work
|
||||||
|
- Gather stakeholder feedback
|
||||||
|
- Document acceptance status
|
||||||
|
- Update product backlog
|
||||||
|
- Use sprint-review-checklist.md
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
action: accept_sprint_deliverables
|
||||||
|
validates: completed_stories
|
||||||
|
notes: |
|
||||||
|
Sprint acceptance:
|
||||||
|
- Review demonstrated features
|
||||||
|
- Confirm acceptance criteria met
|
||||||
|
- Sign off on completed work
|
||||||
|
- Update story status to Done
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: sprint_retrospective
|
||||||
|
creates: sprint-retrospective.md
|
||||||
|
notes: |
|
||||||
|
Sprint retrospective:
|
||||||
|
- What went well
|
||||||
|
- What could improve
|
||||||
|
- Action items for next sprint
|
||||||
|
- Team velocity analysis
|
||||||
|
- Process improvements
|
||||||
|
|
||||||
|
- agent: bmad-master
|
||||||
|
action: update_memory_bank
|
||||||
|
uses: update-memory-bank
|
||||||
|
notes: |
|
||||||
|
Comprehensive Memory Bank update:
|
||||||
|
- Sprint outcomes to progress.md
|
||||||
|
- Technical decisions to systemPatterns.md
|
||||||
|
- Learnings to activeContext.md
|
||||||
|
- Update project velocity metrics
|
||||||
|
|
||||||
|
- workflow_end:
|
||||||
|
action: sprint_complete
|
||||||
|
notes: |
|
||||||
|
Sprint completed!
|
||||||
|
- All deliverables accepted
|
||||||
|
- Memory Bank updated
|
||||||
|
- Retrospective documented
|
||||||
|
- Ready for next sprint planning
|
||||||
|
|
||||||
|
flow_diagram: |
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[Start: Sprint] --> B[bmad-master: sprint kickoff]
|
||||||
|
B --> C[sm: sprint planning]
|
||||||
|
C --> D[po: approve sprint scope]
|
||||||
|
|
||||||
|
D --> E[Daily Cycle Start]
|
||||||
|
E --> F[sm: daily standup]
|
||||||
|
F --> G[dev: implement work]
|
||||||
|
G --> H[dev: daily journal]
|
||||||
|
H --> I{More days?}
|
||||||
|
I -->|Yes| E
|
||||||
|
I -->|No| J[sm: mid-sprint check]
|
||||||
|
|
||||||
|
J --> K{Adjustment needed?}
|
||||||
|
K -->|Yes| L[po: scope adjustment]
|
||||||
|
K -->|No| M[Continue development]
|
||||||
|
L --> M
|
||||||
|
|
||||||
|
M --> N[qa: continuous testing]
|
||||||
|
N --> O{Architecture decision?}
|
||||||
|
O -->|Yes| P[architect: create ADR]
|
||||||
|
O -->|No| Q[sm: prepare review]
|
||||||
|
P --> Q
|
||||||
|
|
||||||
|
Q --> R[sm: sprint review]
|
||||||
|
R --> S[po: accept deliverables]
|
||||||
|
S --> T[sm: retrospective]
|
||||||
|
T --> U[bmad-master: update Memory Bank]
|
||||||
|
U --> V[Sprint Complete]
|
||||||
|
|
||||||
|
style V fill:#90EE90
|
||||||
|
style B fill:#FFE4B5
|
||||||
|
style C fill:#FFE4B5
|
||||||
|
style R fill:#ADD8E6
|
||||||
|
style T fill:#F0E68C
|
||||||
|
style U fill:#DDA0DD
|
||||||
|
```
|
||||||
|
|
||||||
|
decision_guidance:
|
||||||
|
when_to_use:
|
||||||
|
- Team follows agile/scrum methodology
|
||||||
|
- Fixed-length iterations preferred
|
||||||
|
- Regular stakeholder reviews needed
|
||||||
|
- Continuous improvement focus
|
||||||
|
- Multiple stories per iteration
|
||||||
|
|
||||||
|
handoff_prompts:
|
||||||
|
kickoff_to_planning: "Sprint context initialized. Ready for sprint planning with backlog items."
|
||||||
|
planning_to_po: "Sprint plan created with {{story_count}} stories totaling {{story_points}} points. Please review and approve."
|
||||||
|
daily_standup: "Yesterday: {{completed_tasks}}. Today: {{planned_tasks}}. Blockers: {{blockers}}."
|
||||||
|
mid_sprint_alert: "Sprint health check: {{completion_percentage}}% complete. {{at_risk_count}} stories at risk."
|
||||||
|
review_ready: "Sprint review prepared. {{completed_stories}} stories ready for demonstration."
|
||||||
|
retrospective_complete: "Sprint retrospective complete. {{improvement_actions}} action items for next sprint."
|
||||||
|
complete: "Sprint {{sprint_number}} complete. Velocity: {{velocity}} points. Ready for next sprint planning."
|
||||||
|
|
@ -0,0 +1,340 @@
|
||||||
|
workflow:
|
||||||
|
id: system-migration
|
||||||
|
name: System Migration Workflow
|
||||||
|
description: >-
|
||||||
|
Agent workflow for technology migrations, platform upgrades, and system
|
||||||
|
modernization. Handles careful planning, phased implementation, rollback
|
||||||
|
procedures, and validation to ensure safe transitions.
|
||||||
|
type: migration
|
||||||
|
project_types:
|
||||||
|
- platform-migration
|
||||||
|
- framework-upgrade
|
||||||
|
- database-migration
|
||||||
|
- cloud-migration
|
||||||
|
- technology-modernization
|
||||||
|
|
||||||
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: comprehensive_context_load
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Comprehensive initialization:
|
||||||
|
- Full Memory Bank review
|
||||||
|
- Current architecture understanding
|
||||||
|
- Dependency analysis
|
||||||
|
- Integration points mapping
|
||||||
|
- Risk assessment preparation
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: current_state_analysis
|
||||||
|
creates: current-state-analysis.md
|
||||||
|
uses: document-project
|
||||||
|
notes: |
|
||||||
|
Document current state:
|
||||||
|
- Complete system architecture
|
||||||
|
- Technology stack details
|
||||||
|
- Dependencies and versions
|
||||||
|
- Integration points
|
||||||
|
- Performance baselines
|
||||||
|
- Known issues and constraints
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: target_state_design
|
||||||
|
creates: target-state-design.md
|
||||||
|
notes: |
|
||||||
|
Design target architecture:
|
||||||
|
- New technology stack
|
||||||
|
- Migration architecture
|
||||||
|
- Compatibility layers needed
|
||||||
|
- Performance targets
|
||||||
|
- Security improvements
|
||||||
|
- Scalability goals
|
||||||
|
|
||||||
|
- agent: analyst
|
||||||
|
action: gap_analysis
|
||||||
|
creates: migration-gap-analysis.md
|
||||||
|
requires:
|
||||||
|
- current-state-analysis.md
|
||||||
|
- target-state-design.md
|
||||||
|
notes: |
|
||||||
|
Analyze migration gaps:
|
||||||
|
- Technical gaps to bridge
|
||||||
|
- Feature parity assessment
|
||||||
|
- Data migration needs
|
||||||
|
- Training requirements
|
||||||
|
- Tool changes
|
||||||
|
- Process updates needed
|
||||||
|
|
||||||
|
- agent: pm
|
||||||
|
action: migration_planning
|
||||||
|
creates: migration-plan.md
|
||||||
|
requires: migration-gap-analysis.md
|
||||||
|
notes: |
|
||||||
|
Create migration plan:
|
||||||
|
- Phased approach design
|
||||||
|
- Timeline with milestones
|
||||||
|
- Resource requirements
|
||||||
|
- Risk mitigation strategies
|
||||||
|
- Rollback procedures
|
||||||
|
- Success criteria
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: migration_architecture
|
||||||
|
creates: migration-architecture.md
|
||||||
|
notes: |
|
||||||
|
Technical migration design:
|
||||||
|
- Parallel run strategy
|
||||||
|
- Data migration approach
|
||||||
|
- API compatibility layers
|
||||||
|
- Feature flags design
|
||||||
|
- Monitoring strategy
|
||||||
|
- Cutover procedures
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
validates: migration_plan
|
||||||
|
uses: po-master-checklist
|
||||||
|
notes: |
|
||||||
|
Validate migration approach:
|
||||||
|
- Business continuity assured
|
||||||
|
- Risk acceptable
|
||||||
|
- Timeline realistic
|
||||||
|
- Resources available
|
||||||
|
- Rollback viable
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: create_migration_tools
|
||||||
|
creates: migration-tools/
|
||||||
|
notes: |
|
||||||
|
Build migration utilities:
|
||||||
|
- Data migration scripts
|
||||||
|
- Compatibility adapters
|
||||||
|
- Validation tools
|
||||||
|
- Performance benchmarks
|
||||||
|
- Rollback scripts
|
||||||
|
- Monitoring setup
|
||||||
|
|
||||||
|
- migration_phases:
|
||||||
|
repeats: for_each_phase
|
||||||
|
sequence:
|
||||||
|
- agent: sm
|
||||||
|
action: phase_planning
|
||||||
|
creates: phase-plan.md
|
||||||
|
notes: |
|
||||||
|
Plan migration phase:
|
||||||
|
- Define phase scope
|
||||||
|
- Create detailed tasks
|
||||||
|
- Set success criteria
|
||||||
|
- Plan validation steps
|
||||||
|
- Schedule activities
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: implement_phase
|
||||||
|
updates: system_components
|
||||||
|
notes: |
|
||||||
|
Phase implementation:
|
||||||
|
- Migrate components
|
||||||
|
- Update configurations
|
||||||
|
- Modify integrations
|
||||||
|
- Apply compatibility layers
|
||||||
|
- Enable feature flags
|
||||||
|
|
||||||
|
- agent: qa
|
||||||
|
action: phase_validation
|
||||||
|
validates: migrated_components
|
||||||
|
notes: |
|
||||||
|
Comprehensive testing:
|
||||||
|
- Functional validation
|
||||||
|
- Performance testing
|
||||||
|
- Integration testing
|
||||||
|
- Security scanning
|
||||||
|
- Load testing
|
||||||
|
- Compatibility checks
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: parallel_run_validation
|
||||||
|
validates: system_parity
|
||||||
|
condition: parallel_run_phase
|
||||||
|
notes: |
|
||||||
|
Parallel run checks:
|
||||||
|
- Compare outputs
|
||||||
|
- Verify data consistency
|
||||||
|
- Performance comparison
|
||||||
|
- Error rate analysis
|
||||||
|
- Resource utilization
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
creates: adr-migration-phase.md
|
||||||
|
action: document_phase_decisions
|
||||||
|
notes: |
|
||||||
|
Document phase outcomes:
|
||||||
|
- Decisions made
|
||||||
|
- Issues encountered
|
||||||
|
- Workarounds applied
|
||||||
|
- Performance impacts
|
||||||
|
- Lessons learned
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
action: phase_signoff
|
||||||
|
validates: phase_completion
|
||||||
|
notes: |
|
||||||
|
Phase acceptance:
|
||||||
|
- Verify success criteria
|
||||||
|
- Review test results
|
||||||
|
- Approve continuation
|
||||||
|
- Update stakeholders
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
action: cutover_preparation
|
||||||
|
creates: cutover-checklist.md
|
||||||
|
notes: |
|
||||||
|
Prepare for cutover:
|
||||||
|
- Final validation checklist
|
||||||
|
- Cutover procedures
|
||||||
|
- Communication plan
|
||||||
|
- Rollback procedures
|
||||||
|
- Monitoring alerts
|
||||||
|
- Support readiness
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: final_validation
|
||||||
|
validates: system_readiness
|
||||||
|
notes: |
|
||||||
|
Pre-cutover validation:
|
||||||
|
- All components migrated
|
||||||
|
- Performance acceptable
|
||||||
|
- Security validated
|
||||||
|
- Integrations working
|
||||||
|
- Data integrity verified
|
||||||
|
- Rollback tested
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
action: cutover_approval
|
||||||
|
validates: go_live_readiness
|
||||||
|
notes: |
|
||||||
|
Final go-live approval:
|
||||||
|
- All criteria met
|
||||||
|
- Risks acceptable
|
||||||
|
- Team ready
|
||||||
|
- Communications sent
|
||||||
|
- Support prepared
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_migration
|
||||||
|
uses: create-dev-journal
|
||||||
|
notes: |
|
||||||
|
Document migration:
|
||||||
|
- Migration summary
|
||||||
|
- Issues and resolutions
|
||||||
|
- Performance changes
|
||||||
|
- Lessons learned
|
||||||
|
- Update Memory Bank
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: post_migration_review
|
||||||
|
creates: migration-review.md
|
||||||
|
notes: |
|
||||||
|
Post-migration review:
|
||||||
|
- Success metrics
|
||||||
|
- Issues encountered
|
||||||
|
- Performance analysis
|
||||||
|
- Cost analysis
|
||||||
|
- Team feedback
|
||||||
|
- Improvement recommendations
|
||||||
|
|
||||||
|
- workflow_end:
|
||||||
|
action: migration_complete
|
||||||
|
notes: |
|
||||||
|
Migration completed!
|
||||||
|
- System successfully migrated
|
||||||
|
- Performance validated
|
||||||
|
- Documentation updated
|
||||||
|
- Team trained
|
||||||
|
- Monitoring active
|
||||||
|
|
||||||
|
flow_diagram: |
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[Start: Migration] --> B[bmad-master: comprehensive init]
|
||||||
|
B --> C[architect: current state]
|
||||||
|
C --> D[architect: target state]
|
||||||
|
D --> E[analyst: gap analysis]
|
||||||
|
E --> F[pm: migration plan]
|
||||||
|
F --> G[architect: migration architecture]
|
||||||
|
G --> H[po: validate plan]
|
||||||
|
|
||||||
|
H --> I[dev: build tools]
|
||||||
|
I --> J[Migration Phases]
|
||||||
|
J --> K[sm: phase planning]
|
||||||
|
K --> L[dev: implement phase]
|
||||||
|
L --> M[qa: validate phase]
|
||||||
|
M --> N{Parallel run?}
|
||||||
|
N -->|Yes| O[dev: validate parity]
|
||||||
|
N -->|No| P[architect: document phase]
|
||||||
|
O --> P
|
||||||
|
P --> Q[po: phase signoff]
|
||||||
|
Q --> R{More phases?}
|
||||||
|
R -->|Yes| J
|
||||||
|
R -->|No| S[dev: cutover prep]
|
||||||
|
|
||||||
|
S --> T[architect: final validation]
|
||||||
|
T --> U[po: cutover approval]
|
||||||
|
U --> V[dev: document migration]
|
||||||
|
V --> W[sm: post-migration review]
|
||||||
|
W --> X[Migration Complete]
|
||||||
|
|
||||||
|
style X fill:#90EE90
|
||||||
|
style B fill:#FF6B6B
|
||||||
|
style H fill:#FFD700
|
||||||
|
style Q fill:#FFD700
|
||||||
|
style U fill:#FFD700
|
||||||
|
style L fill:#FFA500
|
||||||
|
style M fill:#FFA500
|
||||||
|
style T fill:#98FB98
|
||||||
|
```
|
||||||
|
|
||||||
|
decision_guidance:
|
||||||
|
when_to_use:
|
||||||
|
- End-of-life technology
|
||||||
|
- Performance limitations
|
||||||
|
- Security vulnerabilities
|
||||||
|
- Scalability requirements
|
||||||
|
- Cost optimization needs
|
||||||
|
- Compliance requirements
|
||||||
|
|
||||||
|
handoff_prompts:
|
||||||
|
analysis_complete: |
|
||||||
|
Migration analysis complete:
|
||||||
|
- Current components: {{component_count}}
|
||||||
|
- Migration complexity: {{complexity_score}}/10
|
||||||
|
- Estimated phases: {{phase_count}}
|
||||||
|
- Risk level: {{risk_level}}
|
||||||
|
|
||||||
|
plan_ready: |
|
||||||
|
Migration plan created:
|
||||||
|
- Total phases: {{phase_count}}
|
||||||
|
- Timeline: {{timeline_weeks}} weeks
|
||||||
|
- Rollback points: {{rollback_count}}
|
||||||
|
- Success criteria defined
|
||||||
|
|
||||||
|
phase_complete: |
|
||||||
|
Phase {{phase_number}} complete:
|
||||||
|
- Components migrated: {{component_count}}
|
||||||
|
- Tests passed: {{test_pass_rate}}%
|
||||||
|
- Performance delta: {{performance_change}}%
|
||||||
|
- Issues resolved: {{issue_count}}
|
||||||
|
|
||||||
|
cutover_ready: |
|
||||||
|
System ready for cutover:
|
||||||
|
- All phases complete
|
||||||
|
- Validation passed: {{validation_score}}/100
|
||||||
|
- Rollback tested: Yes
|
||||||
|
- Team prepared: Yes
|
||||||
|
|
||||||
|
complete: |
|
||||||
|
Migration successful!
|
||||||
|
- Cutover completed: {{cutover_duration}}
|
||||||
|
- System stability: {{stability_metric}}
|
||||||
|
- Performance improvement: {{perf_improvement}}%
|
||||||
|
- Zero data loss confirmed
|
||||||
|
|
@ -0,0 +1,268 @@
|
||||||
|
workflow:
|
||||||
|
id: technical-debt
|
||||||
|
name: Technical Debt Reduction Workflow
|
||||||
|
description: >-
|
||||||
|
Agent workflow for systematic technical debt reduction. Focuses on identifying,
|
||||||
|
prioritizing, and safely eliminating technical debt while maintaining system
|
||||||
|
stability and documenting improvements.
|
||||||
|
type: maintenance
|
||||||
|
project_types:
|
||||||
|
- debt-reduction
|
||||||
|
- code-cleanup
|
||||||
|
- refactoring
|
||||||
|
- modernization
|
||||||
|
- system-health
|
||||||
|
|
||||||
|
sequence:
|
||||||
|
- step: session_initialization
|
||||||
|
agent: bmad-master
|
||||||
|
action: session_kickoff
|
||||||
|
uses: session-kickoff
|
||||||
|
notes: |
|
||||||
|
Initialize with debt focus:
|
||||||
|
- Review Memory Bank for known debt
|
||||||
|
- Check previous debt reduction efforts
|
||||||
|
- Review system patterns and pain points
|
||||||
|
- Understand current technical principles
|
||||||
|
- Check ADRs for debt-inducing decisions
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
action: debt_assessment
|
||||||
|
creates: debt-assessment.md
|
||||||
|
uses: document-project
|
||||||
|
notes: |
|
||||||
|
Comprehensive debt analysis:
|
||||||
|
- Code quality metrics analysis
|
||||||
|
- Dependency audit (outdated/vulnerable)
|
||||||
|
- Architecture anti-patterns
|
||||||
|
- Performance bottlenecks
|
||||||
|
- Security vulnerabilities
|
||||||
|
- Testing gaps
|
||||||
|
- Documentation debt
|
||||||
|
|
||||||
|
- agent: analyst
|
||||||
|
action: debt_prioritization
|
||||||
|
creates: debt-priorities.md
|
||||||
|
requires: debt-assessment.md
|
||||||
|
notes: |
|
||||||
|
Prioritize debt items:
|
||||||
|
- Risk assessment (security, stability)
|
||||||
|
- Business impact analysis
|
||||||
|
- Effort estimation
|
||||||
|
- Dependency mapping
|
||||||
|
- Quick wins identification
|
||||||
|
- Create debt backlog
|
||||||
|
|
||||||
|
- agent: pm
|
||||||
|
creates: debt-reduction-plan.md
|
||||||
|
action: create_debt_sprint_plan
|
||||||
|
requires: debt-priorities.md
|
||||||
|
notes: |
|
||||||
|
Plan debt reduction:
|
||||||
|
- Group related debt items
|
||||||
|
- Create epic for major debt areas
|
||||||
|
- Define success metrics
|
||||||
|
- Set realistic timelines
|
||||||
|
- Plan incremental improvements
|
||||||
|
- Balance with feature work
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
creates: refactoring-strategy.md
|
||||||
|
action: design_refactoring_approach
|
||||||
|
requires: debt-reduction-plan.md
|
||||||
|
notes: |
|
||||||
|
Technical approach:
|
||||||
|
- Define refactoring patterns
|
||||||
|
- Plan migration strategies
|
||||||
|
- Design new architecture
|
||||||
|
- Create rollback plans
|
||||||
|
- Define testing strategy
|
||||||
|
- Document constraints
|
||||||
|
|
||||||
|
- agent: po
|
||||||
|
validates: debt_reduction_plan
|
||||||
|
uses: po-master-checklist
|
||||||
|
notes: |
|
||||||
|
Validate approach:
|
||||||
|
- Confirm business value
|
||||||
|
- Verify risk mitigation
|
||||||
|
- Approve timeline
|
||||||
|
- Sign off on approach
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: create_debt_stories
|
||||||
|
creates: debt-stories/
|
||||||
|
uses: create-next-story
|
||||||
|
notes: |
|
||||||
|
Story creation:
|
||||||
|
- Break down into manageable stories
|
||||||
|
- Include refactoring in each story
|
||||||
|
- Add comprehensive test requirements
|
||||||
|
- Define clear acceptance criteria
|
||||||
|
- Include documentation updates
|
||||||
|
|
||||||
|
- development_cycle:
|
||||||
|
repeats: for_each_debt_story
|
||||||
|
sequence:
|
||||||
|
- agent: dev
|
||||||
|
action: implement_refactoring
|
||||||
|
updates: codebase
|
||||||
|
notes: |
|
||||||
|
Careful implementation:
|
||||||
|
- Follow Boy Scout Rule
|
||||||
|
- Maintain backward compatibility
|
||||||
|
- Add missing tests first
|
||||||
|
- Refactor incrementally
|
||||||
|
- Update documentation
|
||||||
|
|
||||||
|
- agent: qa
|
||||||
|
action: regression_testing
|
||||||
|
validates: refactored_code
|
||||||
|
notes: |
|
||||||
|
Thorough testing:
|
||||||
|
- Full regression suite
|
||||||
|
- Performance benchmarks
|
||||||
|
- Security scanning
|
||||||
|
- Integration tests
|
||||||
|
- Load testing if needed
|
||||||
|
|
||||||
|
- agent: architect
|
||||||
|
creates: adr.md
|
||||||
|
action: document_improvements
|
||||||
|
condition: significant_change
|
||||||
|
notes: |
|
||||||
|
Document decisions:
|
||||||
|
- Why refactoring was needed
|
||||||
|
- Approach taken
|
||||||
|
- Trade-offs made
|
||||||
|
- Patterns introduced
|
||||||
|
- Update Memory Bank
|
||||||
|
|
||||||
|
- agent: dev
|
||||||
|
creates: dev_journal_entry
|
||||||
|
action: document_debt_reduction
|
||||||
|
uses: create-dev-journal
|
||||||
|
condition: milestone_reached
|
||||||
|
notes: |
|
||||||
|
Document progress:
|
||||||
|
- Debt eliminated
|
||||||
|
- Patterns improved
|
||||||
|
- Metrics before/after
|
||||||
|
- Lessons learned
|
||||||
|
- Update Memory Bank
|
||||||
|
|
||||||
|
- agent: analyst
|
||||||
|
action: measure_improvement
|
||||||
|
creates: improvement-metrics.md
|
||||||
|
notes: |
|
||||||
|
Quantify improvements:
|
||||||
|
- Code quality metrics
|
||||||
|
- Performance improvements
|
||||||
|
- Test coverage increase
|
||||||
|
- Build time reduction
|
||||||
|
- Reduced vulnerabilities
|
||||||
|
- Developer productivity
|
||||||
|
|
||||||
|
- agent: sm
|
||||||
|
action: debt_sprint_review
|
||||||
|
uses: conduct-sprint-review
|
||||||
|
creates: debt-review-summary.md
|
||||||
|
notes: |
|
||||||
|
Review improvements:
|
||||||
|
- Present metrics
|
||||||
|
- Demonstrate improvements
|
||||||
|
- Show risk reduction
|
||||||
|
- Document remaining debt
|
||||||
|
- Plan next iteration
|
||||||
|
|
||||||
|
- agent: bmad-master
|
||||||
|
action: comprehensive_update
|
||||||
|
uses: update-memory-bank
|
||||||
|
notes: |
|
||||||
|
Update all documentation:
|
||||||
|
- New patterns to systemPatterns.md
|
||||||
|
- Progress to progress.md
|
||||||
|
- Remaining debt to activeContext.md
|
||||||
|
- Update technical context
|
||||||
|
|
||||||
|
- workflow_end:
|
||||||
|
action: debt_reduction_complete
|
||||||
|
notes: |
|
||||||
|
Debt reduction cycle complete!
|
||||||
|
- Metrics improved
|
||||||
|
- Documentation updated
|
||||||
|
- System more maintainable
|
||||||
|
- Team knowledge increased
|
||||||
|
|
||||||
|
flow_diagram: |
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[Start: Debt Reduction] --> B[bmad-master: session init]
|
||||||
|
B --> C[architect: assess debt]
|
||||||
|
C --> D[analyst: prioritize debt]
|
||||||
|
D --> E[pm: create plan]
|
||||||
|
E --> F[architect: refactoring strategy]
|
||||||
|
F --> G[po: validate approach]
|
||||||
|
|
||||||
|
G --> H[sm: create stories]
|
||||||
|
H --> I[Development Cycle]
|
||||||
|
I --> J[dev: implement refactoring]
|
||||||
|
J --> K[qa: regression testing]
|
||||||
|
K --> L{Significant change?}
|
||||||
|
L -->|Yes| M[architect: create ADR]
|
||||||
|
L -->|No| N{More stories?}
|
||||||
|
M --> N
|
||||||
|
N -->|Yes| I
|
||||||
|
N -->|No| O[dev: document progress]
|
||||||
|
|
||||||
|
O --> P[analyst: measure improvement]
|
||||||
|
P --> Q[sm: debt sprint review]
|
||||||
|
Q --> R[bmad-master: update Memory Bank]
|
||||||
|
R --> S[Debt Reduction Complete]
|
||||||
|
|
||||||
|
style S fill:#90EE90
|
||||||
|
style B fill:#DDA0DD
|
||||||
|
style C fill:#FFB6C1
|
||||||
|
style D fill:#FFB6C1
|
||||||
|
style P fill:#98FB98
|
||||||
|
style Q fill:#ADD8E6
|
||||||
|
style R fill:#DDA0DD
|
||||||
|
```
|
||||||
|
|
||||||
|
decision_guidance:
|
||||||
|
when_to_use:
|
||||||
|
- System becoming hard to maintain
|
||||||
|
- Frequent bugs in certain areas
|
||||||
|
- Performance degradation
|
||||||
|
- Security vulnerabilities accumulating
|
||||||
|
- Developer velocity decreasing
|
||||||
|
- Before major feature additions
|
||||||
|
|
||||||
|
handoff_prompts:
|
||||||
|
assessment_complete: |
|
||||||
|
Debt assessment complete:
|
||||||
|
- Critical items: {{critical_count}}
|
||||||
|
- High priority: {{high_count}}
|
||||||
|
- Total debt items: {{total_count}}
|
||||||
|
- Estimated effort: {{total_effort}} hours
|
||||||
|
|
||||||
|
plan_ready: |
|
||||||
|
Debt reduction plan created:
|
||||||
|
- Sprint 1 focus: {{sprint1_focus}}
|
||||||
|
- Quick wins: {{quick_wins_count}}
|
||||||
|
- Risk reduction: {{risk_reduction_percentage}}%
|
||||||
|
|
||||||
|
story_complete: |
|
||||||
|
Debt story {{story_id}} complete:
|
||||||
|
- Code quality: {{before_score}} → {{after_score}}
|
||||||
|
- Test coverage: {{before_coverage}}% → {{after_coverage}}%
|
||||||
|
- Performance: {{improvement_percentage}}% faster
|
||||||
|
|
||||||
|
review_summary: |
|
||||||
|
Debt reduction sprint complete:
|
||||||
|
- Stories completed: {{completed_count}}
|
||||||
|
- Debt eliminated: {{debt_points}} points
|
||||||
|
- System health: {{health_improvement}}% better
|
||||||
|
- Remaining debt: {{remaining_debt}} items
|
||||||
|
|
||||||
|
complete: "Technical debt reduction cycle complete. System health improved by {{overall_improvement}}%."
|
||||||
|
|
@ -26,6 +26,27 @@ If you have just completed an MVP with BMad, and you want to continue with post-
|
||||||
|
|
||||||
## The Complete Brownfield Workflow
|
## The Complete Brownfield Workflow
|
||||||
|
|
||||||
|
### Session Initialization (NEW - Critical First Step)
|
||||||
|
|
||||||
|
Before starting any brownfield work, proper context initialization is essential:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
@bmad-master
|
||||||
|
*session-kickoff
|
||||||
|
```
|
||||||
|
|
||||||
|
This will:
|
||||||
|
- Review existing Memory Bank files if available
|
||||||
|
- Check recent Dev Journal entries for current state
|
||||||
|
- Load relevant ADRs for architectural decisions
|
||||||
|
- Establish proper context for brownfield work
|
||||||
|
|
||||||
|
**Why This Matters for Brownfield**:
|
||||||
|
- Prevents duplicate work or conflicting decisions
|
||||||
|
- Ensures awareness of recent changes and patterns
|
||||||
|
- Maintains consistency with established practices
|
||||||
|
- Provides AI agents with critical historical context
|
||||||
|
|
||||||
### Choose Your Approach
|
### Choose Your Approach
|
||||||
|
|
||||||
#### Approach A: PRD-First (Recommended if adding very large and complex new features, single or multiple epics or massive changes)
|
#### Approach A: PRD-First (Recommended if adding very large and complex new features, single or multiple epics or massive changes)
|
||||||
|
|
@ -81,6 +102,7 @@ The analyst will:
|
||||||
- **Focus on relevant modules** identified in PRD or your description
|
- **Focus on relevant modules** identified in PRD or your description
|
||||||
- **Skip unrelated areas** to keep docs lean
|
- **Skip unrelated areas** to keep docs lean
|
||||||
- **Generate ONE architecture document** for all environments
|
- **Generate ONE architecture document** for all environments
|
||||||
|
- **Initialize Memory Bank** for the project if not exists
|
||||||
|
|
||||||
The analyst creates:
|
The analyst creates:
|
||||||
|
|
||||||
|
|
@ -88,6 +110,13 @@ The analyst creates:
|
||||||
- **Covers all system aspects** in a single file
|
- **Covers all system aspects** in a single file
|
||||||
- **Easy to copy and save** as `docs/project-architecture.md`
|
- **Easy to copy and save** as `docs/project-architecture.md`
|
||||||
- **Can be sharded later** in IDE if desired
|
- **Can be sharded later** in IDE if desired
|
||||||
|
- **Memory Bank initialization** with project context and patterns
|
||||||
|
|
||||||
|
**Memory Bank Integration**:
|
||||||
|
- Creates `docs/memory-bank/projectbrief.md` with project overview
|
||||||
|
- Populates `docs/memory-bank/techContext.md` with discovered stack
|
||||||
|
- Documents patterns in `docs/memory-bank/systemPatterns.md`
|
||||||
|
- Sets up `docs/memory-bank/activeContext.md` for ongoing work
|
||||||
|
|
||||||
For example, if you say "Add payment processing to user service":
|
For example, if you say "Add payment processing to user service":
|
||||||
|
|
||||||
|
|
@ -221,6 +250,14 @@ Follow the enhanced IDE Development Workflow:
|
||||||
- **SM** creates stories with integration awareness
|
- **SM** creates stories with integration awareness
|
||||||
- **Dev** implements with existing code respect
|
- **Dev** implements with existing code respect
|
||||||
- **QA** reviews for compatibility and improvements
|
- **QA** reviews for compatibility and improvements
|
||||||
|
- **Dev Journals** track daily progress and decisions
|
||||||
|
- **Sprint Reviews** ensure alignment and quality
|
||||||
|
|
||||||
|
4. **Continuous Documentation**:
|
||||||
|
- Create Dev Journal entries after significant work
|
||||||
|
- Update Memory Bank's `activeContext.md` with progress
|
||||||
|
- Document decisions in ADRs when making architectural changes
|
||||||
|
- Run sprint reviews to validate progress against goals
|
||||||
|
|
||||||
## Brownfield Best Practices
|
## Brownfield Best Practices
|
||||||
|
|
||||||
|
|
@ -268,6 +305,17 @@ Document:
|
||||||
- New patterns introduced
|
- New patterns introduced
|
||||||
- Deprecation notices
|
- Deprecation notices
|
||||||
|
|
||||||
|
### 6. Maintain Memory Bank (NEW)
|
||||||
|
|
||||||
|
Keep project context current:
|
||||||
|
|
||||||
|
- **Session Start**: Always run `*session-kickoff` to load context
|
||||||
|
- **During Work**: Update `activeContext.md` with current state
|
||||||
|
- **Pattern Discovery**: Document new patterns in `systemPatterns.md`
|
||||||
|
- **Progress Tracking**: Update `progress.md` with completed features
|
||||||
|
- **Tech Changes**: Keep `techContext.md` current with stack updates
|
||||||
|
- **Decision Records**: Create ADRs for significant architectural decisions
|
||||||
|
|
||||||
## Common Brownfield Scenarios
|
## Common Brownfield Scenarios
|
||||||
|
|
||||||
### Scenario 1: Adding a New Feature
|
### Scenario 1: Adding a New Feature
|
||||||
|
|
@ -321,6 +369,9 @@ Document:
|
||||||
### Brownfield-Specific Commands
|
### Brownfield-Specific Commands
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
|
# Initialize session with context (ALWAYS DO FIRST)
|
||||||
|
@bmad-master → *session-kickoff
|
||||||
|
|
||||||
# Document existing project
|
# Document existing project
|
||||||
@analyst → *document-project
|
@analyst → *document-project
|
||||||
|
|
||||||
|
|
@ -335,6 +386,13 @@ Document:
|
||||||
|
|
||||||
# Single story creation
|
# Single story creation
|
||||||
@pm → *brownfield-create-story
|
@pm → *brownfield-create-story
|
||||||
|
|
||||||
|
# Memory Bank operations
|
||||||
|
@bmad-master → *initialize-memory-bank
|
||||||
|
@bmad-master → *update-memory-bank
|
||||||
|
|
||||||
|
# Sprint ceremonies
|
||||||
|
@bmad-master → *conduct-sprint-review
|
||||||
```
|
```
|
||||||
|
|
||||||
### Decision Tree
|
### Decision Tree
|
||||||
|
|
|
||||||
|
|
@ -14,7 +14,7 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics.
|
This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics.
|
||||||
|
|
||||||
If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD.
|
If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD.
|
||||||
|
|
||||||
- id: introduction
|
- id: introduction
|
||||||
|
|
@ -22,7 +22,7 @@ sections:
|
||||||
instruction: Establish the document's purpose and scope for game development
|
instruction: Establish the document's purpose and scope for game development
|
||||||
content: |
|
content: |
|
||||||
This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems.
|
This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems.
|
||||||
|
|
||||||
This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility.
|
This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility.
|
||||||
sections:
|
sections:
|
||||||
- id: change-log
|
- id: change-log
|
||||||
|
|
@ -41,7 +41,7 @@ sections:
|
||||||
title: Architecture Summary
|
title: Architecture Summary
|
||||||
instruction: |
|
instruction: |
|
||||||
Provide a comprehensive overview covering:
|
Provide a comprehensive overview covering:
|
||||||
|
|
||||||
- Game engine choice and configuration
|
- Game engine choice and configuration
|
||||||
- Project structure and organization
|
- Project structure and organization
|
||||||
- Key systems and their interactions
|
- Key systems and their interactions
|
||||||
|
|
@ -129,23 +129,23 @@ sections:
|
||||||
title: Scene Management System
|
title: Scene Management System
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** Handle game flow and scene transitions
|
**Purpose:** Handle game flow and scene transitions
|
||||||
|
|
||||||
**Key Components:**
|
**Key Components:**
|
||||||
|
|
||||||
- Scene loading and unloading
|
- Scene loading and unloading
|
||||||
- Data passing between scenes
|
- Data passing between scenes
|
||||||
- Transition effects
|
- Transition effects
|
||||||
- Memory management
|
- Memory management
|
||||||
|
|
||||||
**Implementation Requirements:**
|
**Implementation Requirements:**
|
||||||
|
|
||||||
- Preload scene for asset loading
|
- Preload scene for asset loading
|
||||||
- Menu system with navigation
|
- Menu system with navigation
|
||||||
- Gameplay scenes with state management
|
- Gameplay scenes with state management
|
||||||
- Pause/resume functionality
|
- Pause/resume functionality
|
||||||
|
|
||||||
**Files to Create:**
|
**Files to Create:**
|
||||||
|
|
||||||
- `src/scenes/BootScene.ts`
|
- `src/scenes/BootScene.ts`
|
||||||
- `src/scenes/PreloadScene.ts`
|
- `src/scenes/PreloadScene.ts`
|
||||||
- `src/scenes/MenuScene.ts`
|
- `src/scenes/MenuScene.ts`
|
||||||
|
|
@ -155,23 +155,23 @@ sections:
|
||||||
title: Game State Management
|
title: Game State Management
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** Track player progress and game status
|
**Purpose:** Track player progress and game status
|
||||||
|
|
||||||
**State Categories:**
|
**State Categories:**
|
||||||
|
|
||||||
- Player progress (levels, unlocks)
|
- Player progress (levels, unlocks)
|
||||||
- Game settings (audio, controls)
|
- Game settings (audio, controls)
|
||||||
- Session data (current level, score)
|
- Session data (current level, score)
|
||||||
- Persistent data (achievements, statistics)
|
- Persistent data (achievements, statistics)
|
||||||
|
|
||||||
**Implementation Requirements:**
|
**Implementation Requirements:**
|
||||||
|
|
||||||
- Save/load system with localStorage
|
- Save/load system with localStorage
|
||||||
- State validation and error recovery
|
- State validation and error recovery
|
||||||
- Cross-session data persistence
|
- Cross-session data persistence
|
||||||
- Settings management
|
- Settings management
|
||||||
|
|
||||||
**Files to Create:**
|
**Files to Create:**
|
||||||
|
|
||||||
- `src/systems/GameState.ts`
|
- `src/systems/GameState.ts`
|
||||||
- `src/systems/SaveManager.ts`
|
- `src/systems/SaveManager.ts`
|
||||||
- `src/types/GameData.ts`
|
- `src/types/GameData.ts`
|
||||||
|
|
@ -179,23 +179,23 @@ sections:
|
||||||
title: Asset Management System
|
title: Asset Management System
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** Efficient loading and management of game assets
|
**Purpose:** Efficient loading and management of game assets
|
||||||
|
|
||||||
**Asset Categories:**
|
**Asset Categories:**
|
||||||
|
|
||||||
- Sprite sheets and animations
|
- Sprite sheets and animations
|
||||||
- Audio files and music
|
- Audio files and music
|
||||||
- Level data and configurations
|
- Level data and configurations
|
||||||
- UI assets and fonts
|
- UI assets and fonts
|
||||||
|
|
||||||
**Implementation Requirements:**
|
**Implementation Requirements:**
|
||||||
|
|
||||||
- Progressive loading strategy
|
- Progressive loading strategy
|
||||||
- Asset caching and optimization
|
- Asset caching and optimization
|
||||||
- Error handling for failed loads
|
- Error handling for failed loads
|
||||||
- Memory management for large assets
|
- Memory management for large assets
|
||||||
|
|
||||||
**Files to Create:**
|
**Files to Create:**
|
||||||
|
|
||||||
- `src/systems/AssetManager.ts`
|
- `src/systems/AssetManager.ts`
|
||||||
- `src/config/AssetConfig.ts`
|
- `src/config/AssetConfig.ts`
|
||||||
- `src/utils/AssetLoader.ts`
|
- `src/utils/AssetLoader.ts`
|
||||||
|
|
@ -203,23 +203,23 @@ sections:
|
||||||
title: Input Management System
|
title: Input Management System
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** Handle all player input across platforms
|
**Purpose:** Handle all player input across platforms
|
||||||
|
|
||||||
**Input Types:**
|
**Input Types:**
|
||||||
|
|
||||||
- Keyboard controls
|
- Keyboard controls
|
||||||
- Mouse/pointer interaction
|
- Mouse/pointer interaction
|
||||||
- Touch gestures (mobile)
|
- Touch gestures (mobile)
|
||||||
- Gamepad support (optional)
|
- Gamepad support (optional)
|
||||||
|
|
||||||
**Implementation Requirements:**
|
**Implementation Requirements:**
|
||||||
|
|
||||||
- Input mapping and configuration
|
- Input mapping and configuration
|
||||||
- Touch-friendly mobile controls
|
- Touch-friendly mobile controls
|
||||||
- Input buffering for responsive gameplay
|
- Input buffering for responsive gameplay
|
||||||
- Customizable control schemes
|
- Customizable control schemes
|
||||||
|
|
||||||
**Files to Create:**
|
**Files to Create:**
|
||||||
|
|
||||||
- `src/systems/InputManager.ts`
|
- `src/systems/InputManager.ts`
|
||||||
- `src/utils/TouchControls.ts`
|
- `src/utils/TouchControls.ts`
|
||||||
- `src/types/InputTypes.ts`
|
- `src/types/InputTypes.ts`
|
||||||
|
|
@ -232,19 +232,19 @@ sections:
|
||||||
title: "{{mechanic_name}} System"
|
title: "{{mechanic_name}} System"
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** {{system_purpose}}
|
**Purpose:** {{system_purpose}}
|
||||||
|
|
||||||
**Core Functionality:**
|
**Core Functionality:**
|
||||||
|
|
||||||
- {{feature_1}}
|
- {{feature_1}}
|
||||||
- {{feature_2}}
|
- {{feature_2}}
|
||||||
- {{feature_3}}
|
- {{feature_3}}
|
||||||
|
|
||||||
**Dependencies:** {{required_systems}}
|
**Dependencies:** {{required_systems}}
|
||||||
|
|
||||||
**Performance Considerations:** {{optimization_notes}}
|
**Performance Considerations:** {{optimization_notes}}
|
||||||
|
|
||||||
**Files to Create:**
|
**Files to Create:**
|
||||||
|
|
||||||
- `src/systems/{{system_name}}.ts`
|
- `src/systems/{{system_name}}.ts`
|
||||||
- `src/gameObjects/{{related_object}}.ts`
|
- `src/gameObjects/{{related_object}}.ts`
|
||||||
- `src/types/{{system_types}}.ts`
|
- `src/types/{{system_types}}.ts`
|
||||||
|
|
@ -252,65 +252,65 @@ sections:
|
||||||
title: Physics & Collision System
|
title: Physics & Collision System
|
||||||
template: |
|
template: |
|
||||||
**Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js)
|
**Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js)
|
||||||
|
|
||||||
**Collision Categories:**
|
**Collision Categories:**
|
||||||
|
|
||||||
- Player collision
|
- Player collision
|
||||||
- Enemy interactions
|
- Enemy interactions
|
||||||
- Environmental objects
|
- Environmental objects
|
||||||
- Collectibles and items
|
- Collectibles and items
|
||||||
|
|
||||||
**Implementation Requirements:**
|
**Implementation Requirements:**
|
||||||
|
|
||||||
- Optimized collision detection
|
- Optimized collision detection
|
||||||
- Physics body management
|
- Physics body management
|
||||||
- Collision callbacks and events
|
- Collision callbacks and events
|
||||||
- Performance monitoring
|
- Performance monitoring
|
||||||
|
|
||||||
**Files to Create:**
|
**Files to Create:**
|
||||||
|
|
||||||
- `src/systems/PhysicsManager.ts`
|
- `src/systems/PhysicsManager.ts`
|
||||||
- `src/utils/CollisionGroups.ts`
|
- `src/utils/CollisionGroups.ts`
|
||||||
- id: audio-system
|
- id: audio-system
|
||||||
title: Audio System
|
title: Audio System
|
||||||
template: |
|
template: |
|
||||||
**Audio Requirements:**
|
**Audio Requirements:**
|
||||||
|
|
||||||
- Background music with looping
|
- Background music with looping
|
||||||
- Sound effects for actions
|
- Sound effects for actions
|
||||||
- Audio settings and volume control
|
- Audio settings and volume control
|
||||||
- Mobile audio optimization
|
- Mobile audio optimization
|
||||||
|
|
||||||
**Implementation Features:**
|
**Implementation Features:**
|
||||||
|
|
||||||
- Audio sprite management
|
- Audio sprite management
|
||||||
- Dynamic music system
|
- Dynamic music system
|
||||||
- Spatial audio (if applicable)
|
- Spatial audio (if applicable)
|
||||||
- Audio pooling for performance
|
- Audio pooling for performance
|
||||||
|
|
||||||
**Files to Create:**
|
**Files to Create:**
|
||||||
|
|
||||||
- `src/systems/AudioManager.ts`
|
- `src/systems/AudioManager.ts`
|
||||||
- `src/config/AudioConfig.ts`
|
- `src/config/AudioConfig.ts`
|
||||||
- id: ui-system
|
- id: ui-system
|
||||||
title: UI System
|
title: UI System
|
||||||
template: |
|
template: |
|
||||||
**UI Components:**
|
**UI Components:**
|
||||||
|
|
||||||
- HUD elements (score, health, etc.)
|
- HUD elements (score, health, etc.)
|
||||||
- Menu navigation
|
- Menu navigation
|
||||||
- Modal dialogs
|
- Modal dialogs
|
||||||
- Settings screens
|
- Settings screens
|
||||||
|
|
||||||
**Implementation Requirements:**
|
**Implementation Requirements:**
|
||||||
|
|
||||||
- Responsive layout system
|
- Responsive layout system
|
||||||
- Touch-friendly interface
|
- Touch-friendly interface
|
||||||
- Keyboard navigation support
|
- Keyboard navigation support
|
||||||
- Animation and transitions
|
- Animation and transitions
|
||||||
|
|
||||||
**Files to Create:**
|
**Files to Create:**
|
||||||
|
|
||||||
- `src/systems/UIManager.ts`
|
- `src/systems/UIManager.ts`
|
||||||
- `src/gameObjects/UI/`
|
- `src/gameObjects/UI/`
|
||||||
- `src/types/UITypes.ts`
|
- `src/types/UITypes.ts`
|
||||||
|
|
@ -610,4 +610,4 @@ sections:
|
||||||
- 90%+ test coverage on game logic
|
- 90%+ test coverage on game logic
|
||||||
- Zero TypeScript errors in strict mode
|
- Zero TypeScript errors in strict mode
|
||||||
- Consistent adherence to coding standards
|
- Consistent adherence to coding standards
|
||||||
- Comprehensive documentation coverage
|
- Comprehensive documentation coverage
|
||||||
|
|
|
||||||
|
|
@ -14,7 +14,7 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
|
This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
|
||||||
|
|
||||||
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.
|
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.
|
||||||
|
|
||||||
- id: game-vision
|
- id: game-vision
|
||||||
|
|
@ -71,7 +71,7 @@ sections:
|
||||||
repeatable: true
|
repeatable: true
|
||||||
template: |
|
template: |
|
||||||
**Core Mechanic: {{mechanic_name}}**
|
**Core Mechanic: {{mechanic_name}}**
|
||||||
|
|
||||||
- **Description:** {{how_it_works}}
|
- **Description:** {{how_it_works}}
|
||||||
- **Player Value:** {{why_its_fun}}
|
- **Player Value:** {{why_its_fun}}
|
||||||
- **Implementation Scope:** {{complexity_estimate}}
|
- **Implementation Scope:** {{complexity_estimate}}
|
||||||
|
|
@ -98,12 +98,12 @@ sections:
|
||||||
title: Technical Constraints
|
title: Technical Constraints
|
||||||
template: |
|
template: |
|
||||||
**Platform Requirements:**
|
**Platform Requirements:**
|
||||||
|
|
||||||
- Primary: {{platform_1}} - {{requirements}}
|
- Primary: {{platform_1}} - {{requirements}}
|
||||||
- Secondary: {{platform_2}} - {{requirements}}
|
- Secondary: {{platform_2}} - {{requirements}}
|
||||||
|
|
||||||
**Technical Specifications:**
|
**Technical Specifications:**
|
||||||
|
|
||||||
- Engine: Phaser 3 + TypeScript
|
- Engine: Phaser 3 + TypeScript
|
||||||
- Performance Target: {{fps_target}} FPS on {{target_device}}
|
- Performance Target: {{fps_target}} FPS on {{target_device}}
|
||||||
- Memory Budget: <{{memory_limit}}MB
|
- Memory Budget: <{{memory_limit}}MB
|
||||||
|
|
@ -141,10 +141,10 @@ sections:
|
||||||
title: Competitive Analysis
|
title: Competitive Analysis
|
||||||
template: |
|
template: |
|
||||||
**Direct Competitors:**
|
**Direct Competitors:**
|
||||||
|
|
||||||
- {{competitor_1}}: {{strengths_and_weaknesses}}
|
- {{competitor_1}}: {{strengths_and_weaknesses}}
|
||||||
- {{competitor_2}}: {{strengths_and_weaknesses}}
|
- {{competitor_2}}: {{strengths_and_weaknesses}}
|
||||||
|
|
||||||
**Differentiation Strategy:**
|
**Differentiation Strategy:**
|
||||||
{{how_we_differ_and_why_thats_valuable}}
|
{{how_we_differ_and_why_thats_valuable}}
|
||||||
- id: market-opportunity
|
- id: market-opportunity
|
||||||
|
|
@ -168,16 +168,16 @@ sections:
|
||||||
title: Content Categories
|
title: Content Categories
|
||||||
template: |
|
template: |
|
||||||
**Core Content:**
|
**Core Content:**
|
||||||
|
|
||||||
- {{content_type_1}}: {{quantity_and_description}}
|
- {{content_type_1}}: {{quantity_and_description}}
|
||||||
- {{content_type_2}}: {{quantity_and_description}}
|
- {{content_type_2}}: {{quantity_and_description}}
|
||||||
|
|
||||||
**Optional Content:**
|
**Optional Content:**
|
||||||
|
|
||||||
- {{optional_content_type}}: {{quantity_and_description}}
|
- {{optional_content_type}}: {{quantity_and_description}}
|
||||||
|
|
||||||
**Replay Elements:**
|
**Replay Elements:**
|
||||||
|
|
||||||
- {{replayability_features}}
|
- {{replayability_features}}
|
||||||
- id: difficulty-accessibility
|
- id: difficulty-accessibility
|
||||||
title: Difficulty and Accessibility
|
title: Difficulty and Accessibility
|
||||||
|
|
@ -244,13 +244,13 @@ sections:
|
||||||
title: Player Experience Metrics
|
title: Player Experience Metrics
|
||||||
template: |
|
template: |
|
||||||
**Engagement Goals:**
|
**Engagement Goals:**
|
||||||
|
|
||||||
- Tutorial completion rate: >{{percentage}}%
|
- Tutorial completion rate: >{{percentage}}%
|
||||||
- Average session length: {{duration}} minutes
|
- Average session length: {{duration}} minutes
|
||||||
- Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}%
|
- Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}%
|
||||||
|
|
||||||
**Quality Benchmarks:**
|
**Quality Benchmarks:**
|
||||||
|
|
||||||
- Player satisfaction: >{{rating}}/10
|
- Player satisfaction: >{{rating}}/10
|
||||||
- Completion rate: >{{percentage}}%
|
- Completion rate: >{{percentage}}%
|
||||||
- Technical performance: {{fps_target}} FPS consistent
|
- Technical performance: {{fps_target}} FPS consistent
|
||||||
|
|
@ -258,13 +258,13 @@ sections:
|
||||||
title: Development Metrics
|
title: Development Metrics
|
||||||
template: |
|
template: |
|
||||||
**Technical Targets:**
|
**Technical Targets:**
|
||||||
|
|
||||||
- Zero critical bugs at launch
|
- Zero critical bugs at launch
|
||||||
- Performance targets met on all platforms
|
- Performance targets met on all platforms
|
||||||
- Load times under {{seconds}}s
|
- Load times under {{seconds}}s
|
||||||
|
|
||||||
**Process Goals:**
|
**Process Goals:**
|
||||||
|
|
||||||
- Development timeline adherence
|
- Development timeline adherence
|
||||||
- Feature scope completion
|
- Feature scope completion
|
||||||
- Quality assurance standards
|
- Quality assurance standards
|
||||||
|
|
@ -273,7 +273,7 @@ sections:
|
||||||
condition: has_business_goals
|
condition: has_business_goals
|
||||||
template: |
|
template: |
|
||||||
**Commercial Goals:**
|
**Commercial Goals:**
|
||||||
|
|
||||||
- {{revenue_target}} in first {{time_period}}
|
- {{revenue_target}} in first {{time_period}}
|
||||||
- {{user_acquisition_target}} players in first {{time_period}}
|
- {{user_acquisition_target}} players in first {{time_period}}
|
||||||
- {{retention_target}} monthly active users
|
- {{retention_target}} monthly active users
|
||||||
|
|
@ -326,12 +326,12 @@ sections:
|
||||||
title: Validation Plan
|
title: Validation Plan
|
||||||
template: |
|
template: |
|
||||||
**Concept Testing:**
|
**Concept Testing:**
|
||||||
|
|
||||||
- {{validation_method_1}} - {{timeline}}
|
- {{validation_method_1}} - {{timeline}}
|
||||||
- {{validation_method_2}} - {{timeline}}
|
- {{validation_method_2}} - {{timeline}}
|
||||||
|
|
||||||
**Prototype Testing:**
|
**Prototype Testing:**
|
||||||
|
|
||||||
- {{testing_approach}} - {{timeline}}
|
- {{testing_approach}} - {{timeline}}
|
||||||
- {{feedback_collection_method}} - {{timeline}}
|
- {{feedback_collection_method}} - {{timeline}}
|
||||||
|
|
||||||
|
|
@ -353,4 +353,4 @@ sections:
|
||||||
type: table
|
type: table
|
||||||
template: |
|
template: |
|
||||||
| Date | Version | Description | Author |
|
| Date | Version | Description | Author |
|
||||||
| :--- | :------ | :---------- | :----- |
|
| :--- | :------ | :---------- | :----- |
|
||||||
|
|
|
||||||
|
|
@ -14,7 +14,7 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
|
This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
|
||||||
|
|
||||||
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis
|
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis
|
||||||
|
|
||||||
- id: executive-summary
|
- id: executive-summary
|
||||||
|
|
@ -59,7 +59,7 @@ sections:
|
||||||
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.
|
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.
|
||||||
template: |
|
template: |
|
||||||
**Primary Loop ({{duration}} seconds):**
|
**Primary Loop ({{duration}} seconds):**
|
||||||
|
|
||||||
1. {{action_1}} ({{time_1}}s)
|
1. {{action_1}} ({{time_1}}s)
|
||||||
2. {{action_2}} ({{time_2}}s)
|
2. {{action_2}} ({{time_2}}s)
|
||||||
3. {{action_3}} ({{time_3}}s)
|
3. {{action_3}} ({{time_3}}s)
|
||||||
|
|
@ -69,12 +69,12 @@ sections:
|
||||||
instruction: Clearly define success and failure states
|
instruction: Clearly define success and failure states
|
||||||
template: |
|
template: |
|
||||||
**Victory Conditions:**
|
**Victory Conditions:**
|
||||||
|
|
||||||
- {{win_condition_1}}
|
- {{win_condition_1}}
|
||||||
- {{win_condition_2}}
|
- {{win_condition_2}}
|
||||||
|
|
||||||
**Failure States:**
|
**Failure States:**
|
||||||
|
|
||||||
- {{loss_condition_1}}
|
- {{loss_condition_1}}
|
||||||
- {{loss_condition_2}}
|
- {{loss_condition_2}}
|
||||||
|
|
||||||
|
|
@ -90,17 +90,17 @@ sections:
|
||||||
title: "{{mechanic_name}}"
|
title: "{{mechanic_name}}"
|
||||||
template: |
|
template: |
|
||||||
**Description:** {{detailed_description}}
|
**Description:** {{detailed_description}}
|
||||||
|
|
||||||
**Player Input:** {{input_method}}
|
**Player Input:** {{input_method}}
|
||||||
|
|
||||||
**System Response:** {{game_response}}
|
**System Response:** {{game_response}}
|
||||||
|
|
||||||
**Implementation Notes:**
|
**Implementation Notes:**
|
||||||
|
|
||||||
- {{tech_requirement_1}}
|
- {{tech_requirement_1}}
|
||||||
- {{tech_requirement_2}}
|
- {{tech_requirement_2}}
|
||||||
- {{performance_consideration}}
|
- {{performance_consideration}}
|
||||||
|
|
||||||
**Dependencies:** {{other_mechanics_needed}}
|
**Dependencies:** {{other_mechanics_needed}}
|
||||||
- id: controls
|
- id: controls
|
||||||
title: Controls
|
title: Controls
|
||||||
|
|
@ -119,9 +119,9 @@ sections:
|
||||||
title: Player Progression
|
title: Player Progression
|
||||||
template: |
|
template: |
|
||||||
**Progression Type:** {{linear|branching|metroidvania}}
|
**Progression Type:** {{linear|branching|metroidvania}}
|
||||||
|
|
||||||
**Key Milestones:**
|
**Key Milestones:**
|
||||||
|
|
||||||
1. **{{milestone_1}}** - {{unlock_description}}
|
1. **{{milestone_1}}** - {{unlock_description}}
|
||||||
2. **{{milestone_2}}** - {{unlock_description}}
|
2. **{{milestone_2}}** - {{unlock_description}}
|
||||||
3. **{{milestone_3}}** - {{unlock_description}}
|
3. **{{milestone_3}}** - {{unlock_description}}
|
||||||
|
|
@ -158,9 +158,9 @@ sections:
|
||||||
**Duration:** {{target_time}}
|
**Duration:** {{target_time}}
|
||||||
**Key Elements:** {{required_mechanics}}
|
**Key Elements:** {{required_mechanics}}
|
||||||
**Difficulty:** {{relative_difficulty}}
|
**Difficulty:** {{relative_difficulty}}
|
||||||
|
|
||||||
**Structure Template:**
|
**Structure Template:**
|
||||||
|
|
||||||
- Introduction: {{intro_description}}
|
- Introduction: {{intro_description}}
|
||||||
- Challenge: {{main_challenge}}
|
- Challenge: {{main_challenge}}
|
||||||
- Resolution: {{completion_requirement}}
|
- Resolution: {{completion_requirement}}
|
||||||
|
|
@ -186,13 +186,13 @@ sections:
|
||||||
title: Platform Specific
|
title: Platform Specific
|
||||||
template: |
|
template: |
|
||||||
**Desktop:**
|
**Desktop:**
|
||||||
|
|
||||||
- Resolution: {{min_resolution}} - {{max_resolution}}
|
- Resolution: {{min_resolution}} - {{max_resolution}}
|
||||||
- Input: Keyboard, Mouse, Gamepad
|
- Input: Keyboard, Mouse, Gamepad
|
||||||
- Browser: Chrome 80+, Firefox 75+, Safari 13+
|
- Browser: Chrome 80+, Firefox 75+, Safari 13+
|
||||||
|
|
||||||
**Mobile:**
|
**Mobile:**
|
||||||
|
|
||||||
- Resolution: {{mobile_min}} - {{mobile_max}}
|
- Resolution: {{mobile_min}} - {{mobile_max}}
|
||||||
- Input: Touch, Tilt (optional)
|
- Input: Touch, Tilt (optional)
|
||||||
- OS: iOS 13+, Android 8+
|
- OS: iOS 13+, Android 8+
|
||||||
|
|
@ -201,14 +201,14 @@ sections:
|
||||||
instruction: Define asset specifications for the art and audio teams
|
instruction: Define asset specifications for the art and audio teams
|
||||||
template: |
|
template: |
|
||||||
**Visual Assets:**
|
**Visual Assets:**
|
||||||
|
|
||||||
- Art Style: {{style_description}}
|
- Art Style: {{style_description}}
|
||||||
- Color Palette: {{color_specification}}
|
- Color Palette: {{color_specification}}
|
||||||
- Animation: {{animation_requirements}}
|
- Animation: {{animation_requirements}}
|
||||||
- UI Resolution: {{ui_specs}}
|
- UI Resolution: {{ui_specs}}
|
||||||
|
|
||||||
**Audio Assets:**
|
**Audio Assets:**
|
||||||
|
|
||||||
- Music Style: {{music_genre}}
|
- Music Style: {{music_genre}}
|
||||||
- Sound Effects: {{sfx_requirements}}
|
- Sound Effects: {{sfx_requirements}}
|
||||||
- Voice Acting: {{voice_needs}}
|
- Voice Acting: {{voice_needs}}
|
||||||
|
|
@ -221,7 +221,7 @@ sections:
|
||||||
title: Engine Configuration
|
title: Engine Configuration
|
||||||
template: |
|
template: |
|
||||||
**Phaser 3 Setup:**
|
**Phaser 3 Setup:**
|
||||||
|
|
||||||
- TypeScript: Strict mode enabled
|
- TypeScript: Strict mode enabled
|
||||||
- Physics: {{physics_system}} (Arcade/Matter)
|
- Physics: {{physics_system}} (Arcade/Matter)
|
||||||
- Renderer: WebGL with Canvas fallback
|
- Renderer: WebGL with Canvas fallback
|
||||||
|
|
@ -230,7 +230,7 @@ sections:
|
||||||
title: Code Architecture
|
title: Code Architecture
|
||||||
template: |
|
template: |
|
||||||
**Required Systems:**
|
**Required Systems:**
|
||||||
|
|
||||||
- Scene Management
|
- Scene Management
|
||||||
- State Management
|
- State Management
|
||||||
- Asset Loading
|
- Asset Loading
|
||||||
|
|
@ -242,7 +242,7 @@ sections:
|
||||||
title: Data Management
|
title: Data Management
|
||||||
template: |
|
template: |
|
||||||
**Save Data:**
|
**Save Data:**
|
||||||
|
|
||||||
- Progress tracking
|
- Progress tracking
|
||||||
- Settings persistence
|
- Settings persistence
|
||||||
- Statistics collection
|
- Statistics collection
|
||||||
|
|
@ -340,4 +340,4 @@ sections:
|
||||||
title: References
|
title: References
|
||||||
instruction: List any competitive analysis, inspiration, or research sources
|
instruction: List any competitive analysis, inspiration, or research sources
|
||||||
type: bullet-list
|
type: bullet-list
|
||||||
template: "{{reference}}"
|
template: "{{reference}}"
|
||||||
|
|
|
||||||
|
|
@ -14,13 +14,13 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
|
This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
|
||||||
|
|
||||||
Before starting, ensure you have access to:
|
Before starting, ensure you have access to:
|
||||||
|
|
||||||
- Game Design Document (GDD)
|
- Game Design Document (GDD)
|
||||||
- Game Architecture Document
|
- Game Architecture Document
|
||||||
- Any existing stories in this epic
|
- Any existing stories in this epic
|
||||||
|
|
||||||
The story should be specific enough that a developer can implement it without requiring additional design decisions.
|
The story should be specific enough that a developer can implement it without requiring additional design decisions.
|
||||||
|
|
||||||
- id: story-header
|
- id: story-header
|
||||||
|
|
@ -69,12 +69,12 @@ sections:
|
||||||
title: Files to Create/Modify
|
title: Files to Create/Modify
|
||||||
template: |
|
template: |
|
||||||
**New Files:**
|
**New Files:**
|
||||||
|
|
||||||
- `{{file_path_1}}` - {{purpose}}
|
- `{{file_path_1}}` - {{purpose}}
|
||||||
- `{{file_path_2}}` - {{purpose}}
|
- `{{file_path_2}}` - {{purpose}}
|
||||||
|
|
||||||
**Modified Files:**
|
**Modified Files:**
|
||||||
|
|
||||||
- `{{existing_file_1}}` - {{changes_needed}}
|
- `{{existing_file_1}}` - {{changes_needed}}
|
||||||
- `{{existing_file_2}}` - {{changes_needed}}
|
- `{{existing_file_2}}` - {{changes_needed}}
|
||||||
- id: class-interface-definitions
|
- id: class-interface-definitions
|
||||||
|
|
@ -89,15 +89,15 @@ sections:
|
||||||
{{property_2}}: {{type}};
|
{{property_2}}: {{type}};
|
||||||
{{method_1}}({{params}}): {{return_type}};
|
{{method_1}}({{params}}): {{return_type}};
|
||||||
}
|
}
|
||||||
|
|
||||||
// {{class_name}}
|
// {{class_name}}
|
||||||
class {{class_name}} extends {{phaser_class}} {
|
class {{class_name}} extends {{phaser_class}} {
|
||||||
private {{property}}: {{type}};
|
private {{property}}: {{type}};
|
||||||
|
|
||||||
constructor({{params}}) {
|
constructor({{params}}) {
|
||||||
// Implementation requirements
|
// Implementation requirements
|
||||||
}
|
}
|
||||||
|
|
||||||
public {{method}}({{params}}): {{return_type}} {
|
public {{method}}({{params}}): {{return_type}} {
|
||||||
// Method requirements
|
// Method requirements
|
||||||
}
|
}
|
||||||
|
|
@ -107,15 +107,15 @@ sections:
|
||||||
instruction: Specify how this feature integrates with existing systems
|
instruction: Specify how this feature integrates with existing systems
|
||||||
template: |
|
template: |
|
||||||
**Scene Integration:**
|
**Scene Integration:**
|
||||||
|
|
||||||
- {{scene_name}}: {{integration_details}}
|
- {{scene_name}}: {{integration_details}}
|
||||||
|
|
||||||
**System Dependencies:**
|
**System Dependencies:**
|
||||||
|
|
||||||
- {{system_name}}: {{dependency_description}}
|
- {{system_name}}: {{dependency_description}}
|
||||||
|
|
||||||
**Event Communication:**
|
**Event Communication:**
|
||||||
|
|
||||||
- Emits: `{{event_name}}` when {{condition}}
|
- Emits: `{{event_name}}` when {{condition}}
|
||||||
- Listens: `{{event_name}}` to {{response}}
|
- Listens: `{{event_name}}` to {{response}}
|
||||||
|
|
||||||
|
|
@ -127,7 +127,7 @@ sections:
|
||||||
title: Dev Agent Record
|
title: Dev Agent Record
|
||||||
template: |
|
template: |
|
||||||
**Tasks:**
|
**Tasks:**
|
||||||
|
|
||||||
- [ ] {{task_1_description}}
|
- [ ] {{task_1_description}}
|
||||||
- [ ] {{task_2_description}}
|
- [ ] {{task_2_description}}
|
||||||
- [ ] {{task_3_description}}
|
- [ ] {{task_3_description}}
|
||||||
|
|
@ -135,18 +135,18 @@ sections:
|
||||||
- [ ] Write unit tests for {{component}}
|
- [ ] Write unit tests for {{component}}
|
||||||
- [ ] Integration testing with {{related_system}}
|
- [ ] Integration testing with {{related_system}}
|
||||||
- [ ] Performance testing and optimization
|
- [ ] Performance testing and optimization
|
||||||
|
|
||||||
**Debug Log:**
|
**Debug Log:**
|
||||||
| Task | File | Change | Reverted? |
|
| Task | File | Change | Reverted? |
|
||||||
|------|------|--------|-----------|
|
|------|------|--------|-----------|
|
||||||
| | | | |
|
| | | | |
|
||||||
|
|
||||||
**Completion Notes:**
|
**Completion Notes:**
|
||||||
|
|
||||||
<!-- Only note deviations from requirements, keep under 50 words -->
|
<!-- Only note deviations from requirements, keep under 50 words -->
|
||||||
|
|
||||||
**Change Log:**
|
**Change Log:**
|
||||||
|
|
||||||
<!-- Only requirement changes during implementation -->
|
<!-- Only requirement changes during implementation -->
|
||||||
|
|
||||||
- id: game-design-context
|
- id: game-design-context
|
||||||
|
|
@ -154,13 +154,13 @@ sections:
|
||||||
instruction: Reference the specific sections of the GDD that this story implements
|
instruction: Reference the specific sections of the GDD that this story implements
|
||||||
template: |
|
template: |
|
||||||
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
|
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
|
||||||
|
|
||||||
**Game Mechanic:** {{mechanic_name}}
|
**Game Mechanic:** {{mechanic_name}}
|
||||||
|
|
||||||
**Player Experience Goal:** {{experience_description}}
|
**Player Experience Goal:** {{experience_description}}
|
||||||
|
|
||||||
**Balance Parameters:**
|
**Balance Parameters:**
|
||||||
|
|
||||||
- {{parameter_1}}: {{value_or_range}}
|
- {{parameter_1}}: {{value_or_range}}
|
||||||
- {{parameter_2}}: {{value_or_range}}
|
- {{parameter_2}}: {{value_or_range}}
|
||||||
|
|
||||||
|
|
@ -172,11 +172,11 @@ sections:
|
||||||
title: Unit Tests
|
title: Unit Tests
|
||||||
template: |
|
template: |
|
||||||
**Test Files:**
|
**Test Files:**
|
||||||
|
|
||||||
- `tests/{{component_name}}.test.ts`
|
- `tests/{{component_name}}.test.ts`
|
||||||
|
|
||||||
**Test Scenarios:**
|
**Test Scenarios:**
|
||||||
|
|
||||||
- {{test_scenario_1}}
|
- {{test_scenario_1}}
|
||||||
- {{test_scenario_2}}
|
- {{test_scenario_2}}
|
||||||
- {{edge_case_test}}
|
- {{edge_case_test}}
|
||||||
|
|
@ -184,12 +184,12 @@ sections:
|
||||||
title: Game Testing
|
title: Game Testing
|
||||||
template: |
|
template: |
|
||||||
**Manual Test Cases:**
|
**Manual Test Cases:**
|
||||||
|
|
||||||
1. {{test_case_1_description}}
|
1. {{test_case_1_description}}
|
||||||
|
|
||||||
- Expected: {{expected_behavior}}
|
- Expected: {{expected_behavior}}
|
||||||
- Performance: {{performance_expectation}}
|
- Performance: {{performance_expectation}}
|
||||||
|
|
||||||
2. {{test_case_2_description}}
|
2. {{test_case_2_description}}
|
||||||
- Expected: {{expected_behavior}}
|
- Expected: {{expected_behavior}}
|
||||||
- Edge Case: {{edge_case_handling}}
|
- Edge Case: {{edge_case_handling}}
|
||||||
|
|
@ -197,7 +197,7 @@ sections:
|
||||||
title: Performance Tests
|
title: Performance Tests
|
||||||
template: |
|
template: |
|
||||||
**Metrics to Verify:**
|
**Metrics to Verify:**
|
||||||
|
|
||||||
- Frame rate maintains {{fps_target}} FPS
|
- Frame rate maintains {{fps_target}} FPS
|
||||||
- Memory usage stays under {{memory_limit}}MB
|
- Memory usage stays under {{memory_limit}}MB
|
||||||
- {{feature_specific_performance_metric}}
|
- {{feature_specific_performance_metric}}
|
||||||
|
|
@ -207,15 +207,15 @@ sections:
|
||||||
instruction: List any dependencies that must be completed before this story can be implemented
|
instruction: List any dependencies that must be completed before this story can be implemented
|
||||||
template: |
|
template: |
|
||||||
**Story Dependencies:**
|
**Story Dependencies:**
|
||||||
|
|
||||||
- {{story_id}}: {{dependency_description}}
|
- {{story_id}}: {{dependency_description}}
|
||||||
|
|
||||||
**Technical Dependencies:**
|
**Technical Dependencies:**
|
||||||
|
|
||||||
- {{system_or_file}}: {{requirement}}
|
- {{system_or_file}}: {{requirement}}
|
||||||
|
|
||||||
**Asset Dependencies:**
|
**Asset Dependencies:**
|
||||||
|
|
||||||
- {{asset_type}}: {{asset_description}}
|
- {{asset_type}}: {{asset_description}}
|
||||||
- Location: `{{asset_path}}`
|
- Location: `{{asset_path}}`
|
||||||
|
|
||||||
|
|
@ -238,16 +238,16 @@ sections:
|
||||||
instruction: Any additional context, design decisions, or implementation notes
|
instruction: Any additional context, design decisions, or implementation notes
|
||||||
template: |
|
template: |
|
||||||
**Implementation Notes:**
|
**Implementation Notes:**
|
||||||
|
|
||||||
- {{note_1}}
|
- {{note_1}}
|
||||||
- {{note_2}}
|
- {{note_2}}
|
||||||
|
|
||||||
**Design Decisions:**
|
**Design Decisions:**
|
||||||
|
|
||||||
- {{decision_1}}: {{rationale}}
|
- {{decision_1}}: {{rationale}}
|
||||||
- {{decision_2}}: {{rationale}}
|
- {{decision_2}}: {{rationale}}
|
||||||
|
|
||||||
**Future Considerations:**
|
**Future Considerations:**
|
||||||
|
|
||||||
- {{future_enhancement_1}}
|
- {{future_enhancement_1}}
|
||||||
- {{future_optimization_1}}
|
- {{future_optimization_1}}
|
||||||
|
|
|
||||||
|
|
@ -14,7 +14,7 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels.
|
This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels.
|
||||||
|
|
||||||
If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents.
|
If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents.
|
||||||
|
|
||||||
- id: introduction
|
- id: introduction
|
||||||
|
|
@ -22,7 +22,7 @@ sections:
|
||||||
instruction: Establish the purpose and scope of level design for this game
|
instruction: Establish the purpose and scope of level design for this game
|
||||||
content: |
|
content: |
|
||||||
This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document.
|
This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document.
|
||||||
|
|
||||||
This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints.
|
This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints.
|
||||||
sections:
|
sections:
|
||||||
- id: change-log
|
- id: change-log
|
||||||
|
|
@ -69,29 +69,29 @@ sections:
|
||||||
title: "{{category_name}} Levels"
|
title: "{{category_name}} Levels"
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** {{gameplay_purpose}}
|
**Purpose:** {{gameplay_purpose}}
|
||||||
|
|
||||||
**Target Duration:** {{min_time}} - {{max_time}} minutes
|
**Target Duration:** {{min_time}} - {{max_time}} minutes
|
||||||
|
|
||||||
**Difficulty Range:** {{difficulty_scale}}
|
**Difficulty Range:** {{difficulty_scale}}
|
||||||
|
|
||||||
**Key Mechanics Featured:**
|
**Key Mechanics Featured:**
|
||||||
|
|
||||||
- {{mechanic_1}} - {{usage_description}}
|
- {{mechanic_1}} - {{usage_description}}
|
||||||
- {{mechanic_2}} - {{usage_description}}
|
- {{mechanic_2}} - {{usage_description}}
|
||||||
|
|
||||||
**Player Objectives:**
|
**Player Objectives:**
|
||||||
|
|
||||||
- Primary: {{primary_objective}}
|
- Primary: {{primary_objective}}
|
||||||
- Secondary: {{secondary_objective}}
|
- Secondary: {{secondary_objective}}
|
||||||
- Hidden: {{secret_objective}}
|
- Hidden: {{secret_objective}}
|
||||||
|
|
||||||
**Success Criteria:**
|
**Success Criteria:**
|
||||||
|
|
||||||
- {{completion_requirement_1}}
|
- {{completion_requirement_1}}
|
||||||
- {{completion_requirement_2}}
|
- {{completion_requirement_2}}
|
||||||
|
|
||||||
**Technical Requirements:**
|
**Technical Requirements:**
|
||||||
|
|
||||||
- Maximum entities: {{entity_limit}}
|
- Maximum entities: {{entity_limit}}
|
||||||
- Performance target: {{fps_target}} FPS
|
- Performance target: {{fps_target}} FPS
|
||||||
- Memory budget: {{memory_limit}}MB
|
- Memory budget: {{memory_limit}}MB
|
||||||
|
|
@ -106,11 +106,11 @@ sections:
|
||||||
instruction: Based on GDD requirements, define the overall level organization
|
instruction: Based on GDD requirements, define the overall level organization
|
||||||
template: |
|
template: |
|
||||||
**Organization Type:** {{linear|hub_world|open_world}}
|
**Organization Type:** {{linear|hub_world|open_world}}
|
||||||
|
|
||||||
**Total Level Count:** {{number}}
|
**Total Level Count:** {{number}}
|
||||||
|
|
||||||
**World Breakdown:**
|
**World Breakdown:**
|
||||||
|
|
||||||
- World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
- World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||||
- World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
- World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||||
- World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
- World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||||
|
|
@ -145,7 +145,7 @@ sections:
|
||||||
instruction: Define how players access new levels
|
instruction: Define how players access new levels
|
||||||
template: |
|
template: |
|
||||||
**Progression Gates:**
|
**Progression Gates:**
|
||||||
|
|
||||||
- Linear progression: Complete previous level
|
- Linear progression: Complete previous level
|
||||||
- Star requirements: {{star_count}} stars to unlock
|
- Star requirements: {{star_count}} stars to unlock
|
||||||
- Skill gates: Demonstrate {{skill_requirement}}
|
- Skill gates: Demonstrate {{skill_requirement}}
|
||||||
|
|
@ -160,17 +160,17 @@ sections:
|
||||||
instruction: Define all environmental components that can be used in levels
|
instruction: Define all environmental components that can be used in levels
|
||||||
template: |
|
template: |
|
||||||
**Terrain Types:**
|
**Terrain Types:**
|
||||||
|
|
||||||
- {{terrain_1}}: {{properties_and_usage}}
|
- {{terrain_1}}: {{properties_and_usage}}
|
||||||
- {{terrain_2}}: {{properties_and_usage}}
|
- {{terrain_2}}: {{properties_and_usage}}
|
||||||
|
|
||||||
**Interactive Objects:**
|
**Interactive Objects:**
|
||||||
|
|
||||||
- {{object_1}}: {{behavior_and_purpose}}
|
- {{object_1}}: {{behavior_and_purpose}}
|
||||||
- {{object_2}}: {{behavior_and_purpose}}
|
- {{object_2}}: {{behavior_and_purpose}}
|
||||||
|
|
||||||
**Hazards and Obstacles:**
|
**Hazards and Obstacles:**
|
||||||
|
|
||||||
- {{hazard_1}}: {{damage_and_behavior}}
|
- {{hazard_1}}: {{damage_and_behavior}}
|
||||||
- {{hazard_2}}: {{damage_and_behavior}}
|
- {{hazard_2}}: {{damage_and_behavior}}
|
||||||
- id: collectibles-rewards
|
- id: collectibles-rewards
|
||||||
|
|
@ -178,18 +178,18 @@ sections:
|
||||||
instruction: Define all collectible items and their placement rules
|
instruction: Define all collectible items and their placement rules
|
||||||
template: |
|
template: |
|
||||||
**Collectible Types:**
|
**Collectible Types:**
|
||||||
|
|
||||||
- {{collectible_1}}: {{value_and_purpose}}
|
- {{collectible_1}}: {{value_and_purpose}}
|
||||||
- {{collectible_2}}: {{value_and_purpose}}
|
- {{collectible_2}}: {{value_and_purpose}}
|
||||||
|
|
||||||
**Placement Guidelines:**
|
**Placement Guidelines:**
|
||||||
|
|
||||||
- Mandatory collectibles: {{placement_rules}}
|
- Mandatory collectibles: {{placement_rules}}
|
||||||
- Optional collectibles: {{placement_rules}}
|
- Optional collectibles: {{placement_rules}}
|
||||||
- Secret collectibles: {{placement_rules}}
|
- Secret collectibles: {{placement_rules}}
|
||||||
|
|
||||||
**Reward Distribution:**
|
**Reward Distribution:**
|
||||||
|
|
||||||
- Easy to find: {{percentage}}%
|
- Easy to find: {{percentage}}%
|
||||||
- Moderate challenge: {{percentage}}%
|
- Moderate challenge: {{percentage}}%
|
||||||
- High skill required: {{percentage}}%
|
- High skill required: {{percentage}}%
|
||||||
|
|
@ -198,18 +198,18 @@ sections:
|
||||||
instruction: Define how enemies should be placed and balanced in levels
|
instruction: Define how enemies should be placed and balanced in levels
|
||||||
template: |
|
template: |
|
||||||
**Enemy Categories:**
|
**Enemy Categories:**
|
||||||
|
|
||||||
- {{enemy_type_1}}: {{behavior_and_usage}}
|
- {{enemy_type_1}}: {{behavior_and_usage}}
|
||||||
- {{enemy_type_2}}: {{behavior_and_usage}}
|
- {{enemy_type_2}}: {{behavior_and_usage}}
|
||||||
|
|
||||||
**Placement Principles:**
|
**Placement Principles:**
|
||||||
|
|
||||||
- Introduction encounters: {{guideline}}
|
- Introduction encounters: {{guideline}}
|
||||||
- Standard encounters: {{guideline}}
|
- Standard encounters: {{guideline}}
|
||||||
- Challenge encounters: {{guideline}}
|
- Challenge encounters: {{guideline}}
|
||||||
|
|
||||||
**Difficulty Scaling:**
|
**Difficulty Scaling:**
|
||||||
|
|
||||||
- Enemy count progression: {{scaling_rule}}
|
- Enemy count progression: {{scaling_rule}}
|
||||||
- Enemy type introduction: {{pacing_rule}}
|
- Enemy type introduction: {{pacing_rule}}
|
||||||
- Encounter complexity: {{complexity_rule}}
|
- Encounter complexity: {{complexity_rule}}
|
||||||
|
|
@ -222,14 +222,14 @@ sections:
|
||||||
title: Level Layout Principles
|
title: Level Layout Principles
|
||||||
template: |
|
template: |
|
||||||
**Spatial Design:**
|
**Spatial Design:**
|
||||||
|
|
||||||
- Grid size: {{grid_dimensions}}
|
- Grid size: {{grid_dimensions}}
|
||||||
- Minimum path width: {{width_units}}
|
- Minimum path width: {{width_units}}
|
||||||
- Maximum vertical distance: {{height_units}}
|
- Maximum vertical distance: {{height_units}}
|
||||||
- Safe zones placement: {{safety_guidelines}}
|
- Safe zones placement: {{safety_guidelines}}
|
||||||
|
|
||||||
**Navigation Design:**
|
**Navigation Design:**
|
||||||
|
|
||||||
- Clear path indication: {{visual_cues}}
|
- Clear path indication: {{visual_cues}}
|
||||||
- Landmark placement: {{landmark_rules}}
|
- Landmark placement: {{landmark_rules}}
|
||||||
- Dead end avoidance: {{dead_end_policy}}
|
- Dead end avoidance: {{dead_end_policy}}
|
||||||
|
|
@ -239,13 +239,13 @@ sections:
|
||||||
instruction: Define how to control the rhythm and pace of gameplay within levels
|
instruction: Define how to control the rhythm and pace of gameplay within levels
|
||||||
template: |
|
template: |
|
||||||
**Action Sequences:**
|
**Action Sequences:**
|
||||||
|
|
||||||
- High intensity duration: {{max_duration}}
|
- High intensity duration: {{max_duration}}
|
||||||
- Rest period requirement: {{min_rest_time}}
|
- Rest period requirement: {{min_rest_time}}
|
||||||
- Intensity variation: {{pacing_pattern}}
|
- Intensity variation: {{pacing_pattern}}
|
||||||
|
|
||||||
**Learning Sequences:**
|
**Learning Sequences:**
|
||||||
|
|
||||||
- New mechanic introduction: {{teaching_method}}
|
- New mechanic introduction: {{teaching_method}}
|
||||||
- Practice opportunity: {{practice_duration}}
|
- Practice opportunity: {{practice_duration}}
|
||||||
- Skill application: {{application_context}}
|
- Skill application: {{application_context}}
|
||||||
|
|
@ -254,14 +254,14 @@ sections:
|
||||||
instruction: Define how to create appropriate challenges for each level type
|
instruction: Define how to create appropriate challenges for each level type
|
||||||
template: |
|
template: |
|
||||||
**Challenge Types:**
|
**Challenge Types:**
|
||||||
|
|
||||||
- Execution challenges: {{skill_requirements}}
|
- Execution challenges: {{skill_requirements}}
|
||||||
- Puzzle challenges: {{complexity_guidelines}}
|
- Puzzle challenges: {{complexity_guidelines}}
|
||||||
- Time challenges: {{time_pressure_rules}}
|
- Time challenges: {{time_pressure_rules}}
|
||||||
- Resource challenges: {{resource_management}}
|
- Resource challenges: {{resource_management}}
|
||||||
|
|
||||||
**Difficulty Calibration:**
|
**Difficulty Calibration:**
|
||||||
|
|
||||||
- Skill check frequency: {{frequency_guidelines}}
|
- Skill check frequency: {{frequency_guidelines}}
|
||||||
- Failure recovery: {{retry_mechanics}}
|
- Failure recovery: {{retry_mechanics}}
|
||||||
- Hint system integration: {{help_system}}
|
- Hint system integration: {{help_system}}
|
||||||
|
|
@ -275,7 +275,7 @@ sections:
|
||||||
instruction: Define how level data should be structured for implementation
|
instruction: Define how level data should be structured for implementation
|
||||||
template: |
|
template: |
|
||||||
**Level File Format:**
|
**Level File Format:**
|
||||||
|
|
||||||
- Data format: {{json|yaml|custom}}
|
- Data format: {{json|yaml|custom}}
|
||||||
- File naming: `level_{{world}}_{{number}}.{{extension}}`
|
- File naming: `level_{{world}}_{{number}}.{{extension}}`
|
||||||
- Data organization: {{structure_description}}
|
- Data organization: {{structure_description}}
|
||||||
|
|
@ -313,14 +313,14 @@ sections:
|
||||||
instruction: Define how level assets are organized and loaded
|
instruction: Define how level assets are organized and loaded
|
||||||
template: |
|
template: |
|
||||||
**Tilemap Requirements:**
|
**Tilemap Requirements:**
|
||||||
|
|
||||||
- Tile size: {{tile_dimensions}}px
|
- Tile size: {{tile_dimensions}}px
|
||||||
- Tileset organization: {{tileset_structure}}
|
- Tileset organization: {{tileset_structure}}
|
||||||
- Layer organization: {{layer_system}}
|
- Layer organization: {{layer_system}}
|
||||||
- Collision data: {{collision_format}}
|
- Collision data: {{collision_format}}
|
||||||
|
|
||||||
**Audio Integration:**
|
**Audio Integration:**
|
||||||
|
|
||||||
- Background music: {{music_requirements}}
|
- Background music: {{music_requirements}}
|
||||||
- Ambient sounds: {{ambient_system}}
|
- Ambient sounds: {{ambient_system}}
|
||||||
- Dynamic audio: {{dynamic_audio_rules}}
|
- Dynamic audio: {{dynamic_audio_rules}}
|
||||||
|
|
@ -329,19 +329,19 @@ sections:
|
||||||
instruction: Define performance requirements for level systems
|
instruction: Define performance requirements for level systems
|
||||||
template: |
|
template: |
|
||||||
**Entity Limits:**
|
**Entity Limits:**
|
||||||
|
|
||||||
- Maximum active entities: {{entity_limit}}
|
- Maximum active entities: {{entity_limit}}
|
||||||
- Maximum particles: {{particle_limit}}
|
- Maximum particles: {{particle_limit}}
|
||||||
- Maximum audio sources: {{audio_limit}}
|
- Maximum audio sources: {{audio_limit}}
|
||||||
|
|
||||||
**Memory Management:**
|
**Memory Management:**
|
||||||
|
|
||||||
- Texture memory budget: {{texture_memory}}MB
|
- Texture memory budget: {{texture_memory}}MB
|
||||||
- Audio memory budget: {{audio_memory}}MB
|
- Audio memory budget: {{audio_memory}}MB
|
||||||
- Level loading time: <{{load_time}}s
|
- Level loading time: <{{load_time}}s
|
||||||
|
|
||||||
**Culling and LOD:**
|
**Culling and LOD:**
|
||||||
|
|
||||||
- Off-screen culling: {{culling_distance}}
|
- Off-screen culling: {{culling_distance}}
|
||||||
- Level-of-detail rules: {{lod_system}}
|
- Level-of-detail rules: {{lod_system}}
|
||||||
- Asset streaming: {{streaming_requirements}}
|
- Asset streaming: {{streaming_requirements}}
|
||||||
|
|
@ -354,13 +354,13 @@ sections:
|
||||||
title: Automated Testing
|
title: Automated Testing
|
||||||
template: |
|
template: |
|
||||||
**Performance Testing:**
|
**Performance Testing:**
|
||||||
|
|
||||||
- Frame rate validation: Maintain {{fps_target}} FPS
|
- Frame rate validation: Maintain {{fps_target}} FPS
|
||||||
- Memory usage monitoring: Stay under {{memory_limit}}MB
|
- Memory usage monitoring: Stay under {{memory_limit}}MB
|
||||||
- Loading time verification: Complete in <{{load_time}}s
|
- Loading time verification: Complete in <{{load_time}}s
|
||||||
|
|
||||||
**Gameplay Testing:**
|
**Gameplay Testing:**
|
||||||
|
|
||||||
- Completion path validation: All objectives achievable
|
- Completion path validation: All objectives achievable
|
||||||
- Collectible accessibility: All items reachable
|
- Collectible accessibility: All items reachable
|
||||||
- Softlock prevention: No unwinnable states
|
- Softlock prevention: No unwinnable states
|
||||||
|
|
@ -388,14 +388,14 @@ sections:
|
||||||
title: Balance Validation
|
title: Balance Validation
|
||||||
template: |
|
template: |
|
||||||
**Metrics Collection:**
|
**Metrics Collection:**
|
||||||
|
|
||||||
- Completion rate: Target {{completion_percentage}}%
|
- Completion rate: Target {{completion_percentage}}%
|
||||||
- Average completion time: {{target_time}} ± {{variance}}
|
- Average completion time: {{target_time}} ± {{variance}}
|
||||||
- Death count per level: <{{max_deaths}}
|
- Death count per level: <{{max_deaths}}
|
||||||
- Collectible discovery rate: {{discovery_percentage}}%
|
- Collectible discovery rate: {{discovery_percentage}}%
|
||||||
|
|
||||||
**Iteration Guidelines:**
|
**Iteration Guidelines:**
|
||||||
|
|
||||||
- Adjustment criteria: {{criteria_for_changes}}
|
- Adjustment criteria: {{criteria_for_changes}}
|
||||||
- Testing sample size: {{minimum_testers}}
|
- Testing sample size: {{minimum_testers}}
|
||||||
- Validation period: {{testing_duration}}
|
- Validation period: {{testing_duration}}
|
||||||
|
|
@ -408,14 +408,14 @@ sections:
|
||||||
title: Design Phase
|
title: Design Phase
|
||||||
template: |
|
template: |
|
||||||
**Concept Development:**
|
**Concept Development:**
|
||||||
|
|
||||||
1. Define level purpose and goals
|
1. Define level purpose and goals
|
||||||
2. Create rough layout sketch
|
2. Create rough layout sketch
|
||||||
3. Identify key mechanics and challenges
|
3. Identify key mechanics and challenges
|
||||||
4. Estimate difficulty and duration
|
4. Estimate difficulty and duration
|
||||||
|
|
||||||
**Documentation Requirements:**
|
**Documentation Requirements:**
|
||||||
|
|
||||||
- Level design brief
|
- Level design brief
|
||||||
- Layout diagrams
|
- Layout diagrams
|
||||||
- Mechanic integration notes
|
- Mechanic integration notes
|
||||||
|
|
@ -424,15 +424,15 @@ sections:
|
||||||
title: Implementation Phase
|
title: Implementation Phase
|
||||||
template: |
|
template: |
|
||||||
**Technical Implementation:**
|
**Technical Implementation:**
|
||||||
|
|
||||||
1. Create level data file
|
1. Create level data file
|
||||||
2. Build tilemap and layout
|
2. Build tilemap and layout
|
||||||
3. Place entities and objects
|
3. Place entities and objects
|
||||||
4. Configure level logic and triggers
|
4. Configure level logic and triggers
|
||||||
5. Integrate audio and visual effects
|
5. Integrate audio and visual effects
|
||||||
|
|
||||||
**Quality Assurance:**
|
**Quality Assurance:**
|
||||||
|
|
||||||
1. Automated testing execution
|
1. Automated testing execution
|
||||||
2. Internal playtesting
|
2. Internal playtesting
|
||||||
3. Performance validation
|
3. Performance validation
|
||||||
|
|
@ -441,14 +441,14 @@ sections:
|
||||||
title: Integration Phase
|
title: Integration Phase
|
||||||
template: |
|
template: |
|
||||||
**Game Integration:**
|
**Game Integration:**
|
||||||
|
|
||||||
1. Level progression integration
|
1. Level progression integration
|
||||||
2. Save system compatibility
|
2. Save system compatibility
|
||||||
3. Analytics integration
|
3. Analytics integration
|
||||||
4. Achievement system integration
|
4. Achievement system integration
|
||||||
|
|
||||||
**Final Validation:**
|
**Final Validation:**
|
||||||
|
|
||||||
1. Full game context testing
|
1. Full game context testing
|
||||||
2. Performance regression testing
|
2. Performance regression testing
|
||||||
3. Platform compatibility verification
|
3. Platform compatibility verification
|
||||||
|
|
@ -481,4 +481,4 @@ sections:
|
||||||
- Difficulty curve adherence: {{curve_accuracy}}
|
- Difficulty curve adherence: {{curve_accuracy}}
|
||||||
- Mechanic integration effectiveness: {{integration_score}}
|
- Mechanic integration effectiveness: {{integration_score}}
|
||||||
- Player guidance clarity: {{guidance_score}}
|
- Player guidance clarity: {{guidance_score}}
|
||||||
- Content accessibility: {{accessibility_rate}}%
|
- Content accessibility: {{accessibility_rate}}%
|
||||||
|
|
|
||||||
|
|
@ -17,21 +17,21 @@ workflow:
|
||||||
- brainstorming_session
|
- brainstorming_session
|
||||||
- game_research_prompt
|
- game_research_prompt
|
||||||
- player_research
|
- player_research
|
||||||
notes: 'Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/design/ folder.'
|
notes: "Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project's docs/design/ folder."
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: game-design-doc.md
|
creates: game-design-doc.md
|
||||||
requires: game-brief.md
|
requires: game-brief.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- competitive_analysis
|
- competitive_analysis
|
||||||
- technical_research
|
- technical_research
|
||||||
notes: 'Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project''s docs/design/ folder.'
|
notes: "Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project's docs/design/ folder."
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: level-design-doc.md
|
creates: level-design-doc.md
|
||||||
requires: game-design-doc.md
|
requires: game-design-doc.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- level_prototyping
|
- level_prototyping
|
||||||
- difficulty_analysis
|
- difficulty_analysis
|
||||||
notes: 'Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project''s docs/design/ folder.'
|
notes: "Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project's docs/design/ folder."
|
||||||
- agent: solution-architect
|
- agent: solution-architect
|
||||||
creates: game-architecture.md
|
creates: game-architecture.md
|
||||||
requires:
|
requires:
|
||||||
|
|
@ -41,7 +41,7 @@ workflow:
|
||||||
- technical_research_prompt
|
- technical_research_prompt
|
||||||
- performance_analysis
|
- performance_analysis
|
||||||
- platform_research
|
- platform_research
|
||||||
notes: 'Create comprehensive technical architecture using game-architecture-tmpl. Defines Phaser 3 systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project''s docs/architecture/ folder.'
|
notes: "Create comprehensive technical architecture using game-architecture-tmpl. Defines Phaser 3 systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project's docs/architecture/ folder."
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
validates: design_consistency
|
validates: design_consistency
|
||||||
requires: all_design_documents
|
requires: all_design_documents
|
||||||
|
|
@ -66,7 +66,7 @@ workflow:
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- quick_brainstorming
|
- quick_brainstorming
|
||||||
- concept_validation
|
- concept_validation
|
||||||
notes: 'Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/ folder.'
|
notes: "Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project's docs/ folder."
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: prototype-design.md
|
creates: prototype-design.md
|
||||||
uses: create-doc prototype-design OR create-game-story
|
uses: create-doc prototype-design OR create-game-story
|
||||||
|
|
|
||||||
|
|
@ -44,7 +44,7 @@ workflow:
|
||||||
notes: Implement stories in priority order. Test frequently and adjust design based on what feels fun. Document discoveries.
|
notes: Implement stories in priority order. Test frequently and adjust design based on what feels fun. Document discoveries.
|
||||||
workflow_end:
|
workflow_end:
|
||||||
action: prototype_evaluation
|
action: prototype_evaluation
|
||||||
notes: 'Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive.'
|
notes: "Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive."
|
||||||
game_jam_sequence:
|
game_jam_sequence:
|
||||||
- step: jam_concept
|
- step: jam_concept
|
||||||
agent: game-designer
|
agent: game-designer
|
||||||
|
|
|
||||||
|
|
@ -14,7 +14,7 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
|
This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
|
||||||
|
|
||||||
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.
|
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.
|
||||||
|
|
||||||
- id: game-vision
|
- id: game-vision
|
||||||
|
|
@ -71,7 +71,7 @@ sections:
|
||||||
repeatable: true
|
repeatable: true
|
||||||
template: |
|
template: |
|
||||||
**Core Mechanic: {{mechanic_name}}**
|
**Core Mechanic: {{mechanic_name}}**
|
||||||
|
|
||||||
- **Description:** {{how_it_works}}
|
- **Description:** {{how_it_works}}
|
||||||
- **Player Value:** {{why_its_fun}}
|
- **Player Value:** {{why_its_fun}}
|
||||||
- **Implementation Scope:** {{complexity_estimate}}
|
- **Implementation Scope:** {{complexity_estimate}}
|
||||||
|
|
@ -98,12 +98,12 @@ sections:
|
||||||
title: Technical Constraints
|
title: Technical Constraints
|
||||||
template: |
|
template: |
|
||||||
**Platform Requirements:**
|
**Platform Requirements:**
|
||||||
|
|
||||||
- Primary: {{platform_1}} - {{requirements}}
|
- Primary: {{platform_1}} - {{requirements}}
|
||||||
- Secondary: {{platform_2}} - {{requirements}}
|
- Secondary: {{platform_2}} - {{requirements}}
|
||||||
|
|
||||||
**Technical Specifications:**
|
**Technical Specifications:**
|
||||||
|
|
||||||
- Engine: Unity & C#
|
- Engine: Unity & C#
|
||||||
- Performance Target: {{fps_target}} FPS on {{target_device}}
|
- Performance Target: {{fps_target}} FPS on {{target_device}}
|
||||||
- Memory Budget: <{{memory_limit}}MB
|
- Memory Budget: <{{memory_limit}}MB
|
||||||
|
|
@ -141,10 +141,10 @@ sections:
|
||||||
title: Competitive Analysis
|
title: Competitive Analysis
|
||||||
template: |
|
template: |
|
||||||
**Direct Competitors:**
|
**Direct Competitors:**
|
||||||
|
|
||||||
- {{competitor_1}}: {{strengths_and_weaknesses}}
|
- {{competitor_1}}: {{strengths_and_weaknesses}}
|
||||||
- {{competitor_2}}: {{strengths_and_weaknesses}}
|
- {{competitor_2}}: {{strengths_and_weaknesses}}
|
||||||
|
|
||||||
**Differentiation Strategy:**
|
**Differentiation Strategy:**
|
||||||
{{how_we_differ_and_why_thats_valuable}}
|
{{how_we_differ_and_why_thats_valuable}}
|
||||||
- id: market-opportunity
|
- id: market-opportunity
|
||||||
|
|
@ -168,16 +168,16 @@ sections:
|
||||||
title: Content Categories
|
title: Content Categories
|
||||||
template: |
|
template: |
|
||||||
**Core Content:**
|
**Core Content:**
|
||||||
|
|
||||||
- {{content_type_1}}: {{quantity_and_description}}
|
- {{content_type_1}}: {{quantity_and_description}}
|
||||||
- {{content_type_2}}: {{quantity_and_description}}
|
- {{content_type_2}}: {{quantity_and_description}}
|
||||||
|
|
||||||
**Optional Content:**
|
**Optional Content:**
|
||||||
|
|
||||||
- {{optional_content_type}}: {{quantity_and_description}}
|
- {{optional_content_type}}: {{quantity_and_description}}
|
||||||
|
|
||||||
**Replay Elements:**
|
**Replay Elements:**
|
||||||
|
|
||||||
- {{replayability_features}}
|
- {{replayability_features}}
|
||||||
- id: difficulty-accessibility
|
- id: difficulty-accessibility
|
||||||
title: Difficulty and Accessibility
|
title: Difficulty and Accessibility
|
||||||
|
|
@ -244,13 +244,13 @@ sections:
|
||||||
title: Player Experience Metrics
|
title: Player Experience Metrics
|
||||||
template: |
|
template: |
|
||||||
**Engagement Goals:**
|
**Engagement Goals:**
|
||||||
|
|
||||||
- Tutorial completion rate: >{{percentage}}%
|
- Tutorial completion rate: >{{percentage}}%
|
||||||
- Average session length: {{duration}} minutes
|
- Average session length: {{duration}} minutes
|
||||||
- Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}%
|
- Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}%
|
||||||
|
|
||||||
**Quality Benchmarks:**
|
**Quality Benchmarks:**
|
||||||
|
|
||||||
- Player satisfaction: >{{rating}}/10
|
- Player satisfaction: >{{rating}}/10
|
||||||
- Completion rate: >{{percentage}}%
|
- Completion rate: >{{percentage}}%
|
||||||
- Technical performance: {{fps_target}} FPS consistent
|
- Technical performance: {{fps_target}} FPS consistent
|
||||||
|
|
@ -258,13 +258,13 @@ sections:
|
||||||
title: Development Metrics
|
title: Development Metrics
|
||||||
template: |
|
template: |
|
||||||
**Technical Targets:**
|
**Technical Targets:**
|
||||||
|
|
||||||
- Zero critical bugs at launch
|
- Zero critical bugs at launch
|
||||||
- Performance targets met on all platforms
|
- Performance targets met on all platforms
|
||||||
- Load times under {{seconds}}s
|
- Load times under {{seconds}}s
|
||||||
|
|
||||||
**Process Goals:**
|
**Process Goals:**
|
||||||
|
|
||||||
- Development timeline adherence
|
- Development timeline adherence
|
||||||
- Feature scope completion
|
- Feature scope completion
|
||||||
- Quality assurance standards
|
- Quality assurance standards
|
||||||
|
|
@ -273,7 +273,7 @@ sections:
|
||||||
condition: has_business_goals
|
condition: has_business_goals
|
||||||
template: |
|
template: |
|
||||||
**Commercial Goals:**
|
**Commercial Goals:**
|
||||||
|
|
||||||
- {{revenue_target}} in first {{time_period}}
|
- {{revenue_target}} in first {{time_period}}
|
||||||
- {{user_acquisition_target}} players in first {{time_period}}
|
- {{user_acquisition_target}} players in first {{time_period}}
|
||||||
- {{retention_target}} monthly active users
|
- {{retention_target}} monthly active users
|
||||||
|
|
@ -326,12 +326,12 @@ sections:
|
||||||
title: Validation Plan
|
title: Validation Plan
|
||||||
template: |
|
template: |
|
||||||
**Concept Testing:**
|
**Concept Testing:**
|
||||||
|
|
||||||
- {{validation_method_1}} - {{timeline}}
|
- {{validation_method_1}} - {{timeline}}
|
||||||
- {{validation_method_2}} - {{timeline}}
|
- {{validation_method_2}} - {{timeline}}
|
||||||
|
|
||||||
**Prototype Testing:**
|
**Prototype Testing:**
|
||||||
|
|
||||||
- {{testing_approach}} - {{timeline}}
|
- {{testing_approach}} - {{timeline}}
|
||||||
- {{feedback_collection_method}} - {{timeline}}
|
- {{feedback_collection_method}} - {{timeline}}
|
||||||
|
|
||||||
|
|
@ -353,4 +353,4 @@ sections:
|
||||||
type: table
|
type: table
|
||||||
template: |
|
template: |
|
||||||
| Date | Version | Description | Author |
|
| Date | Version | Description | Author |
|
||||||
| :--- | :------ | :---------- | :----- |
|
| :--- | :------ | :---------- | :----- |
|
||||||
|
|
|
||||||
|
|
@ -14,7 +14,7 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
|
This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
|
||||||
|
|
||||||
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis
|
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis
|
||||||
|
|
||||||
- id: executive-summary
|
- id: executive-summary
|
||||||
|
|
@ -59,7 +59,7 @@ sections:
|
||||||
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.
|
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.
|
||||||
template: |
|
template: |
|
||||||
**Primary Loop ({{duration}} seconds):**
|
**Primary Loop ({{duration}} seconds):**
|
||||||
|
|
||||||
1. {{action_1}} ({{time_1}}s)
|
1. {{action_1}} ({{time_1}}s)
|
||||||
2. {{action_2}} ({{time_2}}s)
|
2. {{action_2}} ({{time_2}}s)
|
||||||
3. {{action_3}} ({{time_3}}s)
|
3. {{action_3}} ({{time_3}}s)
|
||||||
|
|
@ -69,12 +69,12 @@ sections:
|
||||||
instruction: Clearly define success and failure states
|
instruction: Clearly define success and failure states
|
||||||
template: |
|
template: |
|
||||||
**Victory Conditions:**
|
**Victory Conditions:**
|
||||||
|
|
||||||
- {{win_condition_1}}
|
- {{win_condition_1}}
|
||||||
- {{win_condition_2}}
|
- {{win_condition_2}}
|
||||||
|
|
||||||
**Failure States:**
|
**Failure States:**
|
||||||
|
|
||||||
- {{loss_condition_1}}
|
- {{loss_condition_1}}
|
||||||
- {{loss_condition_2}}
|
- {{loss_condition_2}}
|
||||||
|
|
||||||
|
|
@ -90,17 +90,17 @@ sections:
|
||||||
title: "{{mechanic_name}}"
|
title: "{{mechanic_name}}"
|
||||||
template: |
|
template: |
|
||||||
**Description:** {{detailed_description}}
|
**Description:** {{detailed_description}}
|
||||||
|
|
||||||
**Player Input:** {{input_method}}
|
**Player Input:** {{input_method}}
|
||||||
|
|
||||||
**System Response:** {{game_response}}
|
**System Response:** {{game_response}}
|
||||||
|
|
||||||
**Implementation Notes:**
|
**Implementation Notes:**
|
||||||
|
|
||||||
- {{tech_requirement_1}}
|
- {{tech_requirement_1}}
|
||||||
- {{tech_requirement_2}}
|
- {{tech_requirement_2}}
|
||||||
- {{performance_consideration}}
|
- {{performance_consideration}}
|
||||||
|
|
||||||
**Dependencies:** {{other_mechanics_needed}}
|
**Dependencies:** {{other_mechanics_needed}}
|
||||||
- id: controls
|
- id: controls
|
||||||
title: Controls
|
title: Controls
|
||||||
|
|
@ -119,9 +119,9 @@ sections:
|
||||||
title: Player Progression
|
title: Player Progression
|
||||||
template: |
|
template: |
|
||||||
**Progression Type:** {{linear|branching|metroidvania}}
|
**Progression Type:** {{linear|branching|metroidvania}}
|
||||||
|
|
||||||
**Key Milestones:**
|
**Key Milestones:**
|
||||||
|
|
||||||
1. **{{milestone_1}}** - {{unlock_description}}
|
1. **{{milestone_1}}** - {{unlock_description}}
|
||||||
2. **{{milestone_2}}** - {{unlock_description}}
|
2. **{{milestone_2}}** - {{unlock_description}}
|
||||||
3. **{{milestone_3}}** - {{unlock_description}}
|
3. **{{milestone_3}}** - {{unlock_description}}
|
||||||
|
|
@ -158,9 +158,9 @@ sections:
|
||||||
**Duration:** {{target_time}}
|
**Duration:** {{target_time}}
|
||||||
**Key Elements:** {{required_mechanics}}
|
**Key Elements:** {{required_mechanics}}
|
||||||
**Difficulty:** {{relative_difficulty}}
|
**Difficulty:** {{relative_difficulty}}
|
||||||
|
|
||||||
**Structure Template:**
|
**Structure Template:**
|
||||||
|
|
||||||
- Introduction: {{intro_description}}
|
- Introduction: {{intro_description}}
|
||||||
- Challenge: {{main_challenge}}
|
- Challenge: {{main_challenge}}
|
||||||
- Resolution: {{completion_requirement}}
|
- Resolution: {{completion_requirement}}
|
||||||
|
|
@ -186,13 +186,13 @@ sections:
|
||||||
title: Platform Specific
|
title: Platform Specific
|
||||||
template: |
|
template: |
|
||||||
**Desktop:**
|
**Desktop:**
|
||||||
|
|
||||||
- Resolution: {{min_resolution}} - {{max_resolution}}
|
- Resolution: {{min_resolution}} - {{max_resolution}}
|
||||||
- Input: Keyboard, Mouse, Gamepad
|
- Input: Keyboard, Mouse, Gamepad
|
||||||
- Browser: Chrome 80+, Firefox 75+, Safari 13+
|
- Browser: Chrome 80+, Firefox 75+, Safari 13+
|
||||||
|
|
||||||
**Mobile:**
|
**Mobile:**
|
||||||
|
|
||||||
- Resolution: {{mobile_min}} - {{mobile_max}}
|
- Resolution: {{mobile_min}} - {{mobile_max}}
|
||||||
- Input: Touch, Tilt (optional)
|
- Input: Touch, Tilt (optional)
|
||||||
- OS: iOS 13+, Android 8+
|
- OS: iOS 13+, Android 8+
|
||||||
|
|
@ -201,14 +201,14 @@ sections:
|
||||||
instruction: Define asset specifications for the art and audio teams
|
instruction: Define asset specifications for the art and audio teams
|
||||||
template: |
|
template: |
|
||||||
**Visual Assets:**
|
**Visual Assets:**
|
||||||
|
|
||||||
- Art Style: {{style_description}}
|
- Art Style: {{style_description}}
|
||||||
- Color Palette: {{color_specification}}
|
- Color Palette: {{color_specification}}
|
||||||
- Animation: {{animation_requirements}}
|
- Animation: {{animation_requirements}}
|
||||||
- UI Resolution: {{ui_specs}}
|
- UI Resolution: {{ui_specs}}
|
||||||
|
|
||||||
**Audio Assets:**
|
**Audio Assets:**
|
||||||
|
|
||||||
- Music Style: {{music_genre}}
|
- Music Style: {{music_genre}}
|
||||||
- Sound Effects: {{sfx_requirements}}
|
- Sound Effects: {{sfx_requirements}}
|
||||||
- Voice Acting: {{voice_needs}}
|
- Voice Acting: {{voice_needs}}
|
||||||
|
|
@ -230,7 +230,7 @@ sections:
|
||||||
title: Code Architecture
|
title: Code Architecture
|
||||||
template: |
|
template: |
|
||||||
**Required Systems:**
|
**Required Systems:**
|
||||||
|
|
||||||
- Scene Management
|
- Scene Management
|
||||||
- State Management
|
- State Management
|
||||||
- Asset Loading
|
- Asset Loading
|
||||||
|
|
@ -242,7 +242,7 @@ sections:
|
||||||
title: Data Management
|
title: Data Management
|
||||||
template: |
|
template: |
|
||||||
**Save Data:**
|
**Save Data:**
|
||||||
|
|
||||||
- Progress tracking
|
- Progress tracking
|
||||||
- Settings persistence
|
- Settings persistence
|
||||||
- Statistics collection
|
- Statistics collection
|
||||||
|
|
@ -340,4 +340,4 @@ sections:
|
||||||
title: References
|
title: References
|
||||||
instruction: List any competitive analysis, inspiration, or research sources
|
instruction: List any competitive analysis, inspiration, or research sources
|
||||||
type: bullet-list
|
type: bullet-list
|
||||||
template: "{{reference}}"
|
template: "{{reference}}"
|
||||||
|
|
|
||||||
|
|
@ -14,13 +14,13 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
|
This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
|
||||||
|
|
||||||
Before starting, ensure you have access to:
|
Before starting, ensure you have access to:
|
||||||
|
|
||||||
- Game Design Document (GDD)
|
- Game Design Document (GDD)
|
||||||
- Game Architecture Document
|
- Game Architecture Document
|
||||||
- Any existing stories in this epic
|
- Any existing stories in this epic
|
||||||
|
|
||||||
The story should be specific enough that a developer can implement it without requiring additional design decisions.
|
The story should be specific enough that a developer can implement it without requiring additional design decisions.
|
||||||
|
|
||||||
- id: story-header
|
- id: story-header
|
||||||
|
|
@ -69,12 +69,12 @@ sections:
|
||||||
title: Files to Create/Modify
|
title: Files to Create/Modify
|
||||||
template: |
|
template: |
|
||||||
**New Files:**
|
**New Files:**
|
||||||
|
|
||||||
- `{{file_path_1}}` - {{purpose}}
|
- `{{file_path_1}}` - {{purpose}}
|
||||||
- `{{file_path_2}}` - {{purpose}}
|
- `{{file_path_2}}` - {{purpose}}
|
||||||
|
|
||||||
**Modified Files:**
|
**Modified Files:**
|
||||||
|
|
||||||
- `{{existing_file_1}}` - {{changes_needed}}
|
- `{{existing_file_1}}` - {{changes_needed}}
|
||||||
- `{{existing_file_2}}` - {{changes_needed}}
|
- `{{existing_file_2}}` - {{changes_needed}}
|
||||||
- id: class-interface-definitions
|
- id: class-interface-definitions
|
||||||
|
|
@ -157,13 +157,13 @@ sections:
|
||||||
instruction: Reference the specific sections of the GDD that this story implements
|
instruction: Reference the specific sections of the GDD that this story implements
|
||||||
template: |
|
template: |
|
||||||
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
|
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
|
||||||
|
|
||||||
**Game Mechanic:** {{mechanic_name}}
|
**Game Mechanic:** {{mechanic_name}}
|
||||||
|
|
||||||
**Player Experience Goal:** {{experience_description}}
|
**Player Experience Goal:** {{experience_description}}
|
||||||
|
|
||||||
**Balance Parameters:**
|
**Balance Parameters:**
|
||||||
|
|
||||||
- {{parameter_1}}: {{value_or_range}}
|
- {{parameter_1}}: {{value_or_range}}
|
||||||
- {{parameter_2}}: {{value_or_range}}
|
- {{parameter_2}}: {{value_or_range}}
|
||||||
|
|
||||||
|
|
@ -210,15 +210,15 @@ sections:
|
||||||
instruction: List any dependencies that must be completed before this story can be implemented
|
instruction: List any dependencies that must be completed before this story can be implemented
|
||||||
template: |
|
template: |
|
||||||
**Story Dependencies:**
|
**Story Dependencies:**
|
||||||
|
|
||||||
- {{story_id}}: {{dependency_description}}
|
- {{story_id}}: {{dependency_description}}
|
||||||
|
|
||||||
**Technical Dependencies:**
|
**Technical Dependencies:**
|
||||||
|
|
||||||
- {{system_or_file}}: {{requirement}}
|
- {{system_or_file}}: {{requirement}}
|
||||||
|
|
||||||
**Asset Dependencies:**
|
**Asset Dependencies:**
|
||||||
|
|
||||||
- {{asset_type}}: {{asset_description}}
|
- {{asset_type}}: {{asset_description}}
|
||||||
- Location: `{{asset_path}}`
|
- Location: `{{asset_path}}`
|
||||||
|
|
||||||
|
|
@ -241,16 +241,16 @@ sections:
|
||||||
instruction: Any additional context, design decisions, or implementation notes
|
instruction: Any additional context, design decisions, or implementation notes
|
||||||
template: |
|
template: |
|
||||||
**Implementation Notes:**
|
**Implementation Notes:**
|
||||||
|
|
||||||
- {{note_1}}
|
- {{note_1}}
|
||||||
- {{note_2}}
|
- {{note_2}}
|
||||||
|
|
||||||
**Design Decisions:**
|
**Design Decisions:**
|
||||||
|
|
||||||
- {{decision_1}}: {{rationale}}
|
- {{decision_1}}: {{rationale}}
|
||||||
- {{decision_2}}: {{rationale}}
|
- {{decision_2}}: {{rationale}}
|
||||||
|
|
||||||
**Future Considerations:**
|
**Future Considerations:**
|
||||||
|
|
||||||
- {{future_enhancement_1}}
|
- {{future_enhancement_1}}
|
||||||
- {{future_optimization_1}}
|
- {{future_optimization_1}}
|
||||||
|
|
|
||||||
|
|
@ -14,7 +14,7 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels.
|
This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels.
|
||||||
|
|
||||||
If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents.
|
If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents.
|
||||||
|
|
||||||
- id: introduction
|
- id: introduction
|
||||||
|
|
@ -22,7 +22,7 @@ sections:
|
||||||
instruction: Establish the purpose and scope of level design for this game
|
instruction: Establish the purpose and scope of level design for this game
|
||||||
content: |
|
content: |
|
||||||
This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document.
|
This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document.
|
||||||
|
|
||||||
This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints.
|
This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints.
|
||||||
sections:
|
sections:
|
||||||
- id: change-log
|
- id: change-log
|
||||||
|
|
@ -69,29 +69,29 @@ sections:
|
||||||
title: "{{category_name}} Levels"
|
title: "{{category_name}} Levels"
|
||||||
template: |
|
template: |
|
||||||
**Purpose:** {{gameplay_purpose}}
|
**Purpose:** {{gameplay_purpose}}
|
||||||
|
|
||||||
**Target Duration:** {{min_time}} - {{max_time}} minutes
|
**Target Duration:** {{min_time}} - {{max_time}} minutes
|
||||||
|
|
||||||
**Difficulty Range:** {{difficulty_scale}}
|
**Difficulty Range:** {{difficulty_scale}}
|
||||||
|
|
||||||
**Key Mechanics Featured:**
|
**Key Mechanics Featured:**
|
||||||
|
|
||||||
- {{mechanic_1}} - {{usage_description}}
|
- {{mechanic_1}} - {{usage_description}}
|
||||||
- {{mechanic_2}} - {{usage_description}}
|
- {{mechanic_2}} - {{usage_description}}
|
||||||
|
|
||||||
**Player Objectives:**
|
**Player Objectives:**
|
||||||
|
|
||||||
- Primary: {{primary_objective}}
|
- Primary: {{primary_objective}}
|
||||||
- Secondary: {{secondary_objective}}
|
- Secondary: {{secondary_objective}}
|
||||||
- Hidden: {{secret_objective}}
|
- Hidden: {{secret_objective}}
|
||||||
|
|
||||||
**Success Criteria:**
|
**Success Criteria:**
|
||||||
|
|
||||||
- {{completion_requirement_1}}
|
- {{completion_requirement_1}}
|
||||||
- {{completion_requirement_2}}
|
- {{completion_requirement_2}}
|
||||||
|
|
||||||
**Technical Requirements:**
|
**Technical Requirements:**
|
||||||
|
|
||||||
- Maximum entities: {{entity_limit}}
|
- Maximum entities: {{entity_limit}}
|
||||||
- Performance target: {{fps_target}} FPS
|
- Performance target: {{fps_target}} FPS
|
||||||
- Memory budget: {{memory_limit}}MB
|
- Memory budget: {{memory_limit}}MB
|
||||||
|
|
@ -106,11 +106,11 @@ sections:
|
||||||
instruction: Based on GDD requirements, define the overall level organization
|
instruction: Based on GDD requirements, define the overall level organization
|
||||||
template: |
|
template: |
|
||||||
**Organization Type:** {{linear|hub_world|open_world}}
|
**Organization Type:** {{linear|hub_world|open_world}}
|
||||||
|
|
||||||
**Total Level Count:** {{number}}
|
**Total Level Count:** {{number}}
|
||||||
|
|
||||||
**World Breakdown:**
|
**World Breakdown:**
|
||||||
|
|
||||||
- World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
- World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||||
- World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
- World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||||
- World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
- World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||||
|
|
@ -145,7 +145,7 @@ sections:
|
||||||
instruction: Define how players access new levels
|
instruction: Define how players access new levels
|
||||||
template: |
|
template: |
|
||||||
**Progression Gates:**
|
**Progression Gates:**
|
||||||
|
|
||||||
- Linear progression: Complete previous level
|
- Linear progression: Complete previous level
|
||||||
- Star requirements: {{star_count}} stars to unlock
|
- Star requirements: {{star_count}} stars to unlock
|
||||||
- Skill gates: Demonstrate {{skill_requirement}}
|
- Skill gates: Demonstrate {{skill_requirement}}
|
||||||
|
|
@ -160,17 +160,17 @@ sections:
|
||||||
instruction: Define all environmental components that can be used in levels
|
instruction: Define all environmental components that can be used in levels
|
||||||
template: |
|
template: |
|
||||||
**Terrain Types:**
|
**Terrain Types:**
|
||||||
|
|
||||||
- {{terrain_1}}: {{properties_and_usage}}
|
- {{terrain_1}}: {{properties_and_usage}}
|
||||||
- {{terrain_2}}: {{properties_and_usage}}
|
- {{terrain_2}}: {{properties_and_usage}}
|
||||||
|
|
||||||
**Interactive Objects:**
|
**Interactive Objects:**
|
||||||
|
|
||||||
- {{object_1}}: {{behavior_and_purpose}}
|
- {{object_1}}: {{behavior_and_purpose}}
|
||||||
- {{object_2}}: {{behavior_and_purpose}}
|
- {{object_2}}: {{behavior_and_purpose}}
|
||||||
|
|
||||||
**Hazards and Obstacles:**
|
**Hazards and Obstacles:**
|
||||||
|
|
||||||
- {{hazard_1}}: {{damage_and_behavior}}
|
- {{hazard_1}}: {{damage_and_behavior}}
|
||||||
- {{hazard_2}}: {{damage_and_behavior}}
|
- {{hazard_2}}: {{damage_and_behavior}}
|
||||||
- id: collectibles-rewards
|
- id: collectibles-rewards
|
||||||
|
|
@ -178,18 +178,18 @@ sections:
|
||||||
instruction: Define all collectible items and their placement rules
|
instruction: Define all collectible items and their placement rules
|
||||||
template: |
|
template: |
|
||||||
**Collectible Types:**
|
**Collectible Types:**
|
||||||
|
|
||||||
- {{collectible_1}}: {{value_and_purpose}}
|
- {{collectible_1}}: {{value_and_purpose}}
|
||||||
- {{collectible_2}}: {{value_and_purpose}}
|
- {{collectible_2}}: {{value_and_purpose}}
|
||||||
|
|
||||||
**Placement Guidelines:**
|
**Placement Guidelines:**
|
||||||
|
|
||||||
- Mandatory collectibles: {{placement_rules}}
|
- Mandatory collectibles: {{placement_rules}}
|
||||||
- Optional collectibles: {{placement_rules}}
|
- Optional collectibles: {{placement_rules}}
|
||||||
- Secret collectibles: {{placement_rules}}
|
- Secret collectibles: {{placement_rules}}
|
||||||
|
|
||||||
**Reward Distribution:**
|
**Reward Distribution:**
|
||||||
|
|
||||||
- Easy to find: {{percentage}}%
|
- Easy to find: {{percentage}}%
|
||||||
- Moderate challenge: {{percentage}}%
|
- Moderate challenge: {{percentage}}%
|
||||||
- High skill required: {{percentage}}%
|
- High skill required: {{percentage}}%
|
||||||
|
|
@ -198,18 +198,18 @@ sections:
|
||||||
instruction: Define how enemies should be placed and balanced in levels
|
instruction: Define how enemies should be placed and balanced in levels
|
||||||
template: |
|
template: |
|
||||||
**Enemy Categories:**
|
**Enemy Categories:**
|
||||||
|
|
||||||
- {{enemy_type_1}}: {{behavior_and_usage}}
|
- {{enemy_type_1}}: {{behavior_and_usage}}
|
||||||
- {{enemy_type_2}}: {{behavior_and_usage}}
|
- {{enemy_type_2}}: {{behavior_and_usage}}
|
||||||
|
|
||||||
**Placement Principles:**
|
**Placement Principles:**
|
||||||
|
|
||||||
- Introduction encounters: {{guideline}}
|
- Introduction encounters: {{guideline}}
|
||||||
- Standard encounters: {{guideline}}
|
- Standard encounters: {{guideline}}
|
||||||
- Challenge encounters: {{guideline}}
|
- Challenge encounters: {{guideline}}
|
||||||
|
|
||||||
**Difficulty Scaling:**
|
**Difficulty Scaling:**
|
||||||
|
|
||||||
- Enemy count progression: {{scaling_rule}}
|
- Enemy count progression: {{scaling_rule}}
|
||||||
- Enemy type introduction: {{pacing_rule}}
|
- Enemy type introduction: {{pacing_rule}}
|
||||||
- Encounter complexity: {{complexity_rule}}
|
- Encounter complexity: {{complexity_rule}}
|
||||||
|
|
@ -222,14 +222,14 @@ sections:
|
||||||
title: Level Layout Principles
|
title: Level Layout Principles
|
||||||
template: |
|
template: |
|
||||||
**Spatial Design:**
|
**Spatial Design:**
|
||||||
|
|
||||||
- Grid size: {{grid_dimensions}}
|
- Grid size: {{grid_dimensions}}
|
||||||
- Minimum path width: {{width_units}}
|
- Minimum path width: {{width_units}}
|
||||||
- Maximum vertical distance: {{height_units}}
|
- Maximum vertical distance: {{height_units}}
|
||||||
- Safe zones placement: {{safety_guidelines}}
|
- Safe zones placement: {{safety_guidelines}}
|
||||||
|
|
||||||
**Navigation Design:**
|
**Navigation Design:**
|
||||||
|
|
||||||
- Clear path indication: {{visual_cues}}
|
- Clear path indication: {{visual_cues}}
|
||||||
- Landmark placement: {{landmark_rules}}
|
- Landmark placement: {{landmark_rules}}
|
||||||
- Dead end avoidance: {{dead_end_policy}}
|
- Dead end avoidance: {{dead_end_policy}}
|
||||||
|
|
@ -239,13 +239,13 @@ sections:
|
||||||
instruction: Define how to control the rhythm and pace of gameplay within levels
|
instruction: Define how to control the rhythm and pace of gameplay within levels
|
||||||
template: |
|
template: |
|
||||||
**Action Sequences:**
|
**Action Sequences:**
|
||||||
|
|
||||||
- High intensity duration: {{max_duration}}
|
- High intensity duration: {{max_duration}}
|
||||||
- Rest period requirement: {{min_rest_time}}
|
- Rest period requirement: {{min_rest_time}}
|
||||||
- Intensity variation: {{pacing_pattern}}
|
- Intensity variation: {{pacing_pattern}}
|
||||||
|
|
||||||
**Learning Sequences:**
|
**Learning Sequences:**
|
||||||
|
|
||||||
- New mechanic introduction: {{teaching_method}}
|
- New mechanic introduction: {{teaching_method}}
|
||||||
- Practice opportunity: {{practice_duration}}
|
- Practice opportunity: {{practice_duration}}
|
||||||
- Skill application: {{application_context}}
|
- Skill application: {{application_context}}
|
||||||
|
|
@ -254,14 +254,14 @@ sections:
|
||||||
instruction: Define how to create appropriate challenges for each level type
|
instruction: Define how to create appropriate challenges for each level type
|
||||||
template: |
|
template: |
|
||||||
**Challenge Types:**
|
**Challenge Types:**
|
||||||
|
|
||||||
- Execution challenges: {{skill_requirements}}
|
- Execution challenges: {{skill_requirements}}
|
||||||
- Puzzle challenges: {{complexity_guidelines}}
|
- Puzzle challenges: {{complexity_guidelines}}
|
||||||
- Time challenges: {{time_pressure_rules}}
|
- Time challenges: {{time_pressure_rules}}
|
||||||
- Resource challenges: {{resource_management}}
|
- Resource challenges: {{resource_management}}
|
||||||
|
|
||||||
**Difficulty Calibration:**
|
**Difficulty Calibration:**
|
||||||
|
|
||||||
- Skill check frequency: {{frequency_guidelines}}
|
- Skill check frequency: {{frequency_guidelines}}
|
||||||
- Failure recovery: {{retry_mechanics}}
|
- Failure recovery: {{retry_mechanics}}
|
||||||
- Hint system integration: {{help_system}}
|
- Hint system integration: {{help_system}}
|
||||||
|
|
@ -275,7 +275,7 @@ sections:
|
||||||
instruction: Define how level data should be structured for implementation
|
instruction: Define how level data should be structured for implementation
|
||||||
template: |
|
template: |
|
||||||
**Level File Format:**
|
**Level File Format:**
|
||||||
|
|
||||||
- Data format: {{json|yaml|custom}}
|
- Data format: {{json|yaml|custom}}
|
||||||
- File naming: `level_{{world}}_{{number}}.{{extension}}`
|
- File naming: `level_{{world}}_{{number}}.{{extension}}`
|
||||||
- Data organization: {{structure_description}}
|
- Data organization: {{structure_description}}
|
||||||
|
|
@ -313,14 +313,14 @@ sections:
|
||||||
instruction: Define how level assets are organized and loaded
|
instruction: Define how level assets are organized and loaded
|
||||||
template: |
|
template: |
|
||||||
**Tilemap Requirements:**
|
**Tilemap Requirements:**
|
||||||
|
|
||||||
- Tile size: {{tile_dimensions}}px
|
- Tile size: {{tile_dimensions}}px
|
||||||
- Tileset organization: {{tileset_structure}}
|
- Tileset organization: {{tileset_structure}}
|
||||||
- Layer organization: {{layer_system}}
|
- Layer organization: {{layer_system}}
|
||||||
- Collision data: {{collision_format}}
|
- Collision data: {{collision_format}}
|
||||||
|
|
||||||
**Audio Integration:**
|
**Audio Integration:**
|
||||||
|
|
||||||
- Background music: {{music_requirements}}
|
- Background music: {{music_requirements}}
|
||||||
- Ambient sounds: {{ambient_system}}
|
- Ambient sounds: {{ambient_system}}
|
||||||
- Dynamic audio: {{dynamic_audio_rules}}
|
- Dynamic audio: {{dynamic_audio_rules}}
|
||||||
|
|
@ -329,19 +329,19 @@ sections:
|
||||||
instruction: Define performance requirements for level systems
|
instruction: Define performance requirements for level systems
|
||||||
template: |
|
template: |
|
||||||
**Entity Limits:**
|
**Entity Limits:**
|
||||||
|
|
||||||
- Maximum active entities: {{entity_limit}}
|
- Maximum active entities: {{entity_limit}}
|
||||||
- Maximum particles: {{particle_limit}}
|
- Maximum particles: {{particle_limit}}
|
||||||
- Maximum audio sources: {{audio_limit}}
|
- Maximum audio sources: {{audio_limit}}
|
||||||
|
|
||||||
**Memory Management:**
|
**Memory Management:**
|
||||||
|
|
||||||
- Texture memory budget: {{texture_memory}}MB
|
- Texture memory budget: {{texture_memory}}MB
|
||||||
- Audio memory budget: {{audio_memory}}MB
|
- Audio memory budget: {{audio_memory}}MB
|
||||||
- Level loading time: <{{load_time}}s
|
- Level loading time: <{{load_time}}s
|
||||||
|
|
||||||
**Culling and LOD:**
|
**Culling and LOD:**
|
||||||
|
|
||||||
- Off-screen culling: {{culling_distance}}
|
- Off-screen culling: {{culling_distance}}
|
||||||
- Level-of-detail rules: {{lod_system}}
|
- Level-of-detail rules: {{lod_system}}
|
||||||
- Asset streaming: {{streaming_requirements}}
|
- Asset streaming: {{streaming_requirements}}
|
||||||
|
|
@ -354,13 +354,13 @@ sections:
|
||||||
title: Automated Testing
|
title: Automated Testing
|
||||||
template: |
|
template: |
|
||||||
**Performance Testing:**
|
**Performance Testing:**
|
||||||
|
|
||||||
- Frame rate validation: Maintain {{fps_target}} FPS
|
- Frame rate validation: Maintain {{fps_target}} FPS
|
||||||
- Memory usage monitoring: Stay under {{memory_limit}}MB
|
- Memory usage monitoring: Stay under {{memory_limit}}MB
|
||||||
- Loading time verification: Complete in <{{load_time}}s
|
- Loading time verification: Complete in <{{load_time}}s
|
||||||
|
|
||||||
**Gameplay Testing:**
|
**Gameplay Testing:**
|
||||||
|
|
||||||
- Completion path validation: All objectives achievable
|
- Completion path validation: All objectives achievable
|
||||||
- Collectible accessibility: All items reachable
|
- Collectible accessibility: All items reachable
|
||||||
- Softlock prevention: No unwinnable states
|
- Softlock prevention: No unwinnable states
|
||||||
|
|
@ -388,14 +388,14 @@ sections:
|
||||||
title: Balance Validation
|
title: Balance Validation
|
||||||
template: |
|
template: |
|
||||||
**Metrics Collection:**
|
**Metrics Collection:**
|
||||||
|
|
||||||
- Completion rate: Target {{completion_percentage}}%
|
- Completion rate: Target {{completion_percentage}}%
|
||||||
- Average completion time: {{target_time}} ± {{variance}}
|
- Average completion time: {{target_time}} ± {{variance}}
|
||||||
- Death count per level: <{{max_deaths}}
|
- Death count per level: <{{max_deaths}}
|
||||||
- Collectible discovery rate: {{discovery_percentage}}%
|
- Collectible discovery rate: {{discovery_percentage}}%
|
||||||
|
|
||||||
**Iteration Guidelines:**
|
**Iteration Guidelines:**
|
||||||
|
|
||||||
- Adjustment criteria: {{criteria_for_changes}}
|
- Adjustment criteria: {{criteria_for_changes}}
|
||||||
- Testing sample size: {{minimum_testers}}
|
- Testing sample size: {{minimum_testers}}
|
||||||
- Validation period: {{testing_duration}}
|
- Validation period: {{testing_duration}}
|
||||||
|
|
@ -408,14 +408,14 @@ sections:
|
||||||
title: Design Phase
|
title: Design Phase
|
||||||
template: |
|
template: |
|
||||||
**Concept Development:**
|
**Concept Development:**
|
||||||
|
|
||||||
1. Define level purpose and goals
|
1. Define level purpose and goals
|
||||||
2. Create rough layout sketch
|
2. Create rough layout sketch
|
||||||
3. Identify key mechanics and challenges
|
3. Identify key mechanics and challenges
|
||||||
4. Estimate difficulty and duration
|
4. Estimate difficulty and duration
|
||||||
|
|
||||||
**Documentation Requirements:**
|
**Documentation Requirements:**
|
||||||
|
|
||||||
- Level design brief
|
- Level design brief
|
||||||
- Layout diagrams
|
- Layout diagrams
|
||||||
- Mechanic integration notes
|
- Mechanic integration notes
|
||||||
|
|
@ -424,15 +424,15 @@ sections:
|
||||||
title: Implementation Phase
|
title: Implementation Phase
|
||||||
template: |
|
template: |
|
||||||
**Technical Implementation:**
|
**Technical Implementation:**
|
||||||
|
|
||||||
1. Create level data file
|
1. Create level data file
|
||||||
2. Build tilemap and layout
|
2. Build tilemap and layout
|
||||||
3. Place entities and objects
|
3. Place entities and objects
|
||||||
4. Configure level logic and triggers
|
4. Configure level logic and triggers
|
||||||
5. Integrate audio and visual effects
|
5. Integrate audio and visual effects
|
||||||
|
|
||||||
**Quality Assurance:**
|
**Quality Assurance:**
|
||||||
|
|
||||||
1. Automated testing execution
|
1. Automated testing execution
|
||||||
2. Internal playtesting
|
2. Internal playtesting
|
||||||
3. Performance validation
|
3. Performance validation
|
||||||
|
|
@ -441,14 +441,14 @@ sections:
|
||||||
title: Integration Phase
|
title: Integration Phase
|
||||||
template: |
|
template: |
|
||||||
**Game Integration:**
|
**Game Integration:**
|
||||||
|
|
||||||
1. Level progression integration
|
1. Level progression integration
|
||||||
2. Save system compatibility
|
2. Save system compatibility
|
||||||
3. Analytics integration
|
3. Analytics integration
|
||||||
4. Achievement system integration
|
4. Achievement system integration
|
||||||
|
|
||||||
**Final Validation:**
|
**Final Validation:**
|
||||||
|
|
||||||
1. Full game context testing
|
1. Full game context testing
|
||||||
2. Performance regression testing
|
2. Performance regression testing
|
||||||
3. Platform compatibility verification
|
3. Platform compatibility verification
|
||||||
|
|
@ -481,4 +481,4 @@ sections:
|
||||||
- Difficulty curve adherence: {{curve_accuracy}}
|
- Difficulty curve adherence: {{curve_accuracy}}
|
||||||
- Mechanic integration effectiveness: {{integration_score}}
|
- Mechanic integration effectiveness: {{integration_score}}
|
||||||
- Player guidance clarity: {{guidance_score}}
|
- Player guidance clarity: {{guidance_score}}
|
||||||
- Content accessibility: {{accessibility_rate}}%
|
- Content accessibility: {{accessibility_rate}}%
|
||||||
|
|
|
||||||
|
|
@ -17,21 +17,21 @@ workflow:
|
||||||
- brainstorming_session
|
- brainstorming_session
|
||||||
- game_research_prompt
|
- game_research_prompt
|
||||||
- player_research
|
- player_research
|
||||||
notes: 'Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/design/ folder.'
|
notes: "Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project's docs/design/ folder."
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: game-design-doc.md
|
creates: game-design-doc.md
|
||||||
requires: game-brief.md
|
requires: game-brief.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- competitive_analysis
|
- competitive_analysis
|
||||||
- technical_research
|
- technical_research
|
||||||
notes: 'Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project''s docs/design/ folder.'
|
notes: "Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project's docs/design/ folder."
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: level-design-doc.md
|
creates: level-design-doc.md
|
||||||
requires: game-design-doc.md
|
requires: game-design-doc.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- level_prototyping
|
- level_prototyping
|
||||||
- difficulty_analysis
|
- difficulty_analysis
|
||||||
notes: 'Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project''s docs/design/ folder.'
|
notes: "Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project's docs/design/ folder."
|
||||||
- agent: solution-architect
|
- agent: solution-architect
|
||||||
creates: game-architecture.md
|
creates: game-architecture.md
|
||||||
requires:
|
requires:
|
||||||
|
|
@ -41,7 +41,7 @@ workflow:
|
||||||
- technical_research_prompt
|
- technical_research_prompt
|
||||||
- performance_analysis
|
- performance_analysis
|
||||||
- platform_research
|
- platform_research
|
||||||
notes: 'Create comprehensive technical architecture using game-architecture-tmpl. Defines Unity systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project''s docs/architecture/ folder.'
|
notes: "Create comprehensive technical architecture using game-architecture-tmpl. Defines Unity systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project's docs/architecture/ folder."
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
validates: design_consistency
|
validates: design_consistency
|
||||||
requires: all_design_documents
|
requires: all_design_documents
|
||||||
|
|
@ -66,7 +66,7 @@ workflow:
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- quick_brainstorming
|
- quick_brainstorming
|
||||||
- concept_validation
|
- concept_validation
|
||||||
notes: 'Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/ folder.'
|
notes: "Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project's docs/ folder."
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: prototype-design.md
|
creates: prototype-design.md
|
||||||
uses: create-doc prototype-design OR create-game-story
|
uses: create-doc prototype-design OR create-game-story
|
||||||
|
|
|
||||||
|
|
@ -44,7 +44,7 @@ workflow:
|
||||||
notes: Implement stories in priority order. Test frequently in the Unity Editor and adjust design based on what feels fun. Document discoveries.
|
notes: Implement stories in priority order. Test frequently in the Unity Editor and adjust design based on what feels fun. Document discoveries.
|
||||||
workflow_end:
|
workflow_end:
|
||||||
action: prototype_evaluation
|
action: prototype_evaluation
|
||||||
notes: 'Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive.'
|
notes: "Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive."
|
||||||
game_jam_sequence:
|
game_jam_sequence:
|
||||||
- step: jam_concept
|
- step: jam_concept
|
||||||
agent: game-designer
|
agent: game-designer
|
||||||
|
|
|
||||||
|
|
@ -27,18 +27,18 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
Initial Setup
|
Initial Setup
|
||||||
|
|
||||||
1. Replace {{project_name}} with the actual project name throughout the document
|
1. Replace {{project_name}} with the actual project name throughout the document
|
||||||
2. Gather and review required inputs:
|
2. Gather and review required inputs:
|
||||||
- Product Requirements Document (PRD) - Required for business needs and scale requirements
|
- Product Requirements Document (PRD) - Required for business needs and scale requirements
|
||||||
- Main System Architecture - Required for infrastructure dependencies
|
- Main System Architecture - Required for infrastructure dependencies
|
||||||
- Technical Preferences/Tech Stack Document - Required for technology choices
|
- Technical Preferences/Tech Stack Document - Required for technology choices
|
||||||
- PRD Technical Assumptions - Required for cross-referencing repository and service architecture
|
- PRD Technical Assumptions - Required for cross-referencing repository and service architecture
|
||||||
|
|
||||||
If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
|
If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
|
||||||
|
|
||||||
3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
|
3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
|
||||||
|
|
||||||
Output file location: `docs/infrastructure-architecture.md`
|
Output file location: `docs/infrastructure-architecture.md`
|
||||||
|
|
||||||
- id: infrastructure-overview
|
- id: infrastructure-overview
|
||||||
|
|
@ -67,7 +67,7 @@ sections:
|
||||||
- Repository Structure
|
- Repository Structure
|
||||||
- State Management
|
- State Management
|
||||||
- Dependency Management
|
- Dependency Management
|
||||||
|
|
||||||
<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
|
<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
|
||||||
|
|
||||||
- id: environment-configuration
|
- id: environment-configuration
|
||||||
|
|
@ -103,7 +103,7 @@ sections:
|
||||||
title: Network Architecture
|
title: Network Architecture
|
||||||
instruction: |
|
instruction: |
|
||||||
Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
|
Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
|
||||||
|
|
||||||
Create Mermaid diagram showing:
|
Create Mermaid diagram showing:
|
||||||
- VPC/Network structure
|
- VPC/Network structure
|
||||||
- Security zones and boundaries
|
- Security zones and boundaries
|
||||||
|
|
@ -166,7 +166,7 @@ sections:
|
||||||
title: Data Resources
|
title: Data Resources
|
||||||
instruction: |
|
instruction: |
|
||||||
Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
|
Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
|
||||||
|
|
||||||
Create data flow diagram showing:
|
Create data flow diagram showing:
|
||||||
- Database topology
|
- Database topology
|
||||||
- Replication patterns
|
- Replication patterns
|
||||||
|
|
@ -187,7 +187,7 @@ sections:
|
||||||
- Data Encryption
|
- Data Encryption
|
||||||
- Compliance Controls
|
- Compliance Controls
|
||||||
- Security Scanning & Monitoring
|
- Security Scanning & Monitoring
|
||||||
|
|
||||||
<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
|
<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
|
||||||
|
|
||||||
- id: shared-responsibility
|
- id: shared-responsibility
|
||||||
|
|
@ -223,7 +223,7 @@ sections:
|
||||||
title: CI/CD Pipeline
|
title: CI/CD Pipeline
|
||||||
instruction: |
|
instruction: |
|
||||||
Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
|
Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
|
||||||
|
|
||||||
Create pipeline diagram showing:
|
Create pipeline diagram showing:
|
||||||
- Build stages
|
- Build stages
|
||||||
- Test gates
|
- Test gates
|
||||||
|
|
@ -254,7 +254,7 @@ sections:
|
||||||
- Recovery Procedures
|
- Recovery Procedures
|
||||||
- RTO & RPO Targets
|
- RTO & RPO Targets
|
||||||
- DR Testing Approach
|
- DR Testing Approach
|
||||||
|
|
||||||
<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
|
<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
|
||||||
|
|
||||||
- id: cost-optimization
|
- id: cost-optimization
|
||||||
|
|
@ -296,15 +296,15 @@ sections:
|
||||||
title: DevOps/Platform Feasibility Review
|
title: DevOps/Platform Feasibility Review
|
||||||
instruction: |
|
instruction: |
|
||||||
CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
|
CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
|
||||||
|
|
||||||
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
|
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
|
||||||
- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
|
- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
|
||||||
- **Security Implementation:** Are security patterns achievable with current security toolchain?
|
- **Security Implementation:** Are security patterns achievable with current security toolchain?
|
||||||
- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
|
- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
|
||||||
- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
|
- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
|
||||||
|
|
||||||
Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
|
Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
|
||||||
|
|
||||||
<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>
|
<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>
|
||||||
sections:
|
sections:
|
||||||
- id: feasibility-results
|
- id: feasibility-results
|
||||||
|
|
@ -322,7 +322,7 @@ sections:
|
||||||
title: Validation Framework
|
title: Validation Framework
|
||||||
content: |
|
content: |
|
||||||
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
|
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
|
||||||
|
|
||||||
- Completeness of architecture documentation
|
- Completeness of architecture documentation
|
||||||
- Consistency with broader system architecture
|
- Consistency with broader system architecture
|
||||||
- Appropriate level of detail for different stakeholders
|
- Appropriate level of detail for different stakeholders
|
||||||
|
|
@ -332,12 +332,12 @@ sections:
|
||||||
title: Validation Process
|
title: Validation Process
|
||||||
content: |
|
content: |
|
||||||
The architecture documentation validation should be performed:
|
The architecture documentation validation should be performed:
|
||||||
|
|
||||||
- After initial architecture development
|
- After initial architecture development
|
||||||
- After significant architecture changes
|
- After significant architecture changes
|
||||||
- Before major implementation phases
|
- Before major implementation phases
|
||||||
- During periodic architecture reviews
|
- During periodic architecture reviews
|
||||||
|
|
||||||
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
|
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
|
||||||
|
|
||||||
- id: implementation-handoff
|
- id: implementation-handoff
|
||||||
|
|
@ -348,7 +348,7 @@ sections:
|
||||||
title: Architecture Decision Records (ADRs)
|
title: Architecture Decision Records (ADRs)
|
||||||
content: |
|
content: |
|
||||||
Create ADRs for key infrastructure decisions:
|
Create ADRs for key infrastructure decisions:
|
||||||
|
|
||||||
- Cloud provider selection rationale
|
- Cloud provider selection rationale
|
||||||
- Container orchestration platform choice
|
- Container orchestration platform choice
|
||||||
- Networking architecture decisions
|
- Networking architecture decisions
|
||||||
|
|
@ -358,7 +358,7 @@ sections:
|
||||||
title: Implementation Validation Criteria
|
title: Implementation Validation Criteria
|
||||||
content: |
|
content: |
|
||||||
Define specific criteria for validating correct implementation:
|
Define specific criteria for validating correct implementation:
|
||||||
|
|
||||||
- Infrastructure as Code quality gates
|
- Infrastructure as Code quality gates
|
||||||
- Security compliance checkpoints
|
- Security compliance checkpoints
|
||||||
- Performance benchmarks
|
- Performance benchmarks
|
||||||
|
|
@ -418,7 +418,7 @@ sections:
|
||||||
instruction: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.
|
instruction: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.
|
||||||
content: |
|
content: |
|
||||||
---
|
---
|
||||||
|
|
||||||
_Document Version: 1.0_
|
_Document Version: 1.0_
|
||||||
_Last Updated: {{current_date}}_
|
_Last Updated: {{current_date}}_
|
||||||
_Next Review: {{review_date}}_
|
_Next Review: {{review_date}}_
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ sections:
|
||||||
- id: initial-setup
|
- id: initial-setup
|
||||||
instruction: |
|
instruction: |
|
||||||
Initial Setup
|
Initial Setup
|
||||||
|
|
||||||
1. Replace {{project_name}} with the actual project name throughout the document
|
1. Replace {{project_name}} with the actual project name throughout the document
|
||||||
2. Gather and review required inputs:
|
2. Gather and review required inputs:
|
||||||
- **Infrastructure Architecture Document** (Primary input - REQUIRED)
|
- **Infrastructure Architecture Document** (Primary input - REQUIRED)
|
||||||
|
|
@ -37,10 +37,10 @@ sections:
|
||||||
- Technology Stack Document
|
- Technology Stack Document
|
||||||
- Infrastructure Checklist
|
- Infrastructure Checklist
|
||||||
- NOTE: If Infrastructure Architecture Document is missing, HALT and request: "I need the Infrastructure Architecture Document to proceed with platform implementation. This document defines the infrastructure design that we'll be implementing."
|
- NOTE: If Infrastructure Architecture Document is missing, HALT and request: "I need the Infrastructure Architecture Document to proceed with platform implementation. This document defines the infrastructure design that we'll be implementing."
|
||||||
|
|
||||||
3. Validate that the infrastructure architecture has been reviewed and approved
|
3. Validate that the infrastructure architecture has been reviewed and approved
|
||||||
4. <critical_rule>All platform implementation must align with the approved infrastructure architecture. Any deviations require architect approval.</critical_rule>
|
4. <critical_rule>All platform implementation must align with the approved infrastructure architecture. Any deviations require architect approval.</critical_rule>
|
||||||
|
|
||||||
Output file location: `docs/platform-infrastructure/platform-implementation.md`
|
Output file location: `docs/platform-infrastructure/platform-implementation.md`
|
||||||
|
|
||||||
- id: executive-summary
|
- id: executive-summary
|
||||||
|
|
@ -113,7 +113,7 @@ sections:
|
||||||
# Example Terraform for VPC setup
|
# Example Terraform for VPC setup
|
||||||
module "vpc" {
|
module "vpc" {
|
||||||
source = "./modules/vpc"
|
source = "./modules/vpc"
|
||||||
|
|
||||||
cidr_block = "{{vpc_cidr}}"
|
cidr_block = "{{vpc_cidr}}"
|
||||||
availability_zones = {{availability_zones}}
|
availability_zones = {{availability_zones}}
|
||||||
public_subnets = {{public_subnets}}
|
public_subnets = {{public_subnets}}
|
||||||
|
|
@ -508,7 +508,7 @@ sections:
|
||||||
// K6 Load Test Example
|
// K6 Load Test Example
|
||||||
import http from 'k6/http';
|
import http from 'k6/http';
|
||||||
import { check } from 'k6';
|
import { check } from 'k6';
|
||||||
|
|
||||||
export let options = {
|
export let options = {
|
||||||
stages: [
|
stages: [
|
||||||
{ duration: '5m', target: {{target_users}} },
|
{ duration: '5m', target: {{target_users}} },
|
||||||
|
|
@ -622,8 +622,8 @@ sections:
|
||||||
instruction: Final Review - Ensure all platform layers are properly implemented, integrated, and documented. Verify that the implementation fully supports the BMAD methodology and all agent workflows. Confirm successful validation against the infrastructure checklist.
|
instruction: Final Review - Ensure all platform layers are properly implemented, integrated, and documented. Verify that the implementation fully supports the BMAD methodology and all agent workflows. Confirm successful validation against the infrastructure checklist.
|
||||||
content: |
|
content: |
|
||||||
---
|
---
|
||||||
|
|
||||||
_Platform Version: 1.0_
|
_Platform Version: 1.0_
|
||||||
_Implementation Date: {{implementation_date}}_
|
_Implementation Date: {{implementation_date}}_
|
||||||
_Next Review: {{review_date}}_
|
_Next Review: {{review_date}}_
|
||||||
_Approved by: {{architect_name}} (Architect), {{devops_name}} (DevOps/Platform Engineer)_
|
_Approved by: {{architect_name}} (Architect), {{devops_name}} (DevOps/Platform Engineer)_
|
||||||
|
|
|
||||||
|
|
@ -1,134 +0,0 @@
|
||||||
# Cline's Memory Bank
|
|
||||||
|
|
||||||
I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
|
|
||||||
|
|
||||||
## Memory Bank Structure
|
|
||||||
|
|
||||||
The Memory Bank consists of core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
PB[projectbrief.md] --> PC[productContext.md]
|
|
||||||
PB --> SP[systemPatterns.md]
|
|
||||||
PB --> TC[techContext.md]
|
|
||||||
|
|
||||||
PC --> AC[activeContext.md]
|
|
||||||
SP --> AC
|
|
||||||
TC --> AC
|
|
||||||
|
|
||||||
AC --> P[progress.md]
|
|
||||||
```
|
|
||||||
|
|
||||||
### Core Files (Required)
|
|
||||||
|
|
||||||
1. `projectbrief.md`
|
|
||||||
|
|
||||||
- Foundation document that shapes all other files
|
|
||||||
- Created at project start if it doesn't exist
|
|
||||||
- Defines core requirements and goals
|
|
||||||
- Source of truth for project scope
|
|
||||||
|
|
||||||
2. `productContext.md`
|
|
||||||
|
|
||||||
- Why this project exists
|
|
||||||
- Problems it solves
|
|
||||||
- How it should work
|
|
||||||
- User experience goals
|
|
||||||
|
|
||||||
3. `activeContext.md`
|
|
||||||
|
|
||||||
- Current work focus
|
|
||||||
- Recent changes
|
|
||||||
- Next steps
|
|
||||||
- Active decisions and considerations
|
|
||||||
- Important patterns and preferences
|
|
||||||
- Learnings and project insights
|
|
||||||
|
|
||||||
4. `systemPatterns.md`
|
|
||||||
|
|
||||||
- System architecture
|
|
||||||
- Key technical decisions
|
|
||||||
- Design patterns in use
|
|
||||||
- Component relationships
|
|
||||||
- Critical implementation paths
|
|
||||||
|
|
||||||
5. `techContext.md`
|
|
||||||
|
|
||||||
- Technologies used
|
|
||||||
- Development setup
|
|
||||||
- Technical constraints
|
|
||||||
- Dependencies
|
|
||||||
- Tool usage patterns
|
|
||||||
|
|
||||||
6. `progress.md`
|
|
||||||
- What works
|
|
||||||
- What's left to build
|
|
||||||
- Current status
|
|
||||||
- Known issues
|
|
||||||
- Evolution of project decisions
|
|
||||||
|
|
||||||
### Additional Context
|
|
||||||
|
|
||||||
Create additional files/folders within memory-bank/ when they help organize:
|
|
||||||
|
|
||||||
- Complex feature documentation
|
|
||||||
- Integration specifications
|
|
||||||
- API documentation
|
|
||||||
- Testing strategies
|
|
||||||
- Deployment procedures
|
|
||||||
|
|
||||||
## Core Workflows
|
|
||||||
|
|
||||||
### Plan Mode
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
Start[Start] --> ReadFiles[Read Memory Bank]
|
|
||||||
ReadFiles --> CheckFiles{Files Complete?}
|
|
||||||
|
|
||||||
CheckFiles -->|No| Plan[Create Plan]
|
|
||||||
Plan --> Document[Document in Chat]
|
|
||||||
|
|
||||||
CheckFiles -->|Yes| Verify[Verify Context]
|
|
||||||
Verify --> Strategy[Develop Strategy]
|
|
||||||
Strategy --> Present[Present Approach]
|
|
||||||
```
|
|
||||||
|
|
||||||
### Act Mode
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
Start[Start] --> Context[Check Memory Bank]
|
|
||||||
Context --> Update[Update Documentation]
|
|
||||||
Update --> Execute[Execute Task]
|
|
||||||
Execute --> Document[Document Changes]
|
|
||||||
```
|
|
||||||
|
|
||||||
## Documentation Updates
|
|
||||||
|
|
||||||
Memory Bank updates occur when:
|
|
||||||
|
|
||||||
1. Discovering new project patterns
|
|
||||||
2. After implementing significant changes
|
|
||||||
3. When user requests with **update memory bank** (MUST review ALL files)
|
|
||||||
4. When context needs clarification
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
Start[Update Process]
|
|
||||||
|
|
||||||
subgraph Process
|
|
||||||
P1[Review ALL Files]
|
|
||||||
P2[Document Current State]
|
|
||||||
P3[Clarify Next Steps]
|
|
||||||
P4[Document Insights & Patterns]
|
|
||||||
|
|
||||||
P1 --> P2 --> P3 --> P4
|
|
||||||
end
|
|
||||||
|
|
||||||
Start --> Process
|
|
||||||
```
|
|
||||||
|
|
||||||
Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md and progress.md as they track current state.
|
|
||||||
|
|
||||||
REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
|
|
||||||
|
|
@ -1,163 +0,0 @@
|
||||||
# Project Guidelines
|
|
||||||
|
|
||||||
> **Scope:** This document outlines high-level, project-specific guidelines, policies, and standards unique to this project. It serves as the primary entry point to the rule system, linking to more detailed principles in other files. For universal coding principles, see `02-CoreCodingPrinciples.md`. For mandatory file structure, see `03-ProjectScaffoldingRules.md`. For cloud-native development, see `04-TwelveFactorApp.md`. For our service architecture, see `05-MicroServiceOrientedArchitecture.md`.
|
|
||||||
|
|
||||||
## Documentation Requirements
|
|
||||||
|
|
||||||
- Update relevant documentation in /docs when modifying features
|
|
||||||
- Keep README.md in sync with new capabilities
|
|
||||||
- Maintain changelog entries in CHANGELOG.md
|
|
||||||
|
|
||||||
## Documentation Discipline
|
|
||||||
|
|
||||||
- All major changes must be reflected in README, ADRs, dev journals, and changelogs.
|
|
||||||
- Use and maintain templates for sprint reviews and journal entries.
|
|
||||||
- Document onboarding steps, environment requirements, and common pitfalls in README files.
|
|
||||||
|
|
||||||
## Accessibility & Inclusion
|
|
||||||
|
|
||||||
- All UI components must meet WCAG 2.1 AA accessibility standards.
|
|
||||||
- Ensure sufficient color contrast, keyboard navigation, and screen reader support.
|
|
||||||
- Use inclusive language in documentation and user-facing text.
|
|
||||||
- Accessibility must be tested as part of code review and release.
|
|
||||||
|
|
||||||
## Architecture
|
|
||||||
|
|
||||||
- This project follows a **Microservice-Oriented Architecture**.
|
|
||||||
- All development must adhere to the principles outlined in `04-TwelveFactorApp.md` for cloud-native compatibility and `05-MicroServiceOrientedArchitecture.md` for service design and implementation patterns.
|
|
||||||
|
|
||||||
## Architecture Decision Records
|
|
||||||
|
|
||||||
Create ADRs in /docs/adr for:
|
|
||||||
|
|
||||||
- Major dependency changes
|
|
||||||
- Architectural pattern changes
|
|
||||||
- New integration patterns
|
|
||||||
- Database schema changes
|
|
||||||
Follow template in /docs/adr/template.md
|
|
||||||
|
|
||||||
## Code Style & Patterns
|
|
||||||
|
|
||||||
- Generate API clients using OpenAPI Generator
|
|
||||||
- Use TypeScript axios template
|
|
||||||
- Place generated code in /src/generated
|
|
||||||
- Prefer composition over inheritance
|
|
||||||
- Use repository pattern for data access
|
|
||||||
- Follow error handling pattern in /src/utils/errors.ts
|
|
||||||
|
|
||||||
## REST API Implementation
|
|
||||||
|
|
||||||
- REST endpoints must follow the `CustomEndpointDelegate` pattern and reside in package-scoped Groovy files.
|
|
||||||
- Always declare the package at the top of each endpoint file.
|
|
||||||
- Configure REST script roots and packages via environment variables for auto-discovery.
|
|
||||||
|
|
||||||
## Testing Standards
|
|
||||||
|
|
||||||
- Unit tests required for business logic
|
|
||||||
- Integration tests for API endpoints
|
|
||||||
- E2E tests for critical user flows
|
|
||||||
|
|
||||||
## Testing & Data Utilities
|
|
||||||
|
|
||||||
- All critical endpoints and data utilities must have integration tests.
|
|
||||||
- Synthetic data scripts must be idempotent, robust, and never modify migration tracking tables.
|
|
||||||
- Document the behavior and safety of all data utility scripts.
|
|
||||||
|
|
||||||
## Security & Performance Considerations
|
|
||||||
|
|
||||||
- **Input Validation (IV):** All external data must be validated before processing.
|
|
||||||
- **Resource Management (RM):** Close connections and free resources appropriately.
|
|
||||||
- **Constants Over Magic Values (CMV):** No magic strings or numbers. Use named constants.
|
|
||||||
- **Security-First Thinking (SFT):** Implement proper authentication, authorization, and data protection.
|
|
||||||
- **Performance Awareness (PA):** Consider computational complexity and resource usage.
|
|
||||||
- Rate limit all api endpoints
|
|
||||||
- Use row level security always (RLS)
|
|
||||||
- Captcha on all auth routes/signup pages
|
|
||||||
- If using hosting solution like vercel, enable attack challenge on their WAF
|
|
||||||
- DO NOT read or modify, without prior approval by user:
|
|
||||||
- .env files
|
|
||||||
- \*_/config/secrets._
|
|
||||||
- Any file containing API keys or credentials
|
|
||||||
|
|
||||||
## Security & Quality Automation
|
|
||||||
|
|
||||||
- Integrate Semgrep for static analysis and security scanning in all projects.
|
|
||||||
- Use MegaLinter (or equivalent) for multi-language linting and formatting.
|
|
||||||
- Supplement with language/framework-specific linters (e.g., ESLint for JS/TS, flake8 for Python, RuboCop for Ruby).
|
|
||||||
- All linting and static analysis tools must be run in CI/CD pipelines; merges are blocked on failure.
|
|
||||||
- Linter and static analysis configurations must be version-controlled and documented at the project root.
|
|
||||||
- Regularly review and update linter/analysis rules to address new threats and maintain code quality.
|
|
||||||
- Document and version-control all ignore rules and linter configs.
|
|
||||||
- CI checks must pass before merging any code.
|
|
||||||
|
|
||||||
## Miscellaneous recommendations
|
|
||||||
|
|
||||||
- Always prefer simple solutions
|
|
||||||
- Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality
|
|
||||||
- Write code that takes into account the different environments: dev, test, and prod
|
|
||||||
- You are careful to only make changes that are requested or you are confident are well understood and related to the change being requested
|
|
||||||
- When fixing an issue or bug, do not introduce a new pattern or technology without first exhausting all options for the existing implementation. And if you finally do this, make sure to remove the old implementation afterwards so we don't have duplicate logic.
|
|
||||||
- Keep the codebase very clean and organized
|
|
||||||
- Avoid writing scripts in files if possible, especially if the script is likely only to be run once
|
|
||||||
- Avoid having files over 200-300 lines
|
|
||||||
|
|
||||||
## Project Structure
|
|
||||||
|
|
||||||
- Avoid unnecessary plugin or build complexity; prefer script-based, automatable deployment.
|
|
||||||
- Mocking data is only needed for tests, never mock data for dev or prod
|
|
||||||
- Never add stubbing or fake data patterns to code that affects the dev or prod environments
|
|
||||||
- Never overwrite my .env file without first asking and confirming
|
|
||||||
|
|
||||||
## Automation & CI/CD
|
|
||||||
|
|
||||||
- All code must pass linting and formatting checks in CI before merge.
|
|
||||||
- CI must run all tests (unit, integration, E2E) and block merges on failure.
|
|
||||||
- Add new linters or formatters only with team consensus.
|
|
||||||
|
|
||||||
## Local Development Environment
|
|
||||||
|
|
||||||
- Use Podman or Docker and Ansible for local environment setup.
|
|
||||||
- Provide wrapper scripts for starting, stopping, and resetting the environment; avoid direct Ansible or container CLI usage.
|
|
||||||
- Ensure all environment configuration is version-controlled.
|
|
||||||
|
|
||||||
## Branching & Release Policy
|
|
||||||
|
|
||||||
- Follow [your branching model, e.g. Git Flow or trunk-based] for all work.
|
|
||||||
- Use semantic versioning for releases.
|
|
||||||
- Release branches must be code-frozen and pass all CI checks before tagging.
|
|
||||||
|
|
||||||
## Incident Response
|
|
||||||
|
|
||||||
- Maintain an incident log documenting bugs, outages, and recovery actions.
|
|
||||||
- After any incident, hold a retrospective and update runbooks as needed.
|
|
||||||
- Critical incidents must be reviewed in the next team meeting.
|
|
||||||
|
|
||||||
## Data Privacy & Compliance
|
|
||||||
|
|
||||||
- All data handling must comply with applicable privacy laws (e.g., GDPR, CCPA).
|
|
||||||
- Never log or store sensitive data insecurely.
|
|
||||||
- Review and document data flows for compliance annually.
|
|
||||||
|
|
||||||
## Database Migration & Change Management
|
|
||||||
|
|
||||||
- Use a dedicated, automated migration tool (e.g., Liquibase, Flyway) for all schema changes.
|
|
||||||
- Store all migration scripts under version control, alongside application code.
|
|
||||||
- All environments (dev, test, prod) must be migrated using the same process and scripts.
|
|
||||||
- Manual, ad-hoc schema changes are prohibited.
|
|
||||||
- All migrations must be documented with rationale and expected outcomes.
|
|
||||||
|
|
||||||
## Database Management & Documentation
|
|
||||||
|
|
||||||
- Maintain an up-to-date Entity Relationship Diagram (ERD).
|
|
||||||
- Use templates for documenting schema changes, migrations, and rationale.
|
|
||||||
- Document all reference data and non-obvious constraints.
|
|
||||||
- Maintain a changelog for all database changes.
|
|
||||||
- Review and update database documentation as part of the development workflow.
|
|
||||||
|
|
||||||
## Database Naming Conventions
|
|
||||||
|
|
||||||
- Use clear, consistent, and project-wide naming conventions for tables, columns, indexes, and constraints.
|
|
||||||
- Prefer snake_case for all identifiers.
|
|
||||||
- Prefix/suffix conventions must be documented (e.g., `tbl_` for tables, `_fk` for foreign keys).
|
|
||||||
- Avoid reserved words and ambiguous abbreviations.
|
|
||||||
- Enforce naming conventions in code review and automated linting where possible.
|
|
||||||
|
|
@ -1,82 +0,0 @@
|
||||||
# Core Coding Principles
|
|
||||||
|
|
||||||
> **Scope:** This document defines the core, universal, and project-agnostic engineering principles that apply to all development work. These are the fundamental rules of good software craftsmanship, independent of any specific project.
|
|
||||||
|
|
||||||
## Core Coding Principles
|
|
||||||
|
|
||||||
- [SF] **Simplicity First:** Always choose the simplest viable solution. Complex patterns or architectures require explicit justification.
|
|
||||||
- [RP] **Readability Priority:** Code must be immediately understandable by both humans and AI during future modifications.
|
|
||||||
- [DM] **Dependency Minimalism:** No new libraries or frameworks without explicit request or compelling justification.
|
|
||||||
- [ISA] **Industry Standards Adherence:** Follow established conventions for the relevant language and tech stack.
|
|
||||||
- [SD] **Strategic Documentation:** Comment only complex logic or critical functions. Avoid documenting the obvious.
|
|
||||||
- [TDT] **Test-Driven Thinking:** Design all code to be easily testable from inception.
|
|
||||||
|
|
||||||
## Dependency Management
|
|
||||||
|
|
||||||
- [DM-1] Review third-party dependencies for vulnerabilities at least quarterly.
|
|
||||||
- [DM-2] Prefer signed or verified packages.
|
|
||||||
- [DM-3] Remove unused or outdated dependencies promptly.
|
|
||||||
- [DM-4] Document dependency updates in the changelog.
|
|
||||||
|
|
||||||
## Coding workflow preferences
|
|
||||||
|
|
||||||
- [WF-FOCUS] Focus on the areas of code relevant to the task
|
|
||||||
- [WF-SCOPE] Do not touch code that is unrelated to the task
|
|
||||||
- [WF-TEST] Write thorough tests for all major functionality
|
|
||||||
- [WF-ARCH] Avoid making major changes to the patterns and architecture of how a feature works, after it has shown to work well, unless explicitly structured
|
|
||||||
- [WF-IMPACT] Always think about what other methods and areas of code might be affected by code changes
|
|
||||||
|
|
||||||
## Workflow Standards
|
|
||||||
|
|
||||||
- [AC] **Atomic Changes:** Make small, self-contained modifications to improve traceability and rollback capability.
|
|
||||||
- [CD] **Commit Discipline:** Recommend regular commits with semantic messages using 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
|
|
||||||
Adhere to the ConventionalCommit specification: <https://www.conventionalcommits.org/en/v1.0.0/#specification>
|
|
||||||
|
|
||||||
- [TR] **Transparent Reasoning:** When generating code, explicitly reference which global rules influenced decisions.
|
|
||||||
- [CWM] **Context Window Management:** Be mindful of AI context limitations. Suggest new sessions when necessary.
|
|
||||||
|
|
||||||
## Code Quality Guarantees
|
|
||||||
|
|
||||||
- [DRY] **DRY Principle:** No duplicate code. Reuse or extend existing functionality.
|
|
||||||
- [CA] **Clean Architecture:** Generate cleanly formatted, logically structured code with consistent patterns.
|
|
||||||
- [REH] **Robust Error Handling:** Integrate appropriate error handling for all edge cases and external interactions.
|
|
||||||
- [CSD] **Code Smell Detection:** Proactively identify and suggest refactoring for:
|
|
||||||
- Functions exceeding 30 lines
|
|
||||||
- Files exceeding 300 lines
|
|
||||||
- Nested conditionals beyond 2 levels
|
|
||||||
- Classes with more than 5 public methods
|
|
||||||
|
|
||||||
## Security & Performance Considerations
|
|
||||||
|
|
||||||
- [IV] **Input Validation:** All external data must be validated before processing.
|
|
||||||
- [RM] **Resource Management:** Close connections and free resources appropriately.
|
|
||||||
- [CMV] **Constants Over Magic Values:** No magic strings or numbers. Use named constants.
|
|
||||||
- [SFT] **Security-First Thinking:** Implement proper authentication, authorization, and data protection.
|
|
||||||
- [PA] **Performance Awareness:** Consider computational complexity and resource usage.
|
|
||||||
- [RL] Rate limit all API endpoints.
|
|
||||||
- [RLS] Use row-level security always (RLS).
|
|
||||||
- [CAP] Captcha on all auth routes/signup pages.
|
|
||||||
- [WAF] If using hosting solution like Vercel, enable attack challenge on their WAF.
|
|
||||||
- [SEC-1] **DO NOT** read or modify, without prior approval by user:
|
|
||||||
- .env files
|
|
||||||
- \*_/config/secrets._
|
|
||||||
- Any file containing API keys or credentials
|
|
||||||
|
|
||||||
## AI Communication Guidelines
|
|
||||||
|
|
||||||
- [RAT] **Rule Application Tracking:** When applying rules, tag with the abbreviation in brackets (e.g., [SF], [DRY]).
|
|
||||||
- [EDC] **Explanation Depth Control:** Scale explanation detail based on complexity, from brief to comprehensive.
|
|
||||||
- [AS] **Alternative Suggestions:** When relevant, offer alternative approaches with pros/cons.
|
|
||||||
- [KBT] **Knowledge Boundary Transparency:** Clearly communicate when a request exceeds AI capabilities or project context.
|
|
||||||
|
|
@ -1,35 +0,0 @@
|
||||||
# Project Scaffolding Rules
|
|
||||||
|
|
||||||
> **Scope:** This document defines the mandatory file and folder structure for the project. Adherence to this structure is required to ensure consistency and support automated tooling.
|
|
||||||
|
|
||||||
## Project structure
|
|
||||||
|
|
||||||
The project should include the following files and folders:
|
|
||||||
|
|
||||||
- a .clineignore file
|
|
||||||
- a .gitignore file primed for a regular project managed with CLINE in Microsoft VSCode
|
|
||||||
- a generic readme.md file
|
|
||||||
- a blank .gitattributes file
|
|
||||||
- a license file
|
|
||||||
|
|
||||||
- /.clinerules/rules folder to include all project specific rules for the CLINE extension
|
|
||||||
- /.clinerules/workflows folder to include all project specific workflows for the CLINE extension
|
|
||||||
- /.windsurf/rules/ folder to include all project specific rules for the Windsurf extension
|
|
||||||
- /.windsurf/workflows/ folder to include all project specific workflows for the Windsurf extension
|
|
||||||
|
|
||||||
- a docs/adr folder to include all project specific Architectural Decisions Records (ADRs)
|
|
||||||
- a docs/devJournal folder to include all project specific development journals
|
|
||||||
- a docs/roadmap folder to include all project roadmap and features description
|
|
||||||
- a docs/roadmap/features folder to include all project specific features and their technical, functional and non-functional requirements (Including UX-UI)
|
|
||||||
|
|
||||||
- an src/app folder to include the frontend components of the solution
|
|
||||||
- an src/api folder to include the backend components of the solution
|
|
||||||
- an src/utils folder to include the share utilities components of the solution
|
|
||||||
- an src/tests folder to include the tests components of the solution
|
|
||||||
- an src/tests/e2e folder to include the end-to-end tests components of the solution
|
|
||||||
- an src/tests/postman folder to include the postman tests for the API components of the solution
|
|
||||||
|
|
||||||
- a db folder to include the database components of the solution
|
|
||||||
- a db/liquibase folder to include the liquibase components of the solution
|
|
||||||
|
|
||||||
- a local-dev-setup folder to include the local development setup components of the solution
|
|
||||||
|
|
@ -1,99 +0,0 @@
|
||||||
_Scope: This document provides the definitive, consolidated set of rules based on the Twelve-Factor App methodology. These principles are mandatory for ensuring our applications are built as scalable, resilient, and maintainable cloud-native services._
|
|
||||||
|
|
||||||
# The Consolidated Twelve-Factor App Rules for an AI Agent
|
|
||||||
|
|
||||||
**I. Codebase**
|
|
||||||
|
|
||||||
- A single, version-controlled codebase (e.g., in Git) must represent one and only one application.
|
|
||||||
- All code you generate, manage, or refactor for a specific application must belong to this single codebase.
|
|
||||||
- Shared functionality across applications must be factored into versioned libraries and managed via a dependency manager.
|
|
||||||
- This single codebase is used to produce multiple deploys (e.g., development, staging, production).
|
|
||||||
|
|
||||||
**II. Dependencies**
|
|
||||||
|
|
||||||
- You must explicitly declare all application dependencies via a manifest file (e.g., `requirements.txt`, `package.json`, `pom.xml`).
|
|
||||||
- Never rely on the implicit existence of system-wide packages or tools. The application must run in an isolated environment where only explicitly declared dependencies are available.
|
|
||||||
|
|
||||||
**III. Config**
|
|
||||||
|
|
||||||
- A strict separation between code and configuration must be enforced.
|
|
||||||
- All configuration that varies between deploys (credentials, resource handles, hostnames) must be read from environment variables.
|
|
||||||
- Never hardcode environment-specific values in the source code you generate. The codebase must be runnable anywhere provided the correct environment variables are set.
|
|
||||||
|
|
||||||
**IV. Backing Services**
|
|
||||||
|
|
||||||
- All backing services (databases, message queues, caches, external APIs, etc.) must be treated as attached, swappable resources.
|
|
||||||
- Connect to all backing services via locators/credentials stored in the configuration (environment variables). The code must be agnostic to whether a service is local or third-party.
|
|
||||||
|
|
||||||
**V. Build, Release, Run**
|
|
||||||
|
|
||||||
- Maintain a strict, three-stage separation:
|
|
||||||
- **Build:** Converts the code repo into an executable bundle.
|
|
||||||
- **Release:** Combines the build with environment-specific config.
|
|
||||||
- **Run:** Executes the release in the target environment.
|
|
||||||
- Releases must be immutable and have unique IDs. Any change to code or config must create a new release. You must not generate code that attempts to modify itself at runtime.
|
|
||||||
|
|
||||||
**VI. Processes**
|
|
||||||
|
|
||||||
- Design the application to execute as one or more stateless, share-nothing processes.
|
|
||||||
- Any data that needs to persist must be stored in a stateful backing service (e.g., a database). Never assume that local memory or disk state is available across requests or between process restarts.
|
|
||||||
|
|
||||||
**VII. Port Binding**
|
|
||||||
|
|
||||||
- The application must be self-contained and export its services (e.g., HTTP) by binding to a port specified via configuration. Do not rely on runtime injection of a webserver (e.g., as a module in Apache).
|
|
||||||
|
|
||||||
**VIII. Concurrency**
|
|
||||||
|
|
||||||
- Design the application to scale out horizontally by adding more concurrent processes.
|
|
||||||
- Assign different workload types to different process types (e.g., `web`, `worker`).
|
|
||||||
- Rely on a process manager (e.g., systemd, Foreman, Kubernetes) for process lifecycle management, logging, and crash recovery.
|
|
||||||
|
|
||||||
**IX. Disposability**
|
|
||||||
|
|
||||||
- Processes must be disposable, meaning they can be started or stopped at a moment's notice.
|
|
||||||
- Strive for minimal startup time to facilitate fast elastic scaling and deployments.
|
|
||||||
- Ensure graceful shutdown on `SIGTERM`, finishing any in-progress work before exiting.
|
|
||||||
- Design processes to be robust against sudden death (crash-only design).
|
|
||||||
|
|
||||||
**X. Dev/Prod Parity**
|
|
||||||
|
|
||||||
- Keep development, staging, and production environments as similar as possible.
|
|
||||||
- This applies to the type and version of the programming language, system tooling, and all backing services.
|
|
||||||
|
|
||||||
**XI. Logs**
|
|
||||||
|
|
||||||
- Treat logs as event streams. Never write to or manage log files directly from the application.
|
|
||||||
- Each process must write its event stream, unbuffered, to standard output (`stdout`).
|
|
||||||
- The execution environment is responsible for collecting, aggregating, and routing these log streams for storage and analysis.
|
|
||||||
|
|
||||||
**XII. Admin Processes**
|
|
||||||
|
|
||||||
- Run administrative and management tasks (e.g., database migrations, one-off scripts) as one-off processes in an environment identical to the main application's long-running processes.
|
|
||||||
- Admin scripts must be shipped with the application code and use the same dependency and configuration management to avoid synchronization issues.
|
|
||||||
|
|
||||||
# Additional Consolidated Project Rules
|
|
||||||
|
|
||||||
**Onboarding & Knowledge Transfer**
|
|
||||||
|
|
||||||
- Maintain up-to-date onboarding guides and “How To” docs for new contributors and AI agents.
|
|
||||||
- All major workflows must have step-by-step documentation.
|
|
||||||
- Encourage new team members to suggest improvements to onboarding materials.
|
|
||||||
|
|
||||||
**AI/Agent Safeguards**
|
|
||||||
|
|
||||||
- All AI-generated code must be reviewed by a human before deployment to production.
|
|
||||||
- Escalate ambiguous or risky decisions to a human for approval.
|
|
||||||
- Log all significant AI-suggested changes for auditability.
|
|
||||||
- Never overwrite an `.env` file without first asking and confirming.
|
|
||||||
|
|
||||||
**Continuous Improvement**
|
|
||||||
|
|
||||||
- Hold regular retrospectives to review rules, workflows, and documentation.
|
|
||||||
- Encourage all contributors to provide feedback and suggest improvements.
|
|
||||||
- Update rules and workflows based on lessons learned.
|
|
||||||
|
|
||||||
**Environmental Sustainability**
|
|
||||||
|
|
||||||
- Optimize compute resources and minimize waste in infrastructure choices.
|
|
||||||
- Prefer energy-efficient solutions where practical.
|
|
||||||
- Consider environmental impact in all major technical decisions.
|
|
||||||
|
|
@ -1,35 +0,0 @@
|
||||||
_Scope: This document outlines the specific patterns and strategies for implementing our Microservice-Oriented Architecture, based on Chris Richardson's "Microservices Patterns". It builds upon the foundational principles in `04-TwelveFactorApp.md` and provides a detailed guide for service design, decomposition, communication, and data management._
|
|
||||||
|
|
||||||
Observe the principles set by the book "Microservices Patterns" by Chris Richardson.
|
|
||||||
|
|
||||||
### Microservice Patterns & Principles (with Trigram Codes)
|
|
||||||
|
|
||||||
- [MON] **Monolithic Architecture:** Structures an application as a single, unified deployable unit. Good for simple applications, but becomes "monolithic hell" as complexity grows.
|
|
||||||
- [MSA] **Microservice Architecture:** Structures an application as a collection of small, autonomous, and loosely coupled services. This is the core pattern the rest of the book builds upon.
|
|
||||||
- [DBC] **Decompose by Business Capability:** Define services based on what a business _does_ (e.g., Order Management, Inventory Management) to create stable service boundaries.
|
|
||||||
- [DSD] **Decompose by Subdomain:** Use Domain-Driven Design (DDD) to define services around specific problem subdomains, aligning service boundaries with the business domain model.
|
|
||||||
- [RPI] **Remote Procedure Invocation:** A client invokes a service using a synchronous, request/response protocol like REST or gRPC. Simple and familiar but creates tight coupling and can reduce availability.
|
|
||||||
- [MSG] **Messaging:** Services communicate asynchronously by exchanging messages via a message broker. This promotes loose coupling and improves resilience.
|
|
||||||
- [CBR] **Circuit Breaker:** Prevents a network or service failure from cascading. After a number of consecutive failures, the breaker trips, and further calls fail immediately.
|
|
||||||
- [SDC] **Service Discovery:** Patterns for how a client service can find the network location of a service instance in a dynamic cloud environment (self/3rd party registration, client/server-side discovery).
|
|
||||||
- [DPS] **Database per Service:** Each microservice owns its own data and is solely responsible for it. Fundamental to loose coupling; requires new transaction management strategies.
|
|
||||||
- [SAG] **Saga:** Master pattern for managing data consistency across services without distributed transactions. Sequence of local transactions, each triggering the next via events/messages, with compensating transactions on failure.
|
|
||||||
- [OUT] **Transactional Outbox / Polling Publisher / Transaction Log Tailing:** Reliably publish messages/events as part of a local database transaction, ensuring no messages are lost if a service crashes after updating its database but before sending the message.
|
|
||||||
- [DOM] **Domain Model:** Classic object-oriented approach with classes containing both state and behaviour. Preferred for complex logic.
|
|
||||||
- [TSF] **Transaction Script:** Procedural approach where a single procedure handles a single request. Simpler, but unmanageable for complex logic.
|
|
||||||
- [AGG] **Aggregate:** A cluster of related domain objects treated as a single unit, with a root entity. Transactions only ever create or update a single aggregate.
|
|
||||||
- [DME] **Domain Events:** Aggregates publish events when their state changes. Foundation for event-driven architectures, sagas, and data replication.
|
|
||||||
- [EVS] **Event Sourcing:** Store the sequence of state-changing events rather than the current state. The current state is derived by replaying events, providing a reliable audit log and simplifying event publishing.
|
|
||||||
- [APC] **API Composition:** A client (or API Gateway) retrieves data from multiple services and joins it in memory. Simple for basic queries, inefficient for complex joins across large datasets.
|
|
||||||
- [CQR] **Command Query Responsibility Segregation (CQRS):** Maintain one or more denormalised, read-optimised "view" databases kept up-to-date by subscribing to events from the services that own the data. Separates the command-side (write) from the query-side (read) model.
|
|
||||||
- [APG] **API Gateway:** A single entry point for all external clients. Routes requests to backend services, can perform API composition, and handles cross-cutting concerns like authentication.
|
|
||||||
- [BFF] **Backends for Frontends:** A variation of the API Gateway pattern where you have a separate, tailored API gateway for each specific client (e.g., mobile app, web app).
|
|
||||||
- [CDC] **Consumer-Driven Contract Test:** A test written by the _consumer_ of a service to verify that the _provider_ meets its expectations, ensuring correct communication without slow, brittle end-to-end tests.
|
|
||||||
- [SCT] **Service Component Test:** Acceptance test for a single service in isolation, using stubs for external dependencies.
|
|
||||||
- [SVC] **Service as a Container:** Package a service as a container image (e.g., Docker) to encapsulate its technology stack.
|
|
||||||
- [SRL] **Serverless Deployment:** Deploy services using a platform like AWS Lambda that abstracts away the underlying infrastructure.
|
|
||||||
- [MSC] **Microservice Chassis:** A framework (e.g., Spring Boot + Spring Cloud) that handles cross-cutting concerns such as config, health checks, metrics, and distributed tracing.
|
|
||||||
- [SMH] **Service Mesh:** Infrastructure layer (e.g., Istio, Linkerd) that handles inter-service communication concerns like circuit breakers, distributed tracing, and load balancing outside of service code.
|
|
||||||
- [STR] **Strangler Application:** Strategy for migrating a monolith. Incrementally build new microservices around the monolith, gradually replacing it and avoiding a "big bang" rewrite.
|
|
||||||
|
|
||||||
More at <https://microservices.io/patterns/>
|
|
||||||
|
|
@ -1,60 +0,0 @@
|
||||||
---
|
|
||||||
description: The definitive workflow for safely updating API specifications and generating Postman tests to ensure 100% consistency and prevent data loss.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Workflow: API Spec & Test Generation
|
|
||||||
|
|
||||||
This workflow establishes `openapi.yaml` as the single source of truth for all API development. The Postman collection is **always generated** from this file. **NEVER edit the Postman JSON file directly.** This prevents inconsistencies and the kind of file corruption we have experienced.
|
|
||||||
|
|
||||||
## Guiding Principles
|
|
||||||
|
|
||||||
- **OpenAPI is the ONLY Source of Truth:** All API changes begin and end with `docs/api/openapi.yaml`.
|
|
||||||
- **Postman is a GENERATED ARTIFACT:** The collection file is treated as build output. It is never edited by hand.
|
|
||||||
- **Validate Before Generating:** Always validate the OpenAPI spec _before_ attempting to generate the Postman collection.
|
|
||||||
|
|
||||||
## Steps
|
|
||||||
|
|
||||||
### 1. Update the OpenAPI Specification (`docs/api/openapi.yaml`)
|
|
||||||
|
|
||||||
- **Identify API Changes:** Review the Groovy source code (e.g., `src/com/umig/api/v2/*.groovy`) to identify any new, modified, or removed endpoints.
|
|
||||||
- **Edit the Spec:** Carefully add, modify, or remove the corresponding endpoint definitions under `paths` and schemas under `components/schemas`.
|
|
||||||
- **Best Practice:** Use `allOf` to extend existing schemas non-destructively (e.g., adding audit fields to a base `User` schema).
|
|
||||||
- **Use an IDE with OpenAPI support** to get real-time linting and validation.
|
|
||||||
|
|
||||||
### 2. Validate the OpenAPI Specification
|
|
||||||
|
|
||||||
- **CRITICAL:** Before proceeding, validate your `openapi.yaml` file.
|
|
||||||
- Use your IDE's built-in OpenAPI preview or a dedicated linter.
|
|
||||||
- **DO NOT proceed if the file has errors.** Fix them first. This is the most important step to prevent downstream issues.
|
|
||||||
|
|
||||||
### 3. Generate the Postman Collection
|
|
||||||
|
|
||||||
- **Navigate to the correct directory** in your terminal. The command must be run from here:
|
|
||||||
```bash
|
|
||||||
cd docs/api/postman
|
|
||||||
```
|
|
||||||
- **Run the generation command:**
|
|
||||||
```bash
|
|
||||||
// turbo
|
|
||||||
npx openapi-to-postmanv2 -s ../openapi.yaml -o ./UMIG_API_V2_Collection.postman_collection.json -p -O folderStrategy=Tags
|
|
||||||
```
|
|
||||||
- **Note on `npx`:** The `npx` command runs the `openapi-to-postmanv2` package without requiring a global installation. If you see `command not found`, ensure you are using `npx`.
|
|
||||||
|
|
||||||
### 4. Verify the Changes
|
|
||||||
|
|
||||||
- **Review the Diff:** Use `git diff` to review the changes to `UMIG_API_V2_Collection.postman_collection.json`. Confirm that the new endpoint has been added and that no unexpected changes have occurred.
|
|
||||||
- **Test in Postman:** (Optional but recommended) Import the newly generated collection into Postman and run a few requests against a local dev environment to ensure correctness.
|
|
||||||
|
|
||||||
### 5. Document and Commit
|
|
||||||
|
|
||||||
- **Commit all changes:** Add the modified `openapi.yaml` and the generated `UMIG_API_V2_Collection.postman_collection.json` to your commit.
|
|
||||||
- **Update Changelog:** Add an entry to `CHANGELOG.md` detailing the API changes.
|
|
||||||
- **Update Dev Journal:** Create a developer journal entry summarizing the work done.scribe any removals or replacements and the rationale.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Key Principles:**
|
|
||||||
|
|
||||||
- Never erase or overwrite existing tests/specs unless required by an API change.
|
|
||||||
- Every endpoint in the API must be present and tested in both Postman and OpenAPI.
|
|
||||||
- Consistency, completeness, and traceability are paramount.
|
|
||||||
|
|
@ -1,44 +0,0 @@
|
||||||
---
|
|
||||||
description: The standard workflow for creating or modifying Groovy REST API endpoints in this project.
|
|
||||||
---
|
|
||||||
|
|
||||||
This workflow ensures all API development adheres to the project's established, stable patterns to prevent bugs and maintain consistency.
|
|
||||||
|
|
||||||
## Key Reference Documents
|
|
||||||
|
|
||||||
**PRIMARY REFERENCE**: `/docs/solution-architecture.md` — Comprehensive solution architecture and API design standards
|
|
||||||
|
|
||||||
**SUPPORTING REFERENCES**:
|
|
||||||
|
|
||||||
- Current ADRs in `/docs/adr/` (skip `/docs/adr/archive/` - consolidated in solution-architecture.md)
|
|
||||||
- Working examples: `src/com/umig/api/v2/TeamsApi.groovy`
|
|
||||||
|
|
||||||
1. **Analyze the Existing Pattern**:
|
|
||||||
|
|
||||||
- Before writing any code, thoroughly review a working, stable API file like `src/com/umig/api/v2/TeamsApi.groovy`.
|
|
||||||
- Pay close attention to the structure: separate endpoint definitions for each HTTP method, simple `try-catch` blocks for error handling, and standard `javax.ws.rs.core.Response` objects.
|
|
||||||
|
|
||||||
2. **Replicate the Pattern**:
|
|
||||||
|
|
||||||
- Create a new endpoint definition for each HTTP method (`GET`, `POST`, `PUT`, `DELETE`).
|
|
||||||
- Do NOT use a central dispatcher, custom exception classes, or complex helper methods for error handling. Keep all logic within the endpoint method.
|
|
||||||
|
|
||||||
3. **Implement Business Logic**:
|
|
||||||
|
|
||||||
- Write the core business logic inside a `try` block.
|
|
||||||
- Call the appropriate `UserRepository` or `TeamRepository` methods.
|
|
||||||
|
|
||||||
4. **Handle Success Cases**:
|
|
||||||
|
|
||||||
- For `GET`, `POST`, and `PUT`, return a `Response.ok()` or `Response.status(Response.Status.CREATED)` with a `JsonBuilder` payload.
|
|
||||||
- **CRITICAL**: For a successful `DELETE`, always return `Response.noContent().build()`. Do NOT attempt to return a body.
|
|
||||||
|
|
||||||
5. **Handle Error Cases**:
|
|
||||||
|
|
||||||
- Use `catch (SQLException e)` to handle specific database errors (e.g., foreign key violations `23503`, unique constraint violations `23505`).
|
|
||||||
- Use a generic `catch (Exception e)` for all other unexpected errors.
|
|
||||||
- In all `catch` blocks, log the error using `log.error()` or `log.warn()` and return an appropriate `Response.status(...)` with a simple JSON error message.
|
|
||||||
|
|
||||||
6. **Validate Inputs**:
|
|
||||||
- Strictly validate all incoming data (path parameters, request bodies) at the beginning of the endpoint method.
|
|
||||||
- Return a `400 Bad Request` for any invalid input.
|
|
||||||
|
|
@ -1,162 +0,0 @@
|
||||||
---
|
|
||||||
description: This is the basic workflow to gather last changes, prepare a relevant commit message and commit the staged code changes
|
|
||||||
---
|
|
||||||
|
|
||||||
This workflow guides the creation of a high-quality, comprehensive commit message that accurately reflects all staged changes, adhering strictly to the Conventional Commits 1.0 standard.
|
|
||||||
|
|
||||||
**1. Comprehensive Evidence Gathering (MANDATORY - Prevent tunnel vision):**
|
|
||||||
|
|
||||||
**1.1. Staged Changes Analysis:**
|
|
||||||
|
|
||||||
- **Detailed Diff Review:** Run `git diff --staged --stat` to get both summary and detailed view of all staged changes.
|
|
||||||
- **File-by-File Analysis:** Run `git diff --staged --name-status` to see the operation type (Modified, Added, Deleted) for each file.
|
|
||||||
- **Functional Area Classification:** Group staged files by functional area:
|
|
||||||
- **API Changes:** `src/groovy/umig/api/`, `src/groovy/umig/repository/`
|
|
||||||
- **UI Changes:** `src/groovy/umig/web/js/`, `src/groovy/umig/web/css/`, `src/groovy/umig/macros/`
|
|
||||||
- **Documentation:** `docs/`, `README.md`, `CHANGELOG.md`, `*.md` files
|
|
||||||
- **Tests:** `src/groovy/umig/tests/`, `local-dev-setup/__tests__/`
|
|
||||||
- **Configuration:** `local-dev-setup/liquibase/`, `*.json`, `*.yml`, `*.properties`
|
|
||||||
- **Database:** Migration files, schema changes
|
|
||||||
- **Change Type Analysis:** For each file, determine the type of change:
|
|
||||||
- New functionality added
|
|
||||||
- Existing functionality modified
|
|
||||||
- Bug fixes
|
|
||||||
- Refactoring or code cleanup
|
|
||||||
- Documentation updates
|
|
||||||
- Test additions or modifications
|
|
||||||
|
|
||||||
**1.2. Unstaged and Untracked Files Review:**
|
|
||||||
|
|
||||||
- **Related Files Check:** Run `git status --porcelain` to identify any untracked or unstaged files that might be related.
|
|
||||||
- **Completeness Verification:** Ensure all related changes are staged or deliberately excluded.
|
|
||||||
- **User Prompt:** If potentially related files are unstaged, prompt the user about inclusion.
|
|
||||||
|
|
||||||
**1.3. Work Stream Identification:**
|
|
||||||
|
|
||||||
- **Primary Work Stream:** Identify the main type of work being committed.
|
|
||||||
- **Secondary Work Streams:** Identify supporting changes (e.g., tests, documentation, configuration).
|
|
||||||
- **Cross-Functional Impact:** Note changes that span multiple functional areas.
|
|
||||||
- **Architecture Impact:** Identify any architectural or pattern changes.
|
|
||||||
|
|
||||||
**2. Multi-Context Rationale Analysis (MANDATORY - Address tunnel vision):**
|
|
||||||
|
|
||||||
**2.1. Session Context Review:**
|
|
||||||
|
|
||||||
- **Conversation Timeline:** Review the entire session conversation to understand the evolution of the work.
|
|
||||||
- **Initial Problem:** Identify the original problem or task that initiated the changes.
|
|
||||||
- **Decision Points:** Note key decisions made during the session that influenced the implementation.
|
|
||||||
- **Scope Evolution:** If the work expanded beyond the initial scope, understand how and why.
|
|
||||||
|
|
||||||
**2.2. Development Context:**
|
|
||||||
|
|
||||||
- **Dev Journal Review:** If a development journal entry was created during the session, review it for high-level narrative.
|
|
||||||
- **Related Work:** Check if this commit is part of a larger feature or bug fix spanning multiple commits.
|
|
||||||
- **Previous Commits:** Review recent commits to understand the progression of work.
|
|
||||||
|
|
||||||
**2.3. Business and Technical Context:**
|
|
||||||
|
|
||||||
- **Business Impact:** Understand what user-facing or system benefits this change provides.
|
|
||||||
- **Technical Motivation:** Identify the technical reasons for the changes (performance, maintainability, new features).
|
|
||||||
- **Problem-Solution Mapping:** For each work stream, clearly understand:
|
|
||||||
- What problem was being solved
|
|
||||||
- Why this particular solution was chosen
|
|
||||||
- What alternatives were considered
|
|
||||||
- What the outcome achieves
|
|
||||||
|
|
||||||
**2.4. Change Dependencies:**
|
|
||||||
|
|
||||||
- **Cross-Stream Dependencies:** How different work streams in this commit depend on each other.
|
|
||||||
- **External Dependencies:** Any external factors that influenced the changes.
|
|
||||||
- **Future Implications:** What this change enables or constrains for future development.
|
|
||||||
|
|
||||||
**3. Multi-Stream Commit Message Synthesis (MANDATORY - Address tunnel vision):**
|
|
||||||
|
|
||||||
The goal is to create a message that comprehensively explains all changes and their context for future developers.
|
|
||||||
|
|
||||||
**3.1. Type and Scope Selection:**
|
|
||||||
|
|
||||||
- **Primary Type:** Choose the most significant type from the allowed list (`feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`).
|
|
||||||
- **Multi-Stream Consideration:** If multiple significant work streams exist, choose the type that best represents the overall impact.
|
|
||||||
- **Scope Selection:** Identify the primary part of the codebase affected:
|
|
||||||
- **Specific Components:** `api`, `ui`, `db`, `auth`, `docs`, `tests`
|
|
||||||
- **Functional Areas:** `admin`, `migration`, `iteration`, `planning`
|
|
||||||
- **System-Wide:** Use broader scopes for cross-cutting changes
|
|
||||||
|
|
||||||
**3.2. Subject Line Construction:**
|
|
||||||
|
|
||||||
- **Imperative Mood:** Write a concise summary (under 50 characters) in imperative mood.
|
|
||||||
- **Multi-Stream Subject:** If multiple work streams are significant, write a subject that captures the overall achievement.
|
|
||||||
- **Specific vs General:** Balance specificity with comprehensiveness.
|
|
||||||
|
|
||||||
**3.3. Body Structure (Enhanced for Multi-Stream):**
|
|
||||||
|
|
||||||
- **Primary Change Description:** Start with the main change and its motivation.
|
|
||||||
- **Work Stream Breakdown:** For each significant work stream:
|
|
||||||
- **What Changed:** Specific files, components, or functionality
|
|
||||||
- **Why Changed:** Problem being solved or improvement being made
|
|
||||||
- **How Changed:** Technical approach or implementation details
|
|
||||||
- **Impact:** What this enables or improves
|
|
||||||
- **Cross-Stream Integration:** How different work streams work together.
|
|
||||||
- **Technical Decisions:** Explain significant design choices and why alternatives were rejected.
|
|
||||||
- **Context:** Provide enough context for future developers to understand the change.
|
|
||||||
|
|
||||||
**3.4. Footer Considerations:**
|
|
||||||
|
|
||||||
- **Breaking Changes:** Use `BREAKING CHANGE:` for any breaking changes with migration notes.
|
|
||||||
- **Issue References:** Reference related issues (e.g., `Closes #123`, `Relates to #456`).
|
|
||||||
- **Co-authorship:** Add `Co-Authored-By:` for pair programming or AI assistance.
|
|
||||||
|
|
||||||
**3.5. Message Assembly:**
|
|
||||||
|
|
||||||
- **Single Coherent Story:** Weave multiple work streams into a single, coherent narrative.
|
|
||||||
- **Logical Flow:** Organize information in a logical sequence that makes sense to readers.
|
|
||||||
- **Appropriate Detail:** Include enough detail to understand the change without overwhelming.
|
|
||||||
|
|
||||||
**4. Anti-Tunnel Vision Verification (MANDATORY - Use before finalizing):**
|
|
||||||
|
|
||||||
Before presenting the commit message, verify you have addressed ALL of the following:
|
|
||||||
|
|
||||||
**Content Coverage:**
|
|
||||||
|
|
||||||
- [ ] All staged files are explained in the commit message
|
|
||||||
- [ ] All functional areas touched are documented
|
|
||||||
- [ ] All work streams are identified and described
|
|
||||||
- [ ] Change types (feat/fix/docs/etc.) are accurately represented
|
|
||||||
- [ ] Cross-functional impacts are noted
|
|
||||||
|
|
||||||
**Technical Completeness:**
|
|
||||||
|
|
||||||
- [ ] Code changes include rationale for the approach taken
|
|
||||||
- [ ] API changes are summarized with impact
|
|
||||||
- [ ] UI changes are explained with user impact
|
|
||||||
- [ ] Database changes include migration details
|
|
||||||
- [ ] Configuration changes are noted
|
|
||||||
- [ ] Test changes are explained
|
|
||||||
|
|
||||||
**Context and Rationale:**
|
|
||||||
|
|
||||||
- [ ] Original problem or motivation is clearly stated
|
|
||||||
- [ ] Solution approach is justified
|
|
||||||
- [ ] Technical decisions are explained
|
|
||||||
- [ ] Alternative approaches are noted (if relevant)
|
|
||||||
- [ ] Future implications are considered
|
|
||||||
|
|
||||||
**Message Quality:**
|
|
||||||
|
|
||||||
- [ ] Subject line is under 50 characters and imperative mood
|
|
||||||
- [ ] Body explains "what" and "why" for each work stream
|
|
||||||
- [ ] Information is organized in logical flow
|
|
||||||
- [ ] Appropriate level of detail for future developers
|
|
||||||
- [ ] Conventional Commits format is followed
|
|
||||||
|
|
||||||
**Completeness Verification:**
|
|
||||||
|
|
||||||
- [ ] All evidence from steps 1-2 is reflected in the message
|
|
||||||
- [ ] No significant work is missing from the description
|
|
||||||
- [ ] Multi-stream nature is properly represented
|
|
||||||
- [ ] Session context is appropriately captured
|
|
||||||
|
|
||||||
**5. Await Confirmation and Commit:**
|
|
||||||
|
|
||||||
- Present the generated commit message to the user for review.
|
|
||||||
- After receiving confirmation, execute the `git commit` command.
|
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue