From auto-bmad
Run the GDS pre-implementation pipeline: game vision, design, narrative, architecture, testing, and sprint setup
npx claudepluginhub bramvera/claude-code-plugins --plugin auto-bmad# Load Configuration
Read `_bmad/gds/config.yaml` and set the following variables (resolve `{project-root}` to the actual project root path):
| Variable | Source | Example |
|----------|--------|---------|
| `{{output_folder}}` | gds `output_folder` | `_bmad-output` |
| `{{planning_artifacts}}` | gds `planning_artifacts` | `_bmad-output/planning-artifacts` |
| `{{implementation_artifacts}}` | gds `implementation_artifacts` | `_bmad-output/implementation-artifacts` |
| `{{auto_bmad_artifacts}}` | derived: `{{output_folder}}/auto-bmad-artifacts` | `_bmad-output/auto-bmad-artifacts` |
All p...Read _bmad/gds/config.yaml and set the following variables (resolve {project-root} to the actual project root path):
| Variable | Source | Example |
|---|---|---|
{{output_folder}} | gds output_folder | _bmad-output |
{{planning_artifacts}} | gds planning_artifacts | _bmad-output/planning-artifacts |
{{implementation_artifacts}} | gds implementation_artifacts | _bmad-output/implementation-artifacts |
{{auto_bmad_artifacts}} | derived: {{output_folder}}/auto-bmad-artifacts | _bmad-output/auto-bmad-artifacts |
All paths in this command that reference BMAD output directories MUST use these variables — never hardcode _bmad-output paths.
Read {{output_folder}}/project-context.md if it exists. This gives you general context about the project — its purpose, stack, conventions, and current state. Use this context to make informed decisions throughout the pipeline.
Run the GDS pre-implementation lifecycle as a minimal sequence of BMAD slash commands — lightweight orchestration with git safety.
Each step MUST run in its own foreground Task tool call (subagent_type: "general-purpose") so that each agent gets a fresh context window.
The user MUST provide input alongside the command — a game idea, a description, a file path, or any context about what they want to build. Capture everything the user provides as {{USER_INPUT}}.
@rough-idea.md, a path), read the file contents and include them verbatim as part of {{USER_INPUT}}.CRITICAL — Tool usage rules:
Retry policy: If a step fails, run git reset --hard HEAD to discard its partial changes, then retry once. If the retry also fails, stop the pipeline and tell the user:
git reset --hard {{START_COMMIT_HASH}} to roll back the entire pipeline, or git reset --hard HEAD to retry the failed step.Before running, scan for existing artifacts to determine which steps to skip:
{{planning_artifacts}}/ for:
game-brief-*.md — game brief existsgdd.md or gdd/ — GDD existsnarrative-design.md or narrative-design/ — narrative design existsgame-architecture.md or game-architecture/ — game architecture existstest-design-architecture.md or test-design-qa.md — system-level test design exists{{implementation_artifacts}}/ for:
sprint-status.yaml — sprint planning donejest.config.*, vitest.config.*, game engine test configs, etc.) — test framework existsReport which artifacts already exist and which steps will be skipped.
Set {{USER_INPUT_INSTRUCTION}} to: The user provided the following vision for this game — treat it as the primary input and build the game brief around it:\n\n{{USER_INPUT}}
Before running any steps, record:
{{START_TIME}} — run date -u +"%Y-%m-%dT%H:%M:%S" via Bash and store the output{{START_COMMIT_HASH}} — run git rev-parse --short HEAD and store the resultAfter each successful step, the coordinator runs git add -A && git commit --no-verify -m "wip(gds-plan): step N/8 <step-name> - done" and prints a 1-line progress update: Step N/8: <step-name> — <status>. The coordinator must also track a running list of (step_name, status, start_time, end_time) — note the wall-clock time before and after each Task call to use in the final report.
/gds-create-game-brief yolo — {{USER_INPUT_INSTRUCTION}}Create GDD
/gds-create-gdd ultrathink yolo — {{USER_INPUT_INSTRUCTION}}Create Narrative Design
/gds-create-narrative ultrathink yoloCreate Game Architecture
/gds-game-architecture ultrathink yoloTest Framework Setup
/gds-test-framework yoloGame Test Design
/gds-test-design ultrathink yolo — run in system-level mode using the GDD, game architecture docs, and epics as input. Focus on game-specific test scenarios: core gameplay loops, game systems interactions, state management, performance under load, and platform-specific behaviors. IMPORTANT test strategy constraints: (1) follow a strict test pyramid — push testing effort to the lowest viable layer (unit > integration/API > E2E), (2) E2E tests must be limited to critical happy-path user journeys only — do not duplicate coverage that exists at lower layers, (3) the test design must explicitly define which test types belong at each layer to prevent duplication in downstream workflows.Generate Project Context
/gds-generate-project-context yoloSprint Planning
/gds-sprint-planning yolo{{END_TIME}} — run date -u +"%Y-%m-%dT%H:%M:%S" via Bash and store the output.{{output_folder}}/ recursively for files modified after {{START_TIME}} to build the artifact list.{{auto_bmad_artifacts}}/ directory if it doesn't exist.{{auto_bmad_artifacts}}/gds-plan-report-YYYY-MM-DD-HHMMSS.md (using {{END_TIME}} for the timestamp).Run the token cost report: python3 "$(find ~/.claude/plugins/cache/bramvera-plugins/auto-bmad -name token-report.py | sort | tail -1)" . — saves accurate billing breakdown to {{auto_bmad_artifacts}}/. Use the Cost: $X.XX standard line for the Est. Cost row.
Use this template for the report:
# Pipeline Report: gds-plan
| Field | Value |
|-------|-------|
| Pipeline | gds-plan |
| Start | {{START_TIME}} |
| End | {{END_TIME}} |
| Duration | <minutes>m |
| Est. Cost | ~$X.XX (see token-report-*.md) |
| Initial Commit | {{START_COMMIT_HASH}} |
## Artifacts
- `<relative-path>` — new/updated
## Pipeline Outcome
| # | Step | Status | Duration | Summary |
|---|------|--------|----------|---------|
| 1 | Game Brief | done/skipped | Xm | <game vision/concept captured> |
| 2 | GDD | done/skipped | Xm | <key mechanics, scope summary, epic count> |
| 3 | Narrative Design | done/skipped | Xm | <story/lore scope, or why skipped (no narrative)> |
| 4 | Game Architecture | done/skipped | Xm | <engine/stack chosen, key systems (e.g. "Unity, ECS, state machine")> |
| 5 | Test Framework | done/skipped | Xm | <framework chosen> |
| 6 | Game Test Design | done/skipped | Xm | <test areas covered> |
| 7 | Project Context | done | Xm | <refreshed or newly generated> |
| 8 | Sprint Planning | done/skipped | Xm | <stories queued for first sprint> |
## Key Decisions & Learnings
Summarize notable decisions, issues, and learnings from the pipeline run. Include only items worth remembering — skip routine outcomes. If nothing notable, write "None."
## Action Items
Report only items that genuinely require human action based on what happened during this pipeline run. If the pipeline completed cleanly with no concerns, write "None — pipeline completed without issues requiring human attention."
For each item, prefix with one of:
- **[Review]** — a design or architecture decision the pipeline made that needs human judgement (e.g., engine/framework choice, mechanic scoping, narrative direction, skipped step rationale)
- **[Verify]** — something the pipeline couldn't fully validate (e.g., game feel alignment with vision, target platform feasibility, asset pipeline readiness)
- **[Attention]** — a risk, gap, or assumption flagged during the run (e.g., undefined game systems, scope-heavy first sprint, missing monetization/multiplayer strategy)
Do NOT include items the pipeline already handled successfully. Do NOT fabricate items to fill a quota.
**IMPORTANT: Use dash syntax (e.g. `/auto-bmad-story`) NOT colon syntax (e.g. `/auto-bmad:story`) when suggesting next commands to the user.**
### Next
- Start a new session with fresh context, then run `/auto-bmad-gds-epic-start <epic-number>` to prepare the first epic (test design)
- Then run `/auto-bmad-gds-story <epic-story>` for each story in the sprint (one story per session)
git reset --soft {{START_COMMIT_HASH}} — squash all checkpoint commits, keep changes staged.git add -A && git commit -m "chore: GDS plan — pre-implementation pipeline complete"From this point on, do NOT auto-commit. Only commit when the user explicitly asks you to.