bmad-method 5.1.2 → 6.0.0-alpha.0

package/src/modules/bmm/testarch/tea-knowledge.md

@@ -0,0 +1,275 @@
+<!-- Powered by BMAD-CORE™ -->
+
+# Murat Test Architecture Foundations (Slim Brief)
+
+This brief distills Murat Ozcan's testing philosophy used by the Test Architect agent. Use it as the north star after loading `tea-commands.csv`.
+
+## Core Principles
+
+- Cost vs confidence: cost = creation + execution + maintenance. Push confidence where impact is highest and skip redundant checks.
+- Engineering assumes failure: predict what breaks, defend with tests, learn from every failure. A single failing test means the software is not ready.
+- Quality is team work. Story estimates include testing, documentation, and deployment work required to ship safely.
+- Missing test coverage is feature debt (hurts customers), not mere tech debt—treat it with the same urgency as functionality gaps.
+- Shared mutable state is the source of all evil: design fixtures and helpers so each test owns its data.
+- Composition over inheritance: prefer functional helpers and fixtures that compose behaviour; page objects and deep class trees hide duplication.
+- Setup via API, assert via UI. Keep tests user-centric while priming state through fast interfaces.
+- One test = one concern. Explicit assertions live in the test body, not buried in helpers.
+
+## Patterns & Heuristics
+
+- Selector order: `data-cy` / `data-testid` -> ARIA -> text. Avoid brittle CSS, IDs, or index based locators.
+- Network boundary is the mock boundary. Stub at the edge, never mid-service unless risk demands.
+- **Network-first pattern**: ALWAYS intercept before navigation: `const call = interceptNetwork(); await page.goto(); await call;`
+- Deterministic waits only: await specific network responses, elements disappearing, or event hooks. Ban fixed sleeps.
+- **Fixture architecture (The Murat Way)**:
+  ```typescript
+  // 1. Pure function first (testable independently)
+  export async function apiRequest({ request, method, url, data }) {
+    /* implementation */
+  }
+  // 2. Fixture wrapper
+  export const apiRequestFixture = base.extend({
+    apiRequest: async ({ request }, use) => {
+      await use((params) => apiRequest({ request, ...params }));
+    },
+  });
+  // 3. Compose via mergeTests
+  export const test = mergeTests(base, apiRequestFixture, authFixture, networkFixture);
+  ```
+- **Data factories pattern**:
+  ```typescript
+  export const createUser = (overrides = {}) => ({
+    id: faker.string.uuid(),
+    email: faker.internet.email(),
+    ...overrides,
+  });
+  ```
+- Visual debugging: keep component/test runner UIs available (Playwright trace viewer, Cypress runner) to accelerate feedback.
+
+## Risk & Coverage
+
+- Risk score = probability (1-3) × impact (1-3). Score 9 => gate FAIL, ≥6 => CONCERNS. Most stories have 0-1 high risks.
+- Test level ratio: heavy unit/component coverage, but always include E2E for critical journeys and integration seams.
+- Traceability looks for reality: map each acceptance criterion to concrete tests and flag missing coverage or duplicate value.
+- NFR focus areas: Security, Performance, Reliability, Maintainability. Demand evidence (tests, telemetry, alerts) before approving.
+
+## Test Configuration
+
+- **Timeouts**: actionTimeout 15s, navigationTimeout 30s, testTimeout 60s, expectTimeout 10s
+- **Reporters**: HTML (never auto-open) + JUnit XML for CI integration
+- **Media**: screenshot only-on-failure, video retain-on-failure
+- **Language Matching**: Tests should match source code language (JS/TS frontend -> JS/TS tests)
+
+## Automation & CI
+
+- Prefer Playwright for multi-language teams, worker parallelism, rich debugging; Cypress suits smaller DX-first repos or component-heavy spikes.
+- **Framework Selection**: Large repo + performance = Playwright, Small repo + DX = Cypress
+- **Component Testing**: Large repos = Vitest (has UI, easy RTL conversion), Small repos = Cypress CT
+- CI pipelines run lint -> unit -> component -> e2e, with selective reruns for flakes and artifacts (videos, traces) on failure.
+- Shard suites to keep feedback tight; treat CI as shared safety net, not a bottleneck.
+- Test selection ideas (32+ strategies): filter by tags/grep (`npm run test -- --grep "@smoke"`), file patterns (`--spec "**/*checkout*"`), changed files (`npm run test:changed`), or test level (`npm run test:unit` / `npm run test:e2e`).
+- Burn-in testing: run new or changed specs multiple times (e.g., 3-10x) to flush flakes before they land in main.
+- Keep helper scripts handy (`scripts/test-changed.sh`, `scripts/burn-in-changed.sh`) so CI and local workflows stay in sync.
+
+## Project Structure & Config
+
+- **Directory structure**:
+  ```
+  project/
+  ├── playwright.config.ts     # Environment-based config loading
+  ├── playwright/
+  │   ├── tests/               # All specs (group by domain: auth/, network/, feature-flags/…)
+  │   ├── support/             # Frequently touched helpers (global-setup, merged-fixtures, ui helpers, factories)
+  │   ├── config/              # Environment configs (base, local, staging, production)
+  │   └── scripts/             # Expert utilities (burn-in, record/playback, maintenance)
+  ```
+- **Environment config pattern**:
+  ```javascript
+  const configs = {
+    local: require('./config/local.config'),
+    staging: require('./config/staging.config'),
+    prod: require('./config/prod.config'),
+  };
+  export default configs[process.env.TEST_ENV || 'local'];
+  ```
+
+## Test Hygiene & Independence
+
+- Tests must be independent and stateless; never rely on execution order.
+- Cleanup all data created during tests (afterEach or API cleanup).
+- Ensure idempotency: same results every run.
+- No shared mutable state; prefer factory functions per test.
+- Tests must run in parallel safely; never commit `.only`.
+- Prefer co-location: component tests next to components, integration in `tests/integration`, etc.
+- Feature flags: centralise enum definitions (e.g., `export const FLAGS = Object.freeze({ NEW_FEATURE: 'new-feature' })`), provide helpers to set/clear targeting, and write dedicated flag tests that clean up targeting after each run.
+
+## CCTDD (Component Test-Driven Development)
+
+- Start with failing component test -> implement minimal component -> refactor.
+- Component tests catch ~70% of bugs before integration.
+- Use `cy.mount()` or `render()` to test components in isolation; focus on user interactions.
+
+## CI Optimization Strategies
+
+- **Parallel execution**: Split by test file, not test case.
+- **Smart selection**: Run only tests affected by changes (dependency graphs, git diff).
+- **Burn-in testing**: Run new/modified tests 3x to catch flakiness early.
+- **HAR recording**: Record network traffic for offline playback in CI.
+- **Selective reruns**: Only rerun failed specs, not entire suite.
+- **Network recording**: capture HAR files during stable runs so CI can replay network traffic when external systems are flaky.
+
+## Package Scripts
+
+- **Essential npm scripts**:
+  ```json
+  "test:e2e": "playwright test",
+  "test:unit": "vitest run",
+  "test:component": "cypress run --component",
+  "test:contract": "jest --testMatch='**/pact/*.spec.ts'",
+  "test:debug": "playwright test --headed",
+  "test:ci": "npm run test:unit && npm run test:e2e",
+  "contract:publish": "pact-broker publish"
+  ```
+
+## Contract Testing (Pact)
+
+- Use for microservices with integration points.
+- Consumer generates contracts, provider verifies.
+- Structure: `pact/` directory at root, `pact/config.ts` for broker settings.
+- Reference repos: pact-js-example-consumer, pact-js-example-provider, pact-js-example-react-consumer.
+
+## Online Resources & Examples
+
+- Fixture architecture: https://github.com/muratkeremozcan/cy-vs-pw-murats-version
+- Playwright patterns: https://github.com/muratkeremozcan/pw-book
+- Component testing (CCTDD): https://github.com/muratkeremozcan/cctdd
+- Contract testing: https://github.com/muratkeremozcan/pact-js-example-consumer
+- Full app example: https://github.com/muratkeremozcan/tour-of-heroes-react-vite-cypress-ts
+- Blog posts: https://dev.to/muratkeremozcan
+
+## Risk Model Details
+
+- TECH: Unmitigated architecture flaws, experimental patterns without fallbacks.
+- SEC: Missing security controls, potential vulnerabilities, unsafe data handling.
+- PERF: SLA-breaking slowdowns, resource exhaustion, lack of caching.
+- DATA: Loss or corruption scenarios, migrations without rollback, inconsistent schemas.
+- BUS: Business or user harm, revenue-impacting failures, compliance gaps.
+- OPS: Deployment, infrastructure, or observability gaps that block releases.
+
+## Probability & Impact Scale
+
+- Probability 1 = Unlikely (standard implementation, low risk).
+- Probability 2 = Possible (edge cases, needs attention).
+- Probability 3 = Likely (known issues, high uncertainty).
+- Impact 1 = Minor (cosmetic, easy workaround).
+- Impact 2 = Degraded (partial feature loss, manual workaround needed).
+- Impact 3 = Critical (blocker, data/security/regulatory impact).
+- Scores: 9 => FAIL, 6-8 => CONCERNS, 4 => monitor, 1-3 => note only.
+
+## Test Design Frameworks
+
+- Use `docs/docs-v6/v6-bmm/test-levels-framework.md` for level selection and anti-patterns.
+- Use `docs/docs-v6/v6-bmm/test-priorities-matrix.md` for P0-P3 priority criteria.
+- Naming convention: `{epic}.{story}-{LEVEL}-{sequence}` (e.g., `2.4-E2E-01`).
+- Tie each scenario to risk mitigations or acceptance criteria.
+
+## Test Quality Definition of Done
+
+- No hard waits (`page.waitForTimeout`, `cy.wait(ms)`)—use deterministic waits.
+- Each test < 300 lines and executes in <= 1.5 minutes.
+- Tests are stateless, parallel-safe, and self-cleaning.
+- No conditional logic in tests (`if/else`, `try/catch` controlling flow).
+- Explicit assertions live in tests, not hidden in helpers.
+- Tests must run green locally and in CI with identical commands.
+- A test delivers value only when it has failed at least once—design suites so they regularly catch regressions during development.
+
+## NFR Status Criteria
+
+- **Security**: PASS (auth, authz, secrets handled), CONCERNS (minor gaps), FAIL (critical exposure).
+- **Performance**: PASS (meets targets, profiling evidence), CONCERNS (approaching limits), FAIL (breaches limits, leaks).
+- **Reliability**: PASS (error handling, retries, health checks), CONCERNS (partial coverage), FAIL (no recovery, crashes).
+- **Maintainability**: PASS (tests + docs + clean code), CONCERNS (duplication, low coverage), FAIL (no tests, tangled code).
+- Unknown targets => CONCERNS until defined.
+
+## Quality Gate Schema
+
+```yaml
+schema: 1
+story: '{epic}.{story}'
+story_title: '{title}'
+gate: PASS|CONCERNS|FAIL|WAIVED
+status_reason: 'Single sentence summary'
+reviewer: 'Murat (Master Test Architect)'
+updated: '2024-09-20T12:34:56Z'
+waiver:
+  active: false
+  reason: ''
+  approved_by: ''
+  expires: ''
+top_issues:
+  - id: SEC-001
+    severity: high
+    finding: 'Issue description'
+    suggested_action: 'Action to resolve'
+risk_summary:
+  totals:
+    critical: 0
+    high: 0
+    medium: 0
+    low: 0
+recommendations:
+  must_fix: []
+  monitor: []
+nfr_validation:
+  security: { status: PASS, notes: '' }
+  performance: { status: CONCERNS, notes: 'Add caching' }
+  reliability: { status: PASS, notes: '' }
+  maintainability: { status: PASS, notes: '' }
+history:
+  - at: '2024-09-20T12:34:56Z'
+    gate: CONCERNS
+    note: 'Initial review'
+```
+
+- Optional sections: `quality_score` block for extended metrics, and `evidence` block (tests_reviewed, risks_identified, trace.ac_covered/ac_gaps) when teams track them.
+
+## Collaborative TDD Loop
+
+- Share failing acceptance tests with the developer or AI agent.
+- Track red -> green -> refactor progress alongside the implementation checklist.
+- Update checklist items as each test passes; add new tests for discovered edge cases.
+- Keep conversation focused on observable behavior, not implementation detail.
+
+## Traceability Coverage Definitions
+
+- FULL: All scenarios for the criterion validated across appropriate levels.
+- PARTIAL: Some coverage exists but gaps remain.
+- NONE: No tests currently validate the criterion.
+- UNIT-ONLY: Only low-level tests exist; add integration/E2E.
+- INTEGRATION-ONLY: Missing unit/component coverage for fast feedback.
+- Avoid naive UI E2E until service-level confidence exists; use API or contract tests to harden backends first, then add minimal UI coverage to fill the gaps.
+
+## CI Platform Guidance
+
+- Default to GitHub Actions if no preference is given; otherwise ask for GitLab, CircleCI, etc.
+- Ensure local script mirrors CI pipeline (npm test vs CI workflow).
+- Use concurrency controls to prevent duplicate runs (`concurrency` block in GitHub Actions).
+- Keep job runtime under 10 minutes; split further if necessary.
+
+## Testing Tool Preferences
+
+- Component testing: Large repositories prioritize Vitest with UI (fast, component-native). Smaller DX-first teams with existing Cypress stacks can keep Cypress Component Testing for consistency.
+- E2E testing: Favor Playwright for large or performance-sensitive repos; reserve Cypress for smaller DX-first teams where developer experience outweighs scale.
+- API testing: Prefer Playwright's API testing or contract suites over ad-hoc REST clients.
+- Contract testing: Pact.js for consumer-driven contracts; keep `pact/` config in repo.
+- Visual testing: Percy, Chromatic, or Playwright snapshots when UX must be audited.
+
+## Naming Conventions
+
+- File names: `ComponentName.cy.tsx` for Cypress component tests, `component-name.spec.ts` for Playwright, `ComponentName.test.tsx` for unit/RTL.
+- Describe blocks: `describe('Feature/Component Name', () => { context('when condition', ...) })`.
+- Data attributes: always kebab-case (`data-cy="submit-button"`, `data-testid="user-email"`).
+
+## Reference Materials
+
+If deeper context is needed, consult Murat's testing philosophy notes, blog posts, and sample repositories in https://github.com/muratkeremozcan/test-resources-for-ai/blob/main/gitingest-full-repo-text-version.txt.

package/src/modules/bmm/testarch/test-design.md

@@ -0,0 +1,39 @@
+<!-- Powered by BMAD-CORE™ -->
+
+# Test Design v2.0 (Slim)
+
+```xml
+<task id="bmad/bmm/testarch/test-design" name="Test Design">
+  <llm critical="true">
+    <i>Set command_key="*test-design"</i>
+    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the matching row</i>
+    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md to reinforce Murat's coverage heuristics</i>
+    <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags as guidance</i>
+    <i>Split pipe-delimited values into actionable lists</i>
+    <i>Keep documents actionable—no verbose restatement of requirements</i>
+  </llm>
+  <flow>
+    <step n="1" title="Preflight">
+      <action>Confirm required inputs (risk profile, acceptance criteria)</action>
+      <action>Abort using halt_rules if prerequisites missing</action>
+    </step>
+    <step n="2" title="Design Strategy">
+      <action>Follow flow_cues to map criteria to scenarios, assign test levels, set priorities</action>
+      <action>Use knowledge heuristics for ratios, data factories, and cost vs confidence trade-offs</action>
+    </step>
+    <step n="3" title="Deliverables">
+      <action>Create artifacts defined in deliverables (strategy markdown, tables)</action>
+      <action>Summarize guidance for developers/testers</action>
+    </step>
+  </flow>
+  <halt>
+    <i>Follow halt_rules from the CSV row</i>
+  </halt>
+  <notes>
+    <i>Apply notes column for extra context</i>
+  </notes>
+  <output>
+    <i>Lean test design document aligned with risk profile</i>
+  </output>
+</task>
+```

package/{bmad-core/data → src/modules/bmm/testarch}/test-levels-framework.md

@@ -1,3 +1,5 @@
+<!-- Powered by BMAD-CORE™ -->
+
 # Test Levels Framework
 
 Comprehensive guide for determining appropriate test levels (unit, integration, E2E) for different scenarios.

package/{bmad-core/data → src/modules/bmm/testarch}/test-priorities-matrix.md

@@ -1,3 +1,5 @@
+<!-- Powered by BMAD-CORE™ -->
+
 # Test Priorities Matrix
 
 Guide for prioritizing test scenarios based on risk, criticality, and business impact.

package/src/modules/bmm/testarch/trace-requirements.md

@@ -0,0 +1,38 @@
+<!-- Powered by BMAD-CORE™ -->
+
+# Requirements Traceability v2.0 (Slim)
+
+```xml
+<task id="bmad/bmm/testarch/trace" name="Requirements Traceability">
+  <llm critical="true">
+    <i>Set command_key="*trace"</i>
+    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and read the matching row</i>
+    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md emphasising assertions guidance</i>
+    <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags</i>
+    <i>Split pipe-delimited values into actionable lists</i>
+    <i>Focus on mapping reality: reference actual files, describe coverage gaps, recommend next steps</i>
+  </llm>
+  <flow>
+    <step n="1" title="Preflight">
+      <action>Validate prerequisites; halt per halt_rules if unmet</action>
+    </step>
+    <step n="2" title="Traceability Analysis">
+      <action>Follow flow_cues to map acceptance criteria to implemented tests</action>
+      <action>Leverage knowledge heuristics to highlight assertion quality and duplication risks</action>
+    </step>
+    <step n="3" title="Deliverables">
+      <action>Create traceability report described in deliverables</action>
+      <action>Summarize critical gaps and recommendations</action>
+    </step>
+  </flow>
+  <halt>
+    <i>Apply halt_rules from the CSV row</i>
+  </halt>
+  <notes>
+    <i>Reference notes column for additional emphasis</i>
+  </notes>
+  <output>
+    <i>Coverage matrix and narrative summary</i>
+  </output>
+</task>
+```

package/src/modules/bmm/workflows/1-analysis/brainstorm-game/game-brain-methods.csv

@@ -0,0 +1,26 @@
+category,technique_name,description,facilitation_prompts,best_for,energy_level,typical_duration
+game_design,MDA Framework Exploration,Explore game concepts through Mechanics-Dynamics-Aesthetics lens to ensure cohesive design from implementation to player experience,What mechanics create the core loop?|What dynamics emerge from these mechanics?|What aesthetic experience results?|How do they align?,holistic-design,moderate,20-30
+game_design,Core Loop Brainstorming,Design the fundamental moment-to-moment gameplay loop that players repeat - the heartbeat of your game,What does the player do?|What's the immediate reward?|Why do it again?|How does it evolve?,gameplay-foundation,high,15-25
+game_design,Player Fantasy Mining,Identify and amplify the core fantasy that players want to embody - what makes them feel powerful and engaged,What fantasy does the player live?|What makes them feel awesome?|What power do they wield?|What identity do they assume?,player-motivation,high,15-20
+game_design,Genre Mashup,Combine unexpected game genres to create innovative hybrid experiences that offer fresh gameplay,Take two unrelated genres|How do they merge?|What unique gameplay emerges?|What's the hook?,innovation,high,15-20
+game_design,Verbs Before Nouns,Focus on what players DO before what things ARE - prioritize actions over objects for engaging gameplay,What verbs define your game?|What actions feel good?|Build mechanics from verbs|Nouns support actions,mechanics-first,moderate,20-25
+game_design,Failure State Design,Work backwards from interesting failure conditions to create tension and meaningful choices,How can players fail interestingly?|What makes failure feel fair?|How does failure teach?|Recovery mechanics?,challenge-design,moderate,15-20
+game_design,Progression Curve Sculpting,Map the player's emotional and skill journey from tutorial to mastery - pace challenge and revelation,How does difficulty evolve?|When do we introduce concepts?|What's the skill ceiling?|How do we maintain flow?,pacing-balance,moderate,25-30
+game_design,Emergence Engineering,Design simple rule interactions that create complex unexpected player-driven outcomes,What simple rules combine?|What emerges from interactions?|How do players surprise you?|Systemic possibilities?,depth-complexity,moderate,20-25
+game_design,Accessibility Layers,Brainstorm how different skill levels and abilities can access your core experience meaningfully,Who might struggle with what?|What alternate inputs exist?|How do we preserve challenge?|Inclusive design options?,inclusive-design,moderate,20-25
+game_design,Reward Schedule Architecture,Design the timing and type of rewards to maintain player motivation and engagement,What rewards when?|Variable or fixed schedule?|Intrinsic vs extrinsic rewards?|Progression satisfaction?,engagement-retention,moderate,20-30
+narrative_game,Ludonarrative Harmony,Align story and gameplay so mechanics reinforce narrative themes - make meaning through play,What does gameplay express?|How do mechanics tell story?|Where do they conflict?|How to unify theme?,storytelling,moderate,20-25
+narrative_game,Environmental Storytelling,Use world design and ambient details to convey narrative without explicit exposition,What does the space communicate?|What happened here before?|Visual narrative clues?|Show don't tell?,world-building,moderate,15-20
+narrative_game,Player Agency Moments,Identify key decision points where player choice shapes narrative in meaningful ways,What choices matter?|How do consequences manifest?|Branch vs flavor choices?|Meaningful agency where?,player-choice,moderate,20-25
+narrative_game,Emotion Targeting,Design specific moments intended to evoke targeted emotional responses through integrated design,What emotion when?|How do all elements combine?|Music + mechanics + narrative?|Orchestrated feelings?,emotional-design,high,20-30
+systems_game,Economy Balancing Thought Experiments,Explore resource generation/consumption balance to prevent game-breaking exploits,What resources exist?|Generation vs consumption rates?|What loops emerge?|Where's the exploit?,economy-design,moderate,25-30
+systems_game,Meta-Game Layer Design,Brainstorm progression systems that persist beyond individual play sessions,What carries over between sessions?|Long-term goals?|How does meta feed core loop?|Retention hooks?,retention-systems,moderate,20-25
+multiplayer_game,Social Dynamics Mapping,Anticipate how players will interact and design mechanics that support desired social behaviors,How will players cooperate?|Competitive dynamics?|Toxic behavior prevention?|Positive interaction rewards?,social-design,moderate,20-30
+multiplayer_game,Spectator Experience Design,Consider how watching others play can be entertaining - esports and streaming potential,What's fun to watch?|Readable visual clarity?|Highlight moments?|Narrative for observers?,spectator-value,moderate,15-20
+creative_game,Constraint-Based Creativity,Embrace a specific limitation as your core design constraint and build everything around it,Pick a severe constraint|What if this was your ONLY mechanic?|Build a full game from limitation|Constraint as creativity catalyst,innovation,moderate,15-25
+creative_game,Game Feel Playground,Focus purely on how controls and feedback FEEL before worrying about context or goals,What feels juicy to do?|Controller response?|Visual/audio feedback?|Satisfying micro-interactions?,game-feel,high,20-30
+creative_game,One Button Game Challenge,Design interesting gameplay using only a single input - forces elegant simplicity,Only one button - what can it do?|Context changes meaning?|Timing variations?|Depth from simplicity?,minimalist-design,moderate,15-20
+wild_game,Remix an Existing Game,Take a well-known game and twist one core element - what new experience emerges?,Pick a famous game|Change ONE fundamental rule|What ripples from that change?|New game from mutation?,rapid-prototyping,high,10-15
+wild_game,Anti-Game Design,Design a game that deliberately breaks common conventions - subvert player expectations,What if we broke this rule?|Expectation subversion?|Anti-patterns as features?|Avant-garde possibilities?,experimental,moderate,15-20
+wild_game,Physics Playground,Start with an interesting physics interaction and build a game around that sensation,What physics are fun to play with?|Build game from physics toy|Emergent physics gameplay?|Sensation first?,prototype-first,high,15-25
+wild_game,Toy Before Game,Create a playful interactive toy with no goals first - then discover the game within it,What's fun to mess with?|No goals yet - just play|What game emerges organically?|Toy to game evolution?,discovery-design,high,20-30

package/src/modules/bmm/workflows/1-analysis/brainstorm-game/game-context.md

@@ -0,0 +1,115 @@
+# Game Brainstorming Context
+
+This context guide provides game-specific considerations for brainstorming sessions focused on game design and development.
+
+## Session Focus Areas
+
+When brainstorming for games, consider exploring:
+
+- **Core Gameplay Loop** - What players do moment-to-moment
+- **Player Fantasy** - What identity/power fantasy does the game fulfill?
+- **Game Mechanics** - Rules and interactions that define play
+- **Game Dynamics** - Emergent behaviors from mechanic interactions
+- **Aesthetic Experience** - Emotional responses and feelings evoked
+- **Progression Systems** - How players grow and unlock content
+- **Challenge & Difficulty** - How to create engaging difficulty curves
+- **Social/Multiplayer Features** - How players interact with each other
+- **Narrative & World** - Story, setting, and environmental storytelling
+- **Art Direction & Feel** - Visual style and game feel
+- **Monetization** - Business model and revenue approach (if applicable)
+
+## Game Design Frameworks
+
+### MDA Framework
+
+- **Mechanics** - Rules and systems (what's in the code)
+- **Dynamics** - Runtime behavior (how mechanics interact)
+- **Aesthetics** - Emotional responses (what players feel)
+
+### Player Motivation (Bartle's Taxonomy)
+
+- **Achievers** - Goal completion and progression
+- **Explorers** - Discovery and understanding systems
+- **Socializers** - Interaction and relationships
+- **Killers** - Competition and dominance
+
+### Core Experience Questions
+
+- What does the player DO? (Verbs first, nouns second)
+- What makes them feel powerful/competent/awesome?
+- What's the central tension or challenge?
+- What's the "one more turn" factor?
+
+## Recommended Brainstorming Techniques
+
+### Game Design Specific Techniques
+
+(These are available as additional techniques in game brainstorming sessions)
+
+- **MDA Framework Exploration** - Design through mechanics-dynamics-aesthetics
+- **Core Loop Brainstorming** - Define the heartbeat of gameplay
+- **Player Fantasy Mining** - Identify and amplify player power fantasies
+- **Genre Mashup** - Combine unexpected genres for innovation
+- **Verbs Before Nouns** - Focus on actions before objects
+- **Failure State Design** - Work backwards from interesting failures
+- **Ludonarrative Harmony** - Align story and gameplay
+- **Game Feel Playground** - Focus purely on how controls feel
+
+### Standard Techniques Well-Suited for Games
+
+- **SCAMPER Method** - Innovate on existing game mechanics
+- **What If Scenarios** - Explore radical gameplay possibilities
+- **First Principles Thinking** - Rebuild game concepts from scratch
+- **Role Playing** - Generate ideas from player perspectives
+- **Analogical Thinking** - Find inspiration from other games/media
+- **Constraint-Based Creativity** - Design around limitations
+- **Morphological Analysis** - Explore mechanic combinations
+
+## Output Guidance
+
+Effective game brainstorming sessions should capture:
+
+1. **Core Concept** - High-level game vision and hook
+2. **Key Mechanics** - Primary gameplay verbs and interactions
+3. **Player Experience** - What it feels like to play
+4. **Unique Elements** - What makes this game special/different
+5. **Design Challenges** - Obstacles to solve during development
+6. **Prototype Ideas** - What to test first
+7. **Reference Games** - Existing games that inspire or inform
+8. **Open Questions** - What needs further exploration
+
+## Integration with Game Development Workflow
+
+Game brainstorming sessions typically feed into:
+
+- **Game Briefs** - High-level vision and core pillars
+- **Game Design Documents (GDD)** - Comprehensive design specifications
+- **Technical Design Docs** - Architecture for game systems
+- **Prototype Plans** - What to build to validate concepts
+- **Art Direction Documents** - Visual style and feel guides
+
+## Special Considerations for Game Design
+
+### Start With The Feel
+
+- How should controls feel? Responsive? Weighty? Floaty?
+- What's the "game feel" - the juice and feedback?
+- Can we prototype the core interaction quickly?
+
+### Think in Systems
+
+- How do mechanics interact?
+- What emergent behaviors arise?
+- Are there dominant strategies or exploits?
+
+### Design for Failure
+
+- How do players fail?
+- Is failure interesting and instructive?
+- What's the cost of failure?
+
+### Player Agency vs. Authored Experience
+
+- Where do players have meaningful choices?
+- Where is the experience authored/scripted?
+- How do we balance freedom and guidance?

package/src/modules/bmm/workflows/1-analysis/brainstorm-game/instructions.md

@@ -0,0 +1,47 @@
+# Brainstorm Game - Workflow Instructions
+
+```xml
+<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.md</critical>
+<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
+<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with game-specific context and additional game design techniques</critical>
+
+<workflow>
+
+  <step n="1" goal="Load game brainstorming context and techniques">
+    <action>Read the game context document from: {game_context}</action>
+    <action>This context provides game-specific guidance including:
+      - Focus areas for game ideation (mechanics, narrative, experience, etc.)
+      - Key considerations for game design
+      - Recommended techniques for game brainstorming
+      - Output structure guidance
+    </action>
+    <action>Load game-specific brain techniques from: {game_brain_methods}</action>
+    <action>These additional techniques supplement the standard CIS brainstorming methods with game design-focused approaches like:
+      - MDA Framework exploration
+      - Core loop brainstorming
+      - Player fantasy mining
+      - Genre mashup
+      - And other game-specific ideation methods
+    </action>
+  </step>
+
+  <step n="2" goal="Invoke CIS brainstorming with game context">
+    <action>Execute the CIS brainstorming workflow with game context and additional techniques</action>
+    <invoke-workflow path="{cis_brainstorming}" data="{game_context}" techniques="{game_brain_methods}">
+      The CIS brainstorming workflow will:
+      - Merge game-specific techniques with standard techniques
+      - Present interactive brainstorming techniques menu
+      - Guide the user through selected ideation methods
+      - Generate and capture brainstorming session results
+      - Save output to: {output_folder}/brainstorming-session-results-{{date}}.md
+    </invoke-workflow>
+  </step>
+
+  <step n="3" goal="Completion">
+    <action>Confirm brainstorming session completed successfully</action>
+    <action>Brainstorming results saved by CIS workflow</action>
+    <action>Report workflow completion</action>
+  </step>
+
+</workflow>
+```

package/src/modules/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml

@@ -0,0 +1,22 @@
+# Brainstorm Game Workflow Configuration
+name: "brainstorm-game"
+description: "Facilitate game brainstorming sessions by orchestrating the CIS brainstorming workflow with game-specific context, guidance, and additional game design techniques."
+author: "BMad"
+
+# Critical variables load from config_source
+config_source: "{project-root}/bmad/bmm/config.yaml"
+output_folder: "{config_source}:output_folder"
+user_name: "{config_source}:user_name"
+date: system-generated
+
+# Module path and component files
+installed_path: "{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-game"
+template: false
+instructions: "{installed_path}/instructions.md"
+
+# Context and techniques for game brainstorming
+game_context: "{installed_path}/game-context.md"
+game_brain_methods: "{installed_path}/game-brain-methods.csv"
+
+# CIS brainstorming workflow to invoke
+cis_brainstorming: "{project-root}/bmad/cis/workflows/brainstorming/workflow.yaml"

package/src/modules/bmm/workflows/1-analysis/brainstorm-project/instructions.md

@@ -0,0 +1,38 @@
+# Brainstorm Project - Workflow Instructions
+
+```xml
+<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.md</critical>
+<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
+<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with project-specific context</critical>
+
+<workflow>
+
+  <step n="1" goal="Load project brainstorming context">
+    <action>Read the project context document from: {project_context}</action>
+    <action>This context provides project-specific guidance including:
+      - Focus areas for project ideation
+      - Key considerations for software/product projects
+      - Recommended techniques for project brainstorming
+      - Output structure guidance
+    </action>
+  </step>
+
+  <step n="2" goal="Invoke CIS brainstorming with project context">
+    <action>Execute the CIS brainstorming workflow with project context</action>
+    <invoke-workflow path="{cis_brainstorming}" data="{project_context}">
+      The CIS brainstorming workflow will:
+      - Present interactive brainstorming techniques menu
+      - Guide the user through selected ideation methods
+      - Generate and capture brainstorming session results
+      - Save output to: {output_folder}/brainstorming-session-results-{{date}}.md
+    </invoke-workflow>
+  </step>
+
+  <step n="3" goal="Completion">
+    <action>Confirm brainstorming session completed successfully</action>
+    <action>Brainstorming results saved by CIS workflow</action>
+    <action>Report workflow completion</action>
+  </step>
+
+</workflow>
+```

package/src/modules/bmm/workflows/1-analysis/brainstorm-project/project-context.md

@@ -0,0 +1,25 @@
+# Project Brainstorming Context
+
+This context guide provides project-specific considerations for brainstorming sessions focused on software and product development.
+
+## Session Focus Areas
+
+When brainstorming for projects, consider exploring:
+
+- **User Problems & Pain Points** - What challenges do users face?
+- **Feature Ideas & Capabilities** - What could the product do?
+- **Technical Approaches** - How might we build it?
+- **User Experience** - How will users interact with it?
+- **Business Model & Value** - How does it create value?
+- **Market Differentiation** - What makes it unique?
+- **Technical Risks & Challenges** - What could go wrong?
+- **Success Metrics** - How will we measure success?
+
+## Integration with Project Workflow
+
+Brainstorming sessions typically feed into:
+
+- **Product Briefs** - Initial product vision and strategy
+- **PRDs** - Detailed requirements documents
+- **Technical Specifications** - Architecture and implementation plans
+- **Research Activities** - Areas requiring further investigation