specify md ot yaml
This commit is contained in:
Brian Madison
@@ -1,560 +0,0 @@
|
||||
# {{Game Title}} Game Architecture Document
|
||||
|
||||
[[LLM: This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics.
|
||||
|
||||
If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD.]]
|
||||
|
||||
## Introduction
|
||||
|
||||
[[LLM: Establish the document's purpose and scope for game development]]
|
||||
|
||||
This document outlines the complete technical architecture for {{Game Title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems.
|
||||
|
||||
This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility.
|
||||
|
||||
### Change Log
|
||||
|
||||
[[LLM: Track document versions and changes]]
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
## Technical Overview
|
||||
|
||||
[[LLM: Present all subsections together, then apply `tasks#advanced-elicitation` protocol to the complete section.]]
|
||||
|
||||
### Architecture Summary
|
||||
|
||||
[[LLM: Provide a comprehensive overview covering:
|
||||
|
||||
- Game engine choice and configuration
|
||||
- Project structure and organization
|
||||
- Key systems and their interactions
|
||||
- Performance and optimization strategy
|
||||
- How this architecture achieves GDD requirements]]
|
||||
|
||||
### Platform Targets
|
||||
|
||||
[[LLM: Based on GDD requirements, confirm platform support]]
|
||||
|
||||
**Primary Platform:** {{primary_platform}}
|
||||
**Secondary Platforms:** {{secondary_platforms}}
|
||||
**Minimum Requirements:** {{min_specs}}
|
||||
**Target Performance:** 60 FPS on {{target_device}}
|
||||
|
||||
### Technology Stack
|
||||
|
||||
**Core Engine:** Phaser 3.70+
|
||||
**Language:** TypeScript 5.0+ (Strict Mode)
|
||||
**Build Tool:** {{build_tool}} (Webpack/Vite/Parcel)
|
||||
**Package Manager:** {{package_manager}}
|
||||
**Testing:** {{test_framework}}
|
||||
**Deployment:** {{deployment_platform}}
|
||||
|
||||
## Project Structure
|
||||
|
||||
[[LLM: Define the complete project organization that developers will follow]]
|
||||
|
||||
### Repository Organization
|
||||
|
||||
[[LLM: Design a clear folder structure for game development]]
|
||||
|
||||
```text
|
||||
{{game_name}}/
|
||||
├── src/
|
||||
│ ├── scenes/ # Game scenes
|
||||
│ ├── gameObjects/ # Custom game objects
|
||||
│ ├── systems/ # Core game systems
|
||||
│ ├── utils/ # Utility functions
|
||||
│ ├── types/ # TypeScript type definitions
|
||||
│ ├── config/ # Game configuration
|
||||
│ └── main.ts # Entry point
|
||||
├── assets/
|
||||
│ ├── images/ # Sprite assets
|
||||
│ ├── audio/ # Sound files
|
||||
│ ├── data/ # JSON data files
|
||||
│ └── fonts/ # Font files
|
||||
├── public/ # Static web assets
|
||||
├── tests/ # Test files
|
||||
├── docs/ # Documentation
|
||||
│ ├── stories/ # Development stories
|
||||
│ └── architecture/ # Technical docs
|
||||
└── dist/ # Built game files
|
||||
```
|
||||
|
||||
### Module Organization
|
||||
|
||||
[[LLM: Define how TypeScript modules should be organized]]
|
||||
|
||||
**Scene Structure:**
|
||||
|
||||
- Each scene in separate file
|
||||
- Scene-specific logic contained
|
||||
- Clear data passing between scenes
|
||||
|
||||
**Game Object Pattern:**
|
||||
|
||||
- Component-based architecture
|
||||
- Reusable game object classes
|
||||
- Type-safe property definitions
|
||||
|
||||
**System Architecture:**
|
||||
|
||||
- Singleton managers for global systems
|
||||
- Event-driven communication
|
||||
- Clear separation of concerns
|
||||
|
||||
## Core Game Systems
|
||||
|
||||
[[LLM: Detail each major system that needs to be implemented. Each system should be specific enough for developers to create implementation stories.]]
|
||||
|
||||
### Scene Management System
|
||||
|
||||
**Purpose:** Handle game flow and scene transitions
|
||||
|
||||
**Key Components:**
|
||||
|
||||
- Scene loading and unloading
|
||||
- Data passing between scenes
|
||||
- Transition effects
|
||||
- Memory management
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Preload scene for asset loading
|
||||
- Menu system with navigation
|
||||
- Gameplay scenes with state management
|
||||
- Pause/resume functionality
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/scenes/BootScene.ts`
|
||||
- `src/scenes/PreloadScene.ts`
|
||||
- `src/scenes/MenuScene.ts`
|
||||
- `src/scenes/GameScene.ts`
|
||||
- `src/systems/SceneManager.ts`
|
||||
|
||||
### Game State Management
|
||||
|
||||
**Purpose:** Track player progress and game status
|
||||
|
||||
**State Categories:**
|
||||
|
||||
- Player progress (levels, unlocks)
|
||||
- Game settings (audio, controls)
|
||||
- Session data (current level, score)
|
||||
- Persistent data (achievements, statistics)
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Save/load system with localStorage
|
||||
- State validation and error recovery
|
||||
- Cross-session data persistence
|
||||
- Settings management
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/GameState.ts`
|
||||
- `src/systems/SaveManager.ts`
|
||||
- `src/types/GameData.ts`
|
||||
|
||||
### Asset Management System
|
||||
|
||||
**Purpose:** Efficient loading and management of game assets
|
||||
|
||||
**Asset Categories:**
|
||||
|
||||
- Sprite sheets and animations
|
||||
- Audio files and music
|
||||
- Level data and configurations
|
||||
- UI assets and fonts
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Progressive loading strategy
|
||||
- Asset caching and optimization
|
||||
- Error handling for failed loads
|
||||
- Memory management for large assets
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/AssetManager.ts`
|
||||
- `src/config/AssetConfig.ts`
|
||||
- `src/utils/AssetLoader.ts`
|
||||
|
||||
### Input Management System
|
||||
|
||||
**Purpose:** Handle all player input across platforms
|
||||
|
||||
**Input Types:**
|
||||
|
||||
- Keyboard controls
|
||||
- Mouse/pointer interaction
|
||||
- Touch gestures (mobile)
|
||||
- Gamepad support (optional)
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Input mapping and configuration
|
||||
- Touch-friendly mobile controls
|
||||
- Input buffering for responsive gameplay
|
||||
- Customizable control schemes
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/InputManager.ts`
|
||||
- `src/utils/TouchControls.ts`
|
||||
- `src/types/InputTypes.ts`
|
||||
|
||||
### Game Mechanics Systems
|
||||
|
||||
[[LLM: For each major mechanic defined in the GDD, create a system specification]]
|
||||
|
||||
<<REPEAT section="mechanic_system" count="based_on_gdd">>
|
||||
|
||||
#### {{mechanic_name}} System
|
||||
|
||||
**Purpose:** {{system_purpose}}
|
||||
|
||||
**Core Functionality:**
|
||||
|
||||
- {{feature_1}}
|
||||
- {{feature_2}}
|
||||
- {{feature_3}}
|
||||
|
||||
**Dependencies:** {{required_systems}}
|
||||
|
||||
**Performance Considerations:** {{optimization_notes}}
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/{{SystemName}}.ts`
|
||||
- `src/gameObjects/{{RelatedObject}}.ts`
|
||||
- `src/types/{{SystemTypes}}.ts`
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
### Physics & Collision System
|
||||
|
||||
**Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js)
|
||||
|
||||
**Collision Categories:**
|
||||
|
||||
- Player collision
|
||||
- Enemy interactions
|
||||
- Environmental objects
|
||||
- Collectibles and items
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Optimized collision detection
|
||||
- Physics body management
|
||||
- Collision callbacks and events
|
||||
- Performance monitoring
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/PhysicsManager.ts`
|
||||
- `src/utils/CollisionGroups.ts`
|
||||
|
||||
### Audio System
|
||||
|
||||
**Audio Requirements:**
|
||||
|
||||
- Background music with looping
|
||||
- Sound effects for actions
|
||||
- Audio settings and volume control
|
||||
- Mobile audio optimization
|
||||
|
||||
**Implementation Features:**
|
||||
|
||||
- Audio sprite management
|
||||
- Dynamic music system
|
||||
- Spatial audio (if applicable)
|
||||
- Audio pooling for performance
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/AudioManager.ts`
|
||||
- `src/config/AudioConfig.ts`
|
||||
|
||||
### UI System
|
||||
|
||||
**UI Components:**
|
||||
|
||||
- HUD elements (score, health, etc.)
|
||||
- Menu navigation
|
||||
- Modal dialogs
|
||||
- Settings screens
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Responsive layout system
|
||||
- Touch-friendly interface
|
||||
- Keyboard navigation support
|
||||
- Animation and transitions
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/UIManager.ts`
|
||||
- `src/gameObjects/UI/`
|
||||
- `src/types/UITypes.ts`
|
||||
|
||||
## Performance Architecture
|
||||
|
||||
[[LLM: Define performance requirements and optimization strategies]]
|
||||
|
||||
### Performance Targets
|
||||
|
||||
**Frame Rate:** 60 FPS sustained, 30 FPS minimum
|
||||
**Memory Usage:** <{{memory_limit}}MB total
|
||||
**Load Times:** <{{initial_load}}s initial, <{{level_load}}s per level
|
||||
**Battery Optimization:** Reduced updates when not visible
|
||||
|
||||
### Optimization Strategies
|
||||
|
||||
**Object Pooling:**
|
||||
|
||||
- Bullets and projectiles
|
||||
- Particle effects
|
||||
- Enemy objects
|
||||
- UI elements
|
||||
|
||||
**Asset Optimization:**
|
||||
|
||||
- Texture atlases for sprites
|
||||
- Audio compression
|
||||
- Lazy loading for large assets
|
||||
- Progressive enhancement
|
||||
|
||||
**Rendering Optimization:**
|
||||
|
||||
- Sprite batching
|
||||
- Culling off-screen objects
|
||||
- Reduced particle counts on mobile
|
||||
- Texture resolution scaling
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/utils/ObjectPool.ts`
|
||||
- `src/utils/PerformanceMonitor.ts`
|
||||
- `src/config/OptimizationConfig.ts`
|
||||
|
||||
## Game Configuration
|
||||
|
||||
[[LLM: Define all configurable aspects of the game]]
|
||||
|
||||
### Phaser Configuration
|
||||
|
||||
```typescript
|
||||
// src/config/GameConfig.ts
|
||||
const gameConfig: Phaser.Types.Core.GameConfig = {
|
||||
type: Phaser.AUTO,
|
||||
width: {{game_width}},
|
||||
height: {{game_height}},
|
||||
scale: {
|
||||
mode: {{scale_mode}},
|
||||
autoCenter: Phaser.Scale.CENTER_BOTH
|
||||
},
|
||||
physics: {
|
||||
default: '{{physics_system}}',
|
||||
{{physics_system}}: {
|
||||
gravity: { y: {{gravity}} },
|
||||
debug: false
|
||||
}
|
||||
},
|
||||
// Additional configuration...
|
||||
};
|
||||
```
|
||||
|
||||
### Game Balance Configuration
|
||||
|
||||
[[LLM: Based on GDD, define configurable game parameters]]
|
||||
|
||||
```typescript
|
||||
// src/config/GameBalance.ts
|
||||
export const GameBalance = {
|
||||
player: {
|
||||
speed: {{player_speed}},
|
||||
health: {{player_health}},
|
||||
// Additional player parameters...
|
||||
},
|
||||
difficulty: {
|
||||
easy: {{easy_params}},
|
||||
normal: {{normal_params}},
|
||||
hard: {{hard_params}}
|
||||
},
|
||||
// Additional balance parameters...
|
||||
};
|
||||
```
|
||||
|
||||
## Development Guidelines
|
||||
|
||||
[[LLM: Provide coding standards specific to game development]]
|
||||
|
||||
### TypeScript Standards
|
||||
|
||||
**Type Safety:**
|
||||
|
||||
- Use strict mode
|
||||
- Define interfaces for all data structures
|
||||
- Avoid `any` type usage
|
||||
- Use enums for game states
|
||||
|
||||
**Code Organization:**
|
||||
|
||||
- One class per file
|
||||
- Clear naming conventions
|
||||
- Proper error handling
|
||||
- Comprehensive documentation
|
||||
|
||||
### Phaser 3 Best Practices
|
||||
|
||||
**Scene Management:**
|
||||
|
||||
- Clean up resources in shutdown()
|
||||
- Use scene data for communication
|
||||
- Implement proper event handling
|
||||
- Avoid memory leaks
|
||||
|
||||
**Game Object Design:**
|
||||
|
||||
- Extend Phaser classes appropriately
|
||||
- Use component-based architecture
|
||||
- Implement object pooling where needed
|
||||
- Follow consistent update patterns
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
**Unit Testing:**
|
||||
|
||||
- Test game logic separately from Phaser
|
||||
- Mock Phaser dependencies
|
||||
- Test utility functions
|
||||
- Validate game balance calculations
|
||||
|
||||
**Integration Testing:**
|
||||
|
||||
- Scene loading and transitions
|
||||
- Save/load functionality
|
||||
- Input handling
|
||||
- Performance benchmarks
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `tests/utils/GameLogic.test.ts`
|
||||
- `tests/systems/SaveManager.test.ts`
|
||||
- `tests/performance/FrameRate.test.ts`
|
||||
|
||||
## Deployment Architecture
|
||||
|
||||
[[LLM: Define how the game will be built and deployed]]
|
||||
|
||||
### Build Process
|
||||
|
||||
**Development Build:**
|
||||
|
||||
- Fast compilation
|
||||
- Source maps enabled
|
||||
- Debug logging active
|
||||
- Hot reload support
|
||||
|
||||
**Production Build:**
|
||||
|
||||
- Minified and optimized
|
||||
- Asset compression
|
||||
- Performance monitoring
|
||||
- Error tracking
|
||||
|
||||
### Deployment Strategy
|
||||
|
||||
**Web Deployment:**
|
||||
|
||||
- Static hosting ({{hosting_platform}})
|
||||
- CDN for assets
|
||||
- Progressive loading
|
||||
- Browser compatibility
|
||||
|
||||
**Mobile Packaging:**
|
||||
|
||||
- Cordova/Capacitor wrapper
|
||||
- Platform-specific optimization
|
||||
- App store requirements
|
||||
- Performance testing
|
||||
|
||||
## Implementation Roadmap
|
||||
|
||||
[[LLM: Break down the architecture implementation into phases that align with the GDD development phases]]
|
||||
|
||||
### Phase 1: Foundation ({{duration}})
|
||||
|
||||
**Core Systems:**
|
||||
|
||||
- Project setup and configuration
|
||||
- Basic scene management
|
||||
- Asset loading pipeline
|
||||
- Input handling framework
|
||||
|
||||
**Story Epics:**
|
||||
|
||||
- "Engine Setup and Configuration"
|
||||
- "Basic Scene Management System"
|
||||
- "Asset Loading Foundation"
|
||||
|
||||
### Phase 2: Game Systems ({{duration}})
|
||||
|
||||
**Gameplay Systems:**
|
||||
|
||||
- {{primary_mechanic}} implementation
|
||||
- Physics and collision system
|
||||
- Game state management
|
||||
- UI framework
|
||||
|
||||
**Story Epics:**
|
||||
|
||||
- "{{Primary_Mechanic}} System Implementation"
|
||||
- "Physics and Collision Framework"
|
||||
- "Game State Management System"
|
||||
|
||||
### Phase 3: Content & Polish ({{duration}})
|
||||
|
||||
**Content Systems:**
|
||||
|
||||
- Level loading and management
|
||||
- Audio system integration
|
||||
- Performance optimization
|
||||
- Final polish and testing
|
||||
|
||||
**Story Epics:**
|
||||
|
||||
- "Level Management System"
|
||||
- "Audio Integration and Optimization"
|
||||
- "Performance Optimization and Testing"
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
[[LLM: Identify potential technical risks and mitigation strategies]]
|
||||
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| ---------------------------- | ----------- | ---------- | ------------------- |
|
||||
| Performance issues on mobile | {{prob}} | {{impact}} | {{mitigation}} |
|
||||
| Asset loading bottlenecks | {{prob}} | {{impact}} | {{mitigation}} |
|
||||
| Cross-platform compatibility | {{prob}} | {{impact}} | {{mitigation}} |
|
||||
|
||||
## Success Criteria
|
||||
|
||||
[[LLM: Define measurable technical success criteria]]
|
||||
|
||||
**Technical Metrics:**
|
||||
|
||||
- All systems implemented per specification
|
||||
- Performance targets met consistently
|
||||
- Zero critical bugs in core systems
|
||||
- Successful deployment across target platforms
|
||||
|
||||
**Code Quality:**
|
||||
|
||||
- 90%+ test coverage on game logic
|
||||
- Zero TypeScript errors in strict mode
|
||||
- Consistent adherence to coding standards
|
||||
- Comprehensive documentation coverage
|
||||
@@ -0,0 +1,613 @@
|
||||
template:
|
||||
id: game-architecture-template-v2
|
||||
name: Game Architecture Document
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: "docs/{{game_name}}-game-architecture.md"
|
||||
title: "{{game_title}} Game Architecture Document"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
|
||||
sections:
|
||||
- id: initial-setup
|
||||
instruction: |
|
||||
This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics.
|
||||
|
||||
If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD.
|
||||
|
||||
- id: introduction
|
||||
title: Introduction
|
||||
instruction: Establish the document's purpose and scope for game development
|
||||
content: |
|
||||
This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems.
|
||||
|
||||
This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility.
|
||||
sections:
|
||||
- id: change-log
|
||||
title: Change Log
|
||||
instruction: Track document versions and changes
|
||||
type: table
|
||||
template: |
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
- id: technical-overview
|
||||
title: Technical Overview
|
||||
instruction: Present all subsections together, then apply `tasks#advanced-elicitation` protocol to the complete section.
|
||||
sections:
|
||||
- id: architecture-summary
|
||||
title: Architecture Summary
|
||||
instruction: |
|
||||
Provide a comprehensive overview covering:
|
||||
|
||||
- Game engine choice and configuration
|
||||
- Project structure and organization
|
||||
- Key systems and their interactions
|
||||
- Performance and optimization strategy
|
||||
- How this architecture achieves GDD requirements
|
||||
- id: platform-targets
|
||||
title: Platform Targets
|
||||
instruction: Based on GDD requirements, confirm platform support
|
||||
template: |
|
||||
**Primary Platform:** {{primary_platform}}
|
||||
**Secondary Platforms:** {{secondary_platforms}}
|
||||
**Minimum Requirements:** {{min_specs}}
|
||||
**Target Performance:** 60 FPS on {{target_device}}
|
||||
- id: technology-stack
|
||||
title: Technology Stack
|
||||
template: |
|
||||
**Core Engine:** Phaser 3.70+
|
||||
**Language:** TypeScript 5.0+ (Strict Mode)
|
||||
**Build Tool:** {{build_tool}} (Webpack/Vite/Parcel)
|
||||
**Package Manager:** {{package_manager}}
|
||||
**Testing:** {{test_framework}}
|
||||
**Deployment:** {{deployment_platform}}
|
||||
|
||||
- id: project-structure
|
||||
title: Project Structure
|
||||
instruction: Define the complete project organization that developers will follow
|
||||
sections:
|
||||
- id: repository-organization
|
||||
title: Repository Organization
|
||||
instruction: Design a clear folder structure for game development
|
||||
type: code
|
||||
language: text
|
||||
template: |
|
||||
{{game_name}}/
|
||||
├── src/
|
||||
│ ├── scenes/ # Game scenes
|
||||
│ ├── gameObjects/ # Custom game objects
|
||||
│ ├── systems/ # Core game systems
|
||||
│ ├── utils/ # Utility functions
|
||||
│ ├── types/ # TypeScript type definitions
|
||||
│ ├── config/ # Game configuration
|
||||
│ └── main.ts # Entry point
|
||||
├── assets/
|
||||
│ ├── images/ # Sprite assets
|
||||
│ ├── audio/ # Sound files
|
||||
│ ├── data/ # JSON data files
|
||||
│ └── fonts/ # Font files
|
||||
├── public/ # Static web assets
|
||||
├── tests/ # Test files
|
||||
├── docs/ # Documentation
|
||||
│ ├── stories/ # Development stories
|
||||
│ └── architecture/ # Technical docs
|
||||
└── dist/ # Built game files
|
||||
- id: module-organization
|
||||
title: Module Organization
|
||||
instruction: Define how TypeScript modules should be organized
|
||||
sections:
|
||||
- id: scene-structure
|
||||
title: Scene Structure
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Each scene in separate file
|
||||
- Scene-specific logic contained
|
||||
- Clear data passing between scenes
|
||||
- id: game-object-pattern
|
||||
title: Game Object Pattern
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Component-based architecture
|
||||
- Reusable game object classes
|
||||
- Type-safe property definitions
|
||||
- id: system-architecture
|
||||
title: System Architecture
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Singleton managers for global systems
|
||||
- Event-driven communication
|
||||
- Clear separation of concerns
|
||||
|
||||
- id: core-game-systems
|
||||
title: Core Game Systems
|
||||
instruction: Detail each major system that needs to be implemented. Each system should be specific enough for developers to create implementation stories.
|
||||
sections:
|
||||
- id: scene-management
|
||||
title: Scene Management System
|
||||
template: |
|
||||
**Purpose:** Handle game flow and scene transitions
|
||||
|
||||
**Key Components:**
|
||||
|
||||
- Scene loading and unloading
|
||||
- Data passing between scenes
|
||||
- Transition effects
|
||||
- Memory management
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Preload scene for asset loading
|
||||
- Menu system with navigation
|
||||
- Gameplay scenes with state management
|
||||
- Pause/resume functionality
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/scenes/BootScene.ts`
|
||||
- `src/scenes/PreloadScene.ts`
|
||||
- `src/scenes/MenuScene.ts`
|
||||
- `src/scenes/GameScene.ts`
|
||||
- `src/systems/SceneManager.ts`
|
||||
- id: game-state-management
|
||||
title: Game State Management
|
||||
template: |
|
||||
**Purpose:** Track player progress and game status
|
||||
|
||||
**State Categories:**
|
||||
|
||||
- Player progress (levels, unlocks)
|
||||
- Game settings (audio, controls)
|
||||
- Session data (current level, score)
|
||||
- Persistent data (achievements, statistics)
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Save/load system with localStorage
|
||||
- State validation and error recovery
|
||||
- Cross-session data persistence
|
||||
- Settings management
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/GameState.ts`
|
||||
- `src/systems/SaveManager.ts`
|
||||
- `src/types/GameData.ts`
|
||||
- id: asset-management
|
||||
title: Asset Management System
|
||||
template: |
|
||||
**Purpose:** Efficient loading and management of game assets
|
||||
|
||||
**Asset Categories:**
|
||||
|
||||
- Sprite sheets and animations
|
||||
- Audio files and music
|
||||
- Level data and configurations
|
||||
- UI assets and fonts
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Progressive loading strategy
|
||||
- Asset caching and optimization
|
||||
- Error handling for failed loads
|
||||
- Memory management for large assets
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/AssetManager.ts`
|
||||
- `src/config/AssetConfig.ts`
|
||||
- `src/utils/AssetLoader.ts`
|
||||
- id: input-management
|
||||
title: Input Management System
|
||||
template: |
|
||||
**Purpose:** Handle all player input across platforms
|
||||
|
||||
**Input Types:**
|
||||
|
||||
- Keyboard controls
|
||||
- Mouse/pointer interaction
|
||||
- Touch gestures (mobile)
|
||||
- Gamepad support (optional)
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Input mapping and configuration
|
||||
- Touch-friendly mobile controls
|
||||
- Input buffering for responsive gameplay
|
||||
- Customizable control schemes
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/InputManager.ts`
|
||||
- `src/utils/TouchControls.ts`
|
||||
- `src/types/InputTypes.ts`
|
||||
- id: game-mechanics-systems
|
||||
title: Game Mechanics Systems
|
||||
instruction: For each major mechanic defined in the GDD, create a system specification
|
||||
repeatable: true
|
||||
sections:
|
||||
- id: mechanic-system
|
||||
title: "{{mechanic_name}} System"
|
||||
template: |
|
||||
**Purpose:** {{system_purpose}}
|
||||
|
||||
**Core Functionality:**
|
||||
|
||||
- {{feature_1}}
|
||||
- {{feature_2}}
|
||||
- {{feature_3}}
|
||||
|
||||
**Dependencies:** {{required_systems}}
|
||||
|
||||
**Performance Considerations:** {{optimization_notes}}
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/{{system_name}}.ts`
|
||||
- `src/gameObjects/{{related_object}}.ts`
|
||||
- `src/types/{{system_types}}.ts`
|
||||
- id: physics-collision
|
||||
title: Physics & Collision System
|
||||
template: |
|
||||
**Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js)
|
||||
|
||||
**Collision Categories:**
|
||||
|
||||
- Player collision
|
||||
- Enemy interactions
|
||||
- Environmental objects
|
||||
- Collectibles and items
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Optimized collision detection
|
||||
- Physics body management
|
||||
- Collision callbacks and events
|
||||
- Performance monitoring
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/PhysicsManager.ts`
|
||||
- `src/utils/CollisionGroups.ts`
|
||||
- id: audio-system
|
||||
title: Audio System
|
||||
template: |
|
||||
**Audio Requirements:**
|
||||
|
||||
- Background music with looping
|
||||
- Sound effects for actions
|
||||
- Audio settings and volume control
|
||||
- Mobile audio optimization
|
||||
|
||||
**Implementation Features:**
|
||||
|
||||
- Audio sprite management
|
||||
- Dynamic music system
|
||||
- Spatial audio (if applicable)
|
||||
- Audio pooling for performance
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/AudioManager.ts`
|
||||
- `src/config/AudioConfig.ts`
|
||||
- id: ui-system
|
||||
title: UI System
|
||||
template: |
|
||||
**UI Components:**
|
||||
|
||||
- HUD elements (score, health, etc.)
|
||||
- Menu navigation
|
||||
- Modal dialogs
|
||||
- Settings screens
|
||||
|
||||
**Implementation Requirements:**
|
||||
|
||||
- Responsive layout system
|
||||
- Touch-friendly interface
|
||||
- Keyboard navigation support
|
||||
- Animation and transitions
|
||||
|
||||
**Files to Create:**
|
||||
|
||||
- `src/systems/UIManager.ts`
|
||||
- `src/gameObjects/UI/`
|
||||
- `src/types/UITypes.ts`
|
||||
|
||||
- id: performance-architecture
|
||||
title: Performance Architecture
|
||||
instruction: Define performance requirements and optimization strategies
|
||||
sections:
|
||||
- id: performance-targets
|
||||
title: Performance Targets
|
||||
template: |
|
||||
**Frame Rate:** 60 FPS sustained, 30 FPS minimum
|
||||
**Memory Usage:** <{{memory_limit}}MB total
|
||||
**Load Times:** <{{initial_load}}s initial, <{{level_load}}s per level
|
||||
**Battery Optimization:** Reduced updates when not visible
|
||||
- id: optimization-strategies
|
||||
title: Optimization Strategies
|
||||
sections:
|
||||
- id: object-pooling
|
||||
title: Object Pooling
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Bullets and projectiles
|
||||
- Particle effects
|
||||
- Enemy objects
|
||||
- UI elements
|
||||
- id: asset-optimization
|
||||
title: Asset Optimization
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Texture atlases for sprites
|
||||
- Audio compression
|
||||
- Lazy loading for large assets
|
||||
- Progressive enhancement
|
||||
- id: rendering-optimization
|
||||
title: Rendering Optimization
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Sprite batching
|
||||
- Culling off-screen objects
|
||||
- Reduced particle counts on mobile
|
||||
- Texture resolution scaling
|
||||
- id: optimization-files
|
||||
title: Files to Create
|
||||
type: bullet-list
|
||||
template: |
|
||||
- `src/utils/ObjectPool.ts`
|
||||
- `src/utils/PerformanceMonitor.ts`
|
||||
- `src/config/OptimizationConfig.ts`
|
||||
|
||||
- id: game-configuration
|
||||
title: Game Configuration
|
||||
instruction: Define all configurable aspects of the game
|
||||
sections:
|
||||
- id: phaser-configuration
|
||||
title: Phaser Configuration
|
||||
type: code
|
||||
language: typescript
|
||||
template: |
|
||||
// src/config/GameConfig.ts
|
||||
const gameConfig: Phaser.Types.Core.GameConfig = {
|
||||
type: Phaser.AUTO,
|
||||
width: {{game_width}},
|
||||
height: {{game_height}},
|
||||
scale: {
|
||||
mode: {{scale_mode}},
|
||||
autoCenter: Phaser.Scale.CENTER_BOTH
|
||||
},
|
||||
physics: {
|
||||
default: '{{physics_system}}',
|
||||
{{physics_system}}: {
|
||||
gravity: { y: {{gravity}} },
|
||||
debug: false
|
||||
}
|
||||
},
|
||||
// Additional configuration...
|
||||
};
|
||||
- id: game-balance-configuration
|
||||
title: Game Balance Configuration
|
||||
instruction: Based on GDD, define configurable game parameters
|
||||
type: code
|
||||
language: typescript
|
||||
template: |
|
||||
// src/config/GameBalance.ts
|
||||
export const GameBalance = {
|
||||
player: {
|
||||
speed: {{player_speed}},
|
||||
health: {{player_health}},
|
||||
// Additional player parameters...
|
||||
},
|
||||
difficulty: {
|
||||
easy: {{easy_params}},
|
||||
normal: {{normal_params}},
|
||||
hard: {{hard_params}}
|
||||
},
|
||||
// Additional balance parameters...
|
||||
};
|
||||
|
||||
- id: development-guidelines
|
||||
title: Development Guidelines
|
||||
instruction: Provide coding standards specific to game development
|
||||
sections:
|
||||
- id: typescript-standards
|
||||
title: TypeScript Standards
|
||||
sections:
|
||||
- id: type-safety
|
||||
title: Type Safety
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Use strict mode
|
||||
- Define interfaces for all data structures
|
||||
- Avoid `any` type usage
|
||||
- Use enums for game states
|
||||
- id: code-organization
|
||||
title: Code Organization
|
||||
type: bullet-list
|
||||
template: |
|
||||
- One class per file
|
||||
- Clear naming conventions
|
||||
- Proper error handling
|
||||
- Comprehensive documentation
|
||||
- id: phaser-best-practices
|
||||
title: Phaser 3 Best Practices
|
||||
sections:
|
||||
- id: scene-management-practices
|
||||
title: Scene Management
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Clean up resources in shutdown()
|
||||
- Use scene data for communication
|
||||
- Implement proper event handling
|
||||
- Avoid memory leaks
|
||||
- id: game-object-design
|
||||
title: Game Object Design
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Extend Phaser classes appropriately
|
||||
- Use component-based architecture
|
||||
- Implement object pooling where needed
|
||||
- Follow consistent update patterns
|
||||
- id: testing-strategy
|
||||
title: Testing Strategy
|
||||
sections:
|
||||
- id: unit-testing
|
||||
title: Unit Testing
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Test game logic separately from Phaser
|
||||
- Mock Phaser dependencies
|
||||
- Test utility functions
|
||||
- Validate game balance calculations
|
||||
- id: integration-testing
|
||||
title: Integration Testing
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Scene loading and transitions
|
||||
- Save/load functionality
|
||||
- Input handling
|
||||
- Performance benchmarks
|
||||
- id: test-files
|
||||
title: Files to Create
|
||||
type: bullet-list
|
||||
template: |
|
||||
- `tests/utils/GameLogic.test.ts`
|
||||
- `tests/systems/SaveManager.test.ts`
|
||||
- `tests/performance/FrameRate.test.ts`
|
||||
|
||||
- id: deployment-architecture
|
||||
title: Deployment Architecture
|
||||
instruction: Define how the game will be built and deployed
|
||||
sections:
|
||||
- id: build-process
|
||||
title: Build Process
|
||||
sections:
|
||||
- id: development-build
|
||||
title: Development Build
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Fast compilation
|
||||
- Source maps enabled
|
||||
- Debug logging active
|
||||
- Hot reload support
|
||||
- id: production-build
|
||||
title: Production Build
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Minified and optimized
|
||||
- Asset compression
|
||||
- Performance monitoring
|
||||
- Error tracking
|
||||
- id: deployment-strategy
|
||||
title: Deployment Strategy
|
||||
sections:
|
||||
- id: web-deployment
|
||||
title: Web Deployment
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Static hosting ({{hosting_platform}})
|
||||
- CDN for assets
|
||||
- Progressive loading
|
||||
- Browser compatibility
|
||||
- id: mobile-packaging
|
||||
title: Mobile Packaging
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Cordova/Capacitor wrapper
|
||||
- Platform-specific optimization
|
||||
- App store requirements
|
||||
- Performance testing
|
||||
|
||||
- id: implementation-roadmap
|
||||
title: Implementation Roadmap
|
||||
instruction: Break down the architecture implementation into phases that align with the GDD development phases
|
||||
sections:
|
||||
- id: phase-1-foundation
|
||||
title: "Phase 1: Foundation ({{duration}})"
|
||||
sections:
|
||||
- id: phase-1-core
|
||||
title: Core Systems
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Project setup and configuration
|
||||
- Basic scene management
|
||||
- Asset loading pipeline
|
||||
- Input handling framework
|
||||
- id: phase-1-epics
|
||||
title: Story Epics
|
||||
type: bullet-list
|
||||
template: |
|
||||
- "Engine Setup and Configuration"
|
||||
- "Basic Scene Management System"
|
||||
- "Asset Loading Foundation"
|
||||
- id: phase-2-game-systems
|
||||
title: "Phase 2: Game Systems ({{duration}})"
|
||||
sections:
|
||||
- id: phase-2-gameplay
|
||||
title: Gameplay Systems
|
||||
type: bullet-list
|
||||
template: |
|
||||
- {{primary_mechanic}} implementation
|
||||
- Physics and collision system
|
||||
- Game state management
|
||||
- UI framework
|
||||
- id: phase-2-epics
|
||||
title: Story Epics
|
||||
type: bullet-list
|
||||
template: |
|
||||
- "{{primary_mechanic}} System Implementation"
|
||||
- "Physics and Collision Framework"
|
||||
- "Game State Management System"
|
||||
- id: phase-3-content-polish
|
||||
title: "Phase 3: Content & Polish ({{duration}})"
|
||||
sections:
|
||||
- id: phase-3-content
|
||||
title: Content Systems
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Level loading and management
|
||||
- Audio system integration
|
||||
- Performance optimization
|
||||
- Final polish and testing
|
||||
- id: phase-3-epics
|
||||
title: Story Epics
|
||||
type: bullet-list
|
||||
template: |
|
||||
- "Level Management System"
|
||||
- "Audio Integration and Optimization"
|
||||
- "Performance Optimization and Testing"
|
||||
|
||||
- id: risk-assessment
|
||||
title: Risk Assessment
|
||||
instruction: Identify potential technical risks and mitigation strategies
|
||||
type: table
|
||||
template: |
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| ---------------------------- | ----------- | ---------- | ------------------- |
|
||||
| Performance issues on mobile | {{prob}} | {{impact}} | {{mitigation}} |
|
||||
| Asset loading bottlenecks | {{prob}} | {{impact}} | {{mitigation}} |
|
||||
| Cross-platform compatibility | {{prob}} | {{impact}} | {{mitigation}} |
|
||||
|
||||
- id: success-criteria
|
||||
title: Success Criteria
|
||||
instruction: Define measurable technical success criteria
|
||||
sections:
|
||||
- id: technical-metrics
|
||||
title: Technical Metrics
|
||||
type: bullet-list
|
||||
template: |
|
||||
- All systems implemented per specification
|
||||
- Performance targets met consistently
|
||||
- Zero critical bugs in core systems
|
||||
- Successful deployment across target platforms
|
||||
- id: code-quality
|
||||
title: Code Quality
|
||||
type: bullet-list
|
||||
template: |
|
||||
- 90%+ test coverage on game logic
|
||||
- Zero TypeScript errors in strict mode
|
||||
- Consistent adherence to coding standards
|
||||
- Comprehensive documentation coverage
|
||||
@@ -1,345 +0,0 @@
|
||||
# {{Game Title}} Game Brief
|
||||
|
||||
[[LLM: This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
|
||||
|
||||
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.]]
|
||||
|
||||
## Game Vision
|
||||
|
||||
[[LLM: Establish the core vision and identity of the game. Present each subsection and gather user feedback before proceeding.]]
|
||||
|
||||
### Core Concept
|
||||
|
||||
[[LLM: 2-3 sentences that clearly capture what the game is and why it will be compelling to players]]
|
||||
|
||||
### Elevator Pitch
|
||||
|
||||
[[LLM: Single sentence that captures the essence of the game in a memorable way]]
|
||||
|
||||
**"{{game_description_in_one_sentence}}"**
|
||||
|
||||
### Vision Statement
|
||||
|
||||
[[LLM: Inspirational statement about what the game will achieve for players and why it matters]]
|
||||
|
||||
## Target Market
|
||||
|
||||
[[LLM: Define the audience and market context. Apply `tasks#advanced-elicitation` after presenting this section.]]
|
||||
|
||||
### Primary Audience
|
||||
|
||||
**Demographics:** {{age_range}}, {{platform_preference}}, {{gaming_experience}}
|
||||
**Psychographics:** {{interests}}, {{motivations}}, {{play_patterns}}
|
||||
**Gaming Preferences:** {{preferred_genres}}, {{session_length}}, {{difficulty_preference}}
|
||||
|
||||
### Secondary Audiences
|
||||
|
||||
**Audience 2:** {{description}}
|
||||
**Audience 3:** {{description}}
|
||||
|
||||
### Market Context
|
||||
|
||||
**Genre:** {{primary_genre}} / {{secondary_genre}}
|
||||
**Platform Strategy:** {{platform_focus}}
|
||||
**Competitive Positioning:** {{differentiation_statement}}
|
||||
|
||||
## Game Fundamentals
|
||||
|
||||
[[LLM: Define the core gameplay elements. Each subsection should be specific enough to guide detailed design work.]]
|
||||
|
||||
### Core Gameplay Pillars
|
||||
|
||||
[[LLM: 3-5 fundamental principles that guide all design decisions]]
|
||||
|
||||
1. **{{pillar_1}}** - {{description_and_rationale}}
|
||||
2. **{{pillar_2}}** - {{description_and_rationale}}
|
||||
3. **{{pillar_3}}** - {{description_and_rationale}}
|
||||
|
||||
### Primary Mechanics
|
||||
|
||||
[[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}}
|
||||
|
||||
### Player Experience Goals
|
||||
|
||||
[[LLM: Define what emotions and experiences the game should create for players]]
|
||||
|
||||
**Primary Experience:** {{main_emotional_goal}}
|
||||
**Secondary Experiences:** {{supporting_emotional_goals}}
|
||||
**Engagement Pattern:** {{how_player_engagement_evolves}}
|
||||
|
||||
## Scope and Constraints
|
||||
|
||||
[[LLM: Define the boundaries and limitations that will shape development. Apply `tasks#advanced-elicitation` to clarify any constraints.]]
|
||||
|
||||
### Project Scope
|
||||
|
||||
**Game Length:** {{estimated_content_hours}}
|
||||
**Content Volume:** {{levels_areas_content_amount}}
|
||||
**Feature Complexity:** {{simple|moderate|complex}}
|
||||
**Scope Comparison:** "Similar to {{reference_game}} but with {{key_differences}}"
|
||||
|
||||
### 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
|
||||
- Load Time Goal: <{{load_time_seconds}}s
|
||||
|
||||
### Resource Constraints
|
||||
|
||||
**Team Size:** {{team_composition}}
|
||||
**Timeline:** {{development_duration}}
|
||||
**Budget Considerations:** {{budget_constraints_or_targets}}
|
||||
**Asset Requirements:** {{art_audio_content_needs}}
|
||||
|
||||
### Business Constraints
|
||||
|
||||
^^CONDITION: has_business_goals^^
|
||||
|
||||
**Monetization Model:** {{free|premium|freemium|subscription}}
|
||||
**Revenue Goals:** {{revenue_targets_if_applicable}}
|
||||
**Platform Requirements:** {{store_certification_needs}}
|
||||
**Launch Timeline:** {{target_launch_window}}
|
||||
|
||||
^^/CONDITION: has_business_goals^^
|
||||
|
||||
## Reference Framework
|
||||
|
||||
[[LLM: Provide context through references and competitive analysis]]
|
||||
|
||||
### 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}}
|
||||
|
||||
### Competitive Analysis
|
||||
|
||||
**Direct Competitors:**
|
||||
|
||||
- {{competitor_1}}: {{strengths_and_weaknesses}}
|
||||
- {{competitor_2}}: {{strengths_and_weaknesses}}
|
||||
|
||||
**Differentiation Strategy:**
|
||||
{{how_we_differ_and_why_thats_valuable}}
|
||||
|
||||
### Market Opportunity
|
||||
|
||||
**Market Gap:** {{underserved_need_or_opportunity}}
|
||||
**Timing Factors:** {{why_now_is_the_right_time}}
|
||||
**Success Metrics:** {{how_well_measure_success}}
|
||||
|
||||
## Content Framework
|
||||
|
||||
[[LLM: Outline the content structure and progression without full design detail]]
|
||||
|
||||
### Game Structure
|
||||
|
||||
**Overall Flow:** {{linear|hub_world|open_world|procedural}}
|
||||
**Progression Model:** {{how_players_advance}}
|
||||
**Session Structure:** {{typical_play_session_flow}}
|
||||
|
||||
### 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
|
||||
|
||||
**Difficulty Approach:** {{how_challenge_is_structured}}
|
||||
**Accessibility Features:** {{planned_accessibility_support}}
|
||||
**Skill Requirements:** {{what_skills_players_need}}
|
||||
|
||||
## Art and Audio Direction
|
||||
|
||||
[[LLM: Establish the aesthetic vision that will guide asset creation]]
|
||||
|
||||
### Visual Style
|
||||
|
||||
**Art Direction:** {{style_description}}
|
||||
**Reference Materials:** {{visual_inspiration_sources}}
|
||||
**Technical Approach:** {{2d_style_pixel_vector_etc}}
|
||||
**Color Strategy:** {{color_palette_mood}}
|
||||
|
||||
### Audio Direction
|
||||
|
||||
**Music Style:** {{genre_and_mood}}
|
||||
**Sound Design:** {{audio_personality}}
|
||||
**Implementation Needs:** {{technical_audio_requirements}}
|
||||
|
||||
### UI/UX Approach
|
||||
|
||||
**Interface Style:** {{ui_aesthetic}}
|
||||
**User Experience Goals:** {{ux_priorities}}
|
||||
**Platform Adaptations:** {{cross_platform_considerations}}
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
[[LLM: Identify potential challenges and mitigation strategies]]
|
||||
|
||||
### 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}} |
|
||||
|
||||
### 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}} |
|
||||
|
||||
### Market Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| ----------------- | ----------- | ------ | ------------------- | ------ | --- | ----- | ----------------------- |
|
||||
| {{market_risk_1}} | {{high | med | low}} | {{high | med | low}} | {{mitigation_approach}} |
|
||||
|
||||
## Success Criteria
|
||||
|
||||
[[LLM: Define measurable goals for the project]]
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
^^CONDITION: has_business_goals^^
|
||||
|
||||
### Business Metrics
|
||||
|
||||
**Commercial Goals:**
|
||||
|
||||
- {{revenue_target}} in first {{time_period}}
|
||||
- {{user_acquisition_target}} players in first {{time_period}}
|
||||
- {{retention_target}} monthly active users
|
||||
|
||||
^^/CONDITION: has_business_goals^^
|
||||
|
||||
## Next Steps
|
||||
|
||||
[[LLM: Define immediate actions following the brief completion]]
|
||||
|
||||
### Immediate Actions
|
||||
|
||||
1. **Stakeholder Review** - {{review_process_and_timeline}}
|
||||
2. **Concept Validation** - {{validation_approach}}
|
||||
3. **Resource Planning** - {{team_and_resource_allocation}}
|
||||
|
||||
### 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
|
||||
|
||||
### Documentation Pipeline
|
||||
|
||||
**Required Documents:**
|
||||
|
||||
1. Game Design Document (GDD) - {{target_completion}}
|
||||
2. Technical Architecture Document - {{target_completion}}
|
||||
3. Art Style Guide - {{target_completion}}
|
||||
4. Production Plan - {{target_completion}}
|
||||
|
||||
### Validation Plan
|
||||
|
||||
**Concept Testing:**
|
||||
|
||||
- {{validation_method_1}} - {{timeline}}
|
||||
- {{validation_method_2}} - {{timeline}}
|
||||
|
||||
**Prototype Testing:**
|
||||
|
||||
- {{testing_approach}} - {{timeline}}
|
||||
- {{feedback_collection_method}} - {{timeline}}
|
||||
|
||||
## Appendices
|
||||
|
||||
### Research Materials
|
||||
|
||||
[[LLM: Include any supporting research, competitive analysis, or market data that informed the brief]]
|
||||
|
||||
### Brainstorming Session Notes
|
||||
|
||||
[[LLM: Reference any brainstorming sessions that led to this brief]]
|
||||
|
||||
### Stakeholder Input
|
||||
|
||||
[[LLM: Include key input from stakeholders that shaped the vision]]
|
||||
|
||||
### Change Log
|
||||
|
||||
[[LLM: Track document versions and changes]]
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
@@ -0,0 +1,356 @@
|
||||
template:
|
||||
id: game-brief-template-v2
|
||||
name: Game Brief
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: "docs/{{game_name}}-game-brief.md"
|
||||
title: "{{game_title}} Game Brief"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
|
||||
sections:
|
||||
- id: initial-setup
|
||||
instruction: |
|
||||
This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
|
||||
|
||||
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.
|
||||
|
||||
- id: game-vision
|
||||
title: Game Vision
|
||||
instruction: Establish the core vision and identity of the game. Present each subsection and gather user feedback before proceeding.
|
||||
sections:
|
||||
- id: core-concept
|
||||
title: Core Concept
|
||||
instruction: 2-3 sentences that clearly capture what the game is and why it will be compelling to players
|
||||
- id: elevator-pitch
|
||||
title: Elevator Pitch
|
||||
instruction: Single sentence that captures the essence of the game in a memorable way
|
||||
template: |
|
||||
**"{{game_description_in_one_sentence}}"**
|
||||
- id: vision-statement
|
||||
title: Vision Statement
|
||||
instruction: Inspirational statement about what the game will achieve for players and why it matters
|
||||
|
||||
- id: target-market
|
||||
title: Target Market
|
||||
instruction: Define the audience and market context. Apply `tasks#advanced-elicitation` after presenting this section.
|
||||
sections:
|
||||
- id: primary-audience
|
||||
title: Primary Audience
|
||||
template: |
|
||||
**Demographics:** {{age_range}}, {{platform_preference}}, {{gaming_experience}}
|
||||
**Psychographics:** {{interests}}, {{motivations}}, {{play_patterns}}
|
||||
**Gaming Preferences:** {{preferred_genres}}, {{session_length}}, {{difficulty_preference}}
|
||||
- id: secondary-audiences
|
||||
title: Secondary Audiences
|
||||
template: |
|
||||
**Audience 2:** {{description}}
|
||||
**Audience 3:** {{description}}
|
||||
- id: market-context
|
||||
title: Market Context
|
||||
template: |
|
||||
**Genre:** {{primary_genre}} / {{secondary_genre}}
|
||||
**Platform Strategy:** {{platform_focus}}
|
||||
**Competitive Positioning:** {{differentiation_statement}}
|
||||
|
||||
- id: game-fundamentals
|
||||
title: Game Fundamentals
|
||||
instruction: Define the core gameplay elements. Each subsection should be specific enough to guide detailed design work.
|
||||
sections:
|
||||
- id: core-gameplay-pillars
|
||||
title: Core Gameplay Pillars
|
||||
instruction: 3-5 fundamental principles that guide all design decisions
|
||||
type: numbered-list
|
||||
template: |
|
||||
**{{pillar_name}}** - {{description_and_rationale}}
|
||||
- id: primary-mechanics
|
||||
title: Primary Mechanics
|
||||
instruction: List the 3-5 most important gameplay mechanics that define the player experience
|
||||
repeatable: true
|
||||
template: |
|
||||
**Core Mechanic: {{mechanic_name}}**
|
||||
|
||||
- **Description:** {{how_it_works}}
|
||||
- **Player Value:** {{why_its_fun}}
|
||||
- **Implementation Scope:** {{complexity_estimate}}
|
||||
- id: player-experience-goals
|
||||
title: Player Experience Goals
|
||||
instruction: Define what emotions and experiences the game should create for players
|
||||
template: |
|
||||
**Primary Experience:** {{main_emotional_goal}}
|
||||
**Secondary Experiences:** {{supporting_emotional_goals}}
|
||||
**Engagement Pattern:** {{how_player_engagement_evolves}}
|
||||
|
||||
- id: scope-constraints
|
||||
title: Scope and Constraints
|
||||
instruction: Define the boundaries and limitations that will shape development. Apply `tasks#advanced-elicitation` to clarify any constraints.
|
||||
sections:
|
||||
- id: project-scope
|
||||
title: Project Scope
|
||||
template: |
|
||||
**Game Length:** {{estimated_content_hours}}
|
||||
**Content Volume:** {{levels_areas_content_amount}}
|
||||
**Feature Complexity:** {{simple|moderate|complex}}
|
||||
**Scope Comparison:** "Similar to {{reference_game}} but with {{key_differences}}"
|
||||
- id: technical-constraints
|
||||
title: Technical Constraints
|
||||
template: |
|
||||
**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
|
||||
- Load Time Goal: <{{load_time_seconds}}s
|
||||
- id: resource-constraints
|
||||
title: Resource Constraints
|
||||
template: |
|
||||
**Team Size:** {{team_composition}}
|
||||
**Timeline:** {{development_duration}}
|
||||
**Budget Considerations:** {{budget_constraints_or_targets}}
|
||||
**Asset Requirements:** {{art_audio_content_needs}}
|
||||
- id: business-constraints
|
||||
title: Business Constraints
|
||||
condition: has_business_goals
|
||||
template: |
|
||||
**Monetization Model:** {{free|premium|freemium|subscription}}
|
||||
**Revenue Goals:** {{revenue_targets_if_applicable}}
|
||||
**Platform Requirements:** {{store_certification_needs}}
|
||||
**Launch Timeline:** {{target_launch_window}}
|
||||
|
||||
- id: reference-framework
|
||||
title: Reference Framework
|
||||
instruction: Provide context through references and competitive analysis
|
||||
sections:
|
||||
- id: inspiration-games
|
||||
title: Inspiration Games
|
||||
sections:
|
||||
- id: primary-references
|
||||
title: Primary References
|
||||
type: numbered-list
|
||||
repeatable: true
|
||||
template: |
|
||||
**{{reference_game}}** - {{what_we_learn_from_it}}
|
||||
- id: competitive-analysis
|
||||
title: Competitive Analysis
|
||||
template: |
|
||||
**Direct Competitors:**
|
||||
|
||||
- {{competitor_1}}: {{strengths_and_weaknesses}}
|
||||
- {{competitor_2}}: {{strengths_and_weaknesses}}
|
||||
|
||||
**Differentiation Strategy:**
|
||||
{{how_we_differ_and_why_thats_valuable}}
|
||||
- id: market-opportunity
|
||||
title: Market Opportunity
|
||||
template: |
|
||||
**Market Gap:** {{underserved_need_or_opportunity}}
|
||||
**Timing Factors:** {{why_now_is_the_right_time}}
|
||||
**Success Metrics:** {{how_well_measure_success}}
|
||||
|
||||
- id: content-framework
|
||||
title: Content Framework
|
||||
instruction: Outline the content structure and progression without full design detail
|
||||
sections:
|
||||
- id: game-structure
|
||||
title: Game Structure
|
||||
template: |
|
||||
**Overall Flow:** {{linear|hub_world|open_world|procedural}}
|
||||
**Progression Model:** {{how_players_advance}}
|
||||
**Session Structure:** {{typical_play_session_flow}}
|
||||
- id: content-categories
|
||||
title: Content Categories
|
||||
template: |
|
||||
**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}}
|
||||
- id: difficulty-accessibility
|
||||
title: Difficulty and Accessibility
|
||||
template: |
|
||||
**Difficulty Approach:** {{how_challenge_is_structured}}
|
||||
**Accessibility Features:** {{planned_accessibility_support}}
|
||||
**Skill Requirements:** {{what_skills_players_need}}
|
||||
|
||||
- id: art-audio-direction
|
||||
title: Art and Audio Direction
|
||||
instruction: Establish the aesthetic vision that will guide asset creation
|
||||
sections:
|
||||
- id: visual-style
|
||||
title: Visual Style
|
||||
template: |
|
||||
**Art Direction:** {{style_description}}
|
||||
**Reference Materials:** {{visual_inspiration_sources}}
|
||||
**Technical Approach:** {{2d_style_pixel_vector_etc}}
|
||||
**Color Strategy:** {{color_palette_mood}}
|
||||
- id: audio-direction
|
||||
title: Audio Direction
|
||||
template: |
|
||||
**Music Style:** {{genre_and_mood}}
|
||||
**Sound Design:** {{audio_personality}}
|
||||
**Implementation Needs:** {{technical_audio_requirements}}
|
||||
- id: ui-ux-approach
|
||||
title: UI/UX Approach
|
||||
template: |
|
||||
**Interface Style:** {{ui_aesthetic}}
|
||||
**User Experience Goals:** {{ux_priorities}}
|
||||
**Platform Adaptations:** {{cross_platform_considerations}}
|
||||
|
||||
- id: risk-assessment
|
||||
title: Risk Assessment
|
||||
instruction: Identify potential challenges and mitigation strategies
|
||||
sections:
|
||||
- id: technical-risks
|
||||
title: Technical Risks
|
||||
type: table
|
||||
template: |
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| ---- | ----------- | ------ | ------------------- |
|
||||
| {{technical_risk}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
|
||||
- id: design-risks
|
||||
title: Design Risks
|
||||
type: table
|
||||
template: |
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| ---- | ----------- | ------ | ------------------- |
|
||||
| {{design_risk}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
|
||||
- id: market-risks
|
||||
title: Market Risks
|
||||
type: table
|
||||
template: |
|
||||
| Risk | Probability | Impact | Mitigation Strategy |
|
||||
| ---- | ----------- | ------ | ------------------- |
|
||||
| {{market_risk}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
|
||||
|
||||
- id: success-criteria
|
||||
title: Success Criteria
|
||||
instruction: Define measurable goals for the project
|
||||
sections:
|
||||
- id: player-experience-metrics
|
||||
title: Player Experience Metrics
|
||||
template: |
|
||||
**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
|
||||
- id: development-metrics
|
||||
title: Development Metrics
|
||||
template: |
|
||||
**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
|
||||
- id: business-metrics
|
||||
title: Business Metrics
|
||||
condition: has_business_goals
|
||||
template: |
|
||||
**Commercial Goals:**
|
||||
|
||||
- {{revenue_target}} in first {{time_period}}
|
||||
- {{user_acquisition_target}} players in first {{time_period}}
|
||||
- {{retention_target}} monthly active users
|
||||
|
||||
- id: next-steps
|
||||
title: Next Steps
|
||||
instruction: Define immediate actions following the brief completion
|
||||
sections:
|
||||
- id: immediate-actions
|
||||
title: Immediate Actions
|
||||
type: numbered-list
|
||||
template: |
|
||||
**{{action_item}}** - {{details_and_timeline}}
|
||||
- id: development-roadmap
|
||||
title: Development Roadmap
|
||||
sections:
|
||||
- id: phase-1-preproduction
|
||||
title: "Phase 1: Pre-Production ({{duration}})"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Detailed Game Design Document creation
|
||||
- Technical architecture planning
|
||||
- Art style exploration and pipeline setup
|
||||
- id: phase-2-prototype
|
||||
title: "Phase 2: Prototype ({{duration}})"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Core mechanic implementation
|
||||
- Technical proof of concept
|
||||
- Initial playtesting and iteration
|
||||
- id: phase-3-production
|
||||
title: "Phase 3: Production ({{duration}})"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Full feature development
|
||||
- Content creation and integration
|
||||
- Comprehensive testing and optimization
|
||||
- id: documentation-pipeline
|
||||
title: Documentation Pipeline
|
||||
sections:
|
||||
- id: required-documents
|
||||
title: Required Documents
|
||||
type: numbered-list
|
||||
template: |
|
||||
Game Design Document (GDD) - {{target_completion}}
|
||||
Technical Architecture Document - {{target_completion}}
|
||||
Art Style Guide - {{target_completion}}
|
||||
Production Plan - {{target_completion}}
|
||||
- id: validation-plan
|
||||
title: Validation Plan
|
||||
template: |
|
||||
**Concept Testing:**
|
||||
|
||||
- {{validation_method_1}} - {{timeline}}
|
||||
- {{validation_method_2}} - {{timeline}}
|
||||
|
||||
**Prototype Testing:**
|
||||
|
||||
- {{testing_approach}} - {{timeline}}
|
||||
- {{feedback_collection_method}} - {{timeline}}
|
||||
|
||||
- id: appendices
|
||||
title: Appendices
|
||||
sections:
|
||||
- id: research-materials
|
||||
title: Research Materials
|
||||
instruction: Include any supporting research, competitive analysis, or market data that informed the brief
|
||||
- id: brainstorming-notes
|
||||
title: Brainstorming Session Notes
|
||||
instruction: Reference any brainstorming sessions that led to this brief
|
||||
- id: stakeholder-input
|
||||
title: Stakeholder Input
|
||||
instruction: Include key input from stakeholders that shaped the vision
|
||||
- id: change-log
|
||||
title: Change Log
|
||||
instruction: Track document versions and changes
|
||||
type: table
|
||||
template: |
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
@@ -1,331 +0,0 @@
|
||||
# {{Game Title}} Game Design Document (GDD)
|
||||
|
||||
[[LLM: This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
|
||||
|
||||
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis]]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[[LLM: Create a compelling overview that captures the essence of the game. Present this section first and get user feedback before proceeding.]]
|
||||
|
||||
### Core Concept
|
||||
|
||||
[[LLM: 2-3 sentences that clearly describe what the game is and why players will love it]]
|
||||
|
||||
### Target Audience
|
||||
|
||||
[[LLM: Define the primary and secondary audience with demographics and gaming preferences]]
|
||||
|
||||
**Primary:** {{age_range}}, {{player_type}}, {{platform_preference}}
|
||||
**Secondary:** {{secondary_audience}}
|
||||
|
||||
### Platform & Technical Requirements
|
||||
|
||||
[[LLM: Based on the technical preferences or user input, define the target platforms]]
|
||||
|
||||
**Primary Platform:** {{platform}}
|
||||
**Engine:** Phaser 3 + TypeScript
|
||||
**Performance Target:** 60 FPS on {{minimum_device}}
|
||||
**Screen Support:** {{resolution_range}}
|
||||
|
||||
### Unique Selling Points
|
||||
|
||||
[[LLM: List 3-5 key features that differentiate this game from competitors]]
|
||||
|
||||
1. {{usp_1}}
|
||||
2. {{usp_2}}
|
||||
3. {{usp_3}}
|
||||
|
||||
## Core Gameplay
|
||||
|
||||
[[LLM: This section defines the fundamental game mechanics. After presenting each subsection, apply `tasks#advanced-elicitation` protocol to ensure completeness.]]
|
||||
|
||||
### Game Pillars
|
||||
|
||||
[[LLM: Define 3-5 core pillars that guide all design decisions. These should be specific and actionable.]]
|
||||
|
||||
1. **{{pillar_1}}** - {{description}}
|
||||
2. **{{pillar_2}}** - {{description}}
|
||||
3. **{{pillar_3}}** - {{description}}
|
||||
|
||||
### Core Gameplay Loop
|
||||
|
||||
[[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)
|
||||
4. {{reward_feedback}} ({{time_4}}s)
|
||||
|
||||
### Win/Loss Conditions
|
||||
|
||||
[[LLM: Clearly define success and failure states]]
|
||||
|
||||
**Victory Conditions:**
|
||||
|
||||
- {{win_condition_1}}
|
||||
- {{win_condition_2}}
|
||||
|
||||
**Failure States:**
|
||||
|
||||
- {{loss_condition_1}}
|
||||
- {{loss_condition_2}}
|
||||
|
||||
## Game Mechanics
|
||||
|
||||
[[LLM: Detail each major mechanic that will need to be implemented. Each mechanic should be specific enough for developers to create implementation stories.]]
|
||||
|
||||
### Primary Mechanics
|
||||
|
||||
<<REPEAT section="mechanic" count="3-5">>
|
||||
|
||||
#### {{mechanic_name}}
|
||||
|
||||
**Description:** {{detailed_description}}
|
||||
|
||||
**Player Input:** {{input_method}}
|
||||
|
||||
**System Response:** {{game_response}}
|
||||
|
||||
**Implementation Notes:**
|
||||
|
||||
- {{tech_requirement_1}}
|
||||
- {{tech_requirement_2}}
|
||||
- {{performance_consideration}}
|
||||
|
||||
**Dependencies:** {{other_mechanics_needed}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
### Controls
|
||||
|
||||
[[LLM: Define all input methods for different platforms]]
|
||||
|
||||
| Action | Desktop | Mobile | Gamepad |
|
||||
| ------------ | ------- | ----------- | ---------- |
|
||||
| {{action_1}} | {{key}} | {{gesture}} | {{button}} |
|
||||
| {{action_2}} | {{key}} | {{gesture}} | {{button}} |
|
||||
|
||||
## Progression & Balance
|
||||
|
||||
[[LLM: Define how players advance and how difficulty scales. This section should provide clear parameters for implementation.]]
|
||||
|
||||
### Player Progression
|
||||
|
||||
**Progression Type:** {{linear|branching|metroidvania}}
|
||||
|
||||
**Key Milestones:**
|
||||
|
||||
1. **{{milestone_1}}** - {{unlock_description}}
|
||||
2. **{{milestone_2}}** - {{unlock_description}}
|
||||
3. **{{milestone_3}}** - {{unlock_description}}
|
||||
|
||||
### Difficulty Curve
|
||||
|
||||
[[LLM: Provide specific parameters for balancing]]
|
||||
|
||||
**Tutorial Phase:** {{duration}} - {{difficulty_description}}
|
||||
**Early Game:** {{duration}} - {{difficulty_description}}
|
||||
**Mid Game:** {{duration}} - {{difficulty_description}}
|
||||
**Late Game:** {{duration}} - {{difficulty_description}}
|
||||
|
||||
### Economy & Resources
|
||||
|
||||
^^CONDITION: has_economy^^
|
||||
|
||||
[[LLM: Define any in-game currencies, resources, or collectibles]]
|
||||
|
||||
| Resource | Earn Rate | Spend Rate | Purpose | Cap |
|
||||
| -------------- | --------- | ---------- | ------- | ------- |
|
||||
| {{resource_1}} | {{rate}} | {{rate}} | {{use}} | {{max}} |
|
||||
|
||||
^^/CONDITION: has_economy^^
|
||||
|
||||
## Level Design Framework
|
||||
|
||||
[[LLM: Provide guidelines for level creation that developers can use to create level implementation stories]]
|
||||
|
||||
### Level Types
|
||||
|
||||
<<REPEAT section="level_type" count="2-4">>
|
||||
|
||||
#### {{level_type_name}}
|
||||
|
||||
**Purpose:** {{gameplay_purpose}}
|
||||
**Duration:** {{target_time}}
|
||||
**Key Elements:** {{required_mechanics}}
|
||||
**Difficulty:** {{relative_difficulty}}
|
||||
|
||||
**Structure Template:**
|
||||
|
||||
- Introduction: {{intro_description}}
|
||||
- Challenge: {{main_challenge}}
|
||||
- Resolution: {{completion_requirement}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
### Level Progression
|
||||
|
||||
**World Structure:** {{linear|hub|open}}
|
||||
**Total Levels:** {{number}}
|
||||
**Unlock Pattern:** {{progression_method}}
|
||||
|
||||
## Technical Specifications
|
||||
|
||||
[[LLM: Define technical requirements that will guide architecture and implementation decisions. Review any existing technical preferences.]]
|
||||
|
||||
### Performance Requirements
|
||||
|
||||
**Frame Rate:** 60 FPS (minimum 30 FPS on low-end devices)
|
||||
**Memory Usage:** <{{memory_limit}}MB
|
||||
**Load Times:** <{{load_time}}s initial, <{{level_load}}s between levels
|
||||
**Battery Usage:** Optimized for mobile devices
|
||||
|
||||
### 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+
|
||||
|
||||
### Asset Requirements
|
||||
|
||||
[[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}}
|
||||
|
||||
## Technical Architecture Requirements
|
||||
|
||||
[[LLM: Define high-level technical requirements that the game architecture must support]]
|
||||
|
||||
### Engine Configuration
|
||||
|
||||
**Phaser 3 Setup:**
|
||||
|
||||
- TypeScript: Strict mode enabled
|
||||
- Physics: {{physics_system}} (Arcade/Matter)
|
||||
- Renderer: WebGL with Canvas fallback
|
||||
- Scale Mode: {{scale_mode}}
|
||||
|
||||
### Code Architecture
|
||||
|
||||
**Required Systems:**
|
||||
|
||||
- Scene Management
|
||||
- State Management
|
||||
- Asset Loading
|
||||
- Save/Load System
|
||||
- Input Management
|
||||
- Audio System
|
||||
- Performance Monitoring
|
||||
|
||||
### Data Management
|
||||
|
||||
**Save Data:**
|
||||
|
||||
- Progress tracking
|
||||
- Settings persistence
|
||||
- Statistics collection
|
||||
- {{additional_data}}
|
||||
|
||||
## Development Phases
|
||||
|
||||
[[LLM: Break down the development into phases that can be converted to epics]]
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
## Success Metrics
|
||||
|
||||
[[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}}%
|
||||
- Player retention: D1 {{d1}}%, D7 {{d7}}%
|
||||
|
||||
## Appendices
|
||||
|
||||
### Change Log
|
||||
|
||||
[[LLM: Track document versions and changes]]
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
### References
|
||||
|
||||
[[LLM: List any competitive analysis, inspiration, or research sources]]
|
||||
|
||||
- {{reference_1}}
|
||||
- {{reference_2}}
|
||||
- {{reference_3}}
|
||||
@@ -0,0 +1,343 @@
|
||||
template:
|
||||
id: game-design-doc-template-v2
|
||||
name: Game Design Document (GDD)
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: "docs/{{game_name}}-game-design-document.md"
|
||||
title: "{{game_title}} Game Design Document (GDD)"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
|
||||
sections:
|
||||
- id: initial-setup
|
||||
instruction: |
|
||||
This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
|
||||
|
||||
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis
|
||||
|
||||
- id: executive-summary
|
||||
title: Executive Summary
|
||||
instruction: Create a compelling overview that captures the essence of the game. Present this section first and get user feedback before proceeding.
|
||||
sections:
|
||||
- id: core-concept
|
||||
title: Core Concept
|
||||
instruction: 2-3 sentences that clearly describe what the game is and why players will love it
|
||||
- id: target-audience
|
||||
title: Target Audience
|
||||
instruction: Define the primary and secondary audience with demographics and gaming preferences
|
||||
template: |
|
||||
**Primary:** {{age_range}}, {{player_type}}, {{platform_preference}}
|
||||
**Secondary:** {{secondary_audience}}
|
||||
- id: platform-technical
|
||||
title: Platform & Technical Requirements
|
||||
instruction: Based on the technical preferences or user input, define the target platforms
|
||||
template: |
|
||||
**Primary Platform:** {{platform}}
|
||||
**Engine:** Phaser 3 + TypeScript
|
||||
**Performance Target:** 60 FPS on {{minimum_device}}
|
||||
**Screen Support:** {{resolution_range}}
|
||||
- id: unique-selling-points
|
||||
title: Unique Selling Points
|
||||
instruction: List 3-5 key features that differentiate this game from competitors
|
||||
type: numbered-list
|
||||
template: "{{usp}}"
|
||||
|
||||
- id: core-gameplay
|
||||
title: Core Gameplay
|
||||
instruction: This section defines the fundamental game mechanics. After presenting each subsection, apply `tasks#advanced-elicitation` protocol to ensure completeness.
|
||||
sections:
|
||||
- id: game-pillars
|
||||
title: Game Pillars
|
||||
instruction: Define 3-5 core pillars that guide all design decisions. These should be specific and actionable.
|
||||
type: numbered-list
|
||||
template: |
|
||||
**{{pillar_name}}** - {{description}}
|
||||
- id: core-gameplay-loop
|
||||
title: Core Gameplay Loop
|
||||
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.
|
||||
template: |
|
||||
**Primary Loop ({{duration}} seconds):**
|
||||
|
||||
1. {{action_1}} ({{time_1}}s)
|
||||
2. {{action_2}} ({{time_2}}s)
|
||||
3. {{action_3}} ({{time_3}}s)
|
||||
4. {{reward_feedback}} ({{time_4}}s)
|
||||
- id: win-loss-conditions
|
||||
title: Win/Loss Conditions
|
||||
instruction: Clearly define success and failure states
|
||||
template: |
|
||||
**Victory Conditions:**
|
||||
|
||||
- {{win_condition_1}}
|
||||
- {{win_condition_2}}
|
||||
|
||||
**Failure States:**
|
||||
|
||||
- {{loss_condition_1}}
|
||||
- {{loss_condition_2}}
|
||||
|
||||
- id: game-mechanics
|
||||
title: Game Mechanics
|
||||
instruction: Detail each major mechanic that will need to be implemented. Each mechanic should be specific enough for developers to create implementation stories.
|
||||
sections:
|
||||
- id: primary-mechanics
|
||||
title: Primary Mechanics
|
||||
repeatable: true
|
||||
sections:
|
||||
- id: mechanic
|
||||
title: "{{mechanic_name}}"
|
||||
template: |
|
||||
**Description:** {{detailed_description}}
|
||||
|
||||
**Player Input:** {{input_method}}
|
||||
|
||||
**System Response:** {{game_response}}
|
||||
|
||||
**Implementation Notes:**
|
||||
|
||||
- {{tech_requirement_1}}
|
||||
- {{tech_requirement_2}}
|
||||
- {{performance_consideration}}
|
||||
|
||||
**Dependencies:** {{other_mechanics_needed}}
|
||||
- id: controls
|
||||
title: Controls
|
||||
instruction: Define all input methods for different platforms
|
||||
type: table
|
||||
template: |
|
||||
| Action | Desktop | Mobile | Gamepad |
|
||||
| ------ | ------- | ------ | ------- |
|
||||
| {{action}} | {{key}} | {{gesture}} | {{button}} |
|
||||
|
||||
- id: progression-balance
|
||||
title: Progression & Balance
|
||||
instruction: Define how players advance and how difficulty scales. This section should provide clear parameters for implementation.
|
||||
sections:
|
||||
- id: player-progression
|
||||
title: Player Progression
|
||||
template: |
|
||||
**Progression Type:** {{linear|branching|metroidvania}}
|
||||
|
||||
**Key Milestones:**
|
||||
|
||||
1. **{{milestone_1}}** - {{unlock_description}}
|
||||
2. **{{milestone_2}}** - {{unlock_description}}
|
||||
3. **{{milestone_3}}** - {{unlock_description}}
|
||||
- id: difficulty-curve
|
||||
title: Difficulty Curve
|
||||
instruction: Provide specific parameters for balancing
|
||||
template: |
|
||||
**Tutorial Phase:** {{duration}} - {{difficulty_description}}
|
||||
**Early Game:** {{duration}} - {{difficulty_description}}
|
||||
**Mid Game:** {{duration}} - {{difficulty_description}}
|
||||
**Late Game:** {{duration}} - {{difficulty_description}}
|
||||
- id: economy-resources
|
||||
title: Economy & Resources
|
||||
condition: has_economy
|
||||
instruction: Define any in-game currencies, resources, or collectibles
|
||||
type: table
|
||||
template: |
|
||||
| Resource | Earn Rate | Spend Rate | Purpose | Cap |
|
||||
| -------- | --------- | ---------- | ------- | --- |
|
||||
| {{resource}} | {{rate}} | {{rate}} | {{use}} | {{max}} |
|
||||
|
||||
- id: level-design-framework
|
||||
title: Level Design Framework
|
||||
instruction: Provide guidelines for level creation that developers can use to create level implementation stories
|
||||
sections:
|
||||
- id: level-types
|
||||
title: Level Types
|
||||
repeatable: true
|
||||
sections:
|
||||
- id: level-type
|
||||
title: "{{level_type_name}}"
|
||||
template: |
|
||||
**Purpose:** {{gameplay_purpose}}
|
||||
**Duration:** {{target_time}}
|
||||
**Key Elements:** {{required_mechanics}}
|
||||
**Difficulty:** {{relative_difficulty}}
|
||||
|
||||
**Structure Template:**
|
||||
|
||||
- Introduction: {{intro_description}}
|
||||
- Challenge: {{main_challenge}}
|
||||
- Resolution: {{completion_requirement}}
|
||||
- id: level-progression
|
||||
title: Level Progression
|
||||
template: |
|
||||
**World Structure:** {{linear|hub|open}}
|
||||
**Total Levels:** {{number}}
|
||||
**Unlock Pattern:** {{progression_method}}
|
||||
|
||||
- id: technical-specifications
|
||||
title: Technical Specifications
|
||||
instruction: Define technical requirements that will guide architecture and implementation decisions. Review any existing technical preferences.
|
||||
sections:
|
||||
- id: performance-requirements
|
||||
title: Performance Requirements
|
||||
template: |
|
||||
**Frame Rate:** 60 FPS (minimum 30 FPS on low-end devices)
|
||||
**Memory Usage:** <{{memory_limit}}MB
|
||||
**Load Times:** <{{load_time}}s initial, <{{level_load}}s between levels
|
||||
**Battery Usage:** Optimized for mobile devices
|
||||
- id: platform-specific
|
||||
title: Platform Specific
|
||||
template: |
|
||||
**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+
|
||||
- id: asset-requirements
|
||||
title: Asset Requirements
|
||||
instruction: Define asset specifications for the art and audio teams
|
||||
template: |
|
||||
**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}}
|
||||
|
||||
- id: technical-architecture-requirements
|
||||
title: Technical Architecture Requirements
|
||||
instruction: Define high-level technical requirements that the game architecture must support
|
||||
sections:
|
||||
- id: engine-configuration
|
||||
title: Engine Configuration
|
||||
template: |
|
||||
**Phaser 3 Setup:**
|
||||
|
||||
- TypeScript: Strict mode enabled
|
||||
- Physics: {{physics_system}} (Arcade/Matter)
|
||||
- Renderer: WebGL with Canvas fallback
|
||||
- Scale Mode: {{scale_mode}}
|
||||
- id: code-architecture
|
||||
title: Code Architecture
|
||||
template: |
|
||||
**Required Systems:**
|
||||
|
||||
- Scene Management
|
||||
- State Management
|
||||
- Asset Loading
|
||||
- Save/Load System
|
||||
- Input Management
|
||||
- Audio System
|
||||
- Performance Monitoring
|
||||
- id: data-management
|
||||
title: Data Management
|
||||
template: |
|
||||
**Save Data:**
|
||||
|
||||
- Progress tracking
|
||||
- Settings persistence
|
||||
- Statistics collection
|
||||
- {{additional_data}}
|
||||
|
||||
- id: development-phases
|
||||
title: Development Phases
|
||||
instruction: Break down the development into phases that can be converted to epics
|
||||
sections:
|
||||
- id: phase-1-core-systems
|
||||
title: "Phase 1: Core Systems ({{duration}})"
|
||||
sections:
|
||||
- id: foundation-epic
|
||||
title: "Epic: Foundation"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Engine setup and configuration
|
||||
- Basic scene management
|
||||
- Core input handling
|
||||
- Asset loading pipeline
|
||||
- id: core-mechanics-epic
|
||||
title: "Epic: Core Mechanics"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- {{primary_mechanic}} implementation
|
||||
- Basic physics and collision
|
||||
- Player controller
|
||||
- id: phase-2-gameplay-features
|
||||
title: "Phase 2: Gameplay Features ({{duration}})"
|
||||
sections:
|
||||
- id: game-systems-epic
|
||||
title: "Epic: Game Systems"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- {{mechanic_2}} implementation
|
||||
- {{mechanic_3}} implementation
|
||||
- Game state management
|
||||
- id: content-creation-epic
|
||||
title: "Epic: Content Creation"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Level loading system
|
||||
- First playable levels
|
||||
- Basic UI implementation
|
||||
- id: phase-3-polish-optimization
|
||||
title: "Phase 3: Polish & Optimization ({{duration}})"
|
||||
sections:
|
||||
- id: performance-epic
|
||||
title: "Epic: Performance"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Optimization and profiling
|
||||
- Mobile platform testing
|
||||
- Memory management
|
||||
- id: user-experience-epic
|
||||
title: "Epic: User Experience"
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Audio implementation
|
||||
- Visual effects and polish
|
||||
- Final UI/UX refinement
|
||||
|
||||
- id: success-metrics
|
||||
title: Success Metrics
|
||||
instruction: Define measurable goals for the game
|
||||
sections:
|
||||
- id: technical-metrics
|
||||
title: Technical Metrics
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Frame rate: {{fps_target}}
|
||||
- Load time: {{load_target}}
|
||||
- Crash rate: <{{crash_threshold}}%
|
||||
- Memory usage: <{{memory_target}}MB
|
||||
- id: gameplay-metrics
|
||||
title: Gameplay Metrics
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Tutorial completion: {{completion_rate}}%
|
||||
- Average session: {{session_length}} minutes
|
||||
- Level completion: {{level_completion}}%
|
||||
- Player retention: D1 {{d1}}%, D7 {{d7}}%
|
||||
|
||||
- id: appendices
|
||||
title: Appendices
|
||||
sections:
|
||||
- id: change-log
|
||||
title: Change Log
|
||||
instruction: Track document versions and changes
|
||||
type: table
|
||||
template: |
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
- id: references
|
||||
title: References
|
||||
instruction: List any competitive analysis, inspiration, or research sources
|
||||
type: bullet-list
|
||||
template: "{{reference}}"
|
||||
@@ -1,235 +0,0 @@
|
||||
# Story: {{Story Title}}
|
||||
|
||||
**Epic:** {{Epic Name}}
|
||||
**Story ID:** {{ID}}
|
||||
**Priority:** {{High|Medium|Low}}
|
||||
**Points:** {{Story Points}}
|
||||
**Status:** Draft
|
||||
|
||||
[[LLM: This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
|
||||
|
||||
Before starting, ensure you have access to:
|
||||
|
||||
- Game Design Document (GDD)
|
||||
- Game Architecture Document
|
||||
- Any existing stories in this epic
|
||||
|
||||
The story should be specific enough that a developer can implement it without requiring additional design decisions.]]
|
||||
|
||||
## Description
|
||||
|
||||
[[LLM: Provide a clear, concise description of what this story implements. Focus on the specific game feature or system being built. Reference the GDD section that defines this feature.]]
|
||||
|
||||
{{clear_description_of_what_needs_to_be_implemented}}
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
[[LLM: Define specific, testable conditions that must be met for the story to be considered complete. Each criterion should be verifiable and directly related to gameplay functionality.]]
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- [ ] {{specific_functional_requirement_1}}
|
||||
- [ ] {{specific_functional_requirement_2}}
|
||||
- [ ] {{specific_functional_requirement_3}}
|
||||
|
||||
### Technical Requirements
|
||||
|
||||
- [ ] Code follows TypeScript strict mode standards
|
||||
- [ ] Maintains 60 FPS on target devices
|
||||
- [ ] No memory leaks or performance degradation
|
||||
- [ ] {{specific_technical_requirement}}
|
||||
|
||||
### Game Design Requirements
|
||||
|
||||
- [ ] {{gameplay_requirement_from_gdd}}
|
||||
- [ ] {{balance_requirement_if_applicable}}
|
||||
- [ ] {{player_experience_requirement}}
|
||||
|
||||
## Technical Specifications
|
||||
|
||||
[[LLM: Provide specific technical details that guide implementation. Include class names, file locations, and integration points based on the game architecture.]]
|
||||
|
||||
### Files to Create/Modify
|
||||
|
||||
**New Files:**
|
||||
|
||||
- `{{file_path_1}}` - {{purpose}}
|
||||
- `{{file_path_2}}` - {{purpose}}
|
||||
|
||||
**Modified Files:**
|
||||
|
||||
- `{{existing_file_1}}` - {{changes_needed}}
|
||||
- `{{existing_file_2}}` - {{changes_needed}}
|
||||
|
||||
### Class/Interface Definitions
|
||||
|
||||
[[LLM: Define specific TypeScript interfaces and class structures needed]]
|
||||
|
||||
```typescript
|
||||
// {{interface_name}}
|
||||
interface {{InterfaceName}} {
|
||||
{{property_1}}: {{type}};
|
||||
{{property_2}}: {{type}};
|
||||
{{method_1}}({{params}}): {{return_type}};
|
||||
}
|
||||
|
||||
// {{class_name}}
|
||||
class {{ClassName}} extends {{PhaseClass}} {
|
||||
private {{property}}: {{type}};
|
||||
|
||||
constructor({{params}}) {
|
||||
// Implementation requirements
|
||||
}
|
||||
|
||||
public {{method}}({{params}}): {{return_type}} {
|
||||
// Method requirements
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Integration Points
|
||||
|
||||
[[LLM: Specify how this feature integrates with existing systems]]
|
||||
|
||||
**Scene Integration:**
|
||||
|
||||
- {{scene_name}}: {{integration_details}}
|
||||
|
||||
**System Dependencies:**
|
||||
|
||||
- {{system_name}}: {{dependency_description}}
|
||||
|
||||
**Event Communication:**
|
||||
|
||||
- Emits: `{{event_name}}` when {{condition}}
|
||||
- Listens: `{{event_name}}` to {{response}}
|
||||
|
||||
## Implementation Tasks
|
||||
|
||||
[[LLM: Break down the implementation into specific, ordered tasks. Each task should be completable in 1-4 hours.]]
|
||||
|
||||
### Dev Agent Record
|
||||
|
||||
**Tasks:**
|
||||
|
||||
- [ ] {{task_1_description}}
|
||||
- [ ] {{task_2_description}}
|
||||
- [ ] {{task_3_description}}
|
||||
- [ ] {{task_4_description}}
|
||||
- [ ] Write unit tests for {{component}}
|
||||
- [ ] Integration testing with {{related_system}}
|
||||
- [ ] Performance testing and optimization
|
||||
|
||||
**Debug Log:**
|
||||
| Task | File | Change | Reverted? |
|
||||
|------|------|--------|-----------|
|
||||
| | | | |
|
||||
|
||||
**Completion Notes:**
|
||||
|
||||
<!-- Only note deviations from requirements, keep under 50 words -->
|
||||
|
||||
**Change Log:**
|
||||
|
||||
<!-- Only requirement changes during implementation -->
|
||||
|
||||
## Game Design Context
|
||||
|
||||
[[LLM: Reference the specific sections of the GDD that this story implements]]
|
||||
|
||||
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
|
||||
|
||||
**Game Mechanic:** {{mechanic_name}}
|
||||
|
||||
**Player Experience Goal:** {{experience_description}}
|
||||
|
||||
**Balance Parameters:**
|
||||
|
||||
- {{parameter_1}}: {{value_or_range}}
|
||||
- {{parameter_2}}: {{value_or_range}}
|
||||
|
||||
## Testing Requirements
|
||||
|
||||
[[LLM: Define specific testing criteria for this game feature]]
|
||||
|
||||
### Unit Tests
|
||||
|
||||
**Test Files:**
|
||||
|
||||
- `tests/{{component_name}}.test.ts`
|
||||
|
||||
**Test Scenarios:**
|
||||
|
||||
- {{test_scenario_1}}
|
||||
- {{test_scenario_2}}
|
||||
- {{edge_case_test}}
|
||||
|
||||
### Game Testing
|
||||
|
||||
**Manual Test Cases:**
|
||||
|
||||
1. {{test_case_1_description}}
|
||||
|
||||
- Expected: {{expected_behavior}}
|
||||
- Performance: {{performance_expectation}}
|
||||
|
||||
2. {{test_case_2_description}}
|
||||
- Expected: {{expected_behavior}}
|
||||
- Edge Case: {{edge_case_handling}}
|
||||
|
||||
### Performance Tests
|
||||
|
||||
**Metrics to Verify:**
|
||||
|
||||
- Frame rate maintains {{fps_target}} FPS
|
||||
- Memory usage stays under {{memory_limit}}MB
|
||||
- {{feature_specific_performance_metric}}
|
||||
|
||||
## Dependencies
|
||||
|
||||
[[LLM: List any dependencies that must be completed before this story can be implemented]]
|
||||
|
||||
**Story Dependencies:**
|
||||
|
||||
- {{story_id}}: {{dependency_description}}
|
||||
|
||||
**Technical Dependencies:**
|
||||
|
||||
- {{system_or_file}}: {{requirement}}
|
||||
|
||||
**Asset Dependencies:**
|
||||
|
||||
- {{asset_type}}: {{asset_description}}
|
||||
- Location: `{{asset_path}}`
|
||||
|
||||
## Definition of Done
|
||||
|
||||
[[LLM: Checklist that must be completed before the story is considered finished]]
|
||||
|
||||
- [ ] All acceptance criteria met
|
||||
- [ ] Code reviewed and approved
|
||||
- [ ] Unit tests written and passing
|
||||
- [ ] Integration tests passing
|
||||
- [ ] Performance targets met
|
||||
- [ ] No linting errors
|
||||
- [ ] Documentation updated
|
||||
- [ ] {{game_specific_dod_item}}
|
||||
|
||||
## Notes
|
||||
|
||||
[[LLM: Any additional context, design decisions, or implementation notes]]
|
||||
|
||||
**Implementation Notes:**
|
||||
|
||||
- {{note_1}}
|
||||
- {{note_2}}
|
||||
|
||||
**Design Decisions:**
|
||||
|
||||
- {{decision_1}}: {{rationale}}
|
||||
- {{decision_2}}: {{rationale}}
|
||||
|
||||
**Future Considerations:**
|
||||
|
||||
- {{future_enhancement_1}}
|
||||
- {{future_optimization_1}}
|
||||
@@ -0,0 +1,253 @@
|
||||
template:
|
||||
id: game-story-template-v2
|
||||
name: Game Development Story
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: "stories/{{epic_name}}/{{story_id}}-{{story_name}}.md"
|
||||
title: "Story: {{story_title}}"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
|
||||
sections:
|
||||
- id: initial-setup
|
||||
instruction: |
|
||||
This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
|
||||
|
||||
Before starting, ensure you have access to:
|
||||
|
||||
- Game Design Document (GDD)
|
||||
- Game Architecture Document
|
||||
- Any existing stories in this epic
|
||||
|
||||
The story should be specific enough that a developer can implement it without requiring additional design decisions.
|
||||
|
||||
- id: story-header
|
||||
content: |
|
||||
**Epic:** {{epic_name}}
|
||||
**Story ID:** {{story_id}}
|
||||
**Priority:** {{High|Medium|Low}}
|
||||
**Points:** {{story_points}}
|
||||
**Status:** Draft
|
||||
|
||||
- id: description
|
||||
title: Description
|
||||
instruction: Provide a clear, concise description of what this story implements. Focus on the specific game feature or system being built. Reference the GDD section that defines this feature.
|
||||
template: "{{clear_description_of_what_needs_to_be_implemented}}"
|
||||
|
||||
- id: acceptance-criteria
|
||||
title: Acceptance Criteria
|
||||
instruction: Define specific, testable conditions that must be met for the story to be considered complete. Each criterion should be verifiable and directly related to gameplay functionality.
|
||||
sections:
|
||||
- id: functional-requirements
|
||||
title: Functional Requirements
|
||||
type: checklist
|
||||
items:
|
||||
- "{{specific_functional_requirement}}"
|
||||
- id: technical-requirements
|
||||
title: Technical Requirements
|
||||
type: checklist
|
||||
items:
|
||||
- "Code follows TypeScript strict mode standards"
|
||||
- "Maintains 60 FPS on target devices"
|
||||
- "No memory leaks or performance degradation"
|
||||
- "{{specific_technical_requirement}}"
|
||||
- id: game-design-requirements
|
||||
title: Game Design Requirements
|
||||
type: checklist
|
||||
items:
|
||||
- "{{gameplay_requirement_from_gdd}}"
|
||||
- "{{balance_requirement_if_applicable}}"
|
||||
- "{{player_experience_requirement}}"
|
||||
|
||||
- id: technical-specifications
|
||||
title: Technical Specifications
|
||||
instruction: Provide specific technical details that guide implementation. Include class names, file locations, and integration points based on the game architecture.
|
||||
sections:
|
||||
- id: files-to-modify
|
||||
title: Files to Create/Modify
|
||||
template: |
|
||||
**New Files:**
|
||||
|
||||
- `{{file_path_1}}` - {{purpose}}
|
||||
- `{{file_path_2}}` - {{purpose}}
|
||||
|
||||
**Modified Files:**
|
||||
|
||||
- `{{existing_file_1}}` - {{changes_needed}}
|
||||
- `{{existing_file_2}}` - {{changes_needed}}
|
||||
- id: class-interface-definitions
|
||||
title: Class/Interface Definitions
|
||||
instruction: Define specific TypeScript interfaces and class structures needed
|
||||
type: code
|
||||
language: typescript
|
||||
template: |
|
||||
// {{interface_name}}
|
||||
interface {{interface_name}} {
|
||||
{{property_1}}: {{type}};
|
||||
{{property_2}}: {{type}};
|
||||
{{method_1}}({{params}}): {{return_type}};
|
||||
}
|
||||
|
||||
// {{class_name}}
|
||||
class {{class_name}} extends {{phaser_class}} {
|
||||
private {{property}}: {{type}};
|
||||
|
||||
constructor({{params}}) {
|
||||
// Implementation requirements
|
||||
}
|
||||
|
||||
public {{method}}({{params}}): {{return_type}} {
|
||||
// Method requirements
|
||||
}
|
||||
}
|
||||
- id: integration-points
|
||||
title: Integration Points
|
||||
instruction: Specify how this feature integrates with existing systems
|
||||
template: |
|
||||
**Scene Integration:**
|
||||
|
||||
- {{scene_name}}: {{integration_details}}
|
||||
|
||||
**System Dependencies:**
|
||||
|
||||
- {{system_name}}: {{dependency_description}}
|
||||
|
||||
**Event Communication:**
|
||||
|
||||
- Emits: `{{event_name}}` when {{condition}}
|
||||
- Listens: `{{event_name}}` to {{response}}
|
||||
|
||||
- id: implementation-tasks
|
||||
title: Implementation Tasks
|
||||
instruction: Break down the implementation into specific, ordered tasks. Each task should be completable in 1-4 hours.
|
||||
sections:
|
||||
- id: dev-agent-record
|
||||
title: Dev Agent Record
|
||||
template: |
|
||||
**Tasks:**
|
||||
|
||||
- [ ] {{task_1_description}}
|
||||
- [ ] {{task_2_description}}
|
||||
- [ ] {{task_3_description}}
|
||||
- [ ] {{task_4_description}}
|
||||
- [ ] Write unit tests for {{component}}
|
||||
- [ ] Integration testing with {{related_system}}
|
||||
- [ ] Performance testing and optimization
|
||||
|
||||
**Debug Log:**
|
||||
| Task | File | Change | Reverted? |
|
||||
|------|------|--------|-----------|
|
||||
| | | | |
|
||||
|
||||
**Completion Notes:**
|
||||
|
||||
<!-- Only note deviations from requirements, keep under 50 words -->
|
||||
|
||||
**Change Log:**
|
||||
|
||||
<!-- Only requirement changes during implementation -->
|
||||
|
||||
- id: game-design-context
|
||||
title: Game Design Context
|
||||
instruction: Reference the specific sections of the GDD that this story implements
|
||||
template: |
|
||||
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
|
||||
|
||||
**Game Mechanic:** {{mechanic_name}}
|
||||
|
||||
**Player Experience Goal:** {{experience_description}}
|
||||
|
||||
**Balance Parameters:**
|
||||
|
||||
- {{parameter_1}}: {{value_or_range}}
|
||||
- {{parameter_2}}: {{value_or_range}}
|
||||
|
||||
- id: testing-requirements
|
||||
title: Testing Requirements
|
||||
instruction: Define specific testing criteria for this game feature
|
||||
sections:
|
||||
- id: unit-tests
|
||||
title: Unit Tests
|
||||
template: |
|
||||
**Test Files:**
|
||||
|
||||
- `tests/{{component_name}}.test.ts`
|
||||
|
||||
**Test Scenarios:**
|
||||
|
||||
- {{test_scenario_1}}
|
||||
- {{test_scenario_2}}
|
||||
- {{edge_case_test}}
|
||||
- id: game-testing
|
||||
title: Game Testing
|
||||
template: |
|
||||
**Manual Test Cases:**
|
||||
|
||||
1. {{test_case_1_description}}
|
||||
|
||||
- Expected: {{expected_behavior}}
|
||||
- Performance: {{performance_expectation}}
|
||||
|
||||
2. {{test_case_2_description}}
|
||||
- Expected: {{expected_behavior}}
|
||||
- Edge Case: {{edge_case_handling}}
|
||||
- id: performance-tests
|
||||
title: Performance Tests
|
||||
template: |
|
||||
**Metrics to Verify:**
|
||||
|
||||
- Frame rate maintains {{fps_target}} FPS
|
||||
- Memory usage stays under {{memory_limit}}MB
|
||||
- {{feature_specific_performance_metric}}
|
||||
|
||||
- id: dependencies
|
||||
title: Dependencies
|
||||
instruction: List any dependencies that must be completed before this story can be implemented
|
||||
template: |
|
||||
**Story Dependencies:**
|
||||
|
||||
- {{story_id}}: {{dependency_description}}
|
||||
|
||||
**Technical Dependencies:**
|
||||
|
||||
- {{system_or_file}}: {{requirement}}
|
||||
|
||||
**Asset Dependencies:**
|
||||
|
||||
- {{asset_type}}: {{asset_description}}
|
||||
- Location: `{{asset_path}}`
|
||||
|
||||
- id: definition-of-done
|
||||
title: Definition of Done
|
||||
instruction: Checklist that must be completed before the story is considered finished
|
||||
type: checklist
|
||||
items:
|
||||
- "All acceptance criteria met"
|
||||
- "Code reviewed and approved"
|
||||
- "Unit tests written and passing"
|
||||
- "Integration tests passing"
|
||||
- "Performance targets met"
|
||||
- "No linting errors"
|
||||
- "Documentation updated"
|
||||
- "{{game_specific_dod_item}}"
|
||||
|
||||
- id: notes
|
||||
title: Notes
|
||||
instruction: Any additional context, design decisions, or implementation notes
|
||||
template: |
|
||||
**Implementation Notes:**
|
||||
|
||||
- {{note_1}}
|
||||
- {{note_2}}
|
||||
|
||||
**Design Decisions:**
|
||||
|
||||
- {{decision_1}}: {{rationale}}
|
||||
- {{decision_2}}: {{rationale}}
|
||||
|
||||
**Future Considerations:**
|
||||
|
||||
- {{future_enhancement_1}}
|
||||
- {{future_optimization_1}}
|
||||
@@ -1,470 +0,0 @@
|
||||
# {{Game Title}} Level Design Document
|
||||
|
||||
[[LLM: This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels.
|
||||
|
||||
If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents.]]
|
||||
|
||||
## Introduction
|
||||
|
||||
[[LLM: Establish the purpose and scope of level design for this game]]
|
||||
|
||||
This document defines the level design framework for {{Game Title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document.
|
||||
|
||||
This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints.
|
||||
|
||||
### Change Log
|
||||
|
||||
[[LLM: Track document versions and changes]]
|
||||
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
## Level Design Philosophy
|
||||
|
||||
[[LLM: Establish the overall approach to level design based on the game's core pillars and mechanics. Apply `tasks#advanced-elicitation` after presenting this section.]]
|
||||
|
||||
### Design Principles
|
||||
|
||||
[[LLM: Define 3-5 core principles that guide all level design decisions]]
|
||||
|
||||
1. **{{principle_1}}** - {{description}}
|
||||
2. **{{principle_2}}** - {{description}}
|
||||
3. **{{principle_3}}** - {{description}}
|
||||
|
||||
### Player Experience Goals
|
||||
|
||||
[[LLM: Define what players should feel and learn in each level category]]
|
||||
|
||||
**Tutorial Levels:** {{experience_description}}
|
||||
**Standard Levels:** {{experience_description}}
|
||||
**Challenge Levels:** {{experience_description}}
|
||||
**Boss Levels:** {{experience_description}}
|
||||
|
||||
### Level Flow Framework
|
||||
|
||||
[[LLM: Define the standard structure for level progression]]
|
||||
|
||||
**Introduction Phase:** {{duration}} - {{purpose}}
|
||||
**Development Phase:** {{duration}} - {{purpose}}
|
||||
**Climax Phase:** {{duration}} - {{purpose}}
|
||||
**Resolution Phase:** {{duration}} - {{purpose}}
|
||||
|
||||
## Level Categories
|
||||
|
||||
[[LLM: Define different types of levels based on the GDD requirements. Each category should be specific enough for implementation.]]
|
||||
|
||||
<<REPEAT section="level_category" count="based_on_gdd">>
|
||||
|
||||
### {{category_name}} Levels
|
||||
|
||||
**Purpose:** {{gameplay_purpose}}
|
||||
|
||||
**Target Duration:** {{min_time}} - {{max_time}} minutes
|
||||
|
||||
**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
|
||||
- Asset requirements: {{asset_needs}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
## Level Progression System
|
||||
|
||||
[[LLM: Define how players move through levels and how difficulty scales]]
|
||||
|
||||
### World Structure
|
||||
|
||||
[[LLM: Based on GDD requirements, define the overall level organization]]
|
||||
|
||||
**Organization Type:** {{linear|hub_world|open_world}}
|
||||
|
||||
**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}}
|
||||
|
||||
### Difficulty Progression
|
||||
|
||||
[[LLM: Define how challenge increases across the game]]
|
||||
|
||||
**Progression Curve:**
|
||||
|
||||
````text
|
||||
Difficulty
|
||||
^ ___/```
|
||||
| /
|
||||
| / ___/```
|
||||
| / /
|
||||
| / /
|
||||
|/ /
|
||||
+-----------> Level Number
|
||||
Tutorial Early Mid Late
|
||||
````
|
||||
|
||||
**Scaling Parameters:**
|
||||
|
||||
- Enemy count: {{start_count}} → {{end_count}}
|
||||
- Enemy difficulty: {{start_diff}} → {{end_diff}}
|
||||
- Level complexity: {{start_complex}} → {{end_complex}}
|
||||
- Time pressure: {{start_time}} → {{end_time}}
|
||||
|
||||
### Unlock Requirements
|
||||
|
||||
[[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}}
|
||||
- Optional content: {{unlock_condition}}
|
||||
|
||||
## Level Design Components
|
||||
|
||||
[[LLM: Define the building blocks used to create levels]]
|
||||
|
||||
### Environmental Elements
|
||||
|
||||
[[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}}
|
||||
|
||||
### Collectibles and Rewards
|
||||
|
||||
[[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}}%
|
||||
|
||||
### Enemy Placement Framework
|
||||
|
||||
[[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}}
|
||||
|
||||
## Level Creation Guidelines
|
||||
|
||||
[[LLM: Provide specific guidelines for creating individual levels]]
|
||||
|
||||
### 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}}
|
||||
- Multiple path options: {{branching_rules}}
|
||||
|
||||
### Pacing and Flow
|
||||
|
||||
[[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}}
|
||||
|
||||
### Challenge Design
|
||||
|
||||
[[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}}
|
||||
|
||||
## Technical Implementation
|
||||
|
||||
[[LLM: Define technical requirements for level implementation]]
|
||||
|
||||
### Level Data Structure
|
||||
|
||||
[[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}}",
|
||||
"worldId": "{{world_identifier}}",
|
||||
"difficulty": {{difficulty_value}},
|
||||
"targetTime": {{completion_time_seconds}},
|
||||
"objectives": {
|
||||
"primary": "{{primary_objective}}",
|
||||
"secondary": ["{{secondary_objectives}}"],
|
||||
"hidden": ["{{secret_objectives}}"]
|
||||
},
|
||||
"layout": {
|
||||
"width": {{grid_width}},
|
||||
"height": {{grid_height}},
|
||||
"tilemap": "{{tilemap_reference}}"
|
||||
},
|
||||
"entities": [
|
||||
{
|
||||
"type": "{{entity_type}}",
|
||||
"position": {"x": {{x}}, "y": {{y}}},
|
||||
"properties": {{entity_properties}}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Asset Integration
|
||||
|
||||
[[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}}
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
[[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}}
|
||||
|
||||
## Level Testing Framework
|
||||
|
||||
[[LLM: Define how levels should be tested and validated]]
|
||||
|
||||
### 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
|
||||
|
||||
### Manual Testing Protocol
|
||||
|
||||
**Playtesting Checklist:**
|
||||
|
||||
- [ ] Level completes within target time range
|
||||
- [ ] All mechanics function correctly
|
||||
- [ ] Difficulty feels appropriate for level category
|
||||
- [ ] Player guidance is clear and effective
|
||||
- [ ] No exploits or sequence breaks (unless intended)
|
||||
|
||||
**Player Experience Testing:**
|
||||
|
||||
- [ ] Tutorial levels teach effectively
|
||||
- [ ] Challenge feels fair and rewarding
|
||||
- [ ] Flow and pacing maintain engagement
|
||||
- [ ] Audio and visual feedback support gameplay
|
||||
|
||||
### 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}}
|
||||
|
||||
## Content Creation Pipeline
|
||||
|
||||
[[LLM: Define the workflow for creating new levels]]
|
||||
|
||||
### 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
|
||||
- Asset requirement list
|
||||
|
||||
### Implementation Phase
|
||||
|
||||
**Technical Implementation:**
|
||||
|
||||
1. Create level data file
|
||||
2. Build tilemap and layout
|
||||
3. Place entities and objects
|
||||
4. Configure level logic and triggers
|
||||
5. Integrate audio and visual effects
|
||||
|
||||
**Quality Assurance:**
|
||||
|
||||
1. Automated testing execution
|
||||
2. Internal playtesting
|
||||
3. Performance validation
|
||||
4. Bug fixing and polish
|
||||
|
||||
### 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
|
||||
4. Final approval and release
|
||||
|
||||
## Success Metrics
|
||||
|
||||
[[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}}
|
||||
- Content accessibility: {{accessibility_rate}}%
|
||||
@@ -0,0 +1,484 @@
|
||||
template:
|
||||
id: level-design-doc-template-v2
|
||||
name: Level Design Document
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: "docs/{{game_name}}-level-design-document.md"
|
||||
title: "{{game_title}} Level Design Document"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
|
||||
sections:
|
||||
- id: initial-setup
|
||||
instruction: |
|
||||
This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels.
|
||||
|
||||
If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents.
|
||||
|
||||
- id: introduction
|
||||
title: Introduction
|
||||
instruction: Establish the purpose and scope of level design for this game
|
||||
content: |
|
||||
This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document.
|
||||
|
||||
This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints.
|
||||
sections:
|
||||
- id: change-log
|
||||
title: Change Log
|
||||
instruction: Track document versions and changes
|
||||
type: table
|
||||
template: |
|
||||
| Date | Version | Description | Author |
|
||||
| :--- | :------ | :---------- | :----- |
|
||||
|
||||
- id: level-design-philosophy
|
||||
title: Level Design Philosophy
|
||||
instruction: Establish the overall approach to level design based on the game's core pillars and mechanics. Apply `tasks#advanced-elicitation` after presenting this section.
|
||||
sections:
|
||||
- id: design-principles
|
||||
title: Design Principles
|
||||
instruction: Define 3-5 core principles that guide all level design decisions
|
||||
type: numbered-list
|
||||
template: |
|
||||
**{{principle_name}}** - {{description}}
|
||||
- id: player-experience-goals
|
||||
title: Player Experience Goals
|
||||
instruction: Define what players should feel and learn in each level category
|
||||
template: |
|
||||
**Tutorial Levels:** {{experience_description}}
|
||||
**Standard Levels:** {{experience_description}}
|
||||
**Challenge Levels:** {{experience_description}}
|
||||
**Boss Levels:** {{experience_description}}
|
||||
- id: level-flow-framework
|
||||
title: Level Flow Framework
|
||||
instruction: Define the standard structure for level progression
|
||||
template: |
|
||||
**Introduction Phase:** {{duration}} - {{purpose}}
|
||||
**Development Phase:** {{duration}} - {{purpose}}
|
||||
**Climax Phase:** {{duration}} - {{purpose}}
|
||||
**Resolution Phase:** {{duration}} - {{purpose}}
|
||||
|
||||
- id: level-categories
|
||||
title: Level Categories
|
||||
instruction: Define different types of levels based on the GDD requirements. Each category should be specific enough for implementation.
|
||||
repeatable: true
|
||||
sections:
|
||||
- id: level-category
|
||||
title: "{{category_name}} Levels"
|
||||
template: |
|
||||
**Purpose:** {{gameplay_purpose}}
|
||||
|
||||
**Target Duration:** {{min_time}} - {{max_time}} minutes
|
||||
|
||||
**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
|
||||
- Asset requirements: {{asset_needs}}
|
||||
|
||||
- id: level-progression-system
|
||||
title: Level Progression System
|
||||
instruction: Define how players move through levels and how difficulty scales
|
||||
sections:
|
||||
- id: world-structure
|
||||
title: World Structure
|
||||
instruction: Based on GDD requirements, define the overall level organization
|
||||
template: |
|
||||
**Organization Type:** {{linear|hub_world|open_world}}
|
||||
|
||||
**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}}
|
||||
- id: difficulty-progression
|
||||
title: Difficulty Progression
|
||||
instruction: Define how challenge increases across the game
|
||||
sections:
|
||||
- id: progression-curve
|
||||
title: Progression Curve
|
||||
type: code
|
||||
language: text
|
||||
template: |
|
||||
Difficulty
|
||||
^ ___/```
|
||||
| /
|
||||
| / ___/```
|
||||
| / /
|
||||
| / /
|
||||
|/ /
|
||||
+-----------> Level Number
|
||||
Tutorial Early Mid Late
|
||||
- id: scaling-parameters
|
||||
title: Scaling Parameters
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Enemy count: {{start_count}} → {{end_count}}
|
||||
- Enemy difficulty: {{start_diff}} → {{end_diff}}
|
||||
- Level complexity: {{start_complex}} → {{end_complex}}
|
||||
- Time pressure: {{start_time}} → {{end_time}}
|
||||
- id: unlock-requirements
|
||||
title: Unlock Requirements
|
||||
instruction: Define how players access new levels
|
||||
template: |
|
||||
**Progression Gates:**
|
||||
|
||||
- Linear progression: Complete previous level
|
||||
- Star requirements: {{star_count}} stars to unlock
|
||||
- Skill gates: Demonstrate {{skill_requirement}}
|
||||
- Optional content: {{unlock_condition}}
|
||||
|
||||
- id: level-design-components
|
||||
title: Level Design Components
|
||||
instruction: Define the building blocks used to create levels
|
||||
sections:
|
||||
- id: environmental-elements
|
||||
title: Environmental Elements
|
||||
instruction: Define all environmental components that can be used in levels
|
||||
template: |
|
||||
**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}}
|
||||
- id: collectibles-rewards
|
||||
title: Collectibles and Rewards
|
||||
instruction: Define all collectible items and their placement rules
|
||||
template: |
|
||||
**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}}%
|
||||
- id: enemy-placement-framework
|
||||
title: Enemy Placement Framework
|
||||
instruction: Define how enemies should be placed and balanced in levels
|
||||
template: |
|
||||
**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}}
|
||||
|
||||
- id: level-creation-guidelines
|
||||
title: Level Creation Guidelines
|
||||
instruction: Provide specific guidelines for creating individual levels
|
||||
sections:
|
||||
- id: level-layout-principles
|
||||
title: Level Layout Principles
|
||||
template: |
|
||||
**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}}
|
||||
- Multiple path options: {{branching_rules}}
|
||||
- id: pacing-and-flow
|
||||
title: Pacing and Flow
|
||||
instruction: Define how to control the rhythm and pace of gameplay within levels
|
||||
template: |
|
||||
**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}}
|
||||
- id: challenge-design
|
||||
title: Challenge Design
|
||||
instruction: Define how to create appropriate challenges for each level type
|
||||
template: |
|
||||
**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}}
|
||||
|
||||
- id: technical-implementation
|
||||
title: Technical Implementation
|
||||
instruction: Define technical requirements for level implementation
|
||||
sections:
|
||||
- id: level-data-structure
|
||||
title: Level Data Structure
|
||||
instruction: Define how level data should be structured for implementation
|
||||
template: |
|
||||
**Level File Format:**
|
||||
|
||||
- Data format: {{json|yaml|custom}}
|
||||
- File naming: `level_{{world}}_{{number}}.{{extension}}`
|
||||
- Data organization: {{structure_description}}
|
||||
sections:
|
||||
- id: required-data-fields
|
||||
title: Required Data Fields
|
||||
type: code
|
||||
language: json
|
||||
template: |
|
||||
{
|
||||
"levelId": "{{unique_identifier}}",
|
||||
"worldId": "{{world_identifier}}",
|
||||
"difficulty": {{difficulty_value}},
|
||||
"targetTime": {{completion_time_seconds}},
|
||||
"objectives": {
|
||||
"primary": "{{primary_objective}}",
|
||||
"secondary": ["{{secondary_objectives}}"],
|
||||
"hidden": ["{{secret_objectives}}"]
|
||||
},
|
||||
"layout": {
|
||||
"width": {{grid_width}},
|
||||
"height": {{grid_height}},
|
||||
"tilemap": "{{tilemap_reference}}"
|
||||
},
|
||||
"entities": [
|
||||
{
|
||||
"type": "{{entity_type}}",
|
||||
"position": {"x": {{x}}, "y": {{y}}},
|
||||
"properties": {{entity_properties}}
|
||||
}
|
||||
]
|
||||
}
|
||||
- id: asset-integration
|
||||
title: Asset Integration
|
||||
instruction: Define how level assets are organized and loaded
|
||||
template: |
|
||||
**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}}
|
||||
- id: performance-optimization
|
||||
title: Performance Optimization
|
||||
instruction: Define performance requirements for level systems
|
||||
template: |
|
||||
**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}}
|
||||
|
||||
- id: level-testing-framework
|
||||
title: Level Testing Framework
|
||||
instruction: Define how levels should be tested and validated
|
||||
sections:
|
||||
- id: automated-testing
|
||||
title: Automated Testing
|
||||
template: |
|
||||
**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
|
||||
- id: manual-testing-protocol
|
||||
title: Manual Testing Protocol
|
||||
sections:
|
||||
- id: playtesting-checklist
|
||||
title: Playtesting Checklist
|
||||
type: checklist
|
||||
items:
|
||||
- "Level completes within target time range"
|
||||
- "All mechanics function correctly"
|
||||
- "Difficulty feels appropriate for level category"
|
||||
- "Player guidance is clear and effective"
|
||||
- "No exploits or sequence breaks (unless intended)"
|
||||
- id: player-experience-testing
|
||||
title: Player Experience Testing
|
||||
type: checklist
|
||||
items:
|
||||
- "Tutorial levels teach effectively"
|
||||
- "Challenge feels fair and rewarding"
|
||||
- "Flow and pacing maintain engagement"
|
||||
- "Audio and visual feedback support gameplay"
|
||||
- id: balance-validation
|
||||
title: Balance Validation
|
||||
template: |
|
||||
**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}}
|
||||
|
||||
- id: content-creation-pipeline
|
||||
title: Content Creation Pipeline
|
||||
instruction: Define the workflow for creating new levels
|
||||
sections:
|
||||
- id: design-phase
|
||||
title: Design Phase
|
||||
template: |
|
||||
**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
|
||||
- Asset requirement list
|
||||
- id: implementation-phase
|
||||
title: Implementation Phase
|
||||
template: |
|
||||
**Technical Implementation:**
|
||||
|
||||
1. Create level data file
|
||||
2. Build tilemap and layout
|
||||
3. Place entities and objects
|
||||
4. Configure level logic and triggers
|
||||
5. Integrate audio and visual effects
|
||||
|
||||
**Quality Assurance:**
|
||||
|
||||
1. Automated testing execution
|
||||
2. Internal playtesting
|
||||
3. Performance validation
|
||||
4. Bug fixing and polish
|
||||
- id: integration-phase
|
||||
title: Integration Phase
|
||||
template: |
|
||||
**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
|
||||
4. Final approval and release
|
||||
|
||||
- id: success-metrics
|
||||
title: Success Metrics
|
||||
instruction: Define how to measure level design success
|
||||
sections:
|
||||
- id: player-engagement
|
||||
title: Player Engagement
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Level completion rate: {{target_rate}}%
|
||||
- Replay rate: {{replay_target}}%
|
||||
- Time spent per level: {{engagement_time}}
|
||||
- Player satisfaction scores: {{satisfaction_target}}/10
|
||||
- id: technical-performance
|
||||
title: Technical Performance
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Frame rate consistency: {{fps_consistency}}%
|
||||
- Loading time compliance: {{load_compliance}}%
|
||||
- Memory usage efficiency: {{memory_efficiency}}%
|
||||
- Crash rate: <{{crash_threshold}}%
|
||||
- id: design-quality
|
||||
title: Design Quality
|
||||
type: bullet-list
|
||||
template: |
|
||||
- Difficulty curve adherence: {{curve_accuracy}}
|
||||
- Mechanic integration effectiveness: {{integration_score}}
|
||||
- Player guidance clarity: {{guidance_score}}
|
||||
- Content accessibility: {{accessibility_rate}}%
|
||||
@@ -3,6 +3,9 @@
|
||||
CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
||||
|
||||
```yaml
|
||||
root: .bmad-creator-tools
|
||||
IDE-FILE-RESOLUTION: Dependencies map to files as {root}/{type}/{name} where root=".bmad-core", type=folder (tasks/templates/checklists/utils), name=dependency name.
|
||||
REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), or ask for clarification if ambiguous.
|
||||
activation-instructions:
|
||||
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
||||
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
||||
@@ -42,11 +45,11 @@ commands:
|
||||
- '*exit" - Say goodbye as The Creator, and then abandon inhabiting this persona'
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-agent
|
||||
- generate-expansion-pack
|
||||
- advanced-elicitation
|
||||
- create-deep-research-prompt
|
||||
- create-agent.md
|
||||
- generate-expansion-pack.md
|
||||
- advanced-elicitation.md
|
||||
- create-deep-research-prompt.md
|
||||
templates:
|
||||
- agent-tmpl
|
||||
- expansion-pack-plan-tmpl
|
||||
- agent-tmpl.yaml
|
||||
- expansion-pack-plan-tmpl.yaml
|
||||
```
|
||||
|
||||
@@ -1,154 +0,0 @@
|
||||
# Agent Team Configuration Template
|
||||
|
||||
[[LLM: This template is for creating agent team configurations in YAML format. Follow the structure carefully and replace all placeholders with appropriate values. The team name should reflect the team's purpose and domain focus.]]
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
name: {{team-display-name}}
|
||||
[[LLM: Use format "Team [Descriptor]" for generic teams or "[Domain] Team" for specialized teams. Examples: "Team Fullstack", "Healthcare Team", "Legal Team"]]
|
||||
|
||||
icon: {{team-emoji}}
|
||||
[[LLM: Choose a single emoji that best represents the team's function or name]]
|
||||
|
||||
description: {{team-description}}
|
||||
[[LLM: Write a concise description (1 sentence) that explains:
|
||||
1. The team's primary purpose
|
||||
2. What types of projects they handle
|
||||
3. Any special capabilities or focus areas
|
||||
4. Keep it short as its displayed in menus
|
||||
Example: "Full Stack Ideation Web App Team." or "Startup Business Coaching team"]]
|
||||
|
||||
agents:
|
||||
[[LLM: List the agents that make up this team. Guidelines:
|
||||
- Use shortened agent names (e.g., 'analyst' not 'business-analyst')
|
||||
- Include 'bmad-orchestrator' for bmad-core teams as the coordinator
|
||||
- Only use '*' for an all-inclusive team (rare)
|
||||
- Order agents logically by workflow (analysis → design → development → testing)
|
||||
- For expansion packs, include both core agents and custom agents]]
|
||||
|
||||
^^CONDITION: standard-team^^
|
||||
# Core workflow agents
|
||||
- bmad-orchestrator # Team coordinator
|
||||
- analyst # Requirements and analysis
|
||||
- pm # Product management
|
||||
- architect # System design
|
||||
- dev # Development
|
||||
- qa # Quality assurance
|
||||
^^/CONDITION: standard-team^^
|
||||
|
||||
^^CONDITION: minimal-team^^
|
||||
# Minimal team for quick iterations
|
||||
- bmad-orchestrator # Team coordinator
|
||||
- architect # Design and planning
|
||||
- dev # Implementation
|
||||
^^/CONDITION: minimal-team^^
|
||||
|
||||
^^CONDITION: specialized-team^^
|
||||
# Domain-specific team composition
|
||||
- {{domain}}-orchestrator # Domain coordinator
|
||||
<<REPEAT section="specialist-agents" count="{{agent-count}}">>
|
||||
- {{agent-short-name}} # {{agent-role-description}}
|
||||
<</REPEAT>>
|
||||
^^/CONDITION: specialized-team^^
|
||||
|
||||
^^CONDITION: include-all-agents^^
|
||||
- '*' # Include all available agents
|
||||
^^/CONDITION: include-all-agents^^
|
||||
|
||||
workflows:
|
||||
[[LLM: Define the workflows this team can execute that will guide the user through a multi-step multi agent process. Guidelines:
|
||||
- Use null if the team doesn't have predefined workflows
|
||||
- Workflow names should be descriptive
|
||||
- use domain-specific workflow names]]
|
||||
|
||||
^^CONDITION: no-workflows^^
|
||||
null # No predefined workflows
|
||||
^^/CONDITION: no-workflows^^
|
||||
|
||||
^^CONDITION: standard-workflows^^
|
||||
# New project workflows
|
||||
- greenfield-fullstack # New full-stack application
|
||||
- greenfield-service # New backend service
|
||||
- greenfield-ui # New frontend application
|
||||
|
||||
# Existing project workflows
|
||||
- brownfield-fullstack # Enhance existing full-stack app
|
||||
- brownfield-service # Enhance existing service
|
||||
- brownfield-ui # Enhance existing UI
|
||||
^^/CONDITION: standard-workflows^^
|
||||
|
||||
^^CONDITION: domain-workflows^^
|
||||
# Domain-specific workflows
|
||||
<<REPEAT section="workflows" count="{{workflow-count}}">>
|
||||
- {{workflow-name}} # {{workflow-description}}
|
||||
<</REPEAT>>
|
||||
^^/CONDITION: domain-workflows^^
|
||||
```
|
||||
|
||||
@{example-1: Standard fullstack team}
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
name: Team Fullstack
|
||||
icon: 🚀
|
||||
description: Complete agile team for full-stack web applications. Handles everything from requirements to deployment.
|
||||
agents:
|
||||
- bmad-orchestrator
|
||||
- analyst
|
||||
- pm
|
||||
- architect
|
||||
- dev
|
||||
- qa
|
||||
- ux-expert
|
||||
workflows:
|
||||
- greenfield-fullstack
|
||||
- greenfield-service
|
||||
- greenfield-ui
|
||||
- brownfield-fullstack
|
||||
- brownfield-service
|
||||
- brownfield-ui
|
||||
```
|
||||
|
||||
@{example-2: Healthcare expansion pack team}
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
name: Healthcare Compliance Team
|
||||
icon: ⚕️
|
||||
description: Specialized team for healthcare applications with HIPAA compliance focus. Manages clinical workflows and regulatory requirements.
|
||||
agents:
|
||||
- healthcare-orchestrator
|
||||
- clinical-analyst
|
||||
- compliance-officer
|
||||
- architect
|
||||
- dev
|
||||
- qa
|
||||
workflows:
|
||||
- healthcare-patient-portal
|
||||
- healthcare-compliance-audit
|
||||
- clinical-trial-management
|
||||
```
|
||||
|
||||
@{example-3: Minimal IDE team}
|
||||
|
||||
```yaml
|
||||
bundle:
|
||||
name: Team IDE Minimal
|
||||
icon: ⚡
|
||||
description: Minimal team for IDE usage. Just the essentials for quick development.
|
||||
agents:
|
||||
- bmad-orchestrator
|
||||
- architect
|
||||
- dev
|
||||
workflows: null
|
||||
```
|
||||
|
||||
[[LLM: When creating a new team configuration:
|
||||
|
||||
1. Choose the most appropriate condition block based on team type
|
||||
2. Remove all unused condition blocks
|
||||
3. Replace all placeholders with actual values
|
||||
4. Ensure agent names match available agents in the system
|
||||
5. Verify workflow names match available workflows
|
||||
6. Save as team-[descriptor].yaml or [domain]-team.yaml
|
||||
7. Place in the agent-teams directory of the appropriate location]]
|
||||
@@ -0,0 +1,178 @@
|
||||
template:
|
||||
id: agent-teams-template-v2
|
||||
name: Agent Team Configuration
|
||||
version: 2.0
|
||||
output:
|
||||
format: yaml
|
||||
filename: "agent-teams/{{team_name}}.yaml"
|
||||
title: "{{team_name}}"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
|
||||
sections:
|
||||
- id: header
|
||||
title: Agent Team Configuration Template
|
||||
instruction: |
|
||||
This template is for creating agent team configurations in YAML format. Follow the structure carefully and replace all placeholders with appropriate values. The team name should reflect the team's purpose and domain focus.
|
||||
|
||||
- id: yaml-configuration
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
bundle:
|
||||
name: {{team_display_name}}
|
||||
icon: {{team_emoji}}
|
||||
description: {{team_description}}
|
||||
|
||||
agents:
|
||||
{{agent_list}}
|
||||
|
||||
workflows:
|
||||
{{workflow_list}}
|
||||
instruction: |
|
||||
Use format "Team [Descriptor]" for generic teams or "[Domain] Team" for specialized teams. Examples: "Team Fullstack", "Healthcare Team", "Legal Team"
|
||||
|
||||
Choose a single emoji that best represents the team's function or name
|
||||
|
||||
Write a concise description (1 sentence) that explains:
|
||||
1. The team's primary purpose
|
||||
2. What types of projects they handle
|
||||
3. Any special capabilities or focus areas
|
||||
4. Keep it short as its displayed in menus
|
||||
Example: "Full Stack Ideation Web App Team." or "Startup Business Coaching team"
|
||||
|
||||
List the agents that make up this team. Guidelines:
|
||||
- Use shortened agent names (e.g., 'analyst' not 'business-analyst')
|
||||
- Include 'bmad-orchestrator' for bmad-core teams as the coordinator
|
||||
- Only use '*' for an all-inclusive team (rare)
|
||||
- Order agents logically by workflow (analysis → design → development → testing)
|
||||
- For expansion packs, include both core agents and custom agents
|
||||
|
||||
Define the workflows this team can execute that will guide the user through a multi-step multi agent process. Guidelines:
|
||||
- Use null if the team doesn't have predefined workflows
|
||||
- Workflow names should be descriptive
|
||||
- use domain-specific workflow names
|
||||
sections:
|
||||
- id: standard-team
|
||||
condition: Standard team configuration
|
||||
template: |
|
||||
# Core workflow agents
|
||||
- bmad-orchestrator # Team coordinator
|
||||
- analyst # Requirements and analysis
|
||||
- pm # Product management
|
||||
- architect # System design
|
||||
- dev # Development
|
||||
- qa # Quality assurance
|
||||
- id: minimal-team
|
||||
condition: Minimal team configuration
|
||||
template: |
|
||||
# Minimal team for quick iterations
|
||||
- bmad-orchestrator # Team coordinator
|
||||
- architect # Design and planning
|
||||
- dev # Implementation
|
||||
- id: specialized-team
|
||||
condition: Domain-specific team
|
||||
template: |
|
||||
# Domain-specific team composition
|
||||
- {{domain}}-orchestrator # Domain coordinator
|
||||
- {{agent_short_name}} # {{agent_role_description}}
|
||||
- id: all-agents
|
||||
condition: Include all available agents
|
||||
template: |
|
||||
- '*' # Include all available agents
|
||||
- id: no-workflows
|
||||
condition: No predefined workflows
|
||||
template: |
|
||||
null # No predefined workflows
|
||||
- id: standard-workflows
|
||||
condition: Standard project workflows
|
||||
template: |
|
||||
# New project workflows
|
||||
- greenfield-fullstack # New full-stack application
|
||||
- greenfield-service # New backend service
|
||||
- greenfield-ui # New frontend application
|
||||
|
||||
# Existing project workflows
|
||||
- brownfield-fullstack # Enhance existing full-stack app
|
||||
- brownfield-service # Enhance existing service
|
||||
- brownfield-ui # Enhance existing UI
|
||||
- id: domain-workflows
|
||||
condition: Domain-specific workflows
|
||||
template: |
|
||||
# Domain-specific workflows
|
||||
- {{workflow_name}} # {{workflow_description}}
|
||||
|
||||
- id: examples
|
||||
title: Examples
|
||||
sections:
|
||||
- id: example-1
|
||||
title: "Example 1: Standard fullstack team"
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
bundle:
|
||||
name: Team Fullstack
|
||||
icon: 🚀
|
||||
description: Complete agile team for full-stack web applications. Handles everything from requirements to deployment.
|
||||
agents:
|
||||
- bmad-orchestrator
|
||||
- analyst
|
||||
- pm
|
||||
- architect
|
||||
- dev
|
||||
- qa
|
||||
- ux-expert
|
||||
workflows:
|
||||
- greenfield-fullstack
|
||||
- greenfield-service
|
||||
- greenfield-ui
|
||||
- brownfield-fullstack
|
||||
- brownfield-service
|
||||
- brownfield-ui
|
||||
- id: example-2
|
||||
title: "Example 2: Healthcare expansion pack team"
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
bundle:
|
||||
name: Healthcare Compliance Team
|
||||
icon: ⚕️
|
||||
description: Specialized team for healthcare applications with HIPAA compliance focus. Manages clinical workflows and regulatory requirements.
|
||||
agents:
|
||||
- healthcare-orchestrator
|
||||
- clinical-analyst
|
||||
- compliance-officer
|
||||
- architect
|
||||
- dev
|
||||
- qa
|
||||
workflows:
|
||||
- healthcare-patient-portal
|
||||
- healthcare-compliance-audit
|
||||
- clinical-trial-management
|
||||
- id: example-3
|
||||
title: "Example 3: Minimal IDE team"
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
bundle:
|
||||
name: Team IDE Minimal
|
||||
icon: ⚡
|
||||
description: Minimal team for IDE usage. Just the essentials for quick development.
|
||||
agents:
|
||||
- bmad-orchestrator
|
||||
- architect
|
||||
- dev
|
||||
workflows: null
|
||||
|
||||
- id: creation-instructions
|
||||
instruction: |
|
||||
When creating a new team configuration:
|
||||
|
||||
1. Choose the most appropriate condition block based on team type
|
||||
2. Remove all unused condition blocks
|
||||
3. Replace all placeholders with actual values
|
||||
4. Ensure agent names match available agents in the system
|
||||
5. Verify workflow names match available workflows
|
||||
6. Save as team-[descriptor].yaml or [domain]-team.yaml
|
||||
7. Place in the agent-teams directory of the appropriate location
|
||||
@@ -1,143 +0,0 @@
|
||||
# [AGENT_ID]
|
||||
|
||||
[[LLM: This is an agent definition template. When creating a new agent:
|
||||
|
||||
1. ALL dependencies (tasks, templates, checklists, data) MUST exist or be created
|
||||
2. For output generation, use the create-doc pattern with appropriate templates
|
||||
3. Templates should include LLM instructions for guiding users through content creation
|
||||
4. Character personas should be consistent and domain-appropriate
|
||||
5. Follow the numbered options protocol for all user interactions]]
|
||||
|
||||
CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
||||
|
||||
```yaml
|
||||
activation-instructions:
|
||||
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
||||
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
||||
- The customization field ALWAYS takes precedence over any conflicting instructions
|
||||
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
||||
- Command
|
||||
|
||||
agent:
|
||||
name: [AGENT_NAME]
|
||||
id: [AGENT_ID]
|
||||
title: [AGENT_TITLE]
|
||||
customization: [OPTIONAL_CUSTOMIZATION]
|
||||
|
||||
persona:
|
||||
role: [AGENT_ROLE_DESCRIPTION]
|
||||
style: [COMMUNICATION_STYLE]
|
||||
identity: [AGENT_IDENTITY_DESCRIPTION]
|
||||
focus: [PRIMARY_FOCUS_AREAS]
|
||||
|
||||
core_principles:
|
||||
- [PRINCIPLE_1]
|
||||
- [PRINCIPLE_2]
|
||||
- [PRINCIPLE_3]
|
||||
# Add more principles as needed
|
||||
|
||||
startup:
|
||||
- Greet the user with your name and role, and inform of the *help command.
|
||||
- [STARTUP_INSTRUCTION]
|
||||
- [STARTUP_INSTRUCTION]...
|
||||
|
||||
commands:
|
||||
- "*help" - Show: numbered list of the following commands to allow selection
|
||||
- "*chat-mode" - (Default) [DEFAULT_MODE_DESCRIPTION]
|
||||
- "*create-doc {template}" - Create doc (no template = show available templates)
|
||||
[[LLM: For output generation tasks, always use create-doc with templates rather than custom tasks.
|
||||
Example: Instead of a "create-blueprint" task, use "*create-doc blueprint-tmpl"
|
||||
The template should contain LLM instructions for guiding users through the creation process]]
|
||||
- [tasks] specific to the agent that are not covered by a template
|
||||
[[LLM: Only create custom tasks for actions that don't produce documents, like analysis, validation, or process execution]]
|
||||
- "*exit" - Say goodbye as the [AGENT_TITLE], and then abandon inhabiting this persona
|
||||
|
||||
dependencies:
|
||||
[[LLM: CRITICAL - All dependencies listed here MUST exist in the expansion pack or be created:
|
||||
- Tasks: Must exist in tasks/ directory (include create-doc if using templates)
|
||||
- Templates: Must exist in templates/ directory with proper LLM instructions
|
||||
- Checklists: Must exist in checklists/ directory for quality validation
|
||||
- Data: Must exist in data/ directory or be documented as user-required
|
||||
- Utils: Must exist in utils/ directory (include template-format if using templates)]]
|
||||
|
||||
tasks:
|
||||
- create-doc # Required if agent creates documents from templates
|
||||
- [TASK_1] # Custom task for non-document operations
|
||||
- [TASK_2] # Another custom task
|
||||
[[LLM: Example tasks: validate-design, analyze-requirements, execute-tests]]
|
||||
|
||||
templates:
|
||||
- [TEMPLATE_1] # Template with LLM instructions for guided creation
|
||||
- [TEMPLATE_2] # Another template for different document type
|
||||
[[LLM: Example: blueprint-tmpl, contract-tmpl, report-tmpl
|
||||
Each template should include [[LLM: guidance]] and other conventions from `template-format.md` sections for user interaction]]
|
||||
|
||||
checklists:
|
||||
- [CHECKLIST_1] # Quality validation for template outputs
|
||||
[[LLM: Example: blueprint-checklist, contract-checklist
|
||||
Checklists validate documents created from templates]]
|
||||
|
||||
data:
|
||||
- [DATA_1] # Domain knowledge files
|
||||
[[LLM: Example: building-codes.md, legal-terminology.md
|
||||
Can be embedded in pack or required from user]]
|
||||
|
||||
utils:
|
||||
- template-format # Required if using templates
|
||||
- [UTIL_1] # Other utilities as needed
|
||||
[[LLM: Include workflow-management if agent participates in workflows]]
|
||||
```
|
||||
|
||||
@{example: Construction Contractor Agent}
|
||||
|
||||
```yaml
|
||||
activation-instructions:
|
||||
- Follow all instructions in this file
|
||||
- Stay in character as Marcus Thompson, Construction Manager
|
||||
- Use numbered options for all interactions
|
||||
agent:
|
||||
name: Marcus Thompson
|
||||
id: construction-contractor
|
||||
title: Construction Project Manager
|
||||
customization: null
|
||||
persona:
|
||||
role: Licensed general contractor with 20 years experience
|
||||
style: Professional, detail-oriented, safety-conscious
|
||||
identity: Former site foreman who worked up to project management
|
||||
focus: Building design, code compliance, project scheduling, cost estimation
|
||||
core_principles:
|
||||
- Safety first - all designs must prioritize worker and occupant safety
|
||||
- Code compliance - ensure all work meets local building codes
|
||||
- Quality craftsmanship - no shortcuts on structural integrity
|
||||
startup:
|
||||
- Greet as Marcus Thompson, Construction Project Manager
|
||||
- Briefly mention your experience and readiness to help
|
||||
- Ask what type of construction project they're planning
|
||||
- DO NOT auto-execute any commands
|
||||
commands:
|
||||
- '*help" - Show numbered list of available commands'
|
||||
- '*chat-mode" - Discuss construction projects and provide expertise'
|
||||
- '*create-doc blueprint-tmpl" - Create architectural blueprints'
|
||||
- '*create-doc estimate-tmpl" - Create project cost estimate'
|
||||
- '*create-doc schedule-tmpl" - Create construction schedule'
|
||||
- '*validate-plans" - Review plans for code compliance'
|
||||
- '*safety-assessment" - Evaluate safety considerations'
|
||||
- '*exit" - Say goodbye as Marcus and exit'
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-doc
|
||||
- validate-plans
|
||||
- safety-assessment
|
||||
templates:
|
||||
- blueprint-tmpl
|
||||
- estimate-tmpl
|
||||
- schedule-tmpl
|
||||
checklists:
|
||||
- blueprint-checklist
|
||||
- safety-checklist
|
||||
data:
|
||||
- building-codes.md
|
||||
- materials-guide.md
|
||||
utils:
|
||||
- template-format
|
||||
```
|
||||
154
expansion-packs/bmad-creator-tools/templates/agent-tmpl.yaml
Normal file
154
expansion-packs/bmad-creator-tools/templates/agent-tmpl.yaml
Normal file
@@ -0,0 +1,154 @@
|
||||
template:
|
||||
id: agent-template-v2
|
||||
name: Agent Definition
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: "agents/{{agent_id}}.md"
|
||||
title: "{{agent_id}}"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
|
||||
sections:
|
||||
- id: header
|
||||
title: "{{agent_id}}"
|
||||
instruction: |
|
||||
This is an agent definition template. When creating a new agent:
|
||||
|
||||
1. ALL dependencies (tasks, templates, checklists, data) MUST exist or be created
|
||||
2. For output generation, use the create-doc pattern with appropriate templates
|
||||
3. Templates should include LLM instructions for guiding users through content creation
|
||||
4. Character personas should be consistent and domain-appropriate
|
||||
5. Follow the numbered options protocol for all user interactions
|
||||
|
||||
- id: agent-definition
|
||||
content: |
|
||||
CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
||||
sections:
|
||||
- id: yaml-definition
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
activation-instructions:
|
||||
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
||||
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
||||
- The customization field ALWAYS takes precedence over any conflicting instructions
|
||||
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
||||
- Command
|
||||
|
||||
agent:
|
||||
name: {{agent_name}}
|
||||
id: {{agent_id}}
|
||||
title: {{agent_title}}
|
||||
customization: {{optional_customization}}
|
||||
|
||||
persona:
|
||||
role: {{agent_role_description}}
|
||||
style: {{communication_style}}
|
||||
identity: {{agent_identity_description}}
|
||||
focus: {{primary_focus_areas}}
|
||||
|
||||
core_principles:
|
||||
- {{principle_1}}
|
||||
- {{principle_2}}
|
||||
- {{principle_3}}
|
||||
# Add more principles as needed
|
||||
|
||||
startup:
|
||||
- Greet the user with your name and role, and inform of the *help command.
|
||||
- {{startup_instruction_1}}
|
||||
- {{startup_instruction_2}}
|
||||
|
||||
commands:
|
||||
- "*help" - Show: numbered list of the following commands to allow selection
|
||||
- "*chat-mode" - (Default) {{default_mode_description}}
|
||||
- "*create-doc {template}" - Create doc (no template = show available templates)
|
||||
{{custom_commands}}
|
||||
- "*exit" - Say goodbye as the {{agent_title}}, and then abandon inhabiting this persona
|
||||
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-doc # Required if agent creates documents from templates
|
||||
{{task_list}}
|
||||
|
||||
templates:
|
||||
{{template_list}}
|
||||
|
||||
checklists:
|
||||
{{checklist_list}}
|
||||
|
||||
data:
|
||||
{{data_list}}
|
||||
|
||||
utils:
|
||||
- template-format # Required if using templates
|
||||
{{util_list}}
|
||||
instruction: |
|
||||
For output generation tasks, always use create-doc with templates rather than custom tasks.
|
||||
Example: Instead of a "create-blueprint" task, use "*create-doc blueprint-tmpl"
|
||||
The template should contain LLM instructions for guiding users through the creation process
|
||||
|
||||
Only create custom tasks for actions that don't produce documents, like analysis, validation, or process execution
|
||||
|
||||
CRITICAL - All dependencies listed here MUST exist in the expansion pack or be created:
|
||||
- Tasks: Must exist in tasks/ directory (include create-doc if using templates)
|
||||
- Templates: Must exist in templates/ directory with proper LLM instructions
|
||||
- Checklists: Must exist in checklists/ directory for quality validation
|
||||
- Data: Must exist in data/ directory or be documented as user-required
|
||||
- Utils: Must exist in utils/ directory (include template-format if using templates)
|
||||
|
||||
- id: example
|
||||
title: Example: Construction Contractor Agent
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
activation-instructions:
|
||||
- Follow all instructions in this file
|
||||
- Stay in character as Marcus Thompson, Construction Manager
|
||||
- Use numbered options for all interactions
|
||||
agent:
|
||||
name: Marcus Thompson
|
||||
id: construction-contractor
|
||||
title: Construction Project Manager
|
||||
customization: null
|
||||
persona:
|
||||
role: Licensed general contractor with 20 years experience
|
||||
style: Professional, detail-oriented, safety-conscious
|
||||
identity: Former site foreman who worked up to project management
|
||||
focus: Building design, code compliance, project scheduling, cost estimation
|
||||
core_principles:
|
||||
- Safety first - all designs must prioritize worker and occupant safety
|
||||
- Code compliance - ensure all work meets local building codes
|
||||
- Quality craftsmanship - no shortcuts on structural integrity
|
||||
startup:
|
||||
- Greet as Marcus Thompson, Construction Project Manager
|
||||
- Briefly mention your experience and readiness to help
|
||||
- Ask what type of construction project they're planning
|
||||
- DO NOT auto-execute any commands
|
||||
commands:
|
||||
- '*help" - Show numbered list of available commands'
|
||||
- '*chat-mode" - Discuss construction projects and provide expertise'
|
||||
- '*create-doc blueprint-tmpl" - Create architectural blueprints'
|
||||
- '*create-doc estimate-tmpl" - Create project cost estimate'
|
||||
- '*create-doc schedule-tmpl" - Create construction schedule'
|
||||
- '*validate-plans" - Review plans for code compliance'
|
||||
- '*safety-assessment" - Evaluate safety considerations'
|
||||
- '*exit" - Say goodbye as Marcus and exit'
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-doc
|
||||
- validate-plans
|
||||
- safety-assessment
|
||||
templates:
|
||||
- blueprint-tmpl
|
||||
- estimate-tmpl
|
||||
- schedule-tmpl
|
||||
checklists:
|
||||
- blueprint-checklist
|
||||
- safety-checklist
|
||||
data:
|
||||
- building-codes.md
|
||||
- materials-guide.md
|
||||
utils:
|
||||
- template-format
|
||||
@@ -1,91 +0,0 @@
|
||||
# {Pack Name} Expansion Pack Plan
|
||||
|
||||
## Overview
|
||||
|
||||
- **Pack Name**: {pack-identifier}
|
||||
- **Display Name**: {Full Expansion Pack Name}
|
||||
- **Description**: {Brief description of what this pack does}
|
||||
- **Target Domain**: {Industry/domain this serves}
|
||||
- **Author**: {Your name/organization}
|
||||
|
||||
## Problem Statement
|
||||
|
||||
{What specific challenges does this expansion pack solve?}
|
||||
|
||||
## Target Users
|
||||
|
||||
{Who will benefit from this expansion pack?}
|
||||
|
||||
## Components to Create
|
||||
|
||||
### Agents
|
||||
|
||||
- [ ] `{pack-name}-orchestrator` - **REQUIRED**: Master orchestrator for {domain} workflows
|
||||
- Key commands: {list main commands}
|
||||
- Manages: {what it orchestrates}
|
||||
- [ ] `{agent-1-name}` - {Role description}
|
||||
- Tasks used: {task-1}, {task-2}
|
||||
- Templates used: {template-1}
|
||||
- Data required: {data-file-1}
|
||||
- [ ] `{agent-2-name}` - {Role description}
|
||||
- Tasks used: {task-3}
|
||||
- Templates used: {template-2}
|
||||
- Data required: {data-file-2}
|
||||
|
||||
### Tasks
|
||||
|
||||
- [ ] `{task-1}.md` - {Purpose} (used by: {agent})
|
||||
- [ ] `{task-2}.md` - {Purpose} (used by: {agent})
|
||||
- [ ] `{task-3}.md` - {Purpose} (used by: {agent})
|
||||
|
||||
### Templates
|
||||
|
||||
- [ ] `{template-1}-tmpl.md` - {Document type} (used by: {agent/task})
|
||||
- [ ] `{template-2}-tmpl.md` - {Document type} (used by: {agent/task})
|
||||
|
||||
### Checklists
|
||||
|
||||
- [ ] `{checklist-1}-checklist.md` - {What it validates}
|
||||
- [ ] `{checklist-2}-checklist.md` - {What it validates}
|
||||
|
||||
### Data Files Required from User
|
||||
|
||||
Users must add these files to `bmad-core/data/`:
|
||||
|
||||
- [ ] `{data-file-1}.{ext}` - {Description of required content}
|
||||
- Format: {file format}
|
||||
- Purpose: {why needed}
|
||||
- Example: {brief example}
|
||||
- [ ] `{data-file-2}.{ext}` - {Description of required content}
|
||||
- Format: {file format}
|
||||
- Purpose: {why needed}
|
||||
- Example: {brief example}
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
1. {Step 1 - typically starts with orchestrator}
|
||||
2. {Step 2}
|
||||
3. {Step 3}
|
||||
4. {Final output/deliverable}
|
||||
|
||||
## Integration Points
|
||||
|
||||
- Depends on core agents: {list any core BMad agents used}
|
||||
- Extends teams: {which teams to update}
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] All components created and cross-referenced
|
||||
- [ ] No orphaned task/template references
|
||||
- [ ] Data requirements clearly documented
|
||||
- [ ] Orchestrator provides clear workflow
|
||||
- [ ] README includes setup instructions
|
||||
|
||||
## User Approval
|
||||
|
||||
- [ ] Plan reviewed by user
|
||||
- [ ] Approval to proceed with implementation
|
||||
|
||||
---
|
||||
|
||||
**Next Steps**: Once approved, proceed with Phase 3 implementation starting with the orchestrator agent.
|
||||
@@ -0,0 +1,120 @@
|
||||
template:
|
||||
id: expansion-pack-plan-template-v2
|
||||
name: Expansion Pack Plan
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: "{{pack_name}}-expansion-pack-plan.md"
|
||||
title: "{{pack_display_name}} Expansion Pack Plan"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
|
||||
sections:
|
||||
- id: overview
|
||||
title: Overview
|
||||
template: |
|
||||
- **Pack Name**: {{pack_identifier}}
|
||||
- **Display Name**: {{full_expansion_pack_name}}
|
||||
- **Description**: {{brief_description}}
|
||||
- **Target Domain**: {{industry_domain}}
|
||||
- **Author**: {{author_name_organization}}
|
||||
|
||||
- id: problem-statement
|
||||
title: Problem Statement
|
||||
instruction: What specific challenges does this expansion pack solve?
|
||||
template: "{{problem_description}}"
|
||||
|
||||
- id: target-users
|
||||
title: Target Users
|
||||
instruction: Who will benefit from this expansion pack?
|
||||
template: "{{target_user_description}}"
|
||||
|
||||
- id: components
|
||||
title: Components to Create
|
||||
sections:
|
||||
- id: agents
|
||||
title: Agents
|
||||
type: checklist
|
||||
instruction: List all agents to be created with their roles and dependencies
|
||||
items:
|
||||
- id: orchestrator
|
||||
template: |
|
||||
`{{pack_name}}-orchestrator` - **REQUIRED**: Master orchestrator for {{domain}} workflows
|
||||
- Key commands: {{command_list}}
|
||||
- Manages: {{orchestration_scope}}
|
||||
- id: agent-list
|
||||
repeatable: true
|
||||
template: |
|
||||
`{{agent_name}}` - {{role_description}}
|
||||
- Tasks used: {{task_list}}
|
||||
- Templates used: {{template_list}}
|
||||
- Data required: {{data_requirements}}
|
||||
|
||||
- id: tasks
|
||||
title: Tasks
|
||||
type: checklist
|
||||
instruction: List all tasks to be created
|
||||
repeatable: true
|
||||
template: "`{{task_name}}.md` - {{purpose}} (used by: {{using_agents}})"
|
||||
|
||||
- id: templates
|
||||
title: Templates
|
||||
type: checklist
|
||||
instruction: List all templates to be created
|
||||
repeatable: true
|
||||
template: "`{{template_name}}-tmpl.md` - {{document_type}} (used by: {{using_components}})"
|
||||
|
||||
- id: checklists
|
||||
title: Checklists
|
||||
type: checklist
|
||||
instruction: List all checklists to be created
|
||||
repeatable: true
|
||||
template: "`{{checklist_name}}-checklist.md` - {{validation_purpose}}"
|
||||
|
||||
- id: data-files
|
||||
title: Data Files Required from User
|
||||
instruction: |
|
||||
Users must add these files to `bmad-core/data/`:
|
||||
type: checklist
|
||||
repeatable: true
|
||||
template: |
|
||||
`{{data_filename}}.{{extension}}` - {{content_description}}
|
||||
- Format: {{file_format}}
|
||||
- Purpose: {{why_needed}}
|
||||
- Example: {{brief_example}}
|
||||
|
||||
- id: workflow-overview
|
||||
title: Workflow Overview
|
||||
type: numbered-list
|
||||
instruction: Describe the typical workflow steps
|
||||
template: "{{workflow_step}}"
|
||||
|
||||
- id: integration-points
|
||||
title: Integration Points
|
||||
template: |
|
||||
- Depends on core agents: {{core_agent_dependencies}}
|
||||
- Extends teams: {{team_updates}}
|
||||
|
||||
- id: success-criteria
|
||||
title: Success Criteria
|
||||
type: checklist
|
||||
items:
|
||||
- "All components created and cross-referenced"
|
||||
- "No orphaned task/template references"
|
||||
- "Data requirements clearly documented"
|
||||
- "Orchestrator provides clear workflow"
|
||||
- "README includes setup instructions"
|
||||
|
||||
- id: user-approval
|
||||
title: User Approval
|
||||
type: checklist
|
||||
items:
|
||||
- "Plan reviewed by user"
|
||||
- "Approval to proceed with implementation"
|
||||
|
||||
- id: next-steps
|
||||
content: |
|
||||
---
|
||||
|
||||
**Next Steps**: Once approved, proceed with Phase 3 implementation starting with the orchestrator agent.
|
||||
@@ -3,6 +3,9 @@
|
||||
CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
|
||||
|
||||
```yaml
|
||||
root: .bmad-infrastructure-devops
|
||||
IDE-FILE-RESOLUTION: Dependencies map to files as {root}/{type}/{name} where root=".bmad-core", type=folder (tasks/templates/checklists/utils), name=dependency name.
|
||||
REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), or ask for clarification if ambiguous.
|
||||
activation-instructions:
|
||||
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
|
||||
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
|
||||
@@ -43,16 +46,14 @@ commands:
|
||||
- '*exit" - Say goodbye as Alex, the DevOps Infrastructure Specialist, and then abandon inhabiting this persona'
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-doc
|
||||
- review-infrastructure
|
||||
- validate-infrastructure
|
||||
- create-doc.md
|
||||
- review-infrastructure.md
|
||||
- validate-infrastructure.md
|
||||
templates:
|
||||
- infrastructure-architecture-tmpl
|
||||
- infrastructure-platform-from-arch-tmpl
|
||||
- infrastructure-architecture-tmpl.yaml
|
||||
- infrastructure-platform-from-arch-tmpl.yaml
|
||||
checklists:
|
||||
- infrastructure-checklist
|
||||
- infrastructure-checklist.md
|
||||
data:
|
||||
- technical-preferences
|
||||
utils:
|
||||
- template-format
|
||||
- technical-preferences.md
|
||||
```
|
||||
|
||||
@@ -1,415 +0,0 @@
|
||||
# {{Project Name}} Infrastructure Architecture
|
||||
|
||||
[[LLM: Initial Setup
|
||||
|
||||
1. Replace {{Project Name}} with the actual project name throughout the document
|
||||
2. Gather and review required inputs:
|
||||
- Product Requirements Document (PRD) - Required for business needs and scale requirements
|
||||
- Main System Architecture - Required for infrastructure dependencies
|
||||
- Technical Preferences/Tech Stack Document - Required for technology choices
|
||||
- PRD Technical Assumptions - Required for cross-referencing repository and service architecture
|
||||
|
||||
If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
|
||||
|
||||
3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
|
||||
|
||||
Output file location: `docs/infrastructure-architecture.md`]]
|
||||
|
||||
## Infrastructure Overview
|
||||
|
||||
[[LLM: Review the product requirements document to understand business needs and scale requirements. Analyze the main system architecture to identify infrastructure dependencies. Document non-functional requirements (performance, scalability, reliability, security). Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions.]]
|
||||
|
||||
- Cloud Provider(s)
|
||||
- Core Services & Resources
|
||||
- Regional Architecture
|
||||
- Multi-environment Strategy
|
||||
|
||||
@{example: cloud_strategy}
|
||||
|
||||
- **Cloud Provider:** AWS (primary), with multi-cloud capability for critical services
|
||||
- **Core Services:** EKS for container orchestration, RDS for databases, S3 for storage, CloudFront for CDN
|
||||
- **Regional Architecture:** Multi-region active-passive with primary in us-east-1, DR in us-west-2
|
||||
- **Multi-environment Strategy:** Development, Staging, UAT, Production with identical infrastructure patterns
|
||||
|
||||
@{/example}
|
||||
|
||||
[[LLM: Infrastructure Elicitation Options
|
||||
Present user with domain-specific elicitation options:
|
||||
"For the Infrastructure Overview section, I can explore:
|
||||
|
||||
1. **Multi-Cloud Strategy Analysis** - Evaluate cloud provider options and vendor lock-in considerations
|
||||
2. **Regional Distribution Planning** - Analyze latency requirements and data residency needs
|
||||
3. **Environment Isolation Strategy** - Design security boundaries and resource segregation
|
||||
4. **Scalability Patterns Review** - Assess auto-scaling needs and traffic patterns
|
||||
5. **Compliance Requirements Analysis** - Review regulatory and security compliance needs
|
||||
6. **Cost-Benefit Analysis** - Compare infrastructure options and TCO
|
||||
7. **Proceed to next section**
|
||||
|
||||
Select an option (1-7):"]]
|
||||
|
||||
## Infrastructure as Code (IaC)
|
||||
|
||||
[[LLM: Define IaC approach based on technical preferences and existing patterns. Consider team expertise, tooling ecosystem, and maintenance requirements.]]
|
||||
|
||||
- Tools & Frameworks
|
||||
- Repository Structure
|
||||
- State Management
|
||||
- Dependency Management
|
||||
|
||||
<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
|
||||
|
||||
## Environment Configuration
|
||||
|
||||
[[LLM: Design environment strategy that supports the development workflow while maintaining security and cost efficiency. Reference the Environment Transition Strategy section for promotion details.]]
|
||||
|
||||
- Environment Promotion Strategy
|
||||
- Configuration Management
|
||||
- Secret Management
|
||||
- Feature Flag Integration
|
||||
|
||||
<<REPEAT: environment>>
|
||||
|
||||
### {{environment_name}} Environment
|
||||
|
||||
- **Purpose:** {{environment_purpose}}
|
||||
- **Resources:** {{environment_resources}}
|
||||
- **Access Control:** {{environment_access}}
|
||||
- **Data Classification:** {{environment_data_class}}
|
||||
|
||||
<</REPEAT>>
|
||||
|
||||
## Environment Transition Strategy
|
||||
|
||||
[[LLM: Detail the complete lifecycle of code and configuration changes from development to production. Include governance, testing gates, and rollback procedures.]]
|
||||
|
||||
- Development to Production Pipeline
|
||||
- Deployment Stages and Gates
|
||||
- Approval Workflows and Authorities
|
||||
- Rollback Procedures
|
||||
- Change Cadence and Release Windows
|
||||
- Environment-Specific Configuration Management
|
||||
|
||||
## Network Architecture
|
||||
|
||||
[[LLM: Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
|
||||
|
||||
Create Mermaid diagram showing:
|
||||
|
||||
- VPC/Network structure
|
||||
- Security zones and boundaries
|
||||
- Traffic flow patterns
|
||||
- Load balancer placement
|
||||
- Service mesh topology (if applicable)]]
|
||||
|
||||
- VPC/VNET Design
|
||||
- Subnet Strategy
|
||||
- Security Groups & NACLs
|
||||
- Load Balancers & API Gateways
|
||||
- Service Mesh (if applicable)
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "Production VPC"
|
||||
subgraph "Public Subnets"
|
||||
ALB[Application Load Balancer]
|
||||
end
|
||||
subgraph "Private Subnets"
|
||||
EKS[EKS Cluster]
|
||||
RDS[(RDS Database)]
|
||||
end
|
||||
end
|
||||
Internet((Internet)) --> ALB
|
||||
ALB --> EKS
|
||||
EKS --> RDS
|
||||
```
|
||||
|
||||
^^CONDITION: uses_service_mesh^^
|
||||
|
||||
### Service Mesh Architecture
|
||||
|
||||
- **Mesh Technology:** {{service_mesh_tech}}
|
||||
- **Traffic Management:** {{traffic_policies}}
|
||||
- **Security Policies:** {{mesh_security}}
|
||||
- **Observability Integration:** {{mesh_observability}}
|
||||
|
||||
^^/CONDITION: uses_service_mesh^^
|
||||
|
||||
## Compute Resources
|
||||
|
||||
[[LLM: Select compute strategy based on application architecture (microservices, serverless, monolithic). Consider cost, scalability, and operational complexity.]]
|
||||
|
||||
- Container Strategy
|
||||
- Serverless Architecture
|
||||
- VM/Instance Configuration
|
||||
- Auto-scaling Approach
|
||||
|
||||
^^CONDITION: uses_kubernetes^^
|
||||
|
||||
### Kubernetes Architecture
|
||||
|
||||
- **Cluster Configuration:** {{k8s_cluster_config}}
|
||||
- **Node Groups:** {{k8s_node_groups}}
|
||||
- **Networking:** {{k8s_networking}}
|
||||
- **Storage Classes:** {{k8s_storage}}
|
||||
- **Security Policies:** {{k8s_security}}
|
||||
|
||||
^^/CONDITION: uses_kubernetes^^
|
||||
|
||||
## Data Resources
|
||||
|
||||
[[LLM: Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
|
||||
|
||||
Create data flow diagram showing:
|
||||
|
||||
- Database topology
|
||||
- Replication patterns
|
||||
- Backup flows
|
||||
- Data migration paths]]
|
||||
|
||||
- Database Deployment Strategy
|
||||
- Backup & Recovery
|
||||
- Replication & Failover
|
||||
- Data Migration Strategy
|
||||
|
||||
## Security Architecture
|
||||
|
||||
[[LLM: Implement defense-in-depth strategy. Reference security requirements from PRD and compliance needs. Consider zero-trust principles where applicable.]]
|
||||
|
||||
- IAM & Authentication
|
||||
- Network Security
|
||||
- Data Encryption
|
||||
- Compliance Controls
|
||||
- Security Scanning & Monitoring
|
||||
|
||||
<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
|
||||
|
||||
## Shared Responsibility Model
|
||||
|
||||
[[LLM: Clearly define boundaries between cloud provider, platform team, development team, and security team responsibilities. This is critical for operational success.]]
|
||||
|
||||
- Cloud Provider Responsibilities
|
||||
- Platform Team Responsibilities
|
||||
- Development Team Responsibilities
|
||||
- Security Team Responsibilities
|
||||
- Operational Monitoring Ownership
|
||||
- Incident Response Accountability Matrix
|
||||
|
||||
@{example: responsibility_matrix}
|
||||
|
||||
| Component | Cloud Provider | Platform Team | Dev Team | Security Team |
|
||||
| -------------------- | -------------- | ------------- | -------------- | ------------- |
|
||||
| Physical Security | ✓ | - | - | Audit |
|
||||
| Network Security | Partial | ✓ | Config | Audit |
|
||||
| Application Security | - | Tools | ✓ | Review |
|
||||
| Data Encryption | Engine | Config | Implementation | Standards |
|
||||
|
||||
@{/example}
|
||||
|
||||
## Monitoring & Observability
|
||||
|
||||
[[LLM: Design comprehensive observability strategy covering metrics, logs, traces, and business KPIs. Ensure alignment with SLA/SLO requirements.]]
|
||||
|
||||
- Metrics Collection
|
||||
- Logging Strategy
|
||||
- Tracing Implementation
|
||||
- Alerting & Incident Response
|
||||
- Dashboards & Visualization
|
||||
|
||||
## CI/CD Pipeline
|
||||
|
||||
[[LLM: Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
|
||||
|
||||
Create pipeline diagram showing:
|
||||
|
||||
- Build stages
|
||||
- Test gates
|
||||
- Deployment stages
|
||||
- Approval points
|
||||
- Rollback triggers]]
|
||||
|
||||
- Pipeline Architecture
|
||||
- Build Process
|
||||
- Deployment Strategy
|
||||
- Rollback Procedures
|
||||
- Approval Gates
|
||||
|
||||
^^CONDITION: uses_progressive_deployment^^
|
||||
|
||||
### Progressive Deployment Strategy
|
||||
|
||||
- **Canary Deployment:** {{canary_config}}
|
||||
- **Blue-Green Deployment:** {{blue_green_config}}
|
||||
- **Feature Flags:** {{feature_flag_integration}}
|
||||
- **Traffic Splitting:** {{traffic_split_rules}}
|
||||
|
||||
^^/CONDITION: uses_progressive_deployment^^
|
||||
|
||||
## Disaster Recovery
|
||||
|
||||
[[LLM: Design DR strategy based on business continuity requirements. Define clear RTO/RPO targets and ensure they align with business needs.]]
|
||||
|
||||
- Backup Strategy
|
||||
- Recovery Procedures
|
||||
- RTO & RPO Targets
|
||||
- DR Testing Approach
|
||||
|
||||
<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
|
||||
|
||||
## Cost Optimization
|
||||
|
||||
[[LLM: Balance cost efficiency with performance and reliability requirements. Include both immediate optimizations and long-term strategies.]]
|
||||
|
||||
- Resource Sizing Strategy
|
||||
- Reserved Instances/Commitments
|
||||
- Cost Monitoring & Reporting
|
||||
- Optimization Recommendations
|
||||
|
||||
## BMad Integration Architecture
|
||||
|
||||
[[LLM: Design infrastructure to specifically support other BMad agents and their workflows. This ensures the infrastructure enables the entire BMad methodology.]]
|
||||
|
||||
### Development Agent Support
|
||||
|
||||
- Container platform for development environments
|
||||
- GitOps workflows for application deployment
|
||||
- Service mesh integration for development testing
|
||||
- Developer self-service platform capabilities
|
||||
|
||||
### Product & Architecture Alignment
|
||||
|
||||
- Infrastructure implementing PRD scalability requirements
|
||||
- Deployment automation supporting product iteration speed
|
||||
- Service reliability meeting product SLAs
|
||||
- Architecture patterns properly implemented in infrastructure
|
||||
|
||||
### Cross-Agent Integration Points
|
||||
|
||||
- CI/CD pipelines supporting Frontend, Backend, and Full Stack development workflows
|
||||
- Monitoring and observability data accessible to QA and DevOps agents
|
||||
- Infrastructure enabling Design Architect's UI/UX performance requirements
|
||||
- Platform supporting Analyst's data collection and analysis needs
|
||||
|
||||
## DevOps/Platform Feasibility Review
|
||||
|
||||
[[LLM: CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
|
||||
|
||||
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
|
||||
- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
|
||||
- **Security Implementation:** Are security patterns achievable with current security toolchain?
|
||||
- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
|
||||
- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
|
||||
|
||||
Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
|
||||
|
||||
<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>]]
|
||||
|
||||
### Feasibility Assessment Results
|
||||
|
||||
- **Green Light Items:** {{feasible_items}}
|
||||
- **Yellow Light Items:** {{items_needing_adjustment}}
|
||||
- **Red Light Items:** {{items_requiring_redesign}}
|
||||
- **Mitigation Strategies:** {{mitigation_plans}}
|
||||
|
||||
## Infrastructure Verification
|
||||
|
||||
### Validation Framework
|
||||
|
||||
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
|
||||
|
||||
- Completeness of architecture documentation
|
||||
- Consistency with broader system architecture
|
||||
- Appropriate level of detail for different stakeholders
|
||||
- Clear implementation guidance
|
||||
- Future evolution considerations
|
||||
|
||||
### Validation Process
|
||||
|
||||
The architecture documentation validation should be performed:
|
||||
|
||||
- After initial architecture development
|
||||
- After significant architecture changes
|
||||
- Before major implementation phases
|
||||
- During periodic architecture reviews
|
||||
|
||||
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
|
||||
|
||||
## Implementation Handoff
|
||||
|
||||
[[LLM: Create structured handoff documentation for implementation team. This ensures architecture decisions are properly communicated and implemented.]]
|
||||
|
||||
### Architecture Decision Records (ADRs)
|
||||
|
||||
Create ADRs for key infrastructure decisions:
|
||||
|
||||
- Cloud provider selection rationale
|
||||
- Container orchestration platform choice
|
||||
- Networking architecture decisions
|
||||
- Security implementation choices
|
||||
- Cost optimization trade-offs
|
||||
|
||||
### Implementation Validation Criteria
|
||||
|
||||
Define specific criteria for validating correct implementation:
|
||||
|
||||
- Infrastructure as Code quality gates
|
||||
- Security compliance checkpoints
|
||||
- Performance benchmarks
|
||||
- Cost targets
|
||||
- Operational readiness criteria
|
||||
|
||||
### Knowledge Transfer Requirements
|
||||
|
||||
- Technical documentation for operations team
|
||||
- Runbook creation requirements
|
||||
- Training needs for platform team
|
||||
- Handoff meeting agenda items
|
||||
|
||||
## Infrastructure Evolution
|
||||
|
||||
[[LLM: Document the long-term vision and evolution path for the infrastructure. Consider technology trends, anticipated growth, and technical debt management.]]
|
||||
|
||||
- Technical Debt Inventory
|
||||
- Planned Upgrades and Migrations
|
||||
- Deprecation Schedule
|
||||
- Technology Roadmap
|
||||
- Capacity Planning
|
||||
- Scalability Considerations
|
||||
|
||||
## Integration with Application Architecture
|
||||
|
||||
[[LLM: Map infrastructure components to application services. Ensure infrastructure design supports application requirements and patterns defined in main architecture.]]
|
||||
|
||||
- Service-to-Infrastructure Mapping
|
||||
- Application Dependency Matrix
|
||||
- Performance Requirements Implementation
|
||||
- Security Requirements Implementation
|
||||
- Data Flow to Infrastructure Correlation
|
||||
- API Gateway and Service Mesh Integration
|
||||
|
||||
## Cross-Team Collaboration
|
||||
|
||||
[[LLM: Define clear interfaces and communication patterns between teams. This section is critical for operational success and should include specific touchpoints and escalation paths.]]
|
||||
|
||||
- Platform Engineer and Developer Touchpoints
|
||||
- Frontend/Backend Integration Requirements
|
||||
- Product Requirements to Infrastructure Mapping
|
||||
- Architecture Decision Impact Analysis
|
||||
- Design Architect UI/UX Infrastructure Requirements
|
||||
- Analyst Research Integration
|
||||
|
||||
## Infrastructure Change Management
|
||||
|
||||
[[LLM: Define structured process for infrastructure changes. Include risk assessment, testing requirements, and rollback procedures.]]
|
||||
|
||||
- Change Request Process
|
||||
- Risk Assessment
|
||||
- Testing Strategy
|
||||
- Validation Procedures
|
||||
|
||||
[[LLM: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.]]
|
||||
|
||||
---
|
||||
|
||||
_Document Version: 1.0_
|
||||
_Last Updated: {{current_date}}_
|
||||
_Next Review: {{review_date}}_
|
||||
@@ -0,0 +1,424 @@
|
||||
template:
|
||||
id: infrastructure-architecture-template-v2
|
||||
name: Infrastructure Architecture
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: docs/infrastructure-architecture.md
|
||||
title: "{{project_name}} Infrastructure Architecture"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
elicitation: advanced-elicitation
|
||||
custom_elicitation:
|
||||
title: "Infrastructure Architecture Elicitation Actions"
|
||||
sections:
|
||||
- id: infrastructure-overview
|
||||
options:
|
||||
- "Multi-Cloud Strategy Analysis - Evaluate cloud provider options and vendor lock-in considerations"
|
||||
- "Regional Distribution Planning - Analyze latency requirements and data residency needs"
|
||||
- "Environment Isolation Strategy - Design security boundaries and resource segregation"
|
||||
- "Scalability Patterns Review - Assess auto-scaling needs and traffic patterns"
|
||||
- "Compliance Requirements Analysis - Review regulatory and security compliance needs"
|
||||
- "Cost-Benefit Analysis - Compare infrastructure options and TCO"
|
||||
- "Proceed to next section"
|
||||
|
||||
sections:
|
||||
- id: initial-setup
|
||||
instruction: |
|
||||
Initial Setup
|
||||
|
||||
1. Replace {{project_name}} with the actual project name throughout the document
|
||||
2. Gather and review required inputs:
|
||||
- Product Requirements Document (PRD) - Required for business needs and scale requirements
|
||||
- Main System Architecture - Required for infrastructure dependencies
|
||||
- Technical Preferences/Tech Stack Document - Required for technology choices
|
||||
- PRD Technical Assumptions - Required for cross-referencing repository and service architecture
|
||||
|
||||
If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
|
||||
|
||||
3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
|
||||
|
||||
Output file location: `docs/infrastructure-architecture.md`
|
||||
|
||||
- id: infrastructure-overview
|
||||
title: Infrastructure Overview
|
||||
instruction: |
|
||||
Review the product requirements document to understand business needs and scale requirements. Analyze the main system architecture to identify infrastructure dependencies. Document non-functional requirements (performance, scalability, reliability, security). Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions.
|
||||
elicit: true
|
||||
custom_elicitation: infrastructure-overview
|
||||
template: |
|
||||
- Cloud Provider(s)
|
||||
- Core Services & Resources
|
||||
- Regional Architecture
|
||||
- Multi-environment Strategy
|
||||
examples:
|
||||
- |
|
||||
- **Cloud Provider:** AWS (primary), with multi-cloud capability for critical services
|
||||
- **Core Services:** EKS for container orchestration, RDS for databases, S3 for storage, CloudFront for CDN
|
||||
- **Regional Architecture:** Multi-region active-passive with primary in us-east-1, DR in us-west-2
|
||||
- **Multi-environment Strategy:** Development, Staging, UAT, Production with identical infrastructure patterns
|
||||
|
||||
- id: iac
|
||||
title: Infrastructure as Code (IaC)
|
||||
instruction: Define IaC approach based on technical preferences and existing patterns. Consider team expertise, tooling ecosystem, and maintenance requirements.
|
||||
template: |
|
||||
- Tools & Frameworks
|
||||
- Repository Structure
|
||||
- State Management
|
||||
- Dependency Management
|
||||
|
||||
<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
|
||||
|
||||
- id: environment-configuration
|
||||
title: Environment Configuration
|
||||
instruction: Design environment strategy that supports the development workflow while maintaining security and cost efficiency. Reference the Environment Transition Strategy section for promotion details.
|
||||
template: |
|
||||
- Environment Promotion Strategy
|
||||
- Configuration Management
|
||||
- Secret Management
|
||||
- Feature Flag Integration
|
||||
sections:
|
||||
- id: environments
|
||||
repeatable: true
|
||||
title: "{{environment_name}} Environment"
|
||||
template: |
|
||||
- **Purpose:** {{environment_purpose}}
|
||||
- **Resources:** {{environment_resources}}
|
||||
- **Access Control:** {{environment_access}}
|
||||
- **Data Classification:** {{environment_data_class}}
|
||||
|
||||
- id: environment-transition
|
||||
title: Environment Transition Strategy
|
||||
instruction: Detail the complete lifecycle of code and configuration changes from development to production. Include governance, testing gates, and rollback procedures.
|
||||
template: |
|
||||
- Development to Production Pipeline
|
||||
- Deployment Stages and Gates
|
||||
- Approval Workflows and Authorities
|
||||
- Rollback Procedures
|
||||
- Change Cadence and Release Windows
|
||||
- Environment-Specific Configuration Management
|
||||
|
||||
- id: network-architecture
|
||||
title: Network Architecture
|
||||
instruction: |
|
||||
Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
|
||||
|
||||
Create Mermaid diagram showing:
|
||||
- VPC/Network structure
|
||||
- Security zones and boundaries
|
||||
- Traffic flow patterns
|
||||
- Load balancer placement
|
||||
- Service mesh topology (if applicable)
|
||||
template: |
|
||||
- VPC/VNET Design
|
||||
- Subnet Strategy
|
||||
- Security Groups & NACLs
|
||||
- Load Balancers & API Gateways
|
||||
- Service Mesh (if applicable)
|
||||
sections:
|
||||
- id: network-diagram
|
||||
type: mermaid
|
||||
mermaid_type: graph
|
||||
template: |
|
||||
graph TB
|
||||
subgraph "Production VPC"
|
||||
subgraph "Public Subnets"
|
||||
ALB[Application Load Balancer]
|
||||
end
|
||||
subgraph "Private Subnets"
|
||||
EKS[EKS Cluster]
|
||||
RDS[(RDS Database)]
|
||||
end
|
||||
end
|
||||
Internet((Internet)) --> ALB
|
||||
ALB --> EKS
|
||||
EKS --> RDS
|
||||
- id: service-mesh
|
||||
title: Service Mesh Architecture
|
||||
condition: Uses service mesh
|
||||
template: |
|
||||
- **Mesh Technology:** {{service_mesh_tech}}
|
||||
- **Traffic Management:** {{traffic_policies}}
|
||||
- **Security Policies:** {{mesh_security}}
|
||||
- **Observability Integration:** {{mesh_observability}}
|
||||
|
||||
- id: compute-resources
|
||||
title: Compute Resources
|
||||
instruction: Select compute strategy based on application architecture (microservices, serverless, monolithic). Consider cost, scalability, and operational complexity.
|
||||
template: |
|
||||
- Container Strategy
|
||||
- Serverless Architecture
|
||||
- VM/Instance Configuration
|
||||
- Auto-scaling Approach
|
||||
sections:
|
||||
- id: kubernetes
|
||||
title: Kubernetes Architecture
|
||||
condition: Uses Kubernetes
|
||||
template: |
|
||||
- **Cluster Configuration:** {{k8s_cluster_config}}
|
||||
- **Node Groups:** {{k8s_node_groups}}
|
||||
- **Networking:** {{k8s_networking}}
|
||||
- **Storage Classes:** {{k8s_storage}}
|
||||
- **Security Policies:** {{k8s_security}}
|
||||
|
||||
- id: data-resources
|
||||
title: Data Resources
|
||||
instruction: |
|
||||
Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
|
||||
|
||||
Create data flow diagram showing:
|
||||
- Database topology
|
||||
- Replication patterns
|
||||
- Backup flows
|
||||
- Data migration paths
|
||||
template: |
|
||||
- Database Deployment Strategy
|
||||
- Backup & Recovery
|
||||
- Replication & Failover
|
||||
- Data Migration Strategy
|
||||
|
||||
- id: security-architecture
|
||||
title: Security Architecture
|
||||
instruction: Implement defense-in-depth strategy. Reference security requirements from PRD and compliance needs. Consider zero-trust principles where applicable.
|
||||
template: |
|
||||
- IAM & Authentication
|
||||
- Network Security
|
||||
- Data Encryption
|
||||
- Compliance Controls
|
||||
- Security Scanning & Monitoring
|
||||
|
||||
<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
|
||||
|
||||
- id: shared-responsibility
|
||||
title: Shared Responsibility Model
|
||||
instruction: Clearly define boundaries between cloud provider, platform team, development team, and security team responsibilities. This is critical for operational success.
|
||||
template: |
|
||||
- Cloud Provider Responsibilities
|
||||
- Platform Team Responsibilities
|
||||
- Development Team Responsibilities
|
||||
- Security Team Responsibilities
|
||||
- Operational Monitoring Ownership
|
||||
- Incident Response Accountability Matrix
|
||||
examples:
|
||||
- |
|
||||
| Component | Cloud Provider | Platform Team | Dev Team | Security Team |
|
||||
| -------------------- | -------------- | ------------- | -------------- | ------------- |
|
||||
| Physical Security | ✓ | - | - | Audit |
|
||||
| Network Security | Partial | ✓ | Config | Audit |
|
||||
| Application Security | - | Tools | ✓ | Review |
|
||||
| Data Encryption | Engine | Config | Implementation | Standards |
|
||||
|
||||
- id: monitoring-observability
|
||||
title: Monitoring & Observability
|
||||
instruction: Design comprehensive observability strategy covering metrics, logs, traces, and business KPIs. Ensure alignment with SLA/SLO requirements.
|
||||
template: |
|
||||
- Metrics Collection
|
||||
- Logging Strategy
|
||||
- Tracing Implementation
|
||||
- Alerting & Incident Response
|
||||
- Dashboards & Visualization
|
||||
|
||||
- id: cicd-pipeline
|
||||
title: CI/CD Pipeline
|
||||
instruction: |
|
||||
Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
|
||||
|
||||
Create pipeline diagram showing:
|
||||
- Build stages
|
||||
- Test gates
|
||||
- Deployment stages
|
||||
- Approval points
|
||||
- Rollback triggers
|
||||
template: |
|
||||
- Pipeline Architecture
|
||||
- Build Process
|
||||
- Deployment Strategy
|
||||
- Rollback Procedures
|
||||
- Approval Gates
|
||||
sections:
|
||||
- id: progressive-deployment
|
||||
title: Progressive Deployment Strategy
|
||||
condition: Uses progressive deployment
|
||||
template: |
|
||||
- **Canary Deployment:** {{canary_config}}
|
||||
- **Blue-Green Deployment:** {{blue_green_config}}
|
||||
- **Feature Flags:** {{feature_flag_integration}}
|
||||
- **Traffic Splitting:** {{traffic_split_rules}}
|
||||
|
||||
- id: disaster-recovery
|
||||
title: Disaster Recovery
|
||||
instruction: Design DR strategy based on business continuity requirements. Define clear RTO/RPO targets and ensure they align with business needs.
|
||||
template: |
|
||||
- Backup Strategy
|
||||
- Recovery Procedures
|
||||
- RTO & RPO Targets
|
||||
- DR Testing Approach
|
||||
|
||||
<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
|
||||
|
||||
- id: cost-optimization
|
||||
title: Cost Optimization
|
||||
instruction: Balance cost efficiency with performance and reliability requirements. Include both immediate optimizations and long-term strategies.
|
||||
template: |
|
||||
- Resource Sizing Strategy
|
||||
- Reserved Instances/Commitments
|
||||
- Cost Monitoring & Reporting
|
||||
- Optimization Recommendations
|
||||
|
||||
- id: bmad-integration
|
||||
title: BMad Integration Architecture
|
||||
instruction: Design infrastructure to specifically support other BMad agents and their workflows. This ensures the infrastructure enables the entire BMad methodology.
|
||||
sections:
|
||||
- id: dev-agent-support
|
||||
title: Development Agent Support
|
||||
template: |
|
||||
- Container platform for development environments
|
||||
- GitOps workflows for application deployment
|
||||
- Service mesh integration for development testing
|
||||
- Developer self-service platform capabilities
|
||||
- id: product-architecture-alignment
|
||||
title: Product & Architecture Alignment
|
||||
template: |
|
||||
- Infrastructure implementing PRD scalability requirements
|
||||
- Deployment automation supporting product iteration speed
|
||||
- Service reliability meeting product SLAs
|
||||
- Architecture patterns properly implemented in infrastructure
|
||||
- id: cross-agent-integration
|
||||
title: Cross-Agent Integration Points
|
||||
template: |
|
||||
- CI/CD pipelines supporting Frontend, Backend, and Full Stack development workflows
|
||||
- Monitoring and observability data accessible to QA and DevOps agents
|
||||
- Infrastructure enabling Design Architect's UI/UX performance requirements
|
||||
- Platform supporting Analyst's data collection and analysis needs
|
||||
|
||||
- id: feasibility-review
|
||||
title: DevOps/Platform Feasibility Review
|
||||
instruction: |
|
||||
CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
|
||||
|
||||
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
|
||||
- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
|
||||
- **Security Implementation:** Are security patterns achievable with current security toolchain?
|
||||
- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
|
||||
- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
|
||||
|
||||
Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
|
||||
|
||||
<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>
|
||||
sections:
|
||||
- id: feasibility-results
|
||||
title: Feasibility Assessment Results
|
||||
template: |
|
||||
- **Green Light Items:** {{feasible_items}}
|
||||
- **Yellow Light Items:** {{items_needing_adjustment}}
|
||||
- **Red Light Items:** {{items_requiring_redesign}}
|
||||
- **Mitigation Strategies:** {{mitigation_plans}}
|
||||
|
||||
- id: infrastructure-verification
|
||||
title: Infrastructure Verification
|
||||
sections:
|
||||
- id: validation-framework
|
||||
title: Validation Framework
|
||||
content: |
|
||||
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
|
||||
|
||||
- Completeness of architecture documentation
|
||||
- Consistency with broader system architecture
|
||||
- Appropriate level of detail for different stakeholders
|
||||
- Clear implementation guidance
|
||||
- Future evolution considerations
|
||||
- id: validation-process
|
||||
title: Validation Process
|
||||
content: |
|
||||
The architecture documentation validation should be performed:
|
||||
|
||||
- After initial architecture development
|
||||
- After significant architecture changes
|
||||
- Before major implementation phases
|
||||
- During periodic architecture reviews
|
||||
|
||||
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
|
||||
|
||||
- id: implementation-handoff
|
||||
title: Implementation Handoff
|
||||
instruction: Create structured handoff documentation for implementation team. This ensures architecture decisions are properly communicated and implemented.
|
||||
sections:
|
||||
- id: adrs
|
||||
title: Architecture Decision Records (ADRs)
|
||||
content: |
|
||||
Create ADRs for key infrastructure decisions:
|
||||
|
||||
- Cloud provider selection rationale
|
||||
- Container orchestration platform choice
|
||||
- Networking architecture decisions
|
||||
- Security implementation choices
|
||||
- Cost optimization trade-offs
|
||||
- id: implementation-validation
|
||||
title: Implementation Validation Criteria
|
||||
content: |
|
||||
Define specific criteria for validating correct implementation:
|
||||
|
||||
- Infrastructure as Code quality gates
|
||||
- Security compliance checkpoints
|
||||
- Performance benchmarks
|
||||
- Cost targets
|
||||
- Operational readiness criteria
|
||||
- id: knowledge-transfer
|
||||
title: Knowledge Transfer Requirements
|
||||
template: |
|
||||
- Technical documentation for operations team
|
||||
- Runbook creation requirements
|
||||
- Training needs for platform team
|
||||
- Handoff meeting agenda items
|
||||
|
||||
- id: infrastructure-evolution
|
||||
title: Infrastructure Evolution
|
||||
instruction: Document the long-term vision and evolution path for the infrastructure. Consider technology trends, anticipated growth, and technical debt management.
|
||||
template: |
|
||||
- Technical Debt Inventory
|
||||
- Planned Upgrades and Migrations
|
||||
- Deprecation Schedule
|
||||
- Technology Roadmap
|
||||
- Capacity Planning
|
||||
- Scalability Considerations
|
||||
|
||||
- id: app-integration
|
||||
title: Integration with Application Architecture
|
||||
instruction: Map infrastructure components to application services. Ensure infrastructure design supports application requirements and patterns defined in main architecture.
|
||||
template: |
|
||||
- Service-to-Infrastructure Mapping
|
||||
- Application Dependency Matrix
|
||||
- Performance Requirements Implementation
|
||||
- Security Requirements Implementation
|
||||
- Data Flow to Infrastructure Correlation
|
||||
- API Gateway and Service Mesh Integration
|
||||
|
||||
- id: cross-team-collaboration
|
||||
title: Cross-Team Collaboration
|
||||
instruction: Define clear interfaces and communication patterns between teams. This section is critical for operational success and should include specific touchpoints and escalation paths.
|
||||
template: |
|
||||
- Platform Engineer and Developer Touchpoints
|
||||
- Frontend/Backend Integration Requirements
|
||||
- Product Requirements to Infrastructure Mapping
|
||||
- Architecture Decision Impact Analysis
|
||||
- Design Architect UI/UX Infrastructure Requirements
|
||||
- Analyst Research Integration
|
||||
|
||||
- id: change-management
|
||||
title: Infrastructure Change Management
|
||||
instruction: Define structured process for infrastructure changes. Include risk assessment, testing requirements, and rollback procedures.
|
||||
template: |
|
||||
- Change Request Process
|
||||
- Risk Assessment
|
||||
- Testing Strategy
|
||||
- Validation Procedures
|
||||
|
||||
- id: final-review
|
||||
instruction: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.
|
||||
content: |
|
||||
---
|
||||
|
||||
_Document Version: 1.0_
|
||||
_Last Updated: {{current_date}}_
|
||||
_Next Review: {{review_date}}_
|
||||
Binary file not shown.
@@ -0,0 +1,629 @@
|
||||
template:
|
||||
id: infrastructure-platform-template-v2
|
||||
name: Platform Infrastructure Implementation
|
||||
version: 2.0
|
||||
output:
|
||||
format: markdown
|
||||
filename: docs/platform-infrastructure/platform-implementation.md
|
||||
title: "{{project_name}} Platform Infrastructure Implementation"
|
||||
|
||||
workflow:
|
||||
mode: interactive
|
||||
elicitation: advanced-elicitation
|
||||
custom_elicitation:
|
||||
title: "Platform Implementation Elicitation Actions"
|
||||
sections:
|
||||
- id: foundation-infrastructure
|
||||
options:
|
||||
- "Platform Layer Security Hardening - Additional security controls and compliance validation"
|
||||
- "Performance Optimization - Network and resource optimization"
|
||||
- "Operational Excellence Enhancement - Automation and monitoring improvements"
|
||||
- "Platform Integration Validation - Verify foundation supports upper layers"
|
||||
- "Developer Experience Analysis - Foundation impact on developer workflows"
|
||||
- "Disaster Recovery Testing - Foundation resilience validation"
|
||||
- "BMAD Workflow Integration - Cross-agent support verification"
|
||||
- "Finalize and Proceed to Container Platform"
|
||||
|
||||
sections:
|
||||
- id: initial-setup
|
||||
instruction: |
|
||||
Initial Setup
|
||||
|
||||
1. Replace {{project_name}} with the actual project name throughout the document
|
||||
2. Gather and review required inputs:
|
||||
- **Infrastructure Architecture Document** (Primary input - REQUIRED)
|
||||
- Infrastructure Change Request (if applicable)
|
||||
- Infrastructure Guidelines
|
||||
- Technology Stack Document
|
||||
- Infrastructure Checklist
|
||||
- NOTE: If Infrastructure Architecture Document is missing, HALT and request: "I need the Infrastructure Architecture Document to proceed with platform implementation. This document defines the infrastructure design that we'll be implementing."
|
||||
|
||||
3. Validate that the infrastructure architecture has been reviewed and approved
|
||||
4. <critical_rule>All platform implementation must align with the approved infrastructure architecture. Any deviations require architect approval.</critical_rule>
|
||||
|
||||
Output file location: `docs/platform-infrastructure/platform-implementation.md`
|
||||
|
||||
- id: executive-summary
|
||||
title: Executive Summary
|
||||
instruction: Provide a high-level overview of the platform infrastructure being implemented, referencing the infrastructure architecture document's key decisions and requirements.
|
||||
template: |
|
||||
- Platform implementation scope and objectives
|
||||
- Key architectural decisions being implemented
|
||||
- Expected outcomes and benefits
|
||||
- Timeline and milestones
|
||||
|
||||
- id: joint-planning
|
||||
title: Joint Planning Session with Architect
|
||||
instruction: Document the collaborative planning session between DevOps/Platform Engineer and Architect. This ensures alignment before implementation begins.
|
||||
sections:
|
||||
- id: architecture-alignment
|
||||
title: Architecture Alignment Review
|
||||
template: |
|
||||
- Review of infrastructure architecture document
|
||||
- Confirmation of design decisions
|
||||
- Identification of any ambiguities or gaps
|
||||
- Agreement on implementation approach
|
||||
- id: implementation-strategy
|
||||
title: Implementation Strategy Collaboration
|
||||
template: |
|
||||
- Platform layer sequencing
|
||||
- Technology stack validation
|
||||
- Integration approach between layers
|
||||
- Testing and validation strategy
|
||||
- id: risk-constraint
|
||||
title: Risk & Constraint Discussion
|
||||
template: |
|
||||
- Technical risks and mitigation strategies
|
||||
- Resource constraints and workarounds
|
||||
- Timeline considerations
|
||||
- Compliance and security requirements
|
||||
- id: validation-planning
|
||||
title: Implementation Validation Planning
|
||||
template: |
|
||||
- Success criteria for each platform layer
|
||||
- Testing approach and acceptance criteria
|
||||
- Rollback strategies
|
||||
- Communication plan
|
||||
- id: documentation-planning
|
||||
title: Documentation & Knowledge Transfer Planning
|
||||
template: |
|
||||
- Documentation requirements
|
||||
- Knowledge transfer approach
|
||||
- Training needs identification
|
||||
- Handoff procedures
|
||||
|
||||
- id: foundation-infrastructure
|
||||
title: Foundation Infrastructure Layer
|
||||
instruction: Implement the base infrastructure layer based on the infrastructure architecture. This forms the foundation for all platform services.
|
||||
elicit: true
|
||||
custom_elicitation: foundation-infrastructure
|
||||
sections:
|
||||
- id: cloud-provider-setup
|
||||
title: Cloud Provider Setup
|
||||
template: |
|
||||
- Account/Subscription configuration
|
||||
- Region selection and setup
|
||||
- Resource group/organizational structure
|
||||
- Cost management setup
|
||||
- id: network-foundation
|
||||
title: Network Foundation
|
||||
type: code
|
||||
language: hcl
|
||||
template: |
|
||||
# Example Terraform for VPC setup
|
||||
module "vpc" {
|
||||
source = "./modules/vpc"
|
||||
|
||||
cidr_block = "{{vpc_cidr}}"
|
||||
availability_zones = {{availability_zones}}
|
||||
public_subnets = {{public_subnets}}
|
||||
private_subnets = {{private_subnets}}
|
||||
}
|
||||
- id: security-foundation
|
||||
title: Security Foundation
|
||||
template: |
|
||||
- IAM roles and policies
|
||||
- Security groups and NACLs
|
||||
- Encryption keys (KMS/Key Vault)
|
||||
- Compliance controls
|
||||
- id: core-services
|
||||
title: Core Services
|
||||
template: |
|
||||
- DNS configuration
|
||||
- Certificate management
|
||||
- Logging infrastructure
|
||||
- Monitoring foundation
|
||||
|
||||
- id: container-platform
|
||||
title: Container Platform Implementation
|
||||
instruction: Build the container orchestration platform on top of the foundation infrastructure, following the architecture's container strategy.
|
||||
sections:
|
||||
- id: kubernetes-setup
|
||||
title: Kubernetes Cluster Setup
|
||||
sections:
|
||||
- id: eks-setup
|
||||
condition: Uses EKS
|
||||
type: code
|
||||
language: bash
|
||||
template: |
|
||||
# EKS Cluster Configuration
|
||||
eksctl create cluster \
|
||||
--name {{cluster_name}} \
|
||||
--region {{aws_region}} \
|
||||
--nodegroup-name {{nodegroup_name}} \
|
||||
--node-type {{instance_type}} \
|
||||
--nodes {{node_count}}
|
||||
- id: aks-setup
|
||||
condition: Uses AKS
|
||||
type: code
|
||||
language: bash
|
||||
template: |
|
||||
# AKS Cluster Configuration
|
||||
az aks create \
|
||||
--resource-group {{resource_group}} \
|
||||
--name {{cluster_name}} \
|
||||
--node-count {{node_count}} \
|
||||
--node-vm-size {{vm_size}} \
|
||||
--network-plugin azure
|
||||
- id: node-configuration
|
||||
title: Node Configuration
|
||||
template: |
|
||||
- Node groups/pools setup
|
||||
- Autoscaling configuration
|
||||
- Node security hardening
|
||||
- Resource quotas and limits
|
||||
- id: cluster-services
|
||||
title: Cluster Services
|
||||
template: |
|
||||
- CoreDNS configuration
|
||||
- Ingress controller setup
|
||||
- Certificate management
|
||||
- Storage classes
|
||||
- id: security-rbac
|
||||
title: Security & RBAC
|
||||
template: |
|
||||
- RBAC policies
|
||||
- Pod security policies/standards
|
||||
- Network policies
|
||||
- Secrets management
|
||||
|
||||
- id: gitops-workflow
|
||||
title: GitOps Workflow Implementation
|
||||
instruction: Implement GitOps patterns for declarative infrastructure and application management as defined in the architecture.
|
||||
sections:
|
||||
- id: gitops-tooling
|
||||
title: GitOps Tooling Setup
|
||||
sections:
|
||||
- id: argocd-setup
|
||||
condition: Uses ArgoCD
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: argocd
|
||||
namespace: argocd
|
||||
spec:
|
||||
source:
|
||||
repoURL: {{repo_url}}
|
||||
targetRevision: {{target_revision}}
|
||||
path: {{path}}
|
||||
- id: flux-setup
|
||||
condition: Uses Flux
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
apiVersion: source.toolkit.fluxcd.io/v1beta2
|
||||
kind: GitRepository
|
||||
metadata:
|
||||
name: flux-system
|
||||
namespace: flux-system
|
||||
spec:
|
||||
interval: 1m
|
||||
ref:
|
||||
branch: {{branch}}
|
||||
url: {{git_url}}
|
||||
- id: repository-structure
|
||||
title: Repository Structure
|
||||
type: code
|
||||
language: text
|
||||
template: |
|
||||
platform-gitops/
|
||||
clusters/
|
||||
production/
|
||||
staging/
|
||||
development/
|
||||
infrastructure/
|
||||
base/
|
||||
overlays/
|
||||
applications/
|
||||
base/
|
||||
overlays/
|
||||
- id: deployment-workflows
|
||||
title: Deployment Workflows
|
||||
template: |
|
||||
- Application deployment patterns
|
||||
- Progressive delivery setup
|
||||
- Rollback procedures
|
||||
- Multi-environment promotion
|
||||
- id: access-control
|
||||
title: Access Control
|
||||
template: |
|
||||
- Git repository permissions
|
||||
- GitOps tool RBAC
|
||||
- Secret management integration
|
||||
- Audit logging
|
||||
|
||||
- id: service-mesh
|
||||
title: Service Mesh Implementation
|
||||
instruction: Deploy service mesh for advanced traffic management, security, and observability as specified in the architecture.
|
||||
sections:
|
||||
- id: istio-mesh
|
||||
title: Istio Service Mesh
|
||||
condition: Uses Istio
|
||||
sections:
|
||||
- id: istio-install
|
||||
type: code
|
||||
language: bash
|
||||
template: |
|
||||
# Istio Installation
|
||||
istioctl install --set profile={{istio_profile}} \
|
||||
--set values.gateways.istio-ingressgateway.type={{ingress_type}}
|
||||
- id: istio-config
|
||||
template: |
|
||||
- Control plane configuration
|
||||
- Data plane injection
|
||||
- Gateway configuration
|
||||
- Observability integration
|
||||
- id: linkerd-mesh
|
||||
title: Linkerd Service Mesh
|
||||
condition: Uses Linkerd
|
||||
sections:
|
||||
- id: linkerd-install
|
||||
type: code
|
||||
language: bash
|
||||
template: |
|
||||
# Linkerd Installation
|
||||
linkerd install --cluster-name={{cluster_name}} | kubectl apply -f -
|
||||
linkerd viz install | kubectl apply -f -
|
||||
- id: linkerd-config
|
||||
template: |
|
||||
- Control plane setup
|
||||
- Proxy injection
|
||||
- Traffic policies
|
||||
- Metrics collection
|
||||
- id: traffic-management
|
||||
title: Traffic Management
|
||||
template: |
|
||||
- Load balancing policies
|
||||
- Circuit breakers
|
||||
- Retry policies
|
||||
- Canary deployments
|
||||
- id: security-policies
|
||||
title: Security Policies
|
||||
template: |
|
||||
- mTLS configuration
|
||||
- Authorization policies
|
||||
- Rate limiting
|
||||
- Network segmentation
|
||||
|
||||
- id: developer-experience
|
||||
title: Developer Experience Platform
|
||||
instruction: Build the developer self-service platform to enable efficient development workflows as outlined in the architecture.
|
||||
sections:
|
||||
- id: developer-portal
|
||||
title: Developer Portal
|
||||
template: |
|
||||
- Service catalog setup
|
||||
- API documentation
|
||||
- Self-service workflows
|
||||
- Resource provisioning
|
||||
- id: cicd-integration
|
||||
title: CI/CD Integration
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
apiVersion: tekton.dev/v1beta1
|
||||
kind: Pipeline
|
||||
metadata:
|
||||
name: platform-pipeline
|
||||
spec:
|
||||
tasks:
|
||||
- name: build
|
||||
taskRef:
|
||||
name: build-task
|
||||
- name: test
|
||||
taskRef:
|
||||
name: test-task
|
||||
- name: deploy
|
||||
taskRef:
|
||||
name: gitops-deploy
|
||||
- id: development-tools
|
||||
title: Development Tools
|
||||
template: |
|
||||
- Local development setup
|
||||
- Remote development environments
|
||||
- Testing frameworks
|
||||
- Debugging tools
|
||||
- id: self-service
|
||||
title: Self-Service Capabilities
|
||||
template: |
|
||||
- Environment provisioning
|
||||
- Database creation
|
||||
- Feature flag management
|
||||
- Configuration management
|
||||
|
||||
- id: platform-integration
|
||||
title: Platform Integration & Security Hardening
|
||||
instruction: Implement comprehensive platform-wide integration and security controls across all layers.
|
||||
sections:
|
||||
- id: end-to-end-security
|
||||
title: End-to-End Security
|
||||
template: |
|
||||
- Platform-wide security policies
|
||||
- Cross-layer authentication
|
||||
- Encryption in transit and at rest
|
||||
- Compliance validation
|
||||
- id: integrated-monitoring
|
||||
title: Integrated Monitoring
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: prometheus-config
|
||||
data:
|
||||
prometheus.yaml: |
|
||||
global:
|
||||
scrape_interval: {{scrape_interval}}
|
||||
scrape_configs:
|
||||
- job_name: 'kubernetes-pods'
|
||||
kubernetes_sd_configs:
|
||||
- role: pod
|
||||
- id: platform-observability
|
||||
title: Platform Observability
|
||||
template: |
|
||||
- Metrics aggregation
|
||||
- Log collection and analysis
|
||||
- Distributed tracing
|
||||
- Dashboard creation
|
||||
- id: backup-dr
|
||||
title: Backup & Disaster Recovery
|
||||
template: |
|
||||
- Platform backup strategy
|
||||
- Disaster recovery procedures
|
||||
- RTO/RPO validation
|
||||
- Recovery testing
|
||||
|
||||
- id: platform-operations
|
||||
title: Platform Operations & Automation
|
||||
instruction: Establish operational procedures and automation for platform management.
|
||||
sections:
|
||||
- id: monitoring-alerting
|
||||
title: Monitoring & Alerting
|
||||
template: |
|
||||
- SLA/SLO monitoring
|
||||
- Alert routing
|
||||
- Incident response
|
||||
- Performance baselines
|
||||
- id: automation-framework
|
||||
title: Automation Framework
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
apiVersion: operators.coreos.com/v1alpha1
|
||||
kind: ClusterServiceVersion
|
||||
metadata:
|
||||
name: platform-operator
|
||||
spec:
|
||||
customresourcedefinitions:
|
||||
owned:
|
||||
- name: platformconfigs.platform.io
|
||||
version: v1alpha1
|
||||
- id: maintenance-procedures
|
||||
title: Maintenance Procedures
|
||||
template: |
|
||||
- Upgrade procedures
|
||||
- Patch management
|
||||
- Certificate rotation
|
||||
- Capacity management
|
||||
- id: operational-runbooks
|
||||
title: Operational Runbooks
|
||||
template: |
|
||||
- Common operational tasks
|
||||
- Troubleshooting guides
|
||||
- Emergency procedures
|
||||
- Recovery playbooks
|
||||
|
||||
- id: bmad-workflow-integration
|
||||
title: BMAD Workflow Integration
|
||||
instruction: Validate that the platform supports all BMAD agent workflows and cross-functional requirements.
|
||||
sections:
|
||||
- id: development-agent-support
|
||||
title: Development Agent Support
|
||||
template: |
|
||||
- Frontend development workflows
|
||||
- Backend development workflows
|
||||
- Full-stack integration
|
||||
- Local development experience
|
||||
- id: iac-development
|
||||
title: Infrastructure-as-Code Development
|
||||
template: |
|
||||
- IaC development workflows
|
||||
- Testing frameworks
|
||||
- Deployment automation
|
||||
- Version control integration
|
||||
- id: cross-agent-collaboration
|
||||
title: Cross-Agent Collaboration
|
||||
template: |
|
||||
- Shared services access
|
||||
- Communication patterns
|
||||
- Data sharing mechanisms
|
||||
- Security boundaries
|
||||
- id: cicd-integration-workflow
|
||||
title: CI/CD Integration
|
||||
type: code
|
||||
language: yaml
|
||||
template: |
|
||||
stages:
|
||||
- analyze
|
||||
- plan
|
||||
- architect
|
||||
- develop
|
||||
- test
|
||||
- deploy
|
||||
|
||||
- id: platform-validation
|
||||
title: Platform Validation & Testing
|
||||
instruction: Execute comprehensive validation to ensure the platform meets all requirements.
|
||||
sections:
|
||||
- id: functional-testing
|
||||
title: Functional Testing
|
||||
template: |
|
||||
- Component testing
|
||||
- Integration testing
|
||||
- End-to-end testing
|
||||
- Performance testing
|
||||
- id: security-validation
|
||||
title: Security Validation
|
||||
template: |
|
||||
- Penetration testing
|
||||
- Compliance scanning
|
||||
- Vulnerability assessment
|
||||
- Access control validation
|
||||
- id: dr-testing
|
||||
title: Disaster Recovery Testing
|
||||
template: |
|
||||
- Backup restoration
|
||||
- Failover procedures
|
||||
- Recovery time validation
|
||||
- Data integrity checks
|
||||
- id: load-testing
|
||||
title: Load Testing
|
||||
type: code
|
||||
language: typescript
|
||||
template: |
|
||||
// K6 Load Test Example
|
||||
import http from 'k6/http';
|
||||
import { check } from 'k6';
|
||||
|
||||
export let options = {
|
||||
stages: [
|
||||
{ duration: '5m', target: {{target_users}} },
|
||||
{ duration: '10m', target: {{target_users}} },
|
||||
{ duration: '5m', target: 0 },
|
||||
],
|
||||
};
|
||||
|
||||
- id: knowledge-transfer
|
||||
title: Knowledge Transfer & Documentation
|
||||
instruction: Prepare comprehensive documentation and knowledge transfer materials.
|
||||
sections:
|
||||
- id: platform-documentation
|
||||
title: Platform Documentation
|
||||
template: |
|
||||
- Architecture documentation
|
||||
- Operational procedures
|
||||
- Configuration reference
|
||||
- API documentation
|
||||
- id: training-materials
|
||||
title: Training Materials
|
||||
template: |
|
||||
- Developer guides
|
||||
- Operations training
|
||||
- Security best practices
|
||||
- Troubleshooting guides
|
||||
- id: handoff-procedures
|
||||
title: Handoff Procedures
|
||||
template: |
|
||||
- Team responsibilities
|
||||
- Escalation procedures
|
||||
- Support model
|
||||
- Knowledge base
|
||||
|
||||
- id: implementation-review
|
||||
title: Implementation Review with Architect
|
||||
instruction: Document the post-implementation review session with the Architect to validate alignment and capture learnings.
|
||||
sections:
|
||||
- id: implementation-validation
|
||||
title: Implementation Validation
|
||||
template: |
|
||||
- Architecture alignment verification
|
||||
- Deviation documentation
|
||||
- Performance validation
|
||||
- Security review
|
||||
- id: lessons-learned
|
||||
title: Lessons Learned
|
||||
template: |
|
||||
- What went well
|
||||
- Challenges encountered
|
||||
- Process improvements
|
||||
- Technical insights
|
||||
- id: future-evolution
|
||||
title: Future Evolution
|
||||
template: |
|
||||
- Enhancement opportunities
|
||||
- Technical debt items
|
||||
- Upgrade planning
|
||||
- Capacity planning
|
||||
- id: sign-off
|
||||
title: Sign-off & Acceptance
|
||||
template: |
|
||||
- Architect approval
|
||||
- Stakeholder acceptance
|
||||
- Go-live authorization
|
||||
- Support transition
|
||||
|
||||
- id: platform-metrics
|
||||
title: Platform Metrics & KPIs
|
||||
instruction: Define and implement key performance indicators for platform success measurement.
|
||||
sections:
|
||||
- id: technical-metrics
|
||||
title: Technical Metrics
|
||||
template: |
|
||||
- Platform availability: {{availability_target}}
|
||||
- Response time: {{response_time_target}}
|
||||
- Resource utilization: {{utilization_target}}
|
||||
- Error rates: {{error_rate_target}}
|
||||
- id: business-metrics
|
||||
title: Business Metrics
|
||||
template: |
|
||||
- Developer productivity
|
||||
- Deployment frequency
|
||||
- Lead time for changes
|
||||
- Mean time to recovery
|
||||
- id: operational-metrics
|
||||
title: Operational Metrics
|
||||
template: |
|
||||
- Incident response time
|
||||
- Patch compliance
|
||||
- Cost per workload
|
||||
- Resource efficiency
|
||||
|
||||
- id: appendices
|
||||
title: Appendices
|
||||
sections:
|
||||
- id: config-reference
|
||||
title: A. Configuration Reference
|
||||
instruction: Document all configuration parameters and their values used in the platform implementation.
|
||||
- id: troubleshooting
|
||||
title: B. Troubleshooting Guide
|
||||
instruction: Provide common issues and their resolutions for platform operations.
|
||||
- id: security-controls
|
||||
title: C. Security Controls Matrix
|
||||
instruction: Map implemented security controls to compliance requirements.
|
||||
- id: integration-points
|
||||
title: D. Integration Points
|
||||
instruction: Document all integration points with external systems and services.
|
||||
|
||||
- id: final-review
|
||||
instruction: Final Review - Ensure all platform layers are properly implemented, integrated, and documented. Verify that the implementation fully supports the BMAD methodology and all agent workflows. Confirm successful validation against the infrastructure checklist.
|
||||
content: |
|
||||
---
|
||||
|
||||
_Platform Version: 1.0_
|
||||
_Implementation Date: {{implementation_date}}_
|
||||
_Next Review: {{review_date}}_
|
||||
_Approved by: {{architect_name}} (Architect), {{devops_name}} (DevOps/Platform Engineer)_
|
||||
Reference in New Issue
Block a user