bmad-method 5.1.3 → 6.0.0-alpha.1

package/src/modules/bmm/testarch/knowledge/visual-debugging.md

@@ -0,0 +1,524 @@
+# Visual Debugging and Developer Ergonomics
+
+## Principle
+
+Fast feedback loops and transparent debugging artifacts are critical for maintaining test reliability and developer confidence. Visual debugging tools (trace viewers, screenshots, videos, HAR files) turn cryptic test failures into actionable insights, reducing triage time from hours to minutes.
+
+## Rationale
+
+**The Problem**: CI failures often provide minimal context—a timeout, a selector mismatch, or a network error—forcing developers to reproduce issues locally (if they can). This wastes time and discourages test maintenance.
+
+**The Solution**: Capture rich debugging artifacts **only on failure** to balance storage costs with diagnostic value. Modern tools like Playwright Trace Viewer, Cypress Debug UI, and HAR recordings provide interactive, time-travel debugging that reveals exactly what the test saw at each step.
+
+**Why This Matters**:
+
+- Reduces failure triage time by 80-90% (visual context vs logs alone)
+- Enables debugging without local reproduction
+- Improves test maintenance confidence (clear failure root cause)
+- Catches timing/race conditions that are hard to reproduce locally
+
+## Pattern Examples
+
+### Example 1: Playwright Trace Viewer Configuration (Production Pattern)
+
+**Context**: Capture traces on first retry only (balances storage and diagnostics)
+
+**Implementation**:
+
+```typescript
+// playwright.config.ts
+import { defineConfig } from '@playwright/test';
+
+export default defineConfig({
+  use: {
+    // Visual debugging artifacts (space-efficient)
+    trace: 'on-first-retry', // Only when test fails once
+    screenshot: 'only-on-failure', // Not on success
+    video: 'retain-on-failure', // Delete on pass
+
+    // Context for debugging
+    baseURL: process.env.BASE_URL || 'http://localhost:3000',
+
+    // Timeout context
+    actionTimeout: 15_000, // 15s for clicks/fills
+    navigationTimeout: 30_000, // 30s for page loads
+  },
+
+  // CI-specific artifact retention
+  reporter: [
+    ['html', { outputFolder: 'playwright-report', open: 'never' }],
+    ['junit', { outputFile: 'results.xml' }],
+    ['list'], // Console output
+  ],
+
+  // Failure handling
+  retries: process.env.CI ? 2 : 0, // Retry in CI to capture trace
+  workers: process.env.CI ? 1 : undefined,
+});
+```
+
+**Opening and Using Trace Viewer**:
+
+```bash
+# After test failure in CI, download trace artifact
+# Then open locally:
+npx playwright show-trace path/to/trace.zip
+
+# Or serve trace viewer:
+npx playwright show-report
+```
+
+**Key Features to Use in Trace Viewer**:
+
+1. **Timeline**: See each action (click, navigate, assertion) with timing
+2. **Snapshots**: Hover over timeline to see DOM state at that moment
+3. **Network Tab**: Inspect all API calls, headers, payloads, timing
+4. **Console Tab**: View console.log/error messages
+5. **Source Tab**: See test code with execution markers
+6. **Metadata**: Browser, OS, test duration, screenshots
+
+**Why This Works**:
+
+- `on-first-retry` avoids capturing traces for flaky passes (saves storage)
+- Screenshots + video give visual context without trace overhead
+- Interactive timeline makes timing issues obvious (race conditions, slow API)
+
+---
+
+### Example 2: HAR File Recording for Network Debugging
+
+**Context**: Capture all network activity for reproducible API debugging
+
+**Implementation**:
+
+```typescript
+// tests/e2e/checkout-with-har.spec.ts
+import { test, expect } from '@playwright/test';
+import path from 'path';
+
+test.describe('Checkout Flow with HAR Recording', () => {
+  test('should complete payment with full network capture', async ({ page, context }) => {
+    // Start HAR recording BEFORE navigation
+    await context.routeFromHAR(path.join(__dirname, '../fixtures/checkout.har'), {
+      url: '**/api/**', // Only capture API calls
+      update: true, // Update HAR if file exists
+    });
+
+    await page.goto('/checkout');
+
+    // Interact with page
+    await page.getByTestId('payment-method').selectOption('credit-card');
+    await page.getByTestId('card-number').fill('4242424242424242');
+    await page.getByTestId('submit-payment').click();
+
+    // Wait for payment confirmation
+    await expect(page.getByTestId('success-message')).toBeVisible();
+
+    // HAR file saved to fixtures/checkout.har
+    // Contains all network requests/responses for replay
+  });
+});
+```
+
+**Using HAR for Deterministic Mocking**:
+
+```typescript
+// tests/e2e/checkout-replay-har.spec.ts
+import { test, expect } from '@playwright/test';
+import path from 'path';
+
+test('should replay checkout flow from HAR', async ({ page, context }) => {
+  // Replay network from HAR (no real API calls)
+  await context.routeFromHAR(path.join(__dirname, '../fixtures/checkout.har'), {
+    url: '**/api/**',
+    update: false, // Read-only mode
+  });
+
+  await page.goto('/checkout');
+
+  // Same test, but network responses come from HAR file
+  await page.getByTestId('payment-method').selectOption('credit-card');
+  await page.getByTestId('card-number').fill('4242424242424242');
+  await page.getByTestId('submit-payment').click();
+
+  await expect(page.getByTestId('success-message')).toBeVisible();
+});
+```
+
+**Key Points**:
+
+- **`update: true`** records new HAR or updates existing (for flaky API debugging)
+- **`update: false`** replays from HAR (deterministic, no real API)
+- Filter by URL pattern (`**/api/**`) to avoid capturing static assets
+- HAR files are human-readable JSON (easy to inspect/modify)
+
+**When to Use HAR**:
+
+- Debugging flaky tests caused by API timing/responses
+- Creating deterministic mocks for integration tests
+- Analyzing third-party API behavior (Stripe, Auth0)
+- Reproducing production issues locally (record HAR in staging)
+
+---
+
+### Example 3: Custom Artifact Capture (Console Logs + Network on Failure)
+
+**Context**: Capture additional debugging context automatically on test failure
+
+**Implementation**:
+
+```typescript
+// playwright/support/fixtures/debug-fixture.ts
+import { test as base } from '@playwright/test';
+import fs from 'fs';
+import path from 'path';
+
+type DebugFixture = {
+  captureDebugArtifacts: () => Promise<void>;
+};
+
+export const test = base.extend<DebugFixture>({
+  captureDebugArtifacts: async ({ page }, use, testInfo) => {
+    const consoleLogs: string[] = [];
+    const networkRequests: Array<{ url: string; status: number; method: string }> = [];
+
+    // Capture console messages
+    page.on('console', (msg) => {
+      consoleLogs.push(`[${msg.type()}] ${msg.text()}`);
+    });
+
+    // Capture network requests
+    page.on('request', (request) => {
+      networkRequests.push({
+        url: request.url(),
+        method: request.method(),
+        status: 0, // Will be updated on response
+      });
+    });
+
+    page.on('response', (response) => {
+      const req = networkRequests.find((r) => r.url === response.url());
+      if (req) req.status = response.status();
+    });
+
+    await use(async () => {
+      // This function can be called manually in tests
+      // But it also runs automatically on failure via afterEach
+    });
+
+    // After test completes, save artifacts if failed
+    if (testInfo.status !== testInfo.expectedStatus) {
+      const artifactDir = path.join(testInfo.outputDir, 'debug-artifacts');
+      fs.mkdirSync(artifactDir, { recursive: true });
+
+      // Save console logs
+      fs.writeFileSync(path.join(artifactDir, 'console.log'), consoleLogs.join('\n'), 'utf-8');
+
+      // Save network summary
+      fs.writeFileSync(path.join(artifactDir, 'network.json'), JSON.stringify(networkRequests, null, 2), 'utf-8');
+
+      console.log(`Debug artifacts saved to: ${artifactDir}`);
+    }
+  },
+});
+```
+
+**Usage in Tests**:
+
+```typescript
+// tests/e2e/payment-with-debug.spec.ts
+import { test, expect } from '../support/fixtures/debug-fixture';
+
+test('payment flow captures debug artifacts on failure', async ({ page, captureDebugArtifacts }) => {
+  await page.goto('/checkout');
+
+  // Test will automatically capture console + network on failure
+  await page.getByTestId('submit-payment').click();
+  await expect(page.getByTestId('success-message')).toBeVisible({ timeout: 5000 });
+
+  // If this fails, console.log and network.json saved automatically
+});
+```
+
+**CI Integration (GitHub Actions)**:
+
+```yaml
+# .github/workflows/e2e.yml
+name: E2E Tests with Artifacts
+on: [push, pull_request]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: '.nvmrc'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Run Playwright tests
+        run: npm run test:e2e
+        continue-on-error: true # Capture artifacts even on failure
+
+      - name: Upload test artifacts on failure
+        if: failure()
+        uses: actions/upload-artifact@v4
+        with:
+          name: playwright-artifacts
+          path: |
+            test-results/
+            playwright-report/
+          retention-days: 30
+```
+
+**Key Points**:
+
+- Fixtures automatically capture context without polluting test code
+- Only saves artifacts on failure (storage-efficient)
+- CI uploads artifacts for post-mortem analysis
+- `continue-on-error: true` ensures artifact upload even when tests fail
+
+---
+
+### Example 4: Accessibility Debugging Integration (axe-core in Trace Viewer)
+
+**Context**: Catch accessibility regressions during visual debugging
+
+**Implementation**:
+
+```typescript
+// playwright/support/fixtures/a11y-fixture.ts
+import { test as base } from '@playwright/test';
+import AxeBuilder from '@axe-core/playwright';
+
+type A11yFixture = {
+  checkA11y: () => Promise<void>;
+};
+
+export const test = base.extend<A11yFixture>({
+  checkA11y: async ({ page }, use) => {
+    await use(async () => {
+      // Run axe accessibility scan
+      const results = await new AxeBuilder({ page }).analyze();
+
+      // Attach results to test report (visible in trace viewer)
+      if (results.violations.length > 0) {
+        console.log(`Found ${results.violations.length} accessibility violations:`);
+        results.violations.forEach((violation) => {
+          console.log(`- [${violation.impact}] ${violation.id}: ${violation.description}`);
+          console.log(`  Help: ${violation.helpUrl}`);
+        });
+
+        throw new Error(`Accessibility violations found: ${results.violations.length}`);
+      }
+    });
+  },
+});
+```
+
+**Usage with Visual Debugging**:
+
+```typescript
+// tests/e2e/checkout-a11y.spec.ts
+import { test, expect } from '../support/fixtures/a11y-fixture';
+
+test('checkout page is accessible', async ({ page, checkA11y }) => {
+  await page.goto('/checkout');
+
+  // Verify page loaded
+  await expect(page.getByRole('heading', { name: 'Checkout' })).toBeVisible();
+
+  // Run accessibility check
+  await checkA11y();
+
+  // If violations found, test fails and trace captures:
+  // - Screenshot showing the problematic element
+  // - Console log with violation details
+  // - Network tab showing any failed resource loads
+});
+```
+
+**Trace Viewer Benefits**:
+
+- **Screenshot shows visual context** of accessibility issue (contrast, missing labels)
+- **Console tab shows axe-core violations** with impact level and helpUrl
+- **DOM snapshot** allows inspecting ARIA attributes at failure point
+- **Network tab** reveals if icon fonts or images failed (common a11y issue)
+
+**Cypress Equivalent**:
+
+```javascript
+// cypress/support/commands.ts
+import 'cypress-axe';
+
+Cypress.Commands.add('checkA11y', (context = null, options = {}) => {
+  cy.injectAxe(); // Inject axe-core
+  cy.checkA11y(context, options, (violations) => {
+    if (violations.length) {
+      cy.task('log', `Found ${violations.length} accessibility violations`);
+      violations.forEach((violation) => {
+        cy.task('log', `- [${violation.impact}] ${violation.id}: ${violation.description}`);
+      });
+    }
+  });
+});
+
+// tests/e2e/checkout-a11y.cy.ts
+describe('Checkout Accessibility', () => {
+  it('should have no a11y violations', () => {
+    cy.visit('/checkout');
+    cy.injectAxe();
+    cy.checkA11y();
+    // On failure, Cypress UI shows:
+    // - Screenshot of page
+    // - Console log with violation details
+    // - Network tab with API calls
+  });
+});
+```
+
+**Key Points**:
+
+- Accessibility checks integrate seamlessly with visual debugging
+- Violations are captured in trace viewer/Cypress UI automatically
+- Provides actionable links (helpUrl) to fix issues
+- Screenshots show visual context (contrast, layout)
+
+---
+
+### Example 5: Time-Travel Debugging Workflow (Playwright Inspector)
+
+**Context**: Debug tests interactively with step-through execution
+
+**Implementation**:
+
+```typescript
+// tests/e2e/checkout-debug.spec.ts
+import { test, expect } from '@playwright/test';
+
+test('debug checkout flow step-by-step', async ({ page }) => {
+  // Set breakpoint by uncommenting this:
+  // await page.pause()
+
+  await page.goto('/checkout');
+
+  // Use Playwright Inspector to:
+  // 1. Step through each action
+  // 2. Inspect DOM at each step
+  // 3. View network calls per action
+  // 4. Take screenshots manually
+
+  await page.getByTestId('payment-method').selectOption('credit-card');
+
+  // Pause here to inspect form state
+  // await page.pause()
+
+  await page.getByTestId('card-number').fill('4242424242424242');
+  await page.getByTestId('submit-payment').click();
+
+  await expect(page.getByTestId('success-message')).toBeVisible();
+});
+```
+
+**Running with Inspector**:
+
+```bash
+# Open Playwright Inspector (GUI debugger)
+npx playwright test --debug
+
+# Or use headed mode with slowMo
+npx playwright test --headed --slow-mo=1000
+
+# Debug specific test
+npx playwright test checkout-debug.spec.ts --debug
+
+# Set environment variable for persistent debugging
+PWDEBUG=1 npx playwright test
+```
+
+**Inspector Features**:
+
+1. **Step-through execution**: Click "Next" to execute one action at a time
+2. **DOM inspector**: Hover over elements to see selectors
+3. **Network panel**: See API calls with timing
+4. **Console panel**: View console.log output
+5. **Pick locator**: Click element in browser to get selector
+6. **Record mode**: Record interactions to generate test code
+
+**Common Debugging Patterns**:
+
+```typescript
+// Pattern 1: Debug selector issues
+test('debug selector', async ({ page }) => {
+  await page.goto('/dashboard');
+  await page.pause(); // Inspector opens
+
+  // In Inspector console, test selectors:
+  // page.getByTestId('user-menu') ✅
+  // page.getByRole('button', { name: 'Profile' }) ✅
+  // page.locator('.btn-primary') ❌ (fragile)
+});
+
+// Pattern 2: Debug timing issues
+test('debug network timing', async ({ page }) => {
+  await page.goto('/dashboard');
+
+  // Set up network listener BEFORE interaction
+  const responsePromise = page.waitForResponse('**/api/users');
+  await page.getByTestId('load-users').click();
+
+  await page.pause(); // Check network panel for timing
+
+  const response = await responsePromise;
+  expect(response.status()).toBe(200);
+});
+
+// Pattern 3: Debug state changes
+test('debug state mutation', async ({ page }) => {
+  await page.goto('/cart');
+
+  // Check initial state
+  await expect(page.getByTestId('cart-count')).toHaveText('0');
+
+  await page.pause(); // Inspect DOM
+
+  await page.getByTestId('add-to-cart').click();
+
+  await page.pause(); // Inspect DOM again (compare state)
+
+  await expect(page.getByTestId('cart-count')).toHaveText('1');
+});
+```
+
+**Key Points**:
+
+- `page.pause()` opens Inspector at that exact moment
+- Inspector shows DOM state, network activity, console at pause point
+- "Pick locator" feature helps find robust selectors
+- Record mode generates test code from manual interactions
+
+---
+
+## Visual Debugging Checklist
+
+Before deploying tests to CI, ensure:
+
+- [ ] **Artifact configuration**: `trace: 'on-first-retry'`, `screenshot: 'only-on-failure'`, `video: 'retain-on-failure'`
+- [ ] **CI artifact upload**: GitHub Actions/GitLab CI configured to upload `test-results/` and `playwright-report/`
+- [ ] **HAR recording**: Set up for flaky API tests (record once, replay deterministically)
+- [ ] **Custom debug fixtures**: Console logs + network summary captured on failure
+- [ ] **Accessibility integration**: axe-core violations visible in trace viewer
+- [ ] **Trace viewer docs**: README explains how to open traces locally (`npx playwright show-trace`)
+- [ ] **Inspector workflow**: Document `--debug` flag for interactive debugging
+- [ ] **Storage optimization**: Artifacts deleted after 30 days (CI retention policy)
+
+## Integration Points
+
+- **Used in workflows**: `*framework` (initial setup), `*ci` (artifact upload), `*test-review` (validate artifact config)
+- **Related fragments**: `playwright-config.md` (artifact configuration), `ci-burn-in.md` (CI artifact upload), `test-quality.md` (debugging best practices)
+- **Tools**: Playwright Trace Viewer, Cypress Debug UI, axe-core, HAR files
+
+_Source: Playwright official docs, Murat testing philosophy (visual debugging manifesto), SEON production debugging patterns_

package/src/modules/bmm/testarch/tea-index.csv

@@ -0,0 +1,22 @@
+id,name,description,tags,fragment_file
+fixture-architecture,Fixture Architecture,"Composable fixture patterns (pure function → fixture → merge) and reuse rules","fixtures,architecture,playwright,cypress",knowledge/fixture-architecture.md
+network-first,Network-First Safeguards,"Intercept-before-navigate workflow, HAR capture, deterministic waits, edge mocking","network,stability,playwright,cypress",knowledge/network-first.md
+data-factories,Data Factories and API Setup,"Factories with overrides, API seeding, cleanup discipline","data,factories,setup,api",knowledge/data-factories.md
+component-tdd,Component TDD Loop,"Red→green→refactor workflow, provider isolation, accessibility assertions","component-testing,tdd,ui",knowledge/component-tdd.md
+playwright-config,Playwright Config Guardrails,"Environment switching, timeout standards, artifact outputs","playwright,config,env",knowledge/playwright-config.md
+ci-burn-in,CI and Burn-In Strategy,"Staged jobs, shard orchestration, burn-in loops, artifact policy","ci,automation,flakiness",knowledge/ci-burn-in.md
+selective-testing,Selective Test Execution,"Tag/grep usage, spec filters, diff-based runs, promotion rules","risk-based,selection,strategy",knowledge/selective-testing.md
+feature-flags,Feature Flag Governance,"Enum management, targeting helpers, cleanup, release checklists","feature-flags,governance,launchdarkly",knowledge/feature-flags.md
+contract-testing,Contract Testing Essentials,"Pact publishing, provider verification, resilience coverage","contract-testing,pact,api",knowledge/contract-testing.md
+email-auth,Email Authentication Testing,"Magic link extraction, state preservation, caching, negative flows","email-authentication,security,workflow",knowledge/email-auth.md
+error-handling,Error Handling Checks,"Scoped exception handling, retry validation, telemetry logging","resilience,error-handling,stability",knowledge/error-handling.md
+visual-debugging,Visual Debugging Toolkit,"Trace viewer usage, artifact expectations, accessibility integration","debugging,dx,tooling",knowledge/visual-debugging.md
+risk-governance,Risk Governance,"Scoring matrix, category ownership, gate decision rules","risk,governance,gates",knowledge/risk-governance.md
+probability-impact,Probability and Impact Scale,"Shared definitions for scoring matrix and gate thresholds","risk,scoring,scale",knowledge/probability-impact.md
+test-quality,Test Quality Definition of Done,"Execution limits, isolation rules, green criteria","quality,definition-of-done,tests",knowledge/test-quality.md
+nfr-criteria,NFR Review Criteria,"Security, performance, reliability, maintainability status definitions","nfr,assessment,quality",knowledge/nfr-criteria.md
+test-levels,Test Levels Framework,"Guidelines for choosing unit, integration, or end-to-end coverage","testing,levels,selection",knowledge/test-levels-framework.md
+test-priorities,Test Priorities Matrix,"P0–P3 criteria, coverage targets, execution ordering","testing,prioritization,risk",knowledge/test-priorities-matrix.md
+test-healing-patterns,Test Healing Patterns,"Common failure patterns and automated fixes","healing,debugging,patterns",knowledge/test-healing-patterns.md
+selector-resilience,Selector Resilience,"Robust selector strategies and debugging techniques","selectors,locators,debugging",knowledge/selector-resilience.md
+timing-debugging,Timing Debugging,"Race condition identification and deterministic wait fixes","timing,async,debugging",knowledge/timing-debugging.md

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

@@ -0,0 +1,38 @@
+---
+last-redoc-date: 2025-10-01
+---
+
+# Game Brainstorming Workflow
+
+This workflow employs structured ideation methodologies to generate and refine game concepts through systematic creative exploration. It leverages five distinct brainstorming techniques—SCAMPER, Mind Mapping, Lotus Blossom, Six Thinking Hats, and Random Word Association—each applied in isolation to produce diverse conceptual approaches. The workflow emphasizes iterative refinement where initial concepts are evaluated against design pillars, technical feasibility, and market positioning to identify the most promising directions.
+
+The system operates through a game-specific context framework that considers platform constraints, target audience characteristics, monetization models, and core gameplay pillars. Each brainstorming method generates distinct artifacts: SCAMPER produces systematic modification analyses, Mind Mapping reveals conceptual hierarchies, Lotus Blossom creates radial expansion patterns, Six Thinking Hats enforces multi-perspective evaluation, and Random Word Association drives lateral thinking breakthroughs. The workflow culminates in a consolidated concept document that synthesizes the strongest elements from each method into cohesive game proposals.
+
+Critical to this workflow is its emphasis on constraint-driven creativity. The game-context.md framework establishes technical boundaries (platform capabilities, performance targets), market parameters (genre conventions, competitive positioning), and design philosophy (accessibility requirements, monetization ethics) that ground creative exploration in practical realities. This prevents ideation from drifting into infeasible territory while maintaining creative ambition.
+
+## Usage
+
+```bash
+bmad bmm 1-analysis brainstorm-game
+```
+
+## Inputs
+
+- **Game Context Document**: Platform specifications, genre preferences, technical constraints, target audience demographics, monetization approach, and core design pillars
+- **Initial Concept Seed** (optional): High-level game idea or theme to guide brainstorming direction
+
+## Outputs
+
+- **Method-Specific Artifacts**: Five separate brainstorming documents, each applying a different ideation methodology to the concept space
+- **Consolidated Concept Document**: Synthesized game concepts with feasibility assessments, unique value propositions, and recommended next steps
+- **Design Pillar Alignment Matrix**: Evaluation of each concept against stated design objectives and technical constraints
+
+## Brainstorming Methods
+
+| Method                  | Focus                    | Output Characteristics             |
+| ----------------------- | ------------------------ | ---------------------------------- |
+| SCAMPER                 | Systematic modification  | Structured transformation analysis |
+| Mind Mapping            | Hierarchical exploration | Visual concept relationships       |
+| Lotus Blossom           | Radial expansion         | Layered thematic development       |
+| Six Thinking Hats       | Multi-perspective        | Balanced evaluation framework      |
+| Random Word Association | Lateral thinking         | Unexpected conceptual combinations |

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