mirror of
https://github.com/R0m1k3/xtremflow.git
synced 2026-10-22 14:38:06 +02:00
feat: security overhaul (proxy ssrf fix, streaming sanitization, docker optimization)
This commit is contained in:
Michael committed
1 parent
6d87ada2b8
commit
8df9a37baa
810 files changed
+131090
-151
No files matched your search
@@ -0,0 +1,140 @@
|
||||
# Create Tech-Spec - Spec Engineering for Game Development
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>Communicate in {communication_language}, tailored to {user_skill_level}</critical>
|
||||
<critical>Generate documents in {document_output_language}</critical>
|
||||
<critical>Conversational spec engineering - ask questions, investigate code, produce complete spec</critical>
|
||||
<critical>Spec must contain ALL context a fresh dev agent needs to implement it</critical>
|
||||
<critical>Focus on game-specific considerations: performance, feel, engine patterns</critical>
|
||||
|
||||
<checkpoint-handlers>
|
||||
<on-select key="a">Load and execute {advanced_elicitation}, then return to current step</on-select>
|
||||
<on-select key="p">Load and execute {party_mode_workflow}, then return to current step</on-select>
|
||||
<on-select key="b">Load and execute {quick_dev_workflow} with the tech-spec file</on-select>
|
||||
</checkpoint-handlers>
|
||||
|
||||
<step n="1" goal="Understand what the user wants to build">
|
||||
|
||||
<action>Greet {user_name} and ask them to describe what they want to build or change in their game.</action>
|
||||
|
||||
<action>Ask game-specific clarifying questions:
|
||||
|
||||
- What's the feature/mechanic?
|
||||
- How does it affect gameplay feel?
|
||||
- Performance requirements? (60fps critical path?)
|
||||
- Which game systems does it touch?
|
||||
- Existing code to integrate with?
|
||||
</action>
|
||||
|
||||
<action>Check for existing context in {output_folder} and {implementation_artifacts}</action>
|
||||
|
||||
<checkpoint title="Problem Understanding">
|
||||
[a] Advanced Elicitation [c] Continue [p] Party Mode
|
||||
</checkpoint>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Investigate existing game code (if applicable)">
|
||||
|
||||
<action>If brownfield: identify game engine (Unity/Unreal/Godot/custom)</action>
|
||||
|
||||
<action>Get file paths, read code, identify:
|
||||
|
||||
- Engine patterns and conventions
|
||||
- Existing game systems to integrate with
|
||||
- Performance-critical code paths
|
||||
- Test patterns if any
|
||||
</action>
|
||||
|
||||
<action>Document: engine version, code patterns, files to modify, system dependencies</action>
|
||||
|
||||
<checkpoint title="Context Gathered">
|
||||
[a] Advanced Elicitation [c] Continue [p] Party Mode
|
||||
</checkpoint>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Generate the technical specification">
|
||||
|
||||
<action>Create tech-spec using this game-focused structure:
|
||||
|
||||
```markdown
|
||||
# Tech-Spec: {title}
|
||||
|
||||
**Created:** {date}
|
||||
**Status:** Ready for Development
|
||||
**Engine:** {engine_name} {version}
|
||||
|
||||
## Overview
|
||||
|
||||
### Feature/Mechanic Description
|
||||
|
||||
### Gameplay Impact
|
||||
|
||||
### Scope (In/Out)
|
||||
|
||||
## Context for Development
|
||||
|
||||
### Engine Patterns
|
||||
|
||||
### Existing Systems Integration
|
||||
|
||||
### Files to Reference
|
||||
|
||||
### Technical Decisions
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
### Tasks
|
||||
|
||||
- [ ] Task 1: Description
|
||||
- [ ] Task 2: Description
|
||||
|
||||
### Performance Considerations
|
||||
|
||||
- Frame budget impact
|
||||
- Memory considerations
|
||||
- Critical path notes
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
- [ ] AC 1: Given/When/Then (include feel/responsiveness criteria)
|
||||
- [ ] AC 2: ...
|
||||
|
||||
## Additional Context
|
||||
|
||||
### Dependencies
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
### Notes
|
||||
```
|
||||
|
||||
</action>
|
||||
|
||||
<action>Save to {implementation_artifacts}/tech-spec-{slug}.md</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Review and finalize">
|
||||
|
||||
<action>Present spec to {user_name}, ask if it captures intent, make changes as needed</action>
|
||||
|
||||
<output>**Tech-Spec Complete!** 🎮
|
||||
|
||||
Saved to: {implementation_artifacts}/tech-spec-{slug}.md
|
||||
|
||||
[a] Advanced Elicitation - refine further
|
||||
[b] Begin Development (not recommended - fresh context better)
|
||||
[d] Done - exit
|
||||
[p] Party Mode - get feedback
|
||||
|
||||
**Recommended:** Run `quick-dev` in fresh context with this spec.
|
||||
</output>
|
||||
|
||||
<ask>Choice (a/b/d/p):</ask>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,26 @@
|
||||
# Quick-Flow: Create Tech-Spec (Game Development)
|
||||
name: create-tech-spec
|
||||
description: "Conversational spec engineering for games - ask questions, investigate code, produce implementation-ready tech-spec."
|
||||
author: "BMad"
|
||||
|
||||
# Config
|
||||
config_source: "{project-root}/_bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:game_dev_experience"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmgd/workflows/bmgd-quick-flow/create-tech-spec"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
|
||||
# Related workflows
|
||||
quick_dev_workflow: "{project-root}/_bmad/bmgd/workflows/bmgd-quick-flow/quick-dev/workflow.yaml"
|
||||
quick_prototype_workflow: "{project-root}/_bmad/bmgd/workflows/bmgd-quick-flow/quick-prototype/workflow.yaml"
|
||||
party_mode_exec: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
|
||||
advanced_elicitation: "{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml"
|
||||
|
||||
standalone: true
|
||||
@@ -0,0 +1,37 @@
|
||||
# Quick-Dev Checklist (Game Development)
|
||||
|
||||
## Before Implementation
|
||||
|
||||
- [ ] Context loaded (tech-spec, prototype, or user guidance)
|
||||
- [ ] Files to modify identified
|
||||
- [ ] Game systems affected understood
|
||||
- [ ] Patterns and conventions identified
|
||||
|
||||
## Implementation
|
||||
|
||||
- [ ] All tasks completed
|
||||
- [ ] Code follows existing patterns
|
||||
- [ ] Error handling appropriate
|
||||
- [ ] Performance considerations addressed
|
||||
|
||||
## Game-Specific Checks
|
||||
|
||||
- [ ] No allocations in hot paths (game loop, update, render)
|
||||
- [ ] Object pooling used where appropriate
|
||||
- [ ] Input feels responsive
|
||||
- [ ] Visual/audio feedback present
|
||||
- [ ] Frame rate maintained at target
|
||||
|
||||
## Testing
|
||||
|
||||
- [ ] Game runs without errors
|
||||
- [ ] Feature works as specified
|
||||
- [ ] Related systems still work (no regressions)
|
||||
- [ ] Manual playtest completed
|
||||
|
||||
## Completion
|
||||
|
||||
- [ ] Acceptance criteria satisfied
|
||||
- [ ] Tech-spec updated (if applicable)
|
||||
- [ ] Summary provided to user
|
||||
- [ ] Performance acceptable
|
||||
@@ -0,0 +1,220 @@
|
||||
# Quick-Dev - Flexible Game Development Workflow
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>Communicate in {communication_language}, tailored to {user_skill_level}</critical>
|
||||
<critical>Execute continuously until COMPLETE - do not stop for milestones</critical>
|
||||
<critical>Game-specific: Consider performance (60fps), feel, and player experience</critical>
|
||||
<critical>ALWAYS respect {project_context} if it exists - it defines project standards</critical>
|
||||
|
||||
<checkpoint-handlers>
|
||||
<on-select key="a">Load and execute {advanced_elicitation}, then return</on-select>
|
||||
<on-select key="p">Load and execute {party_mode_exec}, then return</on-select>
|
||||
<on-select key="r">Load and execute {quick_prototype_workflow}</on-select>
|
||||
</checkpoint-handlers>
|
||||
|
||||
<step n="1" goal="Load context and determine execution mode">
|
||||
|
||||
<action>Check if {project_context} exists. If yes, load it - this is your foundational reference for ALL implementation decisions (patterns, conventions, architecture).</action>
|
||||
|
||||
<action>Parse user input:
|
||||
|
||||
**Mode A: Tech-Spec** - e.g., `quick-dev tech-spec-combat.md`
|
||||
→ Load spec, extract tasks/context/AC, goto step 3
|
||||
|
||||
**Mode B: Direct Instructions** - e.g., `implement player jump...`
|
||||
→ Evaluate complexity, offer planning choice
|
||||
|
||||
**Mode C: Prototype Reference** - e.g., `quick-dev from prototype...`
|
||||
→ Load prototype code, productionize
|
||||
</action>
|
||||
|
||||
<check if="Mode A">
|
||||
<action>Load tech-spec, extract tasks/context/AC</action>
|
||||
<goto>step_3</goto>
|
||||
</check>
|
||||
|
||||
<check if="Mode C">
|
||||
<action>Load prototype reference, identify production requirements</action>
|
||||
<goto>step_2</goto>
|
||||
</check>
|
||||
|
||||
<check if="Mode B">
|
||||
|
||||
<action>Evaluate complexity against game development signals:
|
||||
|
||||
**Triggers planning** (if 2+ signals present):
|
||||
|
||||
- Multiple game systems (e.g., combat + inventory + UI)
|
||||
- Performance-critical code (e.g., game loop, rendering, physics)
|
||||
- Cross-platform considerations
|
||||
- Multiplayer/networking
|
||||
- Save system integration
|
||||
|
||||
**Simple enough for direct execution:**
|
||||
|
||||
- Single mechanic adjustment
|
||||
- UI tweak
|
||||
- Bug fix
|
||||
- Asset integration
|
||||
- Config/balance change
|
||||
</action>
|
||||
|
||||
<check if="complex task">
|
||||
<ask>This looks like a significant game feature.
|
||||
|
||||
**[t] Plan first** - Create tech-spec then implement (recommended)
|
||||
**[r] Prototype first** - Test the idea before committing
|
||||
**[w] Use full BMGD workflow** - For larger features
|
||||
**[e] Execute directly** - Start implementation now</ask>
|
||||
|
||||
<check if="t">
|
||||
<action>Create lightweight tech-spec with tasks and AC</action>
|
||||
<goto>step_3</goto>
|
||||
</check>
|
||||
|
||||
<check if="r">
|
||||
<action>Load and execute {quick_prototype_workflow}</action>
|
||||
<action>Return here after prototype complete</action>
|
||||
</check>
|
||||
|
||||
<check if="w">
|
||||
<action>Load and execute {workflow_init}</action>
|
||||
<action>EXIT quick-dev - user routed to full workflow</action>
|
||||
</check>
|
||||
|
||||
<check if="e">
|
||||
<goto>step_2</goto>
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="simple task">
|
||||
<ask>**[e] Execute directly** - Start now
|
||||
**[t] Quick plan** - Brief task breakdown first</ask>
|
||||
|
||||
<check if="e">
|
||||
<goto>step_2</goto>
|
||||
</check>
|
||||
|
||||
<check if="t">
|
||||
<action>Create quick task list</action>
|
||||
<goto>step_3</goto>
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Quick context gathering">
|
||||
|
||||
<action>Identify scope:
|
||||
|
||||
- Files to modify
|
||||
- Game systems affected
|
||||
- Performance considerations
|
||||
- Existing patterns to follow
|
||||
</action>
|
||||
|
||||
<action>Create mental plan:
|
||||
|
||||
- Tasks to complete
|
||||
- Acceptance criteria
|
||||
- Test approach (manual playtest, unit tests, etc.)
|
||||
</action>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Execute implementation" id="step_3">
|
||||
|
||||
<action>For each task:
|
||||
|
||||
1. **Load Context** - Read relevant files, understand integration points
|
||||
2. **Implement** - Follow patterns, consider performance, handle edge cases
|
||||
3. **Test** - Run game, verify behavior, check frame rate impact
|
||||
4. **Mark Complete** - Check off task [x], continue
|
||||
</action>
|
||||
|
||||
<action>Game-specific checks during implementation:
|
||||
|
||||
**Performance:**
|
||||
|
||||
- Avoid allocations in hot paths
|
||||
- Use object pooling where appropriate
|
||||
- Profile if frame time increases
|
||||
|
||||
**Feel:**
|
||||
|
||||
- Test input responsiveness
|
||||
- Verify visual/audio feedback
|
||||
- Check timing and pacing
|
||||
|
||||
**Integration:**
|
||||
|
||||
- Verify save/load compatibility
|
||||
- Check multiplayer sync (if applicable)
|
||||
- Test on target platform
|
||||
</action>
|
||||
|
||||
<action if="3 failures">HALT and request guidance</action>
|
||||
<action if="tests fail">Fix before continuing</action>
|
||||
<action if="frame rate drops">Profile and optimize before continuing</action>
|
||||
|
||||
<critical>Continue through ALL tasks without stopping</critical>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Verify and complete">
|
||||
|
||||
<action>Verify completion:
|
||||
|
||||
- All tasks [x]
|
||||
- Game runs without errors
|
||||
- Feature works as specified
|
||||
- Performance acceptable (target frame rate maintained)
|
||||
- Patterns followed
|
||||
</action>
|
||||
|
||||
<check if="using tech-spec">
|
||||
<action>Update tech-spec status to "Completed", mark all tasks [x]</action>
|
||||
</check>
|
||||
|
||||
<output>**Implementation Complete!**
|
||||
|
||||
**Summary:** {{implementation_summary}}
|
||||
**Files Modified:** {{files_list}}
|
||||
**Tests:** {{test_summary}}
|
||||
**Performance:** {{performance_notes}}
|
||||
**AC Status:** {{ac_status}}
|
||||
|
||||
---
|
||||
|
||||
**Recommended: Playtest the changes**
|
||||
|
||||
Run the game and verify:
|
||||
|
||||
- Feature works as expected
|
||||
- No regressions in related systems
|
||||
- Performance is acceptable
|
||||
- Feel is right
|
||||
|
||||
**Before committing: Consider a code review**
|
||||
|
||||
```
|
||||
You are a senior game developer reviewing code for a game project. These changes were just implemented. Look for:
|
||||
1. Performance issues (allocations in loops, unnecessary calculations)
|
||||
2. Game feel problems (timing, feedback, responsiveness)
|
||||
3. Integration issues (save system, multiplayer, platform)
|
||||
4. Code quality (patterns, readability, maintainability)
|
||||
Find at least 3 issues or improvements.
|
||||
```
|
||||
|
||||
</output>
|
||||
|
||||
<action>Explain what was implemented based on {user_skill_level}</action>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,44 @@
|
||||
# Quick-Flow: Quick-Dev (Game Development)
|
||||
name: quick-dev
|
||||
description: "Flexible game development - execute tech-specs, implement features, or refactor code with game-specific considerations."
|
||||
author: "BMad"
|
||||
|
||||
# Config
|
||||
config_source: "{project-root}/_bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:game_dev_experience"
|
||||
date: system-generated
|
||||
|
||||
# Project context
|
||||
project_context: "**/project-context.md"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmgd/workflows/bmgd-quick-flow/quick-dev"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
checklist: "{installed_path}/checklist.md"
|
||||
|
||||
# Related workflows
|
||||
quick_prototype_workflow: "{project-root}/_bmad/bmgd/workflows/bmgd-quick-flow/quick-prototype/workflow.yaml"
|
||||
party_mode_exec: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
|
||||
advanced_elicitation: "{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml"
|
||||
|
||||
# Routing resources (lazy-loaded)
|
||||
workflow_init: "{project-root}/_bmad/bmgd/workflows/workflow-status/init/workflow.yaml"
|
||||
|
||||
# Game-specific input patterns
|
||||
input_file_patterns:
|
||||
gdd:
|
||||
description: "Game Design Document"
|
||||
whole: "{output_folder}/*gdd*.md"
|
||||
sharded: "{output_folder}/*gdd*/*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
architecture:
|
||||
description: "Game architecture and technical decisions"
|
||||
whole: "{output_folder}/*architecture*.md"
|
||||
sharded: "{output_folder}/*architecture*/*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
standalone: true
|
||||
@@ -0,0 +1,26 @@
|
||||
# Quick-Prototype Checklist
|
||||
|
||||
## Before Prototyping
|
||||
|
||||
- [ ] Prototype scope defined (mechanic/feature/system)
|
||||
- [ ] Success criteria established (2-3 testable items)
|
||||
- [ ] Existing code/patterns identified (if applicable)
|
||||
|
||||
## Implementation
|
||||
|
||||
- [ ] Minimum viable code written
|
||||
- [ ] Placeholder assets used (no polish needed)
|
||||
- [ ] Core functionality testable
|
||||
- [ ] Temporary code clearly marked
|
||||
|
||||
## Playtest
|
||||
|
||||
- [ ] Each success criterion evaluated
|
||||
- [ ] Feel/behavior noted
|
||||
- [ ] Observations documented
|
||||
|
||||
## Completion
|
||||
|
||||
- [ ] Decision made (develop/iterate/archive)
|
||||
- [ ] Learnings captured
|
||||
- [ ] Next steps clear
|
||||
@@ -0,0 +1,156 @@
|
||||
# Quick-Prototype - Rapid Game Prototyping Workflow
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>Communicate in {communication_language}, tailored to {user_skill_level}</critical>
|
||||
<critical>Focus on PLAYABLE outcomes - get something testable fast</critical>
|
||||
<critical>Prototype first, polish later - embrace programmer art</critical>
|
||||
<critical>ALWAYS respect {project_context} if it exists - it defines project standards</critical>
|
||||
|
||||
<checkpoint-handlers>
|
||||
<on-select key="a">Load and execute {advanced_elicitation}, then return</on-select>
|
||||
<on-select key="p">Load and execute {party_mode_exec}, then return</on-select>
|
||||
<on-select key="d">Load and execute {quick_dev_workflow}</on-select>
|
||||
</checkpoint-handlers>
|
||||
|
||||
<step n="1" goal="Understand what to prototype">
|
||||
|
||||
<action>Check if {project_context} exists. If yes, load it for project conventions.</action>
|
||||
|
||||
<action>Parse user input to determine prototype scope:
|
||||
|
||||
**Mechanic Prototype** - Testing a specific game mechanic
|
||||
→ Focus on feel, feedback, core loop
|
||||
|
||||
**Feature Prototype** - Testing a game feature
|
||||
→ Focus on functionality, integration
|
||||
|
||||
**Visual Prototype** - Testing look and feel
|
||||
→ Focus on art direction, UI/UX
|
||||
|
||||
**System Prototype** - Testing a game system
|
||||
→ Focus on data flow, balance hooks
|
||||
</action>
|
||||
|
||||
<ask>**What are you prototyping?**
|
||||
|
||||
Describe the mechanic, feature, or system you want to test. Be specific about:
|
||||
|
||||
- What player action or behavior you're testing
|
||||
- What "feeling right" looks like
|
||||
- Any constraints (engine, platform, existing code)</ask>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Define success criteria">
|
||||
|
||||
<action>Based on prototype type, establish testable success criteria:
|
||||
|
||||
**For Mechanics:**
|
||||
|
||||
- Does the input feel responsive?
|
||||
- Is the feedback clear?
|
||||
- Is it fun to repeat?
|
||||
|
||||
**For Features:**
|
||||
|
||||
- Does it work as expected?
|
||||
- Does it integrate with existing systems?
|
||||
- Can a player understand it?
|
||||
|
||||
**For Systems:**
|
||||
|
||||
- Is the data flowing correctly?
|
||||
- Are the hooks in place for tuning?
|
||||
- Does it scale?
|
||||
</action>
|
||||
|
||||
<ask>**What makes this prototype successful?**
|
||||
|
||||
Define 2-3 specific, testable criteria. For example:
|
||||
|
||||
- "Player can jump and it feels snappy"
|
||||
- "Inventory shows correct item counts"
|
||||
- "Enemy spawner creates waves correctly"</ask>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Rapid implementation">
|
||||
|
||||
<action>Implement the prototype with these principles:
|
||||
|
||||
1. **Minimum Viable Prototype** - Only what's needed to test the idea
|
||||
2. **Hardcode First** - Magic numbers are fine, extract later
|
||||
3. **Skip Edge Cases** - Happy path only for now
|
||||
4. **Placeholder Everything** - Cubes, debug text, temp sounds
|
||||
5. **Comment Intent** - Mark what's temporary vs keeper code
|
||||
</action>
|
||||
|
||||
<action>For each implementation step:
|
||||
|
||||
1. **Create/Modify** - Write the minimum code
|
||||
2. **Test Immediately** - Run and verify
|
||||
3. **Iterate Quickly** - Adjust based on feel
|
||||
4. **Mark Progress** - Note what works
|
||||
</action>
|
||||
|
||||
<critical>Speed over perfection - you're testing an IDEA, not shipping code</critical>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Playtest and evaluate">
|
||||
|
||||
<action>Run through the success criteria:
|
||||
|
||||
For each criterion:
|
||||
|
||||
- [ ] Pass/Fail status
|
||||
- [ ] Notes on feel/behavior
|
||||
- [ ] Ideas for improvement
|
||||
</action>
|
||||
|
||||
<output>**Prototype Complete!**
|
||||
|
||||
**What was built:** {{prototype_summary}}
|
||||
**Files Created/Modified:** {{files_list}}
|
||||
|
||||
**Success Criteria Results:**
|
||||
{{criteria_results}}
|
||||
|
||||
**Observations:**
|
||||
{{playtest_notes}}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
- [d] **Develop further** - Use quick-dev for production implementation
|
||||
- [i] **Iterate** - Adjust and re-test
|
||||
- [a] **Archive** - Keep as reference, move on
|
||||
</output>
|
||||
|
||||
<ask>**How did the prototype feel?**
|
||||
|
||||
Share your playtest observations. What worked? What didn't?
|
||||
What's the next action?
|
||||
|
||||
**[d]** Develop this into production code
|
||||
**[i]** Iterate on the prototype
|
||||
**[a]** Archive and move on</ask>
|
||||
|
||||
<check if="d">
|
||||
<action>Load and execute {quick_dev_workflow} with prototype as reference</action>
|
||||
</check>
|
||||
|
||||
<check if="i">
|
||||
<goto>step_3</goto>
|
||||
</check>
|
||||
|
||||
<check if="a">
|
||||
<action>Document learnings, mark prototype as archived</action>
|
||||
<output>**Prototype Archived**
|
||||
|
||||
Learnings documented. When ready for production, use `quick-dev` with this prototype as reference.</output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,35 @@
|
||||
# Quick-Flow: Quick-Prototype (Game Development)
|
||||
name: quick-prototype
|
||||
description: "Rapid game prototyping - quickly test gameplay ideas, mechanics, or features with minimal setup."
|
||||
author: "BMad"
|
||||
|
||||
# Config
|
||||
config_source: "{project-root}/_bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:game_dev_experience"
|
||||
date: system-generated
|
||||
|
||||
# Project context
|
||||
project_context: "**/project-context.md"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmgd/workflows/bmgd-quick-flow/quick-prototype"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
checklist: "{installed_path}/checklist.md"
|
||||
|
||||
# Related workflows
|
||||
quick_dev_workflow: "{project-root}/_bmad/bmgd/workflows/bmgd-quick-flow/quick-dev/workflow.yaml"
|
||||
party_mode_exec: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
|
||||
advanced_elicitation: "{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml"
|
||||
|
||||
# Game-specific references
|
||||
gdd_patterns:
|
||||
whole: "{output_folder}/*gdd*.md"
|
||||
sharded: "{output_folder}/*gdd*/*.md"
|
||||
architecture_patterns:
|
||||
whole: "{output_folder}/*architecture*.md"
|
||||
|
||||
standalone: true
|
||||
Reference in new issue
Block a user