bmad-method 4.37.0-beta.6 → 5.0.0-beta.1

package/docs/working-in-the-brownfield.md

@@ -27,7 +27,7 @@ If you have just completed an MVP with BMad, and you want to continue with post-
 ## The Complete Brownfield Workflow
 
 1. **Follow the [<ins>User Guide - Installation</ins>](user-guide.md#installation) steps to setup your agent in the web.**
-2. **Generate a 'flattened' single file of your entire codebase** run: ```npx bmad-method flatten```
+2. **Generate a 'flattened' single file of your entire codebase** run: `npx bmad-method flatten`
 
 ### Choose Your Approach
 
@@ -76,7 +76,7 @@ The PM will:
 *document-project
 ```
 
-The analyst will:
+The architect will:
 
 - **Ask about your focus** if no PRD was provided
 - **Offer options**: Create PRD, provide requirements, or describe the enhancement
@@ -85,11 +85,11 @@ The analyst will:
 - **Skip unrelated areas** to keep docs lean
 - **Generate ONE architecture document** for all environments
 
-The analyst creates:
+The architect creates:
 
 - **One comprehensive architecture document** following fullstack-architecture template
 - **Covers all system aspects** in a single file
-- **Easy to copy and save** as `docs/project-architecture.md`
+- **Easy to copy and save** as `docs/architecture.md`
 - **Can be sharded later** in IDE if desired
 
 For example, if you say "Add payment processing to user service":
@@ -108,10 +108,10 @@ For example, if you say "Add payment processing to user service":
 2. **Upload your project**:
    - **Option A**: Paste your GitHub repository URL directly
    - **Option B**: Upload your flattened-codebase.xml file
-3. **Load the analyst agent**: Upload `dist/agents/architect.txt`
+3. **Load the architect agent**: Upload `dist/agents/architect.txt`
 4. **Run documentation**: Type `*document-project`
 
-The analyst will generate comprehensive documentation of everything.
+The architect will generate comprehensive documentation of everything.
 
 #### Phase 2: Plan Your Enhancement
 
@@ -206,19 +206,20 @@ The PO ensures:
 ### Phase 4: Save and Shard Documents
 
 1. Save your PRD and Architecture as:
-   docs/brownfield-prd.md
-   docs/brownfield-architecture.md
+   docs/prd.md
+   docs/architecture.md
+   (Note: You can optionally prefix with 'brownfield-' if managing multiple versions)
 2. Shard your docs:
    In your IDE
 
    ```bash
    @po
-   shard docs/brownfield-prd.md
+   shard docs/prd.md
    ```
 
    ```bash
    @po
-   shard docs/brownfield-architecture.md
+   shard docs/architecture.md
    ```
 
 ### Phase 5: Transition to Development
@@ -255,12 +256,172 @@ Brownfield changes should:
 
 ### 4. Test Integration Thoroughly
 
-Focus testing on:
+#### Why the Test Architect is Critical for Brownfield
+
+In brownfield projects, the Test Architect (Quinn) becomes your safety net against breaking existing functionality. Unlike greenfield where you're building fresh, brownfield requires careful validation that new changes don't destabilize what already works.
+
+#### Brownfield-Specific Testing Challenges
+
+The Test Architect addresses unique brownfield complexities:
+
+| **Challenge**               | **How Test Architect Helps**                      | **Command**         |
+| --------------------------- | ------------------------------------------------- | ------------------- |
+| **Regression Risks**        | Identifies which existing features might break    | `*risk`             |
+| **Legacy Dependencies**     | Maps integration points and hidden dependencies   | `*trace`            |
+| **Performance Degradation** | Validates no slowdown in existing flows           | `*nfr`              |
+| **Coverage Gaps**           | Finds untested legacy code that new changes touch | `*design`           |
+| **Breaking Changes**        | Detects API/contract violations                   | `*review`           |
+| **Migration Safety**        | Validates data transformations and rollback plans | `*risk` + `*review` |
+
+#### Complete Test Architect Workflow for Brownfield
+
+##### Stage 1: Before Development (Risk & Strategy)
 
-- Integration points
-- Existing functionality (regression)
-- Performance impact
-- Data migrations
+**CRITICAL FOR BROWNFIELD - Run These First:**
+
+```bash
+# 1. RISK ASSESSMENT (Run IMMEDIATELY after story creation)
+@qa *risk {brownfield-story}
+# Identifies: Legacy dependencies, breaking changes, integration points
+# Output: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
+# Brownfield Focus:
+#   - Regression probability scoring
+#   - Affected downstream systems
+#   - Data migration risks
+#   - Rollback complexity
+
+# 2. TEST DESIGN (After risk assessment)
+@qa *design {brownfield-story}
+# Creates: Regression test strategy + new feature tests
+# Output: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+# Brownfield Focus:
+#   - Existing functionality that needs regression tests
+#   - Integration test requirements
+#   - Performance benchmarks to maintain
+#   - Feature flag test scenarios
+```
+
+##### Stage 2: During Development (Continuous Validation)
+
+**Monitor Integration Health While Coding:**
+
+```bash
+# 3. REQUIREMENTS TRACING (Mid-development checkpoint)
+@qa *trace {brownfield-story}
+# Maps: New requirements + existing functionality preservation
+# Output: docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
+# Brownfield Focus:
+#   - Existing features that must still work
+#   - New/old feature interactions
+#   - API contract preservation
+#   - Missing regression test coverage
+
+# 4. NFR VALIDATION (Before considering "done")
+@qa *nfr {brownfield-story}
+# Validates: Performance, security, reliability unchanged
+# Output: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
+# Brownfield Focus:
+#   - Performance regression detection
+#   - Security implications of integrations
+#   - Backward compatibility validation
+#   - Load/stress on legacy components
+```
+
+##### Stage 3: Code Review (Deep Integration Analysis)
+
+**Comprehensive Brownfield Review:**
+
+```bash
+# 5. FULL REVIEW (When development complete)
+@qa *review {brownfield-story}
+# Performs: Deep analysis + active refactoring
+# Outputs:
+#   - QA Results in story file
+#   - Gate file: docs/qa/gates/{epic}.{story}-{slug}.yml
+```
+
+The review specifically analyzes:
+
+- **API Breaking Changes**: Validates all existing contracts maintained
+- **Data Migration Safety**: Checks transformation logic and rollback procedures
+- **Performance Regression**: Compares against baseline metrics
+- **Integration Points**: Validates all touchpoints with legacy code
+- **Feature Flag Logic**: Ensures proper toggle behavior
+- **Dependency Impacts**: Maps affected downstream systems
+
+##### Stage 4: Post-Review (Gate Updates)
+
+```bash
+# 6. GATE STATUS UPDATE (After addressing issues)
+@qa *gate {brownfield-story}
+# Updates: Quality gate decision after fixes
+# Output: docs/qa/gates/{epic}.{story}-{slug}.yml
+# Brownfield Considerations:
+#   - May WAIVE certain legacy code issues
+#   - Documents technical debt acceptance
+#   - Tracks migration progress
+```
+
+#### Brownfield-Specific Risk Scoring
+
+The Test Architect uses enhanced risk scoring for brownfield:
+
+| **Risk Category**      | **Brownfield Factors**                     | **Impact on Gate**  |
+| ---------------------- | ------------------------------------------ | ------------------- |
+| **Regression Risk**    | Number of integration points × Age of code | Score ≥9 = FAIL     |
+| **Data Risk**          | Migration complexity × Data volume         | Score ≥6 = CONCERNS |
+| **Performance Risk**   | Current load × Added complexity            | Score ≥6 = CONCERNS |
+| **Compatibility Risk** | API consumers × Contract changes           | Score ≥9 = FAIL     |
+
+#### Brownfield Testing Standards
+
+Quinn enforces additional standards for brownfield:
+
+- **Regression Test Coverage**: Every touched legacy module needs tests
+- **Performance Baselines**: Must maintain or improve current metrics
+- **Rollback Procedures**: Every change needs a rollback plan
+- **Feature Flags**: All risky changes behind toggles
+- **Integration Tests**: Cover all legacy touchpoints
+- **Contract Tests**: Validate API compatibility
+- **Data Validation**: Migration correctness checks
+
+#### Quick Reference: Brownfield Test Commands
+
+| **Scenario**                      | **Commands to Run**                                  | **Order**  | **Why Critical**              |
+| --------------------------------- | ---------------------------------------------------- | ---------- | ----------------------------- |
+| **Adding Feature to Legacy Code** | `*risk` → `*design` → `*trace` → `*review`           | Sequential | Map all dependencies first    |
+| **API Modification**              | `*risk` → `*design` → `*nfr` → `*review`             | Sequential | Prevent breaking consumers    |
+| **Performance-Critical Change**   | `*nfr` early and often → `*review`                   | Continuous | Catch degradation immediately |
+| **Data Migration**                | `*risk` → `*design` → `*trace` → `*review` → `*gate` | Full cycle | Ensure data integrity         |
+| **Bug Fix in Complex System**     | `*risk` → `*trace` → `*review`                       | Focused    | Prevent side effects          |
+
+#### Integration with Brownfield Scenarios
+
+**Scenario-Specific Guidance:**
+
+1. **Legacy Code Modernization**
+   - Start with `*risk` to map all dependencies
+   - Use `*design` to plan strangler fig approach
+   - Run `*trace` frequently to ensure nothing breaks
+   - `*review` with focus on gradual migration
+
+2. **Adding Features to Monolith**
+   - `*risk` identifies integration complexity
+   - `*design` plans isolation strategies
+   - `*nfr` monitors performance impact
+   - `*review` validates no monolith degradation
+
+3. **Microservice Extraction**
+   - `*risk` maps service boundaries
+   - `*trace` ensures functionality preservation
+   - `*nfr` validates network overhead acceptable
+   - `*gate` documents accepted trade-offs
+
+4. **Database Schema Changes**
+   - `*risk` assesses migration complexity
+   - `*design` plans backward-compatible approach
+   - `*trace` maps all affected queries
+   - `*review` validates migration safety
 
 ### 5. Communicate Changes
 
@@ -277,29 +438,63 @@ Document:
 
 1. Document existing system
 2. Create brownfield PRD focusing on integration
-3. Architecture emphasizes compatibility
-4. Stories include integration tasks
+3. **Test Architect Early Involvement**:
+   - Run `@qa *risk` on draft stories to identify integration risks
+   - Use `@qa *design` to plan regression test strategy
+4. Architecture emphasizes compatibility
+5. Stories include integration tasks with test requirements
+6. **During Development**:
+   - Developer runs `@qa *trace` to verify coverage
+   - Use `@qa *nfr` to monitor performance impact
+7. **Review Stage**: `@qa *review` validates integration safety
 
 ### Scenario 2: Modernizing Legacy Code
 
 1. Extensive documentation phase
 2. PRD includes migration strategy
-3. Architecture plans gradual transition
-4. Stories follow strangler fig pattern
+3. **Test Architect Strategy Planning**:
+   - `@qa *risk` assesses modernization complexity
+   - `@qa *design` plans parallel testing approach
+4. Architecture plans gradual transition (strangler fig pattern)
+5. Stories follow incremental modernization with:
+   - Regression tests for untouched legacy code
+   - Integration tests for new/old boundaries
+   - Performance benchmarks at each stage
+6. **Continuous Validation**: Run `@qa *trace` after each increment
+7. **Gate Management**: Use `@qa *gate` to track technical debt acceptance
 
 ### Scenario 3: Bug Fix in Complex System
 
 1. Document relevant subsystems
 2. Use `create-brownfield-story` for focused fix
-3. Include regression test requirements
-4. QA validates no side effects
+3. **Test Architect Risk Assessment**: Run `@qa *risk` to identify side effect potential
+4. Include regression test requirements from `@qa *design` output
+5. **During Fix**: Use `@qa *trace` to map affected functionality
+6. **Before Commit**: Run `@qa *review` for comprehensive validation
+7. Test Architect validates no side effects using:
+   - Risk profiling for side effect analysis (probability × impact scoring)
+   - Trace matrix to ensure fix doesn't break related features
+   - NFR assessment to verify performance/security unchanged
+   - Gate decision documents fix safety
 
 ### Scenario 4: API Integration
 
 1. Document existing API patterns
 2. PRD defines integration requirements
-3. Architecture ensures consistent patterns
-4. Stories include API documentation updates
+3. **Test Architect Contract Analysis**:
+   - `@qa *risk` identifies breaking change potential
+   - `@qa *design` creates contract test strategy
+4. Architecture ensures consistent patterns
+5. **API Testing Focus**:
+   - Contract tests for backward compatibility
+   - Integration tests for new endpoints
+   - Performance tests for added load
+6. Stories include API documentation updates
+7. **Validation Checkpoints**:
+   - `@qa *trace` maps all API consumers
+   - `@qa *nfr` validates response times
+   - `@qa *review` ensures no breaking changes
+8. **Gate Decision**: Document any accepted breaking changes with migration path
 
 ## Troubleshooting
 
@@ -325,19 +520,37 @@ Document:
 
 ```bash
 # Document existing project
-@architect → *document-project
+@architect *document-project
 
 # Create enhancement PRD
-@pm → *create-brownfield-prd
+@pm *create-brownfield-prd
 
 # Create architecture with integration focus
-@architect → *create-brownfield-architecture
+@architect *create-brownfield-architecture
 
 # Quick epic creation
-@pm → *create-brownfield-epic
+@pm *create-brownfield-epic
 
 # Single story creation
-@pm → *create-brownfield-story
+@pm *create-brownfield-story
+```
+
+### Test Architect Commands for Brownfield
+
+Note: Short forms shown below. Full commands: `*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`
+
+```bash
+# BEFORE DEVELOPMENT (Planning)
+@qa *risk {story}     # Assess regression & integration risks
+@qa *design {story}   # Plan regression + new feature tests
+
+# DURING DEVELOPMENT (Validation)
+@qa *trace {story}    # Verify coverage of old + new
+@qa *nfr {story}      # Check performance degradation
+
+# AFTER DEVELOPMENT (Review)
+@qa *review {story}   # Deep integration analysis
+@qa *gate {story}     # Update quality decision
 ```
 
 ### Decision Tree
@@ -352,13 +565,33 @@ Do you have a large codebase or monorepo?
 
 Is this a major enhancement affecting multiple systems?
 ├─ Yes → Full Brownfield Workflow
+│   └─ ALWAYS run Test Architect *risk + *design first
 └─ No → Is this more than a simple bug fix?
-    ├─ Yes → brownfield-create-epic
-    └─ No → brownfield-create-story
+    ├─ Yes → *create-brownfield-epic
+    │   └─ Run Test Architect *risk for integration points
+    └─ No → *create-brownfield-story
+        └─ Still run *risk if touching critical paths
+
+Does the change touch legacy code?
+├─ Yes → Test Architect is MANDATORY
+│   ├─ *risk → Identify regression potential
+│   ├─ *design → Plan test coverage
+│   └─ *review → Validate no breakage
+└─ No → Test Architect is RECOMMENDED
+    └─ *review → Ensure quality standards
 ```
 
 ## Conclusion
 
-Brownfield development with BMad-Method provides structure and safety when modifying existing systems. The key is providing comprehensive context through documentation, using specialized templates that consider integration requirements, and following workflows that respect existing constraints while enabling progress.
+Brownfield development with BMad Method provides structure and safety when modifying existing systems. The Test Architect becomes your critical safety net, using risk assessment, regression testing, and continuous validation to ensure new changes don't destabilize existing functionality.
+
+**The Brownfield Success Formula:**
+
+1. **Document First** - Understand what exists
+2. **Assess Risk Early** - Use Test Architect `*risk` before coding
+3. **Plan Test Strategy** - Design regression + new feature tests
+4. **Validate Continuously** - Check integration health during development
+5. **Review Comprehensively** - Deep analysis before committing
+6. **Gate Decisively** - Document quality decisions
 
-Remember: **Document First, Plan Carefully, Integrate Safely**
+Remember: **In brownfield, the Test Architect isn't optional - it's your insurance policy against breaking production.**

package/expansion-packs/Complete AI Agent System - Blank Templates & Google Cloud Setup/README.md

@@ -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
 
@@ -106,4 +106,4 @@ This expansion pack has a comprehensive structure to get you started:
 
 ## Contributing
 
-Contributions are welcome\! Please follow the main project's `CONTRIBUTING.md` guidelines. For major changes or new features for this expansion pack, please open an issue or discussion first.
+Contributions are welcome\! Please follow the main project's `CONTRIBUTING.md` guidelines. For major changes or new features for this expansion pack, please open an issue or discussion first.

package/expansion-packs/bmad-2d-phaser-game-dev/data/bmad-kb.md

@@ -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

package/expansion-packs/bmad-2d-phaser-game-dev/data/development-guidelines.md

@@ -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

package/expansion-packs/bmad-2d-phaser-game-dev/tasks/advanced-elicitation.md

@@ -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)
 

package/expansion-packs/bmad-2d-phaser-game-dev/tasks/game-design-brainstorming.md

@@ -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