fix(opencode): remove incorrect mode: primary and restore name field in templates#1644
Conversation
…in templates Remove hallucinated mode: primary from opencode-agent template - OpenCode defaults to mode: all and mode: primary does not enable Tab-switching as the original PR bmad-code-org#1556 claimed. Restore the name frontmatter field across all OpenCode templates to match the standard pattern used by other IDEs.
🤖 Augment PR SummarySummary: Removes the incorrect OpenCode frontmatter setting 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
📝 WalkthroughWalkthroughUpdates five OpenCode IDE template files by restoring the Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 6✅ Passed checks (6 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
tools/cli/installers/lib/ide/templates/combined/opencode-agent.md (2)
8-15:⚠️ Potential issue | 🟡 MinorMissing trailing "AGENT FILE:" reference line.
All four other templates (tool, task, workflow, workflow-yaml) include a trailing file reference line at the end (e.g., "TOOL FILE: {project-root}/{{bmadFolderName}}/{{path}}"), but this agent template omits it. This breaks the structural pattern established by the other templates. Either the pattern is valuable and should be applied here, or it's unnecessary and should be removed from the others.
Proposed addition for consistency
5. PRESENT the numbered menu 6. WAIT for user input before proceeding </agent-activation> + +AGENT FILE: {project-root}/{{bmadFolderName}}/{{path}}
8-8:⚠️ Potential issue | 🟡 MinorXML-style tag inconsistent with other template structures.
This template uses
<agent-activation CRITICAL="TRUE">as a structural wrapper, but the four other templates use plain text headers ("TOOL INSTRUCTIONS:", "TASK INSTRUCTIONS:", "WORKFLOW INSTRUCTIONS:"). This structural inconsistency makes the template set harder to maintain. Why does the agent template require XML-style markup while others don't?tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md (1)
12-15:⚠️ Potential issue | 🟡 MinorNo error handling instructions if workflow file is missing or malformed.
The instructions assume the workflow file exists and is readable at the specified path. If the file is missing, corrupted, or has an invalid path, there's no fallback guidance. This is especially concerning given the "CRITICAL" designation — what should happen if a critical workflow can't be loaded?
Consider adding a validation step or error handling instruction, e.g.:
- "If the workflow file cannot be loaded, report an error with the expected path and halt."
tools/cli/installers/lib/ide/templates/combined/opencode-tool.md (1)
8-13:⚠️ Potential issue | 🟡 MinorAdd step 4 and CRITICAL warning to match workflow template requirements.
The opencode-workflow.md and opencode-workflow-yaml.md templates both include step 4 ("DO NOT skip or modify any steps") and a "CRITICAL:" warning, but opencode-tool.md omits both. If step adherence is critical enough to warn about in workflows, tools should have the same safeguards. Add the missing step and warning for consistency.
Additionally, the file path appears redundantly on both line 10 (within step 1) and line 14 (TOOL FILE section) — consolidate to avoid duplication.
tools/cli/installers/lib/ide/templates/combined/opencode-workflow-yaml.md (1)
1-17:⚠️ Potential issue | 🟠 MajorRemove duplicate workflow template — identical md and yaml templates waste space and create confusion.
The
opencode-workflow-yaml.mdtemplate is byte-for-byte identical toopencode-workflow.md, despite the naming suggesting different handling for YAML workflows. The system's template loader in_config-driven.jsexplicitly supports different templates for YAML vs. Markdown workflows (lines 173–174), but the opencode templates provide no YAML-specific instructions or differences.Either consolidate into a single template or add YAML-specific handling (e.g., schema validation, YAML syntax guidance, or parsing instructions) to justify the separate file.
tools/cli/installers/lib/ide/templates/combined/opencode-task.md (1)
1-14:⚠️ Potential issue | 🟠 MajorConsider consolidating task/tool templates or document their semantic distinction.
Both templates are byte-for-byte identical except for word substitutions (task↔tool), and this pattern is systematic across all template families (
default-task/tool.md,kiro-task/tool.md,opencode-task/tool.md, etc.). While the code generator treats tasks and tools as distinct entity types with separate manifests and folder structures, the templates themselves reveal no functional difference in how they're executed.If tasks and tools are genuinely different in BMAD methodology, that distinction should be reflected in the templates. If they're not different, maintaining parallel identical files violates DRY and creates synchronization risk—any future updates (like instruction clarifications or verb standardization) must be applied to both files.
Options:
- Merge templates: Create a single template with a configurable label if semantic difference doesn't exist
- Document difference: If tasks and tools should have different instructions/context, update templates to reflect that
- Automate generation: Generate one from the other during build rather than maintaining both manually
🤖 Fix all issues with AI agents
In `@tools/cli/installers/lib/ide/templates/combined/opencode-tool.md`:
- Line 8: The template missing the severity marker should include the same
"CRITICAL: You must load and follow the workflow definition exactly" line used
by workflow templates to maintain consistency; update the opencode-tool.md
template by inserting that CRITICAL warning immediately above the "TOOL
INSTRUCTIONS:" section so the severity signal matches workflows and preserves
the expected formatting and placement.
In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md`:
- Line 8: The workflow template header contains a lone "CRITICAL: You must load
and follow the workflow definition exactly" statement which is inconsistent with
the tool/task templates; either make the designation consistent across template
types or document why workflows are special: either (A) add the same "CRITICAL"
header to the corresponding tool and task templates, or (B) remove/downgrade the
CRITICAL text from the workflow template and update its header to match the
other templates, or (C) keep the CRITICAL text but add a short explanatory note
in opencode-workflow.md describing the distinct failure modes and why workflows
require strict adherence; update the template header text and the documentation
in the same template file so all templates present a consistent policy.
- Line 2: The rendering in generateCommandContent() assumes workflow.name,
workflow.description, and workflow.path exist and can produce "undefined"/"null"
or TypeError; add defensive validation at the start of generateCommandContent():
verify that workflow.name and workflow.description and workflow.path are
non-empty strings (e.g., typeof === 'string' && .trim().length > 0), and if any
check fails throw a clear Error identifying the missing field and the offending
workflow, rather than continuing to substitute values; ensure any subsequent
substitutions use the validated values to avoid "undefined"/"null" appearing in
the YAML frontmatter.
🧹 Nitpick comments (4)
tools/cli/installers/lib/ide/templates/combined/opencode-tool.md (1)
10-14: Redundant file path specification.The file path
{project-root}/{{bmadFolderName}}/{{path}}appears twice: once in step 1 (line 10) and again in the trailing reference (line 14). This redundancy serves no clear purpose. If the trailing line is meant as a quick reference, it's undermined by being only 4 lines away from the first mention. If step 1 is sufficient, the trailing line is waste.tools/cli/installers/lib/ide/templates/combined/opencode-agent.md (1)
8-15: No empty line after opening tag, breaking formatting pattern.The other four templates include an empty line after their instruction headers (line 9 in tool.md, line 11 in workflow.md). This agent template has no empty line after
<agent-activation CRITICAL="TRUE">, breaking the spacing pattern. Consistent whitespace improves scannability.Proposed spacing adjustment
<agent-activation CRITICAL="TRUE"> + 1. LOAD the FULL agent file from {project-root}/{{bmadFolderName}}/{{path}}tools/cli/installers/lib/ide/templates/combined/opencode-workflow-yaml.md (1)
15-15: Self-referential instruction creates logical paradox.Step 4 says "DO NOT skip or modify any steps" — but if someone were going to skip steps, they'd skip step 4 too. This instruction assumes the reader is simultaneously following instructions (reading step 4) and not following instructions (about to skip steps). It's security theater that adds no enforcement value.
tools/cli/installers/lib/ide/templates/combined/opencode-task.md (1)
6-6: "Execute the BMAD" vs "LOAD" instruction verb inconsistency.The intro says "Execute the BMAD '{{name}}' task" but step 1 says "LOAD the task file". This creates ambiguity about what the template's action verb actually is. While the learning states "execute" in descriptive elements is intentionally left unchanged, having two different action verbs in the same 14-line template is still confusing for users who must mentally translate "execute" → "load".
|
|
||
| Execute the BMAD '{{name}}' tool. | ||
|
|
||
| TOOL INSTRUCTIONS: |
There was a problem hiding this comment.
Missing "CRITICAL:" warning found in workflow templates.
The workflow templates include "CRITICAL: You must load and follow the workflow definition exactly" before their instruction sections, but this tool template has no equivalent severity marker. Are tools inherently less critical than workflows? If so, why? If not, the inconsistency undermines the signal value of "CRITICAL" markers.
🤖 Prompt for AI Agents
In `@tools/cli/installers/lib/ide/templates/combined/opencode-tool.md` at line 8,
The template missing the severity marker should include the same "CRITICAL: You
must load and follow the workflow definition exactly" line used by workflow
templates to maintain consistency; update the opencode-tool.md template by
inserting that CRITICAL warning immediately above the "TOOL INSTRUCTIONS:"
section so the severity signal matches workflows and preserves the expected
formatting and placement.
| @@ -1,4 +1,5 @@ | |||
| --- | |||
| name: '{{name}}' | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -type f \( -name "*.ts" -o -name "*.js" \) | head -20Repository: bmad-code-org/BMAD-METHOD
Length of output: 887
🏁 Script executed:
# Search for template variable references
rg "{{name}}" -C 3Repository: bmad-code-org/BMAD-METHOD
Length of output: 152
🏁 Script executed:
# Search for bmadFolderName references
rg "bmadFolderName" -C 5Repository: bmad-code-org/BMAD-METHOD
Length of output: 50381
🏁 Script executed:
# Find the opencode-workflow file and related template files
fd "opencode-workflow" -type fRepository: bmad-code-org/BMAD-METHOD
Length of output: 239
🏁 Script executed:
# Search for template processing/rendering logic
rg "template|render|populate" --type=ts --type=js -i | head -30Repository: bmad-code-org/BMAD-METHOD
Length of output: 3606
🏁 Script executed:
cat -n tools/cli/installers/lib/ide/templates/combined/opencode-workflow.mdRepository: bmad-code-org/BMAD-METHOD
Length of output: 616
🏁 Script executed:
# Find what populates opencode-workflow.md and how
rg "opencode-workflow" -A 3 -B 3 --type=jsRepository: bmad-code-org/BMAD-METHOD
Length of output: 51
🏁 Script executed:
# Check if there's validation of workflow.name before template rendering
rg "workflow\.name" -A 2 -B 2 --type=js | head -40Repository: bmad-code-org/BMAD-METHOD
Length of output: 3823
🏁 Script executed:
# Find the actual template usage and rendering pipeline
fd "opencode" -type fRepository: bmad-code-org/BMAD-METHOD
Length of output: 239
🏁 Script executed:
# Find all opencode files
find tools/cli/installers/lib/ide/templates/combined -name "*opencode*" -type fRepository: bmad-code-org/BMAD-METHOD
Length of output: 407
🏁 Script executed:
# Search for where opencode-workflow template is used/referenced
rg "opencode" --type=js -B 3 -A 3Repository: bmad-code-org/BMAD-METHOD
Length of output: 51
🏁 Script executed:
# Check if name validation happens before template substitution
rg "workflow\.name" --type=js | head -50Repository: bmad-code-org/BMAD-METHOD
Length of output: 2044
🏁 Script executed:
# Look for where WorkflowCommandGenerator is instantiated and used
rg "WorkflowCommandGenerator" -A 10 -B 5 --type=jsRepository: bmad-code-org/BMAD-METHOD
Length of output: 15012
🏁 Script executed:
# Check the manifest generation logic more carefully
cat -n tools/cli/installers/lib/core/manifest-generator.js | sed -n '1,150p'Repository: bmad-code-org/BMAD-METHOD
Length of output: 6494
🏁 Script executed:
# Look at the exact validation logic in manifest generator
rg "workflow\.name.*workflow\.description" -A 5 -B 5 --type=jsRepository: bmad-code-org/BMAD-METHOD
Length of output: 2176
🏁 Script executed:
# Check if there's any null/undefined check before template rendering
rg "generateCommandContent|replaceAll" -A 2 -B 2 tools/cli/installers/lib/ide/shared/workflow-command-generator.jsRepository: bmad-code-org/BMAD-METHOD
Length of output: 1419
🏁 Script executed:
# See if workflow data could be incomplete or missing fields
rg "collectWorkflowArtifacts" -A 15 --type=js | head -60Repository: bmad-code-org/BMAD-METHOD
Length of output: 4748
🏁 Script executed:
# Check if there's any null/undefined checking before using workflow data in rendering
cat -n tools/cli/installers/lib/ide/shared/workflow-command-generator.js | sed -n '65,120p'Repository: bmad-code-org/BMAD-METHOD
Length of output: 2866
🏁 Script executed:
# Look at the full generateCommandContent method
cat -n tools/cli/installers/lib/ide/shared/workflow-command-generator.js | sed -n '110,160p'Repository: bmad-code-org/BMAD-METHOD
Length of output: 2163
🏁 Script executed:
# Verify the data flow - where does workflow object come from in collectWorkflowArtifacts
cat -n tools/cli/installers/lib/ide/shared/workflow-command-generator.js | sed -n '30,80p'Repository: bmad-code-org/BMAD-METHOD
Length of output: 2499
🏁 Script executed:
# Check the loadWorkflowManifest method to see what data structure is returned
cat -n tools/cli/installers/lib/ide/shared/workflow-command-generator.js | tail -100Repository: bmad-code-org/BMAD-METHOD
Length of output: 3970
🏁 Script executed:
# Check if there's any error handling when workflow data is missing
rg "loadWorkflowManifest" -A 20 --type=js | head -50Repository: bmad-code-org/BMAD-METHOD
Length of output: 5227
🏁 Script executed:
# Verify if workflow.path is guaranteed to exist in the manifest
rg "workflow\.path\|workflow\.name" tools/cli/installers/lib/core/manifest-generator.js | head -20Repository: bmad-code-org/BMAD-METHOD
Length of output: 51
🏁 Script executed:
# Check the actual manifest CSV structure to see what fields are required
fd "manifest" -type f | grep -E "\\.csv$|workflow"Repository: bmad-code-org/BMAD-METHOD
Length of output: 239
🏁 Script executed:
# Check the exact CSV structure that gets written to workflow-manifest.csv
cat -n tools/cli/installers/lib/core/manifest-generator.js | sed -n '240,320p'Repository: bmad-code-org/BMAD-METHOD
Length of output: 3434
🏁 Script executed:
# Look for the writeWorkflowManifest method to see CSV headers and data
rg "writeWorkflowManifest" -A 30 --type=js | head -80Repository: bmad-code-org/BMAD-METHOD
Length of output: 5506
🏁 Script executed:
# Check if there are any tests that verify the manifest generation
find . -name "*test*manifest*" -o -name "*manifest*test*" -type f 2>/dev/nullRepository: bmad-code-org/BMAD-METHOD
Length of output: 51
🏁 Script executed:
# Final verification: Check if there's any error handling or validation around template variable substitution
cat -n tools/cli/installers/lib/ide/shared/workflow-command-generator.js | sed -n '126,165p'Repository: bmad-code-org/BMAD-METHOD
Length of output: 1892
🏁 Script executed:
# Verify what happens if workflow.name is undefined - check if there's type coercion
rg "workflow\\.name.*=.*\|\.replaceAll" tools/cli/installers/lib/ide/shared/workflow-command-generator.js -B 2 -A 2Repository: bmad-code-org/BMAD-METHOD
Length of output: 51
🏁 Script executed:
# Check if there are any unit tests verifying template variable substitution
find test -name "*.js" -type f -exec grep -l "workflow.*name\|template.*variable" {} \;Repository: bmad-code-org/BMAD-METHOD
Length of output: 95
🏁 Script executed:
# Check if there are any tests for template rendering or manifest validation
cat -n test/test-file-refs-csv.js | head -50Repository: bmad-code-org/BMAD-METHOD
Length of output: 1734
🏁 Script executed:
# Final check: verify the actual data flow from manifest to template rendering
rg "collectWorkflowArtifacts|generateCommandContent" -B 5 -A 15 tools/cli/installers/lib/ide/shared/workflow-command-generator.js | head -80Repository: bmad-code-org/BMAD-METHOD
Length of output: 3030
Add defensive validation before template variable substitution.
While the manifest generation validates that workflows have name and description before writing to CSV, the rendering logic at line 156 lacks defensive checks. Line 128 also assumes workflow.path exists without null checking, which could throw a TypeError if the CSV becomes corrupted or fields are unexpectedly empty. Additionally, substituting undefined or null values would render as the string "undefined" or "null" instead of the intended values, breaking the YAML frontmatter.
Add validation in generateCommandContent():
- Check that
workflow.name,workflow.description, andworkflow.pathare non-empty strings before use - Throw a descriptive error if any required field is missing rather than silently rendering invalid content
🤖 Prompt for AI Agents
In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md` at line
2, The rendering in generateCommandContent() assumes workflow.name,
workflow.description, and workflow.path exist and can produce "undefined"/"null"
or TypeError; add defensive validation at the start of generateCommandContent():
verify that workflow.name and workflow.description and workflow.path are
non-empty strings (e.g., typeof === 'string' && .trim().length > 0), and if any
check fails throw a clear Error identifying the missing field and the offending
workflow, rather than continuing to substitute values; ensure any subsequent
substitutions use the validated values to avoid "undefined"/"null" appearing in
the YAML frontmatter.
| @@ -7,6 +8,7 @@ Execute the BMAD '{{name}}' workflow. | |||
| CRITICAL: You must load and follow the workflow definition exactly. | |||
There was a problem hiding this comment.
"CRITICAL:" designation applied inconsistently across template types.
This template marks workflows as "CRITICAL: You must load and follow the workflow definition exactly," but the tool and task templates have no equivalent warning. This implies workflows are critical while tools and tasks are not — but no justification is provided. If this is based on different failure modes, document it. If not, either promote all to CRITICAL or demote workflows to match.
🤖 Prompt for AI Agents
In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md` at line
8, The workflow template header contains a lone "CRITICAL: You must load and
follow the workflow definition exactly" statement which is inconsistent with the
tool/task templates; either make the designation consistent across template
types or document why workflows are special: either (A) add the same "CRITICAL"
header to the corresponding tool and task templates, or (B) remove/downgrade the
CRITICAL text from the workflow template and update its header to match the
other templates, or (C) keep the CRITICAL text but add a short explanatory note
in opencode-workflow.md describing the distinct failure modes and why workflows
require strict adherence; update the template header text and the documentation
in the same template file so all templates present a consistent policy.
2 participants
What
Remove incorrect
mode: primaryfrom the OpenCode agent template and restore thenamefrontmatter field across all OpenCode templates.Why
PR #1556 added
mode: primarybased on a misunderstanding of what this field does in OpenCode. This restricts BMAD agents to primary-only use, preventing them from being invoked as subagents via the@syntax. OpenCode defaults tomode: all, which is the correct behavior.Fixes #1643
How
mode: primarywithname: '{{name}}'inopencode-agent.mdname: '{{name}}'field toopencode-task.md,opencode-tool.md,opencode-workflow.md, andopencode-workflow-yaml.mdTesting
All pre-commit checks pass (schemas, refs, install, lint, format).