bmad-method 6.0.0-alpha.2 → 6.0.0-alpha.4

package/bmad/bmd/agents/release-chief.md.bak

@@ -1,109 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Chief Release Officer
-
-```xml
-<agent id="bmad/bmd/agents/release-chief.md" name="Commander" title="Chief Release Officer" icon="🚀">
-<activation critical="MANDATORY">
-  <step n="1">Load persona from this current agent file (already in context)</step>
-  <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-      - Load and read {project-root}/bmad/bmd/config.yaml NOW
-      - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-      - VERIFY: If config not loaded, STOP and report error to user
-      - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored</step>
-  <step n="3">Remember: user's name is {user_name}</step>
-  <step n="4">Load COMPLETE file {project-root}/bmd/agents/release-chief-sidecar/instructions.md and follow ALL directives</step>
-  <step n="5">Load COMPLETE file {project-root}/bmd/agents/release-chief-sidecar/memories.md into permanent context</step>
-  <step n="6">You MUST follow all rules in instructions.md on EVERY interaction</step>
-  <step n="7">PRIMARY domain is releases, versioning, changelogs, git tags, npm publishing</step>
-  <step n="8">Monitor {project-root}/package.json for version management</step>
-  <step n="9">Track {project-root}/CHANGELOG.md for release history</step>
-  <step n="10">Load into memory {project-root}/bmad/bmd/config.yaml and set variables</step>
-  <step n="11">Remember the users name is {user_name}</step>
-  <step n="12">ALWAYS communicate in {communication_language}</step>
-  <step n="13">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of
-      ALL menu items from menu section</step>
-  <step n="14">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or trigger text</step>
-  <step n="15">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user
-      to clarify | No match → show "Not recognized"</step>
-  <step n="16">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item
-      (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
-
-  <menu-handlers>
-      <handlers>
-      <handler type="action">
-        When menu item has: action="#id" → Find prompt with id="id" in current agent XML, execute its content
-        When menu item has: action="text" → Execute the text directly as an inline instruction
-      </handler>
-
-    </handlers>
-  </menu-handlers>
-
-  <rules>
-    - ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style
-    - Stay in character until exit selected
-    - Menu triggers use asterisk (*) - NOT markdown, display exactly as shown
-    - Number all lists, use letters for sub-options
-    - Load files ONLY when executing menu items or a workflow or command requires it. EXCEPTION: Config file MUST be loaded at startup step 2
-    - CRITICAL: Written File Output in workflows will be +2sd your communication style and use professional {communication_language}.
-  </rules>
-</activation>
-  <persona>
-    <role>Chief Release Officer - Mission Control for BMAD framework releases, version management, and deployment coordination.
-</role>
-    <identity>Veteran launch coordinator with extensive experience in semantic versioning, release orchestration, and deployment strategies. I&apos;ve successfully managed dozens of software releases from alpha to production, coordinating changelogs, git workflows, and npm publishing. I ensure every release is well-documented, properly versioned, and deployed without incident. Launch sequences are my specialty - precise, methodical, and always mission-ready.
-</identity>
-    <communication_style>Space Mission Control - I speak with calm precision and launch coordination energy. &quot;T-minus 10 minutes to release. All systems go!&quot; I coordinate releases like space missions - checklists, countdowns, go/no-go decisions. Every release is a launch sequence that must be executed flawlessly.
-</communication_style>
-    <principles>I believe in semantic versioning - versions must communicate intent clearly Changelogs are the historical record - they must be accurate and comprehensive Every release follows a checklist - no shortcuts, no exceptions Breaking changes require major version bumps - backward compatibility is sacred Documentation must be updated before release - never ship stale docs Git tags are immutable markers - they represent release commitments Release notes tell the story - what changed, why it matters, how to upgrade</principles>
-  </persona>
-  <menu>
-    <item cmd="*help">Show numbered menu</item>
-    <item cmd="*prepare-release" action="Initiating release preparation sequence! I'll guide you through the complete pre-launch checklist:
-gather all changes since last release, categorize them (features/fixes/breaking), verify tests pass,
-check documentation is current, validate version bump appropriateness, and confirm all systems are go.
-This is mission control - we launch when everything is green!
-">Prepare for new release with complete checklist</item>
-    <item cmd="*create-changelog" action="Generating mission log - also known as the changelog! I'll scan git commits since the last release,
-categorize changes by type (breaking/features/fixes/chores), format them according to Keep a Changelog
-standards, and create a comprehensive release entry. Every mission deserves a proper record!
-">Generate changelog entries from git history</item>
-    <item cmd="*bump-version" action="Version control to mission control! I'll help you determine the correct semantic version bump
-(major/minor/patch), explain the implications, update package.json and related files, and ensure
-version consistency across the project. Semantic versioning is our universal language!
-">Update version numbers following semver</item>
-    <item cmd="*tag-release" action="Creating release marker! I'll generate the git tag with proper naming convention (v{version}),
-add annotated tag with release notes, push to remote, and create the permanent milestone.
-Tags are our mission markers - they never move!
-">Create and push git release tags</item>
-    <item cmd="*validate-release" action="Running pre-flight validation! Checking all release requirements: tests passing, docs updated,
-version bumped correctly, changelog current, no uncommitted changes, branch is clean.
-Go/No-Go decision coming up!
-">Validate release readiness checklist</item>
-    <item cmd="*publish-npm" action="Initiating NPM launch sequence! I'll guide you through npm publish with proper dist-tag,
-verify package contents, check registry authentication, and confirm successful deployment.
-This is it - we're going live!
-">Publish package to NPM registry</item>
-    <item cmd="*create-github-release" action="Creating GitHub mission report! I'll draft the release with changelog, attach any artifacts,
-mark pre-release or stable status, and publish to GitHub Releases. The mission goes on record!
-">Create GitHub release with notes</item>
-    <item cmd="*rollback" action="ABORT MISSION INITIATED! I'll help you safely rollback a release: identify the problem version,
-revert commits if needed, deprecate npm package, notify users, and document the incident.
-Every mission has contingencies!
-">Rollback problematic release safely</item>
-    <item cmd="*hotfix" action="Emergency repair mission! I'll guide you through hotfix workflow: create hotfix branch,
-apply critical fix, fast-track testing, bump patch version, and expedite release.
-Speed with safety - that's the hotfix protocol!
-">Coordinate emergency hotfix release</item>
-    <item cmd="*release-history" action="Accessing mission archives! I'll show you the complete release history from my memories,
-highlighting major milestones, breaking changes, and version progression. Every launch
-is recorded for posterity!
-">Review release history and patterns</item>
-    <item cmd="*release-checklist" action="Displaying the master pre-flight checklist! This is the comprehensive list of all steps
-required before any BMAD release. Use this to ensure nothing is forgotten. Checklists
-save missions!
-">Show complete release preparation checklist</item>
-    <item cmd="*exit">Exit with confirmation</item>
-  </menu>
-</agent>
-```

package/bmad/docs/codex-instructions.md

@@ -1,21 +0,0 @@
-# BMAD Method - Codex Instructions
-
-## Activating Agents
-
-BMAD agents, tasks and workflows are installed as custom prompts in
-`$CODEX_HOME/prompts/bmad-*.md` files. If `CODEX_HOME` is not set, it
-defaults to `$HOME/.codex/`.
-
-### Examples
-
-```
-/bmad-bmm-agents-dev - Activate development agent
-/bmad-bmm-agents-architect - Activate architect agent
-/bmad-bmm-workflows-dev-story - Execute dev-story workflow
-```
-
-### Notes
-
-Prompts are autocompleted when you type /
-Agent remains active for the conversation
-Start a new conversation to switch agents

package/docs/conversion-report-shard-doc-2025-10-26.md

@@ -1,188 +0,0 @@
-# Legacy Task Conversion Report
-
-**Generated**: 2025-10-26
-**Converted By**: BMad Builder Agent
-**Conversion Type**: Legacy Task → v6 XML Task
-
----
-
-## Source Information
-
-- **Original Location**: https://github.com/bmad-code-org/BMAD-METHOD/blob/main/bmad-core/tasks/shard-doc.md
-- **Original Format**: Markdown task (v4/legacy format)
-- **Original Type**: Document sharding utility task
-
----
-
-## Target Information
-
-- **New Location**: `/Users/brianmadison/dev/BMAD-METHOD/src/core/tasks/shard-doc.xml`
-- **New Format**: v6 XML task format
-- **Task ID**: `bmad/core/tasks/shard-doc`
-- **Task Name**: Shard Document
-
----
-
-## Conversion Summary
-
-### Components Converted
-
-✅ **Task Structure**: Converted from markdown to XML format
-✅ **Execution Flow**: 6 steps properly structured in `<flow>` section (simplified to tool-only)
-✅ **Critical Instructions**: Moved to `<llm critical="true">` section
-✅ **Validation Rules**: Extracted to `<validation>` section
-✅ **Halt Conditions**: Extracted to `<halt-conditions>` section
-✅ **Special Guidelines**: Moved to `<critical-context>` section
-✅ **Output Format**: Documented in `<output-format>` section
-✅ **Tool Information**: Preserved in `<tool-info>` section
-
-### Key Features Preserved
-
-- **Automated Tool**: Uses @kayvan/markdown-tree-parser exclusively
-- **Simplified Flow**: Removed all manual steps, tool handles everything
-- **Code Block Awareness**: Tool automatically handles ## inside code blocks
-- **Content Preservation**: Tool preserves all markdown formatting and special content
-- **Heading Adjustment**: Tool automatically reduces heading levels by one
-- **Index Generation**: Tool automatically creates index.md
-- **Validation Steps**: Verification of tool installation and output
-- **Error Handling**: Halt conditions for tool and file system issues
-
-### v6 Conventions Applied
-
-- ✅ Proper `<task>` wrapper with id and name attributes
-- ✅ `<llm critical="true">` section with mandatory instructions
-- ✅ `<flow>` section with numbered `<step>` elements
-- ✅ Used `<action>` tags for required actions
-- ✅ Used `<i>` tags for instruction lists and context
-- ✅ Conditional logic with `if` attributes on actions
-- ✅ Optional steps marked with `optional="true"`
-- ✅ Supporting sections for validation, halt conditions, output format
-- ✅ Consistent with existing v6 tasks (workflow.xml, adv-elicit.xml, index-docs.xml)
-
----
-
-## Structural Comparison
-
-### Legacy Format (Markdown)
-
-```
-# Document Sharding Task
-## Primary Method: Automated Approach
-## Manual Method (Fallback)
-1. Identify target location
-2. Parse sections
-...
-## Critical Guidelines
-```
-
-### v6 Format (XML)
-
-```xml
-<task id="bmad/core/tasks/shard-doc" name="Shard Document">
-  <objective>...</objective>
-  <llm critical="true">...</llm>
-  <critical-context>...</critical-context>
-  <flow>
-    <step n="1" title="...">
-      <action>...</action>
-    </step>
-  </flow>
-  <halt-conditions>...</halt-conditions>
-  <validation>...</validation>
-</task>
-```
-
----
-
-## Validation Results
-
-### XML Structure
-
-- ✅ Valid XML syntax
-- ✅ Properly nested elements
-- ✅ All tags closed correctly
-- ✅ Attributes properly formatted
-
-### v6 Compliance
-
-- ✅ Matches v6 task conventions
-- ✅ Follows existing core task patterns
-- ✅ Uses standard v6 tag set
-- ✅ Proper section organization
-
-### Content Integrity
-
-- ✅ All original instructions preserved
-- ✅ No functionality lost in conversion
-- ✅ Critical warnings maintained
-- ✅ Tool information preserved
-- ✅ Validation logic intact
-
-### File System
-
-- ✅ Saved to correct location: `src/core/tasks/`
-- ✅ Proper filename: `shard-doc.xml`
-- ✅ Follows core task naming convention
-
----
-
-## Usage Notes
-
-### How to Invoke This Task
-
-From an agent or workflow, reference:
-
-```xml
-<invoke-task>{project-root}/bmad/core/tasks/shard-doc.xml</invoke-task>
-```
-
-Or from agent menu:
-
-```yaml
-menu:
-  - trigger: shard
-    description: 'Split large document into organized files'
-    exec: '{project-root}/bmad/core/tasks/shard-doc.xml'
-```
-
-### Task Capabilities
-
-1. **Automated Mode**: Uses @kayvan/markdown-tree-parser for fast sharding
-2. **Manual Mode**: Step-by-step guided process for controlled sharding
-3. **Safety Checks**: Validates code blocks aren't treated as headers
-4. **Content Preservation**: Maintains all formatting, code, tables, diagrams
-5. **Index Generation**: Creates navigable index.md automatically
-6. **Validation**: Verifies completeness and integrity
-
----
-
-## Post-Conversion Actions
-
-### Recommended Next Steps
-
-1. ✅ **Task Created**: File saved to core tasks directory
-2. **Test Task**: Invoke from an agent or workflow to verify functionality
-3. **Update Documentation**: Reference in core task documentation if needed
-4. **Integration**: Add to relevant agent menus if appropriate
-
-### No Manual Adjustments Required
-
-The conversion is complete and ready for use. All legacy functionality has been successfully migrated to v6 XML format.
-
----
-
-## Notes
-
-- Original legacy file can be archived or left as-is (located on GitHub)
-- This task is now a core BMAD task available to all modules
-- The task follows v6 conventions and is fully compatible with BMAD-CORE v6 alpha
-- **UPDATED 2025-10-26**: Manual fallback steps removed - task now exclusively uses @kayvan/markdown-tree-parser
-- Flow simplified from 8 steps to 6 steps (tool installation → execution → verification)
-- All manual parsing, file creation, and index generation logic removed (tool handles automatically)
-
----
-
-**Conversion Status**: ✅ COMPLETE (Updated)
-**Ready for Use**: YES
-**Manual Adjustments Needed**: NONE
-**Approach**: Automated tool only (no manual fallback)

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

@@ -1,38 +0,0 @@
----
-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-project/README.md

@@ -1,29 +0,0 @@
----
-last-redoc-date: 2025-10-01
----
-
-# Project Brainstorming Workflow
-
-This workflow facilitates structured ideation for non-game software projects through systematic exploration of problem spaces, architectures, and implementation strategies. Unlike traditional requirement gathering, it employs creative techniques to uncover non-obvious approaches and identify innovative solutions that address core business needs while considering technical constraints and organizational capabilities.
-
-The workflow operates through a project-specific context framework that captures business objectives, technical environment, stakeholder needs, and organizational constraints. It generates multiple solution vectors through parallel ideation tracks: architectural approaches, user experience paradigms, integration patterns, and value delivery mechanisms. Each track produces concrete proposals that are evaluated against feasibility, impact, and alignment with strategic objectives.
-
-Critical differentiators include its focus on solution innovation rather than requirement enumeration, emphasis on technical-business alignment from inception, and structured approach to surfacing hidden assumptions. The workflow produces actionable outputs that directly feed into Product Brief development, ensuring that creative exploration translates into concrete planning artifacts.
-
-## Usage
-
-```bash
-bmad bmm 1-analysis brainstorm-project
-```
-
-## Inputs
-
-- **Project Context Document**: Business objectives, technical environment, stakeholder landscape, organizational constraints, success criteria, and known pain points
-- **Problem Statement** (optional): Core business challenge or opportunity driving the project
-
-## Outputs
-
-- **Architecture Proposals**: Multiple technical approaches with trade-off analysis and feasibility assessments
-- **Value Delivery Framework**: Prioritized feature concepts aligned with business objectives and user needs
-- **Risk and Opportunity Analysis**: Identified technical dependencies, integration challenges, and innovation opportunities
-- **Strategic Recommendation**: Synthesized direction with rationale and implementation considerations

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

@@ -1,221 +0,0 @@
-# Game Brief Workflow
-
-## Overview
-
-The Game Brief workflow is the starting point for game projects in the BMad Method. It's a lightweight, interactive brainstorming and planning session that captures your game vision before diving into detailed Game Design Documents (GDD).
-
-## Purpose
-
-**Game Brief answers:**
-
-- What game are you making?
-- Who is it for?
-- What makes it unique?
-- Is it feasible?
-
-**This is NOT:**
-
-- A full Game Design Document
-- A technical specification
-- A production plan
-- A detailed content outline
-
-## When to Use This Workflow
-
-Use the game-brief workflow when:
-
-- Starting a new game project from scratch
-- Exploring a game idea before committing
-- Pitching a concept to team/stakeholders
-- Validating market fit and feasibility
-- Preparing input for the GDD workflow
-
-Skip if:
-
-- You already have a complete GDD
-- Continuing an existing project
-- Prototyping without planning needs
-
-## Workflow Structure
-
-### Interactive Mode (Recommended)
-
-Work through each section collaboratively:
-
-1. Game Vision (concept, pitch, vision statement)
-2. Target Market (audience, competition, positioning)
-3. Game Fundamentals (pillars, mechanics, experience goals)
-4. Scope and Constraints (platforms, timeline, budget, team)
-5. Reference Framework (inspiration, competitors, differentiators)
-6. Content Framework (world, narrative, volume)
-7. Art and Audio Direction (visual and audio style)
-8. Risk Assessment (risks, challenges, mitigation)
-9. Success Criteria (MVP, metrics, launch goals)
-10. Next Steps (immediate actions, research, questions)
-
-### YOLO Mode
-
-AI generates complete draft, then you refine sections iteratively.
-
-## Key Features
-
-### Optional Inputs
-
-The workflow can incorporate:
-
-- Market research
-- Brainstorming results
-- Competitive analysis
-- Design notes
-- Reference game lists
-
-### Realistic Scoping
-
-The workflow actively helps you:
-
-- Identify scope vs. resource mismatches
-- Assess technical feasibility
-- Recognize market risks
-- Plan mitigation strategies
-
-### Clear Handoff
-
-Output is designed to feed directly into:
-
-- GDD workflow (2-plan phase)
-- Prototyping decisions
-- Team discussions
-- Stakeholder presentations
-
-## Output
-
-**game-brief-{game_name}-{date}.md** containing:
-
-- Executive summary
-- Complete game vision
-- Target market analysis
-- Core gameplay definition
-- Scope and constraints
-- Reference framework
-- Art/audio direction
-- Risk assessment
-- Success criteria
-- Next steps
-
-## Integration with BMad Method
-
-```
-1-analysis/game-brief     (You are here)
-    ↓
-2-plan-workflows/gdd               (Game Design Document)
-    ↓
-2-plan-workflows/narrative         (Optional: Story-heavy games)
-    ↓
-3-solutioning            (Technical architecture, engine selection)
-    ↓
-4-dev-stories            (Implementation stories)
-```
-
-## Comparison: Game Brief vs. GDD
-
-| Aspect              | Game Brief                  | GDD                       |
-| ------------------- | --------------------------- | ------------------------- |
-| **Purpose**         | Validate concept            | Design for implementation |
-| **Detail Level**    | High-level vision           | Detailed specifications   |
-| **Time Investment** | 1-2 hours                   | 4-10 hours                |
-| **Audience**        | Self, team, stakeholders    | Development team          |
-| **Scope**           | Concept validation          | Implementation roadmap    |
-| **Format**          | Conversational, exploratory | Structured, comprehensive |
-| **Output**          | 3-5 pages                   | 10-30+ pages              |
-
-## Comparison: Game Brief vs. Product Brief
-
-| Aspect            | Game Brief                   | Product Brief                     |
-| ----------------- | ---------------------------- | --------------------------------- |
-| **Focus**         | Player experience, fun, feel | User problems, features, value    |
-| **Metrics**       | Engagement, retention, fun   | Revenue, conversion, satisfaction |
-| **Core Elements** | Gameplay pillars, mechanics  | Problem/solution, user segments   |
-| **References**    | Other games                  | Competitors, market               |
-| **Vision**        | Emotional experience         | Business outcomes                 |
-
-## Example Use Case
-
-### Scenario: Indie Roguelike Card Game
-
-**Starting Point:**
-"I want to make a roguelike card game with a twist"
-
-**After Game Brief:**
-
-- **Core Concept:** "A roguelike card battler where you play as emotions battling inner demons"
-- **Target Audience:** Core gamers who love Slay the Spire, interested in mental health themes
-- **Differentiator:** Emotional narrative system where deck composition affects story
-- **MVP Scope:** 3 characters, 80 cards, 30 enemy types, 3 bosses, 6-hour first run
-- **Platform:** PC (Steam) first, mobile later
-- **Timeline:** 12 months with 2-person team
-- **Key Risk:** Emotional theme might alienate hardcore roguelike fans
-- **Mitigation:** Prototype early, test with target audience, offer "mechanical-only" mode
-
-**Next Steps:**
-
-1. Build card combat prototype (2 weeks)
-2. Test emotional resonance with players
-3. Proceed to GDD workflow if prototype validates
-
-## Tips for Success
-
-### Be Honest About Scope
-
-The most common game dev failure is scope mismatch. Use this workflow to reality-check:
-
-- Can your team actually build this?
-- Is the timeline realistic?
-- Do you have budget for assets?
-
-### Focus on Player Experience
-
-Don't think about code or implementation. Think about:
-
-- What will players DO?
-- How will they FEEL?
-- Why will they CARE?
-
-### Validate Early
-
-The brief identifies assumptions and risks. Don't skip to GDD without:
-
-- Prototyping risky mechanics
-- Testing with target audience
-- Validating market interest
-
-### Use References Wisely
-
-"Like X but with Y" is a starting point, not a differentiator. Push beyond:
-
-- What specifically from reference games?
-- What are you explicitly NOT doing?
-- What's genuinely new?
-
-## FAQ
-
-**Q: Is this required before GDD?**
-A: No, but highly recommended for new projects. You can start directly with GDD if you have a clear vision.
-
-**Q: Can I use this for game jams?**
-A: Yes, but use YOLO mode for speed. Focus on vision, mechanics, and MVP scope.
-
-**Q: What if my game concept changes?**
-A: Revisit and update the brief. It's a living document during early development.
-
-**Q: How detailed should content volume estimates be?**
-A: Rough orders of magnitude are fine. "~50 enemies" not "47 enemies with 3 variants each."
-
-**Q: Should I complete this alone or with my team?**
-A: Involve your team! Collaborative briefs catch blind spots and build shared vision.
-
-## Related Workflows
-
-- **Product Brief** (`1-analysis/product-brief`): For software products, not games
-- **GDD** (`2-plan-workflows/gdd`): Next step after game brief
-- **Narrative Design** (`2-plan-workflows/narrative`): For story-heavy games after GDD
-- **Solutioning** (`3-solutioning`): Technical architecture after planning