bmad-method 4.2.0 → 4.4.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/commands/analyst.md +14 -20
- package/.claude/commands/architect.md +15 -20
- package/.claude/commands/bmad-master.md +18 -26
- package/.claude/commands/bmad-orchestrator.md +80 -33
- package/.claude/commands/dev.md +5 -4
- package/.claude/commands/pm.md +11 -16
- package/.claude/commands/sm.md +20 -25
- package/.cursor/rules/analyst.mdc +13 -19
- package/.cursor/rules/architect.mdc +14 -19
- package/.cursor/rules/bmad-master.mdc +18 -26
- package/.cursor/rules/bmad-orchestrator.mdc +80 -33
- package/.cursor/rules/dev.mdc +5 -4
- package/.cursor/rules/pm.mdc +11 -16
- package/.cursor/rules/sm.mdc +19 -24
- package/.releaserc.json +2 -1
- package/.roo/README.md +0 -11
- package/.vscode/settings.json +4 -0
- package/.windsurf/rules/analyst.md +13 -19
- package/.windsurf/rules/architect.md +14 -19
- package/.windsurf/rules/bmad-master.md +18 -26
- package/.windsurf/rules/bmad-orchestrator.md +80 -33
- package/.windsurf/rules/dev.md +5 -4
- package/.windsurf/rules/pm.md +11 -16
- package/.windsurf/rules/sm.md +19 -24
- package/CHANGELOG.md +126 -2
- package/CONTRIBUTING.md +2 -0
- package/README.md +20 -2
- package/{.bmad-core → bmad-core}/agent-teams/team-all.yml +1 -3
- package/bmad-core/agent-teams/team-fullstack.yml +18 -0
- package/{.bmad-core → bmad-core}/agent-teams/team-no-ui.yml +0 -2
- package/{.bmad-core → bmad-core}/agents/analyst.md +14 -20
- package/{.bmad-core → bmad-core}/agents/architect.md +15 -20
- package/{.bmad-core → bmad-core}/agents/bmad-master.md +18 -26
- package/bmad-core/agents/bmad-orchestrator.md +128 -0
- package/{.bmad-core → bmad-core}/agents/dev.md +5 -4
- package/{.bmad-core → bmad-core}/agents/pm.md +11 -16
- package/{.bmad-core → bmad-core}/agents/qa.md +11 -17
- package/bmad-core/agents/sm.md +55 -0
- package/{.bmad-core → bmad-core}/agents/ux-expert.md +14 -20
- package/bmad-core/bmad-core-config.yml +60 -0
- package/bmad-core/data/bmad-kb.md +47 -0
- package/bmad-core/tasks/doc-migration-task.md +143 -0
- package/bmad-core/tasks/document-project.md +389 -0
- package/bmad-core/tasks/generate-ai-frontend-prompt.md +51 -0
- package/{.bmad-core → bmad-core}/tasks/index-docs.md +8 -3
- package/{.bmad-core → bmad-core}/tasks/shard-doc.md +5 -3
- package/{.bmad-core → bmad-core}/templates/architecture-tmpl.md +16 -13
- package/{.bmad-core → bmad-core}/templates/brownfield-architecture-tmpl.md +6 -6
- package/{.bmad-core → bmad-core}/templates/front-end-spec-tmpl.md +6 -6
- package/{.bmad-core → bmad-core}/templates/fullstack-architecture-tmpl.md +85 -103
- package/{.bmad-core → bmad-core}/templates/prd-tmpl.md +1 -1
- package/bmad-core/templates/simple-project-prd-tmpl.md +461 -0
- package/{.bmad-core → bmad-core}/templates/story-tmpl.md +2 -2
- package/{.bmad-core → bmad-core}/utils/agent-switcher.ide.md +6 -6
- package/{.bmad-core → bmad-core}/utils/workflow-management.md +14 -15
- package/{.bmad-core → bmad-core}/web-bundles/agents/analyst.txt +26 -21
- package/{.bmad-core → bmad-core}/web-bundles/agents/architect.txt +608 -236
- package/{.bmad-core → bmad-core}/web-bundles/agents/bmad-master.txt +467 -1049
- package/bmad-core/web-bundles/agents/bmad-orchestrator.txt +647 -0
- package/{.bmad-core → bmad-core}/web-bundles/agents/dev.txt +5 -4
- package/{.bmad-core → bmad-core}/web-bundles/agents/pm.txt +477 -18
- package/{.bmad-core → bmad-core}/web-bundles/agents/po.txt +3 -3
- package/{.bmad-core → bmad-core}/web-bundles/agents/qa.txt +11 -17
- package/{.bmad-core → bmad-core}/web-bundles/agents/sm.txt +22 -27
- package/{.bmad-core → bmad-core}/web-bundles/agents/ux-expert.txt +57 -70
- package/{.bmad-core → bmad-core}/workflows/greenfield-fullstack.yml +3 -3
- package/{.bmad-core → creator-tools}/tasks/create-agent.md +10 -12
- package/{.bmad-core/tasks/create-expansion-pack.md → creator-tools/tasks/generate-expansion-pack.md} +8 -6
- package/docs/bmad-workflow-guide.md +161 -0
- package/docs/claude-code-guide.md +119 -0
- package/docs/core-architecture.md +213 -0
- package/docs/cursor-guide.md +127 -0
- package/docs/how-to-contribute-with-pull-requests.md +141 -0
- package/docs/roo-code-guide.md +140 -0
- package/docs/user-guide.md +1044 -0
- package/docs/versioning-and-releases.md +4 -4
- package/docs/windsurf-guide.md +127 -0
- package/expansion-packs/README.md +1 -111
- package/expansion-packs/bmad-2d-phaser-game-dev/agent-teams/team-game-dev.yml +12 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.md +58 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.md +66 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.md +51 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/checklists/game-design-checklist.md +201 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/checklists/game-story-dod-checklist.md +160 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/data/bmad-kb.md +254 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/data/development-guidelines.md +631 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/manifest.yml +45 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/tasks/advanced-elicitation.md +111 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/tasks/create-game-story.md +216 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/tasks/game-design-brainstorming.md +308 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-architecture-tmpl.md +560 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-brief-tmpl.md +345 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-design-doc-tmpl.md +331 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/game-story-tmpl.md +235 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/templates/level-design-doc-tmpl.md +451 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/agents/game-designer.txt +1758 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/agents/game-developer.txt +1444 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/agents/game-sm.txt +674 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/team-game-dev.txt +4395 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/web-bundles/teams/team-game-dev.txt +4395 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/workflows/game-dev-greenfield.yml +183 -0
- package/expansion-packs/bmad-2d-phaser-game-dev/workflows/game-prototype.yml +175 -0
- package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/README.md +5 -5
- package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/agents/infra-devops-platform.md +3 -3
- package/expansion-packs/bmad-infrastructure-devops/manifest.yml +23 -0
- package/expansion-packs/bmad-infrastructure-devops/tasks/create-doc.md +74 -0
- package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/templates/infrastructure-platform-from-arch-tmpl.md +0 -0
- package/expansion-packs/bmad-infrastructure-devops/web-bundles/agents/infra-devops-platform.txt +2021 -0
- package/package.json +20 -14
- package/tools/builders/web-builder.js +207 -17
- package/tools/cli.js +55 -7
- package/tools/installer/README.md +2 -2
- package/tools/installer/bin/bmad.js +107 -28
- package/tools/installer/config/install.config.yml +43 -43
- package/tools/installer/lib/config-loader.js +39 -2
- package/tools/installer/lib/file-manager.js +20 -3
- package/tools/installer/lib/ide-setup.js +11 -1
- package/tools/installer/lib/installer.js +275 -29
- package/tools/installer/package-lock.json +538 -336
- package/tools/installer/package.json +8 -8
- package/tools/lib/dependency-resolver.js +2 -2
- package/tools/semantic-release-sync-installer.js +31 -0
- package/tools/sync-installer-version.js +34 -0
- package/tools/upgraders/v3-to-v4-upgrader.js +18 -13
- package/tools/version-bump.js +33 -26
- package/tools/yaml-format.js +54 -25
- package/.bmad-core/agent-teams/team-fullstack.yml +0 -26
- package/.bmad-core/agents/bmad-orchestrator.md +0 -81
- package/.bmad-core/agents/sm.md +0 -60
- package/.bmad-core/data/bmad-kb.md +0 -36
- package/.bmad-core/schemas/agent-team-schema.yml +0 -153
- package/.bmad-core/tasks/create-team.md +0 -229
- package/.bmad-core/tasks/doc-migration-task.md +0 -198
- package/.bmad-core/tasks/generate-ai-frontend-prompt.md +0 -58
- package/.bmad-core/web-bundles/agents/bmad-orchestrator.txt +0 -1455
- package/.bmad-core/web-bundles/teams/team-all.txt +0 -10315
- package/.bmad-core/web-bundles/teams/team-fullstack.txt +0 -9663
- package/.bmad-core/web-bundles/teams/team-no-ui.txt +0 -8504
- package/.claude/settings.local.json +0 -22
- package/expansion-packs/infrastructure-devops/manifest.yml +0 -38
- /package/{.bmad-core → bmad-core}/agents/po.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/architect-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/change-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/pm-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/po-master-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/story-dod-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/checklists/story-draft-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/data/technical-preferences.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/advanced-elicitation.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/brainstorming-techniques.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/brownfield-create-epic.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/brownfield-create-story.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/core-dump.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/correct-course.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/create-deep-research-prompt.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/create-doc.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/create-next-story.md +0 -0
- /package/{.bmad-core → bmad-core}/tasks/execute-checklist.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/agent-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/brownfield-prd-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/competitor-analysis-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/expansion-pack-plan-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/front-end-architecture-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/market-research-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/project-brief-tmpl.md +0 -0
- /package/{.bmad-core → bmad-core}/templates/web-agent-startup-instructions-template.md +0 -0
- /package/{.bmad-core → bmad-core}/utils/template-format.md +0 -0
- /package/{.bmad-core → bmad-core}/workflows/brownfield-fullstack.yml +0 -0
- /package/{.bmad-core → bmad-core}/workflows/brownfield-service.yml +0 -0
- /package/{.bmad-core → bmad-core}/workflows/brownfield-ui.yml +0 -0
- /package/{.bmad-core → bmad-core}/workflows/greenfield-service.yml +0 -0
- /package/{.bmad-core → bmad-core}/workflows/greenfield-ui.yml +0 -0
- /package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/checklists/infrastructure-checklist.md +0 -0
- /package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/tasks/review-infrastructure.md +0 -0
- /package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/tasks/validate-infrastructure.md +0 -0
- /package/expansion-packs/{infrastructure-devops → bmad-infrastructure-devops}/templates/infrastructure-architecture-tmpl.md +0 -0
|
@@ -8,7 +8,7 @@ The easiest way to release new versions is through **automatic semantic releases
|
|
|
8
8
|
|
|
9
9
|
Use these prefixes to control what type of release happens:
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
````bash
|
|
12
12
|
fix: resolve CLI argument parsing bug # → patch release (4.1.0 → 4.1.1)
|
|
13
13
|
feat: add new agent orchestration mode # → minor release (4.1.0 → 4.2.0)
|
|
14
14
|
feat!: redesign CLI interface # → major release (4.1.0 → 5.0.0)
|
|
@@ -35,13 +35,13 @@ git push
|
|
|
35
35
|
|
|
36
36
|
# That's it! Release happens automatically 🎉
|
|
37
37
|
# Users can now run: npx bmad-method (and get the new version)
|
|
38
|
-
|
|
38
|
+
````
|
|
39
39
|
|
|
40
40
|
### Commits That DON'T Trigger Releases
|
|
41
41
|
|
|
42
42
|
These commit types won't create releases (use them for maintenance):
|
|
43
43
|
|
|
44
|
-
|
|
44
|
+
````bash
|
|
45
45
|
chore: update dependencies # No release
|
|
46
46
|
docs: fix typo in readme # No release
|
|
47
47
|
style: format code # No release
|
|
@@ -52,7 +52,7 @@ test: add unit tests # No release
|
|
|
52
52
|
|
|
53
53
|
```bash
|
|
54
54
|
npm run release:test # Safe to run locally - tests the config
|
|
55
|
-
|
|
55
|
+
````
|
|
56
56
|
|
|
57
57
|
---
|
|
58
58
|
|
|
@@ -0,0 +1,127 @@
|
|
|
1
|
+
# BMAD Method Guide for Windsurf
|
|
2
|
+
|
|
3
|
+
This guide walks you through the complete BMAD workflow using Windsurf as your AI-powered IDE.
|
|
4
|
+
|
|
5
|
+
## Step 1: Install BMAD in Your Project
|
|
6
|
+
|
|
7
|
+
1. Navigate to your project directory
|
|
8
|
+
2. Run the BMAD installer:
|
|
9
|
+
```bash
|
|
10
|
+
npx bmad-method install
|
|
11
|
+
```
|
|
12
|
+
3. When prompted:
|
|
13
|
+
- **Installation Type**: Choose "Complete installation (recommended)"
|
|
14
|
+
- **IDE**: Select "Windsurf"
|
|
15
|
+
|
|
16
|
+
This creates a `.bmad-core` folder with all agents and a `.windsurf/rules` folder with agent rules.
|
|
17
|
+
|
|
18
|
+
## Step 2: Set Up Team Fullstack in Gemini
|
|
19
|
+
|
|
20
|
+
For ideation and planning, use Google's Gemini with the team-fullstack configuration:
|
|
21
|
+
|
|
22
|
+
1. Open [Google AI Studio (Gemini)](https://aistudio.google.com/)
|
|
23
|
+
2. Create a new chat
|
|
24
|
+
3. Copy the contents of `/Users/brianmadison/dev/BMAD-METHOD/.bmad-core/web-bundles/teams/team-fullstack.txt`
|
|
25
|
+
4. Paste this content into Gemini to set up the team
|
|
26
|
+
|
|
27
|
+
### Gemini Planning Phase
|
|
28
|
+
|
|
29
|
+
In Gemini, ask the BMAD team to help you:
|
|
30
|
+
|
|
31
|
+
- **Ideate** your project concept
|
|
32
|
+
- **Brainstorm** features and requirements
|
|
33
|
+
- **Create a PRD** (Product Requirements Document)
|
|
34
|
+
- **Design the architecture**
|
|
35
|
+
|
|
36
|
+
Ask questions like:
|
|
37
|
+
|
|
38
|
+
- "Help me brainstorm a [type of application] that does [core functionality]"
|
|
39
|
+
- "Create a comprehensive PRD for this concept"
|
|
40
|
+
- "Design the technical architecture for this system"
|
|
41
|
+
|
|
42
|
+
Copy the PRD and architecture documents that Gemini creates into your project's `docs/` folder:
|
|
43
|
+
|
|
44
|
+
- `docs/prd.md`
|
|
45
|
+
- `docs/architecture.md`
|
|
46
|
+
|
|
47
|
+
## Step 3: Back to Windsurf - Document Sharding
|
|
48
|
+
|
|
49
|
+
Once you have your PRD and architecture documents in the `docs/` folder:
|
|
50
|
+
|
|
51
|
+
1. **Start a new chat in Windsurf**
|
|
52
|
+
2. **Load the bmad-master agent**: Type `@bmad-master`
|
|
53
|
+
3. **Shard the PRD**: Type `*shard-doc docs/prd.md prd`
|
|
54
|
+
4. **Shard the architecture**: Type `*shard-doc docs/architecture.md architecture`
|
|
55
|
+
|
|
56
|
+
This creates organized folders:
|
|
57
|
+
|
|
58
|
+
- `docs/prd/` - Contains broken down PRD sections
|
|
59
|
+
- `docs/architecture/` - Contains broken down architecture sections
|
|
60
|
+
|
|
61
|
+
## Step 4: Story Development Cycle
|
|
62
|
+
|
|
63
|
+
Now begin the iterative development cycle:
|
|
64
|
+
|
|
65
|
+
### Create Stories (Scrum Master)
|
|
66
|
+
|
|
67
|
+
1. **Start a new chat**
|
|
68
|
+
2. **Load SM agent**: Type `@sm`
|
|
69
|
+
3. **Create story**: Type `*create` (this runs the create-next-story task)
|
|
70
|
+
4. **Review the generated story**
|
|
71
|
+
5. **If approved**: Set story status to "Approved" in the story file
|
|
72
|
+
|
|
73
|
+
### Implement Stories (Developer)
|
|
74
|
+
|
|
75
|
+
1. **Start a new chat**
|
|
76
|
+
2. **Load Dev agent**: Type `@dev`
|
|
77
|
+
3. **The agent will ask which story to implement**
|
|
78
|
+
4. **Follow the development tasks** the agent provides
|
|
79
|
+
5. **When story is complete**: Mark status as "Done"
|
|
80
|
+
|
|
81
|
+
### Repeat the Cycle
|
|
82
|
+
|
|
83
|
+
1. **Start a new chat with SM agent** (`@sm`)
|
|
84
|
+
2. **Create next story**: Type `*create`
|
|
85
|
+
3. **Review and approve**
|
|
86
|
+
4. **Start new chat with Dev agent** (`@dev`)
|
|
87
|
+
5. **Implement the story**
|
|
88
|
+
6. **Repeat until project complete**
|
|
89
|
+
|
|
90
|
+
## Available Agent Rules in Windsurf
|
|
91
|
+
|
|
92
|
+
All BMAD agents are available as Windsurf rules (use `@` prefix):
|
|
93
|
+
|
|
94
|
+
- `@bmad-master` - Universal task executor
|
|
95
|
+
- `@sm` - Scrum Master for story creation
|
|
96
|
+
- `@dev` - Full-stack developer for implementation
|
|
97
|
+
- `@architect` - Solution architect for design
|
|
98
|
+
- `@pm` - Product manager for planning
|
|
99
|
+
- `@analyst` - Business analyst for requirements
|
|
100
|
+
- `@qa` - QA specialist for testing
|
|
101
|
+
- `@po` - Product owner for prioritization
|
|
102
|
+
- `@ux-expert` - UX specialist for design
|
|
103
|
+
|
|
104
|
+
## Windsurf-Specific Features
|
|
105
|
+
|
|
106
|
+
- **Agent rules are stored in**: `.windsurf/rules/` as `.md` files
|
|
107
|
+
- **Rule activation**: Rules activate when you mention `@agent-name` in chat
|
|
108
|
+
- **Collaborative workflow**: Windsurf's collaborative features work well with BMAD's agent-switching pattern
|
|
109
|
+
- **Context awareness**: Agents have access to your project context
|
|
110
|
+
|
|
111
|
+
## Key Workflow Principles
|
|
112
|
+
|
|
113
|
+
1. **Always start new chats** when switching agents to avoid context confusion
|
|
114
|
+
2. **Use Gemini for initial planning** and ideation with the team-fullstack bundle
|
|
115
|
+
3. **Use bmad-master for document management** (sharding, templates, etc.)
|
|
116
|
+
4. **Follow the SM → Dev cycle** for consistent story development
|
|
117
|
+
5. **Review and approve stories** before implementation begins
|
|
118
|
+
|
|
119
|
+
## Tips for Success
|
|
120
|
+
|
|
121
|
+
- **Keep chats focused**: Each chat should have one agent and one primary task
|
|
122
|
+
- **Use \*help command**: Every agent supports `*help` to see available commands
|
|
123
|
+
- **Review generated content**: Always review and approve stories before marking them ready
|
|
124
|
+
- **Maintain status updates**: Keep story statuses current (Draft → Approved → InProgress → Done)
|
|
125
|
+
- **Leverage Windsurf's collaboration**: Use the collaborative features for team reviews
|
|
126
|
+
|
|
127
|
+
This workflow ensures systematic, AI-assisted development following agile principles with clear handoffs between planning, story creation, and implementation phases.
|
|
@@ -1,113 +1,3 @@
|
|
|
1
1
|
# BMAD Method Expansion Packs
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
Expansion packs extend BMAD Method with specialized capabilities for specific use cases. They allow teams to add functionality without cluttering the core workflow.
|
|
6
|
-
|
|
7
|
-
## Core BMAD Flow
|
|
8
|
-
|
|
9
|
-
The original BMAD Method follows a simple, proven flow:
|
|
10
|
-
|
|
11
|
-
````text
|
|
12
|
-
Analyst → PM → Architect → SM → Dev
|
|
13
|
-
(Brief) → (PRD) → (Architecture) → (Stories) → (Implementation)
|
|
14
|
-
```text
|
|
15
|
-
|
|
16
|
-
This core flow remains clean and focused on getting from business requirements to working software.
|
|
17
|
-
|
|
18
|
-
## Why Expansion Packs?
|
|
19
|
-
|
|
20
|
-
As BMAD has evolved, we've identified specialized needs that don't fit every project:
|
|
21
|
-
|
|
22
|
-
- Infrastructure and DevOps workflows
|
|
23
|
-
- UX/UI design processes
|
|
24
|
-
- Data engineering pipelines
|
|
25
|
-
- Security and compliance workflows
|
|
26
|
-
- Mobile development patterns
|
|
27
|
-
- Real World assistance and workflows without AI Agents development in mind
|
|
28
|
-
|
|
29
|
-
Rather than complicate the core method, expansion packs let you "opt-in" to additional capabilities.
|
|
30
|
-
|
|
31
|
-
## Available Expansion Packs
|
|
32
|
-
|
|
33
|
-
### 1. Infrastructure & DevOps
|
|
34
|
-
|
|
35
|
-
- **Purpose**: Cloud infrastructure design and platform engineering
|
|
36
|
-
- **Adds**: DevOps agent, infrastructure templates, validation checklists
|
|
37
|
-
- **Use When**: You need to design and implement cloud infrastructure
|
|
38
|
-
|
|
39
|
-
### 2. UX/Design (Coming Soon)
|
|
40
|
-
|
|
41
|
-
- **Purpose**: User experience and interface design workflows
|
|
42
|
-
- **Adds**: Design Architect agent, UI component templates
|
|
43
|
-
- **Use When**: You need detailed UI/UX design processes
|
|
44
|
-
|
|
45
|
-
### 3. Data Engineering (Planned)
|
|
46
|
-
|
|
47
|
-
- **Purpose**: Data pipeline and analytics infrastructure
|
|
48
|
-
- **Adds**: Data Engineer agent, ETL templates, data architecture patterns
|
|
49
|
-
- **Use When**: You're building data-intensive applications
|
|
50
|
-
|
|
51
|
-
## Structure of an Expansion Pack
|
|
52
|
-
|
|
53
|
-
Each expansion pack contains:
|
|
54
|
-
|
|
55
|
-
```text
|
|
56
|
-
expansion-pack-name/
|
|
57
|
-
├── README.md # Overview and usage instructions
|
|
58
|
-
├── manifest.yml # Installation configuration
|
|
59
|
-
├── agents/ # Agent configurations (.yml)
|
|
60
|
-
├── personas/ # Persona definitions (.md)
|
|
61
|
-
├── ide-agents/ # IDE-specific agents (.ide.md)
|
|
62
|
-
├── templates/ # Document templates (.md)
|
|
63
|
-
├── tasks/ # Specialized tasks (.md)
|
|
64
|
-
└── checklists/ # Validation checklists (.md)
|
|
65
|
-
````
|
|
66
|
-
|
|
67
|
-
## Installing an Expansion Pack
|
|
68
|
-
|
|
69
|
-
### Method 1: NPM Script
|
|
70
|
-
|
|
71
|
-
````bash
|
|
72
|
-
npm run install:expansion <pack-name>
|
|
73
|
-
```text
|
|
74
|
-
|
|
75
|
-
### Method 2: Direct Script
|
|
76
|
-
|
|
77
|
-
```bash
|
|
78
|
-
node tools/install-expansion-pack.js <pack-name>
|
|
79
|
-
````
|
|
80
|
-
|
|
81
|
-
### Method 3: Manual
|
|
82
|
-
|
|
83
|
-
1. Copy files according to manifest.yml
|
|
84
|
-
2. Update team configurations as needed
|
|
85
|
-
3. Rebuild bundles with `npm run build`
|
|
86
|
-
|
|
87
|
-
## Creating Your Own Expansion Pack
|
|
88
|
-
|
|
89
|
-
1. Create a new folder under `expansion-packs/`
|
|
90
|
-
2. Add your specialized agents, templates, and tasks
|
|
91
|
-
3. Create a manifest.yml defining installation mappings
|
|
92
|
-
4. Write a README explaining purpose and usage
|
|
93
|
-
5. Test installation process
|
|
94
|
-
|
|
95
|
-
## Best Practices
|
|
96
|
-
|
|
97
|
-
1. **Keep Core Simple**: Don't add to core what could be an expansion
|
|
98
|
-
2. **Clear Purpose**: Each pack should solve a specific need
|
|
99
|
-
3. **Self-Contained**: Packs should work independently when possible
|
|
100
|
-
4. **Document Well**: Clear README and usage examples
|
|
101
|
-
5. **Version Compatibility**: Note which BMAD version the pack requires
|
|
102
|
-
|
|
103
|
-
## Future Vision
|
|
104
|
-
|
|
105
|
-
We envision a library of expansion packs for various industries and use cases:
|
|
106
|
-
|
|
107
|
-
- Healthcare compliance workflows
|
|
108
|
-
- Financial services security patterns
|
|
109
|
-
- E-commerce optimization flows
|
|
110
|
-
- Gaming development pipelines
|
|
111
|
-
- IoT device management
|
|
112
|
-
|
|
113
|
-
The goal is to keep BMAD's core simple while allowing infinite extensibility through modular expansion packs.
|
|
3
|
+
Expansion packs extend BMAD-METHOD beyond traditional software development, providing specialized agent teams, templates, and workflows for specific domains and industries. Each pack is a self-contained ecosystem designed to bring the power of AI-assisted workflows to any field. Coming soon.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
bundle:
|
|
2
|
+
name: Game Development Team
|
|
3
|
+
icon: 🎮
|
|
4
|
+
description: Comprehensive game development team specialized in 2D games using Phaser 3 and TypeScript. This team handles the complete game development lifecycle from initial concept brainstorming through detailed design documentation to technical implementation and quality assurance. Specializes in indie games, mobile games, web games, educational games, prototyping, and game feature development with focus on player experience and performance optimization.
|
|
5
|
+
agents:
|
|
6
|
+
- bmad-orchestrator
|
|
7
|
+
- game-designer
|
|
8
|
+
- game-developer
|
|
9
|
+
- game-sm
|
|
10
|
+
workflows:
|
|
11
|
+
- game-dev-greenfield
|
|
12
|
+
- game-prototype
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# game-designer
|
|
2
|
+
|
|
3
|
+
CRITICAL: Read the full YML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
|
4
|
+
|
|
5
|
+
```yaml
|
|
6
|
+
activation-instructions:
|
|
7
|
+
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
|
8
|
+
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
|
9
|
+
- The customization field ALWAYS takes precedence over any conflicting instructions
|
|
10
|
+
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
|
11
|
+
agent:
|
|
12
|
+
name: Alex
|
|
13
|
+
id: game-designer
|
|
14
|
+
title: Game Design Specialist
|
|
15
|
+
icon: 🎮
|
|
16
|
+
whenToUse: Use for game concept development, GDD creation, game mechanics design, and player experience planning
|
|
17
|
+
customization: null
|
|
18
|
+
persona:
|
|
19
|
+
role: Expert Game Designer & Creative Director
|
|
20
|
+
style: Creative, player-focused, systematic, data-informed
|
|
21
|
+
identity: Visionary who creates compelling game experiences through thoughtful design and player psychology understanding
|
|
22
|
+
focus: Defining engaging gameplay systems, balanced progression, and clear development requirements for implementation teams
|
|
23
|
+
core_principles:
|
|
24
|
+
- Player-First Design - Every mechanic serves player engagement and fun
|
|
25
|
+
- Document Everything - Clear specifications enable proper development
|
|
26
|
+
- Iterative Design - Prototype, test, refine approach to all systems
|
|
27
|
+
- Technical Awareness - Design within feasible implementation constraints
|
|
28
|
+
- Data-Driven Decisions - Use metrics and feedback to guide design choices
|
|
29
|
+
- Numbered Options Protocol - Always use numbered lists for user selections
|
|
30
|
+
startup:
|
|
31
|
+
- Greet the user with your name and role, and inform of the *help command
|
|
32
|
+
- CRITICAL: Do NOT automatically create documents or execute tasks during startup
|
|
33
|
+
- CRITICAL: Do NOT create or modify any files during startup
|
|
34
|
+
- Offer to help with game design documentation but wait for explicit user confirmation
|
|
35
|
+
- Only execute tasks when user explicitly requests them
|
|
36
|
+
commands:
|
|
37
|
+
- '*help" - Show numbered list of available commands for selection'
|
|
38
|
+
- '*chat-mode" - Conversational mode with advanced-elicitation for design advice'
|
|
39
|
+
- '*create" - Show numbered list of documents I can create (from templates below)'
|
|
40
|
+
- '*brainstorm {topic}" - Facilitate structured game design brainstorming session'
|
|
41
|
+
- '*research {topic}" - Generate deep research prompt for game-specific investigation'
|
|
42
|
+
- '*elicit" - Run advanced elicitation to clarify game design requirements'
|
|
43
|
+
- '*checklist {checklist}" - Show numbered list of checklists, execute selection'
|
|
44
|
+
- '*exit" - Say goodbye as the Game Designer, and then abandon inhabiting this persona'
|
|
45
|
+
dependencies:
|
|
46
|
+
tasks:
|
|
47
|
+
- create-doc
|
|
48
|
+
- execute-checklist
|
|
49
|
+
- game-design-brainstorming
|
|
50
|
+
- create-deep-research-prompt
|
|
51
|
+
- advanced-elicitation
|
|
52
|
+
templates:
|
|
53
|
+
- game-design-doc-tmpl
|
|
54
|
+
- level-design-doc-tmpl
|
|
55
|
+
- game-brief-tmpl
|
|
56
|
+
checklists:
|
|
57
|
+
- game-design-checklist
|
|
58
|
+
```
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
# game-developer
|
|
2
|
+
|
|
3
|
+
CRITICAL: Read the full YML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
|
4
|
+
|
|
5
|
+
```yaml
|
|
6
|
+
activation-instructions:
|
|
7
|
+
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
|
8
|
+
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
|
9
|
+
- The customization field ALWAYS takes precedence over any conflicting instructions
|
|
10
|
+
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
|
11
|
+
agent:
|
|
12
|
+
name: Maya
|
|
13
|
+
id: game-developer
|
|
14
|
+
title: Game Developer (Phaser 3 & TypeScript)
|
|
15
|
+
icon: 👾
|
|
16
|
+
whenToUse: Use for Phaser 3 implementation, game story development, technical architecture, and code implementation
|
|
17
|
+
customization: null
|
|
18
|
+
persona:
|
|
19
|
+
role: Expert Game Developer & Implementation Specialist
|
|
20
|
+
style: Pragmatic, performance-focused, detail-oriented, test-driven
|
|
21
|
+
identity: Technical expert who transforms game designs into working, optimized Phaser 3 applications
|
|
22
|
+
focus: Story-driven development using game design documents and architecture specifications
|
|
23
|
+
core_principles:
|
|
24
|
+
- Story-Centric Development - Game stories contain ALL implementation details needed
|
|
25
|
+
- Performance Excellence - Target 60 FPS on all supported platforms
|
|
26
|
+
- TypeScript Strict - Type safety prevents runtime errors
|
|
27
|
+
- Component Architecture - Modular, reusable, testable game systems
|
|
28
|
+
- Cross-Platform Optimization - Works seamlessly on desktop and mobile
|
|
29
|
+
- Test-Driven Quality - Comprehensive testing of game logic and systems
|
|
30
|
+
- Numbered Options Protocol - Always use numbered lists for user selections
|
|
31
|
+
startup:
|
|
32
|
+
- Greet the user with your name and role, and inform of the *help command
|
|
33
|
+
- Load development guidelines to ensure consistent coding standards
|
|
34
|
+
- CRITICAL: Do NOT scan docs/stories/ directory automatically during startup
|
|
35
|
+
- CRITICAL: Do NOT begin any implementation tasks automatically
|
|
36
|
+
- Wait for user to specify story or ask for story selection
|
|
37
|
+
- Only load specific story files when user requests implementation
|
|
38
|
+
commands:
|
|
39
|
+
- '*help" - Show numbered list of available commands for selection'
|
|
40
|
+
- '*chat-mode" - Conversational mode for technical advice'
|
|
41
|
+
- '*create" - Show numbered list of documents I can create (from templates below)'
|
|
42
|
+
- '*run-tests" - Execute game-specific linting and tests'
|
|
43
|
+
- '*lint" - Run linting only'
|
|
44
|
+
- '*status" - Show current story progress'
|
|
45
|
+
- '*complete-story" - Finalize story implementation'
|
|
46
|
+
- '*guidelines" - Review development guidelines and coding standards'
|
|
47
|
+
- '*exit" - Say goodbye as the Game Developer, and then abandon inhabiting this persona'
|
|
48
|
+
task-execution:
|
|
49
|
+
flow: Read story → Implement game feature → Write tests → Pass tests → Update [x] → Next task
|
|
50
|
+
updates-ONLY:
|
|
51
|
+
- "Checkboxes: [ ] not started | [-] in progress | [x] complete"
|
|
52
|
+
- "Debug Log: | Task | File | Change | Reverted? |"
|
|
53
|
+
- "Completion Notes: Deviations only, <50 words"
|
|
54
|
+
- "Change Log: Requirement changes only"
|
|
55
|
+
blocking: Unapproved deps | Ambiguous after story check | 3 failures | Missing game config
|
|
56
|
+
done: Game feature works + Tests pass + 60 FPS + No lint errors + Follows Phaser 3 best practices
|
|
57
|
+
dependencies:
|
|
58
|
+
tasks:
|
|
59
|
+
- execute-checklist
|
|
60
|
+
templates:
|
|
61
|
+
- game-architecture-tmpl
|
|
62
|
+
checklists:
|
|
63
|
+
- game-story-dod-checklist
|
|
64
|
+
data:
|
|
65
|
+
- development-guidelines
|
|
66
|
+
```
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# game-sm
|
|
2
|
+
|
|
3
|
+
CRITICAL: Read the full YML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
|
4
|
+
|
|
5
|
+
```yaml
|
|
6
|
+
activation-instructions:
|
|
7
|
+
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
|
8
|
+
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
|
9
|
+
- The customization field ALWAYS takes precedence over any conflicting instructions
|
|
10
|
+
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
|
11
|
+
agent:
|
|
12
|
+
name: Jordan
|
|
13
|
+
id: game-sm
|
|
14
|
+
title: Game Scrum Master
|
|
15
|
+
icon: 🏃♂️
|
|
16
|
+
whenToUse: Use for game story creation, epic management, game development planning, and agile process guidance
|
|
17
|
+
customization: null
|
|
18
|
+
persona:
|
|
19
|
+
role: Technical Game Scrum Master - Game Story Preparation Specialist
|
|
20
|
+
style: Task-oriented, efficient, precise, focused on clear game developer handoffs
|
|
21
|
+
identity: Game story creation expert who prepares detailed, actionable stories for AI game developers
|
|
22
|
+
focus: Creating crystal-clear game development stories that developers can implement without confusion
|
|
23
|
+
core_principles:
|
|
24
|
+
- Task Adherence - Rigorously follow create-game-story procedures
|
|
25
|
+
- Checklist-Driven Validation - Apply game-story-dod-checklist meticulously
|
|
26
|
+
- Clarity for Developer Handoff - Stories must be immediately actionable for game implementation
|
|
27
|
+
- Focus on One Story at a Time - Complete one before starting next
|
|
28
|
+
- Game-Specific Context - Understand Phaser 3, game mechanics, and performance requirements
|
|
29
|
+
- Numbered Options Protocol - Always use numbered lists for selections
|
|
30
|
+
startup:
|
|
31
|
+
- Greet the user with your name and role, and inform of the *help command
|
|
32
|
+
- CRITICAL: Do NOT automatically execute create-game-story tasks during startup
|
|
33
|
+
- CRITICAL: Do NOT create or modify any files during startup
|
|
34
|
+
- Offer to help with game story preparation but wait for explicit user confirmation
|
|
35
|
+
- Only execute tasks when user explicitly requests them
|
|
36
|
+
- "CRITICAL RULE: You are ONLY allowed to create/modify story files - NEVER implement! If asked to implement, tell user they MUST switch to Game Developer Agent"
|
|
37
|
+
commands:
|
|
38
|
+
- '*help" - Show numbered list of available commands for selection'
|
|
39
|
+
- '*chat-mode" - Conversational mode with advanced-elicitation for game dev advice'
|
|
40
|
+
- '*create" - Execute all steps in Create Game Story Task document'
|
|
41
|
+
- '*checklist {checklist}" - Show numbered list of checklists, execute selection'
|
|
42
|
+
- '*exit" - Say goodbye as the Game Scrum Master, and then abandon inhabiting this persona'
|
|
43
|
+
dependencies:
|
|
44
|
+
tasks:
|
|
45
|
+
- create-game-story
|
|
46
|
+
- execute-checklist
|
|
47
|
+
templates:
|
|
48
|
+
- game-story-tmpl
|
|
49
|
+
checklists:
|
|
50
|
+
- game-story-dod-checklist
|
|
51
|
+
```
|
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
# Game Design Document Quality Checklist
|
|
2
|
+
|
|
3
|
+
## Document Completeness
|
|
4
|
+
|
|
5
|
+
### Executive Summary
|
|
6
|
+
|
|
7
|
+
- [ ] **Core Concept** - Game concept is clearly explained in 2-3 sentences
|
|
8
|
+
- [ ] **Target Audience** - Primary and secondary audiences defined with demographics
|
|
9
|
+
- [ ] **Platform Requirements** - Technical platforms and requirements specified
|
|
10
|
+
- [ ] **Unique Selling Points** - 3-5 key differentiators from competitors identified
|
|
11
|
+
- [ ] **Technical Foundation** - Phaser 3 + TypeScript requirements confirmed
|
|
12
|
+
|
|
13
|
+
### Game Design Foundation
|
|
14
|
+
|
|
15
|
+
- [ ] **Game Pillars** - 3-5 core design pillars defined and actionable
|
|
16
|
+
- [ ] **Core Gameplay Loop** - 30-60 second loop documented with specific timings
|
|
17
|
+
- [ ] **Win/Loss Conditions** - Clear victory and failure states defined
|
|
18
|
+
- [ ] **Player Motivation** - Clear understanding of why players will engage
|
|
19
|
+
- [ ] **Scope Realism** - Game scope is achievable with available resources
|
|
20
|
+
|
|
21
|
+
## Gameplay Mechanics
|
|
22
|
+
|
|
23
|
+
### Core Mechanics Documentation
|
|
24
|
+
|
|
25
|
+
- [ ] **Primary Mechanics** - 3-5 core mechanics detailed with implementation notes
|
|
26
|
+
- [ ] **Mechanic Integration** - How mechanics work together is clear
|
|
27
|
+
- [ ] **Player Input** - All input methods specified for each platform
|
|
28
|
+
- [ ] **System Responses** - Game responses to player actions documented
|
|
29
|
+
- [ ] **Performance Impact** - Performance considerations for each mechanic noted
|
|
30
|
+
|
|
31
|
+
### Controls and Interaction
|
|
32
|
+
|
|
33
|
+
- [ ] **Multi-Platform Controls** - Desktop, mobile, and gamepad controls defined
|
|
34
|
+
- [ ] **Input Responsiveness** - Requirements for responsive game feel specified
|
|
35
|
+
- [ ] **Accessibility Options** - Control customization and accessibility considered
|
|
36
|
+
- [ ] **Touch Optimization** - Mobile-specific control adaptations designed
|
|
37
|
+
- [ ] **Edge Case Handling** - Unusual input scenarios addressed
|
|
38
|
+
|
|
39
|
+
## Progression and Balance
|
|
40
|
+
|
|
41
|
+
### Player Progression
|
|
42
|
+
|
|
43
|
+
- [ ] **Progression Type** - Linear, branching, or metroidvania approach defined
|
|
44
|
+
- [ ] **Key Milestones** - Major progression points documented
|
|
45
|
+
- [ ] **Unlock System** - What players unlock and when is specified
|
|
46
|
+
- [ ] **Difficulty Scaling** - How challenge increases over time is detailed
|
|
47
|
+
- [ ] **Player Agency** - Meaningful player choices and consequences defined
|
|
48
|
+
|
|
49
|
+
### Game Balance
|
|
50
|
+
|
|
51
|
+
- [ ] **Balance Parameters** - Numeric values for key game systems provided
|
|
52
|
+
- [ ] **Difficulty Curve** - Appropriate challenge progression designed
|
|
53
|
+
- [ ] **Economy Design** - Resource systems balanced for engagement
|
|
54
|
+
- [ ] **Player Testing** - Plan for validating balance through playtesting
|
|
55
|
+
- [ ] **Iteration Framework** - Process for adjusting balance post-implementation
|
|
56
|
+
|
|
57
|
+
## Level Design Framework
|
|
58
|
+
|
|
59
|
+
### Level Structure
|
|
60
|
+
|
|
61
|
+
- [ ] **Level Types** - Different level categories defined with purposes
|
|
62
|
+
- [ ] **Level Progression** - How players move through levels specified
|
|
63
|
+
- [ ] **Duration Targets** - Expected play time for each level type
|
|
64
|
+
- [ ] **Difficulty Distribution** - Appropriate challenge spread across levels
|
|
65
|
+
- [ ] **Replay Value** - Elements that encourage repeated play designed
|
|
66
|
+
|
|
67
|
+
### Content Guidelines
|
|
68
|
+
|
|
69
|
+
- [ ] **Level Creation Rules** - Clear guidelines for level designers
|
|
70
|
+
- [ ] **Mechanic Introduction** - How new mechanics are taught in levels
|
|
71
|
+
- [ ] **Pacing Variety** - Mix of action, puzzle, and rest moments planned
|
|
72
|
+
- [ ] **Secret Content** - Hidden areas and optional challenges designed
|
|
73
|
+
- [ ] **Accessibility Options** - Multiple difficulty levels or assist modes considered
|
|
74
|
+
|
|
75
|
+
## Technical Implementation Readiness
|
|
76
|
+
|
|
77
|
+
### Performance Requirements
|
|
78
|
+
|
|
79
|
+
- [ ] **Frame Rate Targets** - 60 FPS target with minimum acceptable rates
|
|
80
|
+
- [ ] **Memory Budgets** - Maximum memory usage limits defined
|
|
81
|
+
- [ ] **Load Time Goals** - Acceptable loading times for different content
|
|
82
|
+
- [ ] **Battery Optimization** - Mobile battery usage considerations addressed
|
|
83
|
+
- [ ] **Scalability Plan** - How performance scales across different devices
|
|
84
|
+
|
|
85
|
+
### Platform Specifications
|
|
86
|
+
|
|
87
|
+
- [ ] **Desktop Requirements** - Minimum and recommended PC/Mac specs
|
|
88
|
+
- [ ] **Mobile Optimization** - iOS and Android specific requirements
|
|
89
|
+
- [ ] **Browser Compatibility** - Supported browsers and versions listed
|
|
90
|
+
- [ ] **Cross-Platform Features** - Shared and platform-specific features identified
|
|
91
|
+
- [ ] **Update Strategy** - Plan for post-launch updates and patches
|
|
92
|
+
|
|
93
|
+
### Asset Requirements
|
|
94
|
+
|
|
95
|
+
- [ ] **Art Style Definition** - Clear visual style with reference materials
|
|
96
|
+
- [ ] **Asset Specifications** - Technical requirements for all asset types
|
|
97
|
+
- [ ] **Audio Requirements** - Music and sound effect specifications
|
|
98
|
+
- [ ] **UI/UX Guidelines** - User interface design principles established
|
|
99
|
+
- [ ] **Localization Plan** - Text and cultural localization requirements
|
|
100
|
+
|
|
101
|
+
## Development Planning
|
|
102
|
+
|
|
103
|
+
### Implementation Phases
|
|
104
|
+
|
|
105
|
+
- [ ] **Phase Breakdown** - Development divided into logical phases
|
|
106
|
+
- [ ] **Epic Definitions** - Major development epics identified
|
|
107
|
+
- [ ] **Dependency Mapping** - Prerequisites between features documented
|
|
108
|
+
- [ ] **Risk Assessment** - Technical and design risks identified with mitigation
|
|
109
|
+
- [ ] **Milestone Planning** - Key deliverables and deadlines established
|
|
110
|
+
|
|
111
|
+
### Team Requirements
|
|
112
|
+
|
|
113
|
+
- [ ] **Role Definitions** - Required team roles and responsibilities
|
|
114
|
+
- [ ] **Skill Requirements** - Technical skills needed for implementation
|
|
115
|
+
- [ ] **Resource Allocation** - Time and effort estimates for major features
|
|
116
|
+
- [ ] **External Dependencies** - Third-party tools, assets, or services needed
|
|
117
|
+
- [ ] **Communication Plan** - How team members will coordinate work
|
|
118
|
+
|
|
119
|
+
## Quality Assurance
|
|
120
|
+
|
|
121
|
+
### Success Metrics
|
|
122
|
+
|
|
123
|
+
- [ ] **Technical Metrics** - Measurable technical performance goals
|
|
124
|
+
- [ ] **Gameplay Metrics** - Player engagement and retention targets
|
|
125
|
+
- [ ] **Quality Benchmarks** - Standards for bug rates and polish level
|
|
126
|
+
- [ ] **User Experience Goals** - Specific UX objectives and measurements
|
|
127
|
+
- [ ] **Business Objectives** - Commercial or project success criteria
|
|
128
|
+
|
|
129
|
+
### Testing Strategy
|
|
130
|
+
|
|
131
|
+
- [ ] **Playtesting Plan** - How and when player feedback will be gathered
|
|
132
|
+
- [ ] **Technical Testing** - Performance and compatibility testing approach
|
|
133
|
+
- [ ] **Balance Validation** - Methods for confirming game balance
|
|
134
|
+
- [ ] **Accessibility Testing** - Plan for testing with diverse players
|
|
135
|
+
- [ ] **Iteration Process** - How feedback will drive design improvements
|
|
136
|
+
|
|
137
|
+
## Documentation Quality
|
|
138
|
+
|
|
139
|
+
### Clarity and Completeness
|
|
140
|
+
|
|
141
|
+
- [ ] **Clear Writing** - All sections are well-written and understandable
|
|
142
|
+
- [ ] **Complete Coverage** - No major game systems left undefined
|
|
143
|
+
- [ ] **Actionable Detail** - Enough detail for developers to create implementation stories
|
|
144
|
+
- [ ] **Consistent Terminology** - Game terms used consistently throughout
|
|
145
|
+
- [ ] **Reference Materials** - Links to inspiration, research, and additional resources
|
|
146
|
+
|
|
147
|
+
### Maintainability
|
|
148
|
+
|
|
149
|
+
- [ ] **Version Control** - Change log established for tracking revisions
|
|
150
|
+
- [ ] **Update Process** - Plan for maintaining document during development
|
|
151
|
+
- [ ] **Team Access** - All team members can access and reference the document
|
|
152
|
+
- [ ] **Search Functionality** - Document organized for easy reference and searching
|
|
153
|
+
- [ ] **Living Document** - Process for incorporating feedback and changes
|
|
154
|
+
|
|
155
|
+
## Stakeholder Alignment
|
|
156
|
+
|
|
157
|
+
### Team Understanding
|
|
158
|
+
|
|
159
|
+
- [ ] **Shared Vision** - All team members understand and agree with the game vision
|
|
160
|
+
- [ ] **Role Clarity** - Each team member understands their contribution
|
|
161
|
+
- [ ] **Decision Framework** - Process for making design decisions during development
|
|
162
|
+
- [ ] **Conflict Resolution** - Plan for resolving disagreements about design choices
|
|
163
|
+
- [ ] **Communication Channels** - Regular meetings and feedback sessions planned
|
|
164
|
+
|
|
165
|
+
### External Validation
|
|
166
|
+
|
|
167
|
+
- [ ] **Market Validation** - Competitive analysis and market fit assessment
|
|
168
|
+
- [ ] **Technical Validation** - Feasibility confirmed with technical team
|
|
169
|
+
- [ ] **Resource Validation** - Required resources available and committed
|
|
170
|
+
- [ ] **Timeline Validation** - Development schedule is realistic and achievable
|
|
171
|
+
- [ ] **Quality Validation** - Quality standards align with available time and resources
|
|
172
|
+
|
|
173
|
+
## Final Readiness Assessment
|
|
174
|
+
|
|
175
|
+
### Implementation Preparedness
|
|
176
|
+
|
|
177
|
+
- [ ] **Story Creation Ready** - Document provides sufficient detail for story creation
|
|
178
|
+
- [ ] **Architecture Alignment** - Game design aligns with technical capabilities
|
|
179
|
+
- [ ] **Asset Production** - Asset requirements enable art and audio production
|
|
180
|
+
- [ ] **Development Workflow** - Clear path from design to implementation
|
|
181
|
+
- [ ] **Quality Assurance** - Testing and validation processes established
|
|
182
|
+
|
|
183
|
+
### Document Approval
|
|
184
|
+
|
|
185
|
+
- [ ] **Design Review Complete** - Document reviewed by all relevant stakeholders
|
|
186
|
+
- [ ] **Technical Review Complete** - Technical feasibility confirmed
|
|
187
|
+
- [ ] **Business Review Complete** - Project scope and goals approved
|
|
188
|
+
- [ ] **Final Approval** - Document officially approved for implementation
|
|
189
|
+
- [ ] **Baseline Established** - Current version established as development baseline
|
|
190
|
+
|
|
191
|
+
## Overall Assessment
|
|
192
|
+
|
|
193
|
+
**Document Quality Rating:** ⭐⭐⭐⭐⭐
|
|
194
|
+
|
|
195
|
+
**Ready for Development:** [ ] Yes [ ] No
|
|
196
|
+
|
|
197
|
+
**Key Recommendations:**
|
|
198
|
+
_List any critical items that need attention before moving to implementation phase._
|
|
199
|
+
|
|
200
|
+
**Next Steps:**
|
|
201
|
+
_Outline immediate next actions for the team based on this assessment._
|