feat(quick-flow): add quick-dev2 unified workflow#1807
Merged
bmadcode merged 5 commits intobmad-code-org:mainfrom Mar 3, 2026
Merged
feat(quick-flow): add quick-dev2 unified workflow#1807bmadcode merged 5 commits intobmad-code-org:mainfrom
bmadcode merged 5 commits intobmad-code-org:mainfrom
Conversation
Add the quick-dev2 workflow that unifies clarify, plan, implement, review, and present into a single flow. Register it in the agent menu, module-help catalog, and test fixtures.
🤖 Augment PR SummarySummary: Adds an experimental Changes:
Technical Notes: QD2 relies on spec frontmatter state transitions ( 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
src/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-04-review.md
Outdated
Show resolved
Hide resolved
📝 WalkthroughWalkthroughThis PR introduces the Quick Dev 2 workflow feature to the BMM system, adding a new agent menu entry and implementing a complete 5-step end-to-end workflow (clarify intent, plan, implement, review, present) with supporting templates and orchestration configuration. Changes
Sequence DiagramsequenceDiagram
participant User
participant Agent
participant Step1 as Step 1:<br/>Clarify & Route
participant Step2 as Step 2:<br/>Plan
participant Step3 as Step 3:<br/>Implement
participant Step4 as Step 4:<br/>Review
participant Step5 as Step 5:<br/>Present
participant VCS
User->>Agent: Trigger QD2 workflow with intent
Agent->>Step1: Load and execute clarify-and-route
Step1->>Step1: Q&A loop to clarify intent
Step1->>Step1: Version control & multi-goal check
Step1->>Step1: Generate spec_file path
alt One-shot mode
Step1->>Step3: Route to implement
else Plan-code-review mode
Step1->>Step2: Route to plan
Step2->>Step2: Create structured plan
Step2->>Step3: Proceed to implement
end
Step3->>Step3: Execute implementation
Step3->>Step4: Complete & route to review
Step4->>Step4: Adversarial review & findings
alt Issues found
Step4->>Step2: Loopback for refinement
else No issues
Step4->>Step5: Approve & proceed
end
Step5->>VCS: Create conventional commit
Step5->>User: Present results & commit hash
Step5->>Agent: Mark workflow complete
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 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)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). 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: 10
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/bmm/agents/quick-flow-solo-dev.agent.yaml (1)
22-32:⚠️ Potential issue | 🟡 MinorFix key usage inconsistency: lines 27 and 31 should use
exec:instead ofworkflow:for Markdown workflows.The codebase establishes a semantic distinction:
exec:is used for Markdown workflow files (.md), whileworkflow:is used for YAML workflow files (.yaml). Line 23 correctly usesexec:for a .md file, but lines 27 and 31 incorrectly useworkflow:for .md files. Line 35 is correct, usingworkflow:for a .yaml file. Update lines 27 and 31 to useexec:to match both the pattern in line 23 and the broader codebase convention.🤖 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` around lines 22 - 32, Change the two entries that use workflow: for Markdown workflows to use exec: instead — specifically update the trigger entries for "QD" (quick-dev) and "QD2" (quick-dev2) to replace workflow: with exec: so their .md paths are invoked the same way as the "QS" (quick-spec) entry; ensure the keys read exec: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md" and exec: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev2/workflow.md" respectively to match the .md convention.
🧹 Nitpick comments (2)
src/bmm/workflows/bmad-quick-flow/quick-dev2/tech-spec-template.md (1)
1-7: Missingbaseline_commitfield in frontmatter.step-03-implement.md (line 23) writes
baseline_committo spec_file frontmatter, and step-04-review.md (line 24) reads it. But this template doesn't includebaseline_commitin its frontmatter schema.While agents can add fields dynamically, documenting expected runtime fields in the template improves clarity and helps humans understand the complete spec structure.
Proposed addition
status: 'draft' # draft | ready-for-dev | in-progress | in-review | done context: [] # optional: max 3 project-wide standards/docs. NO source code files. +baseline_commit: '' # populated at implementation start (plan-code-review mode) +specLoopIteration: 1 # review loop counter, max 5 ---🤖 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-dev2/tech-spec-template.md` around lines 1 - 7, Add the missing baseline_commit frontmatter field to the tech-spec template so the spec_file frontmatter matches what step-03-implement.md writes and step-04-review.md expects; update the frontmatter block in quick-dev2/tech-spec-template.md to include a baseline_commit: '' (or null) entry alongside title, type, created, status, and context to document the runtime field and make the expected spec structure explicit.src/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-01-clarify-and-route.md (1)
50-51: Conflated routing paths in NEXT section."One-shot / ready-for-dev" combines two semantically different scenarios:
- One-shot: New work with zero blast radius (no spec exists yet)
- ready-for-dev: Resuming an existing spec that already went through planning
These have different preconditions and state. Lumping them together obscures intent and could cause agents to skip required initialization when resuming vs. starting fresh.
🤖 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-dev2/steps/step-01-clarify-and-route.md` around lines 50 - 51, The NEXT section conflates "One-shot" and "ready-for-dev"; split them into two distinct routing lines so each scenario hits the correct preconditions: route "One-shot" (new work with no spec) to follow `{installed_path}/steps/step-02-plan.md` and route "ready-for-dev" (resuming an existing, already-planned spec) to follow `{installed_path}/steps/step-03-implement.md`, keeping the existing "Plan-code-review" line unchanged otherwise.
🤖 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/quick-dev2/steps/step-01-clarify-and-route.md`:
- Around line 21-24: The step file step-01-clarify-and-route.md conflicts with
the global rule "NEVER skip steps or optimize the sequence" in workflow.md
because it tells agents to "skip to step 3" / "skip to step 4"; remove the
explicit "skip to step X" instructions and instead set spec_file and
execution_mode as indicated (use the existing symbols spec_file, execution_mode,
and {implementation_artifacts}) and mark a resume flag (e.g., resume_from_spec =
true) so downstream steps can detect a resume and fast-track behavior internally
while still executing each step in order; alternatively, if you prefer the
shortcut behavior, update workflow.md to add an explicit exception allowing
resume shortcuts for artifact-based resumes—pick one approach and make the
change consistently so the two documents no longer contradict each other.
- Line 29: The workflow references an uninitialized variable
`{planning_artifacts}` in step-01-clarify-and-route.md; update the quick-dev2
workflow's configuration loading block (the same place that reads project_name,
implementation_artifacts, user_name, etc.) to also initialize
planning_artifacts. Add a planning_artifacts variable (defaulting to the same
shape used in quick-spec/quick-dev) alongside implementation_artifacts and
ensure any downstream uses in the quick-dev2 flow (e.g.,
step-01-clarify-and-route.md) read from this newly initialized
planning_artifacts.
In `@src/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-02-plan.md`:
- Around line 21-23: The references to "READY FOR DEVELOPMENT standard" and
"SCOPE STANDARD" in step-02-plan.md conflict with the Just-In-Time Loading rule
in workflow.md; update the workflow so Step 2 can access those standards by
either inlining the full texts of the READY FOR DEVELOPMENT and SCOPE STANDARD
into src/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-02-plan.md (replace
the references on the lines that mention those standards) or modify workflow.md
to explicitly state that workflow-level standards remain loaded for all steps
(add a clear "persistent context" clause and list the standards to keep in
memory), and ensure the step text references the chosen approach (e.g., "see
below" if inlined or "persistently loaded per workflow.md" if persistent).
In `@src/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-03-implement.md`:
- Line 17: The precondition in step-03 checking that {spec_file} exists on disk
fails for the one-shot path because step-01 only generates the path and step-02
(skipped) creates the file; update the precondition logic (in the
precondition/check routine for step-03) to first inspect execution_mode and only
require the on-disk file when execution_mode != "one-shot", otherwise allow a
missing file or trigger creation; alternatively implement creation of a minimal
spec file in the step-01 routine when execution_mode == "one-shot" or bypass the
existence check when execution_mode == "one-shot" — reference the precondition
check that validates {spec_file}, the execution_mode flag, and the related steps
step-01 and step-02 when making the change.
- Line 29: The doc currently says `execution_mode = "one-shot"` should
"implement the intent" but doesn't state where to read the captured intent from;
update step-03-implement.md to explicitly specify the intent source (either
persist the user intent from step-01 into a known artifact or instruct the agent
to re-capture it). For a concrete fix, add a sentence instructing one-shot runs
to read the intent from a persisted file (e.g., intents/intent.json) or from a
recorded conversation context saved after step-01, and mention the expected
schema/name so the implementation (functions that load intents or the agent boot
sequence) can reliably locate it. Ensure references to `execution_mode`,
"one-shot", and step-01 conversation context are included so implementers know
to either persist via a capture_intent routine or re-use the stored conversation
artifact.
In `@src/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-04-review.md`:
- Line 30: The one-shot path references `{adversarial_review_task}` and "changed
files" but lacks a way to identify diffs because `baseline_commit` may be
absent; update the one-shot flow in step-04 to either (a) require that step-03
records a list of touched files (e.g., emit a `touched_files` artifact) which
the `{adversarial_review_task}` subagent consumes, or (b) modify the instruction
to compute changes by comparing the current workspace to an explicit provided
baseline path/manifest or by using filesystem timestamps/patch generation when
no VCS is present; ensure the doc mentions `baseline_commit`, `step-03`, and
`{adversarial_review_task}` so implementers know where to wire the touched files
into the subagent invocation.
- Around line 47-49: The specLoopIteration counter in step-04-review.md is only
initialized in the frontmatter and never persisted across loopbacks; modify the
loopback flow so that whenever `{specLoopIteration}` is incremented you write
the new value back into the spec frontmatter in `{spec_file}` (update the
frontmatter key), ensure the agent reloads `{spec_file}` frontmatter on step
restart so the incremented value is read, and keep the existing max-5 check to
HALT/escalate when the persisted `{specLoopIteration}` exceeds 5; reference
`specLoopIteration`, `step-04-review.md`, and `{spec_file}` when implementing
the persistence.
In `@src/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-05-present.md`:
- Around line 15-17: The step assumes {spec_file} exists and will fail for
one-shot runs; either create a minimal spec earlier (in step-01 or step-03) or
add conditional logic in the code that renders step-05-present.md to detect
absence of {spec_file} and skip the frontmatter update and title-derived commit
steps. Concretely, update the workflow rendering/handler that executes
"step-05-present" to check for the presence of the spec path/metadata (the
{spec_file} variable) before performing: 1) the frontmatter status change, 2)
deriving the commit message from the spec title, and 3) showing a commit hash;
if missing, produce an alternate summary that explains no spec was created and
offers push/PR options without referencing spec file or title. Ensure the check
references the same variable name used in the diff ({spec_file}) so behavior is
correct for both normal and one-shot flows.
In `@src/bmm/workflows/bmad-quick-flow/quick-dev2/workflow.md`:
- Line 77: The glob `**/project-context.md` used for `project_context` is
ambiguous; update the workflow to be deterministic by either pointing
`project_context` to a single explicit path (e.g., `./project-context.md` or the
repo-root path) or by changing the spec to explicitly define behavior when
multiple matches occur (e.g., "collect all matches, sort by path, and
concatenate" or "use the first match sorted lexicographically"); apply this
change where `project_context` is defined so the loader for project_context will
have a clear, reproducible rule.
- Around line 84-87: The workflow defines duplicate variables (installed_path,
templateFile, wipFile) that are also redeclared in the step frontmatter causing
drift; centralize these in the workflow-level definitions by keeping
installed_path/templateFile/wipFile only where they are currently declared and
remove their redeclaration from the step frontmatter, then update the step
content to reference the workflow-level variables (e.g., use templateFile and
wipFile from the workflow scope rather than redeclaring them) so steps inherit
the values instead of overriding them.
---
Outside diff comments:
In `@src/bmm/agents/quick-flow-solo-dev.agent.yaml`:
- Around line 22-32: Change the two entries that use workflow: for Markdown
workflows to use exec: instead — specifically update the trigger entries for
"QD" (quick-dev) and "QD2" (quick-dev2) to replace workflow: with exec: so their
.md paths are invoked the same way as the "QS" (quick-spec) entry; ensure the
keys read exec:
"{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md" and
exec:
"{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev2/workflow.md"
respectively to match the .md convention.
---
Nitpick comments:
In
`@src/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-01-clarify-and-route.md`:
- Around line 50-51: The NEXT section conflates "One-shot" and "ready-for-dev";
split them into two distinct routing lines so each scenario hits the correct
preconditions: route "One-shot" (new work with no spec) to follow
`{installed_path}/steps/step-02-plan.md` and route "ready-for-dev" (resuming an
existing, already-planned spec) to follow
`{installed_path}/steps/step-03-implement.md`, keeping the existing
"Plan-code-review" line unchanged otherwise.
In `@src/bmm/workflows/bmad-quick-flow/quick-dev2/tech-spec-template.md`:
- Around line 1-7: Add the missing baseline_commit frontmatter field to the
tech-spec template so the spec_file frontmatter matches what
step-03-implement.md writes and step-04-review.md expects; update the
frontmatter block in quick-dev2/tech-spec-template.md to include a
baseline_commit: '' (or null) entry alongside title, type, created, status, and
context to document the runtime field and make the expected spec structure
explicit.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
src/bmm/module-help.csvis excluded by!**/*.csvtest/fixtures/agent-schema/valid/menu-triggers/compound-triggers.agent.yamlis excluded by!test/fixtures/**
📒 Files selected for processing (8)
src/bmm/agents/quick-flow-solo-dev.agent.yamlsrc/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-01-clarify-and-route.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-02-plan.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-03-implement.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-04-review.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev2/steps/step-05-present.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev2/tech-spec-template.mdsrc/bmm/workflows/bmad-quick-flow/quick-dev2/workflow.md
src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-01-clarify-and-route.md
Show resolved
Hide resolved
src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-01-clarify-and-route.md
Show resolved
Hide resolved
src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-02-plan.md
Show resolved
Hide resolved
src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-03-implement.md
Show resolved
Hide resolved
src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-03-implement.md
Show resolved
Hide resolved
src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-04-review.md
Show resolved
Hide resolved
src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-04-review.md
Show resolved
Hide resolved
src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-05-present.md
Show resolved
Hide resolved
bmadcode
requested changes
Mar 2, 2026
COMPOUND_TRIGGER_PATTERN only allows uppercase letters in shortcuts. Rename to QQ so quick-dev2 passes agent schema validation.
- step-04-review: fix copy-paste fallback text to say "perform all three reviews inline sequentially" instead of "implement directly" - workflow.md: add missing planning_artifacts to initialization list, matching quick-spec and quick-dev siblings - quick-flow-solo-dev.agent.yaml: change QD and QQ menu entries from workflow: to exec: for .md files, matching the exec-for-md convention
Contributor
Author
|
@- |
…bagents Sequential inline reviews in the same context suffer from anchoring bias and context blowout. Instead, generate separate review prompt files and ask the human to run each in a separate session.
Rename directory, update all references in agent menu, module-help, and workflow internals.
Contributor
Author
|
good to go, I think |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Test plan
QD2trigger launches the quick-dev2 workflow via the agent menu