Compare commits

...

5 Commits

Author SHA1 Message Date
shindo107 c6bac5411e
Merge 594d9854eb into c748f0f6cc 2026-01-01 14:01:39 +00:00
Brian Madison c748f0f6cc paths for workflow and sprint tatus files fixed 2026-01-01 21:20:14 +08:00
Andaman Lekawat 4142972b6a
fix: standardize variable naming from {project_root} to {project-root} (#1217)
Fixed inconsistent variable naming in workflow instruction files across
CIS, BMGD, and BMM modules. The standard variable format uses hyphens
({project-root}) not underscores ({project_root}).

Affected files:
- CIS: problem-solving, innovation-strategy, design-thinking, storytelling
- BMGD: brainstorm-game, narrative, create-story checklist
- BMM: excalidraw diagrams, create-story checklist

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Brian <bmadcode@gmail.com>
2026-01-01 21:14:21 +08:00
Murat K Ozcan cd45d22eb6
docs: chose your tea engagement (#1228)
* docs: chose your tea engagement

* docs: addressed PR comments

* docs: made refiements to the mermaid diagram

* docs: wired in test architect discoverability nudges

---------

Co-authored-by: Brian <bmadcode@gmail.com>
2026-01-01 19:06:55 +08:00
Nick Pirocanac a297235862
fix: *code-review is picking up non-application files (#1232)
Co-authored-by: Nick Pirocanac <nick.pirocanac@rtktickets.com>
2026-01-01 13:22:51 +08:00
33 changed files with 108 additions and 47 deletions

View File

@ -161,7 +161,7 @@ Production workflows inherit from BMM and add game-specific overrides.
**Command:** `sprint-planning`
**Agent:** Game Scrum Master
**Input:** GDD with epics
**Output:** `{output_folder}/sprint-status.yaml`
**Output:** `{implementation_artifacts}/sprint-status.yaml`
**Description:**
Generates or updates sprint tracking from epic files. Sets up the sprint backlog and tracking.

View File

@ -40,6 +40,8 @@ First know there is the full BMad Method Process and then there is a Quick Flow
- Implementation in minutes, not days
- Has a specialized single agent that does all of this: **[Quick Flow Solo Dev Agent](./quick-flow-solo-dev.md)**
- **TEA engagement (optional)** - Choose TEA engagement: none, TEA-only (standalone), or integrated by track. See **[Test Architect Guide](./test-architecture.md)**.
## 🤖 Agents and Collaboration
Complete guide to BMM's AI agent team:

View File

@ -179,6 +179,16 @@ Once epics and stories are created:
**Why run this?** It ensures all your planning assets align properly before you start building.
#### Optional: TEA Engagement
Testing is not mandated by BMad. Decide how you want to engage TEA:
- **No TEA** - Use your existing team testing approach
- **TEA-only (Standalone)** - Use TEA workflows with your own requirements and environment
- **TEA-integrated** - Use TEA as part of the BMad Method or Enterprise flow
See the [Test Architect Guide](./test-architecture.md) for the five TEA engagement models and recommended sequences.
#### Context Management Tips
- **Use 200k+ context models** for best results (Claude Sonnet 4.5, GPT-4, etc.)
@ -211,7 +221,14 @@ Once planning and architecture are complete, you'll move to Phase 4. **Important
3. Tell the agent: "Run dev-story"
4. The DEV agent will implement the story and update the sprint status
#### 3.4 Review the Code (Optional but Recommended)
#### 3.4 Generate Guardrail Tests (Optional)
1. **Start a new chat** with the **TEA agent**
2. Wait for the menu
3. Tell the agent: "Run automate"
4. The TEA agent generates or expands tests to act as guardrails
#### 3.5 Review the Code (Optional but Recommended)
1. **Start a new chat** with the **DEV agent**
2. Wait for the menu
@ -224,7 +241,8 @@ For each subsequent story, repeat the cycle using **fresh chats** for each workf
1. **New chat** → SM agent → "Run create-story"
2. **New chat** → DEV agent → "Run dev-story"
3. **New chat** → DEV agent → "Run code-review" (optional but recommended)
3. **New chat** → TEA agent → "Run automate" (optional)
4. **New chat** → DEV agent → "Run code-review" (optional but recommended)
After completing all stories in an epic:

View File

@ -6,6 +6,38 @@
- **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project complexity and compliance demands.
- **Use When:** BMad Method or Enterprise track projects, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required. (Quick Flow projects typically don't require TEA)
## Choose Your TEA Engagement Model
BMad does not mandate TEA. There are five valid ways to use it (or skip it). Pick one intentionally.
1. **No TEA**
- Skip all TEA workflows. Use your existing team testing approach.
2. **TEA-only (Standalone)**
- Use TEA on a non-BMad project. Bring your own requirements, acceptance criteria, and environments.
- Typical sequence: `*test-design` (system or epic) -> `*atdd` and/or `*automate` -> optional `*test-review` -> `*trace` for coverage and gate decisions.
- Run `*framework` or `*ci` only if you want TEA to scaffold the harness or pipeline.
3. **Integrated: Greenfield - BMad Method (Simple/Standard Work)**
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
- Phase 4: per-epic `*test-design`, optional `*atdd`, then `*automate` and optional `*test-review`.
- Gate (Phase 2): `*trace`.
4. **Integrated: Brownfield - BMad Method or Enterprise (Simple or Complex)**
- Phase 2: baseline `*trace`.
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
- Phase 4: per-epic `*test-design` focused on regression and integration risks.
- Gate (Phase 2): `*trace`; `*nfr-assess` (if not done earlier).
- For brownfield BMad Method, follow the same flow with `*nfr-assess` optional.
5. **Integrated: Greenfield - Enterprise Method (Enterprise/Compliance Work)**
- Phase 2: `*nfr-assess`.
- Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
- Phase 4: per-epic `*test-design`, plus `*atdd`/`*automate`/`*test-review`.
- Gate (Phase 2): `*trace`; archive artifacts as needed.
If you are unsure, default to the integrated path for your track and adjust later.
## TEA Workflow Lifecycle
TEA integrates into the BMad development lifecycle during Solutioning (Phase 3) and Implementation (Phase 4):
@ -16,6 +48,9 @@ graph TB
subgraph Phase2["<b>Phase 2: PLANNING</b>"]
PM["<b>PM: *prd (creates PRD with FRs/NFRs)</b>"]
PlanNote["<b>Business requirements phase</b>"]
NFR2["<b>TEA: *nfr-assess (optional, enterprise)</b>"]
PM -.-> NFR2
NFR2 -.-> PlanNote
PM -.-> PlanNote
end
@ -23,8 +58,8 @@ graph TB
Architecture["<b>Architect: *architecture</b>"]
EpicsStories["<b>PM/Architect: *create-epics-and-stories</b>"]
TestDesignSys["<b>TEA: *test-design (system-level)</b>"]
Framework["<b>TEA: *framework</b>"]
CI["<b>TEA: *ci</b>"]
Framework["<b>TEA: *framework (optional if needed)</b>"]
CI["<b>TEA: *ci (optional if needed)</b>"]
GateCheck["<b>Architect: *implementation-readiness</b>"]
Architecture --> EpicsStories
Architecture --> TestDesignSys
@ -174,7 +209,7 @@ npm install -D @seontechnologies/playwright-utils
**Enable during BMAD installation** by answering "Yes" when prompted.
**Supported utilities (11 total):**
**Supported utilities (10 total):**
- api-request, network-recorder, auth-session, intercept-network-call, recurse
- log, file-utils, burn-in, network-error-monitor
@ -429,7 +464,7 @@ Provides fixture-based utilities that integrate into TEA's test generation and r
Benefit: Faster CI feedback, HTTP error detection
**Utilities available** (11 total): api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
**Utilities available** (10 total): api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
**Enable during BMAD installation** by answering "Yes" when prompted, or manually set `tea_use_playwright_utils: true` in `_bmad/bmm/config.yaml`.

View File

@ -98,8 +98,9 @@ Stories move through these states in the sprint status file:
1. SM runs `create-story`
2. DEV runs `dev-story`
3. DEV runs `code-review`
4. If code review fails: DEV fixes issues in `dev-story`, then re-runs `code-review`
3. (Optional) TEA runs `*automate` to generate or expand guardrail tests
4. DEV runs `code-review`
5. If code review fails: DEV fixes issues in `dev-story`, then re-runs `code-review`
**After Epic Complete:**

View File

@ -434,7 +434,7 @@ Architecture documents are living. Update them as you learn during implementatio
**Key Difference:** Enterprise adds optional extended workflows AFTER architecture but BEFORE create-epics-and-stories. Everything else is identical to BMad Method.
**Note:** TEA (Test Architect) operates across all phases and validates architecture testability but is not a Phase 3-specific workflow. See [Test Architecture Guide](../../../../docs/modules/bmm-bmad-method/test-architecture.md) for TEA's full lifecycle integration.
**Note:** TEA (Test Architect) operates across all phases and validates architecture testability but is not a Phase 3-specific workflow. See [Test Architecture Guide](./test-architecture.md) for TEA's full lifecycle integration.
---

View File

@ -1,4 +1,4 @@
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language}</critical>
<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with game-specific context and additional game design techniques</critical>

View File

@ -2,7 +2,7 @@
<workflow>
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already completed the GDD workflow</critical>
<critical>Communicate all responses in {communication_language}</critical>
<critical>This workflow creates detailed narrative content for story-driven games</critical>

View File

@ -12,6 +12,7 @@
<critical>Read EVERY file in the File List - verify implementation against story requirements</critical>
<critical>Tasks marked complete but not done = CRITICAL finding</critical>
<critical>Acceptance Criteria not implemented = HIGH severity finding</critical>
<critical>Do not review files that are not part of the application's source code. Always exclude the _bmad/ and _bmad-output/ folders from the review. Always exclude IDE and CLI configuration folders like .cursor/ and .windsurf/ and .claude/</critical>
<step n="1" goal="Load story and discover changes">
<action>Use provided {{story_path}} or ask user which story file to review</action>

View File

@ -12,7 +12,7 @@ user_skill_level: "{config_source}:user_skill_level"
document_output_language: "{config_source}:document_output_language"
date: system-generated
implementation_artifacts: "{config_source}:implementation_artifacts"
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
sprint_status: "{implementation_artifacts}/sprint-status.yaml"
# Workflow components
installed_path: "{project-root}/_bmad/bmgd/workflows/4-production/code-review"

View File

@ -11,7 +11,7 @@ user_skill_level: "{config_source}:user_skill_level"
document_output_language: "{config_source}:document_output_language"
date: system-generated
implementation_artifacts: "{config_source}:implementation_artifacts"
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
sprint_status: "{implementation_artifacts}/sprint-status.yaml"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version

View File

@ -33,7 +33,7 @@ This is a COMPETITION to create the **ULTIMATE story context** that makes LLM de
### **When Running from Create-Story Workflow:**
- The `{project_root}/_bmad/core/tasks/validate-workflow.xml` framework will automatically:
- The `{project-root}/_bmad/core/tasks/validate-workflow.xml` framework will automatically:
- Load this checklist file
- Load the newly created story file (`{story_file_path}`)
- Load workflow variables from `{installed_path}/workflow.yaml`
@ -63,7 +63,7 @@ You will systematically re-do the entire story creation process, but with a crit
1. **Load the workflow configuration**: `{installed_path}/workflow.yaml` for variable inclusion
2. **Load the story file**: `{story_file_path}` (provided by user or discovered)
3. **Load validation framework**: `{project_root}/_bmad/core/tasks/validate-workflow.xml`
3. **Load validation framework**: `{project-root}/_bmad/core/tasks/validate-workflow.xml`
4. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
5. **Resolve all workflow variables**: story_dir, output_folder, epics_file, architecture_file, etc.
6. **Understand current status**: What story implementation guidance is currently provided?

View File

@ -19,7 +19,7 @@ validation: "{installed_path}/checklist.md"
# Variables and inputs
variables:
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml" # Primary source for story tracking
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {implementation_artifacts}/sprint-status.yaml" # Primary source for story tracking
epics_file: "{output_folder}/epics.md" # Preferred source for epic/story breakdown
prd_file: "{output_folder}/PRD.md" # Fallback for requirements
architecture_file: "{planning_artifacts}/architecture.md" # Optional architecture context

View File

@ -16,7 +16,7 @@ story_file: "" # Explicit story path; auto-discovered if empty
# Context file uses same story_key as story file (e.g., "1-2-user-authentication.context.xml")
context_file: "{story_dir}/{{story_key}}.context.xml"
implementation_artifacts: "{config_source}:implementation_artifacts"
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {implementation_artifacts}/sprint-status.yaml"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version

View File

@ -54,7 +54,7 @@ input_file_patterns:
load_strategy: "INDEX_GUIDED"
# Required files
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {implementation_artifacts}/sprint-status.yaml"
story_directory: "{implementation_artifacts}"
retrospectives_folder: "{implementation_artifacts}"

View File

@ -18,14 +18,14 @@ instructions: "{installed_path}/instructions.md"
# Inputs
variables:
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {implementation_artifacts}/sprint-status.yaml"
tracking_system: "file-system"
# Smart input file references
input_file_patterns:
sprint_status:
description: "Sprint status file generated by sprint-planning"
whole: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
whole: "{implementation_artifacts}/sprint-status.yaml || {implementation_artifacts}/sprint-status.yaml"
load_strategy: "FULL_LOAD"
# Standalone so IDE commands get generated

View File

@ -12,6 +12,8 @@
<critical>Read EVERY file in the File List - verify implementation against story requirements</critical>
<critical>Tasks marked complete but not done = CRITICAL finding</critical>
<critical>Acceptance Criteria not implemented = HIGH severity finding</critical>
<critical>Do not review files that are not part of the application's source code. Always exclude the _bmad/ and _bmad-output/ folders from the review. Always exclude IDE and CLI configuration folders like .cursor/ and .windsurf/ and .claude/</critical>
<step n="1" goal="Load story and discover changes">
<action>Use provided {{story_path}} or ask user which story file to review</action>

View File

@ -13,7 +13,7 @@ implementation_artifacts: "{config_source}:implementation_artifacts"
planning_artifacts: "{config_source}:planning_artifacts"
project_knowledge: "{config_source}:project_knowledge"
output_folder: "{implementation_artifacts}"
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
sprint_status: "{implementation_artifacts}/sprint-status.yaml"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version

View File

@ -33,7 +33,7 @@ This is a COMPETITION to create the **ULTIMATE story context** that makes LLM de
### **When Running from Create-Story Workflow:**
- The `{project_root}/_bmad/core/tasks/validate-workflow.xml` framework will automatically:
- The `{project-root}/_bmad/core/tasks/validate-workflow.xml` framework will automatically:
- Load this checklist file
- Load the newly created story file (`{story_file_path}`)
- Load workflow variables from `{installed_path}/workflow.yaml`
@ -63,7 +63,7 @@ You will systematically re-do the entire story creation process, but with a crit
1. **Load the workflow configuration**: `{installed_path}/workflow.yaml` for variable inclusion
2. **Load the story file**: `{story_file_path}` (provided by user or discovered)
3. **Load validation framework**: `{project_root}/_bmad/core/tasks/validate-workflow.xml`
3. **Load validation framework**: `{project-root}/_bmad/core/tasks/validate-workflow.xml`
4. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
5. **Resolve all workflow variables**: story_dir, output_folder, epics_file, architecture_file, etc.
6. **Understand current status**: What story implementation guidance is currently provided?

View File

@ -336,9 +336,10 @@
1. Review the comprehensive story in {{story_file}}
2. Run dev agents `dev-story` for optimized implementation
3. Run `code-review` when complete (auto-marks done)
4. Optional: Run TEA `*automate` after `dev-story` to generate guardrail tests
**The developer now has everything needed for flawless implementation!**
</output>
</step>
</workflow>
</workflow>

View File

@ -20,7 +20,7 @@ validation: "{installed_path}/checklist.md"
# Variables and inputs
variables:
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml" # Primary source for story tracking
sprint_status: "{implementation_artifacts}/sprint-status.yaml" # Primary source for story tracking
epics_file: "{planning_artifacts}/epics.md" # Enhanced epics+stories with BDD and source hints
prd_file: "{planning_artifacts}/prd.md" # Fallback for requirements (if not in epics file)
architecture_file: "{planning_artifacts}/architecture.md" # Fallback for constraints (if not in epics file)

View File

@ -397,6 +397,7 @@
- Verify all acceptance criteria are met
- Ensure deployment readiness if applicable
- Run `code-review` workflow for peer review
- Optional: Run TEA `*automate` to expand guardrail tests
</action>
<output>💡 **Tip:** For best results, run `code-review` using a **different** LLM than the one that implemented this story.</output>
@ -406,4 +407,4 @@
<action>Remain flexible - allow user to choose their own path or ask for other assistance</action>
</step>
</workflow>
</workflow>

View File

@ -19,7 +19,7 @@ instructions: "{installed_path}/instructions.md"
# Inputs
variables:
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml"
tracking_system: "file-system"
# Bug tracking integration (optional)
bugs_yaml: "{planning_artifacts}/bugs.yaml"
@ -29,7 +29,7 @@ variables:
input_file_patterns:
sprint_status:
description: "Sprint status file generated by sprint-planning"
whole: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
whole: "{implementation_artifacts}/sprint-status.yaml"
load_strategy: "FULL_LOAD"
# Standalone so IDE commands get generated

View File

@ -1,7 +1,7 @@
# Create Data Flow Diagram - Workflow Instructions
```xml
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow creates data flow diagrams (DFD) in Excalidraw format.</critical>

View File

@ -1,7 +1,7 @@
# Create Diagram - Workflow Instructions
```xml
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow creates system architecture diagrams, ERDs, UML diagrams, or general technical diagrams in Excalidraw format.</critical>

View File

@ -1,7 +1,7 @@
# Create Flowchart - Workflow Instructions
```xml
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow creates a flowchart visualization in Excalidraw format for processes, pipelines, or logic flows.</critical>

View File

@ -1,7 +1,7 @@
# Create Wireframe - Workflow Instructions
```xml
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow creates website or app wireframes in Excalidraw format.</critical>

View File

@ -25,11 +25,11 @@ The workflow auto-detects which mode to use based on project phase.
### Mode Detection
1. **Check for sprint-status.yaml**
- If `{output_folder}/bmm-sprint-status.yaml` exists → **Epic-Level Mode** (Phase 4)
- If `{implementation_artifacts}/sprint-status.yaml` exists → **Epic-Level Mode** (Phase 4)
- If NOT exists → Check workflow status
2. **Check workflow-status.yaml**
- Read `{output_folder}/bmm-workflow-status.yaml`
- Read `{planning_artifacts}/bmm-workflow-status.yaml`
- If `implementation-readiness: required` or `implementation-readiness: recommended`**System-Level Mode** (Phase 3)
- Otherwise → **Epic-Level Mode** (Phase 4 without sprint status yet)

View File

@ -197,7 +197,7 @@ Your choice:</ask>
<!-- ============================================= -->
<step n="10" goal="Validate mode - Check if calling workflow should proceed">
<action>Read {output_folder}/bmm-workflow-status.yaml if exists</action>
<action>Read {planning_artifacts}/bmm-workflow-status.yaml if exists</action>
<check if="status file not found">
<template-output>status_exists = false</template-output>
@ -261,7 +261,7 @@ Your choice:</ask>
</step>
<step n="20" goal="Data mode - Extract specific information">
<action>Read {output_folder}/bmm-workflow-status.yaml if exists</action>
<action>Read {planning_artifacts}/bmm-workflow-status.yaml if exists</action>
<check if="status file not found">
<template-output>status_exists = false</template-output>
@ -309,7 +309,7 @@ Your choice:</ask>
</step>
<step n="30" goal="Init-check mode - Simple existence check">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
<action>Check if {planning_artifacts}/bmm-workflow-status.yaml exists</action>
<check if="exists">
<template-output>status_exists = true</template-output>
@ -325,7 +325,7 @@ Your choice:</ask>
</step>
<step n="40" goal="Update mode - Centralized status file updates">
<action>Read {output_folder}/bmm-workflow-status.yaml</action>
<action>Read {planning_artifacts}/bmm-workflow-status.yaml</action>
<check if="status file not found">
<template-output>success = false</template-output>

View File

@ -1,7 +1,7 @@
# Design Thinking Workflow Instructions
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project_root}/_bmad/cis/workflows/design-thinking/workflow.yaml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/cis/workflows/design-thinking/workflow.yaml</critical>
<critical>Load and understand design methods from: {design_methods}</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>

View File

@ -1,7 +1,7 @@
# Innovation Strategy Workflow Instructions
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project_root}/_bmad/cis/workflows/innovation-strategy/workflow.yaml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/cis/workflows/innovation-strategy/workflow.yaml</critical>
<critical>Load and understand innovation frameworks from: {innovation_frameworks}</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>

View File

@ -1,7 +1,7 @@
# Problem Solving Workflow Instructions
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project_root}/_bmad/cis/workflows/problem-solving/workflow.yaml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/cis/workflows/problem-solving/workflow.yaml</critical>
<critical>Load and understand solving methods from: {solving_methods}</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>

View File

@ -3,8 +3,8 @@
## Workflow
<workflow>
<critical>The workflow execution engine is governed by: {project_root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project_root}/_bmad/cis/workflows/storytelling/workflow.yaml</critical>
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/_bmad/cis/workflows/storytelling/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language}</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>