bmad-method 6.10.1-next.32 → 6.10.1-next.34

package/.claude-plugin/marketplace.json

@@ -90,7 +90,7 @@
         "./src/bmm-skills/3-solutioning/bmad-generate-project-context",
         "./src/bmm-skills/4-implementation/bmad-agent-dev",
         "./src/bmm-skills/4-implementation/bmad-dev-story",
-        "./src/bmm-skills/4-implementation/bmad-quick-dev",
+        "./src/bmm-skills/4-implementation/bmad-build",
         "./src/bmm-skills/4-implementation/bmad-checkpoint-preview",
         "./src/bmm-skills/4-implementation/bmad-sprint-planning",
         "./src/bmm-skills/4-implementation/bmad-sprint-status",
@@ -98,7 +98,8 @@
         "./src/bmm-skills/4-implementation/bmad-create-story",
         "./src/bmm-skills/4-implementation/bmad-correct-course",
         "./src/bmm-skills/4-implementation/bmad-retrospective",
-        "./src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests"
+        "./src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests",
+        "./src/bmm-skills/v6-shims/bmad-quick-dev"
       ]
     }
   ]

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method",
-  "version": "6.10.1-next.32",
+  "version": "6.10.1-next.34",
   "description": "Breakthrough Method of Agile AI-driven Development",
   "keywords": [
     "agile",
@@ -40,14 +40,14 @@
     "lint:fix": "eslint . --ext .js,.cjs,.mjs,.yaml --fix",
     "lint:md": "markdownlint-cli2 \"**/*.md\"",
     "prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
-    "quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:site-url && npm run test:install && npm run test:urls && npm run test:renderer && npm run test:dev-auto-contract && npm run validate:refs && npm run validate:skills && npm run docs:validate-sidebar",
+    "quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:site-url && npm run test:install && npm run test:urls && npm run test:renderer && npm run test:build-auto-contract && npm run validate:refs && npm run validate:skills && npm run docs:validate-sidebar",
     "rebundle": "node tools/installer/bundlers/bundle-web.js rebundle",
-    "test": "npm run test:refs && npm run test:install && npm run test:urls && npm run test:site-url && npm run test:channels && npm run test:renderer && npm run test:dev-auto-contract && npm run test:skills && npm run lint && npm run lint:md && npm run format:check",
+    "test": "npm run test:refs && npm run test:install && npm run test:urls && npm run test:site-url && npm run test:channels && npm run test:renderer && npm run test:build-auto-contract && npm run test:skills && npm run lint && npm run lint:md && npm run format:check",
+    "test:build-auto-contract": "node test/test-build-auto-contract.js",
     "test:channels": "node test/test-installer-channels.js",
-    "test:dev-auto-contract": "node test/test-dev-auto-contract.js",
     "test:install": "node test/test-installation-components.js",
     "test:refs": "node test/test-file-refs-csv.js",
-    "test:renderer": "uv run --python 3.11 python -m unittest src/scripts/tests/test_config_utils.py src/scripts/tests/test_resolve_config.py src/scripts/tests/test_resolve_customization.py && node test/test-quick-dev-renderer.js && node test/test-dev-auto-renderer.js",
+    "test:renderer": "uv run --python 3.11 python -m unittest src/scripts/tests/test_config_utils.py src/scripts/tests/test_resolve_config.py src/scripts/tests/test_resolve_customization.py && node test/test-build-renderer.js && node test/test-build-auto-renderer.js",
     "test:site-url": "node test/test-site-url.mjs",
     "test:skills": "node test/test-validate-skills.js",
     "test:urls": "node test/test-parse-source-urls.js",

package/src/bmm-skills/2-plan-workflows/bmad-prd/SKILL.md

@@ -20,7 +20,7 @@ You are a master facilitator and coach helping the user create, edit, or validat
 1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly and use defaults.
 2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (entries prefixed `file:` are loaded). `{workflow.external_sources}` is an org-configured registry of internal tools (knowledge bases, MCP tools); consult them alongside generic web research on the same triggers, org tools preferred when their directive matches. Research itself fires during Discovery — see **Research subagents**.
 3. Load `{project-root}/_bmad/bmm/config.yaml` (+ `config.user.yaml` if present). Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`. Missing keys → neutral defaults; never block.
-4. If headless, follow `references/headless.md` for the whole run. Otherwise greet the user **by name** using `{user_name}` and **in their language** using `{communication_language}` — and stay in `{communication_language}` for every turn for the entire run, not just the greeting. In the greeting, let the user know that at any point they can invoke `bmad-party-mode` for multi-agent perspectives or `bmad-advanced-elicitation` for deeper exploration on a specific section. Then scan for misroute on the first message: if the signal points elsewhere (game → BMad GDS; express build → `bmad-quick-dev`; one-pager → `bmad-product-brief`; vet product idea → `bmad-prfaq`; agent skill or custom agent → `bmad-workflow-builder`), suggest they might want the other options before continuing.
+4. If headless, follow `references/headless.md` for the whole run. Otherwise greet the user **by name** using `{user_name}` and **in their language** using `{communication_language}` — and stay in `{communication_language}` for every turn for the entire run, not just the greeting. In the greeting, let the user know that at any point they can invoke `bmad-party-mode` for multi-agent perspectives or `bmad-advanced-elicitation` for deeper exploration on a specific section. Then scan for misroute on the first message: if the signal points elsewhere (game → BMad GDS; express build → `bmad-build`; one-pager → `bmad-product-brief`; vet product idea → `bmad-prfaq`; agent skill or custom agent → `bmad-workflow-builder`), suggest they might want the other options before continuing.
 5. Detect intent: **Create** (no PRD), **Update** (existing PRD), **Validate** (critique only). If ambiguous, ask. For Create intent, before binding a fresh workspace, scan `{workflow.prd_output_path}` for prior in-progress runs (folders matching `{workflow.run_folder_pattern}` whose `prd.md` frontmatter `status` is not `final`); if any exist, offer to resume rather than starting over.
 
 Run `{workflow.activation_steps_append}`.

package/src/bmm-skills/2-plan-workflows/bmad-prd/assets/prd-template.md

@@ -161,5 +161,5 @@ updated: {YYYY-MM-DD}
 - **Environmental and Reliability Requirements**.
 
 ### Small-scope all-inclusive *(use when scope is 1-2 stories' worth and the user wants a single captured artifact — chosen during the Right-skill check in Discovery)*
-- **Stories** — story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-quick-dev` is the better path — this cluster is only for "I want a doc *and* the stories."
+- **Stories** — story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-build` is the better path — this cluster is only for "I want a doc *and* the stories."
 

package/src/bmm-skills/2-plan-workflows/bmad-ux/SKILL.md

@@ -87,4 +87,4 @@ Outcomes, in order:
 - **Key-screen mocks rendered.** Key-screens tool → `.working/` for surfaces where layout drives behavior or anchors visual language.
 - **Mock coverage confirmed.** Walk every IA surface; classify *mocked* vs *spine-only*. Ask: *"These will be built from spine tables alone — any need a visual reference?"* Render more if named; log spine-only choices.
 - **Layout extracted, artifacts promoted.** Distill subagent re-reads each `.working/` and `imports/` artifact; lifts visual decisions into DESIGN.md and behavioral decisions into EXPERIENCE.md. Promote `.working/` keepers to `mockups/` (HTML) or `wireframes/` (Excalidraw); imports stay. Inline relative links at relevant spine sections; state spines-win-on-conflict once.
-- **Polished, handed off, closed.** Apply `{workflow.doc_standards}` in order. Execute `{workflow.external_handoffs}`; surface URLs. Set both files' `status: final`, `updated: {date}`. Log finalization via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type event --text "spines finalized"`. Share paths. Common next: `bmad-architecture`, `bmad-create-epics-and-stories`, `bmad-quick-dev`. Run `{workflow.on_complete}`.
+- **Polished, handed off, closed.** Apply `{workflow.doc_standards}` in order. Execute `{workflow.external_handoffs}`; surface URLs. Set both files' `status: final`, `updated: {date}`. Log finalization via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type event --text "spines finalized"`. Share paths. Common next: `bmad-architecture`, `bmad-create-epics-and-stories`, `bmad-build`. Run `{workflow.on_complete}`.

package/src/bmm-skills/3-solutioning/bmad-architecture/SKILL.md

@@ -73,7 +73,7 @@ Walk the sequence; reviewer fixes land before polish.
 4. **Triage.** Open questions and `[ASSUMPTION]` tags: blockers (unsafe for what's next) resolved one at a time; the rest deferred with a revisit condition in the memlog.
 5. **Renderings & polish.** The spine is the build deliverable; with it and the memlog now in place, produce any *additional* human-facing artifact the user needs, scoped to the purpose and audience drawn out up front. The up-front question already flagged whether one's needed; if it wasn't, still offer one here, seeding concrete options: an interactive HTML+SVG deck to walk a team through the architecture and drive discussion, a fuller HTML/md solution design, a C4 set, or a view of how the work splits across teams/epics. Build only what they pick, right-sized to that purpose; apply `{workflow.doc_standards}` polish to that prose only, never to the spine.
 6. **External handoffs.** Run `{workflow.external_handoffs}`; surface returned URLs/IDs. Offer to invoke the `bmad-spec` skill to adopt the spine as a companion, keeping `AD` IDs stable so downstream can cite them.
-7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-create-epics-and-stories` or — epic altitude — `bmad-quick-dev`; or invoke `bmad-help` to route.
+7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-create-epics-and-stories` or — epic altitude — `bmad-build`; or invoke `bmad-help` to route.
 8. Run `{workflow.on_complete}`.
 
 ## Update

package/src/bmm-skills/4-implementation/bmad-agent-dev/customize.toml

@@ -58,9 +58,9 @@ principles = [
 # registered skill by name) or `prompt` (executes the prompt text directly).
 
 [[agent.menu]]
-code = "QD"
+code = "BD"
 description = "Implement a feature, fix, or story"
-skill = "bmad-quick-dev"
+skill = "bmad-build"
 
 [[agent.menu]]
 code = "QA"

package/src/bmm-skills/4-implementation/{bmad-quick-dev → bmad-build}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-quick-dev
+name: bmad-build
 description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the project''s existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
 ---
 

package/src/bmm-skills/4-implementation/{bmad-quick-dev → bmad-build}/compile-epic-context.md

@@ -52,7 +52,7 @@ Use these headings:
 - **No full copies.** Never quote source documents, section numbers, or paste large blocks verbatim. Always distill.
 - **No story-level details.** The story list is for orientation only. Individual story specs handle the details.
 - **Nothing derivable from the codebase.** Don't document what a developer can learn by reading the code.
-- **Be concise and actionable.** Target 800–1500 tokens total. This file loads into quick-dev's context alongside other material.
+- **Be concise and actionable.** Target 800–1500 tokens total. This file loads into build's context alongside other material.
 - **Never hallucinate content.** If source material doesn't say something, don't invent it.
 - **Omit empty sections entirely**, except Goal and Stories, which are always required.
 

package/src/bmm-skills/4-implementation/{bmad-quick-dev → bmad-build}/customize.toml

@@ -1,8 +1,8 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Default customization values for bmad-quick-dev.
-# Override in _bmad/custom/bmad-quick-dev.toml or
-# _bmad/custom/bmad-quick-dev.user.toml.
+# Default customization values for bmad-build.
+# Override in _bmad/custom/bmad-build.toml or
+# _bmad/custom/bmad-build.user.toml.
 #
 # Merge rules:
 # - Strings replace the default.
@@ -28,11 +28,49 @@ persistent_facts = [
   "file:{project-root}/**/project-context.md",
 ]
 
-# Instruction run after Quick Dev completes.
+# Instruction run after Build completes.
 # Empty means no extra completion behavior.
 
 on_complete = ""
 
+# How Build opens a completed spec for human review. The default deliberately
+# opens the repository root first and the spec second in a reused VS Code
+# window so relative review links resolve in the correct workspace. Override
+# this with the application and equivalent behavior you prefer. Set it to an
+# empty string to disable automatic opening and all related completion output.
+# Example requests for bmad-customize: "Open completed specs in Cursor and
+# reuse the project window" or "Do not open completed specs automatically."
+#
+# Example `open_spec` override instructions for bmad-build.user.toml:
+# {project-root} and {spec_file} are substituted at run time.
+#
+# VS Code and compatible GUI editors — shipped default uses `code`; Cursor,
+# Windsurf, Antigravity, Zed, and similar editors can substitute their launcher.
+# Preserve reuse-window behavior when the launcher supports it, and always pass
+# the repository root first and the spec second:
+#   Run `code -r "{project-root}" "{spec_file}"`, root first.
+#   Run `cursor -r "{project-root}" "{spec_file}"`, root first.
+#   Run `windsurf -r "{project-root}" "{spec_file}"`, root first.
+#   Run `zed "{project-root}" "{spec_file}"`, root first.
+#
+# IntelliJ IDEA — its CLI accepts one path per invocation:
+#   Run `idea "{project-root}"` to open the project, then
+#   `idea "{spec_file}"` to open the spec in that project.
+#
+# Vim — keep repository context as the working directory:
+#   Run `cd "{project-root}" && vim "{spec_file}"`.
+#
+# Emacs — reuse an Emacs server without waiting for the buffer to close:
+#   Run `cd "{project-root}" && emacsclient -n "{spec_file}"`.
+#
+# For every non-empty override, also tell Build to note in the completion summary
+# that the spec was sent to the chosen editor and contains a Suggested Review
+# Order, then include the default navigation tip shown below.
+
+open_spec = """
+Run `code -r "{project-root}" "{spec_file}"` — the repository root first so VS Code opens in the right context, then the spec file. Always double-quote both paths to handle spaces and special characters. If `code` is unavailable or the command fails, skip gracefully and tell the user the spec file path instead. In the completion summary, note that the spec was sent to VS Code and that it contains a Suggested Review Order, then add this navigation tip: "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
+"""
+
 # Handoff for the implementation subagent in step 03. The whole execution
 # recipe — a subagent by default, but an override may run it any other way
 # (a different model, an external coding tool via bash). {spec_file} is

package/src/bmm-skills/4-implementation/{bmad-quick-dev → bmad-build}/render.py

@@ -2,12 +2,12 @@
 # /// script
 # requires-python = ">=3.11"
 # ///
-"""render.py — bmad-quick-dev template renderer.
+"""render.py — bmad-build template renderer.
 
 Resolves compile-time {{.variable}} placeholders from BMad's central config,
 bakes absolute paths for {project-root} into derived values, resolves and
 inlines the skill's [workflow] customization block, and writes rendered .md
-files to {project-root}/_bmad/render/bmad-quick-dev/.
+files to {project-root}/_bmad/render/bmad-build/.
 
 Config: four-layer merge of _bmad/config.toml + config.user.toml +
 custom/config.toml + custom/config.user.toml (post-#2285 installs).
@@ -18,7 +18,7 @@ Optional layers may be missing, but one that exists and cannot be parsed
 or read → HALT.
 
 Customization: three-layer merge of {skill}/customize.toml +
-_bmad/custom/bmad-quick-dev.toml + .user.toml (same structural rules as
+_bmad/custom/bmad-build.toml + .user.toml (same structural rules as
 resolve_customization.py). The resolved [workflow] values fill {workflow.*}
 placeholders, so this skill needs no runtime resolve_customization.py call.
 Other single-curly placeholders ({project-root}, {spec_file}, ...) pass
@@ -85,7 +85,7 @@ def load_toml(path, required=False):
 
 def _deep_merge(base, override):
     """Dict-aware deep merge. Lists and scalars: override wins (we don't need
-    the full keyed-merge semantics of resolve_config.py — quick-dev only reads
+    the full keyed-merge semantics of resolve_config.py — build only reads
     flat scalars out of [core] and [modules.bmm])."""
     if isinstance(base, dict) and isinstance(override, dict):
         result = dict(base)
@@ -391,6 +391,13 @@ def main():
 
     skill_dir = script_dir.replace(os.sep, "/")
     workflow = resolve_workflow(root, skill_dir, skill_name)
+    open_spec = workflow.get("open_spec")
+    if not isinstance(open_spec, str):
+        print(
+            "HALT and report to the user: customization `workflow.open_spec` "
+            "must be a string"
+        )
+        sys.exit(1)
     workflow = expand_review_layer_skill_roots(workflow, skill_dir)
 
     out_dir = posixpath.join(root, "_bmad", "render", skill_name)

package/src/bmm-skills/4-implementation/{bmad-quick-dev → bmad-build}/step-05-present.md

@@ -54,20 +54,17 @@ Change `{spec_file}` status to `done` in the frontmatter.
 
 Follow `./sync-sprint-status.md` with `target_status` = `review`.
 
-### Commit and Open
+### Commit and Complete
 
-1. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
-2. Open the spec in the user's editor so they can click through the Suggested Review Order:
-   - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
-   - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
+If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
+
+{workflow.open_spec}
 
 ### Display Summary
 
-Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators. Include:
+Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators.
 
-- A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
-- **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
-- Offer to push and/or create a pull request.
+Offer to push and/or create a pull request.
 
 Workflow complete.
 

package/src/bmm-skills/4-implementation/{bmad-quick-dev → bmad-build}/step-oneshot.md

@@ -56,16 +56,15 @@ If version control is available and the tree is dirty, create a local commit wit
 
 ### Present
 
-1. Open the spec in the user's editor so they can click through the Suggested Review Order:
-   - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
-   - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
-2. Display a summary in conversation output, including:
-   - The commit hash (if one was created).
-   - List of files changed with one-line descriptions. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — this differs from spec-file links which use spec-file-relative paths.
-   - Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
-   - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
-   - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
-3. Offer to push and/or create a pull request.
+{workflow.open_spec}
+
+Display a summary in conversation output, including:
+
+- The commit hash (if one was created).
+- List of files changed with one-line descriptions. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — this differs from spec-file links which use spec-file-relative paths.
+- Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
+
+Offer to push and/or create a pull request.
 
 HALT and wait for human input.
 

package/src/bmm-skills/4-implementation/{bmad-quick-dev → bmad-build}/sync-sprint-status.md

@@ -1,6 +1,6 @@
 # Sync Sprint Status
 
-Shared sub-step for updating `sprint-status.yaml` during quick-dev. Called from any route (plan-code-review, one-shot, future routes) with a `target_status` parameter.
+Shared sub-step for updating `sprint-status.yaml` during build. Called from any route (plan-code-review, one-shot, future routes) with a `target_status` parameter.
 
 ## Preconditions
 

package/src/bmm-skills/4-implementation/{bmad-quick-dev → bmad-build}/workflow.md

@@ -1,4 +1,4 @@
-# Quick Dev New Preview Workflow
+# Build New Preview Workflow
 
 **Goal:** Turn user intent into a hardened, reviewable artifact.
 

package/src/bmm-skills/4-implementation/{bmad-dev-auto → bmad-build-auto}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-dev-auto
+name: bmad-build-auto
 description: 'One iteration of an unattended development loop. Use when invoked by name.'
 ---
 

package/src/bmm-skills/4-implementation/{bmad-dev-auto → bmad-build-auto}/compile-epic-context.md

@@ -52,7 +52,7 @@ Use these headings:
 - **No full copies.** Never quote source documents, section numbers, or paste large blocks verbatim. Always distill.
 - **No story-level details.** The story list is for orientation only. Individual story specs handle the details.
 - **Nothing derivable from the codebase.** Don't document what a developer can learn by reading the code.
-- **Be concise and actionable.** Target 800–1500 tokens total. This file loads into bmad-dev-auto's context alongside other material.
+- **Be concise and actionable.** Target 800–1500 tokens total. This file loads into bmad-build-auto's context alongside other material.
 - **Never hallucinate content.** If source material doesn't say something, don't invent it.
 - **Omit empty sections entirely**, except Goal and Stories, which are always required.
 

package/src/bmm-skills/4-implementation/{bmad-dev-auto → bmad-build-auto}/customize.toml

@@ -1,8 +1,8 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Default customization values for bmad-dev-auto.
-# Override in _bmad/custom/bmad-dev-auto.toml or
-# _bmad/custom/bmad-dev-auto.user.toml.
+# Default customization values for bmad-build-auto.
+# Override in _bmad/custom/bmad-build-auto.toml or
+# _bmad/custom/bmad-build-auto.user.toml.
 #
 # Merge rules:
 # - Strings replace the default.

package/src/bmm-skills/4-implementation/{bmad-dev-auto → bmad-build-auto}/step-01-clarify-and-route.md

@@ -25,13 +25,13 @@ If the invocation prompt explicitly points to an existing spec file with recogni
 
 If the invocation prompt instead supplies a spec folder and a story id, with no specific spec file path, this is a **folder+id dispatch**: set `spec_folder` (a `{project-root}`-relative or absolute path) and `story_id` from the prompt. Any further prompt text (e.g. `invoke_dev_with` guidance the caller appended) is additional planning context to carry into step-02 — not a competing description of what to implement.
 
-Read `{spec_folder}/stories.yaml`. If the file does not exist or fails to parse, HALT with status `blocked` and blocking condition `no stories.yaml found`. Find the entry whose `id` equals `{story_id}`; if none matches, HALT with status `blocked` and blocking condition `story id not found in stories.yaml`. Take only that entry's `title` and `description` — never read the checkpoint fields or `invoke_dev_with`; those are the caller's orchestration fields, not dev-auto's.
+Read `{spec_folder}/stories.yaml`. If the file does not exist or fails to parse, HALT with status `blocked` and blocking condition `no stories.yaml found`. Find the entry whose `id` equals `{story_id}`; if none matches, HALT with status `blocked` and blocking condition `story id not found in stories.yaml`. Take only that entry's `title` and `description` — never read the checkpoint fields or `invoke_dev_with`; those are the caller's orchestration fields, not build-auto's.
 
 Look for files matching `{spec_folder}/stories/{story_id}-*.md` (id-prefix match — story ids are prefix-free, so at most one should match):
 - **If more than one matches**, HALT with status `blocked` and blocking condition `ambiguous story file match`.
 - **If exactly one matches**, set `spec_file` to that path.
   - `draft` (planning was interrupted mid-flight): accumulate cross-story context before resuming — load every other file matching `{spec_folder}/stories/*.md` (every match except `{spec_file}` itself), regardless of `status`, and carry forward each one's **Code Map**, **Design Notes**, **Spec Change Log**, **Tasks & Acceptance** checklist state, and **Auto Run Result** details, where present, as additional planning context for step-02. Then **EARLY EXIT** to `[[bmad-snapshot:step-02-plan.md]]`.
-  - Any other recognized `status`: **EARLY EXIT** using the same routing as above, including the `review_loop_iteration` reset for `done`. One difference: a `blocked` story HALTs with blocking condition `story already blocked`, not `blocked spec supplied` — the caller did not supply this file; dev-auto found it by id.
+  - Any other recognized `status`: **EARLY EXIT** using the same routing as above, including the `review_loop_iteration` reset for `done`. One difference: a `blocked` story HALTs with blocking condition `story already blocked`, not `blocked spec supplied` — the caller did not supply this file; build-auto found it by id.
   - `status` missing or unrecognized: HALT with status `blocked` and blocking condition `unrecognized status in existing story file`.
 - **If none matches**, this is the first dispatch for `{story_id}`. The entry's `title` and `description` are the resolved intent. If `{spec_folder}/SPEC.md` does not exist, HALT with status `blocked` and blocking condition `no epic spec found`. Otherwise load it and the files listed in its `companions:` frontmatter as planning context, then accumulate cross-story context the same way as the `draft` case above — load every file matching `{spec_folder}/stories/*.md` (none yet exists for `{story_id}` at this point, so nothing is excluded), regardless of `status`, carrying forward the same fields, where present, as additional planning context for step-02. Then continue to INSTRUCTIONS item 3 below — not `step-03-implement.md`, item 3 of the numbered list in this file (items 1 and 2 do not apply — context and intent are already resolved; item 1.A.5's previous-story continuity scan in particular never runs here, since folder+id dispatch already skips items 1 and 2 entirely — the cross-story accumulation above is its replacement for this dispatch mode).
 

package/src/bmm-skills/4-implementation/{bmad-dev-auto → bmad-build-auto}/workflow.md

@@ -1,4 +1,4 @@
-# Dev Auto Workflow
+# Build Auto Workflow
 
 **Goal:** Turn intent into a hardened, reviewable artifact, without human interaction.
 
@@ -29,13 +29,13 @@ To HALT with a final status and optional blocking condition:
      ```
 2. **Otherwise:**
    - If `{spec_file}` is known and exists, update `status` in frontmatter and append missing result details under `## Auto Run Result`.
-   - If `{spec_file}` is unknown or missing, create `{{.implementation_artifacts}}/bmad-dev-auto-result-<slug-or-timestamp>.md` with:
+   - If `{spec_file}` is unknown or missing, create `{{.implementation_artifacts}}/bmad-build-auto-result-<slug-or-timestamp>.md` with:
      ```markdown
      ---
      status: <final status>
      ---
 
-     # BMad Dev Auto Result
+     # BMad Build Auto Result
 
      Status: <final status>
      Blocking condition: <blocking condition, if any>

package/src/bmm-skills/4-implementation/bmad-retrospective/SKILL.md

@@ -238,13 +238,13 @@ Amelia (Developer): "Before we start the team discussion, let me review all the
 Charlie (Senior Dev): "Good idea - those dev notes always have gold in them."
 </output>
 
-<action>For each story in epic {{epic_number}}, read the complete story record from {implementation_artifacts}/{{epic_number}}-{{story_num}}-*.md (legacy story files) and {implementation_artifacts}/spec-{{epic_number}}-{{story_num}}-*.md (quick-dev specs)</action>
+<action>For each story in epic {{epic_number}}, read the complete story record from {implementation_artifacts}/{{epic_number}}-{{story_num}}-*.md (legacy story files) and {implementation_artifacts}/spec-{{epic_number}}-{{story_num}}-*.md (build specs)</action>
 
 <action>Extract and analyze from each story:</action>
 
 **Dev Notes and Struggles:**
 
-- Look for sections like "## Dev Notes", "## Implementation Notes", "## Challenges", "## Development Log" — in quick-dev specs: "## Tasks & Acceptance", "## Code Map", "## Design Notes", "## Spec Change Log"
+- Look for sections like "## Dev Notes", "## Implementation Notes", "## Challenges", "## Development Log" — in build specs: "## Tasks & Acceptance", "## Code Map", "## Design Notes", "## Spec Change Log"
 - Identify where developers struggled or made mistakes
 - Note unexpected complexity or gotchas discovered
 - Record technical decisions that didn't work out as planned
@@ -1480,7 +1480,7 @@ Retrospective document was saved successfully, but {sprint_status_file} may need
   {{else}}
 
 4. **Begin Epic {{next_epic_num}} when ready**
-   - Start the next epic's stories with Developer agent's `quick-dev`
+   - Start the next epic's stories with Developer agent's `build`
    - Epic will be marked as `in-progress` automatically when first story is created
    - Ensure all critical path items are done first
      {{/if}}

package/src/bmm-skills/4-implementation/bmad-sprint-planning/SKILL.md

@@ -181,7 +181,7 @@ development_status:
 #   - done: All stories in epic completed
 #
 # Epic Status Transitions:
-#   - backlog → in-progress: Automatically when first story starts (via quick-dev's sprint sync)
+#   - backlog → in-progress: Automatically when first story starts (via build's sprint sync)
 #   - in-progress → done: Manually when all stories reach 'done' status
 #
 # Story Status:
@@ -202,7 +202,7 @@ development_status:
 #
 # WORKFLOW NOTES:
 # ===============
-# - Epic transitions to 'in-progress' automatically when first story starts (via quick-dev's sprint sync)
+# - Epic transitions to 'in-progress' automatically when first story starts (via build's sprint sync)
 # - Stories can be worked in parallel if team capacity allows
 # - Developer typically creates next story after previous one is 'done' to incorporate learnings
 # - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)

package/src/bmm-skills/4-implementation/bmad-sprint-status/SKILL.md

@@ -152,7 +152,7 @@ Enter corrections (e.g., "1=in-progress, 2=backlog") or "skip" to continue witho
 
 - IF any story has status "review": suggest `/bmad:bmm:workflows:code-review`
 - IF any story has status "in-progress" AND no stories have status "ready-for-dev": recommend staying focused on active story
-- IF all epics have status "backlog" AND no stories have status "ready-for-dev": recommend `bmad-quick-dev` to start the first backlog story
+- IF all epics have status "backlog" AND no stories have status "ready-for-dev": recommend `bmad-build` to start the first backlog story
 - IF `last_updated` timestamp is more than 7 days old (or `last_updated` is missing, fall back to `generated`): warn "sprint-status.yaml may be stale"
 - IF any story key doesn't match an epic pattern (e.g., story "5-1-..." but no "epic-5"): warn "orphaned story detected"
 - IF any epic has status in-progress but has no associated stories: warn "in-progress epic has no stories"
@@ -161,10 +161,10 @@ Enter corrections (e.g., "1=in-progress, 2=backlog") or "skip" to continue witho
 <step n="3" goal="Select next action recommendation">
   <action>Pick the next recommended workflow using priority:</action>
   <note>When selecting "first" story: sort by epic number, then story number (e.g., 1-1 before 1-2 before 2-1)</note>
-  1. If any story status == in-progress → recommend `quick-dev` to resume the first in-progress story
+  1. If any story status == in-progress → recommend `build` to resume the first in-progress story
   2. Else if any story status == review → recommend `code-review` for the first review story
-  3. Else if any story status == ready-for-dev → recommend `quick-dev` to start work on the first ready-for-dev story
-  4. Else if any story status == backlog → recommend `quick-dev` to start the first backlog story
+  3. Else if any story status == ready-for-dev → recommend `build` to start work on the first ready-for-dev story
+  4. Else if any story status == backlog → recommend `build` to start the first backlog story
   5. Else if any retrospective status == optional → recommend `retrospective`
   6. Else → All implementation items done; congratulate the user - you both did amazing work together!
   <action>Store selected recommendation as: next_story_id, next_workflow_id, next_agent (DEV)</action>

package/src/bmm-skills/module-help.csv

@@ -2,7 +2,7 @@ module,skill,display-name,menu-code,description,action,args,phase,preceded-by,fo
 BMad Method,_meta,,,,,,,,,false,https://docs.bmad-method.org/llms.txt,
 BMad Method,bmad-document-project,Document Project,DP,Analyze an existing project to produce useful documentation.,,,anytime,,,false,project-knowledge,*
 BMad Method,bmad-generate-project-context,Generate Project Context,GPC,Scan existing codebase to generate a lean LLM-optimized project-context.md. Essential for brownfield projects.,,,anytime,,,false,output_folder,project context
-BMad Method,bmad-quick-dev,Quick Dev,QQ,Official Phase 4 implementation loop: clarify intent plan implement review and present.,,,4-implementation,bmad-sprint-planning,bmad-code-review,true,implementation_artifacts,spec and project implementation
+BMad Method,bmad-build,Build,BD,Official Phase 4 implementation loop: clarify intent plan implement review and present.,,,4-implementation,bmad-sprint-planning,bmad-code-review,true,implementation_artifacts,spec and project implementation
 BMad Method,bmad-spec,Spec,SPC,"Use to distill any intent input (brief, PRD, transcript, brain dump, design folder, mixed multi-source) into a succinct, no-fluff SPEC.md contract + companions that downstream work derives from. Locks the WHAT before the HOW. Works for software, game design, research, editorial, policy, business, anything intent-bearing. Validation mode also available.",,[path],anytime,,,false,{output_folder}/specs/spec-{slug},SPEC.md + companion files
 BMad Method,bmad-correct-course,Correct Course,CC,Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories.,,,anytime,,,false,planning_artifacts,change proposal
 BMad Method,bmad-agent-tech-writer,Write Document,WD,"Describe in detail what you want, and the agent will follow documentation best practices. Multi-turn conversation with subprocess for research/review.",write,,anytime,,,false,project-knowledge,document
@@ -20,7 +20,7 @@ BMad Method,bmad-create-epics-and-stories,Create Epics and Stories,CE,,,,3-solut
 BMad Method,bmad-check-implementation-readiness,Check Implementation Readiness,IR,Ensure PRD UX Architecture and Epics Stories are aligned.,,,3-solutioning,bmad-create-epics-and-stories,,true,planning_artifacts,readiness report
 BMad Method,bmad-sprint-planning,Sprint Planning,SP,Kicks off implementation by producing a plan the implementation agents will follow in sequence for every story.,,,4-implementation,,,true,implementation_artifacts,sprint status
 BMad Method,bmad-sprint-status,Sprint Status,SS,Anytime: Summarize sprint status and route to next workflow.,,,4-implementation,bmad-sprint-planning,,false,,
-BMad Method,bmad-code-review,Code Review,CR,Ad hoc review of any code change. Optional extra layer after Quick Dev's built-in review.,,,4-implementation,bmad-quick-dev,,false,,
+BMad Method,bmad-code-review,Code Review,CR,Ad hoc review of any code change. Optional extra layer after Build's built-in review.,,,4-implementation,bmad-build,,false,,
 BMad Method,bmad-checkpoint-preview,Checkpoint,CK,Guided walkthrough of a change from purpose and context into details. Use for human review of commits branches or PRs.,,,4-implementation,,,false,,
-BMad Method,bmad-qa-generate-e2e-tests,QA Automation Test,QA,Generate automated API and E2E tests for implemented code. NOT for code review or story validation — use CR for that.,,,4-implementation,bmad-quick-dev,,false,implementation_artifacts,test suite
+BMad Method,bmad-qa-generate-e2e-tests,QA Automation Test,QA,Generate automated API and E2E tests for implemented code. NOT for code review or story validation — use CR for that.,,,4-implementation,bmad-build,,false,implementation_artifacts,test suite
 BMad Method,bmad-retrospective,Retrospective,ER,Optional at epic end: Review completed work lessons learned and next epic or if major issues consider CC.,,,4-implementation,bmad-code-review,,false,implementation_artifacts,retrospective

package/src/bmm-skills/module.yaml

@@ -30,8 +30,8 @@ planning_artifacts: # Phase 1-3 artifacts
   default: "{output_folder}/planning-artifacts"
   result: "{project-root}/{value}"
 
-implementation_artifacts: # Phase 4 artifacts and quick-dev flow output
-  prompt: "Where should implementation artifacts be stored? (Sprint status, stories, reviews, retrospectives, Quick Flow output)"
+implementation_artifacts: # Phase 4 artifacts and build flow output
+  prompt: "Where should implementation artifacts be stored? (Sprint status, stories, reviews, retrospectives, Build output)"
   default: "{output_folder}/implementation-artifacts"
   result: "{project-root}/{value}"
 

package/src/bmm-skills/v6-shims/README.md

@@ -6,6 +6,8 @@ stated intent and pre-resolved customization fields so the target skips its own
 
 | Shim                       | Forwards to                          |
 | -------------------------- | ------------------------------------ |
+| `bmad-quick-dev`           | `bmad-build`                         |
+| `bmad-dev-auto`            | `bmad-build-auto`                    |
 | `bmad-create-story`        | Retained in full                     |
 | `bmad-dev-story`           | Retained in full                     |
 | `bmad-create-prd`          | `bmad-prd` (create intent)           |

package/src/bmm-skills/v6-shims/bmad-create-story/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-create-story
-description: "Deprecated: `bmad-quick-dev` is now the official implementation method. Only use this when explicitly invoked by name."
+description: "Deprecated: `bmad-build` is now the official implementation method. Only use this when explicitly invoked by name."
 ---
 
 # Create Story Workflow
@@ -62,7 +62,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 Greet `{user_name}`, speaking in `{communication_language}`.
 
-<output>Deprecated: `bmad-quick-dev` is now the official implementation method. Only use this when explicitly invoked by name.</output>
+<output>Deprecated: `bmad-build` is now the official implementation method. Only use this when explicitly invoked by name.</output>
 
 ### Step 6: Execute Append Steps
 

package/src/bmm-skills/v6-shims/bmad-dev-auto/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: bmad-dev-auto
+description: "Deprecated: forwards to bmad-build-auto. Do not use unless invoked by name."
+---
+
+# Deprecated Build Auto Alias
+
+## On Activation
+
+1. Check whether either legacy customization file exists:
+   - `{project-root}/_bmad/custom/bmad-dev-auto.toml`
+   - `{project-root}/_bmad/custom/bmad-dev-auto.user.toml`
+2. If neither legacy file exists, output exactly `bmad-dev-auto is deprecated. Redirecting to bmad-build-auto. Please use bmad-build-auto in the future.`, invoke `bmad-build-auto` exactly once with the user's original input verbatim, then execute no further steps in this shim.
+3. For every legacy file that exists, use its matching new filename:
+   - `{project-root}/_bmad/custom/bmad-dev-auto.toml` becomes `{project-root}/_bmad/custom/bmad-build-auto.toml`.
+   - `{project-root}/_bmad/custom/bmad-dev-auto.user.toml` becomes `{project-root}/_bmad/custom/bmad-build-auto.user.toml`.
+4. If the matching new file does not exist, tell the user that the customization file uses the deprecated name and offer to rename it. Rename it only after explicit approval. If approval is declined or unavailable, or the rename fails, HALT and do not invoke any skill.
+5. If the matching new file already exists, do not overwrite it. Read both files, explain their differences, and propose the exact content for the new file. Resolve conflicting values with the user. Only after the user explicitly approves that content, save and verify the new file, then remove the legacy file. If approval is declined or unavailable, or any operation fails, HALT and do not invoke any skill.
+6. After every detected legacy file has been migrated successfully and no legacy file remains, output exactly `bmad-dev-auto is deprecated. Redirecting to bmad-build-auto. Please use bmad-build-auto in the future.`, invoke `bmad-build-auto` exactly once with the user's original input verbatim, then execute no further steps in this shim.

package/src/bmm-skills/v6-shims/bmad-dev-story/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-dev-story
-description: "Deprecated: `bmad-quick-dev` is now the official implementation method. Only use this when explicitly invoked by name."
+description: "Deprecated: `bmad-build` is now the official implementation method. Only use this when explicitly invoked by name."
 ---
 
 # Dev Story Workflow
@@ -60,7 +60,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 Greet `{user_name}`, speaking in `{communication_language}`.
 
-<output>Deprecated: `bmad-quick-dev` is now the official implementation method. Only use this when explicitly invoked by name.</output>
+<output>Deprecated: `bmad-build` is now the official implementation method. Only use this when explicitly invoked by name.</output>
 
 ### Step 6: Execute Append Steps
 

package/src/bmm-skills/v6-shims/bmad-quick-dev/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: bmad-quick-dev
+description: "Deprecated: forwards to bmad-build. Do not use unless invoked by name."
+---
+
+# Deprecated Build Alias
+
+## On Activation
+
+1. Check whether either legacy customization file exists:
+   - `{project-root}/_bmad/custom/bmad-quick-dev.toml`
+   - `{project-root}/_bmad/custom/bmad-quick-dev.user.toml`
+2. If neither legacy file exists, output exactly `bmad-quick-dev is deprecated. Redirecting to bmad-build. Please use bmad-build in the future.`, invoke `bmad-build` exactly once with the user's original input verbatim, then execute no further steps in this shim.
+3. For every legacy file that exists, use its matching new filename:
+   - `{project-root}/_bmad/custom/bmad-quick-dev.toml` becomes `{project-root}/_bmad/custom/bmad-build.toml`.
+   - `{project-root}/_bmad/custom/bmad-quick-dev.user.toml` becomes `{project-root}/_bmad/custom/bmad-build.user.toml`.
+4. If the matching new file does not exist, tell the user that the customization file uses the deprecated name and offer to rename it. Rename it only after explicit approval. If approval is declined or unavailable, or the rename fails, HALT and do not invoke any skill.
+5. If the matching new file already exists, do not overwrite it. Read both files, explain their differences, and propose the exact content for the new file. Resolve conflicting values with the user. Only after the user explicitly approves that content, save and verify the new file, then remove the legacy file. If approval is declined or unavailable, or any operation fails, HALT and do not invoke any skill.
+6. After every detected legacy file has been migrated successfully and no legacy file remains, output exactly `bmad-quick-dev is deprecated. Redirecting to bmad-build. Please use bmad-build in the future.`, invoke `bmad-build` exactly once with the user's original input verbatim, then execute no further steps in this shim.

package/src/core-skills/bmad-forge-idea/SKILL.md

@@ -97,7 +97,7 @@ Voice the personas yourself by default. Spawn separate agents only when a branch
 
 The session can end in three valid states:
 
-- **Hardened** — the idea is stronger and specific enough to use. Distill the memlog into `{workspace}/forged-idea.md`. Keep it extremely short: only the decisions, rejected options, and reasons that matter downstream, in the user's meaning. Do not write a prose summary, template, or conversation recap. If it reads like a document, it is too long. If planning or dev skills are installed (`bmad-spec`, `bmad-prd`, `bmad-prfaq`, `bmad-quick-dev`), offer the file as their input; if none are, the file stands on its own — never treat a missing skill as an error.
+- **Hardened** — the idea is stronger and specific enough to use. Distill the memlog into `{workspace}/forged-idea.md`. Keep it extremely short: only the decisions, rejected options, and reasons that matter downstream, in the user's meaning. Do not write a prose summary, template, or conversation recap. If it reads like a document, it is too long. If planning or dev skills are installed (`bmad-spec`, `bmad-prd`, `bmad-prfaq`, `bmad-build`), offer the file as their input; if none are, the file stands on its own — never treat a missing skill as an error.
 - **Killed** — the idea does not hold up. Say so plainly and record why. Finding that out early is a valid outcome.
 - **Clearer** — the user understands the idea better, but there is no hardened idea to hand off. Leave the memlog as the record; no `forged-idea.md` is needed.
 

package/src/core-skills/module-help.csv

@@ -6,5 +6,5 @@ Core,bmad-help,BMad Help,BH,,,,anytime,,,false,,
 Core,bmad-customize,BMad Customize,BC,"Use when you want to change how an agent or workflow behaves — add persistent facts, swap templates, insert activation hooks, or customize menus. Scans what's customizable, picks the right scope (agent vs workflow), writes the override to _bmad/custom/, and verifies the merge. No TOML hand-authoring required.",,,anytime,,,false,{project-root}/_bmad/custom,TOML override files
 Core,bmad-advanced-elicitation,Advanced Elicitation,AE,"Use at any checkpoint to push a just-produced draft, section, or plan past its first version — pick from a menu of elicitation methods (pre-mortem, first principles, red team, socratic) and apply the improvements.",,,anytime,,,false,,
 Core,bmad-review,Review,RV,"Use to review anything before it ships — a diff, branch, or uncommitted changes; a PRD, spec, story, or architecture doc; any prose document. Runs whichever installed lenses fit the content and reports findings in one shape: shipped lenses cover adversarial critique, edge cases, verification gaps, document structure (cuts, merges, moves), and prose copy-edit, and installs may add more. Reach for it to tighten a bloated or LLM-slop draft, pressure-test a plan before building, or check a change is adequately tested. Run every applicable lens or name the ones you want. Code Review in other modules calls it automatically.",,[path],anytime,,,false,,findings JSON array + markdown report
-Core,bmad-forge-idea,Forge Idea,FI,"Use to pressure-test and harden an idea — software, business, creative, research, or life — until it proves out, hardens into something buildable, or dies cheaply. Persona-driven interrogation; optional handoff to bmad-spec or bmad-quick-dev.",,,anytime,,,false,{output_folder}/forge,refined-idea brief (optional)
+Core,bmad-forge-idea,Forge Idea,FI,"Use to pressure-test and harden an idea — software, business, creative, research, or life — until it proves out, hardens into something buildable, or dies cheaply. Persona-driven interrogation; optional handoff to bmad-spec or bmad-build.",,,anytime,,,false,{output_folder}/forge,refined-idea brief (optional)
 Core,bmad-deep-recon,Deep Recon,RS,Decision-grade research three ways: draft a deep-research prompt for your own AI tool then process the returned report into a downstream-ready cited summary — or run the research directly via web fan-out. Types: market domain technical competitive user-voice academic-lit plus a select shape for choose-between decisions; claim verification and refresh lifecycle. Custom types via overrides.,,[type],anytime,,,false,{planning_artifacts}/research,research report/summary + optional html briefing

package/tools/installer/ide/_config-driven.js

@@ -434,7 +434,7 @@ class ConfigDrivenIdeSetup {
       if (!canonicalId) continue;
 
       // Derive source directory from path column
-      // path is like "_bmad/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/SKILL.md"
+      // path is like "_bmad/bmm/workflows/bmad-quick-flow/bmad-build-new-preview/SKILL.md"
       // Strip bmadFolderName prefix and join with bmadDir, then get dirname
       const relativePath = record.path.startsWith(bmadPrefix) ? record.path.slice(bmadPrefix.length) : record.path;
       const sourceFile = path.join(bmadDir, relativePath);

package/tools/validate-published-implementation-model.mjs

@@ -1,10 +1,13 @@
 import fs from 'node:fs';
 import path from 'node:path';
 
-const CANONICAL_LLMS_ENTRY = '**[Quick Dev]';
+const CANONICAL_LLMS_ENTRY = '**[Build]';
 const CANONICAL_LLMS_DESCRIPTION = 'Canonical implementation workflow for direct intent and fully planned work';
 
 const FORBIDDEN_TERMS = [
+  /\bbmad-(?:quick-dev|dev-auto)\b/gi,
+  /\bQuick[ -]?Dev\b/gi,
+  /\bDev[ -]?Auto\b/gi,
   /\bbmad-(?:create|dev)-story\b/gi,
   /\b(?:create-story|dev-story)\b/gi,
   /\b(?:Create Story|Dev Story)\b/g,
@@ -26,7 +29,7 @@ export function validatePublishedImplementationModel(siteDir) {
   const llmsPath = path.join(siteDir, 'llms.txt');
   const llmsContent = fs.readFileSync(llmsPath, 'utf-8');
   if (!llmsContent.includes(CANONICAL_LLMS_ENTRY) || !llmsContent.includes(CANONICAL_LLMS_DESCRIPTION)) {
-    throw new Error('llms.txt must describe Quick Dev as canonical for both direct intent and fully planned work');
+    throw new Error('llms.txt must describe Build as canonical for both direct intent and fully planned work');
   }
 }
 

package/web-bundles/prd-coach/prd-template.md

@@ -161,5 +161,5 @@ updated: {YYYY-MM-DD}
 - **Environmental and Reliability Requirements**.
 
 ### Small-scope all-inclusive *(use when scope is 1-2 stories' worth and the user wants a single captured artifact: chosen during the Right-skill check in Discovery)*
-- **Stories**: story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-quick-dev` is the better path; this cluster is only for "I want a doc *and* the stories."
+- **Stories**: story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-build` is the better path; this cluster is only for "I want a doc *and* the stories."