Configurable interaction_style setting for better UX#1788
Configurable interaction_style setting for better UX#1788sidtheone wants to merge 2 commits intobmad-code-org:mainfrom
interaction_style setting for better UX#1788Conversation
|
Fix for Add configurable structured interaction style for agent question-asking behavior #1787 |
|
@coderabbitai review |
📝 WalkthroughWalkthroughAdds a top-level Changes
Notes: The RULE insertions are consistent across many template files; several templates also include minor path placeholder changes and a few new preflight/validation lines referencing Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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: 12
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md (1)
12-12:⚠️ Potential issue | 🟡 MinorTemplate variable
{{bmadFolderName}}will not be replaced at runtime.Lines 12-13 reference
{{bmadFolderName}}but the generator code only replaces_bmad. Other templates correctly use_bmad(e.g., workflow-command-template.md). The variable replacement logic in agent-command-generator.js and workflow-command-generator.js handles_bmad, not{{bmadFolderName}}, causing these file references to remain unresolved.Use
_bmadinstead of{{bmadFolderName}}to match the actual variable replacement implementation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md` at line 12, In the kiro-workflow-yaml.md template replace the unresolved template variable `{{bmadFolderName}}` with the actual generator variable `_bmad` used by agent-command-generator.js and workflow-command-generator.js; locate the reference to the workflow XML path (currently using `{{bmadFolderName}}/core/tasks/workflow.xml`) and change it to use `_bmad` so the file path is correctly substituted at runtime.
🟡 Minor comments (11)
tools/cli/installers/lib/ide/templates/combined/default-task.md-11-12 (1)
11-12:⚠️ Potential issue | 🟡 MinorRULE placement inconsistent with default-workflow-yaml.md.
In
default-workflow-yaml.md, the RULE is placed before the execution steps. Here, it's placed after the "Follow all instructions" directive. This inconsistency within the same template family (default-*) is confusing.If the agent follows instructions "exactly as written" in the task file, it may complete execution before encountering this RULE. Standardize placement across all templates - preferably before execution directives.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/default-task.md` around lines 11 - 12, Move the RULE line "RULE: When interaction_style is "structured", EVERY question to the user MUST call the AskUserQuestion tool. Do NOT write questions as plain text. No exceptions." so it appears before the execution steps and before the "Follow all instructions" directive to match placement in default-workflow-yaml.md; update the combined/default-task.md template so the RULE is standardized at the top of the execution block (i.e., prior to any "Follow all instructions" or step list), ensuring the agent will see and enforce the structured-interaction requirement before running steps.tools/cli/installers/lib/ide/templates/combined/rovodev.md-10-11 (1)
10-11:⚠️ Potential issue | 🟡 MinorRULE placement after primary instruction may be overlooked.
The RULE appears after "Follow all instructions in the workflow file exactly as written." AI agents following sequential instructions might execute the workflow file before reaching this rule, potentially missing it entirely. Consider placing the RULE before the workflow file reference or as part of the initial instructions block.
Additionally, "structured options with a numbered list" is less specific than other templates that name explicit tools. Should there be example formatting to ensure consistency?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/rovodev.md` around lines 10 - 11, Move the RULE line "RULE: When interaction_style is \"structured\", EVERY question to the user MUST use structured options with a numbered list. No exceptions." so it appears before the sentence "Follow all instructions in the workflow file exactly as written." or incorporate it into the initial instruction block; update the template text around the workflow file reference to explicitly call out this RULE up front. Also add a short example single-line format for "structured options" (e.g., "1) Option A\n2) Option B\n3) Option C") directly after the RULE to remove ambiguity and ensure every structured question uses a numbered list format.tools/cli/installers/lib/ide/templates/combined/opencode-task.md-13-14 (1)
13-14:⚠️ Potential issue | 🟡 Minor"question tool" should use consistent naming across templates and style.
The
interaction_stylevariable is properly loaded via activation-steps.txt as a session variable during initialization (documented in src/core/module.yaml and activation-steps.txt), so no context is missing there.However, tool naming is inconsistent across templates: opencode family uses "question tool", default family uses "AskUserQuestion tool", gemini family uses "ask_user tool", and others use "structured options with a numbered list". Either standardize to one naming convention across all templates or document which tool applies to which context.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/opencode-task.md` around lines 13 - 14, Template tool naming is inconsistent (opencode uses "question tool", default uses "AskUserQuestion tool", gemini uses "ask_user tool") while interaction_style is set via activation-steps.txt and src/core/module.yaml; standardize all templates to a single tool name (pick one, e.g., "AskUserQuestion tool") by updating the opencode templates (e.g., combined/opencode-task.md and other opencode family templates), the default family templates, and the gemini family templates to call the chosen tool name consistently wherever questions are invoked, and update the documentation (activation-steps.txt or module.yaml docs) to reflect the canonical tool name or alternatively add a clear mapping table in the docs if multiple names must be supported; ensure all templates follow the RULE for interaction_style "structured" to call that unified tool rather than embedding plain-text questions.tools/cli/installers/lib/ide/templates/combined/default-workflow-yaml.md-6-7 (1)
6-7:⚠️ Potential issue | 🟡 MinorFormat
AskUserQuestionas code.The "default" template is intentionally used by multiple IDEs including Claude Code as a universal fallback (per platform-codes.yaml). However,
AskUserQuestionon line 6 should use backticks or be quoted for clarity: "theAskUserQuestiontool" or "the 'AskUserQuestion' tool" to distinguish it as a tool name rather than plain text instruction.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/default-workflow-yaml.md` around lines 6 - 7, Update the template text so the tool name AskUserQuestion is formatted as code or quoted (e.g., `AskUserQuestion` or "AskUserQuestion") instead of plain text; specifically edit the line referencing AskUserQuestion and ensure it appears clearly as the tool name in the context where interaction_style is "structured" to avoid ambiguity when readers scan the default-workflow-yaml template.tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md-15-15 (1)
15-15:⚠️ Potential issue | 🟡 MinorInconsistent instruction: Missing numbered list guidance.
This RULE only mandates calling the
questiontool but doesn't specify that options must be presented as a numbered list. Compare toantigravity.mdwhich says "MUST use structured options with a numbered list."The tool call alone doesn't guarantee structured options are presented. Should this also require numbered options within the tool invocation?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md` at line 15, The RULE about interaction_style="structured" currently mandates calling the question tool but omits requiring numbered options; update the rule text for "RULE: When interaction_style is \"structured\"" to require that every question invoked via the question tool also presents structured options as a numbered list (consistent with antigravity.md). Ensure the wording explicitly references interaction_style, the question tool, and "numbered list" so readers must include structured numbered options in the tool invocation.src/utility/agent-components/activation-steps.txt-4-4 (1)
4-4:⚠️ Potential issue | 🟡 MinorMissing
{document_output_language}in session variables.The
module.yamldefines five configuration fields, but only four are loaded here. Thedocument_output_languagefield (lines 17-20 in module.yaml) is omitted from the session variable list. If any template or agent references{document_output_language}, it will be undefined.Proposed fix
- - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}, {interaction_style} + - Store ALL fields as session variables: {user_name}, {communication_language}, {document_output_language}, {output_folder}, {interaction_style}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/utility/agent-components/activation-steps.txt` at line 4, The session variable list in activation-steps (the step that stores session vars {user_name}, {communication_language}, {output_folder}, {interaction_style}) is missing {document_output_language}; update that activation step to store the fifth config field by adding {document_output_language} to the stored session variables so templates/agents referencing {document_output_language} have a defined value (ensure the key name matches the module configuration exactly: document_output_language).tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md-7-8 (1)
7-8:⚠️ Potential issue | 🟡 MinorInconsistency between fallback templates: extra constraint present here but missing in windsurf-workflow.md.
This template includes "Do NOT ask open-ended inline questions" but
windsurf-workflow.mdomits this phrase entirely (it only says "MUST use structured options with a numbered list. No exceptions.").If this constraint is important for Kiro, why not for Windsurf? Either:
- Add the phrase to windsurf-workflow.md for consistency, or
- Document why Kiro needs stricter guidance than Windsurf
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md` around lines 7 - 8, The kiro-workflow template includes an extra strict constraint ("Do NOT ask open-ended inline questions") that is missing from windsurf-workflow.md; to resolve, either add the exact phrase to the windsurf-workflow.md fallback rule so both templates read "When interaction_style is 'structured', EVERY question to the user MUST use structured options with a numbered list. Do NOT ask open-ended inline questions. No exceptions." or, if the stricter behavior is intentional for Kiro only, add a brief comment in kiro-workflow-yaml.md explaining why Kiro requires prohibiting open-ended inline questions and reference that divergence in windsurf-workflow.md so the difference is documented and intentional.tools/cli/installers/lib/ide/templates/combined/opencode-agent.md-8-9 (1)
8-9:⚠️ Potential issue | 🟡 MinorNo fallback specified for "open" mode or missing/invalid configuration.
The RULE only specifies behavior when
interaction_styleis "structured". What should the agent do when:
interaction_styleis "open"?interaction_styleis undefined or not set?interaction_stylehas an invalid value?Without explicit guidance, agents may behave inconsistently across these scenarios.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/opencode-agent.md` around lines 8 - 9, The template currently only defines behavior for interaction_style == "structured" and lacks fallbacks; update the opencode-agent.md template to explicitly handle other cases by: (1) defining a default behavior when interaction_style is missing/undefined (e.g., default to "open" with free-text questions) and documenting it in the RULE section, (2) specifying that when interaction_style == "open" the agent must NOT call the question tool and may ask plain-text questions, and (3) adding validation guidance for invalid values (reject unknown values or fall back to the default and log/warn); reference the RULE and the interaction_style field in the text so implementers of the agent will enforce these cases consistently.tools/cli/installers/lib/ide/templates/workflow-commander.md-7-7 (1)
7-7:⚠️ Potential issue | 🟡 MinorAlign path notation with other workflow templates.
@{{workflow_path}}should use the full path pattern like other templates. Compare againstwindsurf-workflow.md({project-root}/_bmad/{{workflow_path}}),gemini-workflow.toml({project-root}/{{bmadFolderName}}/{{workflow_path}}), anddefault-workflow.md(@{project-root}/{{bmadFolderName}}/{{path}}). The bare variable reference appears inconsistent with how all other workflow templates construct file paths. Update to match the established pattern for consistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/workflow-commander.md` at line 7, The template uses a bare @{{workflow_path}} which is inconsistent with other workflow templates; update the path notation to the full pattern used elsewhere (for example use @{project-root}/{{bmadFolderName}}/{{workflow_path}}) so the line becomes "LOAD the FULL @{project-root}/{{bmadFolderName}}/{{workflow_path}}, READ its entire contents..." and adjust any other occurrences in workflow-commander.md to match this established pattern (use the @{project-root}/{{bmadFolderName}}/{{workflow_path}} form rather than the bare variable).tools/cli/installers/lib/ide/templates/combined/kiro-agent.md-9-9 (1)
9-9:⚠️ Potential issue | 🟡 Minor
structured optionsis underspecified and likely to produce inconsistent behaviorLine 9 doesn’t define whether multiple selections are allowed, whether an “Other” option is mandatory, or how free-text follow-up is captured. Add a minimal response contract so implementations don’t diverge per IDE.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-agent.md` at line 9, The "structured options" rule at RULE: When interaction_style is "structured" is underspecified — update the contract near that RULE to define minimal required fields: specify whether multiple selections are allowed (e.g., allow_multiple: true|false), whether an "Other" choice is required (include_other: true|false) and its label (other_label), and how free-text follow-ups are returned (e.g., followup_field: "other_text" and followup_required: true|false); reference the interaction_style "structured" rule and the RULE identifier so implementers must implement these keys and semantics for every structured question to ensure consistent behavior across IDEs.tools/cli/installers/lib/ide/templates/combined/kiro-workflow.md-7-7 (1)
7-7:⚠️ Potential issue | 🟡 MinorBehavior is undefined when
interaction_styleis missingLine 7 depends on
interaction_stylebut this template doesn’t define a fallback. For existing installs/configs missing the key, agent behavior becomes ambiguous. Add defaulting guidance (openorstructured) inline.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow.md` at line 7, The template uses the interaction_style key but provides no default; update the combined/kiro-workflow.md template to explicitly document and enforce a fallback for interaction_style (either "open" or "structured") so behavior is well-defined for installs missing the key—add a short sentence near the RULE paragraph referencing interaction_style that states the default value and how it affects question formatting (e.g., default to "open" unless explicitly set to "structured" which then mandates numbered options), and ensure any conditional text that currently assumes interaction_style checks this documented default when deciding whether to use structured options.
🧹 Nitpick comments (13)
tools/cli/installers/lib/ide/templates/combined/trae.md (1)
10-11: Identical to rovodev.md - confirms need for shared template partial.This RULE is character-for-character identical to
rovodev.md. Same placement concern applies. Five IDEs (Kiro, Windsurf, Trae, Antigravity, RovoDev) reportedly use this fallback pattern. Duplicating identical text across all five is maintenance overhead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/trae.md` around lines 10 - 11, The RULE line "When interaction_style is "structured", EVERY question to the user MUST use structured options with a numbered list. No exceptions." is duplicated across multiple templates (including the Trae template shown and rovodev.md); extract this sentence into a shared template partial (e.g., a reusable "structured-interaction-rule" partial) and replace the duplicated line in templates Trae, Kiro, Windsurf, Antigravity and RovoDev with an include/reference to that partial so the text is maintained in one place and placement/formatting stays identical.tools/cli/installers/lib/ide/templates/combined/opencode-tool.md (1)
13-14: Same ambiguity as opencode-task.md - consider DRY principle.This RULE is identical to
opencode-task.md. Same issue with vague "question tool" reference.With 27 templates reportedly modified, have you considered extracting this RULE text into a shared partial or include? Maintaining identical text across 27 files is error-prone. A typo fix or tool name change would require updating all 27 files.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/opencode-tool.md` around lines 13 - 14, The RULE text "RULE: When interaction_style is "structured", EVERY question to the user MUST call the question tool. Do NOT write questions as plain text. No exceptions." is duplicated across templates (e.g., opencode-tool.md and opencode-task.md) and should be factored into a single shared partial; create a shared include (e.g., a common RULE partial named something like structured-question-rule) and replace the inline RULE in all affected templates (the ~27 modified files) with a reference/include to that partial, ensuring the partial contains the exact canonical wording and updating any template rendering logic to pull that partial so future edits happen in one place.tools/cli/installers/lib/ide/templates/combined/gemini-agent.toml (2)
6-8: Pre-flight checklist doesn't verifyinteraction_styleis loaded.The checklist verifies
{user_name}(line 8) but doesn't confirminteraction_stylewas successfully loaded from config. Given the RULE depends on this value, consider adding a verification step:4. [ ] CONFIRM: interaction_style is set to "{interaction_style}".🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-agent.toml` around lines 6 - 8, Add a checklist verification that confirms the interaction_style value was loaded from the agent config (config.yaml) and stored in memory; specifically update the pre-flight checklist (the lines that check {user_name}) to include a step such as "CONFIRM: interaction_style is set to \"{interaction_style}\"" so the RULE that depends on interaction_style can rely on it being present and correct when the agent reads the internalized agent definition at {project-root}/{{bmadFolderName}}/{{path}}.
10-11: Correct tool name, but inconsistent RULE wording across templates.This RULE correctly specifies
ask_userfor Gemini. However, the wording differs from other templates:
Template Wording gemini-agent.toml "Do NOT write questions as plain text" antigravity.md "structured options with a numbered list" agent-command-template.md "Do NOT ask open-ended inline questions" These have different semantic implications. "Plain text" vs "open-ended" vs "not numbered" could be interpreted differently by AI agents. Consider standardizing the wording across all templates.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-agent.toml` around lines 10 - 11, Update the RULE text in the gemini-agent.toml template so its phrasing matches the canonical wording used in other templates: replace the current "Do NOT write questions as plain text" line in the RULE that begins with `When interaction_style is "structured", EVERY question to the user MUST call the ask_user tool` with the standardized phrasing used elsewhere (e.g., explicitly require calling ask_user for every question, forbid open-ended/plain-text inline questions, and require structured options as a numbered list) so the rule semantics match the `antigravity.md`/`agent-command-template.md` intent.tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md (1)
5-5: Verb inconsistency: "Execute" should be "Load and follow" per BMAD standards.Based on learnings, action instructions in BMAD-METHOD should use "load and follow" or "read and follow" instead of "execute." Line 5 says "Execute the BMAD '{{name}}' workflow" which contradicts the standardization effort from issue
#1378and PR#1387/#1570.Proposed fix
-Execute the BMAD '{{name}}' workflow. +Load and follow the BMAD '{{name}}' workflow.Based on learnings: "In BMAD-METHOD, when standardizing verbs like 'execute', 'invoke', 'run' per issue
#1378and PR#1387/#1570, only action instructions are replaced with 'load and follow' or 'read and follow'."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md` at line 5, Replace the verb "Execute" with the standardized BMAD action phrasing "Load and follow" in the template line that currently reads "Execute the BMAD '{{name}}' workflow" so it conforms to BMAD-METHOD conventions (per issue `#1378` / PRs `#1387/`#1570); update the string containing '{{name}}' to "Load and follow the BMAD '{{name}}' workflow" ensuring no other surrounding wording is changed.tools/cli/installers/lib/ide/templates/combined/default-tool.md (1)
11-12: Confusing naming: "default-tool" uses Claude-specificAskUserQuestion.The filename
default-tool.mdimplies this is a fallback/default template, yet it referencesAskUserQuestionwhich is Claude Code-specific. This creates confusion about which IDEs should use this template.Either:
- Rename to
claude-tool.mdto clarify its purpose, or- Use the numbered list fallback if this is truly meant as a default
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/default-tool.md` around lines 11 - 12, The template file default-tool.md contradicts its “default” name by referencing the Claude-specific AskUserQuestion tool and requiring interaction_style "structured"; either rename the file to claude-tool.md to make its Claude-specific intent explicit (update any references to default-tool.md) or modify the template to use the generic numbered-list fallback (remove AskUserQuestion usages and ensure questions are plain numbered list entries when interaction_style is not Claude-specific). Locate occurrences of AskUserQuestion and interaction_style "structured" in default-tool.md and apply one of these two fixes so the template name matches its behavior.src/core/module.yaml (1)
29-29: Consider adding input validation for theinteraction_stylevalue.While
single-selectconstrains the UI options, if a user manually edits theirconfig.yamland introduces a typo (e.g.,"strucutred"), the RULE conditions in templates won't match, and the agent will silently fall back to unstructured behavior. This defeats the purpose of the feature.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/core/module.yaml` at line 29, The interaction_style default in module.yaml can be corrupted by manual edits (e.g., "strucutred"), causing RULE-based templates to silently misbehave; add explicit validation when loading config.yaml: in the configuration loader that reads interaction_style (look for the codepath that parses interaction_style / module.yaml), validate the value against an allowed set (e.g., "structured", "single-select", "unstructured"), and if invalid either throw a clear error or log a warning and fall back to a safe default, ensuring templates/RULE checks see only validated values.tools/cli/installers/lib/ide/templates/combined/windsurf-workflow.md (1)
11-12: Wording inconsistency with tool-based templates may cause behavioral drift.This template says "MUST use structured options with a numbered list" while tool-based templates (default-agent.md, gemini-*.toml) say "Do NOT write questions as plain text." These instructions could be interpreted differently:
- "Numbered list" implies a specific format (1. Option A, 2. Option B...)
- "Not plain text" could mean any structured format
Consider standardizing the wording across all templates to ensure consistent agent behavior, perhaps: "MUST present options as a numbered list (e.g., 1. Option A, 2. Option B). Do NOT write questions as plain prose."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/windsurf-workflow.md` around lines 11 - 12, Update the RULE line that currently reads 'RULE: When interaction_style is "structured", EVERY question to the user MUST use structured options with a numbered list. No exceptions.' to match the wording used in tool-based templates by explicitly requiring a numbered-list format and forbidding prose questions; e.g., replace it with a unified sentence such as: 'When interaction_style is "structured", EVERY question MUST present options as a numbered list (e.g., 1. Option A, 2. Option B) and must NOT be written as plain prose.' Ensure you update the occurrence of interaction_style and the RULE heading in windsuf-workflow.md so it aligns with default-agent.md and gemini-*.toml conventions.tools/cli/installers/lib/ide/templates/combined/gemini-tool.toml (1)
9-9: RULE embedded as numbered step breaks instruction semantics.Steps 1-3 are sequential actions (LOAD, READ, FOLLOW). Step 4 is a conditional rule, not an action. Embedding "4. RULE:" in the numbered list creates ambiguous semantics - is this step 4 to execute after step 3, or a governing constraint that applies throughout?
Consider restructuring to separate the RULE from the numbered steps:
Proposed restructure
TOOL INSTRUCTIONS: 1. LOAD the tool file from {project-root}/{{bmadFolderName}}/{{path}} 2. READ its entire contents 3. FOLLOW every instruction precisely as specified -4. RULE: When interaction_style is "structured", EVERY question to the user MUST call the ask_user tool. Do NOT write questions as plain text. No exceptions. + +RULE: When interaction_style is "structured", EVERY question to the user MUST call the ask_user tool. Do NOT write questions as plain text. No exceptions. TOOL FILE: {project-root}/{{bmadFolderName}}/{{path}}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-tool.toml` at line 9, The numbered list mixes sequential actions with a conditional constraint—specifically the line "4. RULE: When interaction_style is "structured", EVERY question to the user MUST call the ask_user tool."—so extract that rule out of the step sequence and place it as a separate unnumbered RULES or NOTES section (or prepend "RULE:" above/below the numbered steps) so steps 1-3 remain purely sequential (LOAD, READ, FOLLOW) and the constraint is clearly a global/conditional policy that applies at all times rather than an executable step; update the template in gemini-tool.toml to remove the "4." prefix and ensure the rule text references interaction_style and ask_user exactly as written.tools/cli/installers/lib/ide/templates/workflow-commander.md (1)
5-6: Inconsistent terminology: "open-ended inline questions" vs other templates.This template adds "Do NOT ask open-ended inline questions" which doesn't appear in other fallback templates (windsurf-workflow.md, kiro-workflow-yaml.md). The additional phrase could be interpreted as:
- Redundant clarification of "structured options"
- A separate constraint (no inline questions even if structured)
Either standardize across all fallback templates or document why this template needs different wording.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/workflow-commander.md` around lines 5 - 6, The RULE line in workflow-commander.md contains an extra phrase "Do NOT ask open-ended inline questions" that is inconsistent with windsuf-workflow.md and kiro-workflow-yaml.md; either remove that phrase from workflow-commander.md to match the other fallback templates or add the same explicit prohibition to the other templates and a short clarifying note that explains whether "no inline questions" is a separate constraint vs part of "structured options." Update the RULE text (interaction_style "structured") and the templates (workflow-commander.md, windsurf-workflow.md, kiro-workflow-yaml.md) so the wording is identical and, if the prohibition is intended, add a brief doc sentence clarifying its scope and examples.tools/cli/installers/lib/ide/templates/combined/kiro-task.md (1)
11-11: Clarification turns are not accounted forIf the user responds with a clarifying question instead of an option number, this rule gives no recovery path. Add a short loop rule: answer clarification, then re-issue the structured prompt.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-task.md` at line 11, Update the RULE block that begins with "RULE: When interaction_style is \"structured\", EVERY question to the user MUST use structured options with a numbered list. No exceptions." to include a recovery loop for clarification turns: add a short sentence (or a new sub-rule) stating that if the user replies with a clarifying question instead of an option number, the agent must first answer the clarification briefly and then immediately re-issue the same structured prompt with the numbered options; reference the original RULE text so reviewers can find and apply this change in the kiro-task.md template.tools/cli/installers/lib/ide/templates/combined/kiro-tool.md (2)
11-11: Policy text is duplicated and will drift across templatesThis rule is copy-pasted across multiple template files with slightly different wording. Move it to a shared include/token and reference it here to prevent cross-template divergence.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-tool.md` at line 11, The duplicated policy line 'RULE: When interaction_style is "structured", EVERY question to the user MUST use structured options with a numbered list. No exceptions.' in the kiro-tool.md template should be moved into a single shared include/token (e.g., a new template fragment named something like "interaction-style-rule") and replaced here with a reference to that include; update kiro-tool.md to remove the copied policy text and insert the include reference so all templates pull the rule from one source, and add/update tests or documentation that assert the shared include exists and is used by templates referencing the rule.
11-11: Missing invalid-response handling will cause brittle interactionsLine 11 defines question format but not what to do when users reply with non-numeric/free text. Add a mandatory reprompt/normalize rule (e.g., retry with allowed choices, then escalate to open input).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-tool.md` at line 11, The template rule for interaction_style "structured" currently mandates numbered-choice questions but lacks handling for invalid responses; update the combined/kiro-tool.md question schema (look for the interaction_style key and the RULE line) to include a mandatory invalid-response policy: add a reprompt/normalize field that retries up to N times (showing allowed numeric choices), validates numeric/option input, and if still invalid escalates to open/free-text input or a fallback message; ensure the policy metadata is present for every question using structured options so consumers like the renderer/ask_user function can enforce retries and normalization consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@tools/cli/installers/lib/ide/templates/agent-command-template.md`:
- Around line 8-9: This template is inconsistent with the Claude Code
conventions: when interaction_style is "structured" it must use AskUserQuestion
rather than a plain numbered list; update
tools/cli/installers/lib/ide/templates/agent-command-template.md to replace the
numbered-list question format with the AskUserQuestion structured option syntax
so it matches workflow-command-template.md and default-tool.md (use the same
AskUserQuestion fields/keys those files use), or if this file is meant as a
fallback, make that explicit by renaming/moving the template or adding a clear
fallback marker in its metadata so its different format is obvious.
In `@tools/cli/installers/lib/ide/templates/combined/default-agent.md`:
- Line 11: Replace the hardcoded `_bmad` segment in the "LOAD the FULL agent
file" line with the dynamic placeholder used elsewhere so the template follows
the same convention; update the string "LOAD the FULL agent file from
{project-root}/_bmad/{{path}}" to use
"{project-root}/{{bmadFolderName}}/{{path}}" (keep the existing {{path}} token)
so templates like combined/default-agent.md match opencode-agent.md and
gemini-tool.toml behavior.
- Around line 8-9: The default-agent.md currently enforces a Claude-specific
AskUserQuestion rule that will break IDEs whose template_type (e.g., windsurf,
trae, antigravity, cline) lack corresponding agent templates, so either add
missing custom agent templates named <template_type>-agent.md for windsurf,
trae, antigravity (and ensure cline resolves to windsurf if intended) or change
default-agent.md to a universal fallback that does not reference AskUserQuestion
(replace the rule with a neutral instruction like "use the IDE's native ask tool
or mapping" and document mapping keys such as ask_user, question, or
numbered-list for each IDE); update the template resolution code paths that load
default-agent.md to ensure it picks custom <template_type>-agent.md when
present.
In `@tools/cli/installers/lib/ide/templates/combined/gemini-workflow-yaml.toml`:
- Line 14: The embedded RULE currently listed as step 5 after the sequential
steps LOAD/PARSE/EXECUTE/VALIDATE is structurally wrong; edit the template in
combined/gemini-workflow-yaml.toml to remove the RULE line from the numbered
steps (the line beginning with "5. RULE:" that references interaction_style
"structured") and instead add it as an unnumbered standalone directive placed
either immediately before or after the numbered list, preserving its exact
wording and scope so it reads as a cross-cutting constraint rather than a
sequential step.
In `@tools/cli/installers/lib/ide/templates/combined/gemini-workflow.toml`:
- Line 12: The RULE line is a constraint, not a step; convert it into a proper
step entry (e.g., a step with id/name like "enforce_interaction_style" or a
"CONSTRAINT" step) so it sits alongside the existing steps (LOAD, READ, FOLLOW,
DO NOT skip) and references interaction_style == "structured" and the
requirement to call ask_user for every user question; also remove the redundant
phrase "No exceptions" since "EVERY" and "MUST" already enforce it. Ensure the
new step text explicitly mentions calling the ask_user tool when
interaction_style is "structured" and fits the same step-formating used by the
other steps.
In `@tools/cli/installers/lib/ide/templates/combined/kiro-agent.md`:
- Line 9: The rule forbids open-ended questions when interaction_style ==
"structured", which can conflict with workflows that explicitly require open
elicitation; update the rule text to add a clear precedence exception: change
the RULE to require structured numbered options unless the active workflow or
agent instruction explicitly declares an override (e.g., a flag like
workflow.requires_open_capture or instruction tag "allow_open_elicitation"), and
document that when such an override is present the agent may ask unconstrained
questions; ensure references to interaction_style, "structured", and the new
override flag/tag are used in the rule and any validation code so the conflict
is resolved deterministically.
In `@tools/cli/installers/lib/ide/templates/combined/kiro-task.md`:
- Line 11: The template enforces RULE: when interaction_style == "structured"
all prompts must be numbered but lacks a path for free-form answers; update the
combined/kiro-task.md template so every structured question includes an explicit
numbered option like "Other / Enter custom response" that routes to a free-form
capture branch and stores the user's raw text into the task input variable
(preserve existing option handlers), and ensure the task execution logic
recognizes this branch and validates/saves the captured free-form value when
interaction_style is "structured".
In `@tools/cli/installers/lib/ide/templates/combined/kiro-tool.md`:
- Line 11: The current RULE forbids any free-form prompts when interaction_style
is "structured"; change the enforcement so that questions explicitly marked as
free-form are exempt: update the validation that checks interaction_style ==
"structured" and rejects non-option prompts to allow question definitions with a
flag such as input_type: "text" or free_form: true (or similar token) to bypass
the numbered-options requirement; keep the existing behavior for all other
questions so that when interaction_style is "structured" and a question lacks
the free_form/input_type marker it still must provide structured numbered
options.
In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow.md`:
- Line 7: Add an explicit precedence clause to resolve the conflict between the
global rule about interaction_style ("When interaction_style is 'structured',
EVERY question...") and the workflow directive "follow workflow exactly";
clearly state which takes precedence and how to handle exceptions (e.g.,
"workflow-specific step instructions override the global structured-interaction
rule" or conversely "global structured-interaction rule overrides workflow steps
and any open-capture steps must be converted to structured options"), and update
the document near the RULE definitions (reference the terms interaction_style,
structured, and follow workflow exactly) so parsers and implementers know
deterministically which rule to apply.
In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow-yaml.md`:
- Line 15: The embedded constraint "When interaction_style is \"structured\",
EVERY question to the user MUST call the question tool. Do NOT write questions
as plain text. No exceptions." is currently inside the numbered steps and must
be converted into a global RULE block; extract that sentence from the numbered
workflow text and add it as a standalone RULE section (e.g., prefixed with
"RULE:" and placed before or after the step list) so it is treated as a
persistent policy rather than a one-time step, and ensure any references to the
original step are removed or replaced with a short pointer to the new RULE
block.
- Line 15: Replace the vague phrase "question tool" with the precise tool
identifier the template expects (referencing the template's routing name) so the
rule reads e.g. When interaction_style is "structured", EVERY question to the
user MUST call tool:question (use the exact canonical tool id your platform uses
instead of the generic phrase) and ensure "interaction_style" and "structured"
remain unchanged.
- Line 15: The rule "When interaction_style is 'structured', EVERY question to
the user MUST call the question tool" lacks a failure contingency: update the
template text around the RULE and references to interaction_style and question
tool to specify a retry and deterministic fallback policy — retry question tool
calls up to 3 times with exponential backoff (e.g., 500ms, 1s, 2s), and if still
failing, invoke a named deterministic backup (e.g.,
"structured_question_fallback" tool or API) that returns a standardized
structured prompt/response envelope and logs the original tool error; explicitly
forbid rendering plain-text questions and describe the exact fallback call,
error logging behavior, and observability fields to be added so the rule remains
enforceable when the primary question tool is unavailable.
---
Outside diff comments:
In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md`:
- Line 12: In the kiro-workflow-yaml.md template replace the unresolved template
variable `{{bmadFolderName}}` with the actual generator variable `_bmad` used by
agent-command-generator.js and workflow-command-generator.js; locate the
reference to the workflow XML path (currently using
`{{bmadFolderName}}/core/tasks/workflow.xml`) and change it to use `_bmad` so
the file path is correctly substituted at runtime.
---
Minor comments:
In `@src/utility/agent-components/activation-steps.txt`:
- Line 4: The session variable list in activation-steps (the step that stores
session vars {user_name}, {communication_language}, {output_folder},
{interaction_style}) is missing {document_output_language}; update that
activation step to store the fifth config field by adding
{document_output_language} to the stored session variables so templates/agents
referencing {document_output_language} have a defined value (ensure the key name
matches the module configuration exactly: document_output_language).
In `@tools/cli/installers/lib/ide/templates/combined/default-task.md`:
- Around line 11-12: Move the RULE line "RULE: When interaction_style is
"structured", EVERY question to the user MUST call the AskUserQuestion tool. Do
NOT write questions as plain text. No exceptions." so it appears before the
execution steps and before the "Follow all instructions" directive to match
placement in default-workflow-yaml.md; update the combined/default-task.md
template so the RULE is standardized at the top of the execution block (i.e.,
prior to any "Follow all instructions" or step list), ensuring the agent will
see and enforce the structured-interaction requirement before running steps.
In `@tools/cli/installers/lib/ide/templates/combined/default-workflow-yaml.md`:
- Around line 6-7: Update the template text so the tool name AskUserQuestion is
formatted as code or quoted (e.g., `AskUserQuestion` or "AskUserQuestion")
instead of plain text; specifically edit the line referencing AskUserQuestion
and ensure it appears clearly as the tool name in the context where
interaction_style is "structured" to avoid ambiguity when readers scan the
default-workflow-yaml template.
In `@tools/cli/installers/lib/ide/templates/combined/kiro-agent.md`:
- Line 9: The "structured options" rule at RULE: When interaction_style is
"structured" is underspecified — update the contract near that RULE to define
minimal required fields: specify whether multiple selections are allowed (e.g.,
allow_multiple: true|false), whether an "Other" choice is required
(include_other: true|false) and its label (other_label), and how free-text
follow-ups are returned (e.g., followup_field: "other_text" and
followup_required: true|false); reference the interaction_style "structured"
rule and the RULE identifier so implementers must implement these keys and
semantics for every structured question to ensure consistent behavior across
IDEs.
In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md`:
- Around line 7-8: The kiro-workflow template includes an extra strict
constraint ("Do NOT ask open-ended inline questions") that is missing from
windsurf-workflow.md; to resolve, either add the exact phrase to the
windsurf-workflow.md fallback rule so both templates read "When
interaction_style is 'structured', EVERY question to the user MUST use
structured options with a numbered list. Do NOT ask open-ended inline questions.
No exceptions." or, if the stricter behavior is intentional for Kiro only, add a
brief comment in kiro-workflow-yaml.md explaining why Kiro requires prohibiting
open-ended inline questions and reference that divergence in
windsurf-workflow.md so the difference is documented and intentional.
In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow.md`:
- Line 7: The template uses the interaction_style key but provides no default;
update the combined/kiro-workflow.md template to explicitly document and enforce
a fallback for interaction_style (either "open" or "structured") so behavior is
well-defined for installs missing the key—add a short sentence near the RULE
paragraph referencing interaction_style that states the default value and how it
affects question formatting (e.g., default to "open" unless explicitly set to
"structured" which then mandates numbered options), and ensure any conditional
text that currently assumes interaction_style checks this documented default
when deciding whether to use structured options.
In `@tools/cli/installers/lib/ide/templates/combined/opencode-agent.md`:
- Around line 8-9: The template currently only defines behavior for
interaction_style == "structured" and lacks fallbacks; update the
opencode-agent.md template to explicitly handle other cases by: (1) defining a
default behavior when interaction_style is missing/undefined (e.g., default to
"open" with free-text questions) and documenting it in the RULE section, (2)
specifying that when interaction_style == "open" the agent must NOT call the
question tool and may ask plain-text questions, and (3) adding validation
guidance for invalid values (reject unknown values or fall back to the default
and log/warn); reference the RULE and the interaction_style field in the text so
implementers of the agent will enforce these cases consistently.
In `@tools/cli/installers/lib/ide/templates/combined/opencode-task.md`:
- Around line 13-14: Template tool naming is inconsistent (opencode uses
"question tool", default uses "AskUserQuestion tool", gemini uses "ask_user
tool") while interaction_style is set via activation-steps.txt and
src/core/module.yaml; standardize all templates to a single tool name (pick one,
e.g., "AskUserQuestion tool") by updating the opencode templates (e.g.,
combined/opencode-task.md and other opencode family templates), the default
family templates, and the gemini family templates to call the chosen tool name
consistently wherever questions are invoked, and update the documentation
(activation-steps.txt or module.yaml docs) to reflect the canonical tool name or
alternatively add a clear mapping table in the docs if multiple names must be
supported; ensure all templates follow the RULE for interaction_style
"structured" to call that unified tool rather than embedding plain-text
questions.
In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md`:
- Line 15: The RULE about interaction_style="structured" currently mandates
calling the question tool but omits requiring numbered options; update the rule
text for "RULE: When interaction_style is \"structured\"" to require that every
question invoked via the question tool also presents structured options as a
numbered list (consistent with antigravity.md). Ensure the wording explicitly
references interaction_style, the question tool, and "numbered list" so readers
must include structured numbered options in the tool invocation.
In `@tools/cli/installers/lib/ide/templates/combined/rovodev.md`:
- Around line 10-11: Move the RULE line "RULE: When interaction_style is
\"structured\", EVERY question to the user MUST use structured options with a
numbered list. No exceptions." so it appears before the sentence "Follow all
instructions in the workflow file exactly as written." or incorporate it into
the initial instruction block; update the template text around the workflow file
reference to explicitly call out this RULE up front. Also add a short example
single-line format for "structured options" (e.g., "1) Option A\n2) Option B\n3)
Option C") directly after the RULE to remove ambiguity and ensure every
structured question uses a numbered list format.
In `@tools/cli/installers/lib/ide/templates/workflow-commander.md`:
- Line 7: The template uses a bare @{{workflow_path}} which is inconsistent with
other workflow templates; update the path notation to the full pattern used
elsewhere (for example use @{project-root}/{{bmadFolderName}}/{{workflow_path}})
so the line becomes "LOAD the FULL
@{project-root}/{{bmadFolderName}}/{{workflow_path}}, READ its entire
contents..." and adjust any other occurrences in workflow-commander.md to match
this established pattern (use the
@{project-root}/{{bmadFolderName}}/{{workflow_path}} form rather than the bare
variable).
---
Nitpick comments:
In `@src/core/module.yaml`:
- Line 29: The interaction_style default in module.yaml can be corrupted by
manual edits (e.g., "strucutred"), causing RULE-based templates to silently
misbehave; add explicit validation when loading config.yaml: in the
configuration loader that reads interaction_style (look for the codepath that
parses interaction_style / module.yaml), validate the value against an allowed
set (e.g., "structured", "single-select", "unstructured"), and if invalid either
throw a clear error or log a warning and fall back to a safe default, ensuring
templates/RULE checks see only validated values.
In `@tools/cli/installers/lib/ide/templates/combined/default-tool.md`:
- Around line 11-12: The template file default-tool.md contradicts its “default”
name by referencing the Claude-specific AskUserQuestion tool and requiring
interaction_style "structured"; either rename the file to claude-tool.md to make
its Claude-specific intent explicit (update any references to default-tool.md)
or modify the template to use the generic numbered-list fallback (remove
AskUserQuestion usages and ensure questions are plain numbered list entries when
interaction_style is not Claude-specific). Locate occurrences of AskUserQuestion
and interaction_style "structured" in default-tool.md and apply one of these two
fixes so the template name matches its behavior.
In `@tools/cli/installers/lib/ide/templates/combined/gemini-agent.toml`:
- Around line 6-8: Add a checklist verification that confirms the
interaction_style value was loaded from the agent config (config.yaml) and
stored in memory; specifically update the pre-flight checklist (the lines that
check {user_name}) to include a step such as "CONFIRM: interaction_style is set
to \"{interaction_style}\"" so the RULE that depends on interaction_style can
rely on it being present and correct when the agent reads the internalized agent
definition at {project-root}/{{bmadFolderName}}/{{path}}.
- Around line 10-11: Update the RULE text in the gemini-agent.toml template so
its phrasing matches the canonical wording used in other templates: replace the
current "Do NOT write questions as plain text" line in the RULE that begins with
`When interaction_style is "structured", EVERY question to the user MUST call
the ask_user tool` with the standardized phrasing used elsewhere (e.g.,
explicitly require calling ask_user for every question, forbid
open-ended/plain-text inline questions, and require structured options as a
numbered list) so the rule semantics match the
`antigravity.md`/`agent-command-template.md` intent.
In `@tools/cli/installers/lib/ide/templates/combined/gemini-tool.toml`:
- Line 9: The numbered list mixes sequential actions with a conditional
constraint—specifically the line "4. RULE: When interaction_style is
"structured", EVERY question to the user MUST call the ask_user tool."—so
extract that rule out of the step sequence and place it as a separate unnumbered
RULES or NOTES section (or prepend "RULE:" above/below the numbered steps) so
steps 1-3 remain purely sequential (LOAD, READ, FOLLOW) and the constraint is
clearly a global/conditional policy that applies at all times rather than an
executable step; update the template in gemini-tool.toml to remove the "4."
prefix and ensure the rule text references interaction_style and ask_user
exactly as written.
In `@tools/cli/installers/lib/ide/templates/combined/kiro-task.md`:
- Line 11: Update the RULE block that begins with "RULE: When interaction_style
is \"structured\", EVERY question to the user MUST use structured options with a
numbered list. No exceptions." to include a recovery loop for clarification
turns: add a short sentence (or a new sub-rule) stating that if the user replies
with a clarifying question instead of an option number, the agent must first
answer the clarification briefly and then immediately re-issue the same
structured prompt with the numbered options; reference the original RULE text so
reviewers can find and apply this change in the kiro-task.md template.
In `@tools/cli/installers/lib/ide/templates/combined/kiro-tool.md`:
- Line 11: The duplicated policy line 'RULE: When interaction_style is
"structured", EVERY question to the user MUST use structured options with a
numbered list. No exceptions.' in the kiro-tool.md template should be moved into
a single shared include/token (e.g., a new template fragment named something
like "interaction-style-rule") and replaced here with a reference to that
include; update kiro-tool.md to remove the copied policy text and insert the
include reference so all templates pull the rule from one source, and add/update
tests or documentation that assert the shared include exists and is used by
templates referencing the rule.
- Line 11: The template rule for interaction_style "structured" currently
mandates numbered-choice questions but lacks handling for invalid responses;
update the combined/kiro-tool.md question schema (look for the interaction_style
key and the RULE line) to include a mandatory invalid-response policy: add a
reprompt/normalize field that retries up to N times (showing allowed numeric
choices), validates numeric/option input, and if still invalid escalates to
open/free-text input or a fallback message; ensure the policy metadata is
present for every question using structured options so consumers like the
renderer/ask_user function can enforce retries and normalization consistently.
In `@tools/cli/installers/lib/ide/templates/combined/opencode-tool.md`:
- Around line 13-14: The RULE text "RULE: When interaction_style is
"structured", EVERY question to the user MUST call the question tool. Do NOT
write questions as plain text. No exceptions." is duplicated across templates
(e.g., opencode-tool.md and opencode-task.md) and should be factored into a
single shared partial; create a shared include (e.g., a common RULE partial
named something like structured-question-rule) and replace the inline RULE in
all affected templates (the ~27 modified files) with a reference/include to that
partial, ensuring the partial contains the exact canonical wording and updating
any template rendering logic to pull that partial so future edits happen in one
place.
In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md`:
- Line 5: Replace the verb "Execute" with the standardized BMAD action phrasing
"Load and follow" in the template line that currently reads "Execute the BMAD
'{{name}}' workflow" so it conforms to BMAD-METHOD conventions (per issue `#1378`
/ PRs `#1387/`#1570); update the string containing '{{name}}' to "Load and follow
the BMAD '{{name}}' workflow" ensuring no other surrounding wording is changed.
In `@tools/cli/installers/lib/ide/templates/combined/trae.md`:
- Around line 10-11: The RULE line "When interaction_style is "structured",
EVERY question to the user MUST use structured options with a numbered list. No
exceptions." is duplicated across multiple templates (including the Trae
template shown and rovodev.md); extract this sentence into a shared template
partial (e.g., a reusable "structured-interaction-rule" partial) and replace the
duplicated line in templates Trae, Kiro, Windsurf, Antigravity and RovoDev with
an include/reference to that partial so the text is maintained in one place and
placement/formatting stays identical.
In `@tools/cli/installers/lib/ide/templates/combined/windsurf-workflow.md`:
- Around line 11-12: Update the RULE line that currently reads 'RULE: When
interaction_style is "structured", EVERY question to the user MUST use
structured options with a numbered list. No exceptions.' to match the wording
used in tool-based templates by explicitly requiring a numbered-list format and
forbidding prose questions; e.g., replace it with a unified sentence such as:
'When interaction_style is "structured", EVERY question MUST present options as
a numbered list (e.g., 1. Option A, 2. Option B) and must NOT be written as
plain prose.' Ensure you update the occurrence of interaction_style and the RULE
heading in windsuf-workflow.md so it aligns with default-agent.md and
gemini-*.toml conventions.
In `@tools/cli/installers/lib/ide/templates/workflow-commander.md`:
- Around line 5-6: The RULE line in workflow-commander.md contains an extra
phrase "Do NOT ask open-ended inline questions" that is inconsistent with
windsuf-workflow.md and kiro-workflow-yaml.md; either remove that phrase from
workflow-commander.md to match the other fallback templates or add the same
explicit prohibition to the other templates and a short clarifying note that
explains whether "no inline questions" is a separate constraint vs part of
"structured options." Update the RULE text (interaction_style "structured") and
the templates (workflow-commander.md, windsurf-workflow.md,
kiro-workflow-yaml.md) so the wording is identical and, if the prohibition is
intended, add a brief doc sentence clarifying its scope and examples.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (29)
src/core/module.yamlsrc/utility/agent-components/activation-steps.txttools/cli/installers/lib/ide/templates/agent-command-template.mdtools/cli/installers/lib/ide/templates/combined/antigravity.mdtools/cli/installers/lib/ide/templates/combined/default-agent.mdtools/cli/installers/lib/ide/templates/combined/default-task.mdtools/cli/installers/lib/ide/templates/combined/default-tool.mdtools/cli/installers/lib/ide/templates/combined/default-workflow-yaml.mdtools/cli/installers/lib/ide/templates/combined/default-workflow.mdtools/cli/installers/lib/ide/templates/combined/gemini-agent.tomltools/cli/installers/lib/ide/templates/combined/gemini-task.tomltools/cli/installers/lib/ide/templates/combined/gemini-tool.tomltools/cli/installers/lib/ide/templates/combined/gemini-workflow-yaml.tomltools/cli/installers/lib/ide/templates/combined/gemini-workflow.tomltools/cli/installers/lib/ide/templates/combined/kiro-agent.mdtools/cli/installers/lib/ide/templates/combined/kiro-task.mdtools/cli/installers/lib/ide/templates/combined/kiro-tool.mdtools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.mdtools/cli/installers/lib/ide/templates/combined/kiro-workflow.mdtools/cli/installers/lib/ide/templates/combined/opencode-agent.mdtools/cli/installers/lib/ide/templates/combined/opencode-task.mdtools/cli/installers/lib/ide/templates/combined/opencode-tool.mdtools/cli/installers/lib/ide/templates/combined/opencode-workflow-yaml.mdtools/cli/installers/lib/ide/templates/combined/opencode-workflow.mdtools/cli/installers/lib/ide/templates/combined/rovodev.mdtools/cli/installers/lib/ide/templates/combined/trae.mdtools/cli/installers/lib/ide/templates/combined/windsurf-workflow.mdtools/cli/installers/lib/ide/templates/workflow-command-template.mdtools/cli/installers/lib/ide/templates/workflow-commander.md
|
Reworking and testing the fixes. |
|
Fixed all relevant issues and tested on Claude. |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 4
Note
Due to the large number of review comments, Critical severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
tools/cli/installers/lib/ide/platform-codes.yaml (2)
35-43:⚠️ Potential issue | 🟡 MinorAdd an inline comment to claude-code explaining why
ancestor_conflict_checkis enabled.The schema documentation (lines 206-208) explains that
ancestor_conflict_checkrefuses installation when ancestor directories contain BMAD files in the sametarget_dir— necessary for platforms that inherit commands from parent directories. However, there's no inline comment at the claude-code entry (line 43) explaining why this platform specifically uses this flag. Add a brief comment like# ancestor_conflict_check: true # Claude Code inherits commands from parent directoriesto clarify the intent for maintainers.Note: No evidence suggests other CLI tools (gemini, auggie, etc.) have the same inheritance behavior as Claude Code, so the current selective use appears intentional.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/platform-codes.yaml` around lines 35 - 43, Add an inline comment to the claude-code entry explaining why ancestor_conflict_check is enabled: update the claude-code block (symbol: claude-code) next to the ancestor_conflict_check key (symbol: ancestor_conflict_check) to include a short comment such as "# ancestor_conflict_check: true # Claude Code inherits commands from parent directories" so maintainers understand this platform needs to refuse installs when ancestor dirs contain BMAD files.
129-144:⚠️ Potential issue | 🔴 CriticalFix the misleading code comment and add test coverage for multi-target installations.
The
installToMultipleTargets()andinstallToTarget()code paths are cleanly separated and correctly implemented. However:
The class header comment in
_config-driven.jsincorrectly claims "Multi-target installation support (e.g., GitHub Copilot)" — GitHub Copilot uses a custom installer and does not use this code path. OpenCode is the actual multi-target platform using this support.No test coverage found for either the single-target or multi-target installation paths. Both should be tested, particularly:
- OpenCode's multi-target setup (agents and commands directories)
- Artifact type filtering per target
- Legacy target cleanup and directory migration
The configuration schema in platform-codes.yaml documents the
targetsarray, but add a comment clarifying: "Usetargetsarray only when a single platform needs multiple installation directories with different artifact types. Otherwise, use singletarget_dir+template_type."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/platform-codes.yaml` around lines 129 - 144, Update the misleading class header comment in _config-driven.js to reference OpenCode (not GitHub Copilot) as the consumer of multi-target installation support and ensure references to the installToMultipleTargets() and installToTarget() code paths are accurate; add unit/integration tests that cover OpenCode's multi-target install (creating .opencode/agents and .opencode/commands), verify artifact type filtering per target, and test legacy_targets cleanup and directory migration behavior; and augment platform-codes.yaml near the targets array for OpenCode with a clarifying comment: "Use `targets` array only when a single platform needs multiple installation directories with different artifact types. Otherwise, use single `target_dir` + `template_type`."tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md (1)
11-11:⚠️ Potential issue | 🟡 MinorUnclear placeholder syntax pattern requires clarification:
{project-root}vs{{variables}}The template mixes two placeholder syntaxes consistently across all templates:
{{description}},{{name}},{{bmadFolderName}},{{path}}(double braces){project-root}(single braces)This pattern appears 30+ times across 15+ templates, always in the same context:
{project-root}/{{bmadFolderName}}/{{path}}. The systematic nature suggests intentional two-stage templating (install-time vs runtime variable resolution), but this design is undocumented.Clarify: Are these deliberately different templating systems? If so, document the distinction (e.g., which engine/stage handles each syntax). If not, standardize to a single syntax across all templates.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/opencode-workflow.md` at line 11, The template mixes two placeholder syntaxes ({project-root} vs {{bmadFolderName}} and {{path}}) causing ambiguity; either standardize all templates to a single placeholder format (e.g., change {project-root} -> {{projectRoot}} everywhere, or {{bmadFolderName}} -> {bmadFolderName}) or explicitly document the two-stage templating rule (which engine/stage resolves {project-root} and which resolves {{...}}) and update the templates' top-level README or template header to state that rule; search for the pattern "{project-root}/{{bmadFolderName}}/{{path}}" and apply the chosen fix consistently across all templates and template docs.tools/cli/installers/lib/ide/templates/combined/default-agent.md (1)
15-16:⚠️ Potential issue | 🟡 MinorVague menu presentation requirements.
Steps 5 and 6 instruct agents to "PRESENT the numbered menu" and "WAIT for user input" but don't specify:
- Menu format (plain text? markdown table? numbered list with emoji?)
- How to handle menus with many items (pagination? scrolling? categories?)
- Whether the menu is interactive (clickable?) or text-only
- What "WAIT" means technically (async await? blocking call? polling?)
Since this is the default fallback template used by multiple IDEs, these ambiguities will amplify across different AI implementations.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/default-agent.md` around lines 15 - 16, Clarify Steps 5 and 6 in the template: update the instructions for "PRESENT the numbered menu" to require a numbered Markdown list (1. item) with optional short descriptions, group long lists into categories and paginate at N items per page (default 10) with a "more" entry to navigate, and specify whether items can include emoji or links (allow plain-text + optional Markdown links); update "WAIT for user input" to define explicit behavior: for text-only UIs treat it as a blocking prompt that returns the selected index or "more"/"back"/"cancel", for async integrations require the agent to await a promise and include a 30s default timeout and clear timeout handling, and document expected return values (selected index, command token) so implementers of the template (steps 5 and 6) can consistently render, paginate, and handle user responses across IDEs.
♻️ Duplicate comments (4)
tools/cli/installers/lib/ide/templates/combined/claude-tool.md (1)
8-8:⚠️ Potential issue | 🟠 MajorDuplicate issue: hardcoded Claude tool and undefined interaction_style.
This template repeats the same issues already flagged in
claude-workflow-yaml.mdandclaude-task.md:
- Hardcoded
AskUserQuestionwith no fallback or version check- Reference to undefined
interaction_stylevariable- No specification of behavior when interaction_style is not "structured"
The fact that this pattern appears in at least four separate files (claude-workflow-yaml, claude-task, claude-tool, claude-workflow) suggests a systematic design flaw rather than isolated oversights.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/claude-tool.md` at line 8, The template hardcodes calling the AskUserQuestion tool and references an undefined interaction_style variable; update the template logic around AskUserQuestion to first validate that interaction_style is defined and to branch: if interaction_style === "structured" then invoke AskUserQuestion (or a version-checked wrapper that ensures compatibility), else allow free-form input or call an alternative tool; add a clear fallback path and a version/compatibility guard around AskUserQuestion to avoid a hardcoded call and document the behavior when interaction_style is missing or not "structured".tools/cli/installers/lib/ide/templates/combined/claude-task.md (1)
8-8: 🛠️ Refactor suggestion | 🟠 MajorDuplicate hardcoded tool dependency.
This template has the same
AskUserQuestionhardcoding issue asclaude-workflow-yaml.md(see that review). This pattern is now repeated across multiple files, multiplying the maintenance burden when Claude's tool API changes.Consider extracting the RULE into a shared snippet or configuration that all Claude templates import, reducing duplication and making future updates easier.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/claude-task.md` at line 8, The file hardcodes the RULE and the AskUserQuestion tool dependency (the string "RULE: When interaction_style is \"structured\"..." and the literal AskUserQuestion usage); extract that RULE into a single shared snippet/config (e.g., a shared template fragment or config key) and replace the inline RULE and any direct AskUserQuestion mentions in claude-task.md (and other Claude templates) with an import/include/reference to the shared snippet, updating template rendering/loading logic to read that shared rule so future changes to the RULE or tool name only need to be made in one place.tools/cli/installers/lib/ide/templates/combined/default-agent.md (1)
8-8:⚠️ Potential issue | 🟠 MajorRULE still references undefined interaction_style variable.
Even though this template was updated to avoid Claude-specific tools, it still has the fundamental issue flagged in
antigravity.md: the RULE referencesinteraction_stylewith no explanation of where it comes from, what valid values are, or what happens when it's not "structured."This issue exists across multiple templates and needs a systematic fix, not file-by-file patching.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/default-agent.md` at line 8, The RULE references an undefined variable interaction_style; define a clear template-level schema and default for interaction_style (e.g., allowed values: "structured"|"freeform", default "freeform") and update the template engine or metadata section so templates (including the RULE text) can reference it reliably; change the RULE to use that schema (or a conditional macro) to produce the numbered-list requirement only when interaction_style == "structured", and add validation logic in the template loader to error on unknown interaction_style so this is fixed systematically across all templates.tools/cli/installers/lib/ide/templates/combined/claude-workflow.md (1)
6-6:⚠️ Potential issue | 🔴 CriticalDuplicate issue: same RULE pattern repeated across all Claude templates.
This is the fifth Claude template with identical
AskUserQuestionandinteraction_styleissues. All five templates (claude-workflow-yaml, claude-task, claude-tool, claude-workflow, claude-agent) share the same fundamental problems:
- Hardcoded tool name with no version or fallback
- Undefined
interaction_stylevariable- No handling of non-structured modes
- Undocumented override mechanism
This isn't just code duplication—it's architectural fragility. A single change to Claude's API or the interaction_style design requires updating five+ files, increasing the risk of inconsistency.
Consolidate the RULE into a shared template snippet that all Claude templates include via a template inheritance or import mechanism. Update it once, propagate everywhere.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/claude-workflow.md` at line 6, Consolidate the duplicated RULE by extracting the AskUserQuestion/interaction_style logic into a single shared template snippet (e.g., claude-interaction-snippet) and have all Claude templates (claude-workflow, claude-tool, claude-agent, claude-task, claude-workflow-yaml) include/import that snippet; inside the snippet explicitly define a safe default for interaction_style, implement a clear branch for "structured" that ALWAYS uses the AskUserQuestion tool (and for non-structured modes fall back to free-form input), accept a configurable tool name/version with a fallback resolution mechanism instead of hardcoding the tool name, and document/parametrize an override mechanism so callers can opt-out—then update each template to import the shared snippet rather than repeating the RULE.
🟡 Minor comments (24)
tools/cli/installers/lib/ide/templates/combined/kiro-tool.md-11-11 (2)
11-11:⚠️ Potential issue | 🟡 MinorLocalization behavior is missing for structured prompts.
The rule does not require options and labels to follow the active output language/session language, causing mixed-language UX in multilingual runs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-tool.md` at line 11, The structured-prompt rule currently omits localization for option text and labels, causing mixed-language UX; update the template logic that emits RULE and the interaction_style == "structured" branch (look for the "RULE" line and the interaction_style/"structured" handling in kiro-tool.md) to retrieve and render option labels and numbered-list items using the active session/output language (i.e., pass the current locale into the renderer or call the localization utility when constructing each option/label) so all displayed options, labels and the numbered list are localized to the active language.
11-11:⚠️ Potential issue | 🟡 MinorMulti-select questions are undefined.
The rule only covers single numbered options; workflows needing multiple selections have no standardized format.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-tool.md` at line 11, The rule for interaction_style = "structured" lacks a standard for multi-select questions; update the RULE and the combined/kiro-tool.md template to define and enforce a standardized multi-select format (e.g., numbered options plus an instruction like "Select one or more by entering comma-separated numbers" or a distinct "multi-select" block type) so renderers and validators can parse multiple selections consistently; change the validation logic that checks interaction_style "structured" to accept the new multi-select syntax, add examples in the template, and ensure the wording mentions the exact tokens "interaction_style", "structured", and "multi-select" so downstream code can locate and implement the change.tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md-7-7 (3)
7-7:⚠️ Potential issue | 🟡 MinorScope is too broad (“questions to the user”).
This likely catches confirmations and safety prompts where forced option lists are unnecessary. Narrow applicability to requirement-elicitation prompts.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md` at line 7, The RULE text is too broad; update the rule that currently reads "When interaction_style is 'structured', questions to the user MUST use structured options..." to restrict it to requirement-elicitation prompts only—e.g., change it to something like "When interaction_style is 'structured' and the prompt is a requirement-elicitation prompt, questions to the user MUST use structured options..."—so adjust the RULE wording referencing interaction_style and the 'structured' mode to explicitly target requirement-elicitation prompts (not general confirmations or safety prompts).
7-7:⚠️ Potential issue | 🟡 MinorLanguage consistency is not enforced in the rule.
This line doesn’t bind question options to the active output/session language, which can cause mixed-language UX in multilingual workflows.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md` at line 7, The rule for interaction_style == "structured" must enforce that question option labels are localized to the active output/session language; update the rule text to require that structured option lists reference the session's active language (e.g., via the session language variable or localization function) so options are rendered in the current UI language instead of mixing languages, and update any template generators that produce numbered option lists to use the active language lookup (mentioning interaction_style and the session language variable/name) when composing option text.
7-7:⚠️ Potential issue | 🟡 MinorNo fallback behavior for invalid or missing
interaction_style.The rule only handles
"structured"and leaves undefined behavior for null/typo/unset values. Add a deterministic default path.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.md` at line 7, The template rule only handles interaction_style == "structured" and lacks a fallback; update the logic that reads interaction_style to validate the value and apply a deterministic default (e.g., treat null/typo/unset as "structured" or explicitly set "freeform" per spec), and ensure any question-rendering code/path that uses interaction_style falls back to that default before generating UI (reference interaction_style and the "structured" handling branch) so invalid or missing values produce a consistent numbered-options behavior.tools/cli/installers/lib/ide/templates/combined/gemini-task.toml-10-10 (2)
10-10:⚠️ Potential issue | 🟡 MinorRULE assumes
interaction_styleis always defined — no fallback behavior specified.If
interaction_styleis unset, misspelled in config, or set to an unexpected value (neither "structured" nor "open"), the agent has no guidance on what to do. This could lead to inconsistent behavior across installations.Consider: (1) specifying default behavior when the variable is absent, or (2) explicitly stating "otherwise, use free-form questioning."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-task.toml` at line 10, The RULE that checks interaction_style lacks a fallback; update the policy around interaction_style to define explicit default behavior when interaction_style is missing/misspelled/unexpected (e.g., default to "open" or explicitly state "otherwise, use free-form questioning"), and document that in the same template where RULE and interaction_style are defined so callers of the rule or any validation (the interaction_style setting and RULE text) will enforce or assume the fallback consistently.
10-10:⚠️ Potential issue | 🟡 MinorAmbiguous phrase "free-form input is explicitly requested."
What constitutes an "explicit request" for free-form input? Is it a keyword in the workflow file? A user utterance pattern? Without concrete examples or criteria, agent implementations may interpret this inconsistently.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-task.toml` at line 10, The RULE text is ambiguous about what counts as an "explicit request" for free-form input; update the RULE and related documentation to define concrete criteria and examples so implementations are consistent: explicitly state whether an explicit request is a workflow flag (e.g., a field like free_form_allowed = true), a specific keyword or directive in the workflow (e.g., "allow_free_form": true), or a user utterance pattern (e.g., user message starting with "I want to answer freely" or use of a dedicated intent), and add examples showing (1) a workflow snippet that enables free-form input, (2) a user utterance that qualifies, and (3) the default behavior when none are present; reference the interaction_style = "structured" rule and the requirement to call the ask_user tool so readers know exactly how to detect and handle explicit free-form requests.tools/cli/installers/lib/ide/templates/combined/opencode-task.md-13-13 (1)
13-13:⚠️ Potential issue | 🟡 MinorSame fallback gap: no guidance when
interaction_styleis absent or "open".Mirroring the issue in gemini-task.toml — if
interaction_styleis unset or set to "open", agents receive no explicit instruction. The RULE should either specify default behavior or explicitly state "when 'open', use free-form questioning."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/opencode-task.md` at line 13, The RULE only mandates use of the `question` tool when interaction_style == "structured" but doesn't define behavior when interaction_style is absent or set to "open"; update the RULE text (the RULE line mentioning interaction_style) to explicitly define the default: state that when interaction_style is absent or "open", agents should use free-form questioning (i.e., do not call the `question` tool), or alternatively define a default interaction_style (e.g., default to "open") and mirror this same explicit wording in the corresponding gemini-task.toml guidance to ensure consistent behavior; reference the `interaction_style` field and the `question` tool in the revised sentence.tools/cli/installers/lib/ide/templates/combined/gemini-workflow-yaml.toml-15-15 (4)
15-15:⚠️ Potential issue | 🟡 MinorScope is too narrow: it covers “questions” but not all user-input requests.
Confirmations, approvals, and selection prompts can still bypass the tool under this wording.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-workflow-yaml.toml` at line 15, Update the RULE line so it applies to all user-input requests, not just "questions": when interaction_style is "structured", any user-input request (including questions, confirmations, approvals, and selection prompts) MUST call the ask_user tool unless the workflow or user explicitly requests free-form input; modify the wording that currently references "questions" to reference "user-input requests" and list examples (confirmations, approvals, selection prompts) to make intent explicit, keeping the condition tied to interaction_style and the ask_user tool.
15-15:⚠️ Potential issue | 🟡 MinorMultiple questions in a single tool call are not constrained.
Without a one-question-per-call rule, response mapping becomes ambiguous and error-prone.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-workflow-yaml.toml` at line 15, The template allows multiple questions in a single ask_user tool call when interaction_style == "structured", which causes ambiguous response mapping; update the generator/validator that emits the RULE (check for the interaction_style field) to enforce one question per ask_user invocation by splitting multi-question entries into separate ask_user calls and/or validating and rejecting workflow templates that contain more than one question per tool call; reference the interaction_style key and the ask_user tool/field in the workflow generator/validator to implement this constraint and surface a clear validation error tied to the RULE.
15-15:⚠️ Potential issue | 🟡 MinorMixed-mode output is still possible.
Line 15 requires calling
ask_user, but does not forbid duplicating the same question in plain text in the assistant response.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-workflow-yaml.toml` at line 15, The rule for interaction_style "structured" currently mandates calling ask_user but doesn't forbid repeating the same question as plain text; update the rule text and any validation that consumes RULE to explicitly prohibit duplicating the same question in the assistant response outside the ask_user tool when interaction_style == "structured", and enforce this in the template/validator that parses gemini-workflow-yaml.toml by checking for identical question strings in assistant outputs versus tools and rejecting or flagging workflows that repeat them; reference the existing RULE line and the ask_user tool/interaction_style "structured" in the change.
15-15:⚠️ Potential issue | 🟡 MinorAdd explicit error handling guidance for
ask_userfailures in prompt templates.The rule mandates using
ask_userfor structured interactions but provides no recovery behavior if the tool call fails. While Gemini may handle tool errors implicitly, the prompt templates should explicitly document expected fallback behavior (e.g., "if ask_user fails, proceed with free-form input" or "retry the request"). This prevents workflows from silently stalling when tool invocation fails.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/gemini-workflow-yaml.toml` at line 15, The prompt template rule mentioning interaction_style "structured" and the requirement to call the ask_user tool lacks explicit failure/fallback behavior; update the template text around the RULE and any prompt examples that call ask_user to include clear error handling guidance (e.g., on ask_user failure retry N times, then proceed with free-form input, or abort with a descriptive error), and document the preferred default fallback policy so workflows using interaction_style "structured" know to retry or switch to free-form input when the ask_user tool fails.docs/how-to/install-bmad.md-70-70 (1)
70-70:⚠️ Potential issue | 🟡 MinorMissing validation constraints for Interaction Style.
The documentation shows
structuredas the default but doesn't specify:
- Whether the values are case-sensitive ("Structured" vs "structured")
- What happens if you type "struct" or misspell it as "structed"
- Whether there are other valid values beyond structured/open
- What the agent does if the value is invalid
Users editing config.yaml manually need to know the exact valid values and format.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-to/install-bmad.md` at line 70, Update the "Interaction Style" documentation to list exact, case-sensitive valid values and the validator behavior: state that Interaction Style accepts only the lowercase strings "structured" and "open" (no alternate spellings like "Structured", "struct", or "structed"), declare that the value is case-sensitive, describe that the config validator will reject invalid values with a clear error and/or fall back to the default "structured" only if explicitly implemented, and show an example config.yaml snippet and the expected validation error message so editors know what happens when they provide an invalid value; reference the "Interaction Style" field and the example value "structured" from the docs.tools/cli/installers/lib/ide/templates/combined/claude-task.md-10-10 (1)
10-10:⚠️ Potential issue | 🟡 MinorTemplate relies on {{bmadFolderName}} without validation or fallback.
The path
{project-root}/{{bmadFolderName}}/{{path}}assumes{{bmadFolderName}}is always defined and valid, but:
- What if the template engine fails to substitute it?
- What if it's set to an invalid directory name (e.g., contains
../)?- What if the folder doesn't exist at runtime?
The template should either validate the substitution or provide a fallback path (e.g., default to
_bmad).docs/how-to/install-bmad.md-77-77 (1)
77-77:⚠️ Potential issue | 🟡 MinorMisleading guidance about editing config.yaml.
The documentation states users can change settings "by editing that file and rerunning the installer," but doesn't clarify:
- Can you edit config.yaml WITHOUT rerunning the installer? (Will agents pick up the changes?)
- What parts of the installer run when you "rerun" it? (Full reinstall? Just config merge?)
- Whether you risk losing other settings or files by rerunning
- If there's a faster way to reload config (restart IDE? reload workspace?)
This guidance could lead users to unnecessarily reinstall BMAD when a simpler config reload would suffice.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-to/install-bmad.md` at line 77, The doc line claiming settings "can be changed later by editing that file and rerunning the installer" is misleading; update the guidance around `_bmad/<module>/config.yaml` to explicitly state whether agents pick up edits without rerunning the installer, which parts of the installer run on a "rerun" (e.g., only config merge vs full reinstall), any risk of overwriting other settings or files, and provide faster alternatives for applying changes (for example: restart agent service, reload workspace/IDE, or run a specific config-merge command). Also add a short recommended workflow (edit file → run nominal reload command or restart agent → verify with status/logs) and a warning if rerunning the full installer may overwrite manual changes.tools/cli/installers/lib/ide/templates/combined/claude-workflow.md-8-8 (1)
8-8:⚠️ Potential issue | 🟡 MinorDocument or unify path syntax across templates.
The
@prefix appears systematically in all workflow templates (claude-workflow.md,default-workflow.md, and their-yamlvariants) but is absent in task, tool, and agent templates. While this pattern is consistent, there is no documentation explaining why workflow templates require the@prefix. This undocumented distinction will confuse maintainers and raises questions: Is@a meaningful syntax marker (and if so, why?), or an accidental pattern that should be unified across all templates? Either way, the reasoning needs to be documented or the syntax standardized.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/claude-workflow.md` at line 8, The workflow templates (e.g., claude-workflow.md and default-workflow.md) use a leading '@' in path syntax like "@{project-root}/{{bmadFolderName}}/{{path}}" while task/tool/agent templates do not, and there's no documentation explaining this difference; either add a short documented rationale in the templates README explaining that '@' is a deliberate syntax marker and what it means (reference the "@{project-root}/{{bmadFolderName}}/{{path}}" pattern and the files claude-workflow.md/default-workflow.md and their -yaml variants), or remove the '@' from those workflow templates to match task/tool/agent templates and update any consumers/tests accordingly so all templates use the same path syntax. Ensure the chosen change is applied consistently across all workflow template variants and the template docs/examples are updated to reflect the new canonical syntax.src/utility/agent-components/activation-steps.txt-2-7 (1)
2-7:⚠️ Potential issue | 🟡 MinorUpdate verb phrasing to align with workflow standardization.
Line 2: Change "Load and read" to "load and follow" to match the standardized verb phrasing across workflow prompts (PR
#1570). Action instructions use "load and follow" or "read and follow" per the framework's established conventions.Note: Both
interaction_styleanddocument_output_languagehave defaults defined in the config schema (interaction_style defaults to "structured", document_output_language defaults to "English"), so existing installations upgrading will not fail—they will receive defaults for missing fields during config merge operations.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/utility/agent-components/activation-steps.txt` around lines 2 - 7, Update the verb phrasing in the activation step element step n="2": replace the phrase "Load and read {project-root}/_bmad/{{module}}/config.yaml NOW" with "load and follow {project-root}/_bmad/{{module}}/config.yaml NOW" so it matches standardized wording ("load and follow"/"read and follow") used across workflow prompts; keep the remaining lines in step n="2" (storing session variables {user_name}, {communication_language}, {output_folder}, {interaction_style}, {document_output_language}, the VERIFY stop-and-report behavior, and the DO NOT PROCEED gate) unchanged and ensure defaults for interaction_style and document_output_language remain compatible with the config schema merge behavior.tools/cli/installers/lib/ide/templates/combined/claude-workflow-yaml.md-6-6 (1)
6-6:⚠️ Potential issue | 🟡 MinorAdd fallback handling and document AskUserQuestion tool limitations in templates.
The
AskUserQuestiontool is documented in Claude's Agent SDK and Claude Code with a specified API (input shape:questions[]withquestion,header,options[],multiSelect). However, the templates hardcode this tool without:
- Fallback behavior if the tool is unavailable or fails—templates should degrade gracefully (e.g., fallback to free-form input)
- Documentation of tool constraints: the tool cannot be used in Task-spawned subagents and supports only 1–4 questions with 2–4 options each; templates should document these limits
- Handling known reliability issues: GitHub issues report
AskUserQuestionfails to trigger reliably outside plan mode in some Claude Code versions (v2.0.22 and related); templates should account for potential tool unavailabilityAdd conditional logic to handle tool failures and document the tool's limitations inline.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/claude-workflow-yaml.md` at line 6, Update the combined template to add graceful fallback and inline docs for AskUserQuestion: when interaction_style == "structured" invoke AskUserQuestion but wrap it with conditional logic to detect tool availability/failure and fall back to free-form input; add inline comments in the template that document AskUserQuestion constraints (only usable in non-Task-spawned agents, supports 1–4 questions with 2–4 options each, unreliable outside plan mode in some Claude Code versions) and ensure any call-sites in the template check for tool success and handle errors by emitting a fallback prompt to the user or switching to a free-form input path.tools/cli/installers/lib/ide/templates/combined/claude-agent.md-16-16 (1)
16-16:⚠️ Potential issue | 🟡 MinorAmbiguous instruction: "proceeding" to what?
Step 6 says "WAIT for user input before proceeding," but the instruction list ends there. Proceeding to what exactly? Executing the user's menu selection? Reading more instructions from the external file? This should be explicit.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/claude-agent.md` at line 16, Clarify the ambiguous Step 6 text "WAIT for user input before proceeding" in the combined/claude-agent.md template: replace it with a specific action such as "WAIT for user input, then execute the selected menu option" or "WAIT for user input to confirm and continue the installation," and ensure the surrounding steps or a parenthetical note explicitly state whether the input triggers executing the user's selection, reading additional instructions, or terminating; update the Step 6 line and any nearby references so the intended next action (e.g., execute selection, continue installer flow, or read external file) is unambiguous.tools/cli/installers/lib/ide/templates/combined/claude-agent.md-6-6 (1)
6-6:⚠️ Potential issue | 🟡 MinorUndefined "exit command" creates ambiguity.
Line 6 instructs the agent to "NEVER break character until given an exit command," but nowhere in this template or the referenced external files is an exit command defined. How is the agent supposed to recognize it? Is it a specific phrase, a menu option, or a special command format?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/claude-agent.md` at line 6, The template's instruction "NEVER break character until given an exit command" is ambiguous because no exit token is defined; add an explicit exit command token (e.g., a clearly documented string like EXIT_AGENT or a prefixed command such as /exit-agent) to the claude-agent.md template and update the activation instructions to state that exact token, then ensure the agent runtime checks for that token when parsing inputs (update the code path that enforces persona activation to listen for the new token). Also add a short line in the template clarifying whether the token is case-sensitive and whether alternate forms (menu option or special command format) are accepted so consumers know exactly how to terminate the persona.tools/cli/installers/lib/ide/templates/combined/claude-agent.md-10-17 (1)
10-17:⚠️ Potential issue | 🟡 MinorCircular reference and unexplained CRITICAL attribute.
Line 13 says "FOLLOW every step in the
<activation>section precisely," but this instruction is already inside an<agent-activation>section. Is it telling the agent to follow a different<activation>section in the external file loaded in step 1? If so, the naming collision is confusing.Additionally,
CRITICAL="TRUE"on line 10 looks like an XML attribute, but:
- Is this actually parsed by something, or just visual emphasis for humans?
- If parsed, what system handles it and what does it enforce?
- If not parsed, why use attribute syntax instead of a comment or Markdown bold?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/combined/claude-agent.md` around lines 10 - 17, Clarify the ambiguous reference and the CRITICAL attribute: change the ambiguous step that says "FOLLOW every step in the <activation> section precisely" to explicitly reference whether it means the activation section inside the loaded external file from step 1 (e.g., "FOLLOW every step in the external file's <activation> section") or a specific tag (use fully-qualified tag names like <agent-activation> vs <activation> to avoid collision), and update the README/inline text accordingly; also either remove or document the XML-like attribute CRITICAL="TRUE" on <agent-activation> by (a) replacing it with plain Markdown emphasis if it is only human-facing, or (b) adding a short note that specifies which parser/runtime reads CRITICAL="TRUE" and what behavior it enforces (and reference the attribute name CRITICAL="TRUE" in the docs), and ensure the LOAD step and the <agent-activation>/<activation> tags remain consistent after renaming so there is no circular naming confusion.tools/cli/installers/lib/ide/templates/workflow-command-template.md-5-6 (3)
5-6:⚠️ Potential issue | 🟡 MinorDefinition of "structured options" is ambiguous.
The RULE requires "structured options with a numbered list" but doesn't define what constitutes a properly structured question:
- Is "1. Option A\n2. Option B" acceptable?
- What about "1) Option A 2) Option B" (inline)?
- Are lettered lists allowed? "A. Option A\nB. Option B"
- Do options need to be on separate lines?
- Is indentation required?
- What about tool-specific formats (JSON schema for
AskUserQuestion, etc.)?Without a clear specification, agents may generate inconsistent formats, and users may not recognize questions as structured prompts. This is especially problematic if downstream parsing relies on a specific format.
📐 Define the structured format specification
RULE: When interaction_style is "structured", questions to the user MUST use structured options in one of these formats: FORMAT 1 (Numbered list - default): """ [Question text] 1. [Option 1 description] 2. [Option 2 description] 3. [Option 3 description] Please select an option (1-3): """ FORMAT 2 (Platform-specific tool): - Claude Code: Use AskUserQuestion tool with options array - Gemini: Use ask_user tool with choices parameter - OpenCode: Use question tool with options field FORMAT 3 (Inline numbered - for short options): """ [Question text] (1) [Short option 1] (2) [Short option 2] (3) [Short option 3] """ All formats MUST include an explicit prompt for the user to indicate their selection.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/workflow-command-template.md` around lines 5 - 6, Clarify and formalize the ambiguous RULE by specifying an exact permitted set of structured formats for interaction_style "structured": require either FORMAT 1 (default multi-line numbered list with each option on its own line and a trailing prompt like "Please select an option (1-N):"), FORMAT 2 (platform-specific tool usage: AskUserQuestion with options array for Claude Code, ask_user with choices for Gemini, question tool with options for OpenCode), or FORMAT 3 (inline numbered format allowed only for very short options, e.g. "(1) A (2) B", still ending with an explicit selection prompt); explicitly forbid ambiguous variants (lettered lists, inline runs without separators, missing prompt) and mandate that every structured prompt include an explicit selection instruction so downstream parsers can rely on either the numbered-list or the platform-specific tool fields (reference RULE, interaction_style, AskUserQuestion, ask_user, question tool).
5-6:⚠️ Potential issue | 🟡 MinorAmbiguous scope: which questions does this RULE apply to?
The RULE states "questions to the user MUST use structured options" but doesn't specify which questions are in scope:
- Does it apply to clarification questions during workflow execution?
- What about confirmation prompts ("Are you sure? [y/n]")?
- Does it apply to error recovery questions ("The file is missing. What should I do?")?
- What about meta-questions about the workflow itself ("Should I continue to the next step?")?
Some question types are inherently free-form (e.g., "What is your company name?"), while others are naturally structured (e.g., multiple-choice selections). The RULE doesn't distinguish between these cases, which could lead agents to awkwardly force structured formats where free-form is more appropriate.
📝 Clarify scope and provide examples
-RULE: When interaction_style is "structured", questions to the user MUST use structured options with a numbered list unless the workflow or user explicitly requests free-form input. +RULE: When interaction_style is "structured", multi-option questions to the user (e.g., choosing from alternatives, selecting next actions) MUST use structured options with a numbered list. Single-value inputs (e.g., "Enter project name") remain free-form unless the workflow provides predefined options. + +Examples: +✅ CORRECT (structured): + "Which testing framework? 1) Jest 2) Vitest 3) Mocha" + +✅ CORRECT (free-form when appropriate): + "What is your project name?" (free-form text input) + +❌ INCORRECT (forced structure): + "What is your project name? 1) Enter custom name 2) Use default"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/workflow-command-template.md` around lines 5 - 6, The RULE "When interaction_style is 'structured', questions to the user MUST use structured options" is ambiguous about which question types it covers; update the template text in workflow-command-template.md to explicitly enumerate in-scope and out-of-scope question types (e.g., in-scope: clarification questions, multi-choice selections, confirmation prompts that expect a discrete choice; out-of-scope: free-form content requests such as names, addresses, creative text, and user-provided file contents), add concise examples for each category (clarification question -> numbered options; confirmation prompt -> yes/no as structured options; error-recovery -> structured choices plus an "other" free-form fallback), and note that agents may offer a free-form fallback only when the workflow or user explicitly requests it or when the question semantically requires open input (reference the tokens interaction_style and "structured" from the RULE so reviewers can locate and replace the ambiguous sentence).
5-6:⚠️ Potential issue | 🟡 MinorAdd reference documentation for interaction_style variable in template.
The
interaction_stylevariable is defined insrc/core/module.yamlwith two valid values:"structured"(default) and"open", and it's loaded as a session variable from the config during initialization persrc/utility/agent-components/activation-steps.txt. However, this template file references the variable without explaining where it comes from or what values are possible, leaving new users confused about the context.Add a brief comment referencing the source:
Documentation reference
+<!-- interaction_style is loaded from config.yaml (see src/core/module.yaml for valid values: "structured" | "open") --> + RULE: When interaction_style is "structured", questions to the user MUST use structured options with a numbered list unless the workflow or user explicitly requests free-form input.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/ide/templates/workflow-command-template.md` around lines 5 - 6, The template references the session variable interaction_style but lacks documentation; update tools/cli/installers/lib/ide/templates/workflow-command-template.md to add a brief comment that documents interaction_style, noting its definition and valid values (structured (default) and open) and where it’s sourced (see src/core/module.yaml and loaded during initialization per src/utility/agent-components/activation-steps.txt); include a one-sentence example of expected behavior for "structured" (numbered options) vs "open" to guide template authors.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (38)
docs/how-to/install-bmad.mdsrc/utility/agent-components/activation-steps.txttools/cli/installers/lib/ide/platform-codes.yamltools/cli/installers/lib/ide/templates/agent-command-template.mdtools/cli/installers/lib/ide/templates/combined/antigravity.mdtools/cli/installers/lib/ide/templates/combined/claude-agent.mdtools/cli/installers/lib/ide/templates/combined/claude-agent.mdtools/cli/installers/lib/ide/templates/combined/claude-task.mdtools/cli/installers/lib/ide/templates/combined/claude-tool.mdtools/cli/installers/lib/ide/templates/combined/claude-workflow-yaml.mdtools/cli/installers/lib/ide/templates/combined/claude-workflow-yaml.mdtools/cli/installers/lib/ide/templates/combined/claude-workflow.mdtools/cli/installers/lib/ide/templates/combined/claude-workflow.mdtools/cli/installers/lib/ide/templates/combined/default-agent.mdtools/cli/installers/lib/ide/templates/combined/default-task.mdtools/cli/installers/lib/ide/templates/combined/default-tool.mdtools/cli/installers/lib/ide/templates/combined/default-workflow-yaml.mdtools/cli/installers/lib/ide/templates/combined/default-workflow.mdtools/cli/installers/lib/ide/templates/combined/gemini-agent.tomltools/cli/installers/lib/ide/templates/combined/gemini-task.tomltools/cli/installers/lib/ide/templates/combined/gemini-tool.tomltools/cli/installers/lib/ide/templates/combined/gemini-workflow-yaml.tomltools/cli/installers/lib/ide/templates/combined/gemini-workflow.tomltools/cli/installers/lib/ide/templates/combined/kiro-agent.mdtools/cli/installers/lib/ide/templates/combined/kiro-task.mdtools/cli/installers/lib/ide/templates/combined/kiro-tool.mdtools/cli/installers/lib/ide/templates/combined/kiro-workflow-yaml.mdtools/cli/installers/lib/ide/templates/combined/kiro-workflow.mdtools/cli/installers/lib/ide/templates/combined/opencode-agent.mdtools/cli/installers/lib/ide/templates/combined/opencode-task.mdtools/cli/installers/lib/ide/templates/combined/opencode-tool.mdtools/cli/installers/lib/ide/templates/combined/opencode-workflow-yaml.mdtools/cli/installers/lib/ide/templates/combined/opencode-workflow.mdtools/cli/installers/lib/ide/templates/combined/rovodev.mdtools/cli/installers/lib/ide/templates/combined/trae.mdtools/cli/installers/lib/ide/templates/combined/windsurf-workflow.mdtools/cli/installers/lib/ide/templates/workflow-command-template.mdtools/cli/installers/lib/ide/templates/workflow-commander.md
✅ Files skipped from review due to trivial changes (4)
- tools/cli/installers/lib/ide/templates/combined/claude-workflow-yaml.md
- tools/cli/installers/lib/ide/templates/combined/claude-agent.md
- tools/cli/installers/lib/ide/templates/combined/claude-workflow.md
- tools/cli/installers/lib/ide/templates/workflow-commander.md
🚧 Files skipped from review as they are similar to previous changes (16)
- tools/cli/installers/lib/ide/templates/combined/default-workflow.md
- tools/cli/installers/lib/ide/templates/combined/rovodev.md
- tools/cli/installers/lib/ide/templates/combined/default-task.md
- tools/cli/installers/lib/ide/templates/combined/default-workflow-yaml.md
- tools/cli/installers/lib/ide/templates/combined/opencode-agent.md
- tools/cli/installers/lib/ide/templates/combined/trae.md
- tools/cli/installers/lib/ide/templates/combined/kiro-agent.md
- tools/cli/installers/lib/ide/templates/combined/kiro-task.md
- tools/cli/installers/lib/ide/templates/combined/opencode-workflow-yaml.md
- tools/cli/installers/lib/ide/templates/combined/kiro-workflow.md
- tools/cli/installers/lib/ide/templates/combined/windsurf-workflow.md
- tools/cli/installers/lib/ide/templates/combined/gemini-agent.toml
- tools/cli/installers/lib/ide/templates/combined/opencode-tool.md
- tools/cli/installers/lib/ide/templates/combined/gemini-tool.toml
- tools/cli/installers/lib/ide/templates/agent-command-template.md
- tools/cli/installers/lib/ide/templates/combined/gemini-workflow.toml
|
Addressed all review comments, tested positive and negative use cases on claude and added screenshots. @bmadcode for your review. |
…tured question directives Add a new `interaction_style` config setting (open/structured) to module.yaml that controls how agents ask questions. When set to "structured", agents use numbered option lists; when "open" (default), they use natural conversation. Platform-specific templates for Claude Code use `AskUserQuestion` tool, Gemini uses `ask_user`, OpenCode uses `question` tool, and default/kiro/ other platforms use generic structured options. Changes: - Add interaction_style to src/core/module.yaml (between output_folder and tool_supports_subagents) - Add RULE directive to all 27+ IDE templates across 7 platforms - Add interaction_style to activation-rules, activation-steps, handlers, workflow.xml, and agent-command-header - Create dedicated Claude Code templates (claude-agent, claude-task, claude-tool, claude-workflow, claude-workflow-yaml) replacing symlinks - Add claude template_type to platform-codes.yaml - Update codex.js installer for claude support - Document interaction_style in install-bmad.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
sidtheone
force-pushed
the
feature/platform-specific-structured-interaction
branch
from
f096714 to
e2c0f86
Compare
|
Rebased to latest and fixed one remaining comment. |
|
coderabbitai please review |
|
Closing in favor of #1809, which proposes a more comprehensive compile-time approach to interaction mode configuration. That design better addresses the underlying problem (compile-pipeline support for different frameworks) rather than runtime RULE directives. Happy to help with the implementation if needed. |
1 participant
⏺ ## What
Adds a configurable
interaction_stylesetting and platform-specific structured question tool directives to all IDE slash command templates.Why
Agents were asking questions as plain text instead of using each platform's native structured question tool, resulting in a worse user experience. Each IDE has a different tool name (or none at all), so a
one-size-fits-all rule didn't work.
How
interaction_styleconfig option (structured/open) tomodule.yamland loaded it viaactivation-steps.txtAskUserQuestion(Claude Code),ask_user(Gemini),question(OpenCode), and "numbered option list" fallback for platformswithout a native tool (Kiro, Windsurf, Trae, Antigravity, RovoDev)
Testing
Installed from the branch into a fresh test project via
npx bmad-method@github:sidtheone/BMAD-METHOD#feature/platform-specific-structured-interaction installand verified the config prompt appears during setupand the correct tool name is present in generated slash commands.
Need help in tesing on other IDEs