4.8 KiB
| title | description | sidebar | ||
|---|---|---|---|---|
| Quick Dev New Preview | Unified quick workflow that clarifies, plans, implements, reviews, and hands off in one run |
|
Use bmad-quick-dev-new-preview when you want one workflow to carry a change from raw intent to reviewed code without bouncing between separate planning and implementation skills.
This is the experimental unified version of Quick Flow. Instead of running bmad-quick-spec and bmad-quick-dev as separate phases, you start once and the workflow decides whether to plan first or go straight to implementation.
When to Use It
- You have one concrete development goal and want the workflow to manage the handoffs
- You want planning, coding, and review guardrails without manually switching skills
- You are working in an existing codebase and need the workflow to validate assumptions before editing
- You want an adversarial review step before deciding whether to push or open a PR
When NOT to Use It
- You need full BMad artifacts like a Product Brief, PRD, Architecture doc, or Epic/Story breakdown
- The request contains multiple independently shippable goals and should be split first
- The work needs stakeholder alignment before implementation starts
- You only want a quick implementation pass and do not want spec generation or review checkpoints
:::note[Experimental by Design] This workflow is intentionally stricter than a casual "just implement it" prompt. It treats your request as input, not truth, and still performs investigation, spec generation, and review when the blast radius is non-zero. :::
How It Works
bmad-quick-dev-new-preview always runs the same five-step loop:
- Clarify and route. It checks for resumable artifacts, verifies the working state, clarifies unanswered intent gaps, and routes the request into either a one-shot path or a plan-code-review path.
- Plan. For anything with meaningful blast radius, it investigates the codebase and generates a full tech spec from the workflow template. The spec is reviewed at a human checkpoint before implementation starts.
- Implement. The approved spec moves to
in-progress, a baseline commit is captured for diffing, and implementation happens locally only. The workflow never pushes during this step. - Review. It runs adversarial review against the change. On the full path, review findings are classified as intent gaps, bad spec, patchable issues, deferred issues, or noise. Spec defects trigger a loopback instead of papering over the problem.
- Present. It creates a local commit if needed, marks the spec
done, summarizes the work, and offers the next remote step instead of auto-pushing.
What Makes It Different
One workflow, not two
Classic Quick Flow separates planning and implementation into bmad-quick-spec and bmad-quick-dev. Quick Dev New Preview keeps both inside one stateful workflow, so the agent owns routing, artifact management, and review sequencing from start to finish.
Approval freezes intent
After you approve the spec, everything inside the spec's <frozen-after-approval> block becomes human-owned intent. If later review reveals that the original intent was incomplete, the workflow is supposed to stop and bring that gap back to you rather than silently changing scope.
Review can force re-derivation
This workflow is opinionated about bad planning. If review shows the code drifted because the spec was weak, it updates the spec, preserves the parts that worked, and re-derives the implementation instead of stacking more patches on top of a flawed plan.
Output Artifacts
On the plan-code-review path, the main artifact is a tech-spec-{slug}.md file in your implementation artifacts folder. That file records status transitions such as ready-for-dev, in-progress, in-review, and done, and it also stores the baseline commit used for diff-based review.
If the workflow detects extra goals or unrelated issues, it can also append them to deferred-work.md so the current run stays focused on one shippable objective.
Quick Dev New Preview vs Quick Flow
| Need | Better fit |
|---|---|
| Small change, but you still want explicit review and artifact state managed for you | bmad-quick-dev-new-preview |
| Separate planning and implementation conversations | bmad-quick-spec + bmad-quick-dev |
| Fastest path for well-understood small work using the established Quick Flow pair | Quick Flow |
| Multi-phase product work with broader alignment and architecture decisions | Full BMad Method |
When to Graduate
If the workflow surfaces multiple top-level goals, major architectural uncertainty, or repeated intent/spec loopbacks, that is usually a signal to move up a level. Use bmad-quick-spec for a cleaner planning pass, or escalate fully into the broader BMad Method when the work clearly needs product and architecture artifacts.