# Workflow Init - Project Setup Instructions
The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: workflow-init/workflow.yaml
Communicate in {communication_language} with {user_name}
Quick scan for context (do NOT analyze in depth yet):
- Check for codebase: src/, lib/, package.json, .git, etc.
- Check for BMM artifacts: PRD, epics, stories, tech-spec, architecture docs
- Store what was found but do NOT infer project details yet
What's your project called? {{#if project_name}}(Config shows: {{project_name}}){{/if}}
Set project_name
project_name
Looking at what I found, are these:
a) **Works in progress you're finishing** - continuing the work described in these documents
b) **Documents from a previous effort** - you're starting something NEW and different now
c) **The proposed work you're about to start** - these describe what you want to do
d) **None of these** - let me explain what I'm actually working on
Your choice [a/b/c/d]:
User is continuing old work - analyze artifacts to get details
Set continuing_old_work = true
Go to Step 2 (Analyze artifacts for details)
User is doing NEW work - old artifacts are just context
Set continuing_old_work = false
Go to Step 3 (Ask about NEW work)
Artifacts describe proposed work
Set continuing_old_work = true
Go to Step 2 (Analyze artifacts for details)
User will explain their situation
Go to Step 3 (Ask about their work)
Go to Step 3 (Ask about their work)
Analyze found artifacts in detail:
Extract project type from content (game vs software)
Count stories/epics to estimate level:
- Level 0: 1 story
- Level 1: 1-10 stories
- Level 2: 5-15 stories
- Level 3: 12-40 stories
- Level 4: 40+ stories
Detect field type from codebase presence (greenfield vs brownfield)
Does this match what you're working on? (y/n or tell me what's different)
Use analyzed values
Go to Step 4 (Load workflow path)
Update values based on user corrections
Updated to: Level {{project_level}} {{field_type}} {{project_type}}. Correct? (y/n)
Go to Step 4 (Load workflow path)
project_name
project_type
project_level
field_type
Tell me about what you're working on. What's the goal?
Analyze user's description using keyword detection:
- Level 0 keywords: "fix", "bug", "typo", "small change", "update", "patch", "one file"
- Level 1 keywords: "simple", "basic", "small feature", "add", "minor", "single feature"
- Level 2 keywords: "dashboard", "several features", "admin panel", "medium", "feature set"
- Level 3 keywords: "platform", "integration", "complex", "system", "architecture"
- Level 4 keywords: "enterprise", "multi-tenant", "multiple products", "ecosystem", "phased"
Make initial determination:
- project_type (game or software)
- project_level (0-4) - tentative based on keywords
- field_type (greenfield or brownfield)
- confidence (high/medium/low) - based on clarity of description
1. Roughly how many distinct features or changes do you think this involves?
- Just one thing (e.g., fix a bug, add one button, update one API)
- A small feature (2-5 related changes)
- Several features (5-15 related things)
- A major addition (15-40 things to do)
- A large initiative (40+ changes across many areas)
Adjust project_level based on response
2. How much of the existing codebase will this touch?
- Single file or small area
- One module or component
- Multiple modules (2-4 areas)
- Many modules with integration needs
- System-wide changes
Validate and adjust project_level based on scope
3. Is this a game or a software application?
Set project_type based on response
I see you have existing code here. Are you:
1. **Adding to or modifying** the existing codebase (brownfield)
2. **Starting fresh** - the existing code is just a scaffold/template (greenfield)
3. **Something else** - let me clarify
Your choice [1/2/3]:
Set field_type = "brownfield"
Set field_type = "greenfield"
Please explain your situation:
Analyze explanation and set field_type accordingly
Build reasoning for suggestion
Store detected_indicators (keywords, scope indicators, complexity signals)
Does this match what you're working on? (y/n or tell me what's different)
Use determined values
Go to Step 4 (Load workflow path)
Update values based on corrections
Does that look right now? (y/n)
If yes, go to Step 4. If no, ask what needs adjustment and repeat.
project_name
project_type
project_level
field_type
Determine path file based on selections:
Load {path_files}/game-design.yaml
Set workflow_path_file = "game-design.yaml"
Build filename: {field_type}-level-{project_level}.yaml
Load {path_files}/{field_type}-level-{project_level}.yaml
Set workflow_path_file = constructed filename
Parse workflow path file to extract phases and workflows
workflow_path_file
Parse the loaded workflow path file and extract all workflows
For each phase in the path file:
- Extract phase number and name
- Extract all workflows in that phase
- For each workflow, determine its status type:
- required: true → status = "required"
- recommended: true → status = "recommended"
- conditional: "if_has_ui" → status = "conditional"
- optional: true → status = "optional"
- Default if not specified → status = "required"
Build the workflow_items list in this format:
For each phase:
1. Add comment header: ` # Phase {n}: {Phase Name}`
2. For each workflow in phase:
- Add entry: ` {workflow-id}: {status}`
3. Add blank line between phases
Example structure:
```
# Phase 1: Analysis
brainstorm-project: optional
research: optional
product-brief: recommended
# Phase 2: Planning
prd: required
validate-prd: optional
create-design: conditional
```
Scan for existing workflow output files to auto-detect completion:
For each workflow in the list, check common output locations:
- {output_folder}/brainstorm-\*.md for brainstorm-project
- {output_folder}/research-\*.md for research
- {output_folder}/product-brief.md for product-brief
- {output_folder}/prd.md for prd
- {output_folder}/ux-design.md for create-design
- {output_folder}/architecture.md for create-architecture
- {output_folder}/tech-spec.md for tech-spec
- {output_folder}/sprint-status.yaml for sprint-planning
CRITICAL: If file exists, replace status with ONLY the file path - nothing else.
Example: product-brief: docs/product-brief.md
NOT: product-brief: "completed - docs/product-brief.md" or any other text.
workflow_items
Set generated date to current date
generated
Prepare all template variables for workflow-status-template.yaml:
- generated: {current_date}
- project_name: {project_name}
- project_type: {project_type}
- project_level: {project_level}
- field_type: {field_type}
- workflow_path_file: {workflow_path_file}
- workflow_items: {workflow_items from step 5}
Display a preview of what will be created:
Show the first workflow in each phase and total count:
"Ready to create workflow status tracking:
- Phase 1 ({phase_1_workflow_count} workflows): Starting with {first_workflow_phase_1}
- Phase 2 ({phase_2_workflow_count} workflows): Starting with {first_workflow_phase_2}
- Phase 3 ({phase_3_workflow_count} workflows): Starting with {first_workflow_phase_3}
- Phase 4 (Implementation tracked separately in sprint-status.yaml)
{{#if detected_completed_workflows}}
Found existing work:
{{#each detected_files}}
- {{workflow_name}}: {{file_path}}
{{/each}}
{{/if}}"
Ready to create your workflow status file? (y/n)
Generate YAML from workflow-status-template.yaml with all variables
Save status file to {output_folder}/bmm-workflow-status.yaml
Identify the first non-completed workflow in the list
Look up that workflow's agent and command from the path file