chore(bmm): convert quick-dev workflow to native skill#1948
Conversation
🤖 Augment PR SummarySummary: This PR migrates the Changes:
Technical Notes: The migration aims to preserve existing step behavior while using path/name-only updates so the installer registers it as a skill rather than a workflow. 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| - Set `{execution_mode}` = "tech-spec" | ||
| - Set `{tech_spec_path}` = provided path | ||
| - **NEXT:** Read fully and follow: `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-03-execute.md` | ||
| - **NEXT:** Read fully and follow: `./steps/step-03-execute.md` |
There was a problem hiding this comment.
The step files now instruct loading ./steps/... even though they already live inside steps/, which can resolve to a non-existent steps/steps/... and also conflicts with the nextStepFile_* frontmatter values.
This likely breaks sequential navigation; consider making the NEXT directives consistent (e.g., sibling ./step-XX-...md within steps/, or consistently {installed_path}/steps/...). (Guideline: valid_step_references)
Severity: high
Other Locations
src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md:94src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md:117src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md:140src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-02-context-gathering.md:100src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-03-execute.md:92src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-04-self-check.md:92src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-05-adversarial-review.md:80
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
📝 WalkthroughWalkthroughThis PR restructures the Quick-Flow Quick-Dev workflow from Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 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)
📝 Coding Plan
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: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md (1)
37-50: 🛠️ Refactor suggestion | 🟠 MajorInconsistent path resolution styles create confusion and fragility.
Lines 42-44 reference related workflows using explicit absolute paths with
{project-root}, while line 50 references the first step using a relative path./steps/.... Within the same workflow file, you're mixing two completely different path resolution paradigms:
- Absolute style:
{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md- Relative style:
./steps/step-01-mode-detection.mdThis inconsistency makes it unclear which pattern is canonical and requires readers (and potentially the runtime) to track multiple resolution contexts. If the conversion to native skill means all internal references should be relative, why weren't the related workflows also converted? If absolute paths are still valid, why change the step references?
Consider standardizing on one path resolution style throughout the file, or add explicit documentation explaining when each style should be used.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md` around lines 37 - 50, The file mixes absolute `{project-root}` paths (e.g. `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md`, `{project-root}/_bmad/core/workflows/…`) and a relative step path (`./steps/step-01-mode-detection.md`), causing ambiguity; pick one canonical resolution style and apply it consistently: either convert the `Related Workflows` entries to relative paths from this file (e.g. adjust the three `{project-root}/...` references to the correct `../`/`./` relative locations) or change the `Read fully and follow: ./steps/step-01-mode-detection.md` line to use the `{project-root}` absolute pattern to match the others, and add a short comment at the top of the file stating the chosen convention; update all path strings (those exact quoted path literals) to the chosen style so every internal reference in this file follows the same resolution pattern.src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md (3)
89-100:⚠️ Potential issue | 🟡 MinorThe menu handling logic lacks enforcement of the "ALWAYS halt" requirement.
Lines 98-100 state:
- "ALWAYS halt and wait for user input after presenting menu"
- "ONLY proceed when user makes a selection"
But there's no mechanism shown that enforces this halt. The agent is trusted to follow the instruction, but there's no validation that:
- The agent actually stopped and waited
- The user actually made a valid selection (P or E)
- The agent didn't proceed with a default or assumed choice
If the agent misinterprets the instruction or if the runtime doesn't properly support blocking for user input, the workflow could silently skip the escalation decision and proceed incorrectly.
Document what the agent runtime's input-blocking mechanism is (e.g., does it emit a special marker that the IDE intercepts?), or add a post-condition check that verifies user_selection was captured before executing the IF P/E logic.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md` around lines 89 - 100, The menu lacks enforcement that the agent halts and captures a valid selection; add a runtime-blocking mechanism or an explicit post-condition check around the menu presentation so execution cannot continue until a valid user_selection (one of "P" or "E") is present; specifically, after displaying "**Select:** [P] Plan first (tech-spec) [E] Execute directly" ensure the runtime emits/awaits an input marker and then validate user_selection is set and matches /^(P|E)$/ before executing the IF branches that redirect to quick_spec_workflow or to step-02-context-gathering.md, and if validation fails loop back to prompt the user rather than proceeding.
67-80:⚠️ Potential issue | 🟠 MajorThe escalation trigger logic is under-specified and likely produces false negatives.
The escalation threshold (lines 67-80) requires "2+ signals present" from the trigger list, but:
The trigger list is illustrative, not exhaustive: The bullets are prefaced with generic examples like "Multiple components mentioned" without defining what counts as "multiple" or what constitutes a "component". Does "update the button and its tooltip" count as multiple components? Does "refactor the dashboard" count if it touches multiple files?
The "Reduces signal" list is asymmetric: Adding simplicity markers reduces signal strength, but there's no corresponding "Increases signal" mechanism for complexity markers. A request like "architect a new microservice with API gateway integration, database schema, and async worker queue" could also include the word "just" ("just need a new microservice..."), which would reduce signal and potentially prevent escalation despite obvious complexity.
No tie-breaker for exactly 2 signals: If exactly 2 trigger signals are present but 1+ reduction signal is also present, what happens? Does the reduction cancel one trigger, dropping below the 2-signal threshold?
"Holistic judgment" undercuts the 2-signal threshold: Line 81 says "Use holistic judgment, not mechanical keyword matching", which seems to contradict the mechanical "2+ signals present" rule. If judgment overrides the count, why have the count?
Refactor the escalation logic to either:
- Provide a clear scoring algorithm (triggers +1, reductions -1, total >= 2 → escalate)
- Remove the numeric threshold and use purely qualitative guidance ("If the request seems to span multiple systems or architectural layers, escalate")
- Add worked examples covering edge cases (e.g., "This counts as 3 signals", "This has 2 triggers but 2 reductions so no escalation")
5-6:⚠️ Potential issue | 🟡 MinorRemove unused frontmatter variables
nextStepFile_modeAandnextStepFile_modeBfrom lines 5–6.These variables are defined in the frontmatter but are never referenced by the execution logic or validated by any tooling. The actual NEXT directives at lines 53, 94, 117, 140, 153, and 154 hardcode step file paths directly (
./steps/step-03-execute.md,./steps/step-02-context-gathering.md) instead of consuming these metadata variables. Additionally, the frontmatter paths (./step-03-execute.md) do not match the actual paths used in the instructions (./steps/step-03-execute.md), making them misleading documentation. Remove these variables entirely to avoid confusion.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md` around lines 5 - 6, Remove the unused frontmatter variables nextStepFile_modeA and nextStepFile_modeB from the top of step-01-mode-detection.md; delete their declarations entirely and ensure no other code or tooling references them (search for nextStepFile_modeA/nextStepFile_modeB to confirm). Do not replace them with new values—keep the NEXT directives that already hardcode the correct paths (e.g., ./steps/step-03-execute.md and ./steps/step-02-context-gathering.md) so documentation matches execution. Update nothing else and ensure frontmatter remains valid YAML after removal.
🧹 Nitpick comments (7)
src/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md (1)
9-9: Config key name still reflects legacy workflow-path semantics.Consider renaming
quick_dev_workflowto something skill-oriented (quick_dev_skill) to prevent future path-coupled usage patterns.🤖 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-spec/workflow.md` at line 9, Rename the config key quick_dev_workflow to a skill-oriented name such as quick_dev_skill across the repo and update any code that reads or writes this key; specifically, change the key in the workflow.md entry (quick_dev_workflow: '{project-root}/_bmad/...') to quick_dev_skill and update any configuration loaders, validators, or consumers that reference quick_dev_workflow (search for the symbol quick_dev_workflow) so they now reference quick_dev_skill to avoid coupling the config name to a file path.src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-03-execute.md (1)
92-92: NEXT directive duplicates and diverges from frontmatter.Line 92 points to
./steps/step-04-self-check.md, but frontmatter already defines navigation vianextStepFile(Line 5). This split contract is fragile and can desynchronize behavior.Proposed fix
-When ALL tasks are complete (or halted on blocker), read fully and follow: `./steps/step-04-self-check.md`. +When ALL tasks are complete (or halted on blocker), read fully and follow: `{nextStepFile}`.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-03-execute.md` at line 92, The "NEXT" directive in the body duplicates and can diverge from the frontmatter navigation; remove or update the inline sentence "When ALL tasks are complete (or halted on blocker), read fully and follow: `./steps/step-04-self-check.md`" and instead rely on (or synchronize) the frontmatter key nextStepFile to control navigation (update nextStepFile if the intended target is different), ensuring only the frontmatter defines the next step and the markdown body contains no conflicting NEXT directive.src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-05-adversarial-review.md (1)
80-80: Use one canonical next-step reference here.Line 80 hardcodes
./steps/step-06-resolve-findings.md, while frontmatter already declaresnextStepFile(Line 5) as./step-06-resolve-findings.md. Keeping both forms invites routing drift between tooling and agent prompt flow.Proposed fix
-With findings in hand, read fully and follow: `./steps/step-06-resolve-findings.md` for user to choose resolution approach. +With findings in hand, read fully and follow: `{nextStepFile}` for user to choose resolution approach.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-05-adversarial-review.md` at line 80, The markdown contains a hardcoded next-step link './steps/step-06-resolve-findings.md' that conflicts with the frontmatter key nextStepFile which is './step-06-resolve-findings.md'; update the content in step-05-adversarial-review.md to use the canonical reference (either reference the frontmatter variable if the build supports it, or change the hardcoded link to './step-06-resolve-findings.md') so the link matches nextStepFile and avoids routing drift.src/bmm/agents/quick-flow-solo-dev.agent.yaml (1)
27-27: QD still targets a filesystem workflow path instead of the skill entrypoint.After converting quick-dev to a native skill, path-bound
execkeeps this agent coupled to directory layout changes. Route via the skill entry to keep this stable through future relocations.Based on learnings: “In BMAD-METHOD, agents and skills have a defined architectural relationship: agents are invoked via their skill entry point.”
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/agents/quick-flow-solo-dev.agent.yaml` at line 27, The agent's exec is hard-coded to a filesystem path ("{project-root}/_bmad/.../bmad-quick-dev/workflow.md"); update the exec field to invoke the skill entrypoint instead of a file path so the agent calls the native skill (e.g., replace the exec value with the skill entry reference for the quick-dev skill—use the repository's agent-to-skill invocation format to point at the bmad-quick-dev skill entrypoint such as bmad-quick-dev.<entrypoint> or the equivalent skill: bmad-quick-dev reference) so the agent is decoupled from directory layout changes.src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md (3)
153-154: Inconsistent capitalization in NEXT directive instructions undermines reliability.Line 153 uses lowercase "read fully and follow" while line 154 uses capitalized "Read fully and follow". If these are processing markers parsed by the agent runtime, inconsistent capitalization could cause one directive to be recognized and the other to be ignored, leading to unpredictable workflow progression.
If these are free-text instructions for the LLM agent (not parsed markers), the inconsistency is harmless but sloppy. Either way, standardize the capitalization.
Standardize directive capitalization
-- Mode A (tech-spec): "**NEXT:** read fully and follow: `./steps/step-03-execute.md`" +- Mode A (tech-spec): "**NEXT:** Read fully and follow: `./steps/step-03-execute.md`"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md` around lines 153 - 154, The two NEXT directives under Mode A (tech-spec) and Mode B (direct, [E] selected) use inconsistent capitalization ("read fully and follow" vs "Read fully and follow"); update both NEXT lines so the directive phrase is identical (for example, change both to "**NEXT:** Read fully and follow: `./steps/step-03-execute.md`" and "**NEXT:** Read fully and follow: `./steps/step-02-context-gathering.md`") to ensure the agent runtime/parser sees the same marker text.
53-53: The step reference pattern breaks if step files are reorganized or renamed.Lines 53, 153, and 154 hardcode step file names as string literals in NEXT directives. If the team decides to:
- Rename steps (e.g.,
step-03-execute.md→step-03-implementation.md)- Reorganize the directory structure (e.g., move steps to subdirectories)
- Merge or split steps (e.g., combine step-02 and step-03)
...every NEXT directive across all step files must be manually updated. There's no type safety, no link validation, and no automated refactoring support.
The frontmatter variables
nextStepFile_modeAandnextStepFile_modeBcould serve as a single source of truth, but they're unused. Alternatively, the workflow could use symbolic step names (e.g.,NEXT_STEP: execute) that map to file paths in a central configuration.Consider either:
- Using the frontmatter variables in the NEXT directive text (e.g., "Read fully and follow:
{nextStepFile_modeA}")- Adding a build-time validation that checks all hardcoded step references resolve to actual files
- Documenting that step file renames require a global search-and-replace across all NEXT directives
Also applies to: 153-154
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md` at line 53, The NEXT directives currently hardcode step filenames which breaks on renames; replace the string literals in the NEXT lines with the frontmatter variables nextStepFile_modeA and nextStepFile_modeB (e.g., "Read fully and follow: {nextStepFile_modeA}" / "{nextStepFile_modeB}") and ensure your markdown rendering/template pipeline performs variable interpolation for those frontmatter names; additionally add a small build-time validator that scans all NEXT directives and resolves the referenced frontmatter-derived paths to actual files to catch broken references during CI.
94-94: Excessive duplication of the step-02 reference path creates maintenance burden.The path
./steps/step-02-context-gathering.mdappears identically at lines 94, 117, 140, and 154. While the micro-file design pattern intentionally duplicates context for readability, duplicating the exact same path four times in a single file means any future refactoring (e.g., renaming step-02) requires finding and updating four identical string literals.The frontmatter already defines
nextStepFile_modeB: './step-02-context-gathering.md'(line 6) but that variable isn't used. If the frontmatter variable exists specifically to avoid this duplication, use it. If not, consider whether four hardcoded references to the same path in one file crosses the threshold from "self-contained readability" into "fragile maintenance burden."Either reference the frontmatter variable in the NEXT directives, or consolidate the duplication with a markdown reference-style link that can be reused.
Also applies to: 117-117, 140-140, 154-154
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md` at line 94, Replace the four hardcoded NEXT references to './steps/step-02-context-gathering.md' in step-01-mode-detection.md with the frontmatter variable nextStepFile_modeB (or a single markdown reference-style link) so they all source the path from one place; locate the NEXT directives (the lines containing "NEXT:" and the literal './steps/step-02-context-gathering.md') and update them to use nextStepFile_modeB (or change to a reference link defined once near the top that points to nextStepFile_modeB) to eliminate the duplicated string and ensure future renames only need a single change.
🤖 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/bmad-quick-flow/bmad-quick-dev/steps/step-02-context-gathering.md`:
- Line 100: The inline routing link "./steps/step-03-execute.md" in the body
should match the frontmatter key nextStepFile which is declared as
"./step-03-execute.md"; update either the frontmatter nextStepFile or the inline
link so both use the exact same path (prefer changing the body link
"./steps/step-03-execute.md" to "./step-03-execute.md") to eliminate routing
ambiguity and ensure step navigation is consistent across the file.
In
`@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-04-self-check.md`:
- Line 92: The step transition is duplicated: the frontmatter key nextStepFile
uses "./step-05-adversarial-review.md" while the body hardcodes a link
"./steps/step-05-adversarial-review.md"; pick one canonical source (prefer the
frontmatter nextStepFile) and update the hardcoded line in step-04-self-check.md
to match nextStepFile exactly (or vice versa), ensuring both reference the same
relative path string so parsers and prompts use a single source of truth.
In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md`:
- Line 37: The `installed_path` variable in the bmad-quick-dev workflow is
inconsistent and unused; either remove the `installed_path = "."` declaration
from the bmad-quick-dev workflow if it is not required, or restore it to the
standard explicit path pattern (e.g., `{project-root}/_bmad/...`) and update any
steps that should reference `{installed_path}` (mirroring how create-story uses
it for template.md, checklist.md, discover-inputs.md); if you intentionally keep
`"."`, add a short comment in the bmad-quick-dev workflow explaining why `"."`
is appropriate and when/where the value will be consumed.
In `@src/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md`:
- Line 9: The quick_dev_workflow entry currently hardcodes a post-conversion
filesystem path; replace this raw path value for the quick_dev_workflow key with
a skill-resolved reference (e.g., the skill identity/name or token used by your
skill registry) so callers resolve the native quick-dev skill rather than
depending on "{project-root}/_bmad/…/workflow.md"; if any consumer only accepts
paths, implement a small resolver function on that consumer side that maps the
quick_dev_workflow skill identity to the actual file path at runtime instead of
embedding filesystem paths in this workflow config.
---
Outside diff comments:
In
`@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md`:
- Around line 89-100: The menu lacks enforcement that the agent halts and
captures a valid selection; add a runtime-blocking mechanism or an explicit
post-condition check around the menu presentation so execution cannot continue
until a valid user_selection (one of "P" or "E") is present; specifically, after
displaying "**Select:** [P] Plan first (tech-spec) [E] Execute directly" ensure
the runtime emits/awaits an input marker and then validate user_selection is set
and matches /^(P|E)$/ before executing the IF branches that redirect to
quick_spec_workflow or to step-02-context-gathering.md, and if validation fails
loop back to prompt the user rather than proceeding.
- Around line 5-6: Remove the unused frontmatter variables nextStepFile_modeA
and nextStepFile_modeB from the top of step-01-mode-detection.md; delete their
declarations entirely and ensure no other code or tooling references them
(search for nextStepFile_modeA/nextStepFile_modeB to confirm). Do not replace
them with new values—keep the NEXT directives that already hardcode the correct
paths (e.g., ./steps/step-03-execute.md and
./steps/step-02-context-gathering.md) so documentation matches execution. Update
nothing else and ensure frontmatter remains valid YAML after removal.
In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md`:
- Around line 37-50: The file mixes absolute `{project-root}` paths (e.g.
`{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md`,
`{project-root}/_bmad/core/workflows/…`) and a relative step path
(`./steps/step-01-mode-detection.md`), causing ambiguity; pick one canonical
resolution style and apply it consistently: either convert the `Related
Workflows` entries to relative paths from this file (e.g. adjust the three
`{project-root}/...` references to the correct `../`/`./` relative locations) or
change the `Read fully and follow: ./steps/step-01-mode-detection.md` line to
use the `{project-root}` absolute pattern to match the others, and add a short
comment at the top of the file stating the chosen convention; update all path
strings (those exact quoted path literals) to the chosen style so every internal
reference in this file follows the same resolution pattern.
---
Nitpick comments:
In `@src/bmm/agents/quick-flow-solo-dev.agent.yaml`:
- Line 27: The agent's exec is hard-coded to a filesystem path
("{project-root}/_bmad/.../bmad-quick-dev/workflow.md"); update the exec field
to invoke the skill entrypoint instead of a file path so the agent calls the
native skill (e.g., replace the exec value with the skill entry reference for
the quick-dev skill—use the repository's agent-to-skill invocation format to
point at the bmad-quick-dev skill entrypoint such as bmad-quick-dev.<entrypoint>
or the equivalent skill: bmad-quick-dev reference) so the agent is decoupled
from directory layout changes.
In
`@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.md`:
- Around line 153-154: The two NEXT directives under Mode A (tech-spec) and Mode
B (direct, [E] selected) use inconsistent capitalization ("read fully and
follow" vs "Read fully and follow"); update both NEXT lines so the directive
phrase is identical (for example, change both to "**NEXT:** Read fully and
follow: `./steps/step-03-execute.md`" and "**NEXT:** Read fully and follow:
`./steps/step-02-context-gathering.md`") to ensure the agent runtime/parser sees
the same marker text.
- Line 53: The NEXT directives currently hardcode step filenames which breaks on
renames; replace the string literals in the NEXT lines with the frontmatter
variables nextStepFile_modeA and nextStepFile_modeB (e.g., "Read fully and
follow: {nextStepFile_modeA}" / "{nextStepFile_modeB}") and ensure your markdown
rendering/template pipeline performs variable interpolation for those
frontmatter names; additionally add a small build-time validator that scans all
NEXT directives and resolves the referenced frontmatter-derived paths to actual
files to catch broken references during CI.
- Line 94: Replace the four hardcoded NEXT references to
'./steps/step-02-context-gathering.md' in step-01-mode-detection.md with the
frontmatter variable nextStepFile_modeB (or a single markdown reference-style
link) so they all source the path from one place; locate the NEXT directives
(the lines containing "NEXT:" and the literal
'./steps/step-02-context-gathering.md') and update them to use
nextStepFile_modeB (or change to a reference link defined once near the top that
points to nextStepFile_modeB) to eliminate the duplicated string and ensure
future renames only need a single change.
In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-03-execute.md`:
- Line 92: The "NEXT" directive in the body duplicates and can diverge from the
frontmatter navigation; remove or update the inline sentence "When ALL tasks are
complete (or halted on blocker), read fully and follow:
`./steps/step-04-self-check.md`" and instead rely on (or synchronize) the
frontmatter key nextStepFile to control navigation (update nextStepFile if the
intended target is different), ensuring only the frontmatter defines the next
step and the markdown body contains no conflicting NEXT directive.
In
`@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-05-adversarial-review.md`:
- Line 80: The markdown contains a hardcoded next-step link
'./steps/step-06-resolve-findings.md' that conflicts with the frontmatter key
nextStepFile which is './step-06-resolve-findings.md'; update the content in
step-05-adversarial-review.md to use the canonical reference (either reference
the frontmatter variable if the build supports it, or change the hardcoded link
to './step-06-resolve-findings.md') so the link matches nextStepFile and avoids
routing drift.
In `@src/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md`:
- Line 9: Rename the config key quick_dev_workflow to a skill-oriented name such
as quick_dev_skill across the repo and update any code that reads or writes this
key; specifically, change the key in the workflow.md entry (quick_dev_workflow:
'{project-root}/_bmad/...') to quick_dev_skill and update any configuration
loaders, validators, or consumers that reference quick_dev_workflow (search for
the symbol quick_dev_workflow) so they now reference quick_dev_skill to avoid
coupling the config name to a file path.
🪄 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: 6eb49c29-a114-4fee-8fed-af5a6e919ffd
⛔ Files ignored due to path filters (1)
src/bmm/module-help.csvis excluded by!**/*.csv
📒 Files selected for processing (12)
src/bmm/agents/quick-flow-solo-dev.agent.yamlsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/SKILL.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/bmad-skill-manifest.yamlsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-01-mode-detection.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-02-context-gathering.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-03-execute.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-04-self-check.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-05-adversarial-review.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-06-resolve-findings.mdsrc/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev/bmad-skill-manifest.yamlsrc/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md
💤 Files with no reviewable changes (1)
- src/bmm/workflows/bmad-quick-flow/quick-dev/bmad-skill-manifest.yaml
| **CRITICAL:** When user confirms ready, explicitly state: | ||
|
|
||
| - **y:** "**NEXT:** Read fully and follow: `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-03-execute.md`" | ||
| - **y:** "**NEXT:** Read fully and follow: `./steps/step-03-execute.md`" |
There was a problem hiding this comment.
Routing instruction diverges from declared nextStepFile.
Line 100 uses ./steps/step-03-execute.md, while frontmatter already declares next-step routing as ./step-03-execute.md. This creates maintainability and execution ambiguity.
Proposed fix
-- **y:** "**NEXT:** Read fully and follow: `./steps/step-03-execute.md`"
+- **y:** "**NEXT:** Read fully and follow: `{nextStepFile}`"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-02-context-gathering.md`
at line 100, The inline routing link "./steps/step-03-execute.md" in the body
should match the frontmatter key nextStepFile which is declared as
"./step-03-execute.md"; update either the frontmatter nextStepFile or the inline
link so both use the exact same path (prefer changing the body link
"./steps/step-03-execute.md" to "./step-03-execute.md") to eliminate routing
ambiguity and ensure step navigation is consistent across the file.
| ## NEXT STEP | ||
|
|
||
| Proceed immediately to `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/steps/step-05-adversarial-review.md`. | ||
| Proceed immediately to `./steps/step-05-adversarial-review.md`. |
There was a problem hiding this comment.
Step transition path is duplicated in two incompatible forms.
Line 92 hardcodes ./steps/step-05-adversarial-review.md while frontmatter has nextStepFile set differently (./step-05-adversarial-review.md). Keep one source of truth to avoid parser/prompt mismatch.
Proposed fix
-Proceed immediately to `./steps/step-05-adversarial-review.md`.
+Proceed immediately to `{nextStepFile}`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Proceed immediately to `./steps/step-05-adversarial-review.md`. | |
| Proceed immediately to `{nextStepFile}`. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/step-04-self-check.md`
at line 92, The step transition is duplicated: the frontmatter key nextStepFile
uses "./step-05-adversarial-review.md" while the body hardcodes a link
"./steps/step-05-adversarial-review.md"; pick one canonical source (prefer the
frontmatter nextStepFile) and update the hardcoded line in step-04-self-check.md
to match nextStepFile exactly (or vice versa), ensuring both reference the same
relative path string so parsers and prompts use a single source of truth.
| ### Paths | ||
|
|
||
| - `installed_path` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev` | ||
| - `installed_path` = `.` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find all usages of installed_path variable to understand resolution context
# Search for installed_path references in workflow steps
rg -nP '\{installed_path\}' src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/
# Search for installed_path in the installer/agent runtime
rg -nP 'installed_path' tools/cli/
# Check if other skill-type workflows use "." pattern
fd -e md -x grep -l "^- \`installed_path\` = \`\.\`" {} \; src/bmm/workflows/Repository: bmad-code-org/BMAD-METHOD
Length of output: 446
🏁 Script executed:
#!/bin/bash
# Fixed script to find installed_path usage
echo "=== Searching for {installed_path} references in bmad-quick-dev workflow ==="
rg -nP '\{installed_path\}' src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/
echo ""
echo "=== Searching for installed_path in tools/cli ==="
rg -n 'installed_path' tools/cli/ | head -50
echo ""
echo "=== Checking installed_path values across all skill workflows ==="
rg -n 'installed_path.*=' src/bmm/workflows/ --type md | head -30
echo ""
echo "=== Finding the workflow.md file to inspect its content ==="
cat -n src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md | sed -n '30,45p'Repository: bmad-code-org/BMAD-METHOD
Length of output: 3297
🏁 Script executed:
#!/bin/bash
echo "=== Searching for variable consumption in installer/agent runtime ==="
rg -n 'installed_path' tools/ --type js --type ts -B2 -A2 | head -80
echo ""
echo "=== Checking how workflow variables are parsed and used ==="
rg -n 'UNRESOLVABLE_VARS|installed_path|project-root' tools/cli/installers/lib/ --type js | head -50
echo ""
echo "=== Checking if variables from workflow.md are used elsewhere ==="
rg -n 'variables|paths.*installed_path' src/ --type md | head -20
echo ""
echo "=== Looking at skill manifest generation to understand variable usage ==="
rg -n 'skill.*variables|getWorkflow|parseVariables' tools/cli/installers/lib/ --type js | head -40Repository: bmad-code-org/BMAD-METHOD
Length of output: 11062
🏁 Script executed:
#!/bin/bash
echo "=== Finding all {installed_path} references across entire codebase ==="
rg -rn '\{installed_path\}' src/ --type md | head -50
echo ""
echo "=== Looking at create-story workflow that references installed_path ==="
rg -B5 -A5 '\{installed_path\}' src/bmm/workflows/4-implementation/create-story/
echo ""
echo "=== Checking if installed_path is used in bmad-quick-dev steps ==="
ls -la src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/ 2>/dev/null | head -20
rg '\{installed_path\}' src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/ --type md
echo ""
echo "=== Understanding skill installation and path resolution ==="
rg -n 'installVerbatimSkills|installed.*skill|skill.*directory' tools/cli/installers/lib/ide/_config-driven.js -A3 -B1 | head -60Repository: bmad-code-org/BMAD-METHOD
Length of output: 13154
🏁 Script executed:
#!/bin/bash
echo "=== Comprehensive check for {installed_path} in bmad-quick-dev workflow and steps ==="
rg '\{installed_path\}' src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/ -A2 -B2
echo ""
echo "=== Checking all step files explicitly ==="
for file in src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/steps/*.md; do
echo "=== File: $(basename $file) ==="
grep -i 'installed_path\|{.*}' "$file" | head -5
done
echo ""
echo "=== Compare: checking create-story which DOES use installed_path ==="
echo "Number of {installed_path} references in create-story:"
rg '\{installed_path\}' src/bmm/workflows/4-implementation/create-story/ --type md | wc -l
echo ""
echo "=== Check the actual workflow.md content around line 37 in bmad-quick-dev ==="
sed -n '30,50p' src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.mdRepository: bmad-code-org/BMAD-METHOD
Length of output: 2875
🏁 Script executed:
#!/bin/bash
# One final check: is installed_path used by framework code for any workflow?
echo "=== Checking if framework interprets/consumes installed_path from workflow metadata ==="
rg -n 'installed_path' tools/cli/installers/lib/ --type js -B2 -A2 | head -40Repository: bmad-code-org/BMAD-METHOD
Length of output: 156
Inconsistent and apparently unused installed_path declaration.
The installed_path = "." value breaks the established pattern: all 14+ other workflows declare installed_path with an explicit {project-root}/_bmad/... path. More critically, {installed_path} is not referenced anywhere in the bmad-quick-dev workflow steps—whereas other workflows like create-story use it 6+ times to resolve local files (template.md, checklist.md, discover-inputs.md).
The variable appears to be unused metadata, yet its value has been changed from an explicit absolute path to a bare .. This suggests either incomplete refactoring or deferred usage that requires clarification. If this variable is truly not needed for this workflow, remove the declaration. If it's intentionally deferred, document why . is the appropriate value and when it will be consumed.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md` at line 37, The
`installed_path` variable in the bmad-quick-dev workflow is inconsistent and
unused; either remove the `installed_path = "."` declaration from the
bmad-quick-dev workflow if it is not required, or restore it to the standard
explicit path pattern (e.g., `{project-root}/_bmad/...`) and update any steps
that should reference `{installed_path}` (mirroring how create-story uses it for
template.md, checklist.md, discover-inputs.md); if you intentionally keep `"."`,
add a short comment in the bmad-quick-dev workflow explaining why `"."` is
appropriate and when/where the value will be consumed.
| advanced_elicitation: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md' | ||
| party_mode_exec: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md' | ||
| quick_dev_workflow: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md' | ||
| quick_dev_workflow: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md' |
There was a problem hiding this comment.
quick_dev_workflow still hardcodes internal file layout post-conversion.
Now that quick-dev is a native skill, Line 9 should resolve via skill identity rather than a raw workflow path. This path already changed once in this PR; keeping it path-bound invites repeat breakage.
Proposed direction
-quick_dev_workflow: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev/workflow.md'
+quick_dev_workflow: 'skill:bmad-quick-dev'If this key is consumed by a path-only caller, then introduce a resolver layer there rather than hardcoding filesystem paths in workflow config.
🤖 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-spec/workflow.md` at line 9, The
quick_dev_workflow entry currently hardcodes a post-conversion filesystem path;
replace this raw path value for the quick_dev_workflow key with a skill-resolved
reference (e.g., the skill identity/name or token used by your skill registry)
so callers resolve the native quick-dev skill rather than depending on
"{project-root}/_bmad/…/workflow.md"; if any consumer only accepts paths,
implement a small resolver function on that consumer side that maps the
quick_dev_workflow skill identity to the actual file path at runtime instead of
embedding filesystem paths in this workflow config.
alexeyv
force-pushed
the
convert-quick-dev-skill
branch
from
1944489 to
6609667
Compare
…#1948) * chore(bmm): convert quick-dev workflow to native skill package * fix(bmm): normalize quick-dev skill references * fix(bmm): remove duplicate quick-dev workflow metadata * fix(bmm): inline quick-dev skill handoff references
* chore(bmm): convert quick-dev workflow to native skill package * fix(bmm): normalize quick-dev skill references * fix(bmm): remove duplicate quick-dev workflow metadata * fix(bmm): inline quick-dev skill handoff references
1 participant
Summary
quick-devfrom workflow package to nativetype: skillquick-dev->bmad-quick-devSKILL.md, switched manifest totype: skill, and preserved workflow/step behavior with path/name-only updatessrc/bmm/module-help.csv(workflow-file->skill:bmad-quick-dev)src/bmm/agents/quick-flow-solo-dev.agent.yaml(new workflow path)src/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md(new quick-dev path)Validation
workflow.mdstep-01throughstep-06)node tools/cli/bmad-cli.js install --directory /Users/alex/src/bmad --modules bmm --tools claude-code --yes.claude/skills/bmad-quick-dev/contains workflow + step files + generatedSKILL.md_bmad/_config/skill-manifest.csvincludesbmad-quick-dev_bmad/_config/workflow-manifest.csvhas nobmad-quick-deventrynpm testEquivalence protocol note
_bmad-output/implementation-artifacts/deferred-work.mdwith completed mechanical equivalence checks