Merge b0318dab0c into 61d89c82ef

* docs: explain quick dev new preview workflow

* docs: refine quick dev new preview explainer

.github/workflows/publish-latest.yaml

@@ -1,82 +0,0 @@
-name: Publish Latest
-
-on:
-  workflow_dispatch:
-    inputs:
-      bump:
-        description: "Version bump type"
-        required: true
-        default: "patch"
-        type: choice
-        options:
-          - patch
-          - minor
-          - major
-
-concurrency:
-  group: publish-latest
-
-permissions:
-  id-token: write
-  contents: write
-
-jobs:
-  publish:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-          token: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Setup Node
-        uses: actions/setup-node@v4
-        with:
-          node-version-file: ".nvmrc"
-          cache: "npm"
-          registry-url: "https://registry.npmjs.org"
-
-      - name: Configure git user
-        run: |
-          git config user.name "github-actions[bot]"
-          git config user.email "github-actions[bot]@users.noreply.github.com"
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Run tests
-        run: npm test
-
-      - name: Bump version
-        run: 'npm version ${{ inputs.bump }} -m "chore(release): v%s [skip ci]"'
-
-      - name: Publish to npm
-        run: npm publish --tag latest --provenance
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
-
-      - name: Push version commit and tag
-        run: git push origin main --follow-tags
-
-      - name: Create GitHub Release
-        run: |
-          TAG="v$(node -p 'require("./package.json").version')"
-          gh release create "$TAG" --generate-notes
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Notify Discord
-        continue-on-error: true
-        run: |
-          set -o pipefail
-          source .github/scripts/discord-helpers.sh
-          [ -z "$WEBHOOK" ] && exit 0
-
-          VERSION=$(node -p 'require("./package.json").version')
-          RELEASE_URL="${{ github.server_url }}/${{ github.repository }}/releases/tag/v${VERSION}"
-          MSG=$(printf '📦 **[bmad-method v%s released](<%s>)**' "$VERSION" "$RELEASE_URL" | esc)
-
-          jq -n --arg content "$MSG" '{content: $content}' | curl -sf --retry 2 -X POST "$WEBHOOK" -H "Content-Type: application/json" -d @-
-        env:
-          WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}

.github/workflows/publish-next.yaml

@@ -1,65 +0,0 @@
-name: Publish Next
-
-on:
-  push:
-    branches: [main]
-    paths:
-      - "src/**"
-      - "tools/cli/**"
-      - "package.json"
-
-concurrency:
-  group: publish-next
-  cancel-in-progress: true
-
-permissions:
-  id-token: write
-  contents: read
-
-jobs:
-  publish:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Setup Node
-        uses: actions/setup-node@v4
-        with:
-          node-version-file: ".nvmrc"
-          cache: "npm"
-          registry-url: "https://registry.npmjs.org"
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Run tests
-        run: npm test
-
-      - name: Derive next prerelease version
-        run: |
-          NEXT_VER=$(npm view bmad-method@next version 2>/dev/null || echo "")
-          LATEST_VER=$(npm view bmad-method@latest version 2>/dev/null || echo "")
-
-          # Determine the best base version for the next prerelease
-          BASE=$(node -e "
-            const semver = require('semver');
-            const next = process.argv[1] || null;
-            const latest = process.argv[2] || null;
-            if (!next && !latest) process.exit(0);
-            if (!next) { console.log(latest); process.exit(0); }
-            if (!latest) { console.log(next); process.exit(0); }
-            // If latest is newer than next's base, use latest (next prerelease will be based on it)
-            const nextBase = next.replace(/-next\.\d+$/, '');
-            console.log(semver.gt(latest, nextBase) ? latest : next);
-          " "$NEXT_VER" "$LATEST_VER")
-
-          if [ -n "$BASE" ]; then
-            npm version "$BASE" --no-git-tag-version --allow-same-version
-          fi
-          npm version prerelease --preid=next --no-git-tag-version
-
-      - name: Publish to npm
-        run: npm publish --tag next --provenance
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

.github/workflows/publish.yaml

@@ -0,0 +1,133 @@
+name: Publish
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - "src/**"
+      - "tools/cli/**"
+      - "package.json"
+  workflow_dispatch:
+    inputs:
+      channel:
+        description: "Publish channel"
+        required: true
+        default: "latest"
+        type: choice
+        options:
+          - latest
+          - next
+      bump:
+        description: "Version bump type (latest channel only)"
+        required: false
+        default: "patch"
+        type: choice
+        options:
+          - patch
+          - minor
+          - major
+
+concurrency:
+  group: publish
+  cancel-in-progress: ${{ github.event_name == 'push' }}
+
+permissions:
+  id-token: write
+  contents: write
+
+jobs:
+  publish:
+    if: github.event_name != 'workflow_dispatch' || github.ref == 'refs/heads/main'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          token: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Setup Node
+        uses: actions/setup-node@v4
+        with:
+          node-version-file: ".nvmrc"
+          cache: "npm"
+
+      - name: Ensure trusted publishing toolchain
+        run: |
+          # npm trusted publishing requires Node >= 22.14.0 and npm >= 11.5.1.
+          npm install --global npm@11.6.2
+
+      - name: Configure git user
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "github-actions[bot]@users.noreply.github.com"
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Run tests
+        run: npm test
+
+      - name: Derive next prerelease version
+        if: github.event_name == 'push' || (github.event_name == 'workflow_dispatch' && inputs.channel == 'next')
+        run: |
+          NEXT_VER=$(npm view bmad-method@next version 2>/dev/null || echo "")
+          LATEST_VER=$(npm view bmad-method@latest version 2>/dev/null || echo "")
+
+          # Determine the best base version for the next prerelease.
+          BASE=$(node -e "
+            const semver = require('semver');
+            const next = process.argv[1] || null;
+            const latest = process.argv[2] || null;
+            if (!next && !latest) process.exit(0);
+            if (!next) { console.log(latest); process.exit(0); }
+            if (!latest) { console.log(next); process.exit(0); }
+            const nextBase = next.replace(/-next\.\d+$/, '');
+            console.log(semver.gt(latest, nextBase) ? latest : next);
+          " "$NEXT_VER" "$LATEST_VER")
+
+          if [ -n "$BASE" ]; then
+            npm version "$BASE" --no-git-tag-version --allow-same-version
+          fi
+          npm version prerelease --preid=next --no-git-tag-version
+
+      - name: Bump stable version
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
+        run: 'npm version ${{ inputs.bump }} -m "chore(release): v%s [skip ci]"'
+
+      - name: Publish prerelease to npm
+        if: github.event_name == 'push' || (github.event_name == 'workflow_dispatch' && inputs.channel == 'next')
+        run: npm publish --tag next --provenance
+
+      - name: Publish stable release to npm
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
+        run: npm publish --tag latest --provenance
+
+      - name: Push version commit and tag
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
+        run: git push origin main --follow-tags
+
+      - name: Create GitHub Release
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
+        run: |
+          TAG="v$(node -p 'require("./package.json").version')"
+          gh release create "$TAG" --generate-notes
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Notify Discord
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
+        continue-on-error: true
+        run: |
+          set -o pipefail
+          source .github/scripts/discord-helpers.sh
+          [ -z "$WEBHOOK" ] && exit 0
+
+          VERSION=$(node -p 'require("./package.json").version')
+          RELEASE_URL="${{ github.server_url }}/${{ github.repository }}/releases/tag/v${VERSION}"
+          MSG=$(printf '📦 **[bmad-method v%s released](<%s>)**' "$VERSION" "$RELEASE_URL" | esc)
+
+          jq -n --arg content "$MSG" '{content: $content}' | curl -sf --retry 2 -X POST "$WEBHOOK" -H "Content-Type: application/json" -d @-
+        env:
+          WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}

docs/explanation/quick-dev-new-preview.md

@@ -0,0 +1,73 @@
+---
+title: "Quick Dev New Preview"
+description: Reduce human-in-the-loop friction without giving up the checkpoints that protect output quality
+sidebar:
+  order: 2
+---
+
+`bmad-quick-dev-new-preview` is an experimental attempt to radically improve Quick Flow: intent in, code changes out, with lower ceremony and fewer human-in-the-loop turns without sacrificing quality.
+
+It lets the model run longer between checkpoints, then brings the human back only when the task cannot safely continue without human judgment or when it is time to review the end result.
+
+![Quick Dev New Preview workflow diagram](/diagrams/quick-dev-diagram.png)
+
+## Why This Exists
+
+Human-in-the-loop turns are necessary and expensive.
+
+Current LLMs still fail in predictable ways: they misread intent, fill gaps with confident guesses, drift into unrelated work, and generate noisy review output. At the same time, constant human intervention limits development velocity. Human attention is the bottleneck.
+
+This experimental version of Quick Flow is an attempt to rebalance that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
+
+## The Core Design
+
+### 1. Compress intent first
+
+The workflow starts by having the human and the model compress the request into one coherent goal. The input can begin as a rough expression of intent, but before the workflow runs autonomously it has to become small enough, clear enough, and contradiction-free enough to execute.
+
+Intent can come in many forms: a couple of phrases, a bug tracker link, output from plan mode, text copied from a chat session, or even a story number from BMAD's own `epics.md`. In that last case, the workflow will not understand BMAD story-tracking semantics, but it can still take the story itself and run with it.
+
+This workflow does not eliminate human control. It relocates it to a small number of high-value moments:
+
+- **Intent clarification** - turning a messy request into one coherent goal without hidden contradictions
+- **Spec approval** - confirming that the frozen understanding is the right thing to build
+- **Review of the final product** - the primary checkpoint, where the human decides whether the result is acceptable at the end
+
+### 2. Route to the smallest safe path
+
+Once the goal is clear, the workflow decides whether this is a true one-shot change or whether it needs the fuller path. Small, zero-blast-radius changes can go straight to implementation. Everything else goes through planning so the model has a stronger boundary before it runs longer on its own.
+
+### 3. Run longer with less supervision
+
+After that routing decision, the model can carry more of the work on its own. On the fuller path, the approved spec becomes the boundary the model executes against with less supervision, which is the whole point of the experiment.
+
+### 4. Diagnose failure at the right layer
+
+If the implementation is wrong because the intent was wrong, patching the code is the wrong fix. If the code is wrong because the spec was weak, patching the diff is also the wrong fix. The workflow is designed to diagnose where the failure entered the system, go back to that layer, and regenerate from there.
+
+Review findings are used to decide whether the problem came from intent, spec generation, or local implementation. Only truly local problems get patched locally.
+
+### 5. Bring the human back only when needed
+
+The intent interview is human-in-the-loop, but it is not the same kind of interruption as a recurring checkpoint. The workflow tries to keep those recurring checkpoints to a minimum. After the initial shaping of intent, the human mainly comes back when the workflow cannot safely continue without judgment and at the end, when it is time to review the result.
+
+- **Intent-gap resolution** - stepping back in when review proves the workflow could not safely infer what was meant
+
+Everything else is a candidate for longer autonomous execution. That tradeoff is deliberate. Older patterns spend more human attention on continuous supervision. Quick Dev New Preview spends more trust on the model, but saves human attention for the moments where human reasoning has the highest leverage.
+
+## Why the Review System Matters
+
+The review phase is not just there to find bugs. It is there to route correction without destroying momentum.
+
+This workflow works best on a platform that can spawn subagents, or at least invoke another LLM through the command line and wait for a result. If your platform does not support that natively, you can add a skill to do it. Context-free subagents are a cornerstone of the review design.
+
+Agentic reviews often go wrong in two ways:
+
+- They generate too many findings, forcing the human to sift through noise.
+- They derail the current change by surfacing unrelated issues and turning every run into an ad hoc cleanup project.
+
+Quick Dev New Preview addresses both by treating review as triage.
+
+Some findings belong to the current change. Some do not. If a finding is incidental rather than causally tied to the current work, the workflow can defer it instead of forcing the human to handle it immediately. That keeps the run focused and prevents random tangents from consuming the budget of attention.
+
+That triage will sometimes be imperfect. That is acceptable. It is usually better to misjudge some findings than to flood the human with thousands of low-value review comments. The system is optimizing for signal quality, not exhaustive recall.

docs/explanation/quick-flow.md

@@ -7,6 +7,10 @@ sidebar:
 
 Skip the ceremony. Quick Flow takes you from idea to working code in two skills - no Product Brief, no PRD, no Architecture doc.
 
+:::tip[Want a Unified Variant?]
+If you want one workflow to clarify, plan, implement, review, and present in a single run, see [Quick Dev New Preview](./quick-dev-new-preview.md).
+:::
+
 ## When to Use It
 
 - Bug fixes and patches

src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-02-design-epics.md

@@ -76,7 +76,8 @@ Load {outputFile} and review:
 2. **Requirements Grouping**: Group related FRs that deliver cohesive user outcomes
 3. **Incremental Delivery**: Each epic should deliver value independently
 4. **Logical Flow**: Natural progression from user's perspective
-5. **🔗 Dependency-Free Within Epic**: Stories within an epic must NOT depend on future stories
+5. **Dependency-Free Within Epic**: Stories within an epic must NOT depend on future stories
+6. **Implementation Efficiency**: Consider consolidating epics that all modify the same core files into fewer epics
 
 **⚠️ CRITICAL PRINCIPLE:**
 Organize by USER VALUE, not technical layers:
@@ -95,6 +96,18 @@ Organize by USER VALUE, not technical layers:
 - Epic 3: Frontend Components (creates reusable components) - **No user value**
 - Epic 4: Deployment Pipeline (CI/CD setup) - **No user value**
 
+**❌ WRONG Epic Examples (File Churn on Same Component):**
+
+- Epic 1: File Upload (modifies model, controller, web form, web API)
+- Epic 2: File Status (modifies model, controller, web form, web API)
+- Epic 3: File Access permissions (modifies model, controller, web form, web API)
+- All three epics touch the same files — consolidate into one epic with ordered stories
+
+**✅ CORRECT Alternative:**
+
+- Epic 1: File Management Enhancement (upload, status, permissions as stories within one epic)
+- Rationale: Single component, fully pre-designed, no feedback loop between epics
+
 **🔗 DEPENDENCY RULES:**
 
 - Each epic must deliver COMPLETE functionality for its domain
@@ -103,21 +116,38 @@ Organize by USER VALUE, not technical layers:
 
 ### 3. Design Epic Structure Collaboratively
 
-**Step A: Identify User Value Themes**
+**Step A: Assess Context and Identify Themes**
+
+First, assess how much of the solution design is already validated (Architecture, UX, Test Design).
+When the outcome is certain and direction changes between epics are unlikely, prefer fewer but larger epics.
+Split into multiple epics when there is a genuine risk boundary or when early feedback could change direction
+of following epics.
+
+Then, identify user value themes:
 
 - Look for natural groupings in the FRs
 - Identify user journeys or workflows
 - Consider user types and their goals
 
 **Step B: Propose Epic Structure**
-For each proposed epic:
+
+For each proposed epic (considering whether epics share the same core files):
 
 1. **Epic Title**: User-centric, value-focused
 2. **User Outcome**: What users can accomplish after this epic
 3. **FR Coverage**: Which FR numbers this epic addresses
 4. **Implementation Notes**: Any technical or UX considerations
 
-**Step C: Create the epics_list**
+**Step C: Review for File Overlap**
+
+Assess whether multiple proposed epics repeatedly target the same core files. If overlap is significant:
+
+- Distinguish meaningful overlap (same component end-to-end) from incidental sharing
+- Ask whether to consolidate into one epic with ordered stories
+- If confirmed, merge the epic FRs into a single epic, preserving dependency flow: each story must still fit within
+  a single dev agent's context
+
+**Step D: Create the epics_list**
 
 Format the epics_list as:
 

src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-04-final-validation.md

@@ -110,6 +110,12 @@ Review the complete epic and story breakdown to ensure EVERY FR is covered:
 - Dependencies flow naturally
 - Foundation stories only setup what's needed
 - No big upfront technical work
+- **File Churn Check:** Do multiple epics repeatedly modify the same core files?
+  - Assess whether the overlap pattern suggests unnecessary churn or is incidental
+  - If overlap is significant: Validate that splitting provides genuine value (risk mitigation, feedback loops, context size limits)
+  - If no justification for the split: Recommend consolidation into fewer epics
+  - ❌ WRONG: Multiple epics each modify the same core files with no feedback loop between them
+  - ✅ RIGHT: Epics target distinct files/components, OR consolidation was explicitly considered and rejected with rationale
 
 ### 5. Dependency Validation (CRITICAL)
 

tools/build-docs.mjs

@@ -161,6 +161,7 @@ function generateLlmsTxt(outputDir) {
     '## Core Concepts',
     '',
     `- **[Quick Flow](${siteUrl}/explanation/quick-flow/)** - Fast development workflow`,
+    `- **[Quick Dev New Preview](${siteUrl}/explanation/quick-dev-new-preview/)** - Unified quick workflow with planning, implementation, and review in one run`,
     `- **[Party Mode](${siteUrl}/explanation/party-mode/)** - Multi-agent collaboration`,
     `- **[Workflow Map](${siteUrl}/reference/workflow-map/)** - Visual overview of phases and workflows`,
     '',