fix(workflow): make workflow.xml format-agnostic with explicit lookup order

[alexeyv]

Summary

• Fix party-mode bug: reference workflow.md (actual file) not workflow.yaml
• Introduce {workflow_config_file} variable with explicit lookup order:
  • workflow.md (preferred) → workflow.yaml (legacy) → error if neither
• All subsequent references now use the clean variable pattern
• Supports transition period where both .yaml and .md formats coexist

Test plan

• Verify party-mode/workflow.md exists
• Verify grep counts match expected (2 for .yaml, 3 for .md)
• All lint/schema/format tests pass

🤖 Generated with Claude Code

[alexeyv]

@CodeRabbit review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request modifies the workflow configuration resolution logic in workflow.xml to dynamically determine which configuration file to use. It introduces a workflow_config_file variable that prefers workflow.md over workflow.yaml and raises an error if neither exists, with all subsequent references updated to use this resolved path.

Changes

Cohort / File(s)	Summary
Workflow Configuration File Resolution src/core/tasks/workflow.xml	Introduces dynamic workflow config file resolution preferring workflow.md over workflow.yaml. Replaces hardcoded workflow.yaml references with {workflow_config_file} variable throughout initialization, protocol, guidance, and template sections. Adds error handling if neither file exists.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related issues

• The workflow.xml task file contains an incorrect file extension reference for the party-mode workflow #1212: Directly addresses the party-mode workflow file-extension mismatch by introducing workflow.md preference and updating references from workflow.yaml to workflow.md.

Possibly related PRs

• fix(bmm): resolve dead references and syntax errors in agents and workflows #1164: Both PRs update workflow file references to use party-mode workflow.md path, replacing hardcoded workflow.yaml.
• refactor(bmm): convert quick-dev workflow to sharded format with adversarial review #1182: Both PRs modify workflow config handling by transitioning references from workflow.yaml to workflow.md through centralized variable resolution.

Suggested reviewers

• bmadcode

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: making workflow.xml format-agnostic by introducing an explicit lookup order for workflow config files.
Description check	✅ Passed	The description comprehensively explains the changes, including the bug fix, the new variable pattern, the lookup order logic, and the test plan—all directly related to the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@src/core/tasks/workflow.xml`:
- Around line 22-23: The "Locate workflow config file" action currently reads as
a global search; change it to only look within the directory of the provided
workflow path (or, if the provided path already names a file, honor that exact
filename) when resolving {workflow_config_file} — i.e., if the input is a
directory, check directory/workflow.md first, then directory/workflow.yaml; if
the input is a file, use that file directly; if neither exists, halt with an
error that clearly states the scoped path that was checked.
- Around line 142-146: The workflow docs and the Parse Input File Patterns step
are ambiguous about where input_file_patterns lives in markdown workflows;
update the workflow docs and parsing logic to state that input_file_patterns
must be placed in the YAML front-matter of .md files and show a short example
front-matter block (e.g., input_file_patterns: [ "src/**/*.py" ]) so the parser
reading {workflow_config_file} knows to extract the key from YAML front-matter
when the file extension is .md and from the top-level YAML when the file is
.yaml; adjust the code that implements "Parse Input File Patterns" to detect .md
files, strip the leading/front-matter section, parse it as YAML, and fall back
to parsing the whole file for .yaml files so the step n="1" action consistently
retrieves the input_file_patterns key.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Constrain lookup to the provided workflow directory.

The wording can be read as a global search, which risks resolving the wrong workflow when multiple workflows exist. Please clarify that the .md/.yaml lookup is scoped to the directory of the provided workflow path (or that an explicit filename should be honored).

🤖 Prompt for AI Agents

In `@src/core/tasks/workflow.xml` around lines 22 - 23, The "Locate workflow
config file" action currently reads as a global search; change it to only look
within the directory of the provided workflow path (or, if the provided path
already names a file, honor that exact filename) when resolving
{workflow_config_file} — i.e., if the input is a directory, check
directory/workflow.md first, then directory/workflow.yaml; if the input is a
file, use that file directly; if neither exists, halt with an error that clearly
states the scoped path that was checked.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, check if the file exists and view the relevant lines
echo "=== Viewing workflow.xml lines 142-146 ==="
if [ -f "src/core/tasks/workflow.xml" ]; then
  sed -n '140,150p' src/core/tasks/workflow.xml
else
  echo "File not found at src/core/tasks/workflow.xml"
fi

echo -e "\n=== Searching for input_file_patterns in workflow files ==="
# Search for input_file_patterns in markdown and yaml files
rg -n 'input_file_patterns' --glob '**/*.md' --glob '**/*.yaml' --glob '**/*.yml' 2>/dev/null | head -20

Repository: bmad-code-org/BMAD-METHOD

Length of output: 1280

---

🏁 Script executed:

#!/bin/bash
# Search for markdown parsing logic and workflow configuration handling
echo "=== Search for markdown parsing in workflow context ==="
rg -n 'markdown|\.md' src/core/tasks/ --glob '*.py' --glob '*.xml' 2>/dev/null | head -20

echo -e "\n=== Search for YAML front-matter or fenced block handling ==="
rg -n 'front.?matter|---' src/core/ --type xml --type py 2>/dev/null | head -20

Repository: bmad-code-org/BMAD-METHOD

Length of output: 3653

---

🏁 Script executed:

#!/bin/bash
# Look for any workflow examples or documentation
echo "=== Looking for workflow file examples ==="
find . -name '*workflow*' -type f | grep -E '\.(md|yaml|yml)$' | head -10

echo -e "\n=== Check for README or documentation about workflow files ==="
find . -name 'README*' -o -name '*WORKFLOW*' -o -name '*workflow*' | grep -E '\.(md|txt)$' | head -10

Repository: bmad-code-org/BMAD-METHOD

Length of output: 1145

---

🏁 Script executed:

#!/bin/bash
# Check actual workflow.md files for input_file_patterns
echo "=== Examining workflow.md files for input_file_patterns ==="
for file in $(find . -name 'workflow.md' -type f | head -5); do
  echo "--- File: $file ---"
  head -50 "$file"
  echo ""
done

Repository: bmad-code-org/BMAD-METHOD

Length of output: 11070

---

🏁 Script executed:

#!/bin/bash
# Search for code that parses workflow configuration (especially from markdown)
echo "=== Search for workflow parsing/loading code ==="
find src -type f \( -name '*.py' -o -name '*.js' -o -name '*.ts' \) | xargs rg -l 'workflow' 2>/dev/null | head -10

echo -e "\n=== Look for input_file_patterns parsing logic ==="
rg -n 'input_file_patterns' src/ --type py --type js --type ts 2>/dev/null | head -20

Repository: bmad-code-org/BMAD-METHOD

Length of output: 169

---

🏁 Script executed:

#!/bin/bash
# Check if workflow.md files have YAML front-matter or fenced blocks
echo "=== Check workflow.md files for YAML front-matter ==="
for file in $(find . -name 'workflow.md' -type f | head -3); do
  echo "--- File: $file ---"
  head -20 "$file" | cat -A
  echo ""
done

Repository: bmad-code-org/BMAD-METHOD

Length of output: 3090

---

Clarify how input_file_patterns is extracted from markdown workflow files.

Workflow files now prefer .md format with YAML front-matter, but all existing examples of input_file_patterns are in .yaml files only. Specify whether input_file_patterns belongs in the YAML front-matter section of .md files and provide an example, so the parser handling {workflow_config_file} can correctly extract it regardless of format.

🤖 Prompt for AI Agents

In `@src/core/tasks/workflow.xml` around lines 142 - 146, The workflow docs and
the Parse Input File Patterns step are ambiguous about where input_file_patterns
lives in markdown workflows; update the workflow docs and parsing logic to state
that input_file_patterns must be placed in the YAML front-matter of .md files
and show a short example front-matter block (e.g., input_file_patterns: [
"src/**/*.py" ]) so the parser reading {workflow_config_file} knows to extract
the key from YAML front-matter when the file extension is .md and from the
top-level YAML when the file is .yaml; adjust the code that implements "Parse
Input File Patterns" to detect .md files, strip the leading/front-matter
section, parse it as YAML, and fall back to parsing the whole file for .yaml
files so the step n="1" action consistently retrieves the input_file_patterns
key.

[bmadcode]

workflow.xml is meant to be deleted after all the yaml workflows are removed. This is not meant to be a runner for newer workflows that are all self contained.