72 lines
4.8 KiB
Markdown
72 lines
4.8 KiB
Markdown
---
|
|
title: "Quick Dev New Preview"
|
|
description: Unified quick workflow that clarifies, plans, implements, reviews, and hands off in one run
|
|
sidebar:
|
|
order: 2
|
|
---
|
|
|
|
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:
|
|
|
|
1. **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.
|
|
2. **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.
|
|
3. **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.
|
|
4. **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.
|
|
5. **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.
|