feat: transform QA agent into Test Architect with advanced quality capabilities
- Add 6 specialized quality assessment commands - Implement risk-based testing with scoring - Create quality gate system with deterministic decisions - Add comprehensive test design and NFR validation - Update documentation with stage-based workflow integration
This commit is contained in:
@@ -1,9 +1,8 @@
|
||||
## [4.36.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.36.1...v4.36.2) (2025-08-10)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* align installer dependencies with root package versions for ESM compatibility ([#420](https://github.com/bmadcode/BMAD-METHOD/issues/420)) ([3f6b674](https://github.com/bmadcode/BMAD-METHOD/commit/3f6b67443d61ae6add98656374bed27da4704644))
|
||||
- align installer dependencies with root package versions for ESM compatibility ([#420](https://github.com/bmadcode/BMAD-METHOD/issues/420)) ([3f6b674](https://github.com/bmadcode/BMAD-METHOD/commit/3f6b67443d61ae6add98656374bed27da4704644))
|
||||
|
||||
## [4.36.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.36.0...v4.36.1) (2025-08-09)
|
||||
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
# architect
|
||||
|
||||
|
||||
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
|
||||
|
||||
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
# BMad Master
|
||||
|
||||
|
||||
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
|
||||
|
||||
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
# BMad Web Orchestrator
|
||||
|
||||
|
||||
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
|
||||
|
||||
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
|
||||
|
||||
@@ -38,7 +38,6 @@ agent:
|
||||
whenToUse: "Use for code implementation, debugging, refactoring, and development best practices"
|
||||
customization:
|
||||
|
||||
|
||||
persona:
|
||||
role: Expert Senior Software Engineer & Implementation Specialist
|
||||
style: Extremely concise, pragmatic, detail-oriented, solution-focused
|
||||
|
||||
@@ -403,33 +403,28 @@ Ask the user if they want to work through the checklist:
|
||||
Now that you've completed the checklist, generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall architecture readiness (High/Medium/Low)
|
||||
- Critical risks identified
|
||||
- Key strengths of the architecture
|
||||
- Project type (Full-stack/Frontend/Backend) and sections evaluated
|
||||
|
||||
2. Section Analysis
|
||||
|
||||
- Pass rate for each major section (percentage of items passed)
|
||||
- Most concerning failures or gaps
|
||||
- Sections requiring immediate attention
|
||||
- Note any sections skipped due to project type
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations for each
|
||||
- Timeline impact of addressing issues
|
||||
|
||||
4. Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Should-fix items for better quality
|
||||
- Nice-to-have improvements
|
||||
|
||||
5. AI Implementation Readiness
|
||||
|
||||
- Specific concerns for AI agent implementation
|
||||
- Areas needing additional clarification
|
||||
- Complexity hotspots to address
|
||||
|
||||
@@ -304,7 +304,6 @@ Ask the user if they want to work through the checklist:
|
||||
Create a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall PRD completeness (percentage)
|
||||
- MVP scope appropriateness (Too Large/Just Right/Too Small)
|
||||
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
|
||||
@@ -312,26 +311,22 @@ Create a comprehensive validation report that includes:
|
||||
|
||||
2. Category Analysis Table
|
||||
Fill in the actual table with:
|
||||
|
||||
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
|
||||
- Critical Issues: Specific problems that block progress
|
||||
|
||||
3. Top Issues by Priority
|
||||
|
||||
- BLOCKERS: Must fix before architect can proceed
|
||||
- HIGH: Should fix for quality
|
||||
- MEDIUM: Would improve clarity
|
||||
- LOW: Nice to have
|
||||
|
||||
4. MVP Scope Assessment
|
||||
|
||||
- Features that might be cut for true MVP
|
||||
- Missing features that are essential
|
||||
- Complexity concerns
|
||||
- Timeline realism
|
||||
|
||||
5. Technical Readiness
|
||||
|
||||
- Clarity of technical constraints
|
||||
- Identified technical risks
|
||||
- Areas needing architect investigation
|
||||
|
||||
@@ -8,12 +8,10 @@ PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
@@ -347,7 +345,6 @@ Ask the user if they want to work through the checklist:
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
@@ -357,42 +354,36 @@ Generate a comprehensive validation report that adapts to project type:
|
||||
2. Project-Specific Analysis
|
||||
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
|
||||
@@ -25,14 +25,12 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
1. **Requirements Met:**
|
||||
|
||||
[[LLM: Be specific - list each requirement and whether it's complete]]
|
||||
|
||||
- [ ] All functional requirements specified in the story are implemented.
|
||||
- [ ] All acceptance criteria defined in the story are met.
|
||||
|
||||
2. **Coding Standards & Project Structure:**
|
||||
|
||||
[[LLM: Code quality matters for maintainability. Check each item carefully]]
|
||||
|
||||
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
|
||||
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
|
||||
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
|
||||
@@ -44,7 +42,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
3. **Testing:**
|
||||
|
||||
[[LLM: Testing proves your code works. Be honest about test coverage]]
|
||||
|
||||
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
||||
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
||||
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
|
||||
@@ -53,14 +50,12 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
4. **Functionality & Verification:**
|
||||
|
||||
[[LLM: Did you actually run and test your code? Be specific about what you tested]]
|
||||
|
||||
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
|
||||
- [ ] Edge cases and potential error conditions considered and handled gracefully.
|
||||
|
||||
5. **Story Administration:**
|
||||
|
||||
[[LLM: Documentation helps the next developer. What should they know?]]
|
||||
|
||||
- [ ] 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.
|
||||
- [ ] 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.
|
||||
@@ -68,7 +63,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
6. **Dependencies, Build & Configuration:**
|
||||
|
||||
[[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
|
||||
|
||||
- [ ] Project builds successfully without errors.
|
||||
- [ ] Project linting passes
|
||||
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
|
||||
@@ -79,7 +73,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
7. **Documentation (If Applicable):**
|
||||
|
||||
[[LLM: Good documentation prevents future confusion. What needs explaining?]]
|
||||
|
||||
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
|
||||
- [ ] User-facing documentation updated, if changes impact users.
|
||||
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
|
||||
|
||||
@@ -117,19 +117,16 @@ Note: We don't need every file listed - just the important ones.]]
|
||||
Generate a concise validation report:
|
||||
|
||||
1. Quick Summary
|
||||
|
||||
- Story readiness: READY / NEEDS REVISION / BLOCKED
|
||||
- Clarity score (1-10)
|
||||
- Major gaps identified
|
||||
|
||||
2. Fill in the validation table with:
|
||||
|
||||
- PASS: Requirements clearly met
|
||||
- PARTIAL: Some gaps but workable
|
||||
- FAIL: Critical information missing
|
||||
|
||||
3. Specific Issues (if any)
|
||||
|
||||
- List concrete problems to fix
|
||||
- Suggest specific improvements
|
||||
- Identify any blocking dependencies
|
||||
|
||||
@@ -651,8 +651,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
|
||||
|
||||
```markdown
|
||||
## Goals and Background Context
|
||||
|
||||
## Requirements
|
||||
|
||||
## User Interface Design Goals
|
||||
|
||||
## Success Metrics
|
||||
```
|
||||
|
||||
|
||||
@@ -3,16 +3,19 @@
|
||||
## Core Reflective Methods
|
||||
|
||||
**Expand or Contract for Audience**
|
||||
|
||||
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
|
||||
- Identify specific target audience if relevant
|
||||
- Tailor content complexity and depth accordingly
|
||||
|
||||
**Explain Reasoning (CoT Step-by-Step)**
|
||||
|
||||
- Walk through the step-by-step thinking process
|
||||
- Reveal underlying assumptions and decision points
|
||||
- Show how conclusions were reached from current role's perspective
|
||||
|
||||
**Critique and Refine**
|
||||
|
||||
- Review output for flaws, inconsistencies, or improvement areas
|
||||
- Identify specific weaknesses from role's expertise
|
||||
- Suggest refined version reflecting domain knowledge
|
||||
@@ -20,12 +23,14 @@
|
||||
## Structural Analysis Methods
|
||||
|
||||
**Analyze Logical Flow and Dependencies**
|
||||
|
||||
- Examine content structure for logical progression
|
||||
- Check internal consistency and coherence
|
||||
- Identify and validate dependencies between elements
|
||||
- Confirm effective ordering and sequencing
|
||||
|
||||
**Assess Alignment with Overall Goals**
|
||||
|
||||
- Evaluate content contribution to stated objectives
|
||||
- Identify any misalignments or gaps
|
||||
- Interpret alignment from specific role's perspective
|
||||
@@ -34,12 +39,14 @@
|
||||
## Risk and Challenge Methods
|
||||
|
||||
**Identify Potential Risks and Unforeseen Issues**
|
||||
|
||||
- Brainstorm potential risks from role's expertise
|
||||
- Identify overlooked edge cases or scenarios
|
||||
- Anticipate unintended consequences
|
||||
- Highlight implementation challenges
|
||||
|
||||
**Challenge from Critical Perspective**
|
||||
|
||||
- Adopt critical stance on current content
|
||||
- Play devil's advocate from specified viewpoint
|
||||
- Argue against proposal highlighting weaknesses
|
||||
@@ -48,12 +55,14 @@
|
||||
## Creative Exploration Methods
|
||||
|
||||
**Tree of Thoughts Deep Dive**
|
||||
|
||||
- Break problem into discrete "thoughts" or intermediate steps
|
||||
- Explore multiple reasoning paths simultaneously
|
||||
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
|
||||
- Apply search algorithms (BFS/DFS) to find optimal solution paths
|
||||
|
||||
**Hindsight is 20/20: The 'If Only...' Reflection**
|
||||
|
||||
- Imagine retrospective scenario based on current content
|
||||
- Identify the one "if only we had known/done X..." insight
|
||||
- Describe imagined consequences humorously or dramatically
|
||||
@@ -62,6 +71,7 @@
|
||||
## Multi-Persona Collaboration Methods
|
||||
|
||||
**Agile Team Perspective Shift**
|
||||
|
||||
- Rotate through different Scrum team member viewpoints
|
||||
- Product Owner: Focus on user value and business impact
|
||||
- Scrum Master: Examine process flow and team dynamics
|
||||
@@ -69,12 +79,14 @@
|
||||
- QA: Identify testing scenarios and quality concerns
|
||||
|
||||
**Stakeholder Round Table**
|
||||
|
||||
- Convene virtual meeting with multiple personas
|
||||
- Each persona contributes unique perspective on content
|
||||
- Identify conflicts and synergies between viewpoints
|
||||
- Synthesize insights into actionable recommendations
|
||||
|
||||
**Meta-Prompting Analysis**
|
||||
|
||||
- Step back to analyze the structure and logic of current approach
|
||||
- Question the format and methodology being used
|
||||
- Suggest alternative frameworks or mental models
|
||||
@@ -83,24 +95,28 @@
|
||||
## Advanced 2025 Techniques
|
||||
|
||||
**Self-Consistency Validation**
|
||||
|
||||
- Generate multiple reasoning paths for same problem
|
||||
- Compare consistency across different approaches
|
||||
- Identify most reliable and robust solution
|
||||
- Highlight areas where approaches diverge and why
|
||||
|
||||
**ReWOO (Reasoning Without Observation)**
|
||||
|
||||
- Separate parametric reasoning from tool-based actions
|
||||
- Create reasoning plan without external dependencies
|
||||
- Identify what can be solved through pure reasoning
|
||||
- Optimize for efficiency and reduced token usage
|
||||
|
||||
**Persona-Pattern Hybrid**
|
||||
|
||||
- Combine specific role expertise with elicitation pattern
|
||||
- Architect + Risk Analysis: Deep technical risk assessment
|
||||
- UX Expert + User Journey: End-to-end experience critique
|
||||
- PM + Stakeholder Analysis: Multi-perspective impact review
|
||||
|
||||
**Emergent Collaboration Discovery**
|
||||
|
||||
- Allow multiple perspectives to naturally emerge
|
||||
- Identify unexpected insights from persona interactions
|
||||
- Explore novel combinations of viewpoints
|
||||
@@ -109,18 +125,21 @@
|
||||
## Game-Based Elicitation Methods
|
||||
|
||||
**Red Team vs Blue Team**
|
||||
|
||||
- Red Team: Attack the proposal, find vulnerabilities
|
||||
- Blue Team: Defend and strengthen the approach
|
||||
- Competitive analysis reveals blind spots
|
||||
- Results in more robust, battle-tested solutions
|
||||
|
||||
**Innovation Tournament**
|
||||
|
||||
- Pit multiple alternative approaches against each other
|
||||
- Score each approach across different criteria
|
||||
- Crowd-source evaluation from different personas
|
||||
- Identify winning combination of features
|
||||
|
||||
**Escape Room Challenge**
|
||||
|
||||
- Present content as constraints to work within
|
||||
- Find creative solutions within tight limitations
|
||||
- Identify minimum viable approach
|
||||
@@ -129,6 +148,7 @@
|
||||
## Process Control
|
||||
|
||||
**Proceed / No Further Actions**
|
||||
|
||||
- Acknowledge choice to finalize current work
|
||||
- Accept output as-is or move to next step
|
||||
- Prepare to continue without additional elicitation
|
||||
|
||||
@@ -139,16 +139,19 @@ Critical: This is where you'll need to be interactive with the user if informati
|
||||
|
||||
Create Dev Technical Guidance section with available information:
|
||||
|
||||
```markdown
|
||||
````markdown
|
||||
## Dev Technical Guidance
|
||||
|
||||
### Existing System Context
|
||||
|
||||
[Extract from available documentation]
|
||||
|
||||
### Integration Approach
|
||||
|
||||
[Based on patterns found or ask user]
|
||||
|
||||
### Technical Constraints
|
||||
|
||||
[From documentation or user input]
|
||||
|
||||
### Missing Information
|
||||
@@ -191,6 +194,7 @@ Example task structure for brownfield:
|
||||
- [ ] Integration test for {{integration point}}
|
||||
- [ ] Update existing tests if needed
|
||||
```
|
||||
````
|
||||
|
||||
### 5. Risk Assessment and Mitigation
|
||||
|
||||
@@ -202,14 +206,17 @@ Add section for brownfield-specific risks:
|
||||
## Risk Assessment
|
||||
|
||||
### Implementation Risks
|
||||
|
||||
- **Primary Risk**: {{main risk to existing system}}
|
||||
- **Mitigation**: {{how to address}}
|
||||
- **Verification**: {{how to confirm safety}}
|
||||
|
||||
### Rollback Plan
|
||||
|
||||
- {{Simple steps to undo changes if needed}}
|
||||
|
||||
### Safety Checks
|
||||
|
||||
- [ ] Existing {{feature}} tested before changes
|
||||
- [ ] Changes can be feature-flagged or isolated
|
||||
- [ ] Rollback procedure documented
|
||||
@@ -252,6 +259,7 @@ Include header noting documentation context:
|
||||
<!-- Context: Brownfield enhancement to {{existing system}} -->
|
||||
|
||||
## Status: Draft
|
||||
|
||||
[Rest of story content...]
|
||||
```
|
||||
|
||||
|
||||
@@ -21,63 +21,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -246,13 +237,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
|
||||
@@ -112,7 +112,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| ------ | ------- | --------------------------- | --------- |
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
@@ -137,7 +137,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Actual Tech Stack (from package.json/requirements.txt)
|
||||
|
||||
| Category | Technology | Version | Notes |
|
||||
|----------|------------|---------|--------|
|
||||
| --------- | ---------- | ------- | -------------------------- |
|
||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||
@@ -179,6 +179,7 @@ project-root/
|
||||
### Data Models
|
||||
|
||||
Instead of duplicating, reference actual model files:
|
||||
|
||||
- **User Model**: See `src/models/User.js`
|
||||
- **Order Model**: See `src/models/Order.js`
|
||||
- **Related Types**: TypeScript definitions in `src/types/`
|
||||
@@ -209,7 +210,7 @@ Instead of duplicating, reference actual model files:
|
||||
### External Services
|
||||
|
||||
| Service | Purpose | Integration Type | Key Files |
|
||||
|---------|---------|------------------|-----------|
|
||||
| -------- | -------- | ---------------- | ------------------------------ |
|
||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||
|
||||
@@ -256,6 +257,7 @@ npm run test:integration # Runs integration tests (requires local DB)
|
||||
### Files That Will Need Modification
|
||||
|
||||
Based on the enhancement requirements, these files will be affected:
|
||||
|
||||
- `src/services/userService.js` - Add new user fields
|
||||
- `src/models/User.js` - Update schema
|
||||
- `src/routes/userRoutes.js` - New endpoints
|
||||
|
||||
@@ -11,14 +11,12 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
### Required Steps
|
||||
|
||||
1. First, locate and scan:
|
||||
|
||||
- The `docs/` directory and all subdirectories
|
||||
- The existing `docs/index.md` file (create if absent)
|
||||
- All markdown (`.md`) and text (`.txt`) files in the documentation structure
|
||||
- Note the folder structure for hierarchical organization
|
||||
|
||||
2. For the existing `docs/index.md`:
|
||||
|
||||
- Parse current entries
|
||||
- Note existing file references and descriptions
|
||||
- Identify any broken links or missing files
|
||||
@@ -26,7 +24,6 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
- Preserve existing folder sections
|
||||
|
||||
3. For each documentation file found:
|
||||
|
||||
- Extract the title (from first heading or filename)
|
||||
- Generate a brief description by analyzing the content
|
||||
- Create a relative markdown link to the file
|
||||
@@ -35,7 +32,6 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
- If missing or outdated, prepare an update
|
||||
|
||||
4. For any missing or non-existent files found in index:
|
||||
|
||||
- Present a list of all entries that reference non-existent files
|
||||
- For each entry:
|
||||
- Show the full entry details (title, path, description)
|
||||
@@ -88,7 +84,6 @@ Documents within the `another-folder/` directory:
|
||||
### [Nested Document](./another-folder/document.md)
|
||||
|
||||
Description of nested document.
|
||||
|
||||
```
|
||||
|
||||
### Index Entry Format
|
||||
@@ -157,7 +152,6 @@ For each file referenced in the index but not found in the filesystem:
|
||||
### Special Cases
|
||||
|
||||
1. **Sharded Documents**: If a folder contains an `index.md` file, treat it as a sharded document:
|
||||
|
||||
- Use the folder's `index.md` title as the section title
|
||||
- List the folder's documents as subsections
|
||||
- Note in the description that this is a multi-part document
|
||||
|
||||
@@ -6,7 +6,7 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
|
||||
|
||||
## Instructions
|
||||
|
||||
When entering KB mode (*kb-mode), follow these steps:
|
||||
When entering KB mode (\*kb-mode), follow these steps:
|
||||
|
||||
### 1. Welcome and Guide
|
||||
|
||||
@@ -48,12 +48,12 @@ Or ask me about anything else related to BMad-Method!
|
||||
When user is done or wants to exit KB mode:
|
||||
|
||||
- Summarize key points discussed if helpful
|
||||
- Remind them they can return to KB mode anytime with *kb-mode
|
||||
- Remind them they can return to KB mode anytime with \*kb-mode
|
||||
- Suggest next steps based on what was discussed
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User**: *kb-mode
|
||||
**User**: \*kb-mode
|
||||
|
||||
**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
|
||||
|
||||
|
||||
@@ -18,6 +18,7 @@ optional:
|
||||
## Purpose
|
||||
|
||||
Assess non-functional requirements for a story and generate:
|
||||
|
||||
1. YAML block for the gate file's `nfr_validation` section
|
||||
2. Brief markdown assessment saved to `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`
|
||||
|
||||
@@ -26,6 +27,7 @@ Assess non-functional requirements for a story and generate:
|
||||
### 0. Fail-safe for Missing Inputs
|
||||
|
||||
If story_path or story file can't be found:
|
||||
|
||||
- Still create assessment file with note: "Source story not found"
|
||||
- Set all selected NFRs to CONCERNS with notes: "Target unknown / evidence missing"
|
||||
- Continue with assessment to provide value
|
||||
@@ -52,6 +54,7 @@ Which NFRs should I assess? (Enter numbers or press Enter for default)
|
||||
### 2. Check for Thresholds
|
||||
|
||||
Look for NFR requirements in:
|
||||
|
||||
- Story acceptance criteria
|
||||
- `docs/architecture/*.md` files
|
||||
- `docs/technical-preferences.md`
|
||||
@@ -72,6 +75,7 @@ No security requirements found. Required auth method?
|
||||
### 3. Quick Assessment
|
||||
|
||||
For each selected NFR, check:
|
||||
|
||||
- Is there evidence it's implemented?
|
||||
- Can we validate it?
|
||||
- Are there obvious gaps?
|
||||
@@ -123,18 +127,21 @@ If `technical-preferences.md` defines custom weights, use those instead.
|
||||
|
||||
```markdown
|
||||
# NFR Assessment: {epic}.{story}
|
||||
|
||||
Date: {date}
|
||||
Reviewer: Quinn
|
||||
|
||||
<!-- Note: Source story not found (if applicable) -->
|
||||
|
||||
## Summary
|
||||
|
||||
- Security: CONCERNS - Missing rate limiting
|
||||
- Performance: PASS - Meets <200ms requirement
|
||||
- Reliability: PASS - Proper error handling
|
||||
- Maintainability: CONCERNS - Test coverage below target
|
||||
|
||||
## Critical Issues
|
||||
|
||||
1. **No rate limiting** (Security)
|
||||
- Risk: Brute force attacks possible
|
||||
- Fix: Add rate limiting middleware to auth endpoints
|
||||
@@ -144,6 +151,7 @@ Reviewer: Quinn
|
||||
- Fix: Add tests for uncovered branches
|
||||
|
||||
## Quick Wins
|
||||
|
||||
- Add rate limiting: ~2 hours
|
||||
- Increase test coverage: ~4 hours
|
||||
- Add performance monitoring: ~1 hour
|
||||
@@ -152,6 +160,7 @@ Reviewer: Quinn
|
||||
## Output 3: Story Update Line
|
||||
|
||||
**End with this line for the review task to quote:**
|
||||
|
||||
```
|
||||
NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
|
||||
```
|
||||
@@ -159,6 +168,7 @@ NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
|
||||
## Output 4: Gate Integration Line
|
||||
|
||||
**Always print at the end:**
|
||||
|
||||
```
|
||||
Gate NFR block ready → paste into docs/qa/gates/{epic}.{story}-{slug}.yml under nfr_validation
|
||||
```
|
||||
@@ -166,66 +176,82 @@ Gate NFR block ready → paste into docs/qa/gates/{epic}.{story}-{slug}.yml unde
|
||||
## Assessment Criteria
|
||||
|
||||
### Security
|
||||
|
||||
**PASS if:**
|
||||
|
||||
- Authentication implemented
|
||||
- Authorization enforced
|
||||
- Input validation present
|
||||
- No hardcoded secrets
|
||||
|
||||
**CONCERNS if:**
|
||||
|
||||
- Missing rate limiting
|
||||
- Weak encryption
|
||||
- Incomplete authorization
|
||||
|
||||
**FAIL if:**
|
||||
|
||||
- No authentication
|
||||
- Hardcoded credentials
|
||||
- SQL injection vulnerabilities
|
||||
|
||||
### Performance
|
||||
|
||||
**PASS if:**
|
||||
|
||||
- Meets response time targets
|
||||
- No obvious bottlenecks
|
||||
- Reasonable resource usage
|
||||
|
||||
**CONCERNS if:**
|
||||
|
||||
- Close to limits
|
||||
- Missing indexes
|
||||
- No caching strategy
|
||||
|
||||
**FAIL if:**
|
||||
|
||||
- Exceeds response time limits
|
||||
- Memory leaks
|
||||
- Unoptimized queries
|
||||
|
||||
### Reliability
|
||||
|
||||
**PASS if:**
|
||||
|
||||
- Error handling present
|
||||
- Graceful degradation
|
||||
- Retry logic where needed
|
||||
|
||||
**CONCERNS if:**
|
||||
|
||||
- Some error cases unhandled
|
||||
- No circuit breakers
|
||||
- Missing health checks
|
||||
|
||||
**FAIL if:**
|
||||
|
||||
- No error handling
|
||||
- Crashes on errors
|
||||
- No recovery mechanisms
|
||||
|
||||
### Maintainability
|
||||
|
||||
**PASS if:**
|
||||
|
||||
- Test coverage meets target
|
||||
- Code well-structured
|
||||
- Documentation present
|
||||
|
||||
**CONCERNS if:**
|
||||
|
||||
- Test coverage below target
|
||||
- Some code duplication
|
||||
- Missing documentation
|
||||
|
||||
**FAIL if:**
|
||||
|
||||
- No tests
|
||||
- Highly coupled code
|
||||
- No documentation
|
||||
@@ -291,6 +317,7 @@ maintainability:
|
||||
8. **Portability**: Adaptability, installability
|
||||
|
||||
Use these when assessing beyond the core four.
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
@@ -312,4 +339,5 @@ performance_deep_dive:
|
||||
max_rps: 150
|
||||
breaking_point: 200 rps
|
||||
```
|
||||
|
||||
</details>
|
||||
@@ -17,6 +17,7 @@ Generate a standalone quality gate file that provides a clear pass/fail decision
|
||||
**ALWAYS** create file at: `docs/qa/gates/{epic}.{story}-{slug}.yml`
|
||||
|
||||
Slug rules:
|
||||
|
||||
- Convert to lowercase
|
||||
- Replace spaces with hyphens
|
||||
- Strip punctuation
|
||||
@@ -79,21 +80,25 @@ waiver:
|
||||
## Gate Decision Criteria
|
||||
|
||||
### PASS
|
||||
|
||||
- All acceptance criteria met
|
||||
- No high-severity issues
|
||||
- Test coverage meets project standards
|
||||
|
||||
### CONCERNS
|
||||
|
||||
- Non-blocking issues present
|
||||
- Should be tracked and scheduled
|
||||
- Can proceed with awareness
|
||||
|
||||
### FAIL
|
||||
|
||||
- Acceptance criteria not met
|
||||
- High-severity issues present
|
||||
- Recommend return to InProgress
|
||||
|
||||
### WAIVED
|
||||
|
||||
- Issues explicitly accepted
|
||||
- Requires approval and reason
|
||||
- Proceed despite known issues
|
||||
@@ -101,6 +106,7 @@ waiver:
|
||||
## Severity Scale
|
||||
|
||||
**FIXED VALUES - NO VARIATIONS:**
|
||||
|
||||
- `low`: Minor issues, cosmetic problems
|
||||
- `medium`: Should fix soon, not blocking
|
||||
- `high`: Critical issues, should block release
|
||||
@@ -134,11 +140,13 @@ After creating gate file, append to story's QA Results section:
|
||||
## QA Results
|
||||
|
||||
### Review Date: 2025-01-12
|
||||
|
||||
### Reviewed By: Quinn (Test Architect)
|
||||
|
||||
[... existing review content ...]
|
||||
|
||||
### Gate Status
|
||||
|
||||
Gate: CONCERNS → docs/qa/gates/1.3-user-auth-login.yml
|
||||
```
|
||||
|
||||
|
||||
@@ -23,6 +23,7 @@ required:
|
||||
### 1. Risk Assessment (Determines Review Depth)
|
||||
|
||||
**Auto-escalate to deep review when:**
|
||||
|
||||
- Auth/payment/security files touched
|
||||
- No tests added to story
|
||||
- Diff > 500 lines
|
||||
@@ -38,6 +39,7 @@ required:
|
||||
- Verify all requirements have corresponding test cases
|
||||
|
||||
**B. Code Quality Review**
|
||||
|
||||
- Architecture and design patterns
|
||||
- Refactoring opportunities (and perform them)
|
||||
- Code duplication or inefficiencies
|
||||
@@ -46,6 +48,7 @@ required:
|
||||
- Best practices adherence
|
||||
|
||||
**C. Test Architecture Assessment**
|
||||
|
||||
- Test coverage adequacy at appropriate levels
|
||||
- Test level appropriateness (what should be unit vs integration vs e2e)
|
||||
- Test design quality and maintainability
|
||||
@@ -55,17 +58,20 @@ required:
|
||||
- Test execution time and reliability
|
||||
|
||||
**D. Non-Functional Requirements (NFRs)**
|
||||
|
||||
- Security: Authentication, authorization, data protection
|
||||
- Performance: Response times, resource usage
|
||||
- Reliability: Error handling, recovery mechanisms
|
||||
- Maintainability: Code clarity, documentation
|
||||
|
||||
**E. Testability Evaluation**
|
||||
|
||||
- Controllability: Can we control the inputs?
|
||||
- Observability: Can we observe the outputs?
|
||||
- Debuggability: Can we debug failures easily?
|
||||
|
||||
**F. Technical Debt Identification**
|
||||
|
||||
- Accumulated shortcuts
|
||||
- Missing tests
|
||||
- Outdated dependencies
|
||||
@@ -103,6 +109,7 @@ required:
|
||||
**CRITICAL**: You are ONLY authorized to update the "QA Results" section of the story file. DO NOT modify any other sections.
|
||||
|
||||
**QA Results Anchor Rule:**
|
||||
|
||||
- If `## QA Results` doesn't exist, append it at end of file
|
||||
- If it exists, append a new dated entry below existing entries
|
||||
- Never edit other sections
|
||||
@@ -113,25 +120,31 @@ After review and any refactoring, append your results to the story file in the Q
|
||||
## QA Results
|
||||
|
||||
### Review Date: [Date]
|
||||
|
||||
### Reviewed By: Quinn (Test Architect)
|
||||
|
||||
### Code Quality Assessment
|
||||
|
||||
[Overall assessment of implementation quality]
|
||||
|
||||
### Refactoring Performed
|
||||
|
||||
[List any refactoring you performed with explanations]
|
||||
|
||||
- **File**: [filename]
|
||||
- **Change**: [what was changed]
|
||||
- **Why**: [reason for change]
|
||||
- **How**: [how it improves the code]
|
||||
|
||||
### Compliance Check
|
||||
|
||||
- Coding Standards: [✓/✗] [notes if any]
|
||||
- Project Structure: [✓/✗] [notes if any]
|
||||
- Testing Strategy: [✓/✗] [notes if any]
|
||||
- All ACs Met: [✓/✗] [notes if any]
|
||||
|
||||
### Improvements Checklist
|
||||
|
||||
[Check off items you handled yourself, leave unchecked for dev to address]
|
||||
|
||||
- [x] Refactored user service for better error handling (services/user.service.ts)
|
||||
@@ -141,20 +154,25 @@ After review and any refactoring, append your results to the story file in the Q
|
||||
- [ ] Update API documentation for new error codes
|
||||
|
||||
### Security Review
|
||||
|
||||
[Any security concerns found and whether addressed]
|
||||
|
||||
### Performance Considerations
|
||||
|
||||
[Any performance issues found and whether addressed]
|
||||
|
||||
### Files Modified During Review
|
||||
|
||||
[If you modified files, list them here - ask Dev to update File List]
|
||||
|
||||
### Gate Status
|
||||
|
||||
Gate: {STATUS} → docs/qa/gates/{epic}.{story}-{slug}.yml
|
||||
Risk profile: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
|
||||
NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
|
||||
|
||||
### Recommended Status
|
||||
|
||||
[✓ Ready for Done] / [✗ Changes Required - See unchecked items above]
|
||||
(Story owner decides final status)
|
||||
```
|
||||
@@ -162,6 +180,7 @@ NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
|
||||
## Output 2: Create Quality Gate File
|
||||
|
||||
**Template and Directory:**
|
||||
|
||||
- Render from `templates/qa-gate-tmpl.yaml`
|
||||
- Create `docs/qa/gates/` directory if missing
|
||||
- Save to: `docs/qa/gates/{epic}.{story}-{slug}.yml`
|
||||
@@ -185,8 +204,8 @@ quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) or use technical-prefer
|
||||
expires: "{ISO-8601 timestamp}" # Typically 2 weeks from review
|
||||
|
||||
evidence:
|
||||
tests_reviewed: {count}
|
||||
risks_identified: {count}
|
||||
tests_reviewed: { count }
|
||||
risks_identified: { count }
|
||||
trace:
|
||||
ac_covered: [1, 2, 3] # AC numbers with test coverage
|
||||
ac_gaps: [4] # AC numbers lacking coverage
|
||||
@@ -240,6 +259,7 @@ If risk_summary exists, apply its thresholds first (≥9 → FAIL, ≥6 → CONC
|
||||
- WAIVED only when waiver.active: true with reason/approver
|
||||
|
||||
Detailed criteria:
|
||||
|
||||
- **PASS**: All critical requirements met, no blocking issues
|
||||
- **CONCERNS**: Non-critical issues found, team should review
|
||||
- **FAIL**: Critical issues that should be addressed
|
||||
|
||||
@@ -91,13 +91,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
||||
For each extracted section:
|
||||
|
||||
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
||||
|
||||
- Remove special characters
|
||||
- Replace spaces with dashes
|
||||
- Example: "## Tech Stack" → `tech-stack.md`
|
||||
|
||||
2. **Adjust heading levels**:
|
||||
|
||||
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
||||
- All subsection levels decrease by 1:
|
||||
|
||||
|
||||
@@ -9,7 +9,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -22,14 +21,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -38,7 +35,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -46,7 +42,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -60,7 +55,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -70,7 +64,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
|
||||
22
dist/agents/analyst.txt
vendored
22
dist/agents/analyst.txt
vendored
@@ -266,63 +266,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -491,13 +482,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -873,7 +862,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| ------ | ------- | --------------------------- | --------- |
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
@@ -898,7 +887,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Actual Tech Stack (from package.json/requirements.txt)
|
||||
|
||||
| Category | Technology | Version | Notes |
|
||||
|----------|------------|---------|--------|
|
||||
| --------- | ---------- | ------- | -------------------------- |
|
||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||
@@ -940,6 +929,7 @@ project-root/
|
||||
### Data Models
|
||||
|
||||
Instead of duplicating, reference actual model files:
|
||||
|
||||
- **User Model**: See `src/models/User.js`
|
||||
- **Order Model**: See `src/models/Order.js`
|
||||
- **Related Types**: TypeScript definitions in `src/types/`
|
||||
@@ -970,7 +960,7 @@ Instead of duplicating, reference actual model files:
|
||||
### External Services
|
||||
|
||||
| Service | Purpose | Integration Type | Key Files |
|
||||
|---------|---------|------------------|-----------|
|
||||
| -------- | -------- | ---------------- | ------------------------------ |
|
||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||
|
||||
@@ -1017,6 +1007,7 @@ npm run test:integration # Runs integration tests (requires local DB)
|
||||
### Files That Will Need Modification
|
||||
|
||||
Based on the enhancement requirements, these files will be affected:
|
||||
|
||||
- `src/services/userService.js` - Add new user fields
|
||||
- `src/models/User.js` - Update schema
|
||||
- `src/routes/userRoutes.js` - New endpoints
|
||||
@@ -2690,8 +2681,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
|
||||
|
||||
```markdown
|
||||
## Goals and Background Context
|
||||
|
||||
## Requirements
|
||||
|
||||
## User Interface Design Goals
|
||||
|
||||
## Success Metrics
|
||||
```
|
||||
|
||||
|
||||
31
dist/agents/architect.txt
vendored
31
dist/agents/architect.txt
vendored
@@ -233,63 +233,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -458,13 +449,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -616,7 +605,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| ------ | ------- | --------------------------- | --------- |
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
@@ -641,7 +630,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Actual Tech Stack (from package.json/requirements.txt)
|
||||
|
||||
| Category | Technology | Version | Notes |
|
||||
|----------|------------|---------|--------|
|
||||
| --------- | ---------- | ------- | -------------------------- |
|
||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||
@@ -683,6 +672,7 @@ project-root/
|
||||
### Data Models
|
||||
|
||||
Instead of duplicating, reference actual model files:
|
||||
|
||||
- **User Model**: See `src/models/User.js`
|
||||
- **Order Model**: See `src/models/Order.js`
|
||||
- **Related Types**: TypeScript definitions in `src/types/`
|
||||
@@ -713,7 +703,7 @@ Instead of duplicating, reference actual model files:
|
||||
### External Services
|
||||
|
||||
| Service | Purpose | Integration Type | Key Files |
|
||||
|---------|---------|------------------|-----------|
|
||||
| -------- | -------- | ---------------- | ------------------------------ |
|
||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||
|
||||
@@ -760,6 +750,7 @@ npm run test:integration # Runs integration tests (requires local DB)
|
||||
### Files That Will Need Modification
|
||||
|
||||
Based on the enhancement requirements, these files will be affected:
|
||||
|
||||
- `src/services/userService.js` - Add new user fields
|
||||
- `src/models/User.js` - Update schema
|
||||
- `src/routes/userRoutes.js` - New endpoints
|
||||
@@ -857,7 +848,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -870,14 +860,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -886,7 +874,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -894,7 +881,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -908,7 +894,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -918,7 +903,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -3496,33 +3480,28 @@ Ask the user if they want to work through the checklist:
|
||||
Now that you've completed the checklist, generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall architecture readiness (High/Medium/Low)
|
||||
- Critical risks identified
|
||||
- Key strengths of the architecture
|
||||
- Project type (Full-stack/Frontend/Backend) and sections evaluated
|
||||
|
||||
2. Section Analysis
|
||||
|
||||
- Pass rate for each major section (percentage of items passed)
|
||||
- Most concerning failures or gaps
|
||||
- Sections requiring immediate attention
|
||||
- Note any sections skipped due to project type
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations for each
|
||||
- Timeline impact of addressing issues
|
||||
|
||||
4. Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Should-fix items for better quality
|
||||
- Nice-to-have improvements
|
||||
|
||||
5. AI Implementation Readiness
|
||||
|
||||
- Specific concerns for AI agent implementation
|
||||
- Areas needing additional clarification
|
||||
- Complexity hotspots to address
|
||||
|
||||
86
dist/agents/bmad-master.txt
vendored
86
dist/agents/bmad-master.txt
vendored
@@ -794,63 +794,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -1019,13 +1010,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -1281,7 +1270,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| ------ | ------- | --------------------------- | --------- |
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
@@ -1306,7 +1295,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Actual Tech Stack (from package.json/requirements.txt)
|
||||
|
||||
| Category | Technology | Version | Notes |
|
||||
|----------|------------|---------|--------|
|
||||
| --------- | ---------- | ------- | -------------------------- |
|
||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||
@@ -1348,6 +1337,7 @@ project-root/
|
||||
### Data Models
|
||||
|
||||
Instead of duplicating, reference actual model files:
|
||||
|
||||
- **User Model**: See `src/models/User.js`
|
||||
- **Order Model**: See `src/models/Order.js`
|
||||
- **Related Types**: TypeScript definitions in `src/types/`
|
||||
@@ -1378,7 +1368,7 @@ Instead of duplicating, reference actual model files:
|
||||
### External Services
|
||||
|
||||
| Service | Purpose | Integration Type | Key Files |
|
||||
|---------|---------|------------------|-----------|
|
||||
| -------- | -------- | ---------------- | ------------------------------ |
|
||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||
|
||||
@@ -1425,6 +1415,7 @@ npm run test:integration # Runs integration tests (requires local DB)
|
||||
### Files That Will Need Modification
|
||||
|
||||
Based on the enhancement requirements, these files will be affected:
|
||||
|
||||
- `src/services/userService.js` - Add new user fields
|
||||
- `src/models/User.js` - Update schema
|
||||
- `src/routes/userRoutes.js` - New endpoints
|
||||
@@ -1637,7 +1628,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -1650,14 +1640,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -1666,7 +1654,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -1674,7 +1661,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -1688,7 +1674,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -1698,7 +1683,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -1789,14 +1773,12 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
### Required Steps
|
||||
|
||||
1. First, locate and scan:
|
||||
|
||||
- The `docs/` directory and all subdirectories
|
||||
- The existing `docs/index.md` file (create if absent)
|
||||
- All markdown (`.md`) and text (`.txt`) files in the documentation structure
|
||||
- Note the folder structure for hierarchical organization
|
||||
|
||||
2. For the existing `docs/index.md`:
|
||||
|
||||
- Parse current entries
|
||||
- Note existing file references and descriptions
|
||||
- Identify any broken links or missing files
|
||||
@@ -1804,7 +1786,6 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
- Preserve existing folder sections
|
||||
|
||||
3. For each documentation file found:
|
||||
|
||||
- Extract the title (from first heading or filename)
|
||||
- Generate a brief description by analyzing the content
|
||||
- Create a relative markdown link to the file
|
||||
@@ -1813,7 +1794,6 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
||||
- If missing or outdated, prepare an update
|
||||
|
||||
4. For any missing or non-existent files found in index:
|
||||
|
||||
- Present a list of all entries that reference non-existent files
|
||||
- For each entry:
|
||||
- Show the full entry details (title, path, description)
|
||||
@@ -1866,7 +1846,6 @@ Documents within the `another-folder/` directory:
|
||||
### [Nested Document](./another-folder/document.md)
|
||||
|
||||
Description of nested document.
|
||||
|
||||
```
|
||||
|
||||
### Index Entry Format
|
||||
@@ -1935,7 +1914,6 @@ For each file referenced in the index but not found in the filesystem:
|
||||
### Special Cases
|
||||
|
||||
1. **Sharded Documents**: If a folder contains an `index.md` file, treat it as a sharded document:
|
||||
|
||||
- Use the folder's `index.md` title as the section title
|
||||
- List the folder's documents as subsections
|
||||
- Note in the description that this is a multi-part document
|
||||
@@ -2051,13 +2029,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
||||
For each extracted section:
|
||||
|
||||
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
||||
|
||||
- Remove special characters
|
||||
- Replace spaces with dashes
|
||||
- Example: "## Tech Stack" → `tech-stack.md`
|
||||
|
||||
2. **Adjust heading levels**:
|
||||
|
||||
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
||||
- All subsection levels decrease by 1:
|
||||
|
||||
@@ -6457,33 +6433,28 @@ Ask the user if they want to work through the checklist:
|
||||
Now that you've completed the checklist, generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall architecture readiness (High/Medium/Low)
|
||||
- Critical risks identified
|
||||
- Key strengths of the architecture
|
||||
- Project type (Full-stack/Frontend/Backend) and sections evaluated
|
||||
|
||||
2. Section Analysis
|
||||
|
||||
- Pass rate for each major section (percentage of items passed)
|
||||
- Most concerning failures or gaps
|
||||
- Sections requiring immediate attention
|
||||
- Note any sections skipped due to project type
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations for each
|
||||
- Timeline impact of addressing issues
|
||||
|
||||
4. Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Should-fix items for better quality
|
||||
- Nice-to-have improvements
|
||||
|
||||
5. AI Implementation Readiness
|
||||
|
||||
- Specific concerns for AI agent implementation
|
||||
- Areas needing additional clarification
|
||||
- Complexity hotspots to address
|
||||
@@ -6989,7 +6960,6 @@ Ask the user if they want to work through the checklist:
|
||||
Create a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall PRD completeness (percentage)
|
||||
- MVP scope appropriateness (Too Large/Just Right/Too Small)
|
||||
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
|
||||
@@ -6997,26 +6967,22 @@ Create a comprehensive validation report that includes:
|
||||
|
||||
2. Category Analysis Table
|
||||
Fill in the actual table with:
|
||||
|
||||
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
|
||||
- Critical Issues: Specific problems that block progress
|
||||
|
||||
3. Top Issues by Priority
|
||||
|
||||
- BLOCKERS: Must fix before architect can proceed
|
||||
- HIGH: Should fix for quality
|
||||
- MEDIUM: Would improve clarity
|
||||
- LOW: Nice to have
|
||||
|
||||
4. MVP Scope Assessment
|
||||
|
||||
- Features that might be cut for true MVP
|
||||
- Missing features that are essential
|
||||
- Complexity concerns
|
||||
- Timeline realism
|
||||
|
||||
5. Technical Readiness
|
||||
|
||||
- Clarity of technical constraints
|
||||
- Identified technical risks
|
||||
- Areas needing architect investigation
|
||||
@@ -7071,12 +7037,10 @@ PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
@@ -7410,7 +7374,6 @@ Ask the user if they want to work through the checklist:
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
@@ -7420,42 +7383,36 @@ Generate a comprehensive validation report that adapts to project type:
|
||||
2. Project-Specific Analysis
|
||||
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
@@ -7532,14 +7489,12 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
1. **Requirements Met:**
|
||||
|
||||
[[LLM: Be specific - list each requirement and whether it's complete]]
|
||||
|
||||
- [ ] All functional requirements specified in the story are implemented.
|
||||
- [ ] All acceptance criteria defined in the story are met.
|
||||
|
||||
2. **Coding Standards & Project Structure:**
|
||||
|
||||
[[LLM: Code quality matters for maintainability. Check each item carefully]]
|
||||
|
||||
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
|
||||
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
|
||||
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
|
||||
@@ -7551,7 +7506,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
3. **Testing:**
|
||||
|
||||
[[LLM: Testing proves your code works. Be honest about test coverage]]
|
||||
|
||||
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
||||
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
||||
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
|
||||
@@ -7560,14 +7514,12 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
4. **Functionality & Verification:**
|
||||
|
||||
[[LLM: Did you actually run and test your code? Be specific about what you tested]]
|
||||
|
||||
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
|
||||
- [ ] Edge cases and potential error conditions considered and handled gracefully.
|
||||
|
||||
5. **Story Administration:**
|
||||
|
||||
[[LLM: Documentation helps the next developer. What should they know?]]
|
||||
|
||||
- [ ] 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.
|
||||
- [ ] 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.
|
||||
@@ -7575,7 +7527,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
6. **Dependencies, Build & Configuration:**
|
||||
|
||||
[[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
|
||||
|
||||
- [ ] Project builds successfully without errors.
|
||||
- [ ] Project linting passes
|
||||
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
|
||||
@@ -7586,7 +7537,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
7. **Documentation (If Applicable):**
|
||||
|
||||
[[LLM: Good documentation prevents future confusion. What needs explaining?]]
|
||||
|
||||
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
|
||||
- [ ] User-facing documentation updated, if changes impact users.
|
||||
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
|
||||
@@ -7728,19 +7678,16 @@ Note: We don't need every file listed - just the important ones.]]
|
||||
Generate a concise validation report:
|
||||
|
||||
1. Quick Summary
|
||||
|
||||
- Story readiness: READY / NEEDS REVISION / BLOCKED
|
||||
- Clarity score (1-10)
|
||||
- Major gaps identified
|
||||
|
||||
2. Fill in the validation table with:
|
||||
|
||||
- PASS: Requirements clearly met
|
||||
- PARTIAL: Some gaps but workable
|
||||
- FAIL: Critical information missing
|
||||
|
||||
3. Specific Issues (if any)
|
||||
|
||||
- List concrete problems to fix
|
||||
- Suggest specific improvements
|
||||
- Identify any blocking dependencies
|
||||
@@ -8421,8 +8368,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
|
||||
|
||||
```markdown
|
||||
## Goals and Background Context
|
||||
|
||||
## Requirements
|
||||
|
||||
## User Interface Design Goals
|
||||
|
||||
## Success Metrics
|
||||
```
|
||||
|
||||
@@ -8618,16 +8568,19 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Core Reflective Methods
|
||||
|
||||
**Expand or Contract for Audience**
|
||||
|
||||
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
|
||||
- Identify specific target audience if relevant
|
||||
- Tailor content complexity and depth accordingly
|
||||
|
||||
**Explain Reasoning (CoT Step-by-Step)**
|
||||
|
||||
- Walk through the step-by-step thinking process
|
||||
- Reveal underlying assumptions and decision points
|
||||
- Show how conclusions were reached from current role's perspective
|
||||
|
||||
**Critique and Refine**
|
||||
|
||||
- Review output for flaws, inconsistencies, or improvement areas
|
||||
- Identify specific weaknesses from role's expertise
|
||||
- Suggest refined version reflecting domain knowledge
|
||||
@@ -8635,12 +8588,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Structural Analysis Methods
|
||||
|
||||
**Analyze Logical Flow and Dependencies**
|
||||
|
||||
- Examine content structure for logical progression
|
||||
- Check internal consistency and coherence
|
||||
- Identify and validate dependencies between elements
|
||||
- Confirm effective ordering and sequencing
|
||||
|
||||
**Assess Alignment with Overall Goals**
|
||||
|
||||
- Evaluate content contribution to stated objectives
|
||||
- Identify any misalignments or gaps
|
||||
- Interpret alignment from specific role's perspective
|
||||
@@ -8649,12 +8604,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Risk and Challenge Methods
|
||||
|
||||
**Identify Potential Risks and Unforeseen Issues**
|
||||
|
||||
- Brainstorm potential risks from role's expertise
|
||||
- Identify overlooked edge cases or scenarios
|
||||
- Anticipate unintended consequences
|
||||
- Highlight implementation challenges
|
||||
|
||||
**Challenge from Critical Perspective**
|
||||
|
||||
- Adopt critical stance on current content
|
||||
- Play devil's advocate from specified viewpoint
|
||||
- Argue against proposal highlighting weaknesses
|
||||
@@ -8663,12 +8620,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Creative Exploration Methods
|
||||
|
||||
**Tree of Thoughts Deep Dive**
|
||||
|
||||
- Break problem into discrete "thoughts" or intermediate steps
|
||||
- Explore multiple reasoning paths simultaneously
|
||||
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
|
||||
- Apply search algorithms (BFS/DFS) to find optimal solution paths
|
||||
|
||||
**Hindsight is 20/20: The 'If Only...' Reflection**
|
||||
|
||||
- Imagine retrospective scenario based on current content
|
||||
- Identify the one "if only we had known/done X..." insight
|
||||
- Describe imagined consequences humorously or dramatically
|
||||
@@ -8677,6 +8636,7 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Multi-Persona Collaboration Methods
|
||||
|
||||
**Agile Team Perspective Shift**
|
||||
|
||||
- Rotate through different Scrum team member viewpoints
|
||||
- Product Owner: Focus on user value and business impact
|
||||
- Scrum Master: Examine process flow and team dynamics
|
||||
@@ -8684,12 +8644,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
- QA: Identify testing scenarios and quality concerns
|
||||
|
||||
**Stakeholder Round Table**
|
||||
|
||||
- Convene virtual meeting with multiple personas
|
||||
- Each persona contributes unique perspective on content
|
||||
- Identify conflicts and synergies between viewpoints
|
||||
- Synthesize insights into actionable recommendations
|
||||
|
||||
**Meta-Prompting Analysis**
|
||||
|
||||
- Step back to analyze the structure and logic of current approach
|
||||
- Question the format and methodology being used
|
||||
- Suggest alternative frameworks or mental models
|
||||
@@ -8698,24 +8660,28 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Advanced 2025 Techniques
|
||||
|
||||
**Self-Consistency Validation**
|
||||
|
||||
- Generate multiple reasoning paths for same problem
|
||||
- Compare consistency across different approaches
|
||||
- Identify most reliable and robust solution
|
||||
- Highlight areas where approaches diverge and why
|
||||
|
||||
**ReWOO (Reasoning Without Observation)**
|
||||
|
||||
- Separate parametric reasoning from tool-based actions
|
||||
- Create reasoning plan without external dependencies
|
||||
- Identify what can be solved through pure reasoning
|
||||
- Optimize for efficiency and reduced token usage
|
||||
|
||||
**Persona-Pattern Hybrid**
|
||||
|
||||
- Combine specific role expertise with elicitation pattern
|
||||
- Architect + Risk Analysis: Deep technical risk assessment
|
||||
- UX Expert + User Journey: End-to-end experience critique
|
||||
- PM + Stakeholder Analysis: Multi-perspective impact review
|
||||
|
||||
**Emergent Collaboration Discovery**
|
||||
|
||||
- Allow multiple perspectives to naturally emerge
|
||||
- Identify unexpected insights from persona interactions
|
||||
- Explore novel combinations of viewpoints
|
||||
@@ -8724,18 +8690,21 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Game-Based Elicitation Methods
|
||||
|
||||
**Red Team vs Blue Team**
|
||||
|
||||
- Red Team: Attack the proposal, find vulnerabilities
|
||||
- Blue Team: Defend and strengthen the approach
|
||||
- Competitive analysis reveals blind spots
|
||||
- Results in more robust, battle-tested solutions
|
||||
|
||||
**Innovation Tournament**
|
||||
|
||||
- Pit multiple alternative approaches against each other
|
||||
- Score each approach across different criteria
|
||||
- Crowd-source evaluation from different personas
|
||||
- Identify winning combination of features
|
||||
|
||||
**Escape Room Challenge**
|
||||
|
||||
- Present content as constraints to work within
|
||||
- Find creative solutions within tight limitations
|
||||
- Identify minimum viable approach
|
||||
@@ -8744,6 +8713,7 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Process Control
|
||||
|
||||
**Proceed / No Further Actions**
|
||||
|
||||
- Acknowledge choice to finalize current work
|
||||
- Accept output as-is or move to next step
|
||||
- Prepare to continue without additional elicitation
|
||||
|
||||
29
dist/agents/bmad-orchestrator.txt
vendored
29
dist/agents/bmad-orchestrator.txt
vendored
@@ -405,7 +405,7 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
|
||||
|
||||
## Instructions
|
||||
|
||||
When entering KB mode (*kb-mode), follow these steps:
|
||||
When entering KB mode (\*kb-mode), follow these steps:
|
||||
|
||||
### 1. Welcome and Guide
|
||||
|
||||
@@ -447,12 +447,12 @@ Or ask me about anything else related to BMad-Method!
|
||||
When user is done or wants to exit KB mode:
|
||||
|
||||
- Summarize key points discussed if helpful
|
||||
- Remind them they can return to KB mode anytime with *kb-mode
|
||||
- Remind them they can return to KB mode anytime with \*kb-mode
|
||||
- Suggest next steps based on what was discussed
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User**: *kb-mode
|
||||
**User**: \*kb-mode
|
||||
|
||||
**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
|
||||
|
||||
@@ -1128,8 +1128,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
|
||||
|
||||
```markdown
|
||||
## Goals and Background Context
|
||||
|
||||
## Requirements
|
||||
|
||||
## User Interface Design Goals
|
||||
|
||||
## Success Metrics
|
||||
```
|
||||
|
||||
@@ -1286,16 +1289,19 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Core Reflective Methods
|
||||
|
||||
**Expand or Contract for Audience**
|
||||
|
||||
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
|
||||
- Identify specific target audience if relevant
|
||||
- Tailor content complexity and depth accordingly
|
||||
|
||||
**Explain Reasoning (CoT Step-by-Step)**
|
||||
|
||||
- Walk through the step-by-step thinking process
|
||||
- Reveal underlying assumptions and decision points
|
||||
- Show how conclusions were reached from current role's perspective
|
||||
|
||||
**Critique and Refine**
|
||||
|
||||
- Review output for flaws, inconsistencies, or improvement areas
|
||||
- Identify specific weaknesses from role's expertise
|
||||
- Suggest refined version reflecting domain knowledge
|
||||
@@ -1303,12 +1309,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Structural Analysis Methods
|
||||
|
||||
**Analyze Logical Flow and Dependencies**
|
||||
|
||||
- Examine content structure for logical progression
|
||||
- Check internal consistency and coherence
|
||||
- Identify and validate dependencies between elements
|
||||
- Confirm effective ordering and sequencing
|
||||
|
||||
**Assess Alignment with Overall Goals**
|
||||
|
||||
- Evaluate content contribution to stated objectives
|
||||
- Identify any misalignments or gaps
|
||||
- Interpret alignment from specific role's perspective
|
||||
@@ -1317,12 +1325,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Risk and Challenge Methods
|
||||
|
||||
**Identify Potential Risks and Unforeseen Issues**
|
||||
|
||||
- Brainstorm potential risks from role's expertise
|
||||
- Identify overlooked edge cases or scenarios
|
||||
- Anticipate unintended consequences
|
||||
- Highlight implementation challenges
|
||||
|
||||
**Challenge from Critical Perspective**
|
||||
|
||||
- Adopt critical stance on current content
|
||||
- Play devil's advocate from specified viewpoint
|
||||
- Argue against proposal highlighting weaknesses
|
||||
@@ -1331,12 +1341,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Creative Exploration Methods
|
||||
|
||||
**Tree of Thoughts Deep Dive**
|
||||
|
||||
- Break problem into discrete "thoughts" or intermediate steps
|
||||
- Explore multiple reasoning paths simultaneously
|
||||
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
|
||||
- Apply search algorithms (BFS/DFS) to find optimal solution paths
|
||||
|
||||
**Hindsight is 20/20: The 'If Only...' Reflection**
|
||||
|
||||
- Imagine retrospective scenario based on current content
|
||||
- Identify the one "if only we had known/done X..." insight
|
||||
- Describe imagined consequences humorously or dramatically
|
||||
@@ -1345,6 +1357,7 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Multi-Persona Collaboration Methods
|
||||
|
||||
**Agile Team Perspective Shift**
|
||||
|
||||
- Rotate through different Scrum team member viewpoints
|
||||
- Product Owner: Focus on user value and business impact
|
||||
- Scrum Master: Examine process flow and team dynamics
|
||||
@@ -1352,12 +1365,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
- QA: Identify testing scenarios and quality concerns
|
||||
|
||||
**Stakeholder Round Table**
|
||||
|
||||
- Convene virtual meeting with multiple personas
|
||||
- Each persona contributes unique perspective on content
|
||||
- Identify conflicts and synergies between viewpoints
|
||||
- Synthesize insights into actionable recommendations
|
||||
|
||||
**Meta-Prompting Analysis**
|
||||
|
||||
- Step back to analyze the structure and logic of current approach
|
||||
- Question the format and methodology being used
|
||||
- Suggest alternative frameworks or mental models
|
||||
@@ -1366,24 +1381,28 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Advanced 2025 Techniques
|
||||
|
||||
**Self-Consistency Validation**
|
||||
|
||||
- Generate multiple reasoning paths for same problem
|
||||
- Compare consistency across different approaches
|
||||
- Identify most reliable and robust solution
|
||||
- Highlight areas where approaches diverge and why
|
||||
|
||||
**ReWOO (Reasoning Without Observation)**
|
||||
|
||||
- Separate parametric reasoning from tool-based actions
|
||||
- Create reasoning plan without external dependencies
|
||||
- Identify what can be solved through pure reasoning
|
||||
- Optimize for efficiency and reduced token usage
|
||||
|
||||
**Persona-Pattern Hybrid**
|
||||
|
||||
- Combine specific role expertise with elicitation pattern
|
||||
- Architect + Risk Analysis: Deep technical risk assessment
|
||||
- UX Expert + User Journey: End-to-end experience critique
|
||||
- PM + Stakeholder Analysis: Multi-perspective impact review
|
||||
|
||||
**Emergent Collaboration Discovery**
|
||||
|
||||
- Allow multiple perspectives to naturally emerge
|
||||
- Identify unexpected insights from persona interactions
|
||||
- Explore novel combinations of viewpoints
|
||||
@@ -1392,18 +1411,21 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Game-Based Elicitation Methods
|
||||
|
||||
**Red Team vs Blue Team**
|
||||
|
||||
- Red Team: Attack the proposal, find vulnerabilities
|
||||
- Blue Team: Defend and strengthen the approach
|
||||
- Competitive analysis reveals blind spots
|
||||
- Results in more robust, battle-tested solutions
|
||||
|
||||
**Innovation Tournament**
|
||||
|
||||
- Pit multiple alternative approaches against each other
|
||||
- Score each approach across different criteria
|
||||
- Crowd-source evaluation from different personas
|
||||
- Identify winning combination of features
|
||||
|
||||
**Escape Room Challenge**
|
||||
|
||||
- Present content as constraints to work within
|
||||
- Find creative solutions within tight limitations
|
||||
- Identify minimum viable approach
|
||||
@@ -1412,6 +1434,7 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Process Control
|
||||
|
||||
**Proceed / No Further Actions**
|
||||
|
||||
- Acknowledge choice to finalize current work
|
||||
- Accept output as-is or move to next step
|
||||
- Prepare to continue without additional elicitation
|
||||
|
||||
14
dist/agents/dev.txt
vendored
14
dist/agents/dev.txt
vendored
@@ -102,7 +102,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -115,14 +114,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -131,7 +128,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -139,7 +135,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -153,7 +148,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -163,7 +157,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -351,14 +344,12 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
1. **Requirements Met:**
|
||||
|
||||
[[LLM: Be specific - list each requirement and whether it's complete]]
|
||||
|
||||
- [ ] All functional requirements specified in the story are implemented.
|
||||
- [ ] All acceptance criteria defined in the story are met.
|
||||
|
||||
2. **Coding Standards & Project Structure:**
|
||||
|
||||
[[LLM: Code quality matters for maintainability. Check each item carefully]]
|
||||
|
||||
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
|
||||
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
|
||||
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
|
||||
@@ -370,7 +361,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
3. **Testing:**
|
||||
|
||||
[[LLM: Testing proves your code works. Be honest about test coverage]]
|
||||
|
||||
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
||||
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
||||
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
|
||||
@@ -379,14 +369,12 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
4. **Functionality & Verification:**
|
||||
|
||||
[[LLM: Did you actually run and test your code? Be specific about what you tested]]
|
||||
|
||||
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
|
||||
- [ ] Edge cases and potential error conditions considered and handled gracefully.
|
||||
|
||||
5. **Story Administration:**
|
||||
|
||||
[[LLM: Documentation helps the next developer. What should they know?]]
|
||||
|
||||
- [ ] 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.
|
||||
- [ ] 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.
|
||||
@@ -394,7 +382,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
6. **Dependencies, Build & Configuration:**
|
||||
|
||||
[[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
|
||||
|
||||
- [ ] Project builds successfully without errors.
|
||||
- [ ] Project linting passes
|
||||
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
|
||||
@@ -405,7 +392,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
7. **Documentation (If Applicable):**
|
||||
|
||||
[[LLM: Good documentation prevents future confusion. What needs explaining?]]
|
||||
|
||||
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
|
||||
- [ ] User-facing documentation updated, if changes impact users.
|
||||
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
|
||||
|
||||
25
dist/agents/pm.txt
vendored
25
dist/agents/pm.txt
vendored
@@ -304,63 +304,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -529,13 +520,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -897,7 +886,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -910,14 +898,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -926,7 +912,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -934,7 +919,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -948,7 +932,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -958,7 +941,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -1075,13 +1057,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
||||
For each extracted section:
|
||||
|
||||
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
||||
|
||||
- Remove special characters
|
||||
- Replace spaces with dashes
|
||||
- Example: "## Tech Stack" → `tech-stack.md`
|
||||
|
||||
2. **Adjust heading levels**:
|
||||
|
||||
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
||||
- All subsection levels decrease by 1:
|
||||
|
||||
@@ -1966,7 +1946,6 @@ Ask the user if they want to work through the checklist:
|
||||
Create a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall PRD completeness (percentage)
|
||||
- MVP scope appropriateness (Too Large/Just Right/Too Small)
|
||||
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
|
||||
@@ -1974,26 +1953,22 @@ Create a comprehensive validation report that includes:
|
||||
|
||||
2. Category Analysis Table
|
||||
Fill in the actual table with:
|
||||
|
||||
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
|
||||
- Critical Issues: Specific problems that block progress
|
||||
|
||||
3. Top Issues by Priority
|
||||
|
||||
- BLOCKERS: Must fix before architect can proceed
|
||||
- HIGH: Should fix for quality
|
||||
- MEDIUM: Would improve clarity
|
||||
- LOW: Nice to have
|
||||
|
||||
4. MVP Scope Assessment
|
||||
|
||||
- Features that might be cut for true MVP
|
||||
- Missing features that are essential
|
||||
- Complexity concerns
|
||||
- Timeline realism
|
||||
|
||||
5. Technical Readiness
|
||||
|
||||
- Clarity of technical constraints
|
||||
- Identified technical risks
|
||||
- Areas needing architect investigation
|
||||
|
||||
18
dist/agents/po.txt
vendored
18
dist/agents/po.txt
vendored
@@ -110,7 +110,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -123,14 +122,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -139,7 +136,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -147,7 +143,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -161,7 +156,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -171,7 +165,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -288,13 +281,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
||||
For each extracted section:
|
||||
|
||||
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
||||
|
||||
- Remove special characters
|
||||
- Replace spaces with dashes
|
||||
- Example: "## Tech Stack" → `tech-stack.md`
|
||||
|
||||
2. **Adjust heading levels**:
|
||||
|
||||
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
||||
- All subsection levels decrease by 1:
|
||||
|
||||
@@ -745,12 +736,10 @@ PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
@@ -1084,7 +1073,6 @@ Ask the user if they want to work through the checklist:
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
@@ -1094,42 +1082,36 @@ Generate a comprehensive validation report that adapts to project type:
|
||||
2. Project-Specific Analysis
|
||||
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
|
||||
2108
dist/agents/qa.txt
vendored
2108
dist/agents/qa.txt
vendored
File diff suppressed because it is too large
Load Diff
10
dist/agents/sm.txt
vendored
10
dist/agents/sm.txt
vendored
@@ -211,7 +211,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -224,14 +223,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -240,7 +237,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -248,7 +244,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -262,7 +257,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -272,7 +266,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -628,19 +621,16 @@ Note: We don't need every file listed - just the important ones.]]
|
||||
Generate a concise validation report:
|
||||
|
||||
1. Quick Summary
|
||||
|
||||
- Story readiness: READY / NEEDS REVISION / BLOCKED
|
||||
- Clarity score (1-10)
|
||||
- Major gaps identified
|
||||
|
||||
2. Fill in the validation table with:
|
||||
|
||||
- PASS: Requirements clearly met
|
||||
- PARTIAL: Some gaps but workable
|
||||
- FAIL: Critical information missing
|
||||
|
||||
3. Specific Issues (if any)
|
||||
|
||||
- List concrete problems to fix
|
||||
- Suggest specific improvements
|
||||
- Identify any blocking dependencies
|
||||
|
||||
7
dist/agents/ux-expert.txt
vendored
7
dist/agents/ux-expert.txt
vendored
@@ -258,7 +258,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -271,14 +270,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -287,7 +284,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -295,7 +291,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -309,7 +304,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -319,7 +313,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
|
||||
@@ -210,7 +210,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -223,14 +222,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -239,7 +236,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -247,7 +243,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -261,7 +256,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -271,7 +265,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -306,7 +299,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Begin by understanding the game design context and goals. Ask clarifying questions if needed to determine the best approach for game-specific ideation.]]
|
||||
|
||||
1. **Establish Game Context**
|
||||
|
||||
- Understand the game genre or opportunity area
|
||||
- Identify target audience and platform constraints
|
||||
- Determine session goals (concept exploration vs. mechanic refinement)
|
||||
@@ -324,7 +316,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **"What If" Game Scenarios**
|
||||
[[LLM: Generate provocative what-if questions that challenge game design assumptions and expand thinking beyond current genre limitations.]]
|
||||
|
||||
- What if players could rewind time in any genre?
|
||||
- What if the game world reacted to the player's real-world location?
|
||||
- What if failure was more rewarding than success?
|
||||
@@ -333,7 +324,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Cross-Genre Fusion**
|
||||
[[LLM: Help user combine unexpected game genres and mechanics to create unique experiences.]]
|
||||
|
||||
- "How might [genre A] mechanics work in [genre B]?"
|
||||
- Puzzle mechanics in action games
|
||||
- Dating sim elements in strategy games
|
||||
@@ -342,7 +332,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Player Motivation Reversal**
|
||||
[[LLM: Flip traditional player motivations to reveal new gameplay possibilities.]]
|
||||
|
||||
- What if losing was the goal?
|
||||
- What if cooperation was forced in competitive games?
|
||||
- What if players had to help their enemies?
|
||||
@@ -359,7 +348,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **SCAMPER for Game Mechanics**
|
||||
[[LLM: Guide through each SCAMPER prompt specifically for game design.]]
|
||||
|
||||
- **S** = Substitute: What mechanics can be substituted? (walking → flying → swimming)
|
||||
- **C** = Combine: What systems can be merged? (inventory + character growth)
|
||||
- **A** = Adapt: What mechanics from other media? (books, movies, sports)
|
||||
@@ -370,7 +358,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Agency Spectrum**
|
||||
[[LLM: Explore different levels of player control and agency across game systems.]]
|
||||
|
||||
- Full Control: Direct character movement, combat, building
|
||||
- Indirect Control: Setting rules, giving commands, environmental changes
|
||||
- Influence Only: Suggestions, preferences, emotional reactions
|
||||
@@ -378,7 +365,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Temporal Game Design**
|
||||
[[LLM: Explore how time affects gameplay and player experience.]]
|
||||
|
||||
- Real-time vs. turn-based mechanics
|
||||
- Time travel and manipulation
|
||||
- Persistent vs. session-based progress
|
||||
@@ -389,7 +375,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Emotion-First Design**
|
||||
[[LLM: Start with target emotions and work backward to mechanics that create them.]]
|
||||
|
||||
- Target Emotion: Wonder → Mechanics: Discovery, mystery, scale
|
||||
- Target Emotion: Triumph → Mechanics: Challenge, skill growth, recognition
|
||||
- Target Emotion: Connection → Mechanics: Cooperation, shared goals, communication
|
||||
@@ -397,7 +382,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Archetype Brainstorming**
|
||||
[[LLM: Design for different player types and motivations.]]
|
||||
|
||||
- Achievers: Progression, completion, mastery
|
||||
- Explorers: Discovery, secrets, world-building
|
||||
- Socializers: Interaction, cooperation, community
|
||||
@@ -406,7 +390,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Accessibility-First Innovation**
|
||||
[[LLM: Generate ideas that make games more accessible while creating new gameplay.]]
|
||||
|
||||
- Visual impairment considerations leading to audio-focused mechanics
|
||||
- Motor accessibility inspiring one-handed or simplified controls
|
||||
- Cognitive accessibility driving clear feedback and pacing
|
||||
@@ -416,7 +399,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Environmental Storytelling**
|
||||
[[LLM: Brainstorm ways the game world itself tells stories without explicit narrative.]]
|
||||
|
||||
- How does the environment show history?
|
||||
- What do interactive objects reveal about characters?
|
||||
- How can level design communicate mood?
|
||||
@@ -424,7 +406,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player-Generated Narrative**
|
||||
[[LLM: Explore ways players create their own stories through gameplay.]]
|
||||
|
||||
- Emergent storytelling through player choices
|
||||
- Procedural narrative generation
|
||||
- Player-to-player story sharing
|
||||
@@ -432,7 +413,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Genre Expectation Subversion**
|
||||
[[LLM: Identify and deliberately subvert player expectations within genres.]]
|
||||
|
||||
- Fantasy RPG where magic is mundane
|
||||
- Horror game where monsters are friendly
|
||||
- Racing game where going slow is optimal
|
||||
@@ -442,7 +422,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Platform-Specific Design**
|
||||
[[LLM: Generate ideas that leverage unique platform capabilities.]]
|
||||
|
||||
- Mobile: GPS, accelerometer, camera, always-connected
|
||||
- Web: URLs, tabs, social sharing, real-time collaboration
|
||||
- Console: Controllers, TV viewing, couch co-op
|
||||
@@ -450,7 +429,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Constraint-Based Creativity**
|
||||
[[LLM: Use technical or design constraints as creative catalysts.]]
|
||||
|
||||
- One-button games
|
||||
- Games without graphics
|
||||
- Games that play in notification bars
|
||||
@@ -496,19 +474,16 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Guide the brainstorming session with appropriate pacing for game design exploration.]]
|
||||
|
||||
1. **Inspiration Phase** (10-15 min)
|
||||
|
||||
- Reference existing games and mechanics
|
||||
- Explore player experiences and emotions
|
||||
- Gather visual and thematic inspiration
|
||||
|
||||
2. **Divergent Exploration** (25-35 min)
|
||||
|
||||
- Generate many game concepts or mechanics
|
||||
- Use expansion and fusion techniques
|
||||
- Encourage wild and impossible ideas
|
||||
|
||||
3. **Player-Centered Filtering** (15-20 min)
|
||||
|
||||
- Consider target audience reactions
|
||||
- Evaluate emotional impact and engagement
|
||||
- Group ideas by player experience goals
|
||||
@@ -629,63 +604,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -854,13 +820,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -918,7 +882,6 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
|
||||
|
||||
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
|
||||
|
||||
- The entire section as a whole
|
||||
- Individual game elements within the section (specify which element when selecting an action)
|
||||
|
||||
|
||||
@@ -113,7 +113,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -126,14 +125,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -142,7 +139,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -150,7 +146,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -164,7 +159,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -174,7 +168,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -1359,7 +1352,9 @@ class InputManager {
|
||||
}
|
||||
|
||||
private setupKeyboard(): void {
|
||||
this.keys = this.scene.input.keyboard.addKeys("W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT");
|
||||
this.keys = this.scene.input.keyboard.addKeys(
|
||||
"W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT",
|
||||
);
|
||||
}
|
||||
|
||||
private setupTouch(): void {
|
||||
@@ -1564,25 +1559,21 @@ src/
|
||||
### Story Implementation Process
|
||||
|
||||
1. **Read Story Requirements:**
|
||||
|
||||
- Understand acceptance criteria
|
||||
- Identify technical requirements
|
||||
- Review performance constraints
|
||||
|
||||
2. **Plan Implementation:**
|
||||
|
||||
- Identify files to create/modify
|
||||
- Consider component architecture
|
||||
- Plan testing approach
|
||||
|
||||
3. **Implement Feature:**
|
||||
|
||||
- Follow TypeScript strict mode
|
||||
- Use established patterns
|
||||
- Maintain 60 FPS performance
|
||||
|
||||
4. **Test Implementation:**
|
||||
|
||||
- Write unit tests for game logic
|
||||
- Test cross-platform functionality
|
||||
- Validate performance targets
|
||||
|
||||
@@ -318,7 +318,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -331,14 +330,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -347,7 +344,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -355,7 +351,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -369,7 +364,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -379,7 +373,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
|
||||
@@ -580,63 +580,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -805,13 +796,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -973,7 +962,6 @@ User can type `#yolo` to toggle to YOLO mode (process all sections at once).
|
||||
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
|
||||
|
||||
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
|
||||
|
||||
- The entire section as a whole
|
||||
- Individual game elements within the section (specify which element when selecting an action)
|
||||
|
||||
@@ -1181,7 +1169,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| ------ | ------- | --------------------------- | --------- |
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
@@ -1206,7 +1194,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Actual Tech Stack (from package.json/requirements.txt)
|
||||
|
||||
| Category | Technology | Version | Notes |
|
||||
|----------|------------|---------|--------|
|
||||
| --------- | ---------- | ------- | -------------------------- |
|
||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||
@@ -1248,6 +1236,7 @@ project-root/
|
||||
### Data Models
|
||||
|
||||
Instead of duplicating, reference actual model files:
|
||||
|
||||
- **User Model**: See `src/models/User.js`
|
||||
- **Order Model**: See `src/models/Order.js`
|
||||
- **Related Types**: TypeScript definitions in `src/types/`
|
||||
@@ -1278,7 +1267,7 @@ Instead of duplicating, reference actual model files:
|
||||
### External Services
|
||||
|
||||
| Service | Purpose | Integration Type | Key Files |
|
||||
|---------|---------|------------------|-----------|
|
||||
| -------- | -------- | ---------------- | ------------------------------ |
|
||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||
|
||||
@@ -1325,6 +1314,7 @@ npm run test:integration # Runs integration tests (requires local DB)
|
||||
### Files That Will Need Modification
|
||||
|
||||
Based on the enhancement requirements, these files will be affected:
|
||||
|
||||
- `src/services/userService.js` - Add new user fields
|
||||
- `src/models/User.js` - Update schema
|
||||
- `src/routes/userRoutes.js` - New endpoints
|
||||
@@ -2386,13 +2376,11 @@ You are developing games as a "Player Experience CEO" - thinking like a game dir
|
||||
### Phase 1: Game Concept and Design
|
||||
|
||||
1. **Game Designer**: Start with brainstorming and concept development
|
||||
|
||||
- Use \*brainstorm to explore game concepts and mechanics
|
||||
- Create Game Brief using game-brief-tmpl
|
||||
- Develop core game pillars and player experience goals
|
||||
|
||||
2. **Game Designer**: Create comprehensive Game Design Document
|
||||
|
||||
- Use game-design-doc-tmpl to create detailed GDD
|
||||
- Define all game mechanics, progression, and balance
|
||||
- Specify technical requirements and platform targets
|
||||
@@ -2412,13 +2400,11 @@ You are developing games as a "Player Experience CEO" - thinking like a game dir
|
||||
### Phase 3: Story-Driven Development
|
||||
|
||||
5. **Game Scrum Master**: Break down design into development stories
|
||||
|
||||
- Use create-game-story task to create detailed implementation stories
|
||||
- Each story should be immediately actionable by game developers
|
||||
- Apply game-story-dod-checklist to ensure story quality
|
||||
|
||||
6. **Game Developer**: Implement game features story by story
|
||||
|
||||
- Follow TypeScript strict mode and Phaser 3 best practices
|
||||
- Maintain 60 FPS performance target throughout development
|
||||
- Use test-driven development for game logic components
|
||||
@@ -2649,7 +2635,7 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
|
||||
|
||||
## Instructions
|
||||
|
||||
When entering KB mode (*kb-mode), follow these steps:
|
||||
When entering KB mode (\*kb-mode), follow these steps:
|
||||
|
||||
### 1. Welcome and Guide
|
||||
|
||||
@@ -2691,12 +2677,12 @@ Or ask me about anything else related to BMad-Method!
|
||||
When user is done or wants to exit KB mode:
|
||||
|
||||
- Summarize key points discussed if helpful
|
||||
- Remind them they can return to KB mode anytime with *kb-mode
|
||||
- Remind them they can return to KB mode anytime with \*kb-mode
|
||||
- Suggest next steps based on what was discussed
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User**: *kb-mode
|
||||
**User**: \*kb-mode
|
||||
|
||||
**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
|
||||
|
||||
@@ -2724,16 +2710,19 @@ Or ask me about anything else related to BMad-Method!
|
||||
## Core Reflective Methods
|
||||
|
||||
**Expand or Contract for Audience**
|
||||
|
||||
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
|
||||
- Identify specific target audience if relevant
|
||||
- Tailor content complexity and depth accordingly
|
||||
|
||||
**Explain Reasoning (CoT Step-by-Step)**
|
||||
|
||||
- Walk through the step-by-step thinking process
|
||||
- Reveal underlying assumptions and decision points
|
||||
- Show how conclusions were reached from current role's perspective
|
||||
|
||||
**Critique and Refine**
|
||||
|
||||
- Review output for flaws, inconsistencies, or improvement areas
|
||||
- Identify specific weaknesses from role's expertise
|
||||
- Suggest refined version reflecting domain knowledge
|
||||
@@ -2741,12 +2730,14 @@ Or ask me about anything else related to BMad-Method!
|
||||
## Structural Analysis Methods
|
||||
|
||||
**Analyze Logical Flow and Dependencies**
|
||||
|
||||
- Examine content structure for logical progression
|
||||
- Check internal consistency and coherence
|
||||
- Identify and validate dependencies between elements
|
||||
- Confirm effective ordering and sequencing
|
||||
|
||||
**Assess Alignment with Overall Goals**
|
||||
|
||||
- Evaluate content contribution to stated objectives
|
||||
- Identify any misalignments or gaps
|
||||
- Interpret alignment from specific role's perspective
|
||||
@@ -2755,12 +2746,14 @@ Or ask me about anything else related to BMad-Method!
|
||||
## Risk and Challenge Methods
|
||||
|
||||
**Identify Potential Risks and Unforeseen Issues**
|
||||
|
||||
- Brainstorm potential risks from role's expertise
|
||||
- Identify overlooked edge cases or scenarios
|
||||
- Anticipate unintended consequences
|
||||
- Highlight implementation challenges
|
||||
|
||||
**Challenge from Critical Perspective**
|
||||
|
||||
- Adopt critical stance on current content
|
||||
- Play devil's advocate from specified viewpoint
|
||||
- Argue against proposal highlighting weaknesses
|
||||
@@ -2769,12 +2762,14 @@ Or ask me about anything else related to BMad-Method!
|
||||
## Creative Exploration Methods
|
||||
|
||||
**Tree of Thoughts Deep Dive**
|
||||
|
||||
- Break problem into discrete "thoughts" or intermediate steps
|
||||
- Explore multiple reasoning paths simultaneously
|
||||
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
|
||||
- Apply search algorithms (BFS/DFS) to find optimal solution paths
|
||||
|
||||
**Hindsight is 20/20: The 'If Only...' Reflection**
|
||||
|
||||
- Imagine retrospective scenario based on current content
|
||||
- Identify the one "if only we had known/done X..." insight
|
||||
- Describe imagined consequences humorously or dramatically
|
||||
@@ -2783,6 +2778,7 @@ Or ask me about anything else related to BMad-Method!
|
||||
## Multi-Persona Collaboration Methods
|
||||
|
||||
**Agile Team Perspective Shift**
|
||||
|
||||
- Rotate through different Scrum team member viewpoints
|
||||
- Product Owner: Focus on user value and business impact
|
||||
- Scrum Master: Examine process flow and team dynamics
|
||||
@@ -2790,12 +2786,14 @@ Or ask me about anything else related to BMad-Method!
|
||||
- QA: Identify testing scenarios and quality concerns
|
||||
|
||||
**Stakeholder Round Table**
|
||||
|
||||
- Convene virtual meeting with multiple personas
|
||||
- Each persona contributes unique perspective on content
|
||||
- Identify conflicts and synergies between viewpoints
|
||||
- Synthesize insights into actionable recommendations
|
||||
|
||||
**Meta-Prompting Analysis**
|
||||
|
||||
- Step back to analyze the structure and logic of current approach
|
||||
- Question the format and methodology being used
|
||||
- Suggest alternative frameworks or mental models
|
||||
@@ -2804,24 +2802,28 @@ Or ask me about anything else related to BMad-Method!
|
||||
## Advanced 2025 Techniques
|
||||
|
||||
**Self-Consistency Validation**
|
||||
|
||||
- Generate multiple reasoning paths for same problem
|
||||
- Compare consistency across different approaches
|
||||
- Identify most reliable and robust solution
|
||||
- Highlight areas where approaches diverge and why
|
||||
|
||||
**ReWOO (Reasoning Without Observation)**
|
||||
|
||||
- Separate parametric reasoning from tool-based actions
|
||||
- Create reasoning plan without external dependencies
|
||||
- Identify what can be solved through pure reasoning
|
||||
- Optimize for efficiency and reduced token usage
|
||||
|
||||
**Persona-Pattern Hybrid**
|
||||
|
||||
- Combine specific role expertise with elicitation pattern
|
||||
- Architect + Risk Analysis: Deep technical risk assessment
|
||||
- UX Expert + User Journey: End-to-end experience critique
|
||||
- PM + Stakeholder Analysis: Multi-perspective impact review
|
||||
|
||||
**Emergent Collaboration Discovery**
|
||||
|
||||
- Allow multiple perspectives to naturally emerge
|
||||
- Identify unexpected insights from persona interactions
|
||||
- Explore novel combinations of viewpoints
|
||||
@@ -2830,18 +2832,21 @@ Or ask me about anything else related to BMad-Method!
|
||||
## Game-Based Elicitation Methods
|
||||
|
||||
**Red Team vs Blue Team**
|
||||
|
||||
- Red Team: Attack the proposal, find vulnerabilities
|
||||
- Blue Team: Defend and strengthen the approach
|
||||
- Competitive analysis reveals blind spots
|
||||
- Results in more robust, battle-tested solutions
|
||||
|
||||
**Innovation Tournament**
|
||||
|
||||
- Pit multiple alternative approaches against each other
|
||||
- Score each approach across different criteria
|
||||
- Crowd-source evaluation from different personas
|
||||
- Identify winning combination of features
|
||||
|
||||
**Escape Room Challenge**
|
||||
|
||||
- Present content as constraints to work within
|
||||
- Find creative solutions within tight limitations
|
||||
- Identify minimum viable approach
|
||||
@@ -2850,6 +2855,7 @@ Or ask me about anything else related to BMad-Method!
|
||||
## Process Control
|
||||
|
||||
**Proceed / No Further Actions**
|
||||
|
||||
- Acknowledge choice to finalize current work
|
||||
- Accept output as-is or move to next step
|
||||
- Prepare to continue without additional elicitation
|
||||
@@ -2939,7 +2945,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -2952,14 +2957,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -2968,7 +2971,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -2976,7 +2978,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -2990,7 +2991,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -3000,7 +3000,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -3035,7 +3034,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Begin by understanding the game design context and goals. Ask clarifying questions if needed to determine the best approach for game-specific ideation.]]
|
||||
|
||||
1. **Establish Game Context**
|
||||
|
||||
- Understand the game genre or opportunity area
|
||||
- Identify target audience and platform constraints
|
||||
- Determine session goals (concept exploration vs. mechanic refinement)
|
||||
@@ -3053,7 +3051,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **"What If" Game Scenarios**
|
||||
[[LLM: Generate provocative what-if questions that challenge game design assumptions and expand thinking beyond current genre limitations.]]
|
||||
|
||||
- What if players could rewind time in any genre?
|
||||
- What if the game world reacted to the player's real-world location?
|
||||
- What if failure was more rewarding than success?
|
||||
@@ -3062,7 +3059,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Cross-Genre Fusion**
|
||||
[[LLM: Help user combine unexpected game genres and mechanics to create unique experiences.]]
|
||||
|
||||
- "How might [genre A] mechanics work in [genre B]?"
|
||||
- Puzzle mechanics in action games
|
||||
- Dating sim elements in strategy games
|
||||
@@ -3071,7 +3067,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Player Motivation Reversal**
|
||||
[[LLM: Flip traditional player motivations to reveal new gameplay possibilities.]]
|
||||
|
||||
- What if losing was the goal?
|
||||
- What if cooperation was forced in competitive games?
|
||||
- What if players had to help their enemies?
|
||||
@@ -3088,7 +3083,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **SCAMPER for Game Mechanics**
|
||||
[[LLM: Guide through each SCAMPER prompt specifically for game design.]]
|
||||
|
||||
- **S** = Substitute: What mechanics can be substituted? (walking → flying → swimming)
|
||||
- **C** = Combine: What systems can be merged? (inventory + character growth)
|
||||
- **A** = Adapt: What mechanics from other media? (books, movies, sports)
|
||||
@@ -3099,7 +3093,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Agency Spectrum**
|
||||
[[LLM: Explore different levels of player control and agency across game systems.]]
|
||||
|
||||
- Full Control: Direct character movement, combat, building
|
||||
- Indirect Control: Setting rules, giving commands, environmental changes
|
||||
- Influence Only: Suggestions, preferences, emotional reactions
|
||||
@@ -3107,7 +3100,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Temporal Game Design**
|
||||
[[LLM: Explore how time affects gameplay and player experience.]]
|
||||
|
||||
- Real-time vs. turn-based mechanics
|
||||
- Time travel and manipulation
|
||||
- Persistent vs. session-based progress
|
||||
@@ -3118,7 +3110,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Emotion-First Design**
|
||||
[[LLM: Start with target emotions and work backward to mechanics that create them.]]
|
||||
|
||||
- Target Emotion: Wonder → Mechanics: Discovery, mystery, scale
|
||||
- Target Emotion: Triumph → Mechanics: Challenge, skill growth, recognition
|
||||
- Target Emotion: Connection → Mechanics: Cooperation, shared goals, communication
|
||||
@@ -3126,7 +3117,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Archetype Brainstorming**
|
||||
[[LLM: Design for different player types and motivations.]]
|
||||
|
||||
- Achievers: Progression, completion, mastery
|
||||
- Explorers: Discovery, secrets, world-building
|
||||
- Socializers: Interaction, cooperation, community
|
||||
@@ -3135,7 +3125,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Accessibility-First Innovation**
|
||||
[[LLM: Generate ideas that make games more accessible while creating new gameplay.]]
|
||||
|
||||
- Visual impairment considerations leading to audio-focused mechanics
|
||||
- Motor accessibility inspiring one-handed or simplified controls
|
||||
- Cognitive accessibility driving clear feedback and pacing
|
||||
@@ -3145,7 +3134,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Environmental Storytelling**
|
||||
[[LLM: Brainstorm ways the game world itself tells stories without explicit narrative.]]
|
||||
|
||||
- How does the environment show history?
|
||||
- What do interactive objects reveal about characters?
|
||||
- How can level design communicate mood?
|
||||
@@ -3153,7 +3141,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player-Generated Narrative**
|
||||
[[LLM: Explore ways players create their own stories through gameplay.]]
|
||||
|
||||
- Emergent storytelling through player choices
|
||||
- Procedural narrative generation
|
||||
- Player-to-player story sharing
|
||||
@@ -3161,7 +3148,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Genre Expectation Subversion**
|
||||
[[LLM: Identify and deliberately subvert player expectations within genres.]]
|
||||
|
||||
- Fantasy RPG where magic is mundane
|
||||
- Horror game where monsters are friendly
|
||||
- Racing game where going slow is optimal
|
||||
@@ -3171,7 +3157,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Platform-Specific Design**
|
||||
[[LLM: Generate ideas that leverage unique platform capabilities.]]
|
||||
|
||||
- Mobile: GPS, accelerometer, camera, always-connected
|
||||
- Web: URLs, tabs, social sharing, real-time collaboration
|
||||
- Console: Controllers, TV viewing, couch co-op
|
||||
@@ -3179,7 +3164,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Constraint-Based Creativity**
|
||||
[[LLM: Use technical or design constraints as creative catalysts.]]
|
||||
|
||||
- One-button games
|
||||
- Games without graphics
|
||||
- Games that play in notification bars
|
||||
@@ -3225,19 +3209,16 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Guide the brainstorming session with appropriate pacing for game design exploration.]]
|
||||
|
||||
1. **Inspiration Phase** (10-15 min)
|
||||
|
||||
- Reference existing games and mechanics
|
||||
- Explore player experiences and emotions
|
||||
- Gather visual and thematic inspiration
|
||||
|
||||
2. **Divergent Exploration** (25-35 min)
|
||||
|
||||
- Generate many game concepts or mechanics
|
||||
- Use expansion and fusion techniques
|
||||
- Encourage wild and impossible ideas
|
||||
|
||||
3. **Player-Centered Filtering** (15-20 min)
|
||||
|
||||
- Consider target audience reactions
|
||||
- Evaluate emotional impact and engagement
|
||||
- Group ideas by player experience goals
|
||||
@@ -5892,7 +5873,9 @@ class InputManager {
|
||||
}
|
||||
|
||||
private setupKeyboard(): void {
|
||||
this.keys = this.scene.input.keyboard.addKeys("W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT");
|
||||
this.keys = this.scene.input.keyboard.addKeys(
|
||||
"W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT",
|
||||
);
|
||||
}
|
||||
|
||||
private setupTouch(): void {
|
||||
@@ -6097,25 +6080,21 @@ src/
|
||||
### Story Implementation Process
|
||||
|
||||
1. **Read Story Requirements:**
|
||||
|
||||
- Understand acceptance criteria
|
||||
- Identify technical requirements
|
||||
- Review performance constraints
|
||||
|
||||
2. **Plan Implementation:**
|
||||
|
||||
- Identify files to create/modify
|
||||
- Consider component architecture
|
||||
- Plan testing approach
|
||||
|
||||
3. **Implement Feature:**
|
||||
|
||||
- Follow TypeScript strict mode
|
||||
- Use established patterns
|
||||
- Maintain 60 FPS performance
|
||||
|
||||
4. **Test Implementation:**
|
||||
|
||||
- Write unit tests for game logic
|
||||
- Test cross-platform functionality
|
||||
- Validate performance targets
|
||||
@@ -8723,7 +8702,6 @@ sections:
|
||||
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
|
||||
|
||||
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
|
||||
|
||||
- The entire section as a whole
|
||||
- Individual game elements within the section (specify which element when selecting an action)
|
||||
|
||||
@@ -9047,7 +9025,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Begin by understanding the game design context and goals. Ask clarifying questions if needed to determine the best approach for game-specific ideation.]]
|
||||
|
||||
1. **Establish Game Context**
|
||||
|
||||
- Understand the game genre or opportunity area
|
||||
- Identify target audience and platform constraints
|
||||
- Determine session goals (concept exploration vs. mechanic refinement)
|
||||
@@ -9065,7 +9042,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **"What If" Game Scenarios**
|
||||
[[LLM: Generate provocative what-if questions that challenge game design assumptions and expand thinking beyond current genre limitations.]]
|
||||
|
||||
- What if players could rewind time in any genre?
|
||||
- What if the game world reacted to the player's real-world location?
|
||||
- What if failure was more rewarding than success?
|
||||
@@ -9074,7 +9050,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Cross-Genre Fusion**
|
||||
[[LLM: Help user combine unexpected game genres and mechanics to create unique experiences.]]
|
||||
|
||||
- "How might [genre A] mechanics work in [genre B]?"
|
||||
- Puzzle mechanics in action games
|
||||
- Dating sim elements in strategy games
|
||||
@@ -9083,7 +9058,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Player Motivation Reversal**
|
||||
[[LLM: Flip traditional player motivations to reveal new gameplay possibilities.]]
|
||||
|
||||
- What if losing was the goal?
|
||||
- What if cooperation was forced in competitive games?
|
||||
- What if players had to help their enemies?
|
||||
@@ -9100,7 +9074,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **SCAMPER for Game Mechanics**
|
||||
[[LLM: Guide through each SCAMPER prompt specifically for game design.]]
|
||||
|
||||
- **S** = Substitute: What mechanics can be substituted? (walking → flying → swimming)
|
||||
- **C** = Combine: What systems can be merged? (inventory + character growth)
|
||||
- **A** = Adapt: What mechanics from other media? (books, movies, sports)
|
||||
@@ -9111,7 +9084,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Agency Spectrum**
|
||||
[[LLM: Explore different levels of player control and agency across game systems.]]
|
||||
|
||||
- Full Control: Direct character movement, combat, building
|
||||
- Indirect Control: Setting rules, giving commands, environmental changes
|
||||
- Influence Only: Suggestions, preferences, emotional reactions
|
||||
@@ -9119,7 +9091,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Temporal Game Design**
|
||||
[[LLM: Explore how time affects gameplay and player experience.]]
|
||||
|
||||
- Real-time vs. turn-based mechanics
|
||||
- Time travel and manipulation
|
||||
- Persistent vs. session-based progress
|
||||
@@ -9130,7 +9101,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Emotion-First Design**
|
||||
[[LLM: Start with target emotions and work backward to mechanics that create them.]]
|
||||
|
||||
- Target Emotion: Wonder → Mechanics: Discovery, mystery, scale
|
||||
- Target Emotion: Triumph → Mechanics: Challenge, skill growth, recognition
|
||||
- Target Emotion: Connection → Mechanics: Cooperation, shared goals, communication
|
||||
@@ -9138,7 +9108,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Archetype Brainstorming**
|
||||
[[LLM: Design for different player types and motivations.]]
|
||||
|
||||
- Achievers: Progression, completion, mastery
|
||||
- Explorers: Discovery, secrets, world-building
|
||||
- Socializers: Interaction, cooperation, community
|
||||
@@ -9147,7 +9116,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Accessibility-First Innovation**
|
||||
[[LLM: Generate ideas that make games more accessible while creating new gameplay.]]
|
||||
|
||||
- Visual impairment considerations leading to audio-focused mechanics
|
||||
- Motor accessibility inspiring one-handed or simplified controls
|
||||
- Cognitive accessibility driving clear feedback and pacing
|
||||
@@ -9157,7 +9125,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Environmental Storytelling**
|
||||
[[LLM: Brainstorm ways the game world itself tells stories without explicit narrative.]]
|
||||
|
||||
- How does the environment show history?
|
||||
- What do interactive objects reveal about characters?
|
||||
- How can level design communicate mood?
|
||||
@@ -9165,7 +9132,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player-Generated Narrative**
|
||||
[[LLM: Explore ways players create their own stories through gameplay.]]
|
||||
|
||||
- Emergent storytelling through player choices
|
||||
- Procedural narrative generation
|
||||
- Player-to-player story sharing
|
||||
@@ -9173,7 +9139,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Genre Expectation Subversion**
|
||||
[[LLM: Identify and deliberately subvert player expectations within genres.]]
|
||||
|
||||
- Fantasy RPG where magic is mundane
|
||||
- Horror game where monsters are friendly
|
||||
- Racing game where going slow is optimal
|
||||
@@ -9183,7 +9148,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Platform-Specific Design**
|
||||
[[LLM: Generate ideas that leverage unique platform capabilities.]]
|
||||
|
||||
- Mobile: GPS, accelerometer, camera, always-connected
|
||||
- Web: URLs, tabs, social sharing, real-time collaboration
|
||||
- Console: Controllers, TV viewing, couch co-op
|
||||
@@ -9191,7 +9155,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Constraint-Based Creativity**
|
||||
[[LLM: Use technical or design constraints as creative catalysts.]]
|
||||
|
||||
- One-button games
|
||||
- Games without graphics
|
||||
- Games that play in notification bars
|
||||
@@ -9237,19 +9200,16 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Guide the brainstorming session with appropriate pacing for game design exploration.]]
|
||||
|
||||
1. **Inspiration Phase** (10-15 min)
|
||||
|
||||
- Reference existing games and mechanics
|
||||
- Explore player experiences and emotions
|
||||
- Gather visual and thematic inspiration
|
||||
|
||||
2. **Divergent Exploration** (25-35 min)
|
||||
|
||||
- Generate many game concepts or mechanics
|
||||
- Use expansion and fusion techniques
|
||||
- Encourage wild and impossible ideas
|
||||
|
||||
3. **Player-Centered Filtering** (15-20 min)
|
||||
|
||||
- Consider target audience reactions
|
||||
- Evaluate emotional impact and engagement
|
||||
- Group ideas by player experience goals
|
||||
@@ -10119,13 +10079,11 @@ You are developing games as a "Player Experience CEO" - thinking like a game dir
|
||||
### Phase 1: Game Concept and Design
|
||||
|
||||
1. **Game Designer**: Start with brainstorming and concept development
|
||||
|
||||
- Use \*brainstorm to explore game concepts and mechanics
|
||||
- Create Game Brief using game-brief-tmpl
|
||||
- Develop core game pillars and player experience goals
|
||||
|
||||
2. **Game Designer**: Create comprehensive Game Design Document
|
||||
|
||||
- Use game-design-doc-tmpl to create detailed GDD
|
||||
- Define all game mechanics, progression, and balance
|
||||
- Specify technical requirements and platform targets
|
||||
@@ -10145,13 +10103,11 @@ You are developing games as a "Player Experience CEO" - thinking like a game dir
|
||||
### Phase 3: Story-Driven Development
|
||||
|
||||
5. **Game Scrum Master**: Break down design into development stories
|
||||
|
||||
- Use create-game-story task to create detailed implementation stories
|
||||
- Each story should be immediately actionable by game developers
|
||||
- Apply game-story-dod-checklist to ensure story quality
|
||||
|
||||
6. **Game Developer**: Implement game features story by story
|
||||
|
||||
- Follow TypeScript strict mode and Phaser 3 best practices
|
||||
- Maintain 60 FPS performance target throughout development
|
||||
- Use test-driven development for game logic components
|
||||
@@ -10717,7 +10673,9 @@ class InputManager {
|
||||
}
|
||||
|
||||
private setupKeyboard(): void {
|
||||
this.keys = this.scene.input.keyboard.addKeys("W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT");
|
||||
this.keys = this.scene.input.keyboard.addKeys(
|
||||
"W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT",
|
||||
);
|
||||
}
|
||||
|
||||
private setupTouch(): void {
|
||||
@@ -10922,25 +10880,21 @@ src/
|
||||
### Story Implementation Process
|
||||
|
||||
1. **Read Story Requirements:**
|
||||
|
||||
- Understand acceptance criteria
|
||||
- Identify technical requirements
|
||||
- Review performance constraints
|
||||
|
||||
2. **Plan Implementation:**
|
||||
|
||||
- Identify files to create/modify
|
||||
- Consider component architecture
|
||||
- Plan testing approach
|
||||
|
||||
3. **Implement Feature:**
|
||||
|
||||
- Follow TypeScript strict mode
|
||||
- Use established patterns
|
||||
- Maintain 60 FPS performance
|
||||
|
||||
4. **Test Implementation:**
|
||||
|
||||
- Write unit tests for game logic
|
||||
- Test cross-platform functionality
|
||||
- Validate performance targets
|
||||
|
||||
@@ -230,63 +230,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -455,13 +446,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -592,13 +581,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
||||
For each extracted section:
|
||||
|
||||
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
||||
|
||||
- Remove special characters
|
||||
- Replace spaces with dashes
|
||||
- Example: "## Tech Stack" → `tech-stack.md`
|
||||
|
||||
2. **Adjust heading levels**:
|
||||
|
||||
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
||||
- All subsection levels decrease by 1:
|
||||
|
||||
@@ -803,7 +790,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| ------ | ------- | --------------------------- | --------- |
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
@@ -828,7 +815,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Actual Tech Stack (from package.json/requirements.txt)
|
||||
|
||||
| Category | Technology | Version | Notes |
|
||||
|----------|------------|---------|--------|
|
||||
| --------- | ---------- | ------- | -------------------------- |
|
||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||
@@ -870,6 +857,7 @@ project-root/
|
||||
### Data Models
|
||||
|
||||
Instead of duplicating, reference actual model files:
|
||||
|
||||
- **User Model**: See `src/models/User.js`
|
||||
- **Order Model**: See `src/models/Order.js`
|
||||
- **Related Types**: TypeScript definitions in `src/types/`
|
||||
@@ -900,7 +888,7 @@ Instead of duplicating, reference actual model files:
|
||||
### External Services
|
||||
|
||||
| Service | Purpose | Integration Type | Key Files |
|
||||
|---------|---------|------------------|-----------|
|
||||
| -------- | -------- | ---------------- | ------------------------------ |
|
||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||
|
||||
@@ -947,6 +935,7 @@ npm run test:integration # Runs integration tests (requires local DB)
|
||||
### Files That Will Need Modification
|
||||
|
||||
Based on the enhancement requirements, these files will be affected:
|
||||
|
||||
- `src/services/userService.js` - Add new user fields
|
||||
- `src/models/User.js` - Update schema
|
||||
- `src/routes/userRoutes.js` - New endpoints
|
||||
@@ -1044,7 +1033,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -1057,14 +1045,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -1073,7 +1059,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -1081,7 +1066,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -1095,7 +1079,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -1105,7 +1088,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -1149,7 +1131,6 @@ The LLM will:
|
||||
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
|
||||
|
||||
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
|
||||
|
||||
- The entire section as a whole
|
||||
- Individual game elements within the section (specify which element when selecting an action)
|
||||
|
||||
@@ -2633,34 +2614,29 @@ Ask the user if they want to work through the checklist:
|
||||
Generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall game architecture readiness (High/Medium/Low)
|
||||
- Critical risks for game development
|
||||
- Key strengths of the game architecture
|
||||
- Unity-specific assessment
|
||||
|
||||
2. Game Systems Analysis
|
||||
|
||||
- Pass rate for each major system section
|
||||
- Most concerning gaps in game architecture
|
||||
- Systems requiring immediate attention
|
||||
- Unity integration completeness
|
||||
|
||||
3. Performance Risk Assessment
|
||||
|
||||
- Top 5 performance risks for the game
|
||||
- Mobile platform specific concerns
|
||||
- Frame rate stability risks
|
||||
- Memory usage concerns
|
||||
|
||||
4. Implementation Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Unity-specific improvements needed
|
||||
- Game development workflow enhancements
|
||||
|
||||
5. AI Agent Implementation Readiness
|
||||
|
||||
- Game-specific concerns for AI implementation
|
||||
- Unity component complexity assessment
|
||||
- Areas needing additional clarification
|
||||
@@ -3208,25 +3184,21 @@ Assets/
|
||||
### Story Implementation Process
|
||||
|
||||
1. **Read Story Requirements:**
|
||||
|
||||
- Understand acceptance criteria
|
||||
- Identify technical requirements
|
||||
- Review performance constraints
|
||||
|
||||
2. **Plan Implementation:**
|
||||
|
||||
- Identify files to create/modify
|
||||
- Consider Unity's component-based architecture
|
||||
- Plan testing approach
|
||||
|
||||
3. **Implement Feature:**
|
||||
|
||||
- Write clean C# code following all guidelines
|
||||
- Use established patterns
|
||||
- Maintain stable FPS performance
|
||||
|
||||
4. **Test Implementation:**
|
||||
|
||||
- Write edit mode tests for game logic
|
||||
- Write play mode tests for integration testing
|
||||
- Test cross-platform functionality
|
||||
@@ -3540,7 +3512,6 @@ that can handle [specific game requirements] with stable performance."
|
||||
**Prerequisites**: Game planning documents must exist in `docs/` folder of Unity project
|
||||
|
||||
1. **Document Sharding** (CRITICAL STEP for Game Development):
|
||||
|
||||
- Documents created by Game Designer/Architect (in Web or IDE) MUST be sharded for development
|
||||
- Use core BMad agents or tools to shard:
|
||||
a) **Manual**: Use core BMad `shard-doc` task if available
|
||||
@@ -3563,20 +3534,17 @@ Resulting Unity Project Folder Structure:
|
||||
3. **Game Development Cycle** (Sequential, one game story at a time):
|
||||
|
||||
**CRITICAL CONTEXT MANAGEMENT for Unity Development**:
|
||||
|
||||
- **Context windows matter!** Always use fresh, clean context windows
|
||||
- **Model selection matters!** Use most powerful thinking model for Game SM story creation
|
||||
- **ALWAYS start new chat between Game SM, Game Dev, and QA work**
|
||||
|
||||
**Step 1 - Game Story Creation**:
|
||||
|
||||
- **NEW CLEAN CHAT** → Select powerful model → `/bmad2du/game-sm` → `*draft`
|
||||
- Game SM executes create-game-story task using `game-story-tmpl`
|
||||
- Review generated story in `docs/game-stories/`
|
||||
- Update status from "Draft" to "Approved"
|
||||
|
||||
**Step 2 - Unity Game Story Implementation**:
|
||||
|
||||
- **NEW CLEAN CHAT** → `/bmad2du/game-developer`
|
||||
- Agent asks which game story to implement
|
||||
- Include story file content to save game dev agent lookup time
|
||||
@@ -3585,7 +3553,6 @@ Resulting Unity Project Folder Structure:
|
||||
- Game Dev marks story as "Review" when complete with all Unity tests passing
|
||||
|
||||
**Step 3 - Game QA Review**:
|
||||
|
||||
- **NEW CLEAN CHAT** → Use core `@qa` agent → execute review-story task
|
||||
- QA performs senior Unity developer code review
|
||||
- QA can refactor and improve Unity code directly
|
||||
@@ -3625,14 +3592,12 @@ Since this expansion pack doesn't include specific brownfield templates, you'll
|
||||
|
||||
1. **Upload Unity project to Web UI** (GitHub URL, files, or zip)
|
||||
2. **Create adapted Game Design Document**: `/bmad2du/game-designer` - Modify `game-design-doc-tmpl` to include:
|
||||
|
||||
- Analysis of existing game systems
|
||||
- Integration points for new features
|
||||
- Compatibility requirements
|
||||
- Risk assessment for changes
|
||||
|
||||
3. **Game Architecture Planning**:
|
||||
|
||||
- Use `/bmad2du/game-architect` with `game-architecture-tmpl`
|
||||
- Focus on how new features integrate with existing Unity systems
|
||||
- Plan for gradual rollout and testing
|
||||
|
||||
@@ -215,7 +215,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -228,14 +227,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -244,7 +241,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -252,7 +248,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -266,7 +261,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -276,7 +270,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -393,13 +386,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
||||
For each extracted section:
|
||||
|
||||
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
||||
|
||||
- Remove special characters
|
||||
- Replace spaces with dashes
|
||||
- Example: "## Tech Stack" → `tech-stack.md`
|
||||
|
||||
2. **Adjust heading levels**:
|
||||
|
||||
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
||||
- All subsection levels decrease by 1:
|
||||
|
||||
@@ -501,7 +492,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Begin by understanding the game design context and goals. Ask clarifying questions if needed to determine the best approach for game-specific ideation.]]
|
||||
|
||||
1. **Establish Game Context**
|
||||
|
||||
- Understand the game genre or opportunity area
|
||||
- Identify target audience and platform constraints
|
||||
- Determine session goals (concept exploration vs. mechanic refinement)
|
||||
@@ -519,7 +509,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **"What If" Game Scenarios**
|
||||
[[LLM: Generate provocative what-if questions that challenge game design assumptions and expand thinking beyond current genre limitations.]]
|
||||
|
||||
- What if players could rewind time in any genre?
|
||||
- What if the game world reacted to the player's real-world location?
|
||||
- What if failure was more rewarding than success?
|
||||
@@ -528,7 +517,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Cross-Genre Fusion**
|
||||
[[LLM: Help user combine unexpected game genres and mechanics to create unique experiences.]]
|
||||
|
||||
- "How might [genre A] mechanics work in [genre B]?"
|
||||
- Puzzle mechanics in action games
|
||||
- Dating sim elements in strategy games
|
||||
@@ -537,7 +525,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Player Motivation Reversal**
|
||||
[[LLM: Flip traditional player motivations to reveal new gameplay possibilities.]]
|
||||
|
||||
- What if losing was the goal?
|
||||
- What if cooperation was forced in competitive games?
|
||||
- What if players had to help their enemies?
|
||||
@@ -554,7 +541,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **SCAMPER for Game Mechanics**
|
||||
[[LLM: Guide through each SCAMPER prompt specifically for game design.]]
|
||||
|
||||
- **S** = Substitute: What mechanics can be substituted? (walking → flying → swimming)
|
||||
- **C** = Combine: What systems can be merged? (inventory + character growth)
|
||||
- **A** = Adapt: What mechanics from other media? (books, movies, sports)
|
||||
@@ -565,7 +551,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Agency Spectrum**
|
||||
[[LLM: Explore different levels of player control and agency across game systems.]]
|
||||
|
||||
- Full Control: Direct character movement, combat, building
|
||||
- Indirect Control: Setting rules, giving commands, environmental changes
|
||||
- Influence Only: Suggestions, preferences, emotional reactions
|
||||
@@ -573,7 +558,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Temporal Game Design**
|
||||
[[LLM: Explore how time affects gameplay and player experience.]]
|
||||
|
||||
- Real-time vs. turn-based mechanics
|
||||
- Time travel and manipulation
|
||||
- Persistent vs. session-based progress
|
||||
@@ -584,7 +568,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Emotion-First Design**
|
||||
[[LLM: Start with target emotions and work backward to mechanics that create them.]]
|
||||
|
||||
- Target Emotion: Wonder → Mechanics: Discovery, mystery, scale
|
||||
- Target Emotion: Triumph → Mechanics: Challenge, skill growth, recognition
|
||||
- Target Emotion: Connection → Mechanics: Cooperation, shared goals, communication
|
||||
@@ -592,7 +575,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Archetype Brainstorming**
|
||||
[[LLM: Design for different player types and motivations.]]
|
||||
|
||||
- Achievers: Progression, completion, mastery
|
||||
- Explorers: Discovery, secrets, world-building
|
||||
- Socializers: Interaction, cooperation, community
|
||||
@@ -601,7 +583,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Accessibility-First Innovation**
|
||||
[[LLM: Generate ideas that make games more accessible while creating new gameplay.]]
|
||||
|
||||
- Visual impairment considerations leading to audio-focused mechanics
|
||||
- Motor accessibility inspiring one-handed or simplified controls
|
||||
- Cognitive accessibility driving clear feedback and pacing
|
||||
@@ -611,7 +592,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Environmental Storytelling**
|
||||
[[LLM: Brainstorm ways the game world itself tells stories without explicit narrative.]]
|
||||
|
||||
- How does the environment show history?
|
||||
- What do interactive objects reveal about characters?
|
||||
- How can level design communicate mood?
|
||||
@@ -619,7 +599,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player-Generated Narrative**
|
||||
[[LLM: Explore ways players create their own stories through gameplay.]]
|
||||
|
||||
- Emergent storytelling through player choices
|
||||
- Procedural narrative generation
|
||||
- Player-to-player story sharing
|
||||
@@ -627,7 +606,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Genre Expectation Subversion**
|
||||
[[LLM: Identify and deliberately subvert player expectations within genres.]]
|
||||
|
||||
- Fantasy RPG where magic is mundane
|
||||
- Horror game where monsters are friendly
|
||||
- Racing game where going slow is optimal
|
||||
@@ -637,7 +615,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Platform-Specific Design**
|
||||
[[LLM: Generate ideas that leverage unique platform capabilities.]]
|
||||
|
||||
- Mobile: GPS, accelerometer, camera, always-connected
|
||||
- Web: URLs, tabs, social sharing, real-time collaboration
|
||||
- Console: Controllers, TV viewing, couch co-op
|
||||
@@ -645,7 +622,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Constraint-Based Creativity**
|
||||
[[LLM: Use technical or design constraints as creative catalysts.]]
|
||||
|
||||
- One-button games
|
||||
- Games without graphics
|
||||
- Games that play in notification bars
|
||||
@@ -691,19 +667,16 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Guide the brainstorming session with appropriate pacing for game design exploration.]]
|
||||
|
||||
1. **Inspiration Phase** (10-15 min)
|
||||
|
||||
- Reference existing games and mechanics
|
||||
- Explore player experiences and emotions
|
||||
- Gather visual and thematic inspiration
|
||||
|
||||
2. **Divergent Exploration** (25-35 min)
|
||||
|
||||
- Generate many game concepts or mechanics
|
||||
- Use expansion and fusion techniques
|
||||
- Encourage wild and impossible ideas
|
||||
|
||||
3. **Player-Centered Filtering** (15-20 min)
|
||||
|
||||
- Consider target audience reactions
|
||||
- Evaluate emotional impact and engagement
|
||||
- Group ideas by player experience goals
|
||||
@@ -824,63 +797,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -1049,13 +1013,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -1113,7 +1075,6 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
|
||||
|
||||
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
|
||||
|
||||
- The entire section as a whole
|
||||
- Individual game elements within the section (specify which element when selecting an action)
|
||||
|
||||
@@ -3237,7 +3198,6 @@ that can handle [specific game requirements] with stable performance."
|
||||
**Prerequisites**: Game planning documents must exist in `docs/` folder of Unity project
|
||||
|
||||
1. **Document Sharding** (CRITICAL STEP for Game Development):
|
||||
|
||||
- Documents created by Game Designer/Architect (in Web or IDE) MUST be sharded for development
|
||||
- Use core BMad agents or tools to shard:
|
||||
a) **Manual**: Use core BMad `shard-doc` task if available
|
||||
@@ -3260,20 +3220,17 @@ Resulting Unity Project Folder Structure:
|
||||
3. **Game Development Cycle** (Sequential, one game story at a time):
|
||||
|
||||
**CRITICAL CONTEXT MANAGEMENT for Unity Development**:
|
||||
|
||||
- **Context windows matter!** Always use fresh, clean context windows
|
||||
- **Model selection matters!** Use most powerful thinking model for Game SM story creation
|
||||
- **ALWAYS start new chat between Game SM, Game Dev, and QA work**
|
||||
|
||||
**Step 1 - Game Story Creation**:
|
||||
|
||||
- **NEW CLEAN CHAT** → Select powerful model → `/bmad2du/game-sm` → `*draft`
|
||||
- Game SM executes create-game-story task using `game-story-tmpl`
|
||||
- Review generated story in `docs/game-stories/`
|
||||
- Update status from "Draft" to "Approved"
|
||||
|
||||
**Step 2 - Unity Game Story Implementation**:
|
||||
|
||||
- **NEW CLEAN CHAT** → `/bmad2du/game-developer`
|
||||
- Agent asks which game story to implement
|
||||
- Include story file content to save game dev agent lookup time
|
||||
@@ -3282,7 +3239,6 @@ Resulting Unity Project Folder Structure:
|
||||
- Game Dev marks story as "Review" when complete with all Unity tests passing
|
||||
|
||||
**Step 3 - Game QA Review**:
|
||||
|
||||
- **NEW CLEAN CHAT** → Use core `@qa` agent → execute review-story task
|
||||
- QA performs senior Unity developer code review
|
||||
- QA can refactor and improve Unity code directly
|
||||
@@ -3322,14 +3278,12 @@ Since this expansion pack doesn't include specific brownfield templates, you'll
|
||||
|
||||
1. **Upload Unity project to Web UI** (GitHub URL, files, or zip)
|
||||
2. **Create adapted Game Design Document**: `/bmad2du/game-designer` - Modify `game-design-doc-tmpl` to include:
|
||||
|
||||
- Analysis of existing game systems
|
||||
- Integration points for new features
|
||||
- Compatibility requirements
|
||||
- Risk assessment for changes
|
||||
|
||||
3. **Game Architecture Planning**:
|
||||
|
||||
- Use `/bmad2du/game-architect` with `game-architecture-tmpl`
|
||||
- Focus on how new features integrate with existing Unity systems
|
||||
- Plan for gradual rollout and testing
|
||||
|
||||
@@ -108,7 +108,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -121,14 +120,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -137,7 +134,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -145,7 +141,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -159,7 +154,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -169,7 +163,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -357,7 +350,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
1. **Requirements Met:**
|
||||
|
||||
[[LLM: Be specific - list each requirement and whether it's complete. Include game-specific requirements from GDD]]
|
||||
|
||||
- [ ] All functional requirements specified in the story are implemented.
|
||||
- [ ] All acceptance criteria defined in the story are met.
|
||||
- [ ] Game Design Document (GDD) requirements referenced in the story are implemented.
|
||||
@@ -366,7 +358,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
2. **Coding Standards & Project Structure:**
|
||||
|
||||
[[LLM: Code quality matters for maintainability. Check Unity-specific patterns and C# standards]]
|
||||
|
||||
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
|
||||
- [ ] All new/modified code aligns with `Project Structure` (Scripts/, Prefabs/, Scenes/, etc.).
|
||||
- [ ] Adherence to `Tech Stack` for Unity version and packages used.
|
||||
@@ -380,7 +371,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
3. **Testing:**
|
||||
|
||||
[[LLM: Testing proves your code works. Include Unity-specific testing with NUnit and manual testing]]
|
||||
|
||||
- [ ] All required unit tests (NUnit) as per the story and testing strategy are implemented.
|
||||
- [ ] All required integration tests (if applicable) are implemented.
|
||||
- [ ] Manual testing performed in Unity Editor for all game functionality.
|
||||
@@ -392,7 +382,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
4. **Functionality & Verification:**
|
||||
|
||||
[[LLM: Did you actually run and test your code in Unity? Be specific about game mechanics tested]]
|
||||
|
||||
- [ ] Functionality has been manually verified in Unity Editor and play mode.
|
||||
- [ ] Game mechanics work as specified in the GDD.
|
||||
- [ ] Player controls and input handling work correctly.
|
||||
@@ -405,7 +394,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
5. **Story Administration:**
|
||||
|
||||
[[LLM: Documentation helps the next developer. Include Unity-specific implementation notes]]
|
||||
|
||||
- [ ] All tasks within the story file are marked as complete.
|
||||
- [ ] Any clarifications or decisions made during development are documented.
|
||||
- [ ] Unity-specific implementation details documented (scene changes, prefab modifications).
|
||||
@@ -415,7 +403,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
6. **Dependencies, Build & Configuration:**
|
||||
|
||||
[[LLM: Build issues block everyone. Ensure Unity project builds for all target platforms]]
|
||||
|
||||
- [ ] Unity project builds successfully without errors.
|
||||
- [ ] Project builds for all target platforms (desktop/mobile as specified).
|
||||
- [ ] Any new Unity packages or Asset Store items were pre-approved OR approved by user.
|
||||
@@ -427,7 +414,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
7. **Game-Specific Quality:**
|
||||
|
||||
[[LLM: Game quality matters. Check performance, game feel, and player experience]]
|
||||
|
||||
- [ ] Frame rate meets target (30/60 FPS) on all platforms.
|
||||
- [ ] Memory usage within acceptable limits.
|
||||
- [ ] Game feel and responsiveness meet design requirements.
|
||||
@@ -439,7 +425,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
8. **Documentation (If Applicable):**
|
||||
|
||||
[[LLM: Good documentation prevents future confusion. Include Unity-specific docs]]
|
||||
|
||||
- [ ] Code documentation (XML comments) for public APIs complete.
|
||||
- [ ] Unity component documentation in Inspector updated.
|
||||
- [ ] User-facing documentation updated, if changes impact players.
|
||||
|
||||
@@ -286,7 +286,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -299,14 +298,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -315,7 +312,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -323,7 +319,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -337,7 +332,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -347,7 +341,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -387,7 +380,6 @@ The LLM will:
|
||||
### 1. Initial Setup & Mode Selection
|
||||
|
||||
- **Acknowledge Task & Inputs:**
|
||||
|
||||
- Confirm with the user that the "Game Development Correct Course Task" is being initiated.
|
||||
- Verify the change trigger (e.g., performance issue, platform constraint, gameplay feedback, technical blocker).
|
||||
- Confirm access to relevant game artifacts:
|
||||
@@ -408,7 +400,6 @@ The LLM will:
|
||||
### 2. Execute Game Development Checklist Analysis
|
||||
|
||||
- Systematically work through the game-change-checklist sections:
|
||||
|
||||
1. **Change Context & Game Impact**
|
||||
2. **Feature/System Impact Analysis**
|
||||
3. **Technical Artifact Conflict Resolution**
|
||||
@@ -433,7 +424,6 @@ The LLM will:
|
||||
Based on the analysis and agreed path forward:
|
||||
|
||||
- **Identify affected game artifacts requiring updates:**
|
||||
|
||||
- GDD sections (mechanics, systems, progression)
|
||||
- Technical specifications (architecture, performance targets)
|
||||
- Unity-specific configurations (build settings, quality settings)
|
||||
@@ -442,7 +432,6 @@ Based on the analysis and agreed path forward:
|
||||
- Platform-specific adaptations
|
||||
|
||||
- **Draft explicit changes for each artifact:**
|
||||
|
||||
- **Game Stories:** Revise story text, Unity-specific acceptance criteria, technical constraints
|
||||
- **Technical Specs:** Update architecture diagrams, component hierarchies, performance budgets
|
||||
- **Unity Configurations:** Propose settings changes, optimization strategies, platform variants
|
||||
@@ -462,14 +451,12 @@ Based on the analysis and agreed path forward:
|
||||
- Create a comprehensive proposal document containing:
|
||||
|
||||
**A. Change Summary:**
|
||||
|
||||
- Original issue (performance, gameplay, technical constraint)
|
||||
- Game systems affected
|
||||
- Platform/performance implications
|
||||
- Chosen solution approach
|
||||
|
||||
**B. Technical Impact Analysis:**
|
||||
|
||||
- Unity architecture changes needed
|
||||
- Performance implications (with metrics)
|
||||
- Platform compatibility effects
|
||||
@@ -477,14 +464,12 @@ Based on the analysis and agreed path forward:
|
||||
- Third-party dependency impacts
|
||||
|
||||
**C. Specific Proposed Edits:**
|
||||
|
||||
- For each game story: "Change Story GS-X.Y from: [old] To: [new]"
|
||||
- For technical specs: "Update Unity Architecture Section X: [changes]"
|
||||
- For GDD: "Modify [Feature] in Section Y: [updates]"
|
||||
- For configurations: "Change [Setting] from [old_value] to [new_value]"
|
||||
|
||||
**D. Implementation Considerations:**
|
||||
|
||||
- Required Unity version updates
|
||||
- Asset reimport needs
|
||||
- Shader recompilation requirements
|
||||
@@ -496,7 +481,6 @@ Based on the analysis and agreed path forward:
|
||||
- Provide the finalized document to the user
|
||||
|
||||
- **Based on change scope:**
|
||||
|
||||
- **Minor adjustments (can be handled in current sprint):**
|
||||
- Confirm task completion
|
||||
- Suggest handoff to game-dev agent for implementation
|
||||
@@ -510,7 +494,6 @@ Based on the analysis and agreed path forward:
|
||||
## Output Deliverables
|
||||
|
||||
- **Primary:** "Game Development Change Proposal" document containing:
|
||||
|
||||
- Game-specific change analysis
|
||||
- Technical impact assessment with Unity context
|
||||
- Platform and performance considerations
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -239,7 +239,6 @@ To conduct a thorough review of existing infrastructure to identify improvement
|
||||
### 3. Conduct Systematic Review
|
||||
|
||||
- **If "Incremental Mode" was selected:**
|
||||
|
||||
- For each section of the infrastructure checklist:
|
||||
- **a. Present Section Focus:** Explain what aspects of infrastructure this section reviews
|
||||
- **b. Work Through Items:** Examine each checklist item against current infrastructure
|
||||
@@ -425,7 +424,6 @@ To comprehensively validate platform infrastructure changes against security, re
|
||||
### 4. Execute Comprehensive Platform Validation Process
|
||||
|
||||
- **If "Incremental Mode" was selected:**
|
||||
|
||||
- For each section of the infrastructure checklist (Sections 1-16):
|
||||
- **a. Present Section Purpose:** Explain what this section validates and why it's important for platform operations
|
||||
- **b. Work Through Items:** Present each checklist item, guide the user through validation, and document compliance or gaps
|
||||
|
||||
2194
dist/teams/team-all.txt
vendored
2194
dist/teams/team-all.txt
vendored
File diff suppressed because it is too large
Load Diff
76
dist/teams/team-fullstack.txt
vendored
76
dist/teams/team-fullstack.txt
vendored
@@ -728,7 +728,7 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
|
||||
|
||||
## Instructions
|
||||
|
||||
When entering KB mode (*kb-mode), follow these steps:
|
||||
When entering KB mode (\*kb-mode), follow these steps:
|
||||
|
||||
### 1. Welcome and Guide
|
||||
|
||||
@@ -770,12 +770,12 @@ Or ask me about anything else related to BMad-Method!
|
||||
When user is done or wants to exit KB mode:
|
||||
|
||||
- Summarize key points discussed if helpful
|
||||
- Remind them they can return to KB mode anytime with *kb-mode
|
||||
- Remind them they can return to KB mode anytime with \*kb-mode
|
||||
- Suggest next steps based on what was discussed
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User**: *kb-mode
|
||||
**User**: \*kb-mode
|
||||
|
||||
**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
|
||||
|
||||
@@ -1451,8 +1451,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
|
||||
|
||||
```markdown
|
||||
## Goals and Background Context
|
||||
|
||||
## Requirements
|
||||
|
||||
## User Interface Design Goals
|
||||
|
||||
## Success Metrics
|
||||
```
|
||||
|
||||
@@ -1609,16 +1612,19 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Core Reflective Methods
|
||||
|
||||
**Expand or Contract for Audience**
|
||||
|
||||
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
|
||||
- Identify specific target audience if relevant
|
||||
- Tailor content complexity and depth accordingly
|
||||
|
||||
**Explain Reasoning (CoT Step-by-Step)**
|
||||
|
||||
- Walk through the step-by-step thinking process
|
||||
- Reveal underlying assumptions and decision points
|
||||
- Show how conclusions were reached from current role's perspective
|
||||
|
||||
**Critique and Refine**
|
||||
|
||||
- Review output for flaws, inconsistencies, or improvement areas
|
||||
- Identify specific weaknesses from role's expertise
|
||||
- Suggest refined version reflecting domain knowledge
|
||||
@@ -1626,12 +1632,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Structural Analysis Methods
|
||||
|
||||
**Analyze Logical Flow and Dependencies**
|
||||
|
||||
- Examine content structure for logical progression
|
||||
- Check internal consistency and coherence
|
||||
- Identify and validate dependencies between elements
|
||||
- Confirm effective ordering and sequencing
|
||||
|
||||
**Assess Alignment with Overall Goals**
|
||||
|
||||
- Evaluate content contribution to stated objectives
|
||||
- Identify any misalignments or gaps
|
||||
- Interpret alignment from specific role's perspective
|
||||
@@ -1640,12 +1648,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Risk and Challenge Methods
|
||||
|
||||
**Identify Potential Risks and Unforeseen Issues**
|
||||
|
||||
- Brainstorm potential risks from role's expertise
|
||||
- Identify overlooked edge cases or scenarios
|
||||
- Anticipate unintended consequences
|
||||
- Highlight implementation challenges
|
||||
|
||||
**Challenge from Critical Perspective**
|
||||
|
||||
- Adopt critical stance on current content
|
||||
- Play devil's advocate from specified viewpoint
|
||||
- Argue against proposal highlighting weaknesses
|
||||
@@ -1654,12 +1664,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Creative Exploration Methods
|
||||
|
||||
**Tree of Thoughts Deep Dive**
|
||||
|
||||
- Break problem into discrete "thoughts" or intermediate steps
|
||||
- Explore multiple reasoning paths simultaneously
|
||||
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
|
||||
- Apply search algorithms (BFS/DFS) to find optimal solution paths
|
||||
|
||||
**Hindsight is 20/20: The 'If Only...' Reflection**
|
||||
|
||||
- Imagine retrospective scenario based on current content
|
||||
- Identify the one "if only we had known/done X..." insight
|
||||
- Describe imagined consequences humorously or dramatically
|
||||
@@ -1668,6 +1680,7 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Multi-Persona Collaboration Methods
|
||||
|
||||
**Agile Team Perspective Shift**
|
||||
|
||||
- Rotate through different Scrum team member viewpoints
|
||||
- Product Owner: Focus on user value and business impact
|
||||
- Scrum Master: Examine process flow and team dynamics
|
||||
@@ -1675,12 +1688,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
- QA: Identify testing scenarios and quality concerns
|
||||
|
||||
**Stakeholder Round Table**
|
||||
|
||||
- Convene virtual meeting with multiple personas
|
||||
- Each persona contributes unique perspective on content
|
||||
- Identify conflicts and synergies between viewpoints
|
||||
- Synthesize insights into actionable recommendations
|
||||
|
||||
**Meta-Prompting Analysis**
|
||||
|
||||
- Step back to analyze the structure and logic of current approach
|
||||
- Question the format and methodology being used
|
||||
- Suggest alternative frameworks or mental models
|
||||
@@ -1689,24 +1704,28 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Advanced 2025 Techniques
|
||||
|
||||
**Self-Consistency Validation**
|
||||
|
||||
- Generate multiple reasoning paths for same problem
|
||||
- Compare consistency across different approaches
|
||||
- Identify most reliable and robust solution
|
||||
- Highlight areas where approaches diverge and why
|
||||
|
||||
**ReWOO (Reasoning Without Observation)**
|
||||
|
||||
- Separate parametric reasoning from tool-based actions
|
||||
- Create reasoning plan without external dependencies
|
||||
- Identify what can be solved through pure reasoning
|
||||
- Optimize for efficiency and reduced token usage
|
||||
|
||||
**Persona-Pattern Hybrid**
|
||||
|
||||
- Combine specific role expertise with elicitation pattern
|
||||
- Architect + Risk Analysis: Deep technical risk assessment
|
||||
- UX Expert + User Journey: End-to-end experience critique
|
||||
- PM + Stakeholder Analysis: Multi-perspective impact review
|
||||
|
||||
**Emergent Collaboration Discovery**
|
||||
|
||||
- Allow multiple perspectives to naturally emerge
|
||||
- Identify unexpected insights from persona interactions
|
||||
- Explore novel combinations of viewpoints
|
||||
@@ -1715,18 +1734,21 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Game-Based Elicitation Methods
|
||||
|
||||
**Red Team vs Blue Team**
|
||||
|
||||
- Red Team: Attack the proposal, find vulnerabilities
|
||||
- Blue Team: Defend and strengthen the approach
|
||||
- Competitive analysis reveals blind spots
|
||||
- Results in more robust, battle-tested solutions
|
||||
|
||||
**Innovation Tournament**
|
||||
|
||||
- Pit multiple alternative approaches against each other
|
||||
- Score each approach across different criteria
|
||||
- Crowd-source evaluation from different personas
|
||||
- Identify winning combination of features
|
||||
|
||||
**Escape Room Challenge**
|
||||
|
||||
- Present content as constraints to work within
|
||||
- Find creative solutions within tight limitations
|
||||
- Identify minimum viable approach
|
||||
@@ -1735,6 +1757,7 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Process Control
|
||||
|
||||
**Proceed / No Further Actions**
|
||||
|
||||
- Acknowledge choice to finalize current work
|
||||
- Accept output as-is or move to next step
|
||||
- Prepare to continue without additional elicitation
|
||||
@@ -1975,63 +1998,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -2200,13 +2214,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -2358,7 +2370,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| ------ | ------- | --------------------------- | --------- |
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
@@ -2383,7 +2395,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Actual Tech Stack (from package.json/requirements.txt)
|
||||
|
||||
| Category | Technology | Version | Notes |
|
||||
|----------|------------|---------|--------|
|
||||
| --------- | ---------- | ------- | -------------------------- |
|
||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||
@@ -2425,6 +2437,7 @@ project-root/
|
||||
### Data Models
|
||||
|
||||
Instead of duplicating, reference actual model files:
|
||||
|
||||
- **User Model**: See `src/models/User.js`
|
||||
- **Order Model**: See `src/models/Order.js`
|
||||
- **Related Types**: TypeScript definitions in `src/types/`
|
||||
@@ -2455,7 +2468,7 @@ Instead of duplicating, reference actual model files:
|
||||
### External Services
|
||||
|
||||
| Service | Purpose | Integration Type | Key Files |
|
||||
|---------|---------|------------------|-----------|
|
||||
| -------- | -------- | ---------------- | ------------------------------ |
|
||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||
|
||||
@@ -2502,6 +2515,7 @@ npm run test:integration # Runs integration tests (requires local DB)
|
||||
### Files That Will Need Modification
|
||||
|
||||
Based on the enhancement requirements, these files will be affected:
|
||||
|
||||
- `src/services/userService.js` - Add new user fields
|
||||
- `src/models/User.js` - Update schema
|
||||
- `src/routes/userRoutes.js` - New endpoints
|
||||
@@ -3958,7 +3972,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -3971,14 +3984,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -3987,7 +3998,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -3995,7 +4005,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -4009,7 +4018,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -4019,7 +4027,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -4136,13 +4143,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
||||
For each extracted section:
|
||||
|
||||
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
||||
|
||||
- Remove special characters
|
||||
- Replace spaces with dashes
|
||||
- Example: "## Tech Stack" → `tech-stack.md`
|
||||
|
||||
2. **Adjust heading levels**:
|
||||
|
||||
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
||||
- All subsection levels decrease by 1:
|
||||
|
||||
@@ -5027,7 +5032,6 @@ Ask the user if they want to work through the checklist:
|
||||
Create a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall PRD completeness (percentage)
|
||||
- MVP scope appropriateness (Too Large/Just Right/Too Small)
|
||||
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
|
||||
@@ -5035,26 +5039,22 @@ Create a comprehensive validation report that includes:
|
||||
|
||||
2. Category Analysis Table
|
||||
Fill in the actual table with:
|
||||
|
||||
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
|
||||
- Critical Issues: Specific problems that block progress
|
||||
|
||||
3. Top Issues by Priority
|
||||
|
||||
- BLOCKERS: Must fix before architect can proceed
|
||||
- HIGH: Should fix for quality
|
||||
- MEDIUM: Would improve clarity
|
||||
- LOW: Nice to have
|
||||
|
||||
4. MVP Scope Assessment
|
||||
|
||||
- Features that might be cut for true MVP
|
||||
- Missing features that are essential
|
||||
- Complexity concerns
|
||||
- Timeline realism
|
||||
|
||||
5. Technical Readiness
|
||||
|
||||
- Clarity of technical constraints
|
||||
- Identified technical risks
|
||||
- Areas needing architect investigation
|
||||
@@ -8250,33 +8250,28 @@ Ask the user if they want to work through the checklist:
|
||||
Now that you've completed the checklist, generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall architecture readiness (High/Medium/Low)
|
||||
- Critical risks identified
|
||||
- Key strengths of the architecture
|
||||
- Project type (Full-stack/Frontend/Backend) and sections evaluated
|
||||
|
||||
2. Section Analysis
|
||||
|
||||
- Pass rate for each major section (percentage of items passed)
|
||||
- Most concerning failures or gaps
|
||||
- Sections requiring immediate attention
|
||||
- Note any sections skipped due to project type
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations for each
|
||||
- Timeline impact of addressing issues
|
||||
|
||||
4. Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Should-fix items for better quality
|
||||
- Nice-to-have improvements
|
||||
|
||||
5. AI Implementation Readiness
|
||||
|
||||
- Specific concerns for AI agent implementation
|
||||
- Areas needing additional clarification
|
||||
- Complexity hotspots to address
|
||||
@@ -8578,12 +8573,10 @@ PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
@@ -8917,7 +8910,6 @@ Ask the user if they want to work through the checklist:
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
@@ -8927,42 +8919,36 @@ Generate a comprehensive validation report that adapts to project type:
|
||||
2. Project-Specific Analysis
|
||||
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
|
||||
2165
dist/teams/team-ide-minimal.txt
vendored
2165
dist/teams/team-ide-minimal.txt
vendored
File diff suppressed because it is too large
Load Diff
76
dist/teams/team-no-ui.txt
vendored
76
dist/teams/team-no-ui.txt
vendored
@@ -674,7 +674,7 @@ Provide a user-friendly interface to the BMad knowledge base without overwhelmin
|
||||
|
||||
## Instructions
|
||||
|
||||
When entering KB mode (*kb-mode), follow these steps:
|
||||
When entering KB mode (\*kb-mode), follow these steps:
|
||||
|
||||
### 1. Welcome and Guide
|
||||
|
||||
@@ -716,12 +716,12 @@ Or ask me about anything else related to BMad-Method!
|
||||
When user is done or wants to exit KB mode:
|
||||
|
||||
- Summarize key points discussed if helpful
|
||||
- Remind them they can return to KB mode anytime with *kb-mode
|
||||
- Remind them they can return to KB mode anytime with \*kb-mode
|
||||
- Suggest next steps based on what was discussed
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User**: *kb-mode
|
||||
**User**: \*kb-mode
|
||||
|
||||
**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
|
||||
|
||||
@@ -1397,8 +1397,11 @@ Templates with Level 2 headings (`##`) can be automatically sharded:
|
||||
|
||||
```markdown
|
||||
## Goals and Background Context
|
||||
|
||||
## Requirements
|
||||
|
||||
## User Interface Design Goals
|
||||
|
||||
## Success Metrics
|
||||
```
|
||||
|
||||
@@ -1555,16 +1558,19 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Core Reflective Methods
|
||||
|
||||
**Expand or Contract for Audience**
|
||||
|
||||
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
|
||||
- Identify specific target audience if relevant
|
||||
- Tailor content complexity and depth accordingly
|
||||
|
||||
**Explain Reasoning (CoT Step-by-Step)**
|
||||
|
||||
- Walk through the step-by-step thinking process
|
||||
- Reveal underlying assumptions and decision points
|
||||
- Show how conclusions were reached from current role's perspective
|
||||
|
||||
**Critique and Refine**
|
||||
|
||||
- Review output for flaws, inconsistencies, or improvement areas
|
||||
- Identify specific weaknesses from role's expertise
|
||||
- Suggest refined version reflecting domain knowledge
|
||||
@@ -1572,12 +1578,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Structural Analysis Methods
|
||||
|
||||
**Analyze Logical Flow and Dependencies**
|
||||
|
||||
- Examine content structure for logical progression
|
||||
- Check internal consistency and coherence
|
||||
- Identify and validate dependencies between elements
|
||||
- Confirm effective ordering and sequencing
|
||||
|
||||
**Assess Alignment with Overall Goals**
|
||||
|
||||
- Evaluate content contribution to stated objectives
|
||||
- Identify any misalignments or gaps
|
||||
- Interpret alignment from specific role's perspective
|
||||
@@ -1586,12 +1594,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Risk and Challenge Methods
|
||||
|
||||
**Identify Potential Risks and Unforeseen Issues**
|
||||
|
||||
- Brainstorm potential risks from role's expertise
|
||||
- Identify overlooked edge cases or scenarios
|
||||
- Anticipate unintended consequences
|
||||
- Highlight implementation challenges
|
||||
|
||||
**Challenge from Critical Perspective**
|
||||
|
||||
- Adopt critical stance on current content
|
||||
- Play devil's advocate from specified viewpoint
|
||||
- Argue against proposal highlighting weaknesses
|
||||
@@ -1600,12 +1610,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Creative Exploration Methods
|
||||
|
||||
**Tree of Thoughts Deep Dive**
|
||||
|
||||
- Break problem into discrete "thoughts" or intermediate steps
|
||||
- Explore multiple reasoning paths simultaneously
|
||||
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
|
||||
- Apply search algorithms (BFS/DFS) to find optimal solution paths
|
||||
|
||||
**Hindsight is 20/20: The 'If Only...' Reflection**
|
||||
|
||||
- Imagine retrospective scenario based on current content
|
||||
- Identify the one "if only we had known/done X..." insight
|
||||
- Describe imagined consequences humorously or dramatically
|
||||
@@ -1614,6 +1626,7 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Multi-Persona Collaboration Methods
|
||||
|
||||
**Agile Team Perspective Shift**
|
||||
|
||||
- Rotate through different Scrum team member viewpoints
|
||||
- Product Owner: Focus on user value and business impact
|
||||
- Scrum Master: Examine process flow and team dynamics
|
||||
@@ -1621,12 +1634,14 @@ Use the **expansion-creator** pack to build your own:
|
||||
- QA: Identify testing scenarios and quality concerns
|
||||
|
||||
**Stakeholder Round Table**
|
||||
|
||||
- Convene virtual meeting with multiple personas
|
||||
- Each persona contributes unique perspective on content
|
||||
- Identify conflicts and synergies between viewpoints
|
||||
- Synthesize insights into actionable recommendations
|
||||
|
||||
**Meta-Prompting Analysis**
|
||||
|
||||
- Step back to analyze the structure and logic of current approach
|
||||
- Question the format and methodology being used
|
||||
- Suggest alternative frameworks or mental models
|
||||
@@ -1635,24 +1650,28 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Advanced 2025 Techniques
|
||||
|
||||
**Self-Consistency Validation**
|
||||
|
||||
- Generate multiple reasoning paths for same problem
|
||||
- Compare consistency across different approaches
|
||||
- Identify most reliable and robust solution
|
||||
- Highlight areas where approaches diverge and why
|
||||
|
||||
**ReWOO (Reasoning Without Observation)**
|
||||
|
||||
- Separate parametric reasoning from tool-based actions
|
||||
- Create reasoning plan without external dependencies
|
||||
- Identify what can be solved through pure reasoning
|
||||
- Optimize for efficiency and reduced token usage
|
||||
|
||||
**Persona-Pattern Hybrid**
|
||||
|
||||
- Combine specific role expertise with elicitation pattern
|
||||
- Architect + Risk Analysis: Deep technical risk assessment
|
||||
- UX Expert + User Journey: End-to-end experience critique
|
||||
- PM + Stakeholder Analysis: Multi-perspective impact review
|
||||
|
||||
**Emergent Collaboration Discovery**
|
||||
|
||||
- Allow multiple perspectives to naturally emerge
|
||||
- Identify unexpected insights from persona interactions
|
||||
- Explore novel combinations of viewpoints
|
||||
@@ -1661,18 +1680,21 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Game-Based Elicitation Methods
|
||||
|
||||
**Red Team vs Blue Team**
|
||||
|
||||
- Red Team: Attack the proposal, find vulnerabilities
|
||||
- Blue Team: Defend and strengthen the approach
|
||||
- Competitive analysis reveals blind spots
|
||||
- Results in more robust, battle-tested solutions
|
||||
|
||||
**Innovation Tournament**
|
||||
|
||||
- Pit multiple alternative approaches against each other
|
||||
- Score each approach across different criteria
|
||||
- Crowd-source evaluation from different personas
|
||||
- Identify winning combination of features
|
||||
|
||||
**Escape Room Challenge**
|
||||
|
||||
- Present content as constraints to work within
|
||||
- Find creative solutions within tight limitations
|
||||
- Identify minimum viable approach
|
||||
@@ -1681,6 +1703,7 @@ Use the **expansion-creator** pack to build your own:
|
||||
## Process Control
|
||||
|
||||
**Proceed / No Further Actions**
|
||||
|
||||
- Acknowledge choice to finalize current work
|
||||
- Accept output as-is or move to next step
|
||||
- Prepare to continue without additional elicitation
|
||||
@@ -1921,63 +1944,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
|
||||
Present these numbered options to the user:
|
||||
|
||||
1. **Product Validation Research**
|
||||
|
||||
- Validate product hypotheses and market fit
|
||||
- Test assumptions about user needs and solutions
|
||||
- Assess technical and business feasibility
|
||||
- Identify risks and mitigation strategies
|
||||
|
||||
2. **Market Opportunity Research**
|
||||
|
||||
- Analyze market size and growth potential
|
||||
- Identify market segments and dynamics
|
||||
- Assess market entry strategies
|
||||
- Evaluate timing and market readiness
|
||||
|
||||
3. **User & Customer Research**
|
||||
|
||||
- Deep dive into user personas and behaviors
|
||||
- Understand jobs-to-be-done and pain points
|
||||
- Map customer journeys and touchpoints
|
||||
- Analyze willingness to pay and value perception
|
||||
|
||||
4. **Competitive Intelligence Research**
|
||||
|
||||
- Detailed competitor analysis and positioning
|
||||
- Feature and capability comparisons
|
||||
- Business model and strategy analysis
|
||||
- Identify competitive advantages and gaps
|
||||
|
||||
5. **Technology & Innovation Research**
|
||||
|
||||
- Assess technology trends and possibilities
|
||||
- Evaluate technical approaches and architectures
|
||||
- Identify emerging technologies and disruptions
|
||||
- Analyze build vs. buy vs. partner options
|
||||
|
||||
6. **Industry & Ecosystem Research**
|
||||
|
||||
- Map industry value chains and dynamics
|
||||
- Identify key players and relationships
|
||||
- Analyze regulatory and compliance factors
|
||||
- Understand partnership opportunities
|
||||
|
||||
7. **Strategic Options Research**
|
||||
|
||||
- Evaluate different strategic directions
|
||||
- Assess business model alternatives
|
||||
- Analyze go-to-market strategies
|
||||
- Consider expansion and scaling paths
|
||||
|
||||
8. **Risk & Feasibility Research**
|
||||
|
||||
- Identify and assess various risk factors
|
||||
- Evaluate implementation challenges
|
||||
- Analyze resource requirements
|
||||
- Consider regulatory and legal implications
|
||||
|
||||
9. **Custom Research Focus**
|
||||
|
||||
- User-defined research objectives
|
||||
- Specialized domain investigation
|
||||
- Cross-functional research needs
|
||||
@@ -2146,13 +2160,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
|
||||
### 5. Review and Refinement
|
||||
|
||||
1. **Present Complete Prompt**
|
||||
|
||||
- Show the full research prompt
|
||||
- Explain key elements and rationale
|
||||
- Highlight any assumptions made
|
||||
|
||||
2. **Gather Feedback**
|
||||
|
||||
- Are the objectives clear and correct?
|
||||
- Do the questions address all concerns?
|
||||
- Is the scope appropriate?
|
||||
@@ -2304,7 +2316,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Change Log
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
|------|---------|-------------|--------|
|
||||
| ------ | ------- | --------------------------- | --------- |
|
||||
| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
|
||||
|
||||
## Quick Reference - Key Files and Entry Points
|
||||
@@ -2329,7 +2341,7 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
|
||||
### Actual Tech Stack (from package.json/requirements.txt)
|
||||
|
||||
| Category | Technology | Version | Notes |
|
||||
|----------|------------|---------|--------|
|
||||
| --------- | ---------- | ------- | -------------------------- |
|
||||
| Runtime | Node.js | 16.x | [Any constraints] |
|
||||
| Framework | Express | 4.18.2 | [Custom middleware?] |
|
||||
| Database | PostgreSQL | 13 | [Connection pooling setup] |
|
||||
@@ -2371,6 +2383,7 @@ project-root/
|
||||
### Data Models
|
||||
|
||||
Instead of duplicating, reference actual model files:
|
||||
|
||||
- **User Model**: See `src/models/User.js`
|
||||
- **Order Model**: See `src/models/Order.js`
|
||||
- **Related Types**: TypeScript definitions in `src/types/`
|
||||
@@ -2401,7 +2414,7 @@ Instead of duplicating, reference actual model files:
|
||||
### External Services
|
||||
|
||||
| Service | Purpose | Integration Type | Key Files |
|
||||
|---------|---------|------------------|-----------|
|
||||
| -------- | -------- | ---------------- | ------------------------------ |
|
||||
| Stripe | Payments | REST API | `src/integrations/stripe/` |
|
||||
| SendGrid | Emails | SDK | `src/services/emailService.js` |
|
||||
|
||||
@@ -2448,6 +2461,7 @@ npm run test:integration # Runs integration tests (requires local DB)
|
||||
### Files That Will Need Modification
|
||||
|
||||
Based on the enhancement requirements, these files will be affected:
|
||||
|
||||
- `src/services/userService.js` - Add new user fields
|
||||
- `src/models/User.js` - Update schema
|
||||
- `src/routes/userRoutes.js` - New endpoints
|
||||
@@ -3904,7 +3918,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
@@ -3917,14 +3930,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
@@ -3933,7 +3944,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
@@ -3941,7 +3951,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
@@ -3955,7 +3964,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
@@ -3965,7 +3973,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
@@ -4082,13 +4089,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
|
||||
For each extracted section:
|
||||
|
||||
1. **Generate filename**: Convert the section heading to lowercase-dash-case
|
||||
|
||||
- Remove special characters
|
||||
- Replace spaces with dashes
|
||||
- Example: "## Tech Stack" → `tech-stack.md`
|
||||
|
||||
2. **Adjust heading levels**:
|
||||
|
||||
- The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
|
||||
- All subsection levels decrease by 1:
|
||||
|
||||
@@ -4973,7 +4978,6 @@ Ask the user if they want to work through the checklist:
|
||||
Create a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall PRD completeness (percentage)
|
||||
- MVP scope appropriateness (Too Large/Just Right/Too Small)
|
||||
- Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
|
||||
@@ -4981,26 +4985,22 @@ Create a comprehensive validation report that includes:
|
||||
|
||||
2. Category Analysis Table
|
||||
Fill in the actual table with:
|
||||
|
||||
- Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
|
||||
- Critical Issues: Specific problems that block progress
|
||||
|
||||
3. Top Issues by Priority
|
||||
|
||||
- BLOCKERS: Must fix before architect can proceed
|
||||
- HIGH: Should fix for quality
|
||||
- MEDIUM: Would improve clarity
|
||||
- LOW: Nice to have
|
||||
|
||||
4. MVP Scope Assessment
|
||||
|
||||
- Features that might be cut for true MVP
|
||||
- Missing features that are essential
|
||||
- Complexity concerns
|
||||
- Timeline realism
|
||||
|
||||
5. Technical Readiness
|
||||
|
||||
- Clarity of technical constraints
|
||||
- Identified technical risks
|
||||
- Areas needing architect investigation
|
||||
@@ -7790,33 +7790,28 @@ Ask the user if they want to work through the checklist:
|
||||
Now that you've completed the checklist, generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall architecture readiness (High/Medium/Low)
|
||||
- Critical risks identified
|
||||
- Key strengths of the architecture
|
||||
- Project type (Full-stack/Frontend/Backend) and sections evaluated
|
||||
|
||||
2. Section Analysis
|
||||
|
||||
- Pass rate for each major section (percentage of items passed)
|
||||
- Most concerning failures or gaps
|
||||
- Sections requiring immediate attention
|
||||
- Note any sections skipped due to project type
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations for each
|
||||
- Timeline impact of addressing issues
|
||||
|
||||
4. Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Should-fix items for better quality
|
||||
- Nice-to-have improvements
|
||||
|
||||
5. AI Implementation Readiness
|
||||
|
||||
- Specific concerns for AI agent implementation
|
||||
- Areas needing additional clarification
|
||||
- Complexity hotspots to address
|
||||
@@ -8118,12 +8113,10 @@ PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
@@ -8457,7 +8450,6 @@ Ask the user if they want to work through the checklist:
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
@@ -8467,42 +8459,36 @@ Generate a comprehensive validation report that adapts to project type:
|
||||
2. Project-Specific Analysis
|
||||
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
|
||||
@@ -8,21 +8,21 @@ This expansion pack provides a complete, deployable starter kit for building and
|
||||
|
||||
## Features
|
||||
|
||||
* **Automated GCP Setup**: `gcloud` scripts to configure your project, service accounts, and required APIs in minutes.
|
||||
* **Production-Ready Deployment**: Includes a `Dockerfile` and `cloudbuild.yaml` for easy, repeatable deployments to Google Cloud Run.
|
||||
* **Rich Template Library**: A comprehensive set of BMad-compatible templates for Teams, Agents, Tasks, Workflows, Documents, and Checklists.
|
||||
* **Pre-configured Agent Roles**: Includes powerful master templates for key agent archetypes like Orchestrators and Specialists.
|
||||
* **Highly Customizable**: Easily adapt the entire system with company-specific variables and industry-specific configurations.
|
||||
* **Powered by Google ADK**: Built on the official Google Agent Development Kit for robust and native integration with Vertex AI services.
|
||||
- **Automated GCP Setup**: `gcloud` scripts to configure your project, service accounts, and required APIs in minutes.
|
||||
- **Production-Ready Deployment**: Includes a `Dockerfile` and `cloudbuild.yaml` for easy, repeatable deployments to Google Cloud Run.
|
||||
- **Rich Template Library**: A comprehensive set of BMad-compatible templates for Teams, Agents, Tasks, Workflows, Documents, and Checklists.
|
||||
- **Pre-configured Agent Roles**: Includes powerful master templates for key agent archetypes like Orchestrators and Specialists.
|
||||
- **Highly Customizable**: Easily adapt the entire system with company-specific variables and industry-specific configurations.
|
||||
- **Powered by Google ADK**: Built on the official Google Agent Development Kit for robust and native integration with Vertex AI services.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you begin, ensure you have the following installed and configured:
|
||||
|
||||
* A Google Cloud Platform (GCP) Account with an active billing account.
|
||||
* The [Google Cloud SDK (`gcloud` CLI)](https://www.google.com/search?q=%5Bhttps://cloud.google.com/sdk/docs/install%5D\(https://cloud.google.com/sdk/docs/install\)) installed and authenticated.
|
||||
* [Docker](https://www.docker.com/products/docker-desktop/) installed on your local machine.
|
||||
* Python 3.11+
|
||||
- A Google Cloud Platform (GCP) Account with an active billing account.
|
||||
- The [Google Cloud SDK (`gcloud` CLI)](<https://www.google.com/search?q=%5Bhttps://cloud.google.com/sdk/docs/install%5D(https://cloud.google.com/sdk/docs/install)>) installed and authenticated.
|
||||
- [Docker](https://www.docker.com/products/docker-desktop/) installed on your local machine.
|
||||
- Python 3.11+
|
||||
|
||||
## Quick Start Guide
|
||||
|
||||
@@ -32,9 +32,9 @@ Follow these steps to get your own AI agent system running on Google Cloud.
|
||||
|
||||
The setup scripts use placeholder variables. Before running them, open the files in the `/scripts` directory and replace the following placeholders with your own values:
|
||||
|
||||
* `{{PROJECT_ID}}`: Your unique Google Cloud project ID.
|
||||
* `{{COMPANY_NAME}}`: Your company or project name (used for naming resources).
|
||||
* `{{LOCATION}}`: The GCP region you want to deploy to (e.g., `us-central1`).
|
||||
- `{{PROJECT_ID}}`: Your unique Google Cloud project ID.
|
||||
- `{{COMPANY_NAME}}`: Your company or project name (used for naming resources).
|
||||
- `{{LOCATION}}`: The GCP region you want to deploy to (e.g., `us-central1`).
|
||||
|
||||
### 2\. Run the GCP Setup Scripts
|
||||
|
||||
|
||||
@@ -39,13 +39,11 @@ You are developing games as a "Player Experience CEO" - thinking like a game dir
|
||||
### Phase 1: Game Concept and Design
|
||||
|
||||
1. **Game Designer**: Start with brainstorming and concept development
|
||||
|
||||
- Use \*brainstorm to explore game concepts and mechanics
|
||||
- Create Game Brief using game-brief-tmpl
|
||||
- Develop core game pillars and player experience goals
|
||||
|
||||
2. **Game Designer**: Create comprehensive Game Design Document
|
||||
|
||||
- Use game-design-doc-tmpl to create detailed GDD
|
||||
- Define all game mechanics, progression, and balance
|
||||
- Specify technical requirements and platform targets
|
||||
@@ -65,13 +63,11 @@ You are developing games as a "Player Experience CEO" - thinking like a game dir
|
||||
### Phase 3: Story-Driven Development
|
||||
|
||||
5. **Game Scrum Master**: Break down design into development stories
|
||||
|
||||
- Use create-game-story task to create detailed implementation stories
|
||||
- Each story should be immediately actionable by game developers
|
||||
- Apply game-story-dod-checklist to ensure story quality
|
||||
|
||||
6. **Game Developer**: Implement game features story by story
|
||||
|
||||
- Follow TypeScript strict mode and Phaser 3 best practices
|
||||
- Maintain 60 FPS performance target throughout development
|
||||
- Use test-driven development for game logic components
|
||||
|
||||
@@ -380,7 +380,9 @@ class InputManager {
|
||||
}
|
||||
|
||||
private setupKeyboard(): void {
|
||||
this.keys = this.scene.input.keyboard.addKeys("W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT");
|
||||
this.keys = this.scene.input.keyboard.addKeys(
|
||||
"W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT",
|
||||
);
|
||||
}
|
||||
|
||||
private setupTouch(): void {
|
||||
@@ -585,25 +587,21 @@ src/
|
||||
### Story Implementation Process
|
||||
|
||||
1. **Read Story Requirements:**
|
||||
|
||||
- Understand acceptance criteria
|
||||
- Identify technical requirements
|
||||
- Review performance constraints
|
||||
|
||||
2. **Plan Implementation:**
|
||||
|
||||
- Identify files to create/modify
|
||||
- Consider component architecture
|
||||
- Plan testing approach
|
||||
|
||||
3. **Implement Feature:**
|
||||
|
||||
- Follow TypeScript strict mode
|
||||
- Use established patterns
|
||||
- Maintain 60 FPS performance
|
||||
|
||||
4. **Test Implementation:**
|
||||
|
||||
- Write unit tests for game logic
|
||||
- Test cross-platform functionality
|
||||
- Validate performance targets
|
||||
|
||||
@@ -18,7 +18,6 @@
|
||||
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
|
||||
|
||||
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
|
||||
|
||||
- The entire section as a whole
|
||||
- Individual game elements within the section (specify which element when selecting an action)
|
||||
|
||||
|
||||
@@ -9,7 +9,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Begin by understanding the game design context and goals. Ask clarifying questions if needed to determine the best approach for game-specific ideation.]]
|
||||
|
||||
1. **Establish Game Context**
|
||||
|
||||
- Understand the game genre or opportunity area
|
||||
- Identify target audience and platform constraints
|
||||
- Determine session goals (concept exploration vs. mechanic refinement)
|
||||
@@ -27,7 +26,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **"What If" Game Scenarios**
|
||||
[[LLM: Generate provocative what-if questions that challenge game design assumptions and expand thinking beyond current genre limitations.]]
|
||||
|
||||
- What if players could rewind time in any genre?
|
||||
- What if the game world reacted to the player's real-world location?
|
||||
- What if failure was more rewarding than success?
|
||||
@@ -36,7 +34,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Cross-Genre Fusion**
|
||||
[[LLM: Help user combine unexpected game genres and mechanics to create unique experiences.]]
|
||||
|
||||
- "How might [genre A] mechanics work in [genre B]?"
|
||||
- Puzzle mechanics in action games
|
||||
- Dating sim elements in strategy games
|
||||
@@ -45,7 +42,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Player Motivation Reversal**
|
||||
[[LLM: Flip traditional player motivations to reveal new gameplay possibilities.]]
|
||||
|
||||
- What if losing was the goal?
|
||||
- What if cooperation was forced in competitive games?
|
||||
- What if players had to help their enemies?
|
||||
@@ -62,7 +58,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **SCAMPER for Game Mechanics**
|
||||
[[LLM: Guide through each SCAMPER prompt specifically for game design.]]
|
||||
|
||||
- **S** = Substitute: What mechanics can be substituted? (walking → flying → swimming)
|
||||
- **C** = Combine: What systems can be merged? (inventory + character growth)
|
||||
- **A** = Adapt: What mechanics from other media? (books, movies, sports)
|
||||
@@ -73,7 +68,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Agency Spectrum**
|
||||
[[LLM: Explore different levels of player control and agency across game systems.]]
|
||||
|
||||
- Full Control: Direct character movement, combat, building
|
||||
- Indirect Control: Setting rules, giving commands, environmental changes
|
||||
- Influence Only: Suggestions, preferences, emotional reactions
|
||||
@@ -81,7 +75,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Temporal Game Design**
|
||||
[[LLM: Explore how time affects gameplay and player experience.]]
|
||||
|
||||
- Real-time vs. turn-based mechanics
|
||||
- Time travel and manipulation
|
||||
- Persistent vs. session-based progress
|
||||
@@ -92,7 +85,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Emotion-First Design**
|
||||
[[LLM: Start with target emotions and work backward to mechanics that create them.]]
|
||||
|
||||
- Target Emotion: Wonder → Mechanics: Discovery, mystery, scale
|
||||
- Target Emotion: Triumph → Mechanics: Challenge, skill growth, recognition
|
||||
- Target Emotion: Connection → Mechanics: Cooperation, shared goals, communication
|
||||
@@ -100,7 +92,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Archetype Brainstorming**
|
||||
[[LLM: Design for different player types and motivations.]]
|
||||
|
||||
- Achievers: Progression, completion, mastery
|
||||
- Explorers: Discovery, secrets, world-building
|
||||
- Socializers: Interaction, cooperation, community
|
||||
@@ -109,7 +100,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Accessibility-First Innovation**
|
||||
[[LLM: Generate ideas that make games more accessible while creating new gameplay.]]
|
||||
|
||||
- Visual impairment considerations leading to audio-focused mechanics
|
||||
- Motor accessibility inspiring one-handed or simplified controls
|
||||
- Cognitive accessibility driving clear feedback and pacing
|
||||
@@ -119,7 +109,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Environmental Storytelling**
|
||||
[[LLM: Brainstorm ways the game world itself tells stories without explicit narrative.]]
|
||||
|
||||
- How does the environment show history?
|
||||
- What do interactive objects reveal about characters?
|
||||
- How can level design communicate mood?
|
||||
@@ -127,7 +116,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player-Generated Narrative**
|
||||
[[LLM: Explore ways players create their own stories through gameplay.]]
|
||||
|
||||
- Emergent storytelling through player choices
|
||||
- Procedural narrative generation
|
||||
- Player-to-player story sharing
|
||||
@@ -135,7 +123,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Genre Expectation Subversion**
|
||||
[[LLM: Identify and deliberately subvert player expectations within genres.]]
|
||||
|
||||
- Fantasy RPG where magic is mundane
|
||||
- Horror game where monsters are friendly
|
||||
- Racing game where going slow is optimal
|
||||
@@ -145,7 +132,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Platform-Specific Design**
|
||||
[[LLM: Generate ideas that leverage unique platform capabilities.]]
|
||||
|
||||
- Mobile: GPS, accelerometer, camera, always-connected
|
||||
- Web: URLs, tabs, social sharing, real-time collaboration
|
||||
- Console: Controllers, TV viewing, couch co-op
|
||||
@@ -153,7 +139,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Constraint-Based Creativity**
|
||||
[[LLM: Use technical or design constraints as creative catalysts.]]
|
||||
|
||||
- One-button games
|
||||
- Games without graphics
|
||||
- Games that play in notification bars
|
||||
@@ -199,19 +184,16 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Guide the brainstorming session with appropriate pacing for game design exploration.]]
|
||||
|
||||
1. **Inspiration Phase** (10-15 min)
|
||||
|
||||
- Reference existing games and mechanics
|
||||
- Explore player experiences and emotions
|
||||
- Gather visual and thematic inspiration
|
||||
|
||||
2. **Divergent Exploration** (25-35 min)
|
||||
|
||||
- Generate many game concepts or mechanics
|
||||
- Use expansion and fusion techniques
|
||||
- Encourage wild and impossible ideas
|
||||
|
||||
3. **Player-Centered Filtering** (15-20 min)
|
||||
|
||||
- Consider target audience reactions
|
||||
- Evaluate emotional impact and engagement
|
||||
- Group ideas by player experience goals
|
||||
|
||||
@@ -355,34 +355,29 @@ Ask the user if they want to work through the checklist:
|
||||
Generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall game architecture readiness (High/Medium/Low)
|
||||
- Critical risks for game development
|
||||
- Key strengths of the game architecture
|
||||
- Unity-specific assessment
|
||||
|
||||
2. Game Systems Analysis
|
||||
|
||||
- Pass rate for each major system section
|
||||
- Most concerning gaps in game architecture
|
||||
- Systems requiring immediate attention
|
||||
- Unity integration completeness
|
||||
|
||||
3. Performance Risk Assessment
|
||||
|
||||
- Top 5 performance risks for the game
|
||||
- Mobile platform specific concerns
|
||||
- Frame rate stability risks
|
||||
- Memory usage concerns
|
||||
|
||||
4. Implementation Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Unity-specific improvements needed
|
||||
- Game development workflow enhancements
|
||||
|
||||
5. AI Agent Implementation Readiness
|
||||
|
||||
- Game-specific concerns for AI implementation
|
||||
- Unity component complexity assessment
|
||||
- Areas needing additional clarification
|
||||
|
||||
@@ -25,7 +25,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
1. **Requirements Met:**
|
||||
|
||||
[[LLM: Be specific - list each requirement and whether it's complete. Include game-specific requirements from GDD]]
|
||||
|
||||
- [ ] All functional requirements specified in the story are implemented.
|
||||
- [ ] All acceptance criteria defined in the story are met.
|
||||
- [ ] Game Design Document (GDD) requirements referenced in the story are implemented.
|
||||
@@ -34,7 +33,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
2. **Coding Standards & Project Structure:**
|
||||
|
||||
[[LLM: Code quality matters for maintainability. Check Unity-specific patterns and C# standards]]
|
||||
|
||||
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
|
||||
- [ ] All new/modified code aligns with `Project Structure` (Scripts/, Prefabs/, Scenes/, etc.).
|
||||
- [ ] Adherence to `Tech Stack` for Unity version and packages used.
|
||||
@@ -48,7 +46,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
3. **Testing:**
|
||||
|
||||
[[LLM: Testing proves your code works. Include Unity-specific testing with NUnit and manual testing]]
|
||||
|
||||
- [ ] All required unit tests (NUnit) as per the story and testing strategy are implemented.
|
||||
- [ ] All required integration tests (if applicable) are implemented.
|
||||
- [ ] Manual testing performed in Unity Editor for all game functionality.
|
||||
@@ -60,7 +57,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
4. **Functionality & Verification:**
|
||||
|
||||
[[LLM: Did you actually run and test your code in Unity? Be specific about game mechanics tested]]
|
||||
|
||||
- [ ] Functionality has been manually verified in Unity Editor and play mode.
|
||||
- [ ] Game mechanics work as specified in the GDD.
|
||||
- [ ] Player controls and input handling work correctly.
|
||||
@@ -73,7 +69,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
5. **Story Administration:**
|
||||
|
||||
[[LLM: Documentation helps the next developer. Include Unity-specific implementation notes]]
|
||||
|
||||
- [ ] All tasks within the story file are marked as complete.
|
||||
- [ ] Any clarifications or decisions made during development are documented.
|
||||
- [ ] Unity-specific implementation details documented (scene changes, prefab modifications).
|
||||
@@ -83,7 +78,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
6. **Dependencies, Build & Configuration:**
|
||||
|
||||
[[LLM: Build issues block everyone. Ensure Unity project builds for all target platforms]]
|
||||
|
||||
- [ ] Unity project builds successfully without errors.
|
||||
- [ ] Project builds for all target platforms (desktop/mobile as specified).
|
||||
- [ ] Any new Unity packages or Asset Store items were pre-approved OR approved by user.
|
||||
@@ -95,7 +89,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
7. **Game-Specific Quality:**
|
||||
|
||||
[[LLM: Game quality matters. Check performance, game feel, and player experience]]
|
||||
|
||||
- [ ] Frame rate meets target (30/60 FPS) on all platforms.
|
||||
- [ ] Memory usage within acceptable limits.
|
||||
- [ ] Game feel and responsiveness meet design requirements.
|
||||
@@ -107,7 +100,6 @@ The goal is quality delivery, not just checking boxes.]]
|
||||
8. **Documentation (If Applicable):**
|
||||
|
||||
[[LLM: Good documentation prevents future confusion. Include Unity-specific docs]]
|
||||
|
||||
- [ ] Code documentation (XML comments) for public APIs complete.
|
||||
- [ ] Unity component documentation in Inspector updated.
|
||||
- [ ] User-facing documentation updated, if changes impact players.
|
||||
|
||||
@@ -270,7 +270,6 @@ that can handle [specific game requirements] with stable performance."
|
||||
**Prerequisites**: Game planning documents must exist in `docs/` folder of Unity project
|
||||
|
||||
1. **Document Sharding** (CRITICAL STEP for Game Development):
|
||||
|
||||
- Documents created by Game Designer/Architect (in Web or IDE) MUST be sharded for development
|
||||
- Use core BMad agents or tools to shard:
|
||||
a) **Manual**: Use core BMad `shard-doc` task if available
|
||||
@@ -293,20 +292,17 @@ Resulting Unity Project Folder Structure:
|
||||
3. **Game Development Cycle** (Sequential, one game story at a time):
|
||||
|
||||
**CRITICAL CONTEXT MANAGEMENT for Unity Development**:
|
||||
|
||||
- **Context windows matter!** Always use fresh, clean context windows
|
||||
- **Model selection matters!** Use most powerful thinking model for Game SM story creation
|
||||
- **ALWAYS start new chat between Game SM, Game Dev, and QA work**
|
||||
|
||||
**Step 1 - Game Story Creation**:
|
||||
|
||||
- **NEW CLEAN CHAT** → Select powerful model → `/bmad2du/game-sm` → `*draft`
|
||||
- Game SM executes create-game-story task using `game-story-tmpl`
|
||||
- Review generated story in `docs/game-stories/`
|
||||
- Update status from "Draft" to "Approved"
|
||||
|
||||
**Step 2 - Unity Game Story Implementation**:
|
||||
|
||||
- **NEW CLEAN CHAT** → `/bmad2du/game-developer`
|
||||
- Agent asks which game story to implement
|
||||
- Include story file content to save game dev agent lookup time
|
||||
@@ -315,7 +311,6 @@ Resulting Unity Project Folder Structure:
|
||||
- Game Dev marks story as "Review" when complete with all Unity tests passing
|
||||
|
||||
**Step 3 - Game QA Review**:
|
||||
|
||||
- **NEW CLEAN CHAT** → Use core `@qa` agent → execute review-story task
|
||||
- QA performs senior Unity developer code review
|
||||
- QA can refactor and improve Unity code directly
|
||||
@@ -355,14 +350,12 @@ Since this expansion pack doesn't include specific brownfield templates, you'll
|
||||
|
||||
1. **Upload Unity project to Web UI** (GitHub URL, files, or zip)
|
||||
2. **Create adapted Game Design Document**: `/bmad2du/game-designer` - Modify `game-design-doc-tmpl` to include:
|
||||
|
||||
- Analysis of existing game systems
|
||||
- Integration points for new features
|
||||
- Compatibility requirements
|
||||
- Risk assessment for changes
|
||||
|
||||
3. **Game Architecture Planning**:
|
||||
|
||||
- Use `/bmad2du/game-architect` with `game-architecture-tmpl`
|
||||
- Focus on how new features integrate with existing Unity systems
|
||||
- Plan for gradual rollout and testing
|
||||
|
||||
@@ -531,25 +531,21 @@ Assets/
|
||||
### Story Implementation Process
|
||||
|
||||
1. **Read Story Requirements:**
|
||||
|
||||
- Understand acceptance criteria
|
||||
- Identify technical requirements
|
||||
- Review performance constraints
|
||||
|
||||
2. **Plan Implementation:**
|
||||
|
||||
- Identify files to create/modify
|
||||
- Consider Unity's component-based architecture
|
||||
- Plan testing approach
|
||||
|
||||
3. **Implement Feature:**
|
||||
|
||||
- Write clean C# code following all guidelines
|
||||
- Use established patterns
|
||||
- Maintain stable FPS performance
|
||||
|
||||
4. **Test Implementation:**
|
||||
|
||||
- Write edit mode tests for game logic
|
||||
- Write play mode tests for integration testing
|
||||
- Test cross-platform functionality
|
||||
|
||||
@@ -18,7 +18,6 @@
|
||||
2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
|
||||
|
||||
3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
|
||||
|
||||
- The entire section as a whole
|
||||
- Individual game elements within the section (specify which element when selecting an action)
|
||||
|
||||
|
||||
@@ -14,7 +14,6 @@
|
||||
### 1. Initial Setup & Mode Selection
|
||||
|
||||
- **Acknowledge Task & Inputs:**
|
||||
|
||||
- Confirm with the user that the "Game Development Correct Course Task" is being initiated.
|
||||
- Verify the change trigger (e.g., performance issue, platform constraint, gameplay feedback, technical blocker).
|
||||
- Confirm access to relevant game artifacts:
|
||||
@@ -35,7 +34,6 @@
|
||||
### 2. Execute Game Development Checklist Analysis
|
||||
|
||||
- Systematically work through the game-change-checklist sections:
|
||||
|
||||
1. **Change Context & Game Impact**
|
||||
2. **Feature/System Impact Analysis**
|
||||
3. **Technical Artifact Conflict Resolution**
|
||||
@@ -60,7 +58,6 @@
|
||||
Based on the analysis and agreed path forward:
|
||||
|
||||
- **Identify affected game artifacts requiring updates:**
|
||||
|
||||
- GDD sections (mechanics, systems, progression)
|
||||
- Technical specifications (architecture, performance targets)
|
||||
- Unity-specific configurations (build settings, quality settings)
|
||||
@@ -69,7 +66,6 @@ Based on the analysis and agreed path forward:
|
||||
- Platform-specific adaptations
|
||||
|
||||
- **Draft explicit changes for each artifact:**
|
||||
|
||||
- **Game Stories:** Revise story text, Unity-specific acceptance criteria, technical constraints
|
||||
- **Technical Specs:** Update architecture diagrams, component hierarchies, performance budgets
|
||||
- **Unity Configurations:** Propose settings changes, optimization strategies, platform variants
|
||||
@@ -89,14 +85,12 @@ Based on the analysis and agreed path forward:
|
||||
- Create a comprehensive proposal document containing:
|
||||
|
||||
**A. Change Summary:**
|
||||
|
||||
- Original issue (performance, gameplay, technical constraint)
|
||||
- Game systems affected
|
||||
- Platform/performance implications
|
||||
- Chosen solution approach
|
||||
|
||||
**B. Technical Impact Analysis:**
|
||||
|
||||
- Unity architecture changes needed
|
||||
- Performance implications (with metrics)
|
||||
- Platform compatibility effects
|
||||
@@ -104,14 +98,12 @@ Based on the analysis and agreed path forward:
|
||||
- Third-party dependency impacts
|
||||
|
||||
**C. Specific Proposed Edits:**
|
||||
|
||||
- For each game story: "Change Story GS-X.Y from: [old] To: [new]"
|
||||
- For technical specs: "Update Unity Architecture Section X: [changes]"
|
||||
- For GDD: "Modify [Feature] in Section Y: [updates]"
|
||||
- For configurations: "Change [Setting] from [old_value] to [new_value]"
|
||||
|
||||
**D. Implementation Considerations:**
|
||||
|
||||
- Required Unity version updates
|
||||
- Asset reimport needs
|
||||
- Shader recompilation requirements
|
||||
@@ -123,7 +115,6 @@ Based on the analysis and agreed path forward:
|
||||
- Provide the finalized document to the user
|
||||
|
||||
- **Based on change scope:**
|
||||
|
||||
- **Minor adjustments (can be handled in current sprint):**
|
||||
- Confirm task completion
|
||||
- Suggest handoff to game-dev agent for implementation
|
||||
@@ -137,7 +128,6 @@ Based on the analysis and agreed path forward:
|
||||
## Output Deliverables
|
||||
|
||||
- **Primary:** "Game Development Change Proposal" document containing:
|
||||
|
||||
- Game-specific change analysis
|
||||
- Technical impact assessment with Unity context
|
||||
- Platform and performance considerations
|
||||
|
||||
@@ -9,7 +9,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Begin by understanding the game design context and goals. Ask clarifying questions if needed to determine the best approach for game-specific ideation.]]
|
||||
|
||||
1. **Establish Game Context**
|
||||
|
||||
- Understand the game genre or opportunity area
|
||||
- Identify target audience and platform constraints
|
||||
- Determine session goals (concept exploration vs. mechanic refinement)
|
||||
@@ -27,7 +26,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **"What If" Game Scenarios**
|
||||
[[LLM: Generate provocative what-if questions that challenge game design assumptions and expand thinking beyond current genre limitations.]]
|
||||
|
||||
- What if players could rewind time in any genre?
|
||||
- What if the game world reacted to the player's real-world location?
|
||||
- What if failure was more rewarding than success?
|
||||
@@ -36,7 +34,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Cross-Genre Fusion**
|
||||
[[LLM: Help user combine unexpected game genres and mechanics to create unique experiences.]]
|
||||
|
||||
- "How might [genre A] mechanics work in [genre B]?"
|
||||
- Puzzle mechanics in action games
|
||||
- Dating sim elements in strategy games
|
||||
@@ -45,7 +42,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Player Motivation Reversal**
|
||||
[[LLM: Flip traditional player motivations to reveal new gameplay possibilities.]]
|
||||
|
||||
- What if losing was the goal?
|
||||
- What if cooperation was forced in competitive games?
|
||||
- What if players had to help their enemies?
|
||||
@@ -62,7 +58,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **SCAMPER for Game Mechanics**
|
||||
[[LLM: Guide through each SCAMPER prompt specifically for game design.]]
|
||||
|
||||
- **S** = Substitute: What mechanics can be substituted? (walking → flying → swimming)
|
||||
- **C** = Combine: What systems can be merged? (inventory + character growth)
|
||||
- **A** = Adapt: What mechanics from other media? (books, movies, sports)
|
||||
@@ -73,7 +68,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Agency Spectrum**
|
||||
[[LLM: Explore different levels of player control and agency across game systems.]]
|
||||
|
||||
- Full Control: Direct character movement, combat, building
|
||||
- Indirect Control: Setting rules, giving commands, environmental changes
|
||||
- Influence Only: Suggestions, preferences, emotional reactions
|
||||
@@ -81,7 +75,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Temporal Game Design**
|
||||
[[LLM: Explore how time affects gameplay and player experience.]]
|
||||
|
||||
- Real-time vs. turn-based mechanics
|
||||
- Time travel and manipulation
|
||||
- Persistent vs. session-based progress
|
||||
@@ -92,7 +85,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Emotion-First Design**
|
||||
[[LLM: Start with target emotions and work backward to mechanics that create them.]]
|
||||
|
||||
- Target Emotion: Wonder → Mechanics: Discovery, mystery, scale
|
||||
- Target Emotion: Triumph → Mechanics: Challenge, skill growth, recognition
|
||||
- Target Emotion: Connection → Mechanics: Cooperation, shared goals, communication
|
||||
@@ -100,7 +92,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player Archetype Brainstorming**
|
||||
[[LLM: Design for different player types and motivations.]]
|
||||
|
||||
- Achievers: Progression, completion, mastery
|
||||
- Explorers: Discovery, secrets, world-building
|
||||
- Socializers: Interaction, cooperation, community
|
||||
@@ -109,7 +100,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Accessibility-First Innovation**
|
||||
[[LLM: Generate ideas that make games more accessible while creating new gameplay.]]
|
||||
|
||||
- Visual impairment considerations leading to audio-focused mechanics
|
||||
- Motor accessibility inspiring one-handed or simplified controls
|
||||
- Cognitive accessibility driving clear feedback and pacing
|
||||
@@ -119,7 +109,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Environmental Storytelling**
|
||||
[[LLM: Brainstorm ways the game world itself tells stories without explicit narrative.]]
|
||||
|
||||
- How does the environment show history?
|
||||
- What do interactive objects reveal about characters?
|
||||
- How can level design communicate mood?
|
||||
@@ -127,7 +116,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Player-Generated Narrative**
|
||||
[[LLM: Explore ways players create their own stories through gameplay.]]
|
||||
|
||||
- Emergent storytelling through player choices
|
||||
- Procedural narrative generation
|
||||
- Player-to-player story sharing
|
||||
@@ -135,7 +123,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
3. **Genre Expectation Subversion**
|
||||
[[LLM: Identify and deliberately subvert player expectations within genres.]]
|
||||
|
||||
- Fantasy RPG where magic is mundane
|
||||
- Horror game where monsters are friendly
|
||||
- Racing game where going slow is optimal
|
||||
@@ -145,7 +132,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
1. **Platform-Specific Design**
|
||||
[[LLM: Generate ideas that leverage unique platform capabilities.]]
|
||||
|
||||
- Mobile: GPS, accelerometer, camera, always-connected
|
||||
- Web: URLs, tabs, social sharing, real-time collaboration
|
||||
- Console: Controllers, TV viewing, couch co-op
|
||||
@@ -153,7 +139,6 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
|
||||
2. **Constraint-Based Creativity**
|
||||
[[LLM: Use technical or design constraints as creative catalysts.]]
|
||||
|
||||
- One-button games
|
||||
- Games without graphics
|
||||
- Games that play in notification bars
|
||||
@@ -199,19 +184,16 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Guide the brainstorming session with appropriate pacing for game design exploration.]]
|
||||
|
||||
1. **Inspiration Phase** (10-15 min)
|
||||
|
||||
- Reference existing games and mechanics
|
||||
- Explore player experiences and emotions
|
||||
- Gather visual and thematic inspiration
|
||||
|
||||
2. **Divergent Exploration** (25-35 min)
|
||||
|
||||
- Generate many game concepts or mechanics
|
||||
- Use expansion and fusion techniques
|
||||
- Encourage wild and impossible ideas
|
||||
|
||||
3. **Player-Centered Filtering** (15-20 min)
|
||||
|
||||
- Consider target audience reactions
|
||||
- Evaluate emotional impact and engagement
|
||||
- Group ideas by player experience goals
|
||||
|
||||
@@ -247,17 +247,14 @@ A comprehensive 16-section checklist covering:
|
||||
### Common Issues
|
||||
|
||||
1. **Infrastructure Drift**
|
||||
|
||||
- Solution: Implement drift detection in IaC pipelines
|
||||
- Prevention: Restrict manual changes, enforce GitOps
|
||||
|
||||
2. **Cost Overruns**
|
||||
|
||||
- Solution: Implement cost monitoring and alerts
|
||||
- Prevention: Resource tagging, budget limits
|
||||
|
||||
3. **Performance Problems**
|
||||
|
||||
- Solution: Review monitoring data, scale resources
|
||||
- Prevention: Load testing, capacity planning
|
||||
|
||||
|
||||
@@ -32,7 +32,6 @@ To conduct a thorough review of existing infrastructure to identify improvement
|
||||
### 3. Conduct Systematic Review
|
||||
|
||||
- **If "Incremental Mode" was selected:**
|
||||
|
||||
- For each section of the infrastructure checklist:
|
||||
- **a. Present Section Focus:** Explain what aspects of infrastructure this section reviews
|
||||
- **b. Work Through Items:** Examine each checklist item against current infrastructure
|
||||
|
||||
@@ -55,7 +55,6 @@ To comprehensively validate platform infrastructure changes against security, re
|
||||
### 4. Execute Comprehensive Platform Validation Process
|
||||
|
||||
- **If "Incremental Mode" was selected:**
|
||||
|
||||
- For each section of the infrastructure checklist (Sections 1-16):
|
||||
- **a. Present Section Purpose:** Explain what this section validates and why it's important for platform operations
|
||||
- **b. Work Through Items:** Present each checklist item, guide the user through validation, and document compliance or gaps
|
||||
|
||||
Reference in New Issue
Block a user