Compare commits
16 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
835075e992 | ||
|
|
2cf3ba1ab8 | ||
|
|
f217bdf07e | ||
|
|
c78a35f547 | ||
|
|
d619068ccc | ||
|
|
1e5c0b5351 | ||
|
|
1148b32fa9 | ||
|
|
b07a8b367d | ||
|
|
ff6112d6c2 | ||
|
|
42a41969b0 | ||
|
|
c685b9e328 | ||
|
|
09d2ad6aea | ||
|
|
f723e0b0e8 | ||
|
|
d9a989dbe5 | ||
|
|
bbcc30ac29 | ||
|
|
3267144248 |
42
CHANGELOG.md
42
CHANGELOG.md
@@ -1,3 +1,45 @@
|
||||
## [4.10.3](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.2...v4.10.3) (2025-06-20)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* bundle update ([2cf3ba1](https://github.com/bmadcode/BMAD-METHOD/commit/2cf3ba1ab8dd7e52584bef16a96e65e7d2513c4f))
|
||||
|
||||
## [4.10.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.1...v4.10.2) (2025-06-20)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* file formatting ([c78a35f](https://github.com/bmadcode/BMAD-METHOD/commit/c78a35f547459b07a15d94c827ec05921cd21571))
|
||||
|
||||
## [4.10.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.10.0...v4.10.1) (2025-06-20)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* SM sometimes would skip the rest of the epic stories, fixed ([1148b32](https://github.com/bmadcode/BMAD-METHOD/commit/1148b32fa97586d2f86d07a70ffbf9bb8c327261))
|
||||
|
||||
# [4.10.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.2...v4.10.0) (2025-06-19)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* Core Config and doc sharding is now optional in v4 ([ff6112d](https://github.com/bmadcode/BMAD-METHOD/commit/ff6112d6c2f822ed22c75046f5a14f05e36041c2))
|
||||
|
||||
## [4.9.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.1...v4.9.2) (2025-06-19)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* bad brownfield yml ([09d2ad6](https://github.com/bmadcode/BMAD-METHOD/commit/09d2ad6aea187996d0a2e1dff27d9bf7e3e6dc06))
|
||||
|
||||
## [4.9.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.9.0...v4.9.1) (2025-06-19)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* dist bundles updated ([d9a989d](https://github.com/bmadcode/BMAD-METHOD/commit/d9a989dbe50da62cf598afa07a8588229c56b69c))
|
||||
|
||||
# [4.9.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.8.0...v4.9.0) (2025-06-19)
|
||||
|
||||
|
||||
|
||||
34
README.md
34
README.md
@@ -172,11 +172,37 @@ The upgrade process will:
|
||||
|
||||
After upgrading:
|
||||
|
||||
1. Review your documents in the `docs/` folder
|
||||
2. Use `@bmad-master` agent to run the `doc-migration-task` to align your documents with V4 templates
|
||||
3. If you have separate front-end and backend architecture docs, the migration task will help merge them into a unified `full-stack-architecture.md`
|
||||
1. Review your documents in the `docs/` folder - if you had a PRD or architecture in your old project, copy it from the backup to the docs folder if they are not there.
|
||||
2. Optionally run the `doc-migration-task` to align your documents with V4 templates - you can do this with your agent my saying something like: 'run {drag in task} against {drag prd or arch file from docs} to align with {drag the template from .bmad-core/templates/full-stack-architecture.md}
|
||||
3. If you have separate front-end and backend architecture docs you can modify step 2 to merge both into a single full stack architecture or separate Front and Back end.
|
||||
|
||||
**Note**: The agents in `.bmad-core/` fully replace the items in `bmad-agent/`.
|
||||
The reason #2 and 3 are optional is because now BMad V4 makes sharding optional for the SM. See [Core Configuration](#-core-configuration-new-in-v4)
|
||||
|
||||
**Note**: The agents in `.bmad-core/` fully replace the items in `bmad-agent/` - you can remove the backup folder versions.
|
||||
|
||||
### 🔧 Core Configuration (NEW in V4)
|
||||
|
||||
**Critical**: V4 introduces `bmad-core/core-config.yml` - a powerful configuration file that enables BMAD to work seamlessly with any project structure, whether it's V4-optimized or legacy. You can even now use non-standard PRDs and architectures!
|
||||
|
||||
#### What is core-config.yml?
|
||||
|
||||
This configuration file tells BMAD agents exactly where to find your project documents and how they're structured. It's the key to V4's flexibility and backwards compatibility.
|
||||
|
||||
#### Key Features:
|
||||
|
||||
- **Version Awareness**: Agents understand if your PRD/Architecture follows V4 conventions or earlier versions
|
||||
- **Flexible Document Locations**: Works whether your epics are embedded in PRD or properly sharded
|
||||
- **Developer Context**: Define which files the dev agent should always load
|
||||
- **Debug Support**: Built-in logging for troubleshooting story implementation
|
||||
|
||||
#### Why It Matters:
|
||||
|
||||
- **Use BMAD with ANY project structure** - V3, V4, or custom layouts
|
||||
- **No forced migrations** - Keep your existing document organization
|
||||
- **Customize developer workflow** - Specify exactly which files provide context
|
||||
- **Seamless upgrades** - Start with V3 docs and gradually adopt V4 patterns
|
||||
|
||||
See the [detailed core-config.yml guide](docs/user-guide.md#core-configuration-coreconfigyml) for configuration examples and best practices.
|
||||
|
||||
## Teams & Workflows
|
||||
|
||||
|
||||
@@ -99,6 +99,11 @@ loading:
|
||||
- Agents: Only when transforming
|
||||
- Templates/Tasks: Only when executing
|
||||
- Always indicate loading
|
||||
kb-mode-behavior:
|
||||
- When *kb-mode is invoked, use kb-mode-interaction task
|
||||
- Don't dump all KB content immediately
|
||||
- Present topic areas and wait for user selection
|
||||
- Provide focused, contextual responses
|
||||
workflow-guidance:
|
||||
- Discover available workflows in the bundle at runtime
|
||||
- Understand each workflow's purpose, options, and decision points
|
||||
@@ -112,6 +117,7 @@ dependencies:
|
||||
tasks:
|
||||
- advanced-elicitation
|
||||
- create-doc
|
||||
- kb-mode-interaction
|
||||
data:
|
||||
- bmad-kb
|
||||
utils:
|
||||
|
||||
@@ -66,6 +66,64 @@ npx bmad-method install
|
||||
|
||||
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
|
||||
|
||||
## Core Configuration (core-config.yml)
|
||||
|
||||
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
|
||||
|
||||
### What is core-config.yml?
|
||||
|
||||
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
|
||||
|
||||
- **Version Flexibility**: Work with V3, V4, or custom document structures
|
||||
- **Custom Locations**: Define where your documents and shards live
|
||||
- **Developer Context**: Specify which files the dev agent should always load
|
||||
- **Debug Support**: Built-in logging for troubleshooting
|
||||
|
||||
### Key Configuration Areas
|
||||
|
||||
#### PRD Configuration
|
||||
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
|
||||
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
|
||||
- **prdShardedLocation**: Where to find sharded epic files
|
||||
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
|
||||
|
||||
#### Architecture Configuration
|
||||
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
|
||||
- **architectureSharded**: Whether architecture is split into components
|
||||
- **architectureShardedLocation**: Where sharded architecture files live
|
||||
|
||||
#### Developer Files
|
||||
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
|
||||
- **devDebugLog**: Where dev agent logs repeated failures
|
||||
- **agentCoreDump**: Export location for chat conversations
|
||||
|
||||
### Why It Matters
|
||||
|
||||
1. **No Forced Migrations**: Keep your existing document structure
|
||||
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
|
||||
3. **Custom Workflows**: Configure BMAD to match your team's process
|
||||
4. **Intelligent Agents**: Agents automatically adapt to your configuration
|
||||
|
||||
### Common Configurations
|
||||
|
||||
**Legacy V3 Project**:
|
||||
```yaml
|
||||
prdVersion: v3
|
||||
prdSharded: false
|
||||
architectureVersion: v3
|
||||
architectureSharded: false
|
||||
```
|
||||
|
||||
**V4 Optimized Project**:
|
||||
```yaml
|
||||
prdVersion: v4
|
||||
prdSharded: true
|
||||
prdShardedLocation: docs/prd
|
||||
architectureVersion: v4
|
||||
architectureSharded: true
|
||||
architectureShardedLocation: docs/architecture
|
||||
```
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
### Vibe CEO'ing
|
||||
|
||||
@@ -57,12 +57,40 @@ To identify the next logical story based on project progress and epic definition
|
||||
```
|
||||
|
||||
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
|
||||
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and check for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
|
||||
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., look for `epic-{lastEpicNum + 1}*.md`, then `epic-{lastEpicNum + 2}*.md`, etc.) whose prerequisites are met.
|
||||
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and parse it to find ALL stories in that epic. **ALWAYS select the next sequential story** (e.g., if last was 2.2, next MUST be 2.3).
|
||||
- If the next sequential story has unmet prerequisites, present this to the user:
|
||||
|
||||
```plaintext
|
||||
ALERT: Next story has unmet prerequisites:
|
||||
Story: {epicNum}.{storyNum} - {Story Title}
|
||||
Prerequisites not met: [list specific prerequisites]
|
||||
|
||||
Would you like to:
|
||||
1. Create the story anyway (mark prerequisites as pending)
|
||||
2. Skip to a different story (requires your specific instruction)
|
||||
3. Cancel story creation
|
||||
|
||||
Please choose an option (1/2/3):
|
||||
```
|
||||
|
||||
- If there are no more stories in the current epic (e.g., 2.9 was done and there is no 2.10):
|
||||
|
||||
```plaintext
|
||||
Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed.
|
||||
|
||||
Would you like to:
|
||||
1. Begin Epic {epicNum + 1} with story {epicNum + 1}.1
|
||||
2. Select a specific story to work on
|
||||
3. Cancel story creation
|
||||
|
||||
Please choose an option (1/2/3):
|
||||
```
|
||||
|
||||
- **CRITICAL**: NEVER automatically skip to another epic or non-sequential story. The user MUST explicitly instruct which story to create if skipping the sequential order.
|
||||
|
||||
- **If no story files exist in `docs/stories/`:**
|
||||
- The next story is the first story in the first epic file (look for `epic-1-*.md`, then `epic-2-*.md`, etc.) whose prerequisites are met.
|
||||
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
|
||||
- The next story is ALWAYS 1.1 (the first story of the first epic).
|
||||
- If story 1.1 has unmet prerequisites, follow the same alert process as above.
|
||||
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
|
||||
|
||||
### 2. Gather Core Story Requirements (from Epic)
|
||||
|
||||
70
bmad-core/tasks/kb-mode-interaction.md
Normal file
70
bmad-core/tasks/kb-mode-interaction.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# KB Mode Interaction Task
|
||||
|
||||
## Purpose
|
||||
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
|
||||
|
||||
## Instructions
|
||||
|
||||
When entering KB mode (*kb-mode), follow these steps:
|
||||
|
||||
### 1. Welcome and Guide
|
||||
Announce entering KB mode with a brief, friendly introduction:
|
||||
|
||||
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
|
||||
|
||||
### 2. Present Topic Areas
|
||||
Offer a concise list of main topic areas the user might want to explore:
|
||||
|
||||
**What would you like to know more about?**
|
||||
|
||||
1. **Setup & Installation** - Getting started with BMAD
|
||||
2. **Workflows** - Choosing the right workflow for your project
|
||||
3. **Web vs IDE** - When to use each environment
|
||||
4. **Agents** - Understanding specialized agents and their roles
|
||||
5. **Documents** - PRDs, Architecture, Stories, and more
|
||||
6. **Agile Process** - How BMAD implements Agile methodologies
|
||||
7. **Configuration** - Customizing BMAD for your needs
|
||||
8. **Best Practices** - Tips for effective BMAD usage
|
||||
|
||||
Or ask me about anything else related to BMAD-METHOD!
|
||||
|
||||
### 3. Respond Contextually
|
||||
- Wait for user's specific question or topic selection
|
||||
- Provide focused, relevant information from the knowledge base
|
||||
- Offer to dive deeper or explore related topics
|
||||
- Keep responses concise unless user asks for detailed explanations
|
||||
|
||||
### 4. Interactive Exploration
|
||||
- After answering, suggest related topics they might find helpful
|
||||
- Maintain conversational flow rather than data dumping
|
||||
- Use examples when appropriate
|
||||
- Reference specific documentation sections when relevant
|
||||
|
||||
### 5. Exit Gracefully
|
||||
When user is done or wants to exit KB mode:
|
||||
- Summarize key points discussed if helpful
|
||||
- Remind them they can return to KB mode anytime with *kb-mode
|
||||
- Suggest next steps based on what was discussed
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User**: *kb-mode
|
||||
|
||||
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
|
||||
|
||||
**What would you like to know more about?**
|
||||
|
||||
1. **Setup & Installation** - Getting started with BMAD
|
||||
2. **Workflows** - Choosing the right workflow for your project
|
||||
3. **Web vs IDE** - When to use each environment
|
||||
4. **Agents** - Understanding specialized agents and their roles
|
||||
5. **Documents** - PRDs, Architecture, Stories, and more
|
||||
6. **Agile Process** - How BMAD implements Agile methodologies
|
||||
7. **Configuration** - Customizing BMAD for your needs
|
||||
8. **Best Practices** - Tips for effective BMAD usage
|
||||
|
||||
Or ask me about anything else related to BMAD-METHOD!
|
||||
|
||||
**User**: Tell me about workflows
|
||||
|
||||
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
|
||||
@@ -112,7 +112,7 @@ Create an `index.md` file in the sharded folder that:
|
||||
- [Section Name 2](./section-name-2.md)
|
||||
- [Section Name 3](./section-name-3.md)
|
||||
...
|
||||
```text
|
||||
```
|
||||
|
||||
### 5. Preserve Special Content
|
||||
|
||||
|
||||
@@ -357,7 +357,7 @@ servers:
|
||||
'[object Object]': null
|
||||
description:
|
||||
'[object Object]': null
|
||||
```text
|
||||
```
|
||||
|
||||
^^/CONDITION: has_rest_api^^
|
||||
|
||||
@@ -420,7 +420,6 @@ After presenting the structure, apply `tasks#advanced-elicitation` protocol to r
|
||||
├── {{package-manifest}} # Dependencies manifest
|
||||
├── {{config-files}} # Language/framework configs
|
||||
└── README.md # Project documentation
|
||||
```text
|
||||
|
||||
@{example: monorepo-structure}
|
||||
project-root/
|
||||
@@ -432,6 +431,7 @@ project-root/
|
||||
├── scripts/ # Monorepo management scripts
|
||||
└── package.json # Root package.json with workspaces
|
||||
@{/example}
|
||||
```
|
||||
|
||||
[[LLM: After presenting the source tree structure, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
|
||||
@@ -226,7 +226,7 @@ Present component architecture and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```mermaid
|
||||
{{component_interaction_diagram}}
|
||||
```text
|
||||
```
|
||||
|
||||
## API Design and Integration
|
||||
|
||||
@@ -266,7 +266,7 @@ Present API design and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```json
|
||||
{{response_schema}}
|
||||
```text
|
||||
```
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
|
||||
@@ -78,7 +78,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```mermaid
|
||||
{{sitemap_diagram}}
|
||||
```text
|
||||
```
|
||||
|
||||
@{example: sitemap}
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ Available workflows for [Team Name]:
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
@@ -73,7 +73,7 @@ In Progress:
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
@@ -89,7 +89,7 @@ BMad: I see you've completed Discovery and part of Product Planning.
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-next
|
||||
|
||||
@@ -159,7 +159,7 @@ BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```text
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
@@ -185,7 +185,7 @@ Sally: I see we're in the Product Planning stage of the greenfield-fullstack wor
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```text
|
||||
```
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ workflow:
|
||||
|
||||
sequence:
|
||||
- step: service_analysis
|
||||
agent: architect
|
||||
agent: architect
|
||||
action: analyze existing project and use task document-project
|
||||
creates: multiple documents per the document-project template
|
||||
notes: "Review existing service documentation, codebase, performance metrics, and identify integration dependencies."
|
||||
|
||||
58
dist/agents/analyst.txt
vendored
58
dist/agents/analyst.txt
vendored
@@ -1679,6 +1679,64 @@ npx bmad-method install
|
||||
|
||||
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
|
||||
|
||||
## Core Configuration (core-config.yml)
|
||||
|
||||
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
|
||||
|
||||
### What is core-config.yml?
|
||||
|
||||
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
|
||||
|
||||
- **Version Flexibility**: Work with V3, V4, or custom document structures
|
||||
- **Custom Locations**: Define where your documents and shards live
|
||||
- **Developer Context**: Specify which files the dev agent should always load
|
||||
- **Debug Support**: Built-in logging for troubleshooting
|
||||
|
||||
### Key Configuration Areas
|
||||
|
||||
#### PRD Configuration
|
||||
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
|
||||
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
|
||||
- **prdShardedLocation**: Where to find sharded epic files
|
||||
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
|
||||
|
||||
#### Architecture Configuration
|
||||
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
|
||||
- **architectureSharded**: Whether architecture is split into components
|
||||
- **architectureShardedLocation**: Where sharded architecture files live
|
||||
|
||||
#### Developer Files
|
||||
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
|
||||
- **devDebugLog**: Where dev agent logs repeated failures
|
||||
- **agentCoreDump**: Export location for chat conversations
|
||||
|
||||
### Why It Matters
|
||||
|
||||
1. **No Forced Migrations**: Keep your existing document structure
|
||||
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
|
||||
3. **Custom Workflows**: Configure BMAD to match your team's process
|
||||
4. **Intelligent Agents**: Agents automatically adapt to your configuration
|
||||
|
||||
### Common Configurations
|
||||
|
||||
**Legacy V3 Project**:
|
||||
```yaml
|
||||
prdVersion: v3
|
||||
prdSharded: false
|
||||
architectureVersion: v3
|
||||
architectureSharded: false
|
||||
```
|
||||
|
||||
**V4 Optimized Project**:
|
||||
```yaml
|
||||
prdVersion: v4
|
||||
prdSharded: true
|
||||
prdShardedLocation: docs/prd
|
||||
architectureVersion: v4
|
||||
architectureSharded: true
|
||||
architectureShardedLocation: docs/architecture
|
||||
```
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
### Vibe CEO'ing
|
||||
|
||||
8
dist/agents/architect.txt
vendored
8
dist/agents/architect.txt
vendored
@@ -1335,7 +1335,7 @@ servers:
|
||||
'[object Object]': null
|
||||
description:
|
||||
'[object Object]': null
|
||||
```text
|
||||
```
|
||||
|
||||
^^/CONDITION: has_rest_api^^
|
||||
|
||||
@@ -1398,7 +1398,6 @@ After presenting the structure, apply `tasks#advanced-elicitation` protocol to r
|
||||
├── {{package-manifest}} # Dependencies manifest
|
||||
├── {{config-files}} # Language/framework configs
|
||||
└── README.md # Project documentation
|
||||
```text
|
||||
|
||||
@{example: monorepo-structure}
|
||||
project-root/
|
||||
@@ -1410,6 +1409,7 @@ project-root/
|
||||
├── scripts/ # Monorepo management scripts
|
||||
└── package.json # Root package.json with workspaces
|
||||
@{/example}
|
||||
```
|
||||
|
||||
[[LLM: After presenting the source tree structure, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
@@ -3182,7 +3182,7 @@ Present component architecture and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```mermaid
|
||||
{{component_interaction_diagram}}
|
||||
```text
|
||||
```
|
||||
|
||||
## API Design and Integration
|
||||
|
||||
@@ -3222,7 +3222,7 @@ Present API design and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```json
|
||||
{{response_schema}}
|
||||
```text
|
||||
```
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
|
||||
116
dist/agents/bmad-master.txt
vendored
116
dist/agents/bmad-master.txt
vendored
@@ -1774,12 +1774,40 @@ To identify the next logical story based on project progress and epic definition
|
||||
```
|
||||
|
||||
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
|
||||
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and check for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
|
||||
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., look for `epic-{lastEpicNum + 1}*.md`, then `epic-{lastEpicNum + 2}*.md`, etc.) whose prerequisites are met.
|
||||
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and parse it to find ALL stories in that epic. **ALWAYS select the next sequential story** (e.g., if last was 2.2, next MUST be 2.3).
|
||||
- If the next sequential story has unmet prerequisites, present this to the user:
|
||||
|
||||
```plaintext
|
||||
ALERT: Next story has unmet prerequisites:
|
||||
Story: {epicNum}.{storyNum} - {Story Title}
|
||||
Prerequisites not met: [list specific prerequisites]
|
||||
|
||||
Would you like to:
|
||||
1. Create the story anyway (mark prerequisites as pending)
|
||||
2. Skip to a different story (requires your specific instruction)
|
||||
3. Cancel story creation
|
||||
|
||||
Please choose an option (1/2/3):
|
||||
```
|
||||
|
||||
- If there are no more stories in the current epic (e.g., 2.9 was done and there is no 2.10):
|
||||
|
||||
```plaintext
|
||||
Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed.
|
||||
|
||||
Would you like to:
|
||||
1. Begin Epic {epicNum + 1} with story {epicNum + 1}.1
|
||||
2. Select a specific story to work on
|
||||
3. Cancel story creation
|
||||
|
||||
Please choose an option (1/2/3):
|
||||
```
|
||||
|
||||
- **CRITICAL**: NEVER automatically skip to another epic or non-sequential story. The user MUST explicitly instruct which story to create if skipping the sequential order.
|
||||
|
||||
- **If no story files exist in `docs/stories/`:**
|
||||
- The next story is the first story in the first epic file (look for `epic-1-*.md`, then `epic-2-*.md`, etc.) whose prerequisites are met.
|
||||
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
|
||||
- The next story is ALWAYS 1.1 (the first story of the first epic).
|
||||
- If story 1.1 has unmet prerequisites, follow the same alert process as above.
|
||||
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
|
||||
|
||||
### 2. Gather Core Story Requirements (from Epic)
|
||||
@@ -2392,7 +2420,7 @@ Create an `index.md` file in the sharded folder that:
|
||||
- [Section Name 2](./section-name-2.md)
|
||||
- [Section Name 3](./section-name-3.md)
|
||||
...
|
||||
```text
|
||||
```
|
||||
|
||||
### 5. Preserve Special Content
|
||||
|
||||
@@ -2813,7 +2841,7 @@ servers:
|
||||
'[object Object]': null
|
||||
description:
|
||||
'[object Object]': null
|
||||
```text
|
||||
```
|
||||
|
||||
^^/CONDITION: has_rest_api^^
|
||||
|
||||
@@ -2876,7 +2904,6 @@ After presenting the structure, apply `tasks#advanced-elicitation` protocol to r
|
||||
├── {{package-manifest}} # Dependencies manifest
|
||||
├── {{config-files}} # Language/framework configs
|
||||
└── README.md # Project documentation
|
||||
```text
|
||||
|
||||
@{example: monorepo-structure}
|
||||
project-root/
|
||||
@@ -2888,6 +2915,7 @@ project-root/
|
||||
├── scripts/ # Monorepo management scripts
|
||||
└── package.json # Root package.json with workspaces
|
||||
@{/example}
|
||||
```
|
||||
|
||||
[[LLM: After presenting the source tree structure, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
@@ -3461,7 +3489,7 @@ Present component architecture and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```mermaid
|
||||
{{component_interaction_diagram}}
|
||||
```text
|
||||
```
|
||||
|
||||
## API Design and Integration
|
||||
|
||||
@@ -3501,7 +3529,7 @@ Present API design and apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```json
|
||||
{{response_schema}}
|
||||
```text
|
||||
```
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
@@ -4577,7 +4605,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```mermaid
|
||||
{{sitemap_diagram}}
|
||||
```text
|
||||
```
|
||||
|
||||
@{example: sitemap}
|
||||
|
||||
@@ -8486,6 +8514,64 @@ npx bmad-method install
|
||||
|
||||
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
|
||||
|
||||
## Core Configuration (core-config.yml)
|
||||
|
||||
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
|
||||
|
||||
### What is core-config.yml?
|
||||
|
||||
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
|
||||
|
||||
- **Version Flexibility**: Work with V3, V4, or custom document structures
|
||||
- **Custom Locations**: Define where your documents and shards live
|
||||
- **Developer Context**: Specify which files the dev agent should always load
|
||||
- **Debug Support**: Built-in logging for troubleshooting
|
||||
|
||||
### Key Configuration Areas
|
||||
|
||||
#### PRD Configuration
|
||||
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
|
||||
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
|
||||
- **prdShardedLocation**: Where to find sharded epic files
|
||||
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
|
||||
|
||||
#### Architecture Configuration
|
||||
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
|
||||
- **architectureSharded**: Whether architecture is split into components
|
||||
- **architectureShardedLocation**: Where sharded architecture files live
|
||||
|
||||
#### Developer Files
|
||||
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
|
||||
- **devDebugLog**: Where dev agent logs repeated failures
|
||||
- **agentCoreDump**: Export location for chat conversations
|
||||
|
||||
### Why It Matters
|
||||
|
||||
1. **No Forced Migrations**: Keep your existing document structure
|
||||
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
|
||||
3. **Custom Workflows**: Configure BMAD to match your team's process
|
||||
4. **Intelligent Agents**: Agents automatically adapt to your configuration
|
||||
|
||||
### Common Configurations
|
||||
|
||||
**Legacy V3 Project**:
|
||||
```yaml
|
||||
prdVersion: v3
|
||||
prdSharded: false
|
||||
architectureVersion: v3
|
||||
architectureSharded: false
|
||||
```
|
||||
|
||||
**V4 Optimized Project**:
|
||||
```yaml
|
||||
prdVersion: v4
|
||||
prdSharded: true
|
||||
prdShardedLocation: docs/prd
|
||||
architectureVersion: v4
|
||||
architectureSharded: true
|
||||
architectureShardedLocation: docs/architecture
|
||||
```
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
### Vibe CEO'ing
|
||||
@@ -8933,7 +9019,7 @@ Available workflows for [Team Name]:
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
@@ -8959,7 +9045,7 @@ In Progress:
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
@@ -8975,7 +9061,7 @@ BMad: I see you've completed Discovery and part of Product Planning.
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-next
|
||||
|
||||
@@ -9045,7 +9131,7 @@ BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```text
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
@@ -9071,7 +9157,7 @@ Sally: I see we're in the Product Planning stage of the greenfield-fullstack wor
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```text
|
||||
```
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
|
||||
147
dist/agents/bmad-orchestrator.txt
vendored
147
dist/agents/bmad-orchestrator.txt
vendored
@@ -136,6 +136,11 @@ loading:
|
||||
- Agents: Only when transforming
|
||||
- Templates/Tasks: Only when executing
|
||||
- Always indicate loading
|
||||
kb-mode-behavior:
|
||||
- When *kb-mode is invoked, use kb-mode-interaction task
|
||||
- Don't dump all KB content immediately
|
||||
- Present topic areas and wait for user selection
|
||||
- Provide focused, contextual responses
|
||||
workflow-guidance:
|
||||
- Discover available workflows in the bundle at runtime
|
||||
- Understand each workflow's purpose, options, and decision points
|
||||
@@ -149,6 +154,7 @@ dependencies:
|
||||
tasks:
|
||||
- advanced-elicitation
|
||||
- create-doc
|
||||
- kb-mode-interaction
|
||||
data:
|
||||
- bmad-kb
|
||||
utils:
|
||||
@@ -329,6 +335,79 @@ If template specifies a checklist:
|
||||
- Template markup is for AI processing only - never expose to users
|
||||
==================== END: tasks#create-doc ====================
|
||||
|
||||
==================== START: tasks#kb-mode-interaction ====================
|
||||
# KB Mode Interaction Task
|
||||
|
||||
## Purpose
|
||||
Provide a user-friendly interface to the BMAD knowledge base without overwhelming users with information upfront.
|
||||
|
||||
## Instructions
|
||||
|
||||
When entering KB mode (*kb-mode), follow these steps:
|
||||
|
||||
### 1. Welcome and Guide
|
||||
Announce entering KB mode with a brief, friendly introduction:
|
||||
|
||||
"I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD."
|
||||
|
||||
### 2. Present Topic Areas
|
||||
Offer a concise list of main topic areas the user might want to explore:
|
||||
|
||||
**What would you like to know more about?**
|
||||
|
||||
1. **Setup & Installation** - Getting started with BMAD
|
||||
2. **Workflows** - Choosing the right workflow for your project
|
||||
3. **Web vs IDE** - When to use each environment
|
||||
4. **Agents** - Understanding specialized agents and their roles
|
||||
5. **Documents** - PRDs, Architecture, Stories, and more
|
||||
6. **Agile Process** - How BMAD implements Agile methodologies
|
||||
7. **Configuration** - Customizing BMAD for your needs
|
||||
8. **Best Practices** - Tips for effective BMAD usage
|
||||
|
||||
Or ask me about anything else related to BMAD-METHOD!
|
||||
|
||||
### 3. Respond Contextually
|
||||
- Wait for user's specific question or topic selection
|
||||
- Provide focused, relevant information from the knowledge base
|
||||
- Offer to dive deeper or explore related topics
|
||||
- Keep responses concise unless user asks for detailed explanations
|
||||
|
||||
### 4. Interactive Exploration
|
||||
- After answering, suggest related topics they might find helpful
|
||||
- Maintain conversational flow rather than data dumping
|
||||
- Use examples when appropriate
|
||||
- Reference specific documentation sections when relevant
|
||||
|
||||
### 5. Exit Gracefully
|
||||
When user is done or wants to exit KB mode:
|
||||
- Summarize key points discussed if helpful
|
||||
- Remind them they can return to KB mode anytime with *kb-mode
|
||||
- Suggest next steps based on what was discussed
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User**: *kb-mode
|
||||
|
||||
**Assistant**: I've entered KB mode and have access to the full BMAD knowledge base. I can help you with detailed information about any aspect of BMAD-METHOD.
|
||||
|
||||
**What would you like to know more about?**
|
||||
|
||||
1. **Setup & Installation** - Getting started with BMAD
|
||||
2. **Workflows** - Choosing the right workflow for your project
|
||||
3. **Web vs IDE** - When to use each environment
|
||||
4. **Agents** - Understanding specialized agents and their roles
|
||||
5. **Documents** - PRDs, Architecture, Stories, and more
|
||||
6. **Agile Process** - How BMAD implements Agile methodologies
|
||||
7. **Configuration** - Customizing BMAD for your needs
|
||||
8. **Best Practices** - Tips for effective BMAD usage
|
||||
|
||||
Or ask me about anything else related to BMAD-METHOD!
|
||||
|
||||
**User**: Tell me about workflows
|
||||
|
||||
**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
|
||||
==================== END: tasks#kb-mode-interaction ====================
|
||||
|
||||
==================== START: data#bmad-kb ====================
|
||||
# BMAD Knowledge Base
|
||||
|
||||
@@ -398,6 +477,64 @@ npx bmad-method install
|
||||
|
||||
**Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
|
||||
|
||||
## Core Configuration (core-config.yml)
|
||||
|
||||
**New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
|
||||
|
||||
### What is core-config.yml?
|
||||
|
||||
This configuration file acts as a map for BMAD agents, telling them exactly where to find your project documents and how they're structured. It enables:
|
||||
|
||||
- **Version Flexibility**: Work with V3, V4, or custom document structures
|
||||
- **Custom Locations**: Define where your documents and shards live
|
||||
- **Developer Context**: Specify which files the dev agent should always load
|
||||
- **Debug Support**: Built-in logging for troubleshooting
|
||||
|
||||
### Key Configuration Areas
|
||||
|
||||
#### PRD Configuration
|
||||
- **prdVersion**: Tells agents if PRD follows v3 or v4 conventions
|
||||
- **prdSharded**: Whether epics are embedded (false) or in separate files (true)
|
||||
- **prdShardedLocation**: Where to find sharded epic files
|
||||
- **epicFilePattern**: Pattern for epic filenames (e.g., `epic-{n}*.md`)
|
||||
|
||||
#### Architecture Configuration
|
||||
- **architectureVersion**: v3 (monolithic) or v4 (sharded)
|
||||
- **architectureSharded**: Whether architecture is split into components
|
||||
- **architectureShardedLocation**: Where sharded architecture files live
|
||||
|
||||
#### Developer Files
|
||||
- **devLoadAlwaysFiles**: List of files the dev agent loads for every task
|
||||
- **devDebugLog**: Where dev agent logs repeated failures
|
||||
- **agentCoreDump**: Export location for chat conversations
|
||||
|
||||
### Why It Matters
|
||||
|
||||
1. **No Forced Migrations**: Keep your existing document structure
|
||||
2. **Gradual Adoption**: Start with V3 and migrate to V4 at your pace
|
||||
3. **Custom Workflows**: Configure BMAD to match your team's process
|
||||
4. **Intelligent Agents**: Agents automatically adapt to your configuration
|
||||
|
||||
### Common Configurations
|
||||
|
||||
**Legacy V3 Project**:
|
||||
```yaml
|
||||
prdVersion: v3
|
||||
prdSharded: false
|
||||
architectureVersion: v3
|
||||
architectureSharded: false
|
||||
```
|
||||
|
||||
**V4 Optimized Project**:
|
||||
```yaml
|
||||
prdVersion: v4
|
||||
prdSharded: true
|
||||
prdShardedLocation: docs/prd
|
||||
architectureVersion: v4
|
||||
architectureSharded: true
|
||||
architectureShardedLocation: docs/architecture
|
||||
```
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
### Vibe CEO'ing
|
||||
@@ -810,7 +947,7 @@ Available workflows for [Team Name]:
|
||||
[... etc. ...]
|
||||
|
||||
Use /workflow-start {number or id} to begin a workflow.
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-start {workflow-id}
|
||||
|
||||
@@ -836,7 +973,7 @@ In Progress:
|
||||
- Create PRD (John) - awaiting input
|
||||
|
||||
Next: Technical Architecture
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-resume
|
||||
|
||||
@@ -852,7 +989,7 @@ BMad: I see you've completed Discovery and part of Product Planning.
|
||||
- UX Strategy with Sally (ux-expert)
|
||||
|
||||
Would you like me to load Sally to continue?
|
||||
```text
|
||||
```
|
||||
|
||||
### /workflow-next
|
||||
|
||||
@@ -922,7 +1059,7 @@ BMad: I see you have a PRD and architecture document. Based on these artifacts,
|
||||
- Load Sarah (Product Owner) to validate all artifacts
|
||||
|
||||
Would you like to continue with this workflow?
|
||||
```text
|
||||
```
|
||||
|
||||
## Workflow Context Passing
|
||||
|
||||
@@ -948,7 +1085,7 @@ Sally: I see we're in the Product Planning stage of the greenfield-fullstack wor
|
||||
|
||||
Let's create the UX strategy and UI specifications. First, let me review
|
||||
the PRD to understand the features we're designing for...
|
||||
```text
|
||||
```
|
||||
|
||||
## Multi-Path Workflows
|
||||
|
||||
|
||||
26
dist/agents/dev.txt
vendored
26
dist/agents/dev.txt
vendored
@@ -51,6 +51,12 @@ agent:
|
||||
icon: 💻
|
||||
whenToUse: Use for code implementation, debugging, refactoring, and development best practices
|
||||
customization: null
|
||||
startup:
|
||||
- Announce: Greet the user with your name and role, and inform of the *help command.
|
||||
- CRITICAL: Load .bmad-core/core-config.yml and read devLoadAlwaysFiles list and devDebugLog values
|
||||
- CRITICAL: Load ONLY files specified in devLoadAlwaysFiles. If any missing, inform user but continue
|
||||
- CRITICAL: Do NOT load any story files during startup unless user requested you do
|
||||
- CRITICAL: Do NOT begin development until told to proceed
|
||||
persona:
|
||||
role: Expert Senior Software Engineer & Implementation Specialist
|
||||
style: Extremely concise, pragmatic, detail-oriented, solution-focused
|
||||
@@ -58,30 +64,16 @@ persona:
|
||||
focus: Executing story tasks with precision, updating Dev Agent Record sections only, maintaining minimal context overhead
|
||||
core_principles:
|
||||
- CRITICAL: Story-Centric - Story has ALL info. NEVER load PRD/architecture/other docs files unless explicitly directed in dev notes
|
||||
- CRITICAL: Config-Based Loading - MUST load .bmad-core/core-config.yml at startup, then load ONLY files listed in devLoadAlwaysFiles. Inform user of missing files but continue
|
||||
- CRITICAL: Dev Record Only - ONLY update Dev Agent Record sections (checkboxes/Debug Log/Completion Notes/Change Log)
|
||||
- Sequential Execution - Complete tasks 1-by-1 in order. Mark [x] before next. No skipping
|
||||
- CRITICAL: Dev Record Only - ONLY update story file Dev Agent Record sections (checkboxes/Debug Log/Completion Notes/Change Log)
|
||||
- Strive for Sequential Task Execution - Complete tasks 1-by-1 and mark [x] as completed
|
||||
- Test-Driven Quality - Write tests alongside code. Task incomplete without passing tests
|
||||
- Debug Log Discipline - Log temp changes to table. Revert after fix. Keep story lean
|
||||
- Debug Log Discipline - Log temp changes to md table in devDebugLog. Revert after fix.
|
||||
- Block Only When Critical - HALT for: missing approval/ambiguous reqs/3 failures/missing config
|
||||
- Code Excellence - Clean, secure, maintainable code per loaded standards
|
||||
- Numbered Options - Always use numbered lists when presenting choices
|
||||
startup:
|
||||
- Announce: Greet the user with your name and role, and inform of the *help command.
|
||||
- CRITICAL: Load .bmad-core/core-config.yml and read devLoadAlwaysFiles list
|
||||
- CRITICAL: Load ONLY files specified in devLoadAlwaysFiles. If any missing, inform user but continue
|
||||
- CRITICAL: Do NOT load any story files during startup unless user requested you do
|
||||
- CRITICAL: Do NOT scan docs/stories/ directory automatically
|
||||
- CRITICAL: Do NOT begin any tasks automatically
|
||||
- Wait for user to specify story or ask for story selection
|
||||
- Only load story files and begin work when explicitly requested by user
|
||||
commands:
|
||||
- help: Show numbered list of the following commands to allow selection
|
||||
- chat-mode: Conversational mode for development discussions
|
||||
- run-tests: Execute linting and tests
|
||||
- lint: Run linting only
|
||||
- dod-check: Run story-dod-checklist
|
||||
- status: Show task progress
|
||||
- debug-log: Show debug entries
|
||||
- complete-story: Finalize to "Review"
|
||||
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
|
||||
|
||||
2
dist/agents/pm.txt
vendored
2
dist/agents/pm.txt
vendored
@@ -1084,7 +1084,7 @@ Create an `index.md` file in the sharded folder that:
|
||||
- [Section Name 2](./section-name-2.md)
|
||||
- [Section Name 3](./section-name-3.md)
|
||||
...
|
||||
```text
|
||||
```
|
||||
|
||||
### 5. Preserve Special Content
|
||||
|
||||
|
||||
2
dist/agents/po.txt
vendored
2
dist/agents/po.txt
vendored
@@ -316,7 +316,7 @@ Create an `index.md` file in the sharded folder that:
|
||||
- [Section Name 2](./section-name-2.md)
|
||||
- [Section Name 3](./section-name-3.md)
|
||||
...
|
||||
```text
|
||||
```
|
||||
|
||||
### 5. Preserve Special Content
|
||||
|
||||
|
||||
36
dist/agents/sm.txt
vendored
36
dist/agents/sm.txt
vendored
@@ -149,12 +149,40 @@ To identify the next logical story based on project progress and epic definition
|
||||
```
|
||||
|
||||
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
|
||||
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and check for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
|
||||
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., look for `epic-{lastEpicNum + 1}*.md`, then `epic-{lastEpicNum + 2}*.md`, etc.) whose prerequisites are met.
|
||||
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}*.md`) and parse it to find ALL stories in that epic. **ALWAYS select the next sequential story** (e.g., if last was 2.2, next MUST be 2.3).
|
||||
- If the next sequential story has unmet prerequisites, present this to the user:
|
||||
|
||||
```plaintext
|
||||
ALERT: Next story has unmet prerequisites:
|
||||
Story: {epicNum}.{storyNum} - {Story Title}
|
||||
Prerequisites not met: [list specific prerequisites]
|
||||
|
||||
Would you like to:
|
||||
1. Create the story anyway (mark prerequisites as pending)
|
||||
2. Skip to a different story (requires your specific instruction)
|
||||
3. Cancel story creation
|
||||
|
||||
Please choose an option (1/2/3):
|
||||
```
|
||||
|
||||
- If there are no more stories in the current epic (e.g., 2.9 was done and there is no 2.10):
|
||||
|
||||
```plaintext
|
||||
Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed.
|
||||
|
||||
Would you like to:
|
||||
1. Begin Epic {epicNum + 1} with story {epicNum + 1}.1
|
||||
2. Select a specific story to work on
|
||||
3. Cancel story creation
|
||||
|
||||
Please choose an option (1/2/3):
|
||||
```
|
||||
|
||||
- **CRITICAL**: NEVER automatically skip to another epic or non-sequential story. The user MUST explicitly instruct which story to create if skipping the sequential order.
|
||||
|
||||
- **If no story files exist in `docs/stories/`:**
|
||||
- The next story is the first story in the first epic file (look for `epic-1-*.md`, then `epic-2-*.md`, etc.) whose prerequisites are met.
|
||||
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
|
||||
- The next story is ALWAYS 1.1 (the first story of the first epic).
|
||||
- If story 1.1 has unmet prerequisites, follow the same alert process as above.
|
||||
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
|
||||
|
||||
### 2. Gather Core Story Requirements (from Epic)
|
||||
|
||||
2
dist/agents/ux-expert.txt
vendored
2
dist/agents/ux-expert.txt
vendored
@@ -717,7 +717,7 @@ After presenting this section, apply `tasks#advanced-elicitation` protocol]]
|
||||
|
||||
```mermaid
|
||||
{{sitemap_diagram}}
|
||||
```text
|
||||
```
|
||||
|
||||
@{example: sitemap}
|
||||
|
||||
|
||||
@@ -288,6 +288,7 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Begin by understanding the game design context and goals. Ask clarifying questions if needed to determine the best approach for game-specific ideation.]]
|
||||
|
||||
1. **Establish Game Context**
|
||||
|
||||
- Understand the game genre or opportunity area
|
||||
- Identify target audience and platform constraints
|
||||
- Determine session goals (concept exploration vs. mechanic refinement)
|
||||
@@ -443,26 +444,31 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Help user select appropriate techniques based on their specific game design needs.]]
|
||||
|
||||
**For Initial Game Concepts:**
|
||||
|
||||
- What If Game Scenarios
|
||||
- Cross-Genre Fusion
|
||||
- Emotion-First Design
|
||||
|
||||
**For Stuck/Blocked Creativity:**
|
||||
|
||||
- Player Motivation Reversal
|
||||
- Constraint-Based Creativity
|
||||
- Genre Expectation Subversion
|
||||
|
||||
**For Mechanic Development:**
|
||||
|
||||
- SCAMPER for Game Mechanics
|
||||
- Core Loop Deconstruction
|
||||
- Player Agency Spectrum
|
||||
|
||||
**For Player Experience:**
|
||||
|
||||
- Player Archetype Brainstorming
|
||||
- Emotion-First Design
|
||||
- Accessibility-First Innovation
|
||||
|
||||
**For World Building:**
|
||||
|
||||
- Environmental Storytelling
|
||||
- Player-Generated Narrative
|
||||
- Platform-Specific Design
|
||||
@@ -472,16 +478,19 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Guide the brainstorming session with appropriate pacing for game design exploration.]]
|
||||
|
||||
1. **Inspiration Phase** (10-15 min)
|
||||
|
||||
- Reference existing games and mechanics
|
||||
- Explore player experiences and emotions
|
||||
- Gather visual and thematic inspiration
|
||||
|
||||
2. **Divergent Exploration** (25-35 min)
|
||||
|
||||
- Generate many game concepts or mechanics
|
||||
- Use expansion and fusion techniques
|
||||
- Encourage wild and impossible ideas
|
||||
|
||||
3. **Player-Centered Filtering** (15-20 min)
|
||||
|
||||
- Consider target audience reactions
|
||||
- Evaluate emotional impact and engagement
|
||||
- Group ideas by player experience goals
|
||||
@@ -496,6 +505,7 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
[[LLM: Present brainstorming results in a format useful for game development.]]
|
||||
|
||||
**Session Summary:**
|
||||
|
||||
- Techniques used and focus areas
|
||||
- Total concepts/mechanics generated
|
||||
- Key themes and patterns identified
|
||||
@@ -511,21 +521,25 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
**Development Readiness:**
|
||||
|
||||
**Prototype-Ready Ideas:**
|
||||
|
||||
- Ideas that can be tested immediately
|
||||
- Minimum viable implementations
|
||||
- Quick validation approaches
|
||||
|
||||
**Research-Required Ideas:**
|
||||
|
||||
- Concepts needing technical investigation
|
||||
- Player testing and market research needs
|
||||
- Competitive analysis requirements
|
||||
|
||||
**Future Innovation Pipeline:**
|
||||
|
||||
- Ideas requiring significant development
|
||||
- Technology-dependent concepts
|
||||
- Market timing considerations
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
- Which concepts to prototype first
|
||||
- Recommended research areas
|
||||
- Suggested playtesting approaches
|
||||
@@ -534,24 +548,28 @@ This task provides a comprehensive toolkit of creative brainstorming techniques
|
||||
## Game Design Specific Considerations
|
||||
|
||||
### Platform and Audience Awareness
|
||||
|
||||
- Always consider target platform limitations and advantages
|
||||
- Keep target audience preferences and expectations in mind
|
||||
- Balance innovation with familiar game design patterns
|
||||
- Consider monetization and business model implications
|
||||
|
||||
### Rapid Prototyping Mindset
|
||||
|
||||
- Focus on ideas that can be quickly tested
|
||||
- Emphasize core mechanics over complex features
|
||||
- Design for iteration and player feedback
|
||||
- Consider digital and paper prototyping approaches
|
||||
|
||||
### Player Psychology Integration
|
||||
|
||||
- Understand motivation and engagement drivers
|
||||
- Consider learning curves and skill development
|
||||
- Design for different play session lengths
|
||||
- Balance challenge and reward appropriately
|
||||
|
||||
### Technical Feasibility
|
||||
|
||||
- Keep development resources and timeline in mind
|
||||
- Consider art and audio asset requirements
|
||||
- Think about performance and optimization needs
|
||||
@@ -979,6 +997,7 @@ This elicitation task is specifically designed for game development and should b
|
||||
- **Platform Considerations**: When adapting designs for different devices and input methods
|
||||
|
||||
The questions and perspectives offered should always consider:
|
||||
|
||||
- Player psychology and motivation
|
||||
- Technical feasibility with Phaser 3 and TypeScript
|
||||
- Performance implications for 60 FPS targets
|
||||
@@ -1042,6 +1061,7 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
[[LLM: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.]]
|
||||
|
||||
**Primary Loop ({{duration}} seconds):**
|
||||
|
||||
1. {{action_1}} ({{time_1}}s)
|
||||
2. {{action_2}} ({{time_2}}s)
|
||||
3. {{action_3}} ({{time_3}}s)
|
||||
@@ -1052,10 +1072,12 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
[[LLM: Clearly define success and failure states]]
|
||||
|
||||
**Victory Conditions:**
|
||||
|
||||
- {{win_condition_1}}
|
||||
- {{win_condition_2}}
|
||||
|
||||
**Failure States:**
|
||||
|
||||
- {{loss_condition_1}}
|
||||
- {{loss_condition_2}}
|
||||
|
||||
@@ -1076,6 +1098,7 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
**System Response:** {{game_response}}
|
||||
|
||||
**Implementation Notes:**
|
||||
|
||||
- {{tech_requirement_1}}
|
||||
- {{tech_requirement_2}}
|
||||
- {{performance_consideration}}
|
||||
@@ -1088,8 +1111,8 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
|
||||
[[LLM: Define all input methods for different platforms]]
|
||||
|
||||
| Action | Desktop | Mobile | Gamepad |
|
||||
|--------|---------|--------|---------|
|
||||
| Action | Desktop | Mobile | Gamepad |
|
||||
| ------------ | ------- | ----------- | ---------- |
|
||||
| {{action_1}} | {{key}} | {{gesture}} | {{button}} |
|
||||
| {{action_2}} | {{key}} | {{gesture}} | {{button}} |
|
||||
|
||||
@@ -1102,6 +1125,7 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
**Progression Type:** {{linear|branching|metroidvania}}
|
||||
|
||||
**Key Milestones:**
|
||||
|
||||
1. **{{milestone_1}}** - {{unlock_description}}
|
||||
2. **{{milestone_2}}** - {{unlock_description}}
|
||||
3. **{{milestone_3}}** - {{unlock_description}}
|
||||
@@ -1121,9 +1145,9 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
|
||||
[[LLM: Define any in-game currencies, resources, or collectibles]]
|
||||
|
||||
| Resource | Earn Rate | Spend Rate | Purpose | Cap |
|
||||
|----------|-----------|------------|---------|-----|
|
||||
| {{resource_1}} | {{rate}} | {{rate}} | {{use}} | {{max}} |
|
||||
| Resource | Earn Rate | Spend Rate | Purpose | Cap |
|
||||
| -------------- | --------- | ---------- | ------- | ------- |
|
||||
| {{resource_1}} | {{rate}} | {{rate}} | {{use}} | {{max}} |
|
||||
|
||||
^^/CONDITION: has_economy^^
|
||||
|
||||
@@ -1143,6 +1167,7 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
**Difficulty:** {{relative_difficulty}}
|
||||
|
||||
**Structure Template:**
|
||||
|
||||
- Introduction: {{intro_description}}
|
||||
- Challenge: {{main_challenge}}
|
||||
- Resolution: {{completion_requirement}}
|
||||
@@ -1169,11 +1194,13 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
### Platform Specific
|
||||
|
||||
**Desktop:**
|
||||
|
||||
- Resolution: {{min_resolution}} - {{max_resolution}}
|
||||
- Input: Keyboard, Mouse, Gamepad
|
||||
- Browser: Chrome 80+, Firefox 75+, Safari 13+
|
||||
|
||||
**Mobile:**
|
||||
|
||||
- Resolution: {{mobile_min}} - {{mobile_max}}
|
||||
- Input: Touch, Tilt (optional)
|
||||
- OS: iOS 13+, Android 8+
|
||||
@@ -1183,12 +1210,14 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
[[LLM: Define asset specifications for the art and audio teams]]
|
||||
|
||||
**Visual Assets:**
|
||||
|
||||
- Art Style: {{style_description}}
|
||||
- Color Palette: {{color_specification}}
|
||||
- Animation: {{animation_requirements}}
|
||||
- UI Resolution: {{ui_specs}}
|
||||
|
||||
**Audio Assets:**
|
||||
|
||||
- Music Style: {{music_genre}}
|
||||
- Sound Effects: {{sfx_requirements}}
|
||||
- Voice Acting: {{voice_needs}}
|
||||
@@ -1200,6 +1229,7 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
### Engine Configuration
|
||||
|
||||
**Phaser 3 Setup:**
|
||||
|
||||
- TypeScript: Strict mode enabled
|
||||
- Physics: {{physics_system}} (Arcade/Matter)
|
||||
- Renderer: WebGL with Canvas fallback
|
||||
@@ -1208,6 +1238,7 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
### Code Architecture
|
||||
|
||||
**Required Systems:**
|
||||
|
||||
- Scene Management
|
||||
- State Management
|
||||
- Asset Loading
|
||||
@@ -1219,6 +1250,7 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
### Data Management
|
||||
|
||||
**Save Data:**
|
||||
|
||||
- Progress tracking
|
||||
- Settings persistence
|
||||
- Statistics collection
|
||||
@@ -1231,12 +1263,14 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
### Phase 1: Core Systems ({{duration}})
|
||||
|
||||
**Epic: Foundation**
|
||||
|
||||
- Engine setup and configuration
|
||||
- Basic scene management
|
||||
- Core input handling
|
||||
- Asset loading pipeline
|
||||
|
||||
**Epic: Core Mechanics**
|
||||
|
||||
- {{primary_mechanic}} implementation
|
||||
- Basic physics and collision
|
||||
- Player controller
|
||||
@@ -1244,11 +1278,13 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
### Phase 2: Gameplay Features ({{duration}})
|
||||
|
||||
**Epic: Game Systems**
|
||||
|
||||
- {{mechanic_2}} implementation
|
||||
- {{mechanic_3}} implementation
|
||||
- Game state management
|
||||
|
||||
**Epic: Content Creation**
|
||||
|
||||
- Level loading system
|
||||
- First playable levels
|
||||
- Basic UI implementation
|
||||
@@ -1256,11 +1292,13 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
### Phase 3: Polish & Optimization ({{duration}})
|
||||
|
||||
**Epic: Performance**
|
||||
|
||||
- Optimization and profiling
|
||||
- Mobile platform testing
|
||||
- Memory management
|
||||
|
||||
**Epic: User Experience**
|
||||
|
||||
- Audio implementation
|
||||
- Visual effects and polish
|
||||
- Final UI/UX refinement
|
||||
@@ -1270,12 +1308,14 @@ If available, review any provided documents or ask if any are optionally availab
|
||||
[[LLM: Define measurable goals for the game]]
|
||||
|
||||
**Technical Metrics:**
|
||||
|
||||
- Frame rate: {{fps_target}}
|
||||
- Load time: {{load_target}}
|
||||
- Crash rate: <{{crash_threshold}}%
|
||||
- Memory usage: <{{memory_target}}MB
|
||||
|
||||
**Gameplay Metrics:**
|
||||
|
||||
- Tutorial completion: {{completion_rate}}%
|
||||
- Average session: {{session_length}} minutes
|
||||
- Level completion: {{level_completion}}%
|
||||
@@ -1366,19 +1406,23 @@ This framework ensures consistency across all levels while providing flexibility
|
||||
**Difficulty Range:** {{difficulty_scale}}
|
||||
|
||||
**Key Mechanics Featured:**
|
||||
|
||||
- {{mechanic_1}} - {{usage_description}}
|
||||
- {{mechanic_2}} - {{usage_description}}
|
||||
|
||||
**Player Objectives:**
|
||||
|
||||
- Primary: {{primary_objective}}
|
||||
- Secondary: {{secondary_objective}}
|
||||
- Hidden: {{secret_objective}}
|
||||
|
||||
**Success Criteria:**
|
||||
|
||||
- {{completion_requirement_1}}
|
||||
- {{completion_requirement_2}}
|
||||
|
||||
**Technical Requirements:**
|
||||
|
||||
- Maximum entities: {{entity_limit}}
|
||||
- Performance target: {{fps_target}} FPS
|
||||
- Memory budget: {{memory_limit}}MB
|
||||
@@ -1399,6 +1443,7 @@ This framework ensures consistency across all levels while providing flexibility
|
||||
**Total Level Count:** {{number}}
|
||||
|
||||
**World Breakdown:**
|
||||
|
||||
- World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||
- World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||
- World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}}
|
||||
@@ -1408,7 +1453,8 @@ This framework ensures consistency across all levels while providing flexibility
|
||||
[[LLM: Define how challenge increases across the game]]
|
||||
|
||||
**Progression Curve:**
|
||||
```text
|
||||
|
||||
````text
|
||||
Difficulty
|
||||
^ ___/```
|
||||
| /
|
||||
@@ -1418,9 +1464,10 @@ Difficulty
|
||||
|/ /
|
||||
+-----------> Level Number
|
||||
Tutorial Early Mid Late
|
||||
```text
|
||||
````
|
||||
|
||||
**Scaling Parameters:**
|
||||
|
||||
- Enemy count: {{start_count}} → {{end_count}}
|
||||
- Enemy difficulty: {{start_diff}} → {{end_diff}}
|
||||
- Level complexity: {{start_complex}} → {{end_complex}}
|
||||
@@ -1431,6 +1478,7 @@ Difficulty
|
||||
[[LLM: Define how players access new levels]]
|
||||
|
||||
**Progression Gates:**
|
||||
|
||||
- Linear progression: Complete previous level
|
||||
- Star requirements: {{star_count}} stars to unlock
|
||||
- Skill gates: Demonstrate {{skill_requirement}}
|
||||
@@ -1445,14 +1493,17 @@ Difficulty
|
||||
[[LLM: Define all environmental components that can be used in levels]]
|
||||
|
||||
**Terrain Types:**
|
||||
|
||||
- {{terrain_1}}: {{properties_and_usage}}
|
||||
- {{terrain_2}}: {{properties_and_usage}}
|
||||
|
||||
**Interactive Objects:**
|
||||
|
||||
- {{object_1}}: {{behavior_and_purpose}}
|
||||
- {{object_2}}: {{behavior_and_purpose}}
|
||||
|
||||
**Hazards and Obstacles:**
|
||||
|
||||
- {{hazard_1}}: {{damage_and_behavior}}
|
||||
- {{hazard_2}}: {{damage_and_behavior}}
|
||||
|
||||
@@ -1461,15 +1512,18 @@ Difficulty
|
||||
[[LLM: Define all collectible items and their placement rules]]
|
||||
|
||||
**Collectible Types:**
|
||||
|
||||
- {{collectible_1}}: {{value_and_purpose}}
|
||||
- {{collectible_2}}: {{value_and_purpose}}
|
||||
|
||||
**Placement Guidelines:**
|
||||
|
||||
- Mandatory collectibles: {{placement_rules}}
|
||||
- Optional collectibles: {{placement_rules}}
|
||||
- Secret collectibles: {{placement_rules}}
|
||||
|
||||
**Reward Distribution:**
|
||||
|
||||
- Easy to find: {{percentage}}%
|
||||
- Moderate challenge: {{percentage}}%
|
||||
- High skill required: {{percentage}}%
|
||||
@@ -1479,15 +1533,18 @@ Difficulty
|
||||
[[LLM: Define how enemies should be placed and balanced in levels]]
|
||||
|
||||
**Enemy Categories:**
|
||||
|
||||
- {{enemy_type_1}}: {{behavior_and_usage}}
|
||||
- {{enemy_type_2}}: {{behavior_and_usage}}
|
||||
|
||||
**Placement Principles:**
|
||||
|
||||
- Introduction encounters: {{guideline}}
|
||||
- Standard encounters: {{guideline}}
|
||||
- Challenge encounters: {{guideline}}
|
||||
|
||||
**Difficulty Scaling:**
|
||||
|
||||
- Enemy count progression: {{scaling_rule}}
|
||||
- Enemy type introduction: {{pacing_rule}}
|
||||
- Encounter complexity: {{complexity_rule}}
|
||||
@@ -1499,12 +1556,14 @@ Difficulty
|
||||
### Level Layout Principles
|
||||
|
||||
**Spatial Design:**
|
||||
|
||||
- Grid size: {{grid_dimensions}}
|
||||
- Minimum path width: {{width_units}}
|
||||
- Maximum vertical distance: {{height_units}}
|
||||
- Safe zones placement: {{safety_guidelines}}
|
||||
|
||||
**Navigation Design:**
|
||||
|
||||
- Clear path indication: {{visual_cues}}
|
||||
- Landmark placement: {{landmark_rules}}
|
||||
- Dead end avoidance: {{dead_end_policy}}
|
||||
@@ -1515,11 +1574,13 @@ Difficulty
|
||||
[[LLM: Define how to control the rhythm and pace of gameplay within levels]]
|
||||
|
||||
**Action Sequences:**
|
||||
|
||||
- High intensity duration: {{max_duration}}
|
||||
- Rest period requirement: {{min_rest_time}}
|
||||
- Intensity variation: {{pacing_pattern}}
|
||||
|
||||
**Learning Sequences:**
|
||||
|
||||
- New mechanic introduction: {{teaching_method}}
|
||||
- Practice opportunity: {{practice_duration}}
|
||||
- Skill application: {{application_context}}
|
||||
@@ -1529,12 +1590,14 @@ Difficulty
|
||||
[[LLM: Define how to create appropriate challenges for each level type]]
|
||||
|
||||
**Challenge Types:**
|
||||
|
||||
- Execution challenges: {{skill_requirements}}
|
||||
- Puzzle challenges: {{complexity_guidelines}}
|
||||
- Time challenges: {{time_pressure_rules}}
|
||||
- Resource challenges: {{resource_management}}
|
||||
|
||||
**Difficulty Calibration:**
|
||||
|
||||
- Skill check frequency: {{frequency_guidelines}}
|
||||
- Failure recovery: {{retry_mechanics}}
|
||||
- Hint system integration: {{help_system}}
|
||||
@@ -1548,11 +1611,13 @@ Difficulty
|
||||
[[LLM: Define how level data should be structured for implementation]]
|
||||
|
||||
**Level File Format:**
|
||||
|
||||
- Data format: {{json|yaml|custom}}
|
||||
- File naming: `level_{{world}}_{{number}}.{{extension}}`
|
||||
- Data organization: {{structure_description}}
|
||||
|
||||
**Required Data Fields:**
|
||||
|
||||
```json
|
||||
{
|
||||
"levelId": "{{unique_identifier}}",
|
||||
@@ -1584,12 +1649,14 @@ Difficulty
|
||||
[[LLM: Define how level assets are organized and loaded]]
|
||||
|
||||
**Tilemap Requirements:**
|
||||
|
||||
- Tile size: {{tile_dimensions}}px
|
||||
- Tileset organization: {{tileset_structure}}
|
||||
- Layer organization: {{layer_system}}
|
||||
- Collision data: {{collision_format}}
|
||||
|
||||
**Audio Integration:**
|
||||
|
||||
- Background music: {{music_requirements}}
|
||||
- Ambient sounds: {{ambient_system}}
|
||||
- Dynamic audio: {{dynamic_audio_rules}}
|
||||
@@ -1599,16 +1666,19 @@ Difficulty
|
||||
[[LLM: Define performance requirements for level systems]]
|
||||
|
||||
**Entity Limits:**
|
||||
|
||||
- Maximum active entities: {{entity_limit}}
|
||||
- Maximum particles: {{particle_limit}}
|
||||
- Maximum audio sources: {{audio_limit}}
|
||||
|
||||
**Memory Management:**
|
||||
|
||||
- Texture memory budget: {{texture_memory}}MB
|
||||
- Audio memory budget: {{audio_memory}}MB
|
||||
- Level loading time: <{{load_time}}s
|
||||
|
||||
**Culling and LOD:**
|
||||
|
||||
- Off-screen culling: {{culling_distance}}
|
||||
- Level-of-detail rules: {{lod_system}}
|
||||
- Asset streaming: {{streaming_requirements}}
|
||||
@@ -1620,11 +1690,13 @@ Difficulty
|
||||
### Automated Testing
|
||||
|
||||
**Performance Testing:**
|
||||
|
||||
- Frame rate validation: Maintain {{fps_target}} FPS
|
||||
- Memory usage monitoring: Stay under {{memory_limit}}MB
|
||||
- Loading time verification: Complete in <{{load_time}}s
|
||||
|
||||
**Gameplay Testing:**
|
||||
|
||||
- Completion path validation: All objectives achievable
|
||||
- Collectible accessibility: All items reachable
|
||||
- Softlock prevention: No unwinnable states
|
||||
@@ -1632,6 +1704,7 @@ Difficulty
|
||||
### Manual Testing Protocol
|
||||
|
||||
**Playtesting Checklist:**
|
||||
|
||||
- [ ] Level completes within target time range
|
||||
- [ ] All mechanics function correctly
|
||||
- [ ] Difficulty feels appropriate for level category
|
||||
@@ -1639,6 +1712,7 @@ Difficulty
|
||||
- [ ] No exploits or sequence breaks (unless intended)
|
||||
|
||||
**Player Experience Testing:**
|
||||
|
||||
- [ ] Tutorial levels teach effectively
|
||||
- [ ] Challenge feels fair and rewarding
|
||||
- [ ] Flow and pacing maintain engagement
|
||||
@@ -1647,12 +1721,14 @@ Difficulty
|
||||
### Balance Validation
|
||||
|
||||
**Metrics Collection:**
|
||||
|
||||
- Completion rate: Target {{completion_percentage}}%
|
||||
- Average completion time: {{target_time}} ± {{variance}}
|
||||
- Death count per level: <{{max_deaths}}
|
||||
- Collectible discovery rate: {{discovery_percentage}}%
|
||||
|
||||
**Iteration Guidelines:**
|
||||
|
||||
- Adjustment criteria: {{criteria_for_changes}}
|
||||
- Testing sample size: {{minimum_testers}}
|
||||
- Validation period: {{testing_duration}}
|
||||
@@ -1664,12 +1740,14 @@ Difficulty
|
||||
### Design Phase
|
||||
|
||||
**Concept Development:**
|
||||
|
||||
1. Define level purpose and goals
|
||||
2. Create rough layout sketch
|
||||
3. Identify key mechanics and challenges
|
||||
4. Estimate difficulty and duration
|
||||
|
||||
**Documentation Requirements:**
|
||||
|
||||
- Level design brief
|
||||
- Layout diagrams
|
||||
- Mechanic integration notes
|
||||
@@ -1678,6 +1756,7 @@ Difficulty
|
||||
### Implementation Phase
|
||||
|
||||
**Technical Implementation:**
|
||||
|
||||
1. Create level data file
|
||||
2. Build tilemap and layout
|
||||
3. Place entities and objects
|
||||
@@ -1685,6 +1764,7 @@ Difficulty
|
||||
5. Integrate audio and visual effects
|
||||
|
||||
**Quality Assurance:**
|
||||
|
||||
1. Automated testing execution
|
||||
2. Internal playtesting
|
||||
3. Performance validation
|
||||
@@ -1693,12 +1773,14 @@ Difficulty
|
||||
### Integration Phase
|
||||
|
||||
**Game Integration:**
|
||||
|
||||
1. Level progression integration
|
||||
2. Save system compatibility
|
||||
3. Analytics integration
|
||||
4. Achievement system integration
|
||||
|
||||
**Final Validation:**
|
||||
|
||||
1. Full game context testing
|
||||
2. Performance regression testing
|
||||
3. Platform compatibility verification
|
||||
@@ -1709,18 +1791,21 @@ Difficulty
|
||||
[[LLM: Define how to measure level design success]]
|
||||
|
||||
**Player Engagement:**
|
||||
|
||||
- Level completion rate: {{target_rate}}%
|
||||
- Replay rate: {{replay_target}}%
|
||||
- Time spent per level: {{engagement_time}}
|
||||
- Player satisfaction scores: {{satisfaction_target}}/10
|
||||
|
||||
**Technical Performance:**
|
||||
|
||||
- Frame rate consistency: {{fps_consistency}}%
|
||||
- Loading time compliance: {{load_compliance}}%
|
||||
- Memory usage efficiency: {{memory_efficiency}}%
|
||||
- Crash rate: <{{crash_threshold}}%
|
||||
|
||||
**Design Quality:**
|
||||
|
||||
- Difficulty curve adherence: {{curve_accuracy}}
|
||||
- Mechanic integration effectiveness: {{integration_score}}
|
||||
- Player guidance clarity: {{guidance_score}}
|
||||
@@ -1790,11 +1875,13 @@ This brief is typically created early in the ideation process, often after brain
|
||||
[[LLM: List the 3-5 most important gameplay mechanics that define the player experience]]
|
||||
|
||||
**Core Mechanic 1: {{mechanic_name}}**
|
||||
|
||||
- **Description:** {{how_it_works}}
|
||||
- **Player Value:** {{why_its_fun}}
|
||||
- **Implementation Scope:** {{complexity_estimate}}
|
||||
|
||||
**Core Mechanic 2: {{mechanic_name}}**
|
||||
|
||||
- **Description:** {{how_it_works}}
|
||||
- **Player Value:** {{why_its_fun}}
|
||||
- **Implementation Scope:** {{complexity_estimate}}
|
||||
@@ -1821,10 +1908,12 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Technical Constraints
|
||||
|
||||
**Platform Requirements:**
|
||||
|
||||
- Primary: {{platform_1}} - {{requirements}}
|
||||
- Secondary: {{platform_2}} - {{requirements}}
|
||||
|
||||
**Technical Specifications:**
|
||||
|
||||
- Engine: Phaser 3 + TypeScript
|
||||
- Performance Target: {{fps_target}} FPS on {{target_device}}
|
||||
- Memory Budget: <{{memory_limit}}MB
|
||||
@@ -1855,6 +1944,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Inspiration Games
|
||||
|
||||
**Primary References:**
|
||||
|
||||
1. **{{reference_game_1}}** - {{what_we_learn_from_it}}
|
||||
2. **{{reference_game_2}}** - {{what_we_learn_from_it}}
|
||||
3. **{{reference_game_3}}** - {{what_we_learn_from_it}}
|
||||
@@ -1862,6 +1952,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Competitive Analysis
|
||||
|
||||
**Direct Competitors:**
|
||||
|
||||
- {{competitor_1}}: {{strengths_and_weaknesses}}
|
||||
- {{competitor_2}}: {{strengths_and_weaknesses}}
|
||||
|
||||
@@ -1887,13 +1978,16 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Content Categories
|
||||
|
||||
**Core Content:**
|
||||
|
||||
- {{content_type_1}}: {{quantity_and_description}}
|
||||
- {{content_type_2}}: {{quantity_and_description}}
|
||||
|
||||
**Optional Content:**
|
||||
|
||||
- {{optional_content_type}}: {{quantity_and_description}}
|
||||
|
||||
**Replay Elements:**
|
||||
|
||||
- {{replayability_features}}
|
||||
|
||||
### Difficulty and Accessibility
|
||||
@@ -1931,23 +2025,23 @@ This brief is typically created early in the ideation process, often after brain
|
||||
|
||||
### Technical Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
|------|-------------|--------|-------------------|
|
||||
| {{technical_risk_1}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
|
||||
| {{technical_risk_2}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| -------------------- | ----------- | ------ | ------------------- | ------ | --- | ----- | ----------------------- |
|
||||
| {{technical_risk_1}} | {{high | med | low}} | {{high | med | low}} | {{mitigation_approach}} |
|
||||
| {{technical_risk_2}} | {{high | med | low}} | {{high | med | low}} | {{mitigation_approach}} |
|
||||
|
||||
### Design Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
|------|-------------|--------|-------------------|
|
||||
| {{design_risk_1}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
|
||||
| {{design_risk_2}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| ----------------- | ----------- | ------ | ------------------- | ------ | --- | ----- | ----------------------- |
|
||||
| {{design_risk_1}} | {{high | med | low}} | {{high | med | low}} | {{mitigation_approach}} |
|
||||
| {{design_risk_2}} | {{high | med | low}} | {{high | med | low}} | {{mitigation_approach}} |
|
||||
|
||||
### Market Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
|------|-------------|--------|-------------------|
|
||||
| {{market_risk_1}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| ----------------- | ----------- | ------ | ------------------- | ------ | --- | ----- | ----------------------- |
|
||||
| {{market_risk_1}} | {{high | med | low}} | {{high | med | low}} | {{mitigation_approach}} |
|
||||
|
||||
## Success Criteria
|
||||
|
||||
@@ -1956,11 +2050,13 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Player Experience Metrics
|
||||
|
||||
**Engagement Goals:**
|
||||
|
||||
- Tutorial completion rate: >{{percentage}}%
|
||||
- Average session length: {{duration}} minutes
|
||||
- Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}%
|
||||
|
||||
**Quality Benchmarks:**
|
||||
|
||||
- Player satisfaction: >{{rating}}/10
|
||||
- Completion rate: >{{percentage}}%
|
||||
- Technical performance: {{fps_target}} FPS consistent
|
||||
@@ -1968,11 +2064,13 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Development Metrics
|
||||
|
||||
**Technical Targets:**
|
||||
|
||||
- Zero critical bugs at launch
|
||||
- Performance targets met on all platforms
|
||||
- Load times under {{seconds}}s
|
||||
|
||||
**Process Goals:**
|
||||
|
||||
- Development timeline adherence
|
||||
- Feature scope completion
|
||||
- Quality assurance standards
|
||||
@@ -1982,6 +2080,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Business Metrics
|
||||
|
||||
**Commercial Goals:**
|
||||
|
||||
- {{revenue_target}} in first {{time_period}}
|
||||
- {{user_acquisition_target}} players in first {{time_period}}
|
||||
- {{retention_target}} monthly active users
|
||||
@@ -2001,16 +2100,19 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Development Roadmap
|
||||
|
||||
**Phase 1: Pre-Production** ({{duration}})
|
||||
|
||||
- Detailed Game Design Document creation
|
||||
- Technical architecture planning
|
||||
- Art style exploration and pipeline setup
|
||||
|
||||
**Phase 2: Prototype** ({{duration}})
|
||||
|
||||
- Core mechanic implementation
|
||||
- Technical proof of concept
|
||||
- Initial playtesting and iteration
|
||||
|
||||
**Phase 3: Production** ({{duration}})
|
||||
|
||||
- Full feature development
|
||||
- Content creation and integration
|
||||
- Comprehensive testing and optimization
|
||||
@@ -2018,6 +2120,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Documentation Pipeline
|
||||
|
||||
**Required Documents:**
|
||||
|
||||
1. Game Design Document (GDD) - {{target_completion}}
|
||||
2. Technical Architecture Document - {{target_completion}}
|
||||
3. Art Style Guide - {{target_completion}}
|
||||
@@ -2026,10 +2129,12 @@ This brief is typically created early in the ideation process, often after brain
|
||||
### Validation Plan
|
||||
|
||||
**Concept Testing:**
|
||||
|
||||
- {{validation_method_1}} - {{timeline}}
|
||||
- {{validation_method_2}} - {{timeline}}
|
||||
|
||||
**Prototype Testing:**
|
||||
|
||||
- {{testing_approach}} - {{timeline}}
|
||||
- {{feedback_collection_method}} - {{timeline}}
|
||||
|
||||
@@ -2061,6 +2166,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Document Completeness
|
||||
|
||||
### Executive Summary
|
||||
|
||||
- [ ] **Core Concept** - Game concept is clearly explained in 2-3 sentences
|
||||
- [ ] **Target Audience** - Primary and secondary audiences defined with demographics
|
||||
- [ ] **Platform Requirements** - Technical platforms and requirements specified
|
||||
@@ -2068,6 +2174,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Technical Foundation** - Phaser 3 + TypeScript requirements confirmed
|
||||
|
||||
### Game Design Foundation
|
||||
|
||||
- [ ] **Game Pillars** - 3-5 core design pillars defined and actionable
|
||||
- [ ] **Core Gameplay Loop** - 30-60 second loop documented with specific timings
|
||||
- [ ] **Win/Loss Conditions** - Clear victory and failure states defined
|
||||
@@ -2077,6 +2184,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Gameplay Mechanics
|
||||
|
||||
### Core Mechanics Documentation
|
||||
|
||||
- [ ] **Primary Mechanics** - 3-5 core mechanics detailed with implementation notes
|
||||
- [ ] **Mechanic Integration** - How mechanics work together is clear
|
||||
- [ ] **Player Input** - All input methods specified for each platform
|
||||
@@ -2084,6 +2192,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Performance Impact** - Performance considerations for each mechanic noted
|
||||
|
||||
### Controls and Interaction
|
||||
|
||||
- [ ] **Multi-Platform Controls** - Desktop, mobile, and gamepad controls defined
|
||||
- [ ] **Input Responsiveness** - Requirements for responsive game feel specified
|
||||
- [ ] **Accessibility Options** - Control customization and accessibility considered
|
||||
@@ -2093,6 +2202,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Progression and Balance
|
||||
|
||||
### Player Progression
|
||||
|
||||
- [ ] **Progression Type** - Linear, branching, or metroidvania approach defined
|
||||
- [ ] **Key Milestones** - Major progression points documented
|
||||
- [ ] **Unlock System** - What players unlock and when is specified
|
||||
@@ -2100,6 +2210,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Player Agency** - Meaningful player choices and consequences defined
|
||||
|
||||
### Game Balance
|
||||
|
||||
- [ ] **Balance Parameters** - Numeric values for key game systems provided
|
||||
- [ ] **Difficulty Curve** - Appropriate challenge progression designed
|
||||
- [ ] **Economy Design** - Resource systems balanced for engagement
|
||||
@@ -2109,6 +2220,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Level Design Framework
|
||||
|
||||
### Level Structure
|
||||
|
||||
- [ ] **Level Types** - Different level categories defined with purposes
|
||||
- [ ] **Level Progression** - How players move through levels specified
|
||||
- [ ] **Duration Targets** - Expected play time for each level type
|
||||
@@ -2116,6 +2228,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Replay Value** - Elements that encourage repeated play designed
|
||||
|
||||
### Content Guidelines
|
||||
|
||||
- [ ] **Level Creation Rules** - Clear guidelines for level designers
|
||||
- [ ] **Mechanic Introduction** - How new mechanics are taught in levels
|
||||
- [ ] **Pacing Variety** - Mix of action, puzzle, and rest moments planned
|
||||
@@ -2125,6 +2238,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Technical Implementation Readiness
|
||||
|
||||
### Performance Requirements
|
||||
|
||||
- [ ] **Frame Rate Targets** - 60 FPS target with minimum acceptable rates
|
||||
- [ ] **Memory Budgets** - Maximum memory usage limits defined
|
||||
- [ ] **Load Time Goals** - Acceptable loading times for different content
|
||||
@@ -2132,6 +2246,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Scalability Plan** - How performance scales across different devices
|
||||
|
||||
### Platform Specifications
|
||||
|
||||
- [ ] **Desktop Requirements** - Minimum and recommended PC/Mac specs
|
||||
- [ ] **Mobile Optimization** - iOS and Android specific requirements
|
||||
- [ ] **Browser Compatibility** - Supported browsers and versions listed
|
||||
@@ -2139,6 +2254,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Update Strategy** - Plan for post-launch updates and patches
|
||||
|
||||
### Asset Requirements
|
||||
|
||||
- [ ] **Art Style Definition** - Clear visual style with reference materials
|
||||
- [ ] **Asset Specifications** - Technical requirements for all asset types
|
||||
- [ ] **Audio Requirements** - Music and sound effect specifications
|
||||
@@ -2148,6 +2264,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Development Planning
|
||||
|
||||
### Implementation Phases
|
||||
|
||||
- [ ] **Phase Breakdown** - Development divided into logical phases
|
||||
- [ ] **Epic Definitions** - Major development epics identified
|
||||
- [ ] **Dependency Mapping** - Prerequisites between features documented
|
||||
@@ -2155,6 +2272,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Milestone Planning** - Key deliverables and deadlines established
|
||||
|
||||
### Team Requirements
|
||||
|
||||
- [ ] **Role Definitions** - Required team roles and responsibilities
|
||||
- [ ] **Skill Requirements** - Technical skills needed for implementation
|
||||
- [ ] **Resource Allocation** - Time and effort estimates for major features
|
||||
@@ -2164,6 +2282,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Quality Assurance
|
||||
|
||||
### Success Metrics
|
||||
|
||||
- [ ] **Technical Metrics** - Measurable technical performance goals
|
||||
- [ ] **Gameplay Metrics** - Player engagement and retention targets
|
||||
- [ ] **Quality Benchmarks** - Standards for bug rates and polish level
|
||||
@@ -2171,6 +2290,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Business Objectives** - Commercial or project success criteria
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
- [ ] **Playtesting Plan** - How and when player feedback will be gathered
|
||||
- [ ] **Technical Testing** - Performance and compatibility testing approach
|
||||
- [ ] **Balance Validation** - Methods for confirming game balance
|
||||
@@ -2180,6 +2300,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Documentation Quality
|
||||
|
||||
### Clarity and Completeness
|
||||
|
||||
- [ ] **Clear Writing** - All sections are well-written and understandable
|
||||
- [ ] **Complete Coverage** - No major game systems left undefined
|
||||
- [ ] **Actionable Detail** - Enough detail for developers to create implementation stories
|
||||
@@ -2187,6 +2308,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Reference Materials** - Links to inspiration, research, and additional resources
|
||||
|
||||
### Maintainability
|
||||
|
||||
- [ ] **Version Control** - Change log established for tracking revisions
|
||||
- [ ] **Update Process** - Plan for maintaining document during development
|
||||
- [ ] **Team Access** - All team members can access and reference the document
|
||||
@@ -2196,6 +2318,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Stakeholder Alignment
|
||||
|
||||
### Team Understanding
|
||||
|
||||
- [ ] **Shared Vision** - All team members understand and agree with the game vision
|
||||
- [ ] **Role Clarity** - Each team member understands their contribution
|
||||
- [ ] **Decision Framework** - Process for making design decisions during development
|
||||
@@ -2203,6 +2326,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Communication Channels** - Regular meetings and feedback sessions planned
|
||||
|
||||
### External Validation
|
||||
|
||||
- [ ] **Market Validation** - Competitive analysis and market fit assessment
|
||||
- [ ] **Technical Validation** - Feasibility confirmed with technical team
|
||||
- [ ] **Resource Validation** - Required resources available and committed
|
||||
@@ -2212,6 +2336,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
## Final Readiness Assessment
|
||||
|
||||
### Implementation Preparedness
|
||||
|
||||
- [ ] **Story Creation Ready** - Document provides sufficient detail for story creation
|
||||
- [ ] **Architecture Alignment** - Game design aligns with technical capabilities
|
||||
- [ ] **Asset Production** - Asset requirements enable art and audio production
|
||||
@@ -2219,6 +2344,7 @@ This brief is typically created early in the ideation process, often after brain
|
||||
- [ ] **Quality Assurance** - Testing and validation processes established
|
||||
|
||||
### Document Approval
|
||||
|
||||
- [ ] **Design Review Complete** - Document reviewed by all relevant stakeholders
|
||||
- [ ] **Technical Review Complete** - Technical feasibility confirmed
|
||||
- [ ] **Business Review Complete** - Project scope and goals approved
|
||||
|
||||
@@ -290,7 +290,7 @@ This architecture is designed to support the gameplay mechanics defined in the G
|
||||
│ ├── stories/ # Development stories
|
||||
│ └── architecture/ # Technical docs
|
||||
└── dist/ # Built game files
|
||||
```text
|
||||
```
|
||||
|
||||
### Module Organization
|
||||
|
||||
@@ -575,7 +575,7 @@ const gameConfig: Phaser.Types.Core.GameConfig = {
|
||||
},
|
||||
// Additional configuration...
|
||||
};
|
||||
```text
|
||||
```
|
||||
|
||||
### Game Balance Configuration
|
||||
|
||||
@@ -776,6 +776,7 @@ export const GameBalance = {
|
||||
## Story Completeness
|
||||
|
||||
### Basic Story Elements
|
||||
|
||||
- [ ] **Story Title** - Clear, descriptive title that identifies the feature
|
||||
- [ ] **Epic Assignment** - Story is properly assigned to relevant epic
|
||||
- [ ] **Priority Level** - Appropriate priority assigned (High/Medium/Low)
|
||||
@@ -783,6 +784,7 @@ export const GameBalance = {
|
||||
- [ ] **Description** - Clear, concise description of what needs to be implemented
|
||||
|
||||
### Game Design Alignment
|
||||
|
||||
- [ ] **GDD Reference** - Specific Game Design Document section referenced
|
||||
- [ ] **Game Mechanic Context** - Clear connection to game mechanics defined in GDD
|
||||
- [ ] **Player Experience Goal** - Describes the intended player experience
|
||||
@@ -792,6 +794,7 @@ export const GameBalance = {
|
||||
## Technical Specifications
|
||||
|
||||
### Architecture Compliance
|
||||
|
||||
- [ ] **File Organization** - Follows game architecture document structure
|
||||
- [ ] **Class Definitions** - TypeScript interfaces and classes are properly defined
|
||||
- [ ] **Integration Points** - Clear specification of how feature integrates with existing systems
|
||||
@@ -799,6 +802,7 @@ export const GameBalance = {
|
||||
- [ ] **Dependencies** - All system dependencies clearly identified
|
||||
|
||||
### Phaser 3 Requirements
|
||||
|
||||
- [ ] **Scene Integration** - Specifies which scenes are affected and how
|
||||
- [ ] **Game Object Usage** - Proper use of Phaser 3 game objects and components
|
||||
- [ ] **Physics Integration** - Physics requirements specified if applicable
|
||||
@@ -806,6 +810,7 @@ export const GameBalance = {
|
||||
- [ ] **Performance Considerations** - 60 FPS target and optimization requirements
|
||||
|
||||
### Code Quality Standards
|
||||
|
||||
- [ ] **TypeScript Strict Mode** - All code must comply with strict TypeScript
|
||||
- [ ] **Error Handling** - Error scenarios and handling requirements specified
|
||||
- [ ] **Memory Management** - Object pooling and cleanup requirements where needed
|
||||
@@ -815,6 +820,7 @@ export const GameBalance = {
|
||||
## Implementation Readiness
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
- [ ] **Functional Requirements** - All functional acceptance criteria are specific and testable
|
||||
- [ ] **Technical Requirements** - Technical acceptance criteria are complete and verifiable
|
||||
- [ ] **Game Design Requirements** - Game-specific requirements match GDD specifications
|
||||
@@ -822,6 +828,7 @@ export const GameBalance = {
|
||||
- [ ] **Completeness** - No acceptance criteria are vague or unmeasurable
|
||||
|
||||
### Implementation Tasks
|
||||
|
||||
- [ ] **Task Breakdown** - Story broken into specific, ordered implementation tasks
|
||||
- [ ] **Task Scope** - Each task is completable in 1-4 hours
|
||||
- [ ] **Task Clarity** - Each task has clear, actionable instructions
|
||||
@@ -829,6 +836,7 @@ export const GameBalance = {
|
||||
- [ ] **Development Flow** - Tasks follow logical implementation order
|
||||
|
||||
### Dependencies
|
||||
|
||||
- [ ] **Story Dependencies** - All prerequisite stories identified with IDs
|
||||
- [ ] **Technical Dependencies** - Required systems and files identified
|
||||
- [ ] **Asset Dependencies** - All needed assets specified with locations
|
||||
@@ -838,6 +846,7 @@ export const GameBalance = {
|
||||
## Testing Requirements
|
||||
|
||||
### Test Coverage
|
||||
|
||||
- [ ] **Unit Test Requirements** - Specific unit test files and scenarios defined
|
||||
- [ ] **Integration Test Cases** - Integration testing with other game systems specified
|
||||
- [ ] **Manual Test Cases** - Game-specific manual testing procedures defined
|
||||
@@ -845,6 +854,7 @@ export const GameBalance = {
|
||||
- [ ] **Edge Case Testing** - Edge cases and error conditions covered
|
||||
|
||||
### Test Implementation
|
||||
|
||||
- [ ] **Test File Paths** - Exact test file locations specified
|
||||
- [ ] **Test Scenarios** - All test scenarios are complete and executable
|
||||
- [ ] **Expected Behaviors** - Clear expected outcomes for all tests defined
|
||||
@@ -854,6 +864,7 @@ export const GameBalance = {
|
||||
## Game-Specific Quality
|
||||
|
||||
### Gameplay Implementation
|
||||
|
||||
- [ ] **Mechanic Accuracy** - Implementation matches GDD mechanic specifications
|
||||
- [ ] **Player Controls** - Input handling requirements are complete
|
||||
- [ ] **Game Feel** - Requirements for juice, feedback, and responsiveness specified
|
||||
@@ -861,6 +872,7 @@ export const GameBalance = {
|
||||
- [ ] **State Management** - Game state changes and persistence requirements defined
|
||||
|
||||
### User Experience
|
||||
|
||||
- [ ] **UI Requirements** - User interface elements and behaviors specified
|
||||
- [ ] **Audio Integration** - Sound effect and music requirements defined
|
||||
- [ ] **Visual Feedback** - Animation and visual effect requirements specified
|
||||
@@ -868,6 +880,7 @@ export const GameBalance = {
|
||||
- [ ] **Error Recovery** - User-facing error handling and recovery specified
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
- [ ] **Frame Rate Targets** - Specific FPS requirements for different platforms
|
||||
- [ ] **Memory Usage** - Memory consumption limits and monitoring requirements
|
||||
- [ ] **Asset Optimization** - Texture, audio, and data optimization requirements
|
||||
@@ -877,6 +890,7 @@ export const GameBalance = {
|
||||
## Documentation and Communication
|
||||
|
||||
### Story Documentation
|
||||
|
||||
- [ ] **Implementation Notes** - Additional context and implementation guidance provided
|
||||
- [ ] **Design Decisions** - Key design choices documented with rationale
|
||||
- [ ] **Future Considerations** - Potential future enhancements or modifications noted
|
||||
@@ -884,6 +898,7 @@ export const GameBalance = {
|
||||
- [ ] **Reference Materials** - Links to relevant GDD sections and architecture docs
|
||||
|
||||
### Developer Handoff
|
||||
|
||||
- [ ] **Immediate Actionability** - Developer can start implementation without additional questions
|
||||
- [ ] **Complete Context** - All necessary context provided within the story
|
||||
- [ ] **Clear Boundaries** - What is and isn't included in the story scope is clear
|
||||
@@ -893,6 +908,7 @@ export const GameBalance = {
|
||||
## Final Validation
|
||||
|
||||
### Story Readiness
|
||||
|
||||
- [ ] **No Ambiguity** - No sections require interpretation or additional design decisions
|
||||
- [ ] **Technical Completeness** - All technical requirements are specified and actionable
|
||||
- [ ] **Scope Appropriateness** - Story scope matches assigned story points
|
||||
@@ -900,6 +916,7 @@ export const GameBalance = {
|
||||
- [ ] **Review Completion** - Story has been reviewed for completeness and accuracy
|
||||
|
||||
### Implementation Preparedness
|
||||
|
||||
- [ ] **Environment Ready** - Development environment requirements specified
|
||||
- [ ] **Resources Available** - All required resources (assets, docs, dependencies) accessible
|
||||
- [ ] **Testing Prepared** - Testing environment and data requirements specified
|
||||
@@ -928,6 +945,7 @@ This document establishes coding standards, architectural patterns, and developm
|
||||
### Strict Mode Configuration
|
||||
|
||||
**Required tsconfig.json settings:**
|
||||
|
||||
```json
|
||||
{
|
||||
"compilerOptions": {
|
||||
@@ -941,11 +959,12 @@ This document establishes coding standards, architectural patterns, and developm
|
||||
"exactOptionalPropertyTypes": true
|
||||
}
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
### Type Definitions
|
||||
|
||||
**Game Object Interfaces:**
|
||||
|
||||
```typescript
|
||||
// Core game entity interface
|
||||
interface GameEntity {
|
||||
@@ -969,9 +988,10 @@ interface GameSystem {
|
||||
update(delta: number): void;
|
||||
shutdown(): void;
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
**Scene Data Interfaces:**
|
||||
|
||||
```typescript
|
||||
// Scene transition data
|
||||
interface SceneData {
|
||||
@@ -989,28 +1009,32 @@ interface GameState {
|
||||
interface GameSettings {
|
||||
musicVolume: number;
|
||||
sfxVolume: number;
|
||||
difficulty: 'easy' | 'normal' | 'hard';
|
||||
difficulty: "easy" | "normal" | "hard";
|
||||
controls: ControlScheme;
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
**Classes and Interfaces:**
|
||||
|
||||
- PascalCase for classes: `PlayerSprite`, `GameManager`, `AudioSystem`
|
||||
- PascalCase with 'I' prefix for interfaces: `IGameEntity`, `IPlayerController`
|
||||
- Descriptive names that indicate purpose: `CollisionManager` not `CM`
|
||||
|
||||
**Methods and Variables:**
|
||||
|
||||
- camelCase for methods and variables: `updatePosition()`, `playerSpeed`
|
||||
- Descriptive names: `calculateDamage()` not `calcDmg()`
|
||||
- Boolean variables with is/has/can prefix: `isActive`, `hasCollision`, `canMove`
|
||||
|
||||
**Constants:**
|
||||
|
||||
- UPPER_SNAKE_CASE for constants: `MAX_PLAYER_SPEED`, `DEFAULT_VOLUME`
|
||||
- Group related constants in enums or const objects
|
||||
|
||||
**Files and Directories:**
|
||||
|
||||
- kebab-case for file names: `player-controller.ts`, `audio-manager.ts`
|
||||
- PascalCase for scene files: `MenuScene.ts`, `GameScene.ts`
|
||||
|
||||
@@ -1019,88 +1043,91 @@ interface GameSettings {
|
||||
### Scene Organization
|
||||
|
||||
**Scene Lifecycle Management:**
|
||||
|
||||
```typescript
|
||||
class GameScene extends Phaser.Scene {
|
||||
private gameManager!: GameManager;
|
||||
private inputManager!: InputManager;
|
||||
|
||||
|
||||
constructor() {
|
||||
super({ key: 'GameScene' });
|
||||
super({ key: "GameScene" });
|
||||
}
|
||||
|
||||
|
||||
preload(): void {
|
||||
// Load only scene-specific assets
|
||||
this.load.image('player', 'assets/player.png');
|
||||
this.load.image("player", "assets/player.png");
|
||||
}
|
||||
|
||||
|
||||
create(data: SceneData): void {
|
||||
// Initialize game systems
|
||||
this.gameManager = new GameManager(this);
|
||||
this.inputManager = new InputManager(this);
|
||||
|
||||
|
||||
// Set up scene-specific logic
|
||||
this.setupGameObjects();
|
||||
this.setupEventListeners();
|
||||
}
|
||||
|
||||
|
||||
update(time: number, delta: number): void {
|
||||
// Update all game systems
|
||||
this.gameManager.update(delta);
|
||||
this.inputManager.update(delta);
|
||||
}
|
||||
|
||||
|
||||
shutdown(): void {
|
||||
// Clean up resources
|
||||
this.gameManager.destroy();
|
||||
this.inputManager.destroy();
|
||||
|
||||
|
||||
// Remove event listeners
|
||||
this.events.off('*');
|
||||
this.events.off("*");
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Scene Transitions:**
|
||||
|
||||
```typescript
|
||||
// Proper scene transitions with data
|
||||
this.scene.start('NextScene', {
|
||||
this.scene.start("NextScene", {
|
||||
playerScore: this.playerScore,
|
||||
currentLevel: this.currentLevel + 1
|
||||
currentLevel: this.currentLevel + 1,
|
||||
});
|
||||
|
||||
// Scene overlays for UI
|
||||
this.scene.launch('PauseMenuScene');
|
||||
this.scene.launch("PauseMenuScene");
|
||||
this.scene.pause();
|
||||
```text
|
||||
```
|
||||
|
||||
### Game Object Patterns
|
||||
|
||||
**Component-Based Architecture:**
|
||||
|
||||
```typescript
|
||||
// Base game entity
|
||||
abstract class GameEntity extends Phaser.GameObjects.Sprite {
|
||||
protected components: Map<string, GameComponent> = new Map();
|
||||
|
||||
|
||||
constructor(scene: Phaser.Scene, x: number, y: number, texture: string) {
|
||||
super(scene, x, y, texture);
|
||||
scene.add.existing(this);
|
||||
}
|
||||
|
||||
|
||||
addComponent<T extends GameComponent>(component: T): T {
|
||||
this.components.set(component.name, component);
|
||||
return component;
|
||||
}
|
||||
|
||||
|
||||
getComponent<T extends GameComponent>(name: string): T | undefined {
|
||||
return this.components.get(name) as T;
|
||||
}
|
||||
|
||||
|
||||
update(delta: number): void {
|
||||
this.components.forEach(component => component.update(delta));
|
||||
this.components.forEach((component) => component.update(delta));
|
||||
}
|
||||
|
||||
|
||||
destroy(): void {
|
||||
this.components.forEach(component => component.destroy());
|
||||
this.components.forEach((component) => component.destroy());
|
||||
this.components.clear();
|
||||
super.destroy();
|
||||
}
|
||||
@@ -1110,65 +1137,67 @@ abstract class GameEntity extends Phaser.GameObjects.Sprite {
|
||||
class Player extends GameEntity {
|
||||
private movement!: MovementComponent;
|
||||
private health!: HealthComponent;
|
||||
|
||||
|
||||
constructor(scene: Phaser.Scene, x: number, y: number) {
|
||||
super(scene, x, y, 'player');
|
||||
|
||||
super(scene, x, y, "player");
|
||||
|
||||
this.movement = this.addComponent(new MovementComponent(this));
|
||||
this.health = this.addComponent(new HealthComponent(this, 100));
|
||||
}
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
### System Management
|
||||
|
||||
**Singleton Managers:**
|
||||
|
||||
```typescript
|
||||
class GameManager {
|
||||
private static instance: GameManager;
|
||||
private scene: Phaser.Scene;
|
||||
private gameState: GameState;
|
||||
|
||||
|
||||
constructor(scene: Phaser.Scene) {
|
||||
if (GameManager.instance) {
|
||||
throw new Error('GameManager already exists!');
|
||||
throw new Error("GameManager already exists!");
|
||||
}
|
||||
|
||||
|
||||
this.scene = scene;
|
||||
this.gameState = this.loadGameState();
|
||||
GameManager.instance = this;
|
||||
}
|
||||
|
||||
|
||||
static getInstance(): GameManager {
|
||||
if (!GameManager.instance) {
|
||||
throw new Error('GameManager not initialized!');
|
||||
throw new Error("GameManager not initialized!");
|
||||
}
|
||||
return GameManager.instance;
|
||||
}
|
||||
|
||||
|
||||
update(delta: number): void {
|
||||
// Update game logic
|
||||
}
|
||||
|
||||
|
||||
destroy(): void {
|
||||
GameManager.instance = null!;
|
||||
}
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Object Pooling
|
||||
|
||||
**Required for High-Frequency Objects:**
|
||||
|
||||
```typescript
|
||||
class BulletPool {
|
||||
private pool: Bullet[] = [];
|
||||
private scene: Phaser.Scene;
|
||||
|
||||
|
||||
constructor(scene: Phaser.Scene, initialSize: number = 50) {
|
||||
this.scene = scene;
|
||||
|
||||
|
||||
// Pre-create bullets
|
||||
for (let i = 0; i < initialSize; i++) {
|
||||
const bullet = new Bullet(scene, 0, 0);
|
||||
@@ -1177,20 +1206,20 @@ class BulletPool {
|
||||
this.pool.push(bullet);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
getBullet(): Bullet | null {
|
||||
const bullet = this.pool.find(b => !b.active);
|
||||
const bullet = this.pool.find((b) => !b.active);
|
||||
if (bullet) {
|
||||
bullet.setActive(true);
|
||||
bullet.setVisible(true);
|
||||
return bullet;
|
||||
}
|
||||
|
||||
|
||||
// Pool exhausted - create new bullet
|
||||
console.warn('Bullet pool exhausted, creating new bullet');
|
||||
console.warn("Bullet pool exhausted, creating new bullet");
|
||||
return new Bullet(this.scene, 0, 0);
|
||||
}
|
||||
|
||||
|
||||
releaseBullet(bullet: Bullet): void {
|
||||
bullet.setActive(false);
|
||||
bullet.setVisible(false);
|
||||
@@ -1202,45 +1231,47 @@ class BulletPool {
|
||||
### Frame Rate Optimization
|
||||
|
||||
**Performance Monitoring:**
|
||||
|
||||
```typescript
|
||||
class PerformanceMonitor {
|
||||
private frameCount: number = 0;
|
||||
private lastTime: number = 0;
|
||||
private frameRate: number = 60;
|
||||
|
||||
|
||||
update(time: number): void {
|
||||
this.frameCount++;
|
||||
|
||||
|
||||
if (time - this.lastTime >= 1000) {
|
||||
this.frameRate = this.frameCount;
|
||||
this.frameCount = 0;
|
||||
this.lastTime = time;
|
||||
|
||||
|
||||
if (this.frameRate < 55) {
|
||||
console.warn(`Low frame rate detected: ${this.frameRate} FPS`);
|
||||
this.optimizePerformance();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
private optimizePerformance(): void {
|
||||
// Reduce particle counts, disable effects, etc.
|
||||
}
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
**Update Loop Optimization:**
|
||||
|
||||
```typescript
|
||||
// Avoid expensive operations in update loops
|
||||
class GameScene extends Phaser.Scene {
|
||||
private updateTimer: number = 0;
|
||||
private readonly UPDATE_INTERVAL = 100; // ms
|
||||
|
||||
|
||||
update(time: number, delta: number): void {
|
||||
// High-frequency updates (every frame)
|
||||
this.updatePlayer(delta);
|
||||
this.updatePhysics(delta);
|
||||
|
||||
|
||||
// Low-frequency updates (10 times per second)
|
||||
this.updateTimer += delta;
|
||||
if (this.updateTimer >= this.UPDATE_INTERVAL) {
|
||||
@@ -1250,13 +1281,14 @@ class GameScene extends Phaser.Scene {
|
||||
}
|
||||
}
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
## Input Handling
|
||||
|
||||
### Cross-Platform Input
|
||||
|
||||
**Input Abstraction:**
|
||||
|
||||
```typescript
|
||||
interface InputState {
|
||||
moveLeft: boolean;
|
||||
@@ -1272,26 +1304,26 @@ class InputManager {
|
||||
moveRight: false,
|
||||
jump: false,
|
||||
action: false,
|
||||
pause: false
|
||||
pause: false,
|
||||
};
|
||||
|
||||
|
||||
private keys!: { [key: string]: Phaser.Input.Keyboard.Key };
|
||||
private pointer!: Phaser.Input.Pointer;
|
||||
|
||||
|
||||
constructor(private scene: Phaser.Scene) {
|
||||
this.setupKeyboard();
|
||||
this.setupTouch();
|
||||
}
|
||||
|
||||
|
||||
private setupKeyboard(): void {
|
||||
this.keys = this.scene.input.keyboard.addKeys('W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT');
|
||||
this.keys = this.scene.input.keyboard.addKeys("W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT");
|
||||
}
|
||||
|
||||
|
||||
private setupTouch(): void {
|
||||
this.scene.input.on('pointerdown', this.handlePointerDown, this);
|
||||
this.scene.input.on('pointerup', this.handlePointerUp, this);
|
||||
this.scene.input.on("pointerdown", this.handlePointerDown, this);
|
||||
this.scene.input.on("pointerup", this.handlePointerUp, this);
|
||||
}
|
||||
|
||||
|
||||
update(): void {
|
||||
// Update input state from multiple sources
|
||||
this.inputState.moveLeft = this.keys.A.isDown || this.keys.LEFT.isDown;
|
||||
@@ -1299,42 +1331,43 @@ class InputManager {
|
||||
this.inputState.jump = Phaser.Input.Keyboard.JustDown(this.keys.SPACE);
|
||||
// ... handle touch input
|
||||
}
|
||||
|
||||
|
||||
getInputState(): InputState {
|
||||
return { ...this.inputState };
|
||||
}
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Graceful Degradation
|
||||
|
||||
**Asset Loading Error Handling:**
|
||||
|
||||
```typescript
|
||||
class AssetManager {
|
||||
loadAssets(): Promise<void> {
|
||||
return new Promise((resolve, reject) => {
|
||||
this.scene.load.on('filecomplete', this.handleFileComplete, this);
|
||||
this.scene.load.on('loaderror', this.handleLoadError, this);
|
||||
this.scene.load.on('complete', () => resolve());
|
||||
|
||||
this.scene.load.on("filecomplete", this.handleFileComplete, this);
|
||||
this.scene.load.on("loaderror", this.handleLoadError, this);
|
||||
this.scene.load.on("complete", () => resolve());
|
||||
|
||||
this.scene.load.start();
|
||||
});
|
||||
}
|
||||
|
||||
|
||||
private handleLoadError(file: Phaser.Loader.File): void {
|
||||
console.error(`Failed to load asset: ${file.key}`);
|
||||
|
||||
|
||||
// Use fallback assets
|
||||
this.loadFallbackAsset(file.key);
|
||||
}
|
||||
|
||||
|
||||
private loadFallbackAsset(key: string): void {
|
||||
// Load placeholder or default assets
|
||||
switch (key) {
|
||||
case 'player':
|
||||
this.scene.load.image('player', 'assets/defaults/default-player.png');
|
||||
case "player":
|
||||
this.scene.load.image("player", "assets/defaults/default-player.png");
|
||||
break;
|
||||
default:
|
||||
console.warn(`No fallback for asset: ${key}`);
|
||||
@@ -1346,25 +1379,26 @@ class AssetManager {
|
||||
### Runtime Error Recovery
|
||||
|
||||
**System Error Handling:**
|
||||
|
||||
```typescript
|
||||
class GameSystem {
|
||||
protected handleError(error: Error, context: string): void {
|
||||
console.error(`Error in ${context}:`, error);
|
||||
|
||||
|
||||
// Report to analytics/logging service
|
||||
this.reportError(error, context);
|
||||
|
||||
|
||||
// Attempt recovery
|
||||
this.attemptRecovery(context);
|
||||
}
|
||||
|
||||
|
||||
private attemptRecovery(context: string): void {
|
||||
switch (context) {
|
||||
case 'update':
|
||||
case "update":
|
||||
// Reset system state
|
||||
this.reset();
|
||||
break;
|
||||
case 'render':
|
||||
case "render":
|
||||
// Disable visual effects
|
||||
this.disableEffects();
|
||||
break;
|
||||
@@ -1374,64 +1408,66 @@ class GameSystem {
|
||||
}
|
||||
}
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
## Testing Standards
|
||||
|
||||
### Unit Testing
|
||||
|
||||
**Game Logic Testing:**
|
||||
|
||||
```typescript
|
||||
// Example test for game mechanics
|
||||
describe('HealthComponent', () => {
|
||||
describe("HealthComponent", () => {
|
||||
let healthComponent: HealthComponent;
|
||||
|
||||
|
||||
beforeEach(() => {
|
||||
const mockEntity = {} as GameEntity;
|
||||
healthComponent = new HealthComponent(mockEntity, 100);
|
||||
});
|
||||
|
||||
test('should initialize with correct health', () => {
|
||||
|
||||
test("should initialize with correct health", () => {
|
||||
expect(healthComponent.currentHealth).toBe(100);
|
||||
expect(healthComponent.maxHealth).toBe(100);
|
||||
});
|
||||
|
||||
test('should handle damage correctly', () => {
|
||||
|
||||
test("should handle damage correctly", () => {
|
||||
healthComponent.takeDamage(25);
|
||||
expect(healthComponent.currentHealth).toBe(75);
|
||||
expect(healthComponent.isAlive()).toBe(true);
|
||||
});
|
||||
|
||||
test('should handle death correctly', () => {
|
||||
|
||||
test("should handle death correctly", () => {
|
||||
healthComponent.takeDamage(150);
|
||||
expect(healthComponent.currentHealth).toBe(0);
|
||||
expect(healthComponent.isAlive()).toBe(false);
|
||||
});
|
||||
});
|
||||
```text
|
||||
```
|
||||
|
||||
### Integration Testing
|
||||
|
||||
**Scene Testing:**
|
||||
|
||||
```typescript
|
||||
describe('GameScene Integration', () => {
|
||||
describe("GameScene Integration", () => {
|
||||
let scene: GameScene;
|
||||
let mockGame: Phaser.Game;
|
||||
|
||||
|
||||
beforeEach(() => {
|
||||
// Mock Phaser game instance
|
||||
mockGame = createMockGame();
|
||||
scene = new GameScene();
|
||||
});
|
||||
|
||||
test('should initialize all systems', () => {
|
||||
|
||||
test("should initialize all systems", () => {
|
||||
scene.create({});
|
||||
|
||||
|
||||
expect(scene.gameManager).toBeDefined();
|
||||
expect(scene.inputManager).toBeDefined();
|
||||
});
|
||||
});
|
||||
```text
|
||||
```
|
||||
|
||||
## File Organization
|
||||
|
||||
@@ -1485,21 +1521,25 @@ src/
|
||||
### Story Implementation Process
|
||||
|
||||
1. **Read Story Requirements:**
|
||||
|
||||
- Understand acceptance criteria
|
||||
- Identify technical requirements
|
||||
- Review performance constraints
|
||||
|
||||
2. **Plan Implementation:**
|
||||
|
||||
- Identify files to create/modify
|
||||
- Consider component architecture
|
||||
- Plan testing approach
|
||||
|
||||
3. **Implement Feature:**
|
||||
|
||||
- Follow TypeScript strict mode
|
||||
- Use established patterns
|
||||
- Maintain 60 FPS performance
|
||||
|
||||
4. **Test Implementation:**
|
||||
|
||||
- Write unit tests for game logic
|
||||
- Test cross-platform functionality
|
||||
- Validate performance targets
|
||||
@@ -1512,6 +1552,7 @@ src/
|
||||
### Code Review Checklist
|
||||
|
||||
**Before Committing:**
|
||||
|
||||
- [ ] TypeScript compiles without errors
|
||||
- [ ] All tests pass
|
||||
- [ ] Performance targets met (60 FPS)
|
||||
@@ -1525,17 +1566,20 @@ src/
|
||||
## Performance Targets
|
||||
|
||||
### Frame Rate Requirements
|
||||
|
||||
- **Desktop**: Maintain 60 FPS at 1080p
|
||||
- **Mobile**: Maintain 60 FPS on mid-range devices, minimum 30 FPS on low-end
|
||||
- **Optimization**: Implement dynamic quality scaling when performance drops
|
||||
|
||||
### Memory Management
|
||||
|
||||
- **Total Memory**: Under 100MB for full game
|
||||
- **Per Scene**: Under 50MB per gameplay scene
|
||||
- **Asset Loading**: Progressive loading to stay under limits
|
||||
- **Garbage Collection**: Minimize object creation in update loops
|
||||
|
||||
### Loading Performance
|
||||
|
||||
- **Initial Load**: Under 5 seconds for game start
|
||||
- **Scene Transitions**: Under 2 seconds between scenes
|
||||
- **Asset Streaming**: Background loading for upcoming content
|
||||
|
||||
@@ -109,6 +109,7 @@ Create detailed, actionable game development stories that enable AI developers t
|
||||
## Prerequisites
|
||||
|
||||
Before creating stories, ensure you have:
|
||||
|
||||
- Completed Game Design Document (GDD)
|
||||
- Game Architecture Document
|
||||
- Epic definition this story belongs to
|
||||
@@ -119,12 +120,14 @@ Before creating stories, ensure you have:
|
||||
### 1. Story Identification
|
||||
|
||||
**Review Epic Context:**
|
||||
|
||||
- Understand the epic's overall goal
|
||||
- Identify specific features that need implementation
|
||||
- Review any existing stories in the epic
|
||||
- Ensure no duplicate work
|
||||
|
||||
**Feature Analysis:**
|
||||
|
||||
- Reference specific GDD sections
|
||||
- Understand player experience goals
|
||||
- Identify technical complexity
|
||||
@@ -133,12 +136,14 @@ Before creating stories, ensure you have:
|
||||
### 2. Story Scoping
|
||||
|
||||
**Single Responsibility:**
|
||||
|
||||
- Focus on one specific game feature
|
||||
- Ensure story is completable in 1-3 days
|
||||
- Break down complex features into multiple stories
|
||||
- Maintain clear boundaries with other stories
|
||||
|
||||
**Implementation Clarity:**
|
||||
|
||||
- Define exactly what needs to be built
|
||||
- Specify all technical requirements
|
||||
- Include all necessary integration points
|
||||
@@ -150,6 +155,7 @@ Before creating stories, ensure you have:
|
||||
Use `templates#game-story-tmpl` following all embedded LLM instructions
|
||||
|
||||
**Key Focus Areas:**
|
||||
|
||||
- Clear, actionable description
|
||||
- Specific acceptance criteria
|
||||
- Detailed technical specifications
|
||||
@@ -159,18 +165,21 @@ Use `templates#game-story-tmpl` following all embedded LLM instructions
|
||||
### 4. Story Validation
|
||||
|
||||
**Technical Review:**
|
||||
|
||||
- Verify all technical specifications are complete
|
||||
- Ensure integration points are clearly defined
|
||||
- Confirm file paths match architecture
|
||||
- Validate TypeScript interfaces and classes
|
||||
|
||||
**Game Design Alignment:**
|
||||
|
||||
- Confirm story implements GDD requirements
|
||||
- Verify player experience goals are met
|
||||
- Check balance parameters are included
|
||||
- Ensure game mechanics are correctly interpreted
|
||||
|
||||
**Implementation Readiness:**
|
||||
|
||||
- All dependencies identified
|
||||
- Assets requirements specified
|
||||
- Testing criteria defined
|
||||
@@ -182,6 +191,7 @@ Use `templates#game-story-tmpl` following all embedded LLM instructions
|
||||
Execute `checklists#game-story-dod-checklist` against completed story
|
||||
|
||||
**Story Criteria:**
|
||||
|
||||
- Story is immediately actionable
|
||||
- No design decisions left to developer
|
||||
- Technical requirements are complete
|
||||
@@ -191,12 +201,14 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
### 6. Story Refinement
|
||||
|
||||
**Developer Perspective:**
|
||||
|
||||
- Can a developer start implementation immediately?
|
||||
- Are all technical questions answered?
|
||||
- Is the scope appropriate for the estimated points?
|
||||
- Are all dependencies clearly identified?
|
||||
|
||||
**Iterative Improvement:**
|
||||
|
||||
- Address any gaps or ambiguities
|
||||
- Clarify complex technical requirements
|
||||
- Ensure story fits within epic scope
|
||||
@@ -205,6 +217,7 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
## Story Elements Checklist
|
||||
|
||||
### Required Sections
|
||||
|
||||
- [ ] Clear, specific description
|
||||
- [ ] Complete acceptance criteria (functional, technical, game design)
|
||||
- [ ] Detailed technical specifications
|
||||
@@ -218,6 +231,7 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
- [ ] Definition of Done checklist
|
||||
|
||||
### Game-Specific Requirements
|
||||
|
||||
- [ ] GDD section references
|
||||
- [ ] Game mechanic implementation details
|
||||
- [ ] Player experience goals
|
||||
@@ -227,6 +241,7 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
- [ ] Cross-platform considerations
|
||||
|
||||
### Technical Quality
|
||||
|
||||
- [ ] TypeScript strict mode compliance
|
||||
- [ ] Architecture document alignment
|
||||
- [ ] Code organization follows standards
|
||||
@@ -237,18 +252,21 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
## Common Pitfalls
|
||||
|
||||
**Scope Issues:**
|
||||
|
||||
- Story too large (break into multiple stories)
|
||||
- Story too vague (add specific requirements)
|
||||
- Missing dependencies (identify all prerequisites)
|
||||
- Unclear boundaries (define what's in/out of scope)
|
||||
|
||||
**Technical Issues:**
|
||||
|
||||
- Missing integration details
|
||||
- Incomplete technical specifications
|
||||
- Undefined interfaces or classes
|
||||
- Missing performance requirements
|
||||
|
||||
**Game Design Issues:**
|
||||
|
||||
- Not referencing GDD properly
|
||||
- Missing player experience context
|
||||
- Unclear game mechanic implementation
|
||||
@@ -257,6 +275,7 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
## Success Criteria
|
||||
|
||||
**Story Readiness:**
|
||||
|
||||
- [ ] Developer can start implementation immediately
|
||||
- [ ] No additional design decisions required
|
||||
- [ ] All technical questions answered
|
||||
@@ -265,6 +284,7 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
- [ ] Story fits within epic scope
|
||||
|
||||
**Quality Validation:**
|
||||
|
||||
- [ ] Game story DOD checklist passes
|
||||
- [ ] Architecture alignment confirmed
|
||||
- [ ] GDD requirements covered
|
||||
@@ -274,6 +294,7 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
## Handoff Protocol
|
||||
|
||||
**To Game Developer:**
|
||||
|
||||
1. Provide story document
|
||||
2. Confirm GDD and architecture access
|
||||
3. Verify all dependencies are met
|
||||
@@ -281,6 +302,7 @@ Execute `checklists#game-story-dod-checklist` against completed story
|
||||
5. Establish check-in schedule
|
||||
|
||||
**Story Status Updates:**
|
||||
|
||||
- Draft → Ready for Development
|
||||
- In Development → Code Review
|
||||
- Code Review → Testing
|
||||
@@ -633,6 +655,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
## Story Completeness
|
||||
|
||||
### Basic Story Elements
|
||||
|
||||
- [ ] **Story Title** - Clear, descriptive title that identifies the feature
|
||||
- [ ] **Epic Assignment** - Story is properly assigned to relevant epic
|
||||
- [ ] **Priority Level** - Appropriate priority assigned (High/Medium/Low)
|
||||
@@ -640,6 +663,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Description** - Clear, concise description of what needs to be implemented
|
||||
|
||||
### Game Design Alignment
|
||||
|
||||
- [ ] **GDD Reference** - Specific Game Design Document section referenced
|
||||
- [ ] **Game Mechanic Context** - Clear connection to game mechanics defined in GDD
|
||||
- [ ] **Player Experience Goal** - Describes the intended player experience
|
||||
@@ -649,6 +673,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
## Technical Specifications
|
||||
|
||||
### Architecture Compliance
|
||||
|
||||
- [ ] **File Organization** - Follows game architecture document structure
|
||||
- [ ] **Class Definitions** - TypeScript interfaces and classes are properly defined
|
||||
- [ ] **Integration Points** - Clear specification of how feature integrates with existing systems
|
||||
@@ -656,6 +681,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Dependencies** - All system dependencies clearly identified
|
||||
|
||||
### Phaser 3 Requirements
|
||||
|
||||
- [ ] **Scene Integration** - Specifies which scenes are affected and how
|
||||
- [ ] **Game Object Usage** - Proper use of Phaser 3 game objects and components
|
||||
- [ ] **Physics Integration** - Physics requirements specified if applicable
|
||||
@@ -663,6 +689,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Performance Considerations** - 60 FPS target and optimization requirements
|
||||
|
||||
### Code Quality Standards
|
||||
|
||||
- [ ] **TypeScript Strict Mode** - All code must comply with strict TypeScript
|
||||
- [ ] **Error Handling** - Error scenarios and handling requirements specified
|
||||
- [ ] **Memory Management** - Object pooling and cleanup requirements where needed
|
||||
@@ -672,6 +699,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
## Implementation Readiness
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
- [ ] **Functional Requirements** - All functional acceptance criteria are specific and testable
|
||||
- [ ] **Technical Requirements** - Technical acceptance criteria are complete and verifiable
|
||||
- [ ] **Game Design Requirements** - Game-specific requirements match GDD specifications
|
||||
@@ -679,6 +707,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Completeness** - No acceptance criteria are vague or unmeasurable
|
||||
|
||||
### Implementation Tasks
|
||||
|
||||
- [ ] **Task Breakdown** - Story broken into specific, ordered implementation tasks
|
||||
- [ ] **Task Scope** - Each task is completable in 1-4 hours
|
||||
- [ ] **Task Clarity** - Each task has clear, actionable instructions
|
||||
@@ -686,6 +715,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Development Flow** - Tasks follow logical implementation order
|
||||
|
||||
### Dependencies
|
||||
|
||||
- [ ] **Story Dependencies** - All prerequisite stories identified with IDs
|
||||
- [ ] **Technical Dependencies** - Required systems and files identified
|
||||
- [ ] **Asset Dependencies** - All needed assets specified with locations
|
||||
@@ -695,6 +725,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
## Testing Requirements
|
||||
|
||||
### Test Coverage
|
||||
|
||||
- [ ] **Unit Test Requirements** - Specific unit test files and scenarios defined
|
||||
- [ ] **Integration Test Cases** - Integration testing with other game systems specified
|
||||
- [ ] **Manual Test Cases** - Game-specific manual testing procedures defined
|
||||
@@ -702,6 +733,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Edge Case Testing** - Edge cases and error conditions covered
|
||||
|
||||
### Test Implementation
|
||||
|
||||
- [ ] **Test File Paths** - Exact test file locations specified
|
||||
- [ ] **Test Scenarios** - All test scenarios are complete and executable
|
||||
- [ ] **Expected Behaviors** - Clear expected outcomes for all tests defined
|
||||
@@ -711,6 +743,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
## Game-Specific Quality
|
||||
|
||||
### Gameplay Implementation
|
||||
|
||||
- [ ] **Mechanic Accuracy** - Implementation matches GDD mechanic specifications
|
||||
- [ ] **Player Controls** - Input handling requirements are complete
|
||||
- [ ] **Game Feel** - Requirements for juice, feedback, and responsiveness specified
|
||||
@@ -718,6 +751,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **State Management** - Game state changes and persistence requirements defined
|
||||
|
||||
### User Experience
|
||||
|
||||
- [ ] **UI Requirements** - User interface elements and behaviors specified
|
||||
- [ ] **Audio Integration** - Sound effect and music requirements defined
|
||||
- [ ] **Visual Feedback** - Animation and visual effect requirements specified
|
||||
@@ -725,6 +759,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Error Recovery** - User-facing error handling and recovery specified
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
- [ ] **Frame Rate Targets** - Specific FPS requirements for different platforms
|
||||
- [ ] **Memory Usage** - Memory consumption limits and monitoring requirements
|
||||
- [ ] **Asset Optimization** - Texture, audio, and data optimization requirements
|
||||
@@ -734,6 +769,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
## Documentation and Communication
|
||||
|
||||
### Story Documentation
|
||||
|
||||
- [ ] **Implementation Notes** - Additional context and implementation guidance provided
|
||||
- [ ] **Design Decisions** - Key design choices documented with rationale
|
||||
- [ ] **Future Considerations** - Potential future enhancements or modifications noted
|
||||
@@ -741,6 +777,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Reference Materials** - Links to relevant GDD sections and architecture docs
|
||||
|
||||
### Developer Handoff
|
||||
|
||||
- [ ] **Immediate Actionability** - Developer can start implementation without additional questions
|
||||
- [ ] **Complete Context** - All necessary context provided within the story
|
||||
- [ ] **Clear Boundaries** - What is and isn't included in the story scope is clear
|
||||
@@ -750,6 +787,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
## Final Validation
|
||||
|
||||
### Story Readiness
|
||||
|
||||
- [ ] **No Ambiguity** - No sections require interpretation or additional design decisions
|
||||
- [ ] **Technical Completeness** - All technical requirements are specified and actionable
|
||||
- [ ] **Scope Appropriateness** - Story scope matches assigned story points
|
||||
@@ -757,6 +795,7 @@ class {{ClassName}} extends {{PhaseClass}} {
|
||||
- [ ] **Review Completion** - Story has been reviewed for completeness and accuracy
|
||||
|
||||
### Implementation Preparedness
|
||||
|
||||
- [ ] **Environment Ready** - Development environment requirements specified
|
||||
- [ ] **Resources Available** - All required resources (assets, docs, dependencies) accessible
|
||||
- [ ] **Testing Prepared** - Testing environment and data requirements specified
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1006,7 +1006,7 @@ module "vpc" {
|
||||
public_subnets = {{public_subnets}}
|
||||
private_subnets = {{private_subnets}}
|
||||
}
|
||||
```text
|
||||
```
|
||||
|
||||
### Security Foundation
|
||||
|
||||
@@ -1053,7 +1053,7 @@ eksctl create cluster \
|
||||
--nodegroup-name {{nodegroup_name}} \
|
||||
--node-type {{instance_type}} \
|
||||
--nodes {{node_count}}
|
||||
```text
|
||||
```
|
||||
|
||||
^^/CONDITION: uses_eks^^
|
||||
|
||||
@@ -1067,7 +1067,7 @@ az aks create \
|
||||
--node-count {{node_count}} \
|
||||
--node-vm-size {{vm_size}} \
|
||||
--network-plugin azure
|
||||
```text
|
||||
```
|
||||
|
||||
^^/CONDITION: uses_aks^^
|
||||
|
||||
@@ -1111,11 +1111,11 @@ metadata:
|
||||
spec:
|
||||
source:
|
||||
repoURL:
|
||||
'[object Object]': null
|
||||
"[object Object]": null
|
||||
targetRevision:
|
||||
'[object Object]': null
|
||||
"[object Object]": null
|
||||
path:
|
||||
'[object Object]': null
|
||||
"[object Object]": null
|
||||
```
|
||||
|
||||
^^/CONDITION: uses_argocd^^
|
||||
@@ -1132,10 +1132,10 @@ spec:
|
||||
interval: 1m
|
||||
ref:
|
||||
branch:
|
||||
'[object Object]': null
|
||||
"[object Object]": null
|
||||
url:
|
||||
'[object Object]': null
|
||||
```text
|
||||
"[object Object]": null
|
||||
```
|
||||
|
||||
^^/CONDITION: uses_flux^^
|
||||
|
||||
@@ -1153,7 +1153,7 @@ platform-gitops/
|
||||
| ||||