feat: add platform capability flags for conditional workflow execution#1897
feat: add platform capability flags for conditional workflow execution#1897Dynokostya wants to merge 3 commits intobmad-code-org:mainfrom
Conversation
Add capabilities schema (sub_agents, task_tracking, structured_ask) to
platform-codes.yaml for all 21 platforms. Capabilities are persisted to
_config/ides/{platform}.yaml at install time.
Update quick-dev step-03-execute and dev-story workflow to conditionally
use agent delegation and task tracking when the platform supports them,
falling back to direct implementation otherwise.
Currently only Claude Code has all capabilities enabled. Other platforms
default to false and should be updated as their capabilities are verified.
|
Worth noting: most BMAD users run Claude Code since it has the strongest coding models, so this feature will be immediately beneficial for the majority of the user base. The capability flags infrastructure is ready for other platforms to opt in as they add similar tooling — just a one-line change in |
📝 WalkthroughWalkthroughThis PR introduces a capability-driven execution model for workflows and IDE configuration. It adds a capabilities metadata structure (sub_agents, task_tracking, structured_ask) to platform definitions, persists capabilities through IDE configuration, and extends workflows to conditionally enable task tracking registration and agent delegation based on available capabilities. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 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: 1
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/core/ide-config-manager.js (1)
119-125:⚠️ Potential issue | 🟡 Minor
loadAllIdeConfigsreturns onlyconfiguration, notcapabilities.The
saveIdeConfigmethod now persists capabilities alongside configuration, butloadAllIdeConfigs(line 124) returns onlyconfig.configuration. This means callers usingloadAllIdeConfigswon't have access to the capabilities block.If any code path needs to load capabilities for all IDEs (e.g., to refresh or compare capabilities during updates), it would need to call
loadIdeConfigfor each IDE individually.Consider whether
loadAllIdeConfigsshould return the full config object or a structure that includes capabilities:if (config) { - configs[ideName] = config.configuration; + configs[ideName] = { + configuration: config.configuration, + capabilities: config.capabilities, + }; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/installers/lib/core/ide-config-manager.js` around lines 119 - 125, loadAllIdeConfigs currently only stores config.configuration, dropping the capabilities saved by saveIdeConfig; update loadAllIdeConfigs (the loop that calls loadIdeConfig and populates configs) to store the full loaded object (or an explicit {configuration, capabilities} shape) for each ideName instead of only config.configuration, and ensure any callers that expect the old shape are updated to read configuration from the new object (or adapt to the new structure); reference the methods loadAllIdeConfigs, loadIdeConfig and saveIdeConfig when making the change.
🧹 Nitpick comments (1)
src/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-03-execute.md (1)
44-49: TaskCreate/TaskUpdate assumed but not defined.The REGISTER TASKS section references
TaskCreateandTaskUpdatetools without specifying their API or fallback if the tools don't exist. Ifcapabilities.task_trackingis true but the tools are unavailable (misconfiguration), the workflow would fail.Consider adding validation or fallback:
If `{capabilities.task_tracking}` available: Register all identified tasks... +Verify the TaskCreate tool is accessible before attempting registration; if unavailable, fall back to document checkboxes.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-03-execute.md` around lines 44 - 49, The REGISTER TASKS section assumes TaskCreate and TaskUpdate exist when capabilities.task_tracking is true; add a validation and fallback: check that TaskCreate and TaskUpdate handlers (or their client objects) are present before using them, and if missing, log a clear warning and fall back to the document-checkbox progress method or create an in-memory/task-buffer queue. Update the code paths around capabilities.task_tracking, TaskCreate, and TaskUpdate to perform this presence check and graceful fallback so the workflow won’t throw if the task-tracking tools are misconfigured.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/bmm/workflows/4-implementation/dev-story/workflow.md`:
- Around line 291-296: The agent discovery path is hardcoded to
".claude/agents/" in the "Agent Selection" step; update the workflow to
parameterize the discovery location based on the detected IDE or capability
instead of a fixed path. Use the existing capability key
(capabilities.sub_agents) or introduce a new capability like
capabilities.agent_paths to map IDE identifiers (e.g., "claude" ->
".claude/agents/", "cursor" -> ".cursor/agents/") and change the actions that
"Identify target file types and task domain" and "Check for a specialized agent
in .claude/agents/" to consult that capability mapping at runtime and fall back
to a general-purpose agent when no mapping or match is found.
---
Outside diff comments:
In `@tools/cli/installers/lib/core/ide-config-manager.js`:
- Around line 119-125: loadAllIdeConfigs currently only stores
config.configuration, dropping the capabilities saved by saveIdeConfig; update
loadAllIdeConfigs (the loop that calls loadIdeConfig and populates configs) to
store the full loaded object (or an explicit {configuration, capabilities}
shape) for each ideName instead of only config.configuration, and ensure any
callers that expect the old shape are updated to read configuration from the new
object (or adapt to the new structure); reference the methods loadAllIdeConfigs,
loadIdeConfig and saveIdeConfig when making the change.
---
Nitpick comments:
In `@src/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-03-execute.md`:
- Around line 44-49: The REGISTER TASKS section assumes TaskCreate and
TaskUpdate exist when capabilities.task_tracking is true; add a validation and
fallback: check that TaskCreate and TaskUpdate handlers (or their client
objects) are present before using them, and if missing, log a clear warning and
fall back to the document-checkbox progress method or create an
in-memory/task-buffer queue. Update the code paths around
capabilities.task_tracking, TaskCreate, and TaskUpdate to perform this presence
check and graceful fallback so the workflow won’t throw if the task-tracking
tools are misconfigured.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 249b1f79-d752-4d59-8116-fc0aade3c93c
📒 Files selected for processing (5)
src/bmm/workflows/4-implementation/dev-story/workflow.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-03-execute.mdtools/cli/installers/lib/core/ide-config-manager.jstools/cli/installers/lib/core/installer.jstools/cli/installers/lib/ide/platform-codes.yaml
| <check if="{capabilities.sub_agents} is available"> | ||
| <!-- Agent Selection --> | ||
| <action>Identify target file types and task domain for the current task/subtask</action> | ||
| <action>Check for a specialized agent in .claude/agents/ (or IDE equivalent) whose description matches the target file types and task domain</action> | ||
| <action>If no specialized agent matches, use a general-purpose agent as fallback</action> | ||
|
|
There was a problem hiding this comment.
Agent discovery path hardcoded to .claude/agents/.
The agent selection step specifies checking .claude/agents/ for specialized agents. This is Claude-specific and won't work for other IDEs that may have agents in different locations (e.g., .cursor/agents/).
If this workflow should support capability-driven execution across multiple IDEs, the agent discovery path should be parameterized based on the detected IDE:
- <action>Check for a specialized agent in .claude/agents/ (or IDE equivalent) whose description matches the target file types and task domain</action>
+ <action>Check for a specialized agent in the current IDE's agents directory (e.g., .{ide}/agents/) whose description matches the target file types and task domain</action>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/bmm/workflows/4-implementation/dev-story/workflow.md` around lines 291 -
296, The agent discovery path is hardcoded to ".claude/agents/" in the "Agent
Selection" step; update the workflow to parameterize the discovery location
based on the detected IDE or capability instead of a fixed path. Use the
existing capability key (capabilities.sub_agents) or introduce a new capability
like capabilities.agent_paths to map IDE identifiers (e.g., "claude" ->
".claude/agents/", "cursor" -> ".cursor/agents/") and change the actions that
"Identify target file types and task domain" and "Check for a specialized agent
in .claude/agents/" to consult that capability mapping at runtime and fall back
to a general-purpose agent when no mapping or match is found.
Replace hardcoded .claude/agents/ references with generic phrasing that uses the IDE's own agents directory, keeping .claude/agents/ only as an example.
|
Re: agent discovery path hardcoded to Re: In practice there's no gap: workflows read the YAML file directly at runtime and get the full object including |
|
@Dynokostya I like this idea, not sure we want to maintain it though - I have a skill coming soon called bmad-init or something similar that every workflow will call at the start, and pulling in tool capabilities also at that time is a great idea, then as we are converting to skills there will be common language or phrasing that can exist and progressive disclosure to different prompts based on capabilities. |
2 participants
What
Add a platform capabilities system that allows BMAD workflows to adapt behavior based on what the IDE/CLI tool supports — specifically sub-agent delegation, task tracking, and structured user prompting.
Why
BMAD supports 20+ IDE platforms, but implementation workflows (quick-dev, dev-story) previously had no way to leverage advanced platform features like sub-agent delegation or task tracking. This meant workflows either used platform-specific features (breaking other platforms) or avoided them entirely (leaving capabilities on the table).
This was targeted mainly for Claude Code which currently has the richest tool support. Other coding tools should explore adding
capabilitiessupport as their platforms evolve — the infrastructure is ready, just flip the flags inplatform-codes.yaml.Fixes #1898
How
capabilitiesschema toplatform-codes.yamlwith three flags per platform:sub_agents,task_tracking,structured_askfalse(conservative — expand as verified)_config/ides/{platform}.yamlat install time viaide-config-manager.jsquick-dev/step-03-execute.md: loads capabilities, conditionally registers tasks, uses orchestrator pattern (agent delegation) whensub_agentsavailable, falls back to direct implementationdev-story/workflow.md: step 4 conditionally registers tasks, step 5 conditionally delegates to agents or implements directly with red-green-refactorTesting