Compare commits
1 Commits
a2b3dd666e
...
265fde7cd9
| Author | SHA1 | Date |
|---|---|---|
Alex Verkhovsky
|
265fde7cd9 |
20
CHANGELOG.md
20
CHANGELOG.md
|
|
@ -1,25 +1,5 @@
|
||||||
# Changelog
|
# Changelog
|
||||||
|
|
||||||
## [6.0.0-alpha.19]
|
|
||||||
|
|
||||||
**Release: December 18, 2025**
|
|
||||||
|
|
||||||
### 🐛 Bug Fixes
|
|
||||||
|
|
||||||
**Installer Stability:**
|
|
||||||
|
|
||||||
- **Fixed \_bmad Folder Stutter**: Resolved issue with duplicate \_bmad folder creation when applying agent custom files
|
|
||||||
- **Cleaner Installation**: Removed unnecessary backup file that was causing bloat in the installer
|
|
||||||
- **Streamlined Agent Customization**: Fixed path handling for agent custom files to prevent folder duplication
|
|
||||||
|
|
||||||
### 📊 Statistics
|
|
||||||
|
|
||||||
- **3 files changed** with critical fix
|
|
||||||
- **3,688 lines removed** by eliminating backup files
|
|
||||||
- **Improved installer performance** and stability
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## [6.0.0-alpha.18]
|
## [6.0.0-alpha.18]
|
||||||
|
|
||||||
**Release: December 18, 2025**
|
**Release: December 18, 2025**
|
||||||
|
|
|
||||||
|
|
@ -231,8 +231,6 @@ MIT License - See [LICENSE](LICENSE) for details.
|
||||||
|
|
||||||
**Trademarks:** BMad™ and BMAD-METHOD™ are trademarks of BMad Code, LLC.
|
**Trademarks:** BMad™ and BMAD-METHOD™ are trademarks of BMad Code, LLC.
|
||||||
|
|
||||||
Supported by: <a href="https://m.do.co/c/00f11bd932bb"><img src="https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/SVG/DO_Logo_horizontal_blue.svg" height="24" alt="DigitalOcean" style="vertical-align: middle;"></a>
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
<p align="center">
|
<p align="center">
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
{
|
{
|
||||||
"$schema": "https://json.schemastore.org/package.json",
|
"$schema": "https://json.schemastore.org/package.json",
|
||||||
"name": "bmad-method",
|
"name": "bmad-method",
|
||||||
"version": "6.0.0-alpha.19",
|
"version": "6.0.0-alpha.18",
|
||||||
"description": "Breakthrough Method of Agile AI-driven Development",
|
"description": "Breakthrough Method of Agile AI-driven Development",
|
||||||
"keywords": [
|
"keywords": [
|
||||||
"agile",
|
"agile",
|
||||||
|
|
|
||||||
|
|
@ -1,82 +0,0 @@
|
||||||
<task id="_bmad/core/tasks/review-adversarial-general.xml" name="Adversarial Review (General)">
|
|
||||||
<objective>Cynically review content and produce numbered findings with severity and classification</objective>
|
|
||||||
|
|
||||||
<inputs>
|
|
||||||
<input name="content" desc="Content to review - diff, spec, story, doc, or any artifact" />
|
|
||||||
</inputs>
|
|
||||||
|
|
||||||
<llm critical="true">
|
|
||||||
<i>You are a cynical, jaded reviewer with zero patience for sloppy work</i>
|
|
||||||
<i>The content was submitted by a clueless weasel and you expect to find problems</i>
|
|
||||||
<i>Find at least five issues to fix or improve - be skeptical of everything</i>
|
|
||||||
<i>Zero findings is suspicious - if you find nothing, halt and question your analysis</i>
|
|
||||||
</llm>
|
|
||||||
|
|
||||||
<flow>
|
|
||||||
<step n="1" title="Receive Content">
|
|
||||||
<action>Load the content to review from provided input or context</action>
|
|
||||||
<action>Identify content type (diff, spec, story, doc, etc.) to calibrate review approach</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" title="Adversarial Analysis" critical="true">
|
|
||||||
<mandate>Review with extreme skepticism - assume problems exist</mandate>
|
|
||||||
|
|
||||||
<analysis-areas>
|
|
||||||
<area>Correctness - Is it actually right? Look for logic errors, bugs, gaps</area>
|
|
||||||
<area>Completeness - What's missing? Edge cases, error handling, validation</area>
|
|
||||||
<area>Consistency - Does it match patterns, conventions, existing code?</area>
|
|
||||||
<area>Clarity - Is it understandable? Naming, structure, documentation</area>
|
|
||||||
<area>Quality - Is it good enough? Performance, security, maintainability</area>
|
|
||||||
</analysis-areas>
|
|
||||||
|
|
||||||
<action>Find at least 5 issues - dig deep, don't accept surface-level "looks good"</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" title="Classify Findings">
|
|
||||||
<action>For each finding, assign:</action>
|
|
||||||
|
|
||||||
<finding-id>F1, F2, F3... (sequential)</finding-id>
|
|
||||||
|
|
||||||
<severity>
|
|
||||||
<level name="critical">Must fix - blocks ship, causes failures</level>
|
|
||||||
<level name="high">Should fix - significant issue, notable risk</level>
|
|
||||||
<level name="medium">Consider fixing - minor issue, small improvement</level>
|
|
||||||
<level name="low">Nitpick - optional, stylistic, nice-to-have</level>
|
|
||||||
</severity>
|
|
||||||
|
|
||||||
<classification>
|
|
||||||
<type name="real">Confirmed issue - should address</type>
|
|
||||||
<type name="noise">False positive - no action needed</type>
|
|
||||||
<type name="uncertain">Needs discussion - could go either way</type>
|
|
||||||
</classification>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" title="Present Findings">
|
|
||||||
<action>Output findings in structured format</action>
|
|
||||||
</step>
|
|
||||||
</flow>
|
|
||||||
|
|
||||||
<findings-format>
|
|
||||||
**Adversarial Review Findings**
|
|
||||||
|
|
||||||
| ID | Severity | Classification | Finding |
|
|
||||||
|----|----------|----------------|---------|
|
|
||||||
| F1 | {severity} | {classification} | {description} |
|
|
||||||
| F2 | {severity} | {classification} | {description} |
|
|
||||||
| ... | | | |
|
|
||||||
|
|
||||||
**Summary:** {count} findings - {critical_count} critical, {high_count} high, {medium_count} medium, {low_count} low
|
|
||||||
</findings-format>
|
|
||||||
|
|
||||||
<halt-conditions>
|
|
||||||
<condition>HALT if zero findings - this is suspicious, re-analyze or ask for guidance</condition>
|
|
||||||
<condition>HALT if content is empty or unreadable</condition>
|
|
||||||
</halt-conditions>
|
|
||||||
|
|
||||||
<critical-rules>
|
|
||||||
<rule>NEVER accept "looks good" without deep analysis</rule>
|
|
||||||
<rule>ALWAYS find at least 5 issues - if you can't, you're not looking hard enough</rule>
|
|
||||||
<rule>ALWAYS assign ID, severity, and classification to each finding</rule>
|
|
||||||
<rule>Be cynical but fair - classify noise as noise, real as real</rule>
|
|
||||||
</critical-rules>
|
|
||||||
</task>
|
|
||||||
|
|
@ -33,10 +33,6 @@ agent:
|
||||||
exec: "{project-root}/_bmad/bmgd/workflows/3-technical/game-architecture/workflow.md"
|
exec: "{project-root}/_bmad/bmgd/workflows/3-technical/game-architecture/workflow.md"
|
||||||
description: Produce a Scale Adaptive Game Architecture
|
description: Produce a Scale Adaptive Game Architecture
|
||||||
|
|
||||||
- trigger: generate-project-context
|
|
||||||
exec: "{project-root}/_bmad/bmgd/workflows/3-technical/generate-project-context/workflow.md"
|
|
||||||
description: Create optimized project-context.md for AI agent consistency
|
|
||||||
|
|
||||||
- trigger: correct-course
|
- trigger: correct-course
|
||||||
workflow: "{project-root}/_bmad/bmgd/workflows/4-production/correct-course/workflow.yaml"
|
workflow: "{project-root}/_bmad/bmgd/workflows/4-production/correct-course/workflow.yaml"
|
||||||
description: Course Correction Analysis (when implementation is off-track)
|
description: Course Correction Analysis (when implementation is off-track)
|
||||||
|
|
|
||||||
|
|
@ -12,7 +12,6 @@ outputFile: '{output_folder}/game-architecture.md'
|
||||||
|
|
||||||
# Handoff References
|
# Handoff References
|
||||||
epicWorkflow: '{project-root}/_bmad/bmgd/workflows/4-production/epic-workflow/workflow.yaml'
|
epicWorkflow: '{project-root}/_bmad/bmgd/workflows/4-production/epic-workflow/workflow.yaml'
|
||||||
projectContextWorkflow: '{project-root}/_bmad/bmgd/workflows/3-technical/generate-project-context/workflow.md'
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step 9: Completion
|
# Step 9: Completion
|
||||||
|
|
@ -132,17 +131,7 @@ platform: '{{platform}}'
|
||||||
---
|
---
|
||||||
````
|
````
|
||||||
|
|
||||||
### 4. Update Workflow Status
|
### 4. Present Completion Summary
|
||||||
|
|
||||||
**If not in standalone mode:**
|
|
||||||
|
|
||||||
Load `{output_folder}/bmgd-workflow-status.yaml` and:
|
|
||||||
|
|
||||||
- Update `create-architecture` status to the output file path
|
|
||||||
- Preserve all comments and structure
|
|
||||||
- Determine next workflow in sequence
|
|
||||||
|
|
||||||
### 5. Present Completion Summary
|
|
||||||
|
|
||||||
"**Architecture Complete!**
|
"**Architecture Complete!**
|
||||||
|
|
||||||
|
|
@ -169,50 +158,9 @@ Load `{output_folder}/bmgd-workflow-status.yaml` and:
|
||||||
|
|
||||||
**Document saved to:** `{outputFile}`
|
**Document saved to:** `{outputFile}`
|
||||||
|
|
||||||
Do you want to review or adjust anything before we finalize?
|
Do you want to review or adjust anything before we finalize?"
|
||||||
|
|
||||||
**Optional Enhancement: Project Context File**
|
### 5. Handle Review Requests
|
||||||
|
|
||||||
Would you like to create a `project-context.md` file? This is a concise, optimized guide for AI agents that captures:
|
|
||||||
|
|
||||||
- Critical engine-specific rules they might miss
|
|
||||||
- Specific patterns and conventions for your game project
|
|
||||||
- Performance and optimization requirements
|
|
||||||
- Anti-patterns and edge cases to avoid
|
|
||||||
|
|
||||||
{if_existing_project_context}
|
|
||||||
I noticed you already have a project context file. Would you like to update it with your new architectural decisions?
|
|
||||||
{else}
|
|
||||||
This file helps ensure AI agents implement game code consistently with your project's unique requirements and patterns.
|
|
||||||
{/if_existing_project_context}
|
|
||||||
|
|
||||||
**Create/Update project context?** [Y/N]"
|
|
||||||
|
|
||||||
### 6. Handle Project Context Creation Choice
|
|
||||||
|
|
||||||
If user responds 'Y' or 'yes' to creating/updating project context:
|
|
||||||
|
|
||||||
"Excellent choice! Let me launch the Generate Project Context workflow to create a comprehensive guide for AI agents.
|
|
||||||
|
|
||||||
This will help ensure consistent implementation by capturing:
|
|
||||||
|
|
||||||
- Engine-specific patterns and rules
|
|
||||||
- Performance and optimization conventions from your architecture
|
|
||||||
- Testing and quality standards
|
|
||||||
- Anti-patterns to avoid
|
|
||||||
|
|
||||||
The workflow will collaborate with you to create an optimized `project-context.md` file that AI agents will read before implementing any game code."
|
|
||||||
|
|
||||||
**Execute the Generate Project Context workflow:**
|
|
||||||
|
|
||||||
- Load and execute: `{projectContextWorkflow}`
|
|
||||||
- The workflow will handle discovery, generation, and completion of the project context file
|
|
||||||
- After completion, return here for final handoff
|
|
||||||
|
|
||||||
If user responds 'N' or 'no':
|
|
||||||
"Understood! Your architecture is complete and ready for implementation. You can always create a project context file later using the Generate Project Context workflow if needed."
|
|
||||||
|
|
||||||
### 7. Handle Review Requests
|
|
||||||
|
|
||||||
**If user wants to review:**
|
**If user wants to review:**
|
||||||
|
|
||||||
|
|
@ -231,7 +179,7 @@ Or type 'all' to see the complete document."
|
||||||
|
|
||||||
**Show requested section and allow edits.**
|
**Show requested section and allow edits.**
|
||||||
|
|
||||||
### 8. Present Next Steps Menu
|
### 6. Present Next Steps Menu
|
||||||
|
|
||||||
**After user confirms completion:**
|
**After user confirms completion:**
|
||||||
|
|
||||||
|
|
@ -256,7 +204,7 @@ Or type 'all' to see the complete document."
|
||||||
2. Proceed to Epic creation workflow
|
2. Proceed to Epic creation workflow
|
||||||
3. Exit workflow"
|
3. Exit workflow"
|
||||||
|
|
||||||
### 9. Handle User Selection
|
### 7. Handle User Selection
|
||||||
|
|
||||||
Based on user choice:
|
Based on user choice:
|
||||||
|
|
||||||
|
|
@ -276,7 +224,7 @@ Based on user choice:
|
||||||
- Confirm document is saved and complete
|
- Confirm document is saved and complete
|
||||||
- Exit workflow gracefully
|
- Exit workflow gracefully
|
||||||
|
|
||||||
### 10. Provide Handoff Guidance
|
### 8. Provide Handoff Guidance
|
||||||
|
|
||||||
**For Epic Creation handoff:**
|
**For Epic Creation handoff:**
|
||||||
|
|
||||||
|
|
@ -322,7 +270,6 @@ This is the final step. Ensure:
|
||||||
- Development setup is complete
|
- Development setup is complete
|
||||||
- Document status updated to 'complete'
|
- Document status updated to 'complete'
|
||||||
- Frontmatter shows all steps completed
|
- Frontmatter shows all steps completed
|
||||||
- Workflow status updated (if tracking)
|
|
||||||
- User has clear next steps
|
- User has clear next steps
|
||||||
- Document saved and ready for AI agent consumption
|
- Document saved and ready for AI agent consumption
|
||||||
|
|
||||||
|
|
@ -331,7 +278,6 @@ This is the final step. Ensure:
|
||||||
- Missing executive summary
|
- Missing executive summary
|
||||||
- Incomplete development setup
|
- Incomplete development setup
|
||||||
- Frontmatter not updated
|
- Frontmatter not updated
|
||||||
- Status not updated when tracking
|
|
||||||
- No clear next steps provided
|
- No clear next steps provided
|
||||||
- User left without actionable guidance
|
- User left without actionable guidance
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,20 +0,0 @@
|
||||||
---
|
|
||||||
project_name: '{{project_name}}'
|
|
||||||
user_name: '{{user_name}}'
|
|
||||||
date: '{{date}}'
|
|
||||||
sections_completed: []
|
|
||||||
---
|
|
||||||
|
|
||||||
# Project Context for AI Agents
|
|
||||||
|
|
||||||
_This file contains critical rules and patterns that AI agents must follow when implementing game code in this project. Focus on unobvious details that agents might otherwise miss._
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Technology Stack & Versions
|
|
||||||
|
|
||||||
_Documented after discovery phase_
|
|
||||||
|
|
||||||
## Critical Implementation Rules
|
|
||||||
|
|
||||||
_Documented after discovery phase_
|
|
||||||
|
|
@ -1,201 +0,0 @@
|
||||||
# Step 1: Context Discovery & Initialization
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- NEVER generate content without user input
|
|
||||||
- ALWAYS treat this as collaborative discovery between technical peers
|
|
||||||
- YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- FOCUS on discovering existing project context and technology stack
|
|
||||||
- IDENTIFY critical implementation rules that AI agents need
|
|
||||||
- ABSOLUTELY NO TIME ESTIMATES
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- Show your analysis before taking any action
|
|
||||||
- Read existing project files to understand current context
|
|
||||||
- Initialize document and update frontmatter
|
|
||||||
- FORBIDDEN to load next step until discovery is complete
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Variables from workflow.md are available in memory
|
|
||||||
- Focus on existing project files and architecture decisions
|
|
||||||
- Look for patterns, conventions, and unique requirements
|
|
||||||
- Prioritize rules that prevent implementation mistakes
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Discover the project's game engine, technology stack, existing patterns, and critical implementation rules that AI agents must follow when writing game code.
|
|
||||||
|
|
||||||
## DISCOVERY SEQUENCE:
|
|
||||||
|
|
||||||
### 1. Check for Existing Project Context
|
|
||||||
|
|
||||||
First, check if project context already exists:
|
|
||||||
|
|
||||||
- Look for file at `{output_folder}/project-context.md`
|
|
||||||
- If exists: Read complete file to understand existing rules
|
|
||||||
- Present to user: "Found existing project context with {number_of_sections} sections. Would you like to update this or create a new one?"
|
|
||||||
|
|
||||||
### 2. Discover Game Engine & Technology Stack
|
|
||||||
|
|
||||||
Load and analyze project files to identify technologies:
|
|
||||||
|
|
||||||
**Architecture Document:**
|
|
||||||
|
|
||||||
- Look for `{output_folder}/game-architecture.md` or `{output_folder}/architecture.md`
|
|
||||||
- Extract engine choice with specific version (Unity, Unreal, Godot, custom)
|
|
||||||
- Note architectural decisions that affect implementation
|
|
||||||
|
|
||||||
**Engine-Specific Files:**
|
|
||||||
|
|
||||||
- Unity: Check for `ProjectSettings/ProjectVersion.txt`, `Packages/manifest.json`
|
|
||||||
- Unreal: Check for `.uproject` files, `Config/DefaultEngine.ini`
|
|
||||||
- Godot: Check for `project.godot`, `export_presets.cfg`
|
|
||||||
- Custom: Check for engine config files, build scripts
|
|
||||||
|
|
||||||
**Package/Dependency Files:**
|
|
||||||
|
|
||||||
- Unity: `Packages/manifest.json`, NuGet packages
|
|
||||||
- Unreal: `.Build.cs` files, plugin configs
|
|
||||||
- Godot: `addons/` directory, GDExtension configs
|
|
||||||
- Web-based: `package.json`, `requirements.txt`
|
|
||||||
|
|
||||||
**Configuration Files:**
|
|
||||||
|
|
||||||
- Build tool configs
|
|
||||||
- Linting and formatting configs
|
|
||||||
- Testing configurations
|
|
||||||
- CI/CD pipeline configs
|
|
||||||
|
|
||||||
### 3. Identify Existing Code Patterns
|
|
||||||
|
|
||||||
Search through existing codebase for patterns:
|
|
||||||
|
|
||||||
**Naming Conventions:**
|
|
||||||
|
|
||||||
- Script/class naming patterns
|
|
||||||
- Asset naming conventions
|
|
||||||
- Scene/level naming patterns
|
|
||||||
- Test file naming patterns
|
|
||||||
|
|
||||||
**Code Organization:**
|
|
||||||
|
|
||||||
- How components/scripts are structured
|
|
||||||
- Where utilities and helpers are placed
|
|
||||||
- How systems are organized
|
|
||||||
- Folder hierarchy patterns
|
|
||||||
|
|
||||||
**Engine-Specific Patterns:**
|
|
||||||
|
|
||||||
- Unity: MonoBehaviour patterns, ScriptableObject usage, serialization rules
|
|
||||||
- Unreal: Actor/Component patterns, Blueprint integration, UE macros
|
|
||||||
- Godot: Node patterns, signal usage, autoload patterns
|
|
||||||
|
|
||||||
### 4. Extract Critical Implementation Rules
|
|
||||||
|
|
||||||
Look for rules that AI agents might miss:
|
|
||||||
|
|
||||||
**Engine-Specific Rules:**
|
|
||||||
|
|
||||||
- Unity: Assembly definitions, Unity lifecycle methods, coroutine patterns
|
|
||||||
- Unreal: UPROPERTY/UFUNCTION usage, garbage collection rules, tick patterns
|
|
||||||
- Godot: `_ready` vs `_enter_tree`, node ownership, scene instancing
|
|
||||||
|
|
||||||
**Performance Rules:**
|
|
||||||
|
|
||||||
- Frame budget constraints
|
|
||||||
- Memory allocation patterns
|
|
||||||
- Hot path optimization requirements
|
|
||||||
- Object pooling patterns
|
|
||||||
|
|
||||||
**Platform-Specific Rules:**
|
|
||||||
|
|
||||||
- Target platform constraints
|
|
||||||
- Input handling conventions
|
|
||||||
- Platform-specific code patterns
|
|
||||||
- Build configuration rules
|
|
||||||
|
|
||||||
**Testing Rules:**
|
|
||||||
|
|
||||||
- Test structure requirements
|
|
||||||
- Mock usage conventions
|
|
||||||
- Integration vs unit test boundaries
|
|
||||||
- Play mode vs edit mode testing
|
|
||||||
|
|
||||||
### 5. Initialize Project Context Document
|
|
||||||
|
|
||||||
Based on discovery, create or update the context document:
|
|
||||||
|
|
||||||
#### A. Fresh Document Setup (if no existing context)
|
|
||||||
|
|
||||||
Copy template from `{installed_path}/project-context-template.md` to `{output_folder}/project-context.md`
|
|
||||||
Initialize frontmatter with:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
---
|
|
||||||
project_name: '{{project_name}}'
|
|
||||||
user_name: '{{user_name}}'
|
|
||||||
date: '{{date}}'
|
|
||||||
sections_completed: ['technology_stack']
|
|
||||||
existing_patterns_found: { { number_of_patterns_discovered } }
|
|
||||||
---
|
|
||||||
```
|
|
||||||
|
|
||||||
#### B. Existing Document Update
|
|
||||||
|
|
||||||
Load existing context and prepare for updates
|
|
||||||
Set frontmatter `sections_completed` to track what will be updated
|
|
||||||
|
|
||||||
### 6. Present Discovery Summary
|
|
||||||
|
|
||||||
Report findings to user:
|
|
||||||
|
|
||||||
"Welcome {{user_name}}! I've analyzed your game project for {{project_name}} to discover the context that AI agents need.
|
|
||||||
|
|
||||||
**Game Engine & Stack Discovered:**
|
|
||||||
{{engine_and_version}}
|
|
||||||
{{list_of_technologies_with_versions}}
|
|
||||||
|
|
||||||
**Existing Patterns Found:**
|
|
||||||
|
|
||||||
- {{number_of_patterns}} implementation patterns
|
|
||||||
- {{number_of_conventions}} coding conventions
|
|
||||||
- {{number_of_rules}} critical rules
|
|
||||||
|
|
||||||
**Key Areas for Context Rules:**
|
|
||||||
|
|
||||||
- {{area_1}} (e.g., Engine lifecycle and patterns)
|
|
||||||
- {{area_2}} (e.g., Performance and optimization)
|
|
||||||
- {{area_3}} (e.g., Platform-specific requirements)
|
|
||||||
|
|
||||||
{if_existing_context}
|
|
||||||
**Existing Context:** Found {{sections}} sections already defined. We can update or add to these.
|
|
||||||
{/if_existing_context}
|
|
||||||
|
|
||||||
Ready to create/update your project context. This will help AI agents implement game code consistently with your project's standards.
|
|
||||||
|
|
||||||
[C] Continue to context generation"
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
- Existing project context properly detected and handled
|
|
||||||
- Game engine and technology stack accurately identified with versions
|
|
||||||
- Critical implementation patterns discovered
|
|
||||||
- Project context document properly initialized
|
|
||||||
- Discovery findings clearly presented to user
|
|
||||||
- User ready to proceed with context generation
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
- Not checking for existing project context before creating new one
|
|
||||||
- Missing critical engine versions or configurations
|
|
||||||
- Overlooking important coding patterns or conventions
|
|
||||||
- Not initializing frontmatter properly
|
|
||||||
- Not presenting clear discovery summary to user
|
|
||||||
|
|
||||||
## NEXT STEP:
|
|
||||||
|
|
||||||
After user selects [C] to continue, load `./step-02-generate.md` to collaboratively generate the specific project context rules.
|
|
||||||
|
|
||||||
Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and discovery is confirmed!
|
|
||||||
|
|
@ -1,373 +0,0 @@
|
||||||
# Step 2: Context Rules Generation
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- NEVER generate content without user input
|
|
||||||
- ALWAYS treat this as collaborative discovery between technical peers
|
|
||||||
- YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- FOCUS on unobvious rules that AI agents need to be reminded of
|
|
||||||
- KEEP CONTENT LEAN - optimize for LLM context efficiency
|
|
||||||
- ABSOLUTELY NO TIME ESTIMATES
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- Show your analysis before taking any action
|
|
||||||
- Focus on specific, actionable rules rather than general advice
|
|
||||||
- Present A/P/C menu after each major rule category
|
|
||||||
- ONLY save when user chooses C (Continue)
|
|
||||||
- Update frontmatter with completed sections
|
|
||||||
- FORBIDDEN to load next step until all sections are complete
|
|
||||||
|
|
||||||
## COLLABORATION MENUS (A/P/C):
|
|
||||||
|
|
||||||
This step will generate content and present choices for each rule category:
|
|
||||||
|
|
||||||
- **A (Advanced Elicitation)**: Use discovery protocols to explore nuanced implementation rules
|
|
||||||
- **P (Party Mode)**: Bring multiple perspectives to identify critical edge cases
|
|
||||||
- **C (Continue)**: Save the current rules and proceed to next category
|
|
||||||
|
|
||||||
## PROTOCOL INTEGRATION:
|
|
||||||
|
|
||||||
- When 'A' selected: Execute {project-root}/\_bmad/core/tasks/advanced-elicitation.xml
|
|
||||||
- When 'P' selected: Execute {project-root}/\_bmad/core/workflows/party-mode
|
|
||||||
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
|
||||||
- User accepts/rejects protocol changes before proceeding
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Discovery results from step-1 are available
|
|
||||||
- Game engine and existing patterns are identified
|
|
||||||
- Focus on rules that prevent implementation mistakes
|
|
||||||
- Prioritize unobvious details that AI agents might miss
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Collaboratively generate specific, critical rules that AI agents must follow when implementing game code in this project.
|
|
||||||
|
|
||||||
## CONTEXT GENERATION SEQUENCE:
|
|
||||||
|
|
||||||
### 1. Technology Stack & Versions
|
|
||||||
|
|
||||||
Document the exact technology stack from discovery:
|
|
||||||
|
|
||||||
**Core Technologies:**
|
|
||||||
Based on user skill level, present findings:
|
|
||||||
|
|
||||||
**Expert Mode:**
|
|
||||||
"Technology stack from your architecture and project files:
|
|
||||||
{{exact_technologies_with_versions}}
|
|
||||||
|
|
||||||
Any critical version constraints I should document for agents?"
|
|
||||||
|
|
||||||
**Intermediate Mode:**
|
|
||||||
"I found your technology stack:
|
|
||||||
|
|
||||||
**Game Engine:**
|
|
||||||
{{engine_with_version}}
|
|
||||||
|
|
||||||
**Key Dependencies:**
|
|
||||||
{{important_dependencies_with_versions}}
|
|
||||||
|
|
||||||
Are there any version constraints or compatibility notes agents should know about?"
|
|
||||||
|
|
||||||
**Beginner Mode:**
|
|
||||||
"Here are the technologies you're using:
|
|
||||||
|
|
||||||
**Game Engine:**
|
|
||||||
{{friendly_description_of_engine}}
|
|
||||||
|
|
||||||
**Important Notes:**
|
|
||||||
{{key_things_agents_need_to_know_about_versions}}
|
|
||||||
|
|
||||||
Should I document any special version rules or compatibility requirements?"
|
|
||||||
|
|
||||||
### 2. Engine-Specific Rules
|
|
||||||
|
|
||||||
Focus on unobvious engine patterns agents might miss:
|
|
||||||
|
|
||||||
**Unity Rules (if applicable):**
|
|
||||||
"Based on your Unity project, I notice some specific patterns:
|
|
||||||
|
|
||||||
**Lifecycle Rules:**
|
|
||||||
{{unity_lifecycle_patterns}}
|
|
||||||
|
|
||||||
**Serialization Rules:**
|
|
||||||
{{serialization_requirements}}
|
|
||||||
|
|
||||||
**Assembly Definitions:**
|
|
||||||
{{assembly_definition_rules}}
|
|
||||||
|
|
||||||
**Coroutine/Async Patterns:**
|
|
||||||
{{async_patterns}}
|
|
||||||
|
|
||||||
Are these patterns correct? Any other Unity-specific rules agents should follow?"
|
|
||||||
|
|
||||||
**Unreal Rules (if applicable):**
|
|
||||||
"Based on your Unreal project, I notice some specific patterns:
|
|
||||||
|
|
||||||
**UPROPERTY/UFUNCTION Rules:**
|
|
||||||
{{macro_usage_patterns}}
|
|
||||||
|
|
||||||
**Blueprint Integration:**
|
|
||||||
{{blueprint_rules}}
|
|
||||||
|
|
||||||
**Garbage Collection:**
|
|
||||||
{{gc_patterns}}
|
|
||||||
|
|
||||||
**Tick Patterns:**
|
|
||||||
{{tick_optimization_rules}}
|
|
||||||
|
|
||||||
Are these patterns correct? Any other Unreal-specific rules agents should follow?"
|
|
||||||
|
|
||||||
**Godot Rules (if applicable):**
|
|
||||||
"Based on your Godot project, I notice some specific patterns:
|
|
||||||
|
|
||||||
**Node Lifecycle:**
|
|
||||||
{{node_lifecycle_patterns}}
|
|
||||||
|
|
||||||
**Signal Usage:**
|
|
||||||
{{signal_conventions}}
|
|
||||||
|
|
||||||
**Scene Instancing:**
|
|
||||||
{{scene_patterns}}
|
|
||||||
|
|
||||||
**Autoload Patterns:**
|
|
||||||
{{autoload_rules}}
|
|
||||||
|
|
||||||
Are these patterns correct? Any other Godot-specific rules agents should follow?"
|
|
||||||
|
|
||||||
### 3. Performance Rules
|
|
||||||
|
|
||||||
Document performance-critical patterns:
|
|
||||||
|
|
||||||
**Frame Budget Rules:**
|
|
||||||
"Your game has these performance requirements:
|
|
||||||
|
|
||||||
**Target Frame Rate:**
|
|
||||||
{{target_fps}}
|
|
||||||
|
|
||||||
**Frame Budget:**
|
|
||||||
{{milliseconds_per_frame}}
|
|
||||||
|
|
||||||
**Critical Systems:**
|
|
||||||
{{systems_that_must_meet_budget}}
|
|
||||||
|
|
||||||
**Hot Path Rules:**
|
|
||||||
{{hot_path_patterns}}
|
|
||||||
|
|
||||||
Any other performance rules agents must follow?"
|
|
||||||
|
|
||||||
**Memory Management:**
|
|
||||||
"Memory patterns for your project:
|
|
||||||
|
|
||||||
**Allocation Rules:**
|
|
||||||
{{allocation_patterns}}
|
|
||||||
|
|
||||||
**Pooling Requirements:**
|
|
||||||
{{object_pooling_rules}}
|
|
||||||
|
|
||||||
**Asset Loading:**
|
|
||||||
{{asset_loading_patterns}}
|
|
||||||
|
|
||||||
Are there memory constraints agents should know about?"
|
|
||||||
|
|
||||||
### 4. Code Organization Rules
|
|
||||||
|
|
||||||
Document project structure and organization:
|
|
||||||
|
|
||||||
**Folder Structure:**
|
|
||||||
"Your project organization:
|
|
||||||
|
|
||||||
**Script Organization:**
|
|
||||||
{{script_folder_structure}}
|
|
||||||
|
|
||||||
**Asset Organization:**
|
|
||||||
{{asset_folder_patterns}}
|
|
||||||
|
|
||||||
**Scene/Level Organization:**
|
|
||||||
{{scene_organization}}
|
|
||||||
|
|
||||||
Any organization rules agents must follow?"
|
|
||||||
|
|
||||||
**Naming Conventions:**
|
|
||||||
"Your naming patterns:
|
|
||||||
|
|
||||||
**Script/Class Names:**
|
|
||||||
{{class_naming_patterns}}
|
|
||||||
|
|
||||||
**Asset Names:**
|
|
||||||
{{asset_naming_patterns}}
|
|
||||||
|
|
||||||
**Variable/Method Names:**
|
|
||||||
{{variable_naming_patterns}}
|
|
||||||
|
|
||||||
Any other naming rules?"
|
|
||||||
|
|
||||||
### 5. Testing Rules
|
|
||||||
|
|
||||||
Focus on testing patterns that ensure consistency:
|
|
||||||
|
|
||||||
**Test Structure Rules:**
|
|
||||||
"Your testing setup shows these patterns:
|
|
||||||
|
|
||||||
**Test Organization:**
|
|
||||||
{{test_file_organization}}
|
|
||||||
|
|
||||||
**Test Categories:**
|
|
||||||
{{unit_vs_integration_boundaries}}
|
|
||||||
|
|
||||||
**Mocking Patterns:**
|
|
||||||
{{mock_usage_conventions}}
|
|
||||||
|
|
||||||
**Play Mode Testing:**
|
|
||||||
{{play_mode_test_patterns}}
|
|
||||||
|
|
||||||
Are there testing rules agents should always follow?"
|
|
||||||
|
|
||||||
### 6. Platform & Build Rules
|
|
||||||
|
|
||||||
Document platform-specific requirements:
|
|
||||||
|
|
||||||
**Target Platforms:**
|
|
||||||
"Your platform configuration:
|
|
||||||
|
|
||||||
**Primary Platform:**
|
|
||||||
{{primary_platform}}
|
|
||||||
|
|
||||||
**Platform-Specific Code:**
|
|
||||||
{{platform_conditional_patterns}}
|
|
||||||
|
|
||||||
**Build Configurations:**
|
|
||||||
{{build_config_rules}}
|
|
||||||
|
|
||||||
**Input Handling:**
|
|
||||||
{{input_abstraction_patterns}}
|
|
||||||
|
|
||||||
Any platform rules agents must know?"
|
|
||||||
|
|
||||||
### 7. Critical Don't-Miss Rules
|
|
||||||
|
|
||||||
Identify rules that prevent common mistakes:
|
|
||||||
|
|
||||||
**Anti-Patterns to Avoid:**
|
|
||||||
"Based on your codebase, here are critical things agents must NOT do:
|
|
||||||
|
|
||||||
{{critical_anti_patterns_with_examples}}
|
|
||||||
|
|
||||||
**Edge Cases:**
|
|
||||||
{{specific_edge_cases_agents_should_handle}}
|
|
||||||
|
|
||||||
**Common Gotchas:**
|
|
||||||
{{engine_specific_gotchas}}
|
|
||||||
|
|
||||||
**Performance Traps:**
|
|
||||||
{{performance_patterns_to_avoid}}
|
|
||||||
|
|
||||||
Are there other 'gotchas' agents should know about?"
|
|
||||||
|
|
||||||
### 8. Generate Context Content
|
|
||||||
|
|
||||||
For each category, prepare lean content for the project context file:
|
|
||||||
|
|
||||||
#### Content Structure:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Technology Stack & Versions
|
|
||||||
|
|
||||||
{{concise_technology_list_with_exact_versions}}
|
|
||||||
|
|
||||||
## Critical Implementation Rules
|
|
||||||
|
|
||||||
### Engine-Specific Rules
|
|
||||||
|
|
||||||
{{bullet_points_of_engine_rules}}
|
|
||||||
|
|
||||||
### Performance Rules
|
|
||||||
|
|
||||||
{{bullet_points_of_performance_requirements}}
|
|
||||||
|
|
||||||
### Code Organization Rules
|
|
||||||
|
|
||||||
{{bullet_points_of_organization_patterns}}
|
|
||||||
|
|
||||||
### Testing Rules
|
|
||||||
|
|
||||||
{{bullet_points_of_testing_requirements}}
|
|
||||||
|
|
||||||
### Platform & Build Rules
|
|
||||||
|
|
||||||
{{bullet_points_of_platform_requirements}}
|
|
||||||
|
|
||||||
### Critical Don't-Miss Rules
|
|
||||||
|
|
||||||
{{bullet_points_of_anti_patterns_and_gotchas}}
|
|
||||||
```
|
|
||||||
|
|
||||||
### 9. Present Content and Menu
|
|
||||||
|
|
||||||
After each category, show the generated rules and present choices:
|
|
||||||
|
|
||||||
"I've drafted the {{category_name}} rules for your project context.
|
|
||||||
|
|
||||||
**Here's what I'll add:**
|
|
||||||
|
|
||||||
[Show the complete markdown content for this category]
|
|
||||||
|
|
||||||
**What would you like to do?**
|
|
||||||
[A] Advanced Elicitation - Explore nuanced rules for this category
|
|
||||||
[P] Party Mode - Review from different implementation perspectives
|
|
||||||
[C] Continue - Save these rules and move to next category"
|
|
||||||
|
|
||||||
### 10. Handle Menu Selection
|
|
||||||
|
|
||||||
#### If 'A' (Advanced Elicitation):
|
|
||||||
|
|
||||||
- Execute advanced-elicitation.xml with current category rules
|
|
||||||
- Process enhanced rules that come back
|
|
||||||
- Ask user: "Accept these enhanced rules for {{category}}? (y/n)"
|
|
||||||
- If yes: Update content, then return to A/P/C menu
|
|
||||||
- If no: Keep original content, then return to A/P/C menu
|
|
||||||
|
|
||||||
#### If 'P' (Party Mode):
|
|
||||||
|
|
||||||
- Execute party-mode workflow with category rules context
|
|
||||||
- Process collaborative insights on implementation patterns
|
|
||||||
- Ask user: "Accept these changes to {{category}} rules? (y/n)"
|
|
||||||
- If yes: Update content, then return to A/P/C menu
|
|
||||||
- If no: Keep original content, then return to A/P/C menu
|
|
||||||
|
|
||||||
#### If 'C' (Continue):
|
|
||||||
|
|
||||||
- Save the current category content to project context file
|
|
||||||
- Update frontmatter: `sections_completed: [...]`
|
|
||||||
- Proceed to next category or step-03 if complete
|
|
||||||
|
|
||||||
## APPEND TO PROJECT CONTEXT:
|
|
||||||
|
|
||||||
When user selects 'C' for a category, append the content directly to `{output_folder}/project-context.md` using the structure from step 8.
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
- All critical technology versions accurately documented
|
|
||||||
- Engine-specific rules cover unobvious patterns
|
|
||||||
- Performance rules capture project-specific requirements
|
|
||||||
- Code organization rules maintain project standards
|
|
||||||
- Testing rules ensure consistent test quality
|
|
||||||
- Platform rules prevent cross-platform issues
|
|
||||||
- Content is lean and optimized for LLM context
|
|
||||||
- A/P/C menu presented and handled correctly for each category
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
- Including obvious rules that agents already know
|
|
||||||
- Making content too verbose for LLM context efficiency
|
|
||||||
- Missing critical anti-patterns or edge cases
|
|
||||||
- Not getting user validation for each rule category
|
|
||||||
- Not documenting exact versions and configurations
|
|
||||||
- Not presenting A/P/C menu after content generation
|
|
||||||
|
|
||||||
## NEXT STEP:
|
|
||||||
|
|
||||||
After completing all rule categories and user selects 'C' for the final category, load `./step-03-complete.md` to finalize the project context file.
|
|
||||||
|
|
||||||
Remember: Do NOT proceed to step-03 until all categories are complete and user explicitly selects 'C' for each!
|
|
||||||
|
|
@ -1,279 +0,0 @@
|
||||||
# Step 3: Context Completion & Finalization
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- NEVER generate content without user input
|
|
||||||
- ALWAYS treat this as collaborative completion between technical peers
|
|
||||||
- YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- FOCUS on finalizing a lean, LLM-optimized project context
|
|
||||||
- ENSURE all critical rules are captured and actionable
|
|
||||||
- ABSOLUTELY NO TIME ESTIMATES
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- Show your analysis before taking any action
|
|
||||||
- Review and optimize content for LLM context efficiency
|
|
||||||
- Update frontmatter with completion status
|
|
||||||
- NO MORE STEPS - this is the final step
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- All rule categories from step-2 are complete
|
|
||||||
- Technology stack and versions are documented
|
|
||||||
- Focus on final review, optimization, and completion
|
|
||||||
- Ensure the context file is ready for AI agent consumption
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Complete the project context file, optimize it for LLM efficiency, and provide guidance for usage and maintenance.
|
|
||||||
|
|
||||||
## COMPLETION SEQUENCE:
|
|
||||||
|
|
||||||
### 1. Review Complete Context File
|
|
||||||
|
|
||||||
Read the entire project context file and analyze:
|
|
||||||
|
|
||||||
**Content Analysis:**
|
|
||||||
|
|
||||||
- Total length and readability for LLMs
|
|
||||||
- Clarity and specificity of rules
|
|
||||||
- Coverage of all critical areas
|
|
||||||
- Actionability of each rule
|
|
||||||
|
|
||||||
**Structure Analysis:**
|
|
||||||
|
|
||||||
- Logical organization of sections
|
|
||||||
- Consistency of formatting
|
|
||||||
- Absence of redundant or obvious information
|
|
||||||
- Optimization for quick scanning
|
|
||||||
|
|
||||||
### 2. Optimize for LLM Context
|
|
||||||
|
|
||||||
Ensure the file is lean and efficient:
|
|
||||||
|
|
||||||
**Content Optimization:**
|
|
||||||
|
|
||||||
- Remove any redundant rules or obvious information
|
|
||||||
- Combine related rules into concise bullet points
|
|
||||||
- Use specific, actionable language
|
|
||||||
- Ensure each rule provides unique value
|
|
||||||
|
|
||||||
**Formatting Optimization:**
|
|
||||||
|
|
||||||
- Use consistent markdown formatting
|
|
||||||
- Implement clear section hierarchy
|
|
||||||
- Ensure scannability with strategic use of bolding
|
|
||||||
- Maintain readability while maximizing information density
|
|
||||||
|
|
||||||
### 3. Final Content Structure
|
|
||||||
|
|
||||||
Ensure the final structure follows this optimized format:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# Project Context for AI Agents
|
|
||||||
|
|
||||||
_This file contains critical rules and patterns that AI agents must follow when implementing game code in this project. Focus on unobvious details that agents might otherwise miss._
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Technology Stack & Versions
|
|
||||||
|
|
||||||
{{concise_technology_list}}
|
|
||||||
|
|
||||||
## Critical Implementation Rules
|
|
||||||
|
|
||||||
### Engine-Specific Rules
|
|
||||||
|
|
||||||
{{engine_rules}}
|
|
||||||
|
|
||||||
### Performance Rules
|
|
||||||
|
|
||||||
{{performance_requirements}}
|
|
||||||
|
|
||||||
### Code Organization Rules
|
|
||||||
|
|
||||||
{{organization_patterns}}
|
|
||||||
|
|
||||||
### Testing Rules
|
|
||||||
|
|
||||||
{{testing_requirements}}
|
|
||||||
|
|
||||||
### Platform & Build Rules
|
|
||||||
|
|
||||||
{{platform_requirements}}
|
|
||||||
|
|
||||||
### Critical Don't-Miss Rules
|
|
||||||
|
|
||||||
{{anti_patterns_and_gotchas}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Usage Guidelines
|
|
||||||
|
|
||||||
**For AI Agents:**
|
|
||||||
|
|
||||||
- Read this file before implementing any game code
|
|
||||||
- Follow ALL rules exactly as documented
|
|
||||||
- When in doubt, prefer the more restrictive option
|
|
||||||
- Update this file if new patterns emerge
|
|
||||||
|
|
||||||
**For Humans:**
|
|
||||||
|
|
||||||
- Keep this file lean and focused on agent needs
|
|
||||||
- Update when technology stack changes
|
|
||||||
- Review quarterly for outdated rules
|
|
||||||
- Remove rules that become obvious over time
|
|
||||||
|
|
||||||
Last Updated: {{date}}
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4. Present Completion Summary
|
|
||||||
|
|
||||||
Based on user skill level, present the completion:
|
|
||||||
|
|
||||||
**Expert Mode:**
|
|
||||||
"Project context complete. Optimized for LLM consumption with {{rule_count}} critical rules across {{section_count}} sections.
|
|
||||||
|
|
||||||
File saved to: `{output_folder}/project-context.md`
|
|
||||||
|
|
||||||
Ready for AI agent integration."
|
|
||||||
|
|
||||||
**Intermediate Mode:**
|
|
||||||
"Your project context is complete and optimized for AI agents!
|
|
||||||
|
|
||||||
**What we created:**
|
|
||||||
|
|
||||||
- {{rule_count}} critical implementation rules
|
|
||||||
- Technology stack with exact versions
|
|
||||||
- Engine-specific patterns and conventions
|
|
||||||
- Performance and optimization guidelines
|
|
||||||
- Testing and platform requirements
|
|
||||||
|
|
||||||
**Key benefits:**
|
|
||||||
|
|
||||||
- AI agents will implement consistently with your standards
|
|
||||||
- Reduced context switching and implementation errors
|
|
||||||
- Clear guidance for unobvious project requirements
|
|
||||||
|
|
||||||
**Next steps:**
|
|
||||||
|
|
||||||
- AI agents should read this file before implementing
|
|
||||||
- Update as your project evolves
|
|
||||||
- Review periodically for optimization"
|
|
||||||
|
|
||||||
**Beginner Mode:**
|
|
||||||
"Excellent! Your project context guide is ready!
|
|
||||||
|
|
||||||
**What this does:**
|
|
||||||
Think of this as a 'rules of the road' guide for AI agents working on your game. It ensures they all follow the same patterns and avoid common mistakes.
|
|
||||||
|
|
||||||
**What's included:**
|
|
||||||
|
|
||||||
- Exact engine and technology versions to use
|
|
||||||
- Critical coding rules they might miss
|
|
||||||
- Performance and optimization standards
|
|
||||||
- Testing and platform requirements
|
|
||||||
|
|
||||||
**How AI agents use it:**
|
|
||||||
They read this file before writing any code, ensuring everything they create follows your project's standards perfectly.
|
|
||||||
|
|
||||||
Your project context is saved and ready to help agents implement consistently!"
|
|
||||||
|
|
||||||
### 5. Final File Updates
|
|
||||||
|
|
||||||
Update the project context file with completion information:
|
|
||||||
|
|
||||||
**Frontmatter Update:**
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
---
|
|
||||||
project_name: '{{project_name}}'
|
|
||||||
user_name: '{{user_name}}'
|
|
||||||
date: '{{date}}'
|
|
||||||
sections_completed:
|
|
||||||
['technology_stack', 'engine_rules', 'performance_rules', 'organization_rules', 'testing_rules', 'platform_rules', 'anti_patterns']
|
|
||||||
status: 'complete'
|
|
||||||
rule_count: { { total_rules } }
|
|
||||||
optimized_for_llm: true
|
|
||||||
---
|
|
||||||
```
|
|
||||||
|
|
||||||
**Add Usage Section:**
|
|
||||||
Append the usage guidelines from step 3 to complete the document.
|
|
||||||
|
|
||||||
### 6. Completion Validation
|
|
||||||
|
|
||||||
Final checks before completion:
|
|
||||||
|
|
||||||
**Content Validation:**
|
|
||||||
|
|
||||||
- All critical technology versions documented
|
|
||||||
- Engine-specific rules are specific and actionable
|
|
||||||
- Performance rules capture project requirements
|
|
||||||
- Code organization rules maintain standards
|
|
||||||
- Testing rules ensure consistency
|
|
||||||
- Platform rules prevent cross-platform issues
|
|
||||||
- Anti-pattern rules prevent common mistakes
|
|
||||||
|
|
||||||
**Format Validation:**
|
|
||||||
|
|
||||||
- Content is lean and optimized for LLMs
|
|
||||||
- Structure is logical and scannable
|
|
||||||
- No redundant or obvious information
|
|
||||||
- Consistent formatting throughout
|
|
||||||
|
|
||||||
### 7. Completion Message
|
|
||||||
|
|
||||||
Present final completion to user:
|
|
||||||
|
|
||||||
"**Project Context Generation Complete!**
|
|
||||||
|
|
||||||
Your optimized project context file is ready at:
|
|
||||||
`{output_folder}/project-context.md`
|
|
||||||
|
|
||||||
**Context Summary:**
|
|
||||||
|
|
||||||
- {{rule_count}} critical rules for AI agents
|
|
||||||
- {{section_count}} comprehensive sections
|
|
||||||
- Optimized for LLM context efficiency
|
|
||||||
- Ready for immediate agent integration
|
|
||||||
|
|
||||||
**Key Benefits:**
|
|
||||||
|
|
||||||
- Consistent implementation across all AI agents
|
|
||||||
- Reduced common mistakes and edge cases
|
|
||||||
- Clear guidance for project-specific patterns
|
|
||||||
- Minimal LLM context usage
|
|
||||||
|
|
||||||
**Next Steps:**
|
|
||||||
|
|
||||||
1. AI agents will automatically read this file when implementing
|
|
||||||
2. Update this file when your technology stack or patterns evolve
|
|
||||||
3. Review quarterly to optimize and remove outdated rules
|
|
||||||
|
|
||||||
Your project context will help ensure high-quality, consistent game implementation across all development work. Great work capturing your project's critical implementation requirements!"
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
- Complete project context file with all critical rules
|
|
||||||
- Content optimized for LLM context efficiency
|
|
||||||
- All technology versions and patterns documented
|
|
||||||
- File structure is logical and scannable
|
|
||||||
- Usage guidelines included for agents and humans
|
|
||||||
- Frontmatter properly updated with completion status
|
|
||||||
- User provided with clear next steps and benefits
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
- Final content is too verbose for LLM consumption
|
|
||||||
- Missing critical implementation rules or patterns
|
|
||||||
- Not optimizing content for agent readability
|
|
||||||
- Not providing clear usage guidelines
|
|
||||||
- Frontmatter not properly updated
|
|
||||||
- Not validating file completion before ending
|
|
||||||
|
|
||||||
## WORKFLOW COMPLETE:
|
|
||||||
|
|
||||||
This is the final step of the Generate Project Context workflow. The user now has a comprehensive, optimized project context file that will ensure consistent, high-quality game implementation across all AI agents working on the project.
|
|
||||||
|
|
||||||
The project context file serves as the critical "rules of the road" that agents need to implement game code consistently with the project's standards and patterns.
|
|
||||||
|
|
@ -1,48 +0,0 @@
|
||||||
---
|
|
||||||
name: generate-project-context
|
|
||||||
description: Creates a concise project-context.md file with critical rules and patterns that AI agents must follow when implementing game code. Optimized for LLM context efficiency.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Generate Project Context Workflow
|
|
||||||
|
|
||||||
**Goal:** Create a concise, optimized `project-context.md` file containing critical rules, patterns, and guidelines that AI agents must follow when implementing game code. This file focuses on unobvious details that LLMs need to be reminded of.
|
|
||||||
|
|
||||||
**Your Role:** You are a technical facilitator working with a peer to capture the essential implementation rules that will ensure consistent, high-quality game code generation across all AI agents working on the project.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## WORKFLOW ARCHITECTURE
|
|
||||||
|
|
||||||
This uses **micro-file architecture** for disciplined execution:
|
|
||||||
|
|
||||||
- Each step is a self-contained file with embedded rules
|
|
||||||
- Sequential progression with user control at each step
|
|
||||||
- Document state tracked in frontmatter
|
|
||||||
- Focus on lean, LLM-optimized content generation
|
|
||||||
- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## INITIALIZATION
|
|
||||||
|
|
||||||
### Configuration Loading
|
|
||||||
|
|
||||||
Load config from `{project-root}/_bmad/bmgd/config.yaml` and resolve:
|
|
||||||
|
|
||||||
- `project_name`, `output_folder`, `user_name`
|
|
||||||
- `communication_language`, `document_output_language`, `game_dev_experience`
|
|
||||||
- `date` as system-generated current datetime
|
|
||||||
|
|
||||||
### Paths
|
|
||||||
|
|
||||||
- `installed_path` = `{project-root}/_bmad/bmgd/workflows/3-technical/generate-project-context`
|
|
||||||
- `template_path` = `{installed_path}/project-context-template.md`
|
|
||||||
- `output_file` = `{output_folder}/project-context.md`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## EXECUTION
|
|
||||||
|
|
||||||
Load and execute `steps/step-01-discover.md` to begin the workflow.
|
|
||||||
|
|
||||||
**Note:** Input document discovery and initialization protocols are handled in step-01-discover.md.
|
|
||||||
|
|
@ -0,0 +1,33 @@
|
||||||
|
# Quick-Dev Checklist
|
||||||
|
|
||||||
|
## Before Implementation
|
||||||
|
|
||||||
|
- [ ] Context loaded (tech-spec or user guidance)
|
||||||
|
- [ ] Files to modify identified
|
||||||
|
- [ ] Patterns understood
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
- [ ] All tasks completed
|
||||||
|
- [ ] Code follows existing patterns
|
||||||
|
- [ ] Error handling appropriate
|
||||||
|
|
||||||
|
## Testing
|
||||||
|
|
||||||
|
- [ ] Tests written (where appropriate)
|
||||||
|
- [ ] All tests passing
|
||||||
|
- [ ] No regressions
|
||||||
|
|
||||||
|
## Completion
|
||||||
|
|
||||||
|
- [ ] Acceptance criteria satisfied
|
||||||
|
- [ ] Tech-spec updated (if applicable)
|
||||||
|
- [ ] Summary provided to user
|
||||||
|
|
||||||
|
## Adversarial Review
|
||||||
|
|
||||||
|
- [ ] Diff constructed (tracked changes from {baseline_commit} + new untracked files)
|
||||||
|
- [ ] Adversarial review executed (subagent preferred)
|
||||||
|
- [ ] Findings presented with severity and classification
|
||||||
|
- [ ] User chose handling approach (walk through / auto-fix / skip)
|
||||||
|
- [ ] Findings resolved or acknowledged
|
||||||
|
|
@ -0,0 +1,276 @@
|
||||||
|
# Quick-Dev - Flexible 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>Flexible - handles tech-specs OR direct instructions</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_workflow}, then return</on-select>
|
||||||
|
<on-select key="t">Load and execute {create_tech_spec_workflow}</on-select>
|
||||||
|
</checkpoint-handlers>
|
||||||
|
|
||||||
|
<step n="1" goal="Load project context and determine execution mode">
|
||||||
|
|
||||||
|
<action>Record current HEAD as baseline for later review. Run `git rev-parse HEAD` and store the result as {baseline_commit}.</action>
|
||||||
|
|
||||||
|
<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-auth.md`
|
||||||
|
→ Load spec, extract tasks/context/AC, goto step 3
|
||||||
|
|
||||||
|
**Mode B: Direct Instructions** - e.g., `refactor src/foo.ts...`
|
||||||
|
→ Offer planning choice
|
||||||
|
</action>
|
||||||
|
|
||||||
|
<check if="Mode A">
|
||||||
|
<action>Load tech-spec, extract tasks/context/AC</action>
|
||||||
|
<goto>step_3</goto>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="Mode B">
|
||||||
|
|
||||||
|
<!-- Escalation Threshold: Lightweight check - should we invoke scale-adaptive? -->
|
||||||
|
|
||||||
|
<action>Evaluate escalation threshold against user input (minimal tokens, no file loading):
|
||||||
|
|
||||||
|
**Triggers escalation** (if 2+ signals present):
|
||||||
|
|
||||||
|
- Multiple components mentioned (e.g., dashboard + api + database)
|
||||||
|
- System-level language (e.g., platform, integration, architecture)
|
||||||
|
- Uncertainty about approach (e.g., "how should I", "best way to")
|
||||||
|
- Multi-layer scope (e.g., UI + backend + data together)
|
||||||
|
- Extended timeframe (e.g., "this week", "over the next few days")
|
||||||
|
|
||||||
|
**Reduces signal:**
|
||||||
|
|
||||||
|
- Simplicity markers (e.g., "just", "quickly", "fix", "bug", "typo", "simple", "basic", "minor")
|
||||||
|
- Single file/component focus
|
||||||
|
- Confident, specific request
|
||||||
|
|
||||||
|
Use holistic judgment, not mechanical keyword matching.</action>
|
||||||
|
|
||||||
|
<!-- No Escalation: Simple request, offer existing choice -->
|
||||||
|
<check if="escalation threshold NOT triggered">
|
||||||
|
<ask>**[t] Plan first** - Create tech-spec then implement
|
||||||
|
**[e] Execute directly** - Start now</ask>
|
||||||
|
|
||||||
|
<check if="t">
|
||||||
|
<action>Load and execute {create_tech_spec_workflow}</action>
|
||||||
|
<action>Continue to implementation after spec complete</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="e">
|
||||||
|
<ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
|
||||||
|
<goto>step_2</goto>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<!-- Escalation Triggered: Load scale-adaptive and evaluate level -->
|
||||||
|
<check if="escalation threshold triggered">
|
||||||
|
<action>Load {project_levels} and evaluate user input against detection_hints.keywords</action>
|
||||||
|
<action>Determine level (0-4) using scale-adaptive definitions</action>
|
||||||
|
|
||||||
|
<!-- Level 0: Scale-adaptive confirms simple, fall back to standard choice -->
|
||||||
|
<check if="level 0">
|
||||||
|
<ask>**[t] Plan first** - Create tech-spec then implement
|
||||||
|
|
||||||
|
**[e] Execute directly** - Start now</ask>
|
||||||
|
|
||||||
|
<check if="t">
|
||||||
|
<action>Load and execute {create_tech_spec_workflow}</action>
|
||||||
|
<action>Continue to implementation after spec complete</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="e">
|
||||||
|
<ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
|
||||||
|
<goto>step_2</goto>
|
||||||
|
</check>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="level 1 or 2 or couldn't determine level">
|
||||||
|
<ask>This looks like a focused feature with multiple components.
|
||||||
|
|
||||||
|
**[t] Create tech-spec first** (recommended)
|
||||||
|
**[w] Seems bigger than quick-dev** — see what BMad Method recommends (workflow-init)
|
||||||
|
**[e] Execute directly**</ask>
|
||||||
|
|
||||||
|
<check if="t">
|
||||||
|
<action>Load and execute {create_tech_spec_workflow}</action>
|
||||||
|
<action>Continue to implementation after spec complete</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="w">
|
||||||
|
<action>Load and execute {workflow_init}</action>
|
||||||
|
<action>EXIT quick-dev - user has been routed to BMad Method</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="e">
|
||||||
|
<ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
|
||||||
|
<goto>step_2</goto>
|
||||||
|
</check>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<!-- Level 3+: BMad Method territory, recommend workflow-init -->
|
||||||
|
<check if="level 3 or higher">
|
||||||
|
<ask>This sounds like platform/system work.
|
||||||
|
|
||||||
|
**[w] Start BMad Method** (recommended) (workflow-init)
|
||||||
|
**[t] Create tech-spec** (lighter planning)
|
||||||
|
**[e] Execute directly** - feeling lucky</ask>
|
||||||
|
|
||||||
|
<check if="w">
|
||||||
|
<action>Load and execute {workflow_init}</action>
|
||||||
|
<action>EXIT quick-dev - user has been routed to BMad Method</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="t">
|
||||||
|
<action>Load and execute {create_tech_spec_workflow}</action>
|
||||||
|
<action>Continue to implementation after spec complete</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="e">
|
||||||
|
<ask>Any additional guidance before I begin? (patterns, files, constraints) Or "go" to start.</ask>
|
||||||
|
<goto>step_2</goto>
|
||||||
|
</check>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
</check>
|
||||||
|
|
||||||
|
</check>
|
||||||
|
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="2" goal="Quick context gathering (direct mode)">
|
||||||
|
|
||||||
|
<action>Identify files to modify, find relevant patterns, note dependencies</action>
|
||||||
|
|
||||||
|
<action>Create mental plan: tasks, acceptance criteria, files to touch</action>
|
||||||
|
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="3" goal="Execute implementation" id="step_3">
|
||||||
|
|
||||||
|
<action>For each task:
|
||||||
|
|
||||||
|
1. **Load Context** - read files from spec or relevant to change
|
||||||
|
2. **Implement** - follow patterns, handle errors, follow conventions
|
||||||
|
3. **Test** - write tests, run existing tests, verify AC
|
||||||
|
4. **Mark Complete** - check off task [x], continue
|
||||||
|
</action>
|
||||||
|
|
||||||
|
<action if="3 failures">HALT and request guidance</action>
|
||||||
|
<action if="tests fail">Fix before continuing</action>
|
||||||
|
|
||||||
|
<critical>Continue through ALL tasks without stopping</critical>
|
||||||
|
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="4" goal="Verify and transition to review">
|
||||||
|
|
||||||
|
<action>Verify: all tasks [x], tests passing, AC satisfied, 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}}
|
||||||
|
**AC Status:** {{ac_status}}
|
||||||
|
|
||||||
|
Running adversarial code review...
|
||||||
|
</output>
|
||||||
|
|
||||||
|
<action>Proceed immediately to step 5</action>
|
||||||
|
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="5" goal="Adversarial code review (automatic)">
|
||||||
|
|
||||||
|
<action>Construct diff of all changes since workflow started and capture as {diff_output}:
|
||||||
|
|
||||||
|
**Tracked file changes:**
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git diff {baseline_commit}
|
||||||
|
```
|
||||||
|
|
||||||
|
**New files created by this workflow:**
|
||||||
|
Only include untracked files that YOU actually created during steps 2-4. Do not include pre-existing untracked files. For each new file you created, include its full content as a "new file" addition.
|
||||||
|
|
||||||
|
Combine both into {diff_output} for review. Do NOT `git add` anything - this is read-only inspection.</action>
|
||||||
|
|
||||||
|
<action>Execute adversarial review using this hierarchy (try in order until one succeeds):
|
||||||
|
|
||||||
|
1. **Spawn subagent** (preferred) - pass the diff output along with this prompt:
|
||||||
|
|
||||||
|
```
|
||||||
|
You are a cynical, jaded code reviewer with zero patience for sloppy work. This diff was submitted by a clueless weasel and you expect to find problems. Find at least five issues to fix or improve. Number them. Be skeptical of everything.
|
||||||
|
|
||||||
|
<diff>
|
||||||
|
{diff_output}
|
||||||
|
</diff>
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **CLI fallback** - pipe diff to `claude --print` with same prompt
|
||||||
|
|
||||||
|
3. **Inline self-review** - Review the diff output yourself using the cynical reviewer persona above
|
||||||
|
</action>
|
||||||
|
|
||||||
|
<check if="zero findings returned">
|
||||||
|
<action>HALT - Zero findings is suspicious. Adversarial review should always find something. Request user guidance.</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Process findings:
|
||||||
|
|
||||||
|
- Assign IDs: F1, F2, F3...
|
||||||
|
- Assign severity: 🔴 Critical | 🟠 High | 🟡 Medium | 🟢 Low
|
||||||
|
- Classify each: **real** (confirmed issue) | **noise** (false positive) | **uncertain** (needs discussion)
|
||||||
|
</action>
|
||||||
|
|
||||||
|
<output>**Adversarial Review Findings**
|
||||||
|
|
||||||
|
| ID | Severity | Classification | Finding |
|
||||||
|
| --- | -------- | -------------- | ------- |
|
||||||
|
| F1 | 🟠 | real | ... |
|
||||||
|
| F2 | 🟡 | noise | ... |
|
||||||
|
| ... |
|
||||||
|
|
||||||
|
</output>
|
||||||
|
|
||||||
|
<ask>How would you like to handle these findings?
|
||||||
|
|
||||||
|
**[1] Walk through** - Discuss each finding individually
|
||||||
|
**[2] Auto-fix** - Automatically fix issues classified as "real"
|
||||||
|
**[3] Skip** - Acknowledge and proceed to commit</ask>
|
||||||
|
|
||||||
|
<check if="1">
|
||||||
|
<action>Present each finding one by one. For each, ask: fix now / skip / discuss</action>
|
||||||
|
<action>Apply fixes as approved</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="2">
|
||||||
|
<action>Automatically fix all findings classified as "real"</action>
|
||||||
|
<action>Report what was fixed</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="3">
|
||||||
|
<action>Acknowledge findings were reviewed and user chose to skip</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<output>**Review complete. Ready to commit.**</output>
|
||||||
|
|
||||||
|
<action>Explain what was implemented based on {user_skill_level}</action>
|
||||||
|
|
||||||
|
</step>
|
||||||
|
|
||||||
|
</workflow>
|
||||||
|
|
@ -1,148 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-01-mode-detection'
|
|
||||||
description: 'Determine execution mode (tech-spec vs direct), handle escalation, set state variables'
|
|
||||||
|
|
||||||
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
|
|
||||||
thisStepFile: '{workflow_path}/steps/step-01-mode-detection.md'
|
|
||||||
nextStepFile_modeA: '{workflow_path}/steps/step-03-execute.md'
|
|
||||||
nextStepFile_modeB: '{workflow_path}/steps/step-02-context-gathering.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 1: Mode Detection
|
|
||||||
|
|
||||||
**Goal:** Determine execution mode, capture baseline, handle escalation if needed.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## STATE VARIABLES (capture now, persist throughout)
|
|
||||||
|
|
||||||
These variables MUST be set in this step and available to all subsequent steps:
|
|
||||||
|
|
||||||
- `{baseline_commit}` - Git HEAD at workflow start
|
|
||||||
- `{execution_mode}` - "tech-spec" or "direct"
|
|
||||||
- `{tech_spec_path}` - Path to tech-spec file (if Mode A)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## EXECUTION SEQUENCE
|
|
||||||
|
|
||||||
### 1. Capture Baseline
|
|
||||||
|
|
||||||
Run `git rev-parse HEAD` and store result as `{baseline_commit}`.
|
|
||||||
|
|
||||||
### 2. Load Project Context
|
|
||||||
|
|
||||||
Check if `{project_context}` exists (`**/project-context.md`). If found, load it - this is foundational reference for ALL implementation decisions.
|
|
||||||
|
|
||||||
### 3. Parse User Input
|
|
||||||
|
|
||||||
Analyze the user's input to determine mode:
|
|
||||||
|
|
||||||
**Mode A: Tech-Spec**
|
|
||||||
|
|
||||||
- User provided a path to a tech-spec file (e.g., `quick-dev tech-spec-auth.md`)
|
|
||||||
- Load the spec, extract tasks/context/AC
|
|
||||||
- Set `{execution_mode}` = "tech-spec"
|
|
||||||
- Set `{tech_spec_path}` = provided path
|
|
||||||
- **NEXT:** Load `step-03-execute.md`
|
|
||||||
|
|
||||||
**Mode B: Direct Instructions**
|
|
||||||
|
|
||||||
- User provided task description directly (e.g., `refactor src/foo.ts...`)
|
|
||||||
- Set `{execution_mode}` = "direct"
|
|
||||||
- **NEXT:** Evaluate escalation threshold, then proceed
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## ESCALATION THRESHOLD (Mode B only)
|
|
||||||
|
|
||||||
Evaluate user input with minimal token usage (no file loading):
|
|
||||||
|
|
||||||
**Triggers escalation (if 2+ signals present):**
|
|
||||||
|
|
||||||
- Multiple components mentioned (dashboard + api + database)
|
|
||||||
- System-level language (platform, integration, architecture)
|
|
||||||
- Uncertainty about approach ("how should I", "best way to")
|
|
||||||
- Multi-layer scope (UI + backend + data together)
|
|
||||||
- Extended timeframe ("this week", "over the next few days")
|
|
||||||
|
|
||||||
**Reduces signal:**
|
|
||||||
|
|
||||||
- Simplicity markers ("just", "quickly", "fix", "bug", "typo", "simple")
|
|
||||||
- Single file/component focus
|
|
||||||
- Confident, specific request
|
|
||||||
|
|
||||||
Use holistic judgment, not mechanical keyword matching.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## ESCALATION HANDLING
|
|
||||||
|
|
||||||
### No Escalation (simple request)
|
|
||||||
|
|
||||||
Present choice:
|
|
||||||
|
|
||||||
```
|
|
||||||
**[t] Plan first** - Create tech-spec then implement
|
|
||||||
**[e] Execute directly** - Start now
|
|
||||||
```
|
|
||||||
|
|
||||||
- **[t]:** Direct user to `{create_tech_spec_workflow}`. **EXIT Quick Dev.**
|
|
||||||
- **[e]:** Ask for any additional guidance, then **NEXT:** Load `step-02-context-gathering.md`
|
|
||||||
|
|
||||||
### Escalation Triggered - Level 0-2
|
|
||||||
|
|
||||||
```
|
|
||||||
This looks like a focused feature with multiple components.
|
|
||||||
|
|
||||||
**[t] Create tech-spec first** (recommended)
|
|
||||||
**[w] Seems bigger than quick-dev** - see what BMad Method recommends
|
|
||||||
**[e] Execute directly**
|
|
||||||
```
|
|
||||||
|
|
||||||
- **[t]:** Direct to `{create_tech_spec_workflow}`. **EXIT Quick Dev.**
|
|
||||||
- **[w]:** Direct to `{workflow_init}`. **EXIT Quick Dev.**
|
|
||||||
- **[e]:** Ask for guidance, then **NEXT:** Load `step-02-context-gathering.md`
|
|
||||||
|
|
||||||
### Escalation Triggered - Level 3+
|
|
||||||
|
|
||||||
```
|
|
||||||
This sounds like platform/system work.
|
|
||||||
|
|
||||||
**[w] Start BMad Method** (recommended)
|
|
||||||
**[t] Create tech-spec** (lighter planning)
|
|
||||||
**[e] Execute directly** - feeling lucky
|
|
||||||
```
|
|
||||||
|
|
||||||
- **[w]:** Direct to `{workflow_init}`. **EXIT Quick Dev.**
|
|
||||||
- **[t]:** Direct to `{create_tech_spec_workflow}`. **EXIT Quick Dev.**
|
|
||||||
- **[e]:** Ask for guidance, then **NEXT:** Load `step-02-context-gathering.md`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## NEXT STEP DIRECTIVE
|
|
||||||
|
|
||||||
**CRITICAL:** When this step completes, explicitly state which step to load:
|
|
||||||
|
|
||||||
- Mode A (tech-spec): "**NEXT:** Loading `step-03-execute.md`"
|
|
||||||
- Mode B (direct, [e] selected): "**NEXT:** Loading `step-02-context-gathering.md`"
|
|
||||||
- Escalation ([t] or [w]): "**EXITING Quick Dev.** Follow the directed workflow."
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SUCCESS METRICS
|
|
||||||
|
|
||||||
- `{baseline_commit}` captured and stored
|
|
||||||
- `{execution_mode}` determined ("tech-spec" or "direct")
|
|
||||||
- `{tech_spec_path}` set if Mode A
|
|
||||||
- Project context loaded if exists
|
|
||||||
- Escalation evaluated appropriately (Mode B)
|
|
||||||
- Explicit NEXT directive provided
|
|
||||||
|
|
||||||
## FAILURE MODES
|
|
||||||
|
|
||||||
- Proceeding without capturing baseline commit
|
|
||||||
- Not setting execution_mode variable
|
|
||||||
- Loading step-02 when Mode A (tech-spec provided)
|
|
||||||
- Attempting to "return" after escalation instead of EXIT
|
|
||||||
- No explicit NEXT directive at step completion
|
|
||||||
|
|
@ -1,117 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-02-context-gathering'
|
|
||||||
description: 'Quick context gathering for direct mode - identify files, patterns, dependencies'
|
|
||||||
|
|
||||||
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
|
|
||||||
thisStepFile: '{workflow_path}/steps/step-02-context-gathering.md'
|
|
||||||
nextStepFile: '{workflow_path}/steps/step-03-execute.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 2: Context Gathering (Direct Mode)
|
|
||||||
|
|
||||||
**Goal:** Quickly gather context for direct instructions - files, patterns, dependencies.
|
|
||||||
|
|
||||||
**Note:** This step only runs for Mode B (direct instructions). If `{execution_mode}` is "tech-spec", this step was skipped.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## AVAILABLE STATE
|
|
||||||
|
|
||||||
From step-01:
|
|
||||||
|
|
||||||
- `{baseline_commit}` - Git HEAD at workflow start
|
|
||||||
- `{execution_mode}` - Should be "direct"
|
|
||||||
- `{project_context}` - Loaded if exists
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## EXECUTION SEQUENCE
|
|
||||||
|
|
||||||
### 1. Identify Files to Modify
|
|
||||||
|
|
||||||
Based on user's direct instructions:
|
|
||||||
|
|
||||||
- Search for relevant files using glob/grep
|
|
||||||
- Identify the specific files that need changes
|
|
||||||
- Note file locations and purposes
|
|
||||||
|
|
||||||
### 2. Find Relevant Patterns
|
|
||||||
|
|
||||||
Examine the identified files and their surroundings:
|
|
||||||
|
|
||||||
- Code style and conventions used
|
|
||||||
- Existing patterns for similar functionality
|
|
||||||
- Import/export patterns
|
|
||||||
- Error handling approaches
|
|
||||||
- Test patterns (if tests exist nearby)
|
|
||||||
|
|
||||||
### 3. Note Dependencies
|
|
||||||
|
|
||||||
Identify:
|
|
||||||
|
|
||||||
- External libraries used
|
|
||||||
- Internal module dependencies
|
|
||||||
- Configuration files that may need updates
|
|
||||||
- Related files that might be affected
|
|
||||||
|
|
||||||
### 4. Create Mental Plan
|
|
||||||
|
|
||||||
Synthesize gathered context into:
|
|
||||||
|
|
||||||
- List of tasks to complete
|
|
||||||
- Acceptance criteria (inferred from user request)
|
|
||||||
- Order of operations
|
|
||||||
- Files to touch
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## PRESENT PLAN
|
|
||||||
|
|
||||||
Display to user:
|
|
||||||
|
|
||||||
```
|
|
||||||
**Context Gathered:**
|
|
||||||
|
|
||||||
**Files to modify:**
|
|
||||||
- {list files}
|
|
||||||
|
|
||||||
**Patterns identified:**
|
|
||||||
- {key patterns}
|
|
||||||
|
|
||||||
**Plan:**
|
|
||||||
1. {task 1}
|
|
||||||
2. {task 2}
|
|
||||||
...
|
|
||||||
|
|
||||||
**Inferred AC:**
|
|
||||||
- {acceptance criteria}
|
|
||||||
|
|
||||||
Ready to execute? (y/n/adjust)
|
|
||||||
```
|
|
||||||
|
|
||||||
- **y:** Proceed to execution
|
|
||||||
- **n:** Gather more context or clarify
|
|
||||||
- **adjust:** Modify the plan based on feedback
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## NEXT STEP
|
|
||||||
|
|
||||||
When user confirms ready, load `step-03-execute.md`.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SUCCESS METRICS
|
|
||||||
|
|
||||||
- Files to modify identified
|
|
||||||
- Relevant patterns documented
|
|
||||||
- Dependencies noted
|
|
||||||
- Mental plan created with tasks and AC
|
|
||||||
- User confirmed readiness to proceed
|
|
||||||
|
|
||||||
## FAILURE MODES
|
|
||||||
|
|
||||||
- Executing this step when Mode A (tech-spec)
|
|
||||||
- Proceeding without identifying files to modify
|
|
||||||
- Not presenting plan for user confirmation
|
|
||||||
- Missing obvious patterns in existing code
|
|
||||||
|
|
@ -1,113 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-03-execute'
|
|
||||||
description: 'Execute implementation - iterate through tasks, write code, run tests'
|
|
||||||
|
|
||||||
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
|
|
||||||
thisStepFile: '{workflow_path}/steps/step-03-execute.md'
|
|
||||||
nextStepFile: '{workflow_path}/steps/step-04-self-check.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 3: Execute Implementation
|
|
||||||
|
|
||||||
**Goal:** Implement all tasks, write tests, follow patterns, handle errors.
|
|
||||||
|
|
||||||
**Critical:** Continue through ALL tasks without stopping for milestones.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## AVAILABLE STATE
|
|
||||||
|
|
||||||
From previous steps:
|
|
||||||
|
|
||||||
- `{baseline_commit}` - Git HEAD at workflow start
|
|
||||||
- `{execution_mode}` - "tech-spec" or "direct"
|
|
||||||
- `{tech_spec_path}` - Tech-spec file (if Mode A)
|
|
||||||
- `{project_context}` - Project patterns (if exists)
|
|
||||||
|
|
||||||
From context:
|
|
||||||
|
|
||||||
- Mode A: Tasks and AC extracted from tech-spec
|
|
||||||
- Mode B: Tasks and AC from step-02 mental plan
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## EXECUTION LOOP
|
|
||||||
|
|
||||||
For each task:
|
|
||||||
|
|
||||||
### 1. Load Context
|
|
||||||
|
|
||||||
- Read files relevant to this task
|
|
||||||
- Review patterns from project-context or observed code
|
|
||||||
- Understand dependencies
|
|
||||||
|
|
||||||
### 2. Implement
|
|
||||||
|
|
||||||
- Write code following existing patterns
|
|
||||||
- Handle errors appropriately
|
|
||||||
- Follow conventions observed in codebase
|
|
||||||
- Add appropriate comments where non-obvious
|
|
||||||
|
|
||||||
### 3. Test
|
|
||||||
|
|
||||||
- Write tests if appropriate for the change
|
|
||||||
- Run existing tests to catch regressions
|
|
||||||
- Verify the specific AC for this task
|
|
||||||
|
|
||||||
### 4. Mark Complete
|
|
||||||
|
|
||||||
- Check off task: `- [x] Task N`
|
|
||||||
- Continue to next task immediately
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## HALT CONDITIONS
|
|
||||||
|
|
||||||
**HALT and request guidance if:**
|
|
||||||
|
|
||||||
- 3 consecutive failures on same task
|
|
||||||
- Tests fail and fix is not obvious
|
|
||||||
- Blocking dependency discovered
|
|
||||||
- Ambiguity that requires user decision
|
|
||||||
|
|
||||||
**Do NOT halt for:**
|
|
||||||
|
|
||||||
- Minor issues that can be noted and continued
|
|
||||||
- Warnings that don't block functionality
|
|
||||||
- Style preferences (follow existing patterns)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## CONTINUOUS EXECUTION
|
|
||||||
|
|
||||||
**Critical:** Do not stop between tasks for approval.
|
|
||||||
|
|
||||||
- Execute all tasks in sequence
|
|
||||||
- Only halt for blocking issues
|
|
||||||
- Tests failing = fix before continuing
|
|
||||||
- Track all completed work for self-check
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## NEXT STEP
|
|
||||||
|
|
||||||
When ALL tasks are complete (or halted on blocker), load `step-04-self-check.md`.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SUCCESS METRICS
|
|
||||||
|
|
||||||
- All tasks attempted
|
|
||||||
- Code follows existing patterns
|
|
||||||
- Error handling appropriate
|
|
||||||
- Tests written where appropriate
|
|
||||||
- Tests passing
|
|
||||||
- No unnecessary halts
|
|
||||||
|
|
||||||
## FAILURE MODES
|
|
||||||
|
|
||||||
- Stopping for approval between tasks
|
|
||||||
- Ignoring existing patterns
|
|
||||||
- Not running tests after changes
|
|
||||||
- Giving up after first failure
|
|
||||||
- Not following project-context rules (if exists)
|
|
||||||
|
|
@ -1,113 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-04-self-check'
|
|
||||||
description: 'Self-audit implementation against tasks, tests, AC, and patterns'
|
|
||||||
|
|
||||||
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
|
|
||||||
thisStepFile: '{workflow_path}/steps/step-04-self-check.md'
|
|
||||||
nextStepFile: '{workflow_path}/steps/step-05-adversarial-review.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 4: Self-Check
|
|
||||||
|
|
||||||
**Goal:** Audit completed work against tasks, tests, AC, and patterns before external review.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## AVAILABLE STATE
|
|
||||||
|
|
||||||
From previous steps:
|
|
||||||
|
|
||||||
- `{baseline_commit}` - Git HEAD at workflow start
|
|
||||||
- `{execution_mode}` - "tech-spec" or "direct"
|
|
||||||
- `{tech_spec_path}` - Tech-spec file (if Mode A)
|
|
||||||
- `{project_context}` - Project patterns (if exists)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SELF-CHECK AUDIT
|
|
||||||
|
|
||||||
### 1. Tasks Complete
|
|
||||||
|
|
||||||
Verify all tasks are marked complete:
|
|
||||||
|
|
||||||
- [ ] All tasks from tech-spec or mental plan marked `[x]`
|
|
||||||
- [ ] No tasks skipped without documented reason
|
|
||||||
- [ ] Any blocked tasks have clear explanation
|
|
||||||
|
|
||||||
### 2. Tests Passing
|
|
||||||
|
|
||||||
Verify test status:
|
|
||||||
|
|
||||||
- [ ] All existing tests still pass
|
|
||||||
- [ ] New tests written for new functionality
|
|
||||||
- [ ] No test warnings or skipped tests without reason
|
|
||||||
|
|
||||||
### 3. Acceptance Criteria Satisfied
|
|
||||||
|
|
||||||
For each AC:
|
|
||||||
|
|
||||||
- [ ] AC is demonstrably met
|
|
||||||
- [ ] Can explain how implementation satisfies AC
|
|
||||||
- [ ] Edge cases considered
|
|
||||||
|
|
||||||
### 4. Patterns Followed
|
|
||||||
|
|
||||||
Verify code quality:
|
|
||||||
|
|
||||||
- [ ] Follows existing code patterns in codebase
|
|
||||||
- [ ] Follows project-context rules (if exists)
|
|
||||||
- [ ] Error handling consistent with codebase
|
|
||||||
- [ ] No obvious code smells introduced
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## UPDATE TECH-SPEC (Mode A only)
|
|
||||||
|
|
||||||
If `{execution_mode}` is "tech-spec":
|
|
||||||
|
|
||||||
1. Load `{tech_spec_path}`
|
|
||||||
2. Mark all tasks as `[x]` complete
|
|
||||||
3. Update status to "Implementation Complete"
|
|
||||||
4. Save changes
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## IMPLEMENTATION SUMMARY
|
|
||||||
|
|
||||||
Present summary to transition to review:
|
|
||||||
|
|
||||||
```
|
|
||||||
**Implementation Complete!**
|
|
||||||
|
|
||||||
**Summary:** {what was implemented}
|
|
||||||
**Files Modified:** {list of files}
|
|
||||||
**Tests:** {test summary - passed/added/etc}
|
|
||||||
**AC Status:** {all satisfied / issues noted}
|
|
||||||
|
|
||||||
Proceeding to adversarial code review...
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## NEXT STEP
|
|
||||||
|
|
||||||
Proceed immediately to `step-05-adversarial-review.md`.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SUCCESS METRICS
|
|
||||||
|
|
||||||
- All tasks verified complete
|
|
||||||
- All tests passing
|
|
||||||
- All AC satisfied
|
|
||||||
- Patterns followed
|
|
||||||
- Tech-spec updated (if Mode A)
|
|
||||||
- Summary presented
|
|
||||||
|
|
||||||
## FAILURE MODES
|
|
||||||
|
|
||||||
- Claiming tasks complete when they're not
|
|
||||||
- Not running tests before proceeding
|
|
||||||
- Missing AC verification
|
|
||||||
- Ignoring pattern violations
|
|
||||||
- Not updating tech-spec status (Mode A)
|
|
||||||
|
|
@ -1,96 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-05-adversarial-review'
|
|
||||||
description: 'Construct diff and invoke adversarial review task'
|
|
||||||
|
|
||||||
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
|
|
||||||
thisStepFile: '{workflow_path}/steps/step-05-adversarial-review.md'
|
|
||||||
nextStepFile: '{workflow_path}/steps/step-06-resolve-findings.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 5: Adversarial Code Review
|
|
||||||
|
|
||||||
**Goal:** Construct diff of all changes, invoke adversarial review task, present findings.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## AVAILABLE STATE
|
|
||||||
|
|
||||||
From previous steps:
|
|
||||||
|
|
||||||
- `{baseline_commit}` - Git HEAD at workflow start (CRITICAL for diff)
|
|
||||||
- `{execution_mode}` - "tech-spec" or "direct"
|
|
||||||
- `{tech_spec_path}` - Tech-spec file (if Mode A)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## STEP 1: CONSTRUCT DIFF
|
|
||||||
|
|
||||||
Build complete diff of all changes since workflow started.
|
|
||||||
|
|
||||||
### Tracked File Changes
|
|
||||||
|
|
||||||
```bash
|
|
||||||
git diff {baseline_commit}
|
|
||||||
```
|
|
||||||
|
|
||||||
### New Untracked Files
|
|
||||||
|
|
||||||
Only include untracked files that YOU created during this workflow (steps 2-4).
|
|
||||||
Do not include pre-existing untracked files.
|
|
||||||
For each new file created, include its full content as a "new file" addition.
|
|
||||||
|
|
||||||
### Capture as {diff_output}
|
|
||||||
|
|
||||||
Merge tracked changes and new files into `{diff_output}`.
|
|
||||||
|
|
||||||
**Note:** Do NOT `git add` anything - this is read-only inspection.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## STEP 2: INVOKE ADVERSARIAL REVIEW
|
|
||||||
|
|
||||||
With `{diff_output}` constructed, invoke the review task:
|
|
||||||
|
|
||||||
```xml
|
|
||||||
<invoke-task input="{diff_output}">{project-root}/_bmad/core/tasks/review-adversarial-general.xml</invoke-task>
|
|
||||||
```
|
|
||||||
|
|
||||||
**Platform fallback:** If task invocation not available, load the task file and execute its instructions inline, passing `{diff_output}` as the content input.
|
|
||||||
|
|
||||||
The task will:
|
|
||||||
|
|
||||||
- Review with cynical skepticism
|
|
||||||
- Find at least 5 issues
|
|
||||||
- Assign IDs (F1, F2...), severity (critical/high/medium/low), classification (real/noise/uncertain)
|
|
||||||
- Return structured findings table
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## STEP 3: RECEIVE FINDINGS
|
|
||||||
|
|
||||||
Capture the findings from the task output.
|
|
||||||
|
|
||||||
**If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## NEXT STEP
|
|
||||||
|
|
||||||
With findings in hand, load `step-06-resolve-findings.md` for user to choose resolution approach.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SUCCESS METRICS
|
|
||||||
|
|
||||||
- Diff constructed from baseline_commit
|
|
||||||
- New files included in diff
|
|
||||||
- Task invoked with diff as input
|
|
||||||
- Findings received with IDs, severity, classification
|
|
||||||
- Zero-findings case handled appropriately
|
|
||||||
|
|
||||||
## FAILURE MODES
|
|
||||||
|
|
||||||
- Missing baseline_commit (can't construct accurate diff)
|
|
||||||
- Not including new untracked files in diff
|
|
||||||
- Invoking task without providing diff input
|
|
||||||
- Accepting zero findings without questioning
|
|
||||||
|
|
@ -1,140 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-06-resolve-findings'
|
|
||||||
description: 'Handle review findings interactively, apply fixes, update tech-spec with final status'
|
|
||||||
|
|
||||||
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
|
|
||||||
thisStepFile: '{workflow_path}/steps/step-06-resolve-findings.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 6: Resolve Findings
|
|
||||||
|
|
||||||
**Goal:** Handle adversarial review findings interactively, apply fixes, finalize tech-spec.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## AVAILABLE STATE
|
|
||||||
|
|
||||||
From previous steps:
|
|
||||||
|
|
||||||
- `{baseline_commit}` - Git HEAD at workflow start
|
|
||||||
- `{execution_mode}` - "tech-spec" or "direct"
|
|
||||||
- `{tech_spec_path}` - Tech-spec file (if Mode A)
|
|
||||||
- Findings table from step-05
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## RESOLUTION OPTIONS
|
|
||||||
|
|
||||||
Present choice to user:
|
|
||||||
|
|
||||||
```
|
|
||||||
How would you like to handle these findings?
|
|
||||||
|
|
||||||
**[1] Walk through** - Discuss each finding individually
|
|
||||||
**[2] Auto-fix** - Automatically fix issues classified as "real"
|
|
||||||
**[3] Skip** - Acknowledge and proceed to commit
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## OPTION 1: WALK THROUGH
|
|
||||||
|
|
||||||
For each finding in order:
|
|
||||||
|
|
||||||
1. Present the finding with context
|
|
||||||
2. Ask: **fix now / skip / discuss**
|
|
||||||
3. If fix: Apply the fix immediately
|
|
||||||
4. If skip: Note as acknowledged, continue
|
|
||||||
5. If discuss: Provide more context, re-ask
|
|
||||||
6. Move to next finding
|
|
||||||
|
|
||||||
After all findings processed, summarize what was fixed/skipped.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## OPTION 2: AUTO-FIX
|
|
||||||
|
|
||||||
1. Filter findings to only those classified as "real"
|
|
||||||
2. Apply fixes for each real finding
|
|
||||||
3. Report what was fixed:
|
|
||||||
|
|
||||||
```
|
|
||||||
**Auto-fix Applied:**
|
|
||||||
- F1: {description of fix}
|
|
||||||
- F3: {description of fix}
|
|
||||||
...
|
|
||||||
|
|
||||||
Skipped (noise/uncertain): F2, F4
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## OPTION 3: SKIP
|
|
||||||
|
|
||||||
1. Acknowledge all findings were reviewed
|
|
||||||
2. Note that user chose to proceed without fixes
|
|
||||||
3. Continue to completion
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## UPDATE TECH-SPEC (Mode A only)
|
|
||||||
|
|
||||||
If `{execution_mode}` is "tech-spec":
|
|
||||||
|
|
||||||
1. Load `{tech_spec_path}`
|
|
||||||
2. Update status to "Completed"
|
|
||||||
3. Add review notes:
|
|
||||||
```
|
|
||||||
## Review Notes
|
|
||||||
- Adversarial review completed
|
|
||||||
- Findings: {count} total, {fixed} fixed, {skipped} skipped
|
|
||||||
- Resolution approach: {walk-through/auto-fix/skip}
|
|
||||||
```
|
|
||||||
4. Save changes
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## COMPLETION OUTPUT
|
|
||||||
|
|
||||||
```
|
|
||||||
**Review complete. Ready to commit.**
|
|
||||||
|
|
||||||
**Implementation Summary:**
|
|
||||||
- {what was implemented}
|
|
||||||
- Files modified: {count}
|
|
||||||
- Tests: {status}
|
|
||||||
- Review findings: {X} addressed, {Y} skipped
|
|
||||||
|
|
||||||
{Explain what was implemented based on user_skill_level}
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## WORKFLOW COMPLETE
|
|
||||||
|
|
||||||
This is the final step. The Quick Dev workflow is now complete.
|
|
||||||
|
|
||||||
User can:
|
|
||||||
|
|
||||||
- Commit changes
|
|
||||||
- Run additional tests
|
|
||||||
- Start new Quick Dev session
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## SUCCESS METRICS
|
|
||||||
|
|
||||||
- User presented with resolution options
|
|
||||||
- Chosen approach executed correctly
|
|
||||||
- Fixes applied cleanly (if applicable)
|
|
||||||
- Tech-spec updated with final status (Mode A)
|
|
||||||
- Completion summary provided
|
|
||||||
- User understands what was implemented
|
|
||||||
|
|
||||||
## FAILURE MODES
|
|
||||||
|
|
||||||
- Not presenting resolution options
|
|
||||||
- Auto-fixing "noise" or "uncertain" findings
|
|
||||||
- Not updating tech-spec after resolution (Mode A)
|
|
||||||
- No completion summary
|
|
||||||
- Leaving user unclear on next steps
|
|
||||||
|
|
@ -1,62 +0,0 @@
|
||||||
---
|
|
||||||
name: quick-dev
|
|
||||||
description: 'Flexible development - execute tech-specs OR direct instructions with optional planning.'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Quick Dev Workflow
|
|
||||||
|
|
||||||
**Goal:** Execute implementation tasks efficiently, either from a tech-spec or direct user instructions.
|
|
||||||
|
|
||||||
**Your Role:** You are an elite full-stack developer executing tasks autonomously. Follow patterns, ship code, run tests. Every response moves the project forward.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## WORKFLOW ARCHITECTURE
|
|
||||||
|
|
||||||
This uses **step-file architecture** for focused execution:
|
|
||||||
|
|
||||||
- Each step loads fresh to combat "lost in the middle"
|
|
||||||
- State persists via variables: `{baseline_commit}`, `{execution_mode}`, `{tech_spec_path}`
|
|
||||||
- Sequential progression through implementation phases
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## INITIALIZATION
|
|
||||||
|
|
||||||
### Configuration Loading
|
|
||||||
|
|
||||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|
||||||
|
|
||||||
- `user_name`, `communication_language`, `user_skill_level`
|
|
||||||
- `output_folder`, `sprint_artifacts`
|
|
||||||
- `date` as system-generated current datetime
|
|
||||||
|
|
||||||
### Paths
|
|
||||||
|
|
||||||
- `installed_path` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev`
|
|
||||||
- `project_context` = `**/project-context.md` (load if exists)
|
|
||||||
- `project_levels` = `{project-root}/_bmad/bmm/workflows/workflow-status/project-levels.yaml`
|
|
||||||
|
|
||||||
### Related Workflows
|
|
||||||
|
|
||||||
- `create_tech_spec_workflow` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.yaml`
|
|
||||||
- `workflow_init` = `{project-root}/_bmad/bmm/workflows/workflow-status/init/workflow.yaml`
|
|
||||||
- `party_mode_exec` = `{project-root}/_bmad/core/workflows/party-mode/workflow.md`
|
|
||||||
- `advanced_elicitation` = `{project-root}/_bmad/core/tasks/advanced-elicitation.xml`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## CHECKPOINT HANDLERS
|
|
||||||
|
|
||||||
At any checkpoint throughout this workflow, the following options are available:
|
|
||||||
|
|
||||||
- **[a] Advanced Elicitation** - Invoke `{advanced_elicitation}` for deeper analysis using First Principles, Pre-mortem, or other techniques
|
|
||||||
- **[p] Party Mode** - Invoke `{party_mode_exec}` to bring in multiple agent perspectives for complex decisions
|
|
||||||
|
|
||||||
These are optional power tools - use when stuck, facing ambiguity, or wanting diverse input.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## EXECUTION
|
|
||||||
|
|
||||||
Load and execute `steps/step-01-mode-detection.md` to begin the workflow.
|
|
||||||
|
|
@ -0,0 +1,33 @@
|
||||||
|
# Quick-Flow: Quick-Dev
|
||||||
|
name: quick-dev
|
||||||
|
description: "Flexible development - execute tech-specs OR direct instructions with optional planning."
|
||||||
|
author: "BMad"
|
||||||
|
|
||||||
|
# Config
|
||||||
|
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||||
|
output_folder: "{config_source}:output_folder"
|
||||||
|
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||||
|
user_name: "{config_source}:user_name"
|
||||||
|
communication_language: "{config_source}:communication_language"
|
||||||
|
user_skill_level: "{config_source}:user_skill_level"
|
||||||
|
date: system-generated
|
||||||
|
|
||||||
|
# Project context
|
||||||
|
project_context: "**/project-context.md"
|
||||||
|
|
||||||
|
# Workflow components
|
||||||
|
installed_path: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev"
|
||||||
|
instructions: "{installed_path}/instructions.md"
|
||||||
|
checklist: "{installed_path}/checklist.md"
|
||||||
|
|
||||||
|
# Related workflows
|
||||||
|
create_tech_spec_workflow: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.yaml"
|
||||||
|
party_mode_exec: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
|
||||||
|
advanced_elicitation: "{project-root}/_bmad/core/tasks/advanced-elicitation.xml"
|
||||||
|
|
||||||
|
# Routing resources (lazy-loaded)
|
||||||
|
project_levels: "{project-root}/_bmad/bmm/workflows/workflow-status/project-levels.yaml"
|
||||||
|
workflow_init: "{project-root}/_bmad/bmm/workflows/workflow-status/init/workflow.yaml"
|
||||||
|
|
||||||
|
standalone: true
|
||||||
|
web_bundle: false
|
||||||
Loading…
Reference in New Issue