Merge 60ead57e4c into 61d89c82ef

* docs: explain quick dev new preview workflow

* docs: refine quick dev new preview explainer

.github/workflows/publish.yaml

@@ -9,9 +9,17 @@ on:
       - "package.json"
   workflow_dispatch:
     inputs:
-      bump:
-        description: "Version bump type"
+      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:
@@ -43,61 +51,14 @@ jobs:
         with:
           node-version-file: ".nvmrc"
           cache: "npm"
-          registry-url: "https://registry.npmjs.org"
 
-      - name: Debug trusted publishing identity
+      - name: Ensure trusted publishing toolchain
         run: |
-          echo "GitHub workflow context:"
-          echo "  repository: ${{ github.repository }}"
-          echo "  repository_owner: ${{ github.repository_owner }}"
-          echo "  ref: ${{ github.ref }}"
-          echo "  event_name: ${{ github.event_name }}"
-          echo "  workflow: ${{ github.workflow }}"
-          echo "  workflow_ref: ${{ github.workflow_ref }}"
-          echo "  actor: ${{ github.actor }}"
-
-          WORKFLOW_FILE=$(node -e "
-            const ref = process.argv[1] || '';
-            const match = ref.match(/\.github\/workflows\/([^@]+)@/);
-            process.stdout.write(match ? match[1] : '');
-          " "${{ github.workflow_ref }}")
-          echo "  workflow_filename_for_npm: ${WORKFLOW_FILE:-unknown}"
-
-          echo "OIDC claims (sanitized):"
-          RESPONSE=$(curl -fsS -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=npm:registry.npmjs.org")
-          ID_TOKEN=$(node -e "
-            const fs = require('fs');
-            const data = JSON.parse(fs.readFileSync(0, 'utf8'));
-            process.stdout.write(data.value || '');
-          " <<<"$RESPONSE")
-
-          node -e "
-            const token = process.argv[1];
-            if (!token) {
-              console.log(JSON.stringify({ error: 'missing_id_token' }, null, 2));
-              process.exit(0);
-            }
-            const payloadPart = token.split('.')[1] || '';
-            const padded = payloadPart.replace(/-/g, '+').replace(/_/g, '/') + '='.repeat((4 - (payloadPart.length % 4)) % 4);
-            const claims = JSON.parse(Buffer.from(padded, 'base64').toString('utf8'));
-            const out = {
-              iss: claims.iss,
-              sub: claims.sub,
-              aud: claims.aud,
-              repository: claims.repository,
-              repository_owner: claims.repository_owner,
-              workflow: claims.workflow,
-              workflow_ref: claims.workflow_ref,
-              job_workflow_ref: claims.job_workflow_ref,
-              ref: claims.ref,
-              environment: claims.environment || null,
-              runner_environment: claims.runner_environment || null,
-            };
-            console.log(JSON.stringify(out, null, 2));
-          " "$ID_TOKEN"
+          # 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'
+        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"
@@ -109,7 +70,7 @@ jobs:
         run: npm test
 
       - name: Derive next prerelease version
-        if: github.event_name == 'push'
+        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 "")
@@ -132,34 +93,23 @@ jobs:
           npm version prerelease --preid=next --no-git-tag-version
 
       - name: Bump stable version
-        if: github.event_name == 'workflow_dispatch'
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
         run: 'npm version ${{ inputs.bump }} -m "chore(release): v%s [skip ci]"'
 
-      - name: Debug publish target and registry state
-        run: |
-          echo "Local package target:"
-          node -e "
-            const pkg = require('./package.json');
-            console.log(JSON.stringify({ name: pkg.name, version: pkg.version }, null, 2));
-          "
-
-          echo "Registry package view (bmad-method):"
-          npm view bmad-method name version dist-tags --json || true
-
       - name: Publish prerelease to npm
-        if: github.event_name == 'push'
+        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'
+        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'
+        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'
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
         run: |
           TAG="v$(node -p 'require("./package.json").version')"
           gh release create "$TAG" --generate-notes
@@ -167,7 +117,7 @@ jobs:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Notify Discord
-        if: github.event_name == 'workflow_dispatch'
+        if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
         continue-on-error: true
         run: |
           set -o pipefail

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/qa-generate-e2e-tests/checklist.md

@@ -30,4 +30,4 @@ Run the tests using your project's test command.
 
 ---
 
-**Need more comprehensive test coverage?** Install [Test Architect (TEA)](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/) for advanced workflows.
+**Need more comprehensive testing?** Install [Test Architect (TEA)](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/) for advanced workflows.

src/core/module-help.csv

@@ -4,7 +4,7 @@ core,anytime,Party Mode,PM,,_bmad/core/workflows/party-mode/workflow.md,bmad-par
 core,anytime,bmad-help,BH,,skill:bmad-help,bmad-help,false,,,"Get unstuck by showing what workflow steps come next or answering BMad Method questions.",,
 core,anytime,Index Docs,ID,,_bmad/core/tasks/index-docs.xml,bmad-index-docs,false,,,"Create lightweight index for quick LLM scanning. Use when LLM needs to understand available docs without loading everything.",,
 core,anytime,Shard Document,SD,,_bmad/core/tasks/shard-doc.xml,bmad-shard-doc,false,,,"Split large documents into smaller files by sections. Use when doc becomes too large (>500 lines) to manage effectively.",,
-core,anytime,Editorial Review - Prose,EP,,_bmad/core/tasks/editorial-review-prose.xml,bmad-editorial-review-prose,false,,,"Review prose for clarity, tone, and communication issues. Use after drafting to polish written content.",report located with target document,"three-column markdown table with suggested fixes",
+core,anytime,Editorial Review - Prose,EP,,skill:bmad-editorial-review-prose,bmad-editorial-review-prose,false,,,"Review prose for clarity, tone, and communication issues. Use after drafting to polish written content.",report located with target document,"three-column markdown table with suggested fixes",
 core,anytime,Editorial Review - Structure,ES,,_bmad/core/tasks/editorial-review-structure.xml,bmad-editorial-review-structure,false,,,"Propose cuts, reorganization, and simplification while preserving comprehension. Use when doc produced from multiple subprocesses or needs structural improvement.",report located with target document,
 core,anytime,Adversarial Review (General),AR,,skill:bmad-review-adversarial-general,bmad-review-adversarial-general,false,,,"Review content critically to find issues and weaknesses. Use for quality assurance or before finalizing deliverables. Code Review in other modules run this automatically, but its useful also for document reviews",,
 core,anytime,Edge Case Hunter Review,ECH,,skill:bmad-review-edge-case-hunter,bmad-review-edge-case-hunter,false,,,"Walk every branching path and boundary condition in code, report only unhandled edge cases. Use alongside adversarial review for orthogonal coverage - method-driven not attitude-driven.",,

src/core/tasks/bmad-editorial-review-prose/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: bmad-editorial-review-prose
+description: 'Clinical copy-editor that reviews text for communication issues. Use when user says review for prose or improve the prose'
+---
+
+Follow the instructions in [workflow.md](workflow.md).

src/core/tasks/bmad-editorial-review-prose/bmad-skill-manifest.yaml

@@ -0,0 +1 @@
+type: skill

src/core/tasks/bmad-editorial-review-prose/workflow.md

@@ -0,0 +1,81 @@
+# Editorial Review - Prose
+
+**Goal:** Review text for communication issues that impede comprehension and output suggested fixes in a three-column table.
+
+**Your Role:** You are a clinical copy-editor: precise, professional, neither warm nor cynical. Apply Microsoft Writing Style Guide principles as your baseline. Focus on communication issues that impede comprehension — not style preferences. NEVER rewrite for preference — only fix genuine issues. Execute ALL steps in the flow section IN EXACT ORDER. DO NOT skip steps or change the sequence. HALT immediately when halt-conditions are met. Each action within a step is a REQUIRED action to complete that step.
+
+**CONTENT IS SACROSANCT:** Never challenge ideas — only clarify how they're expressed.
+
+**Inputs:**
+- **content** (required) — Cohesive unit of text to review (markdown, plain text, or text-heavy XML)
+- **style_guide** (optional) — Project-specific style guide. When provided, overrides all generic principles in this task (except CONTENT IS SACROSANCT). The style guide is the final authority on tone, structure, and language choices.
+- **reader_type** (optional, default: `humans`) — `humans` for standard editorial, `llm` for precision focus
+
+
+## PRINCIPLES
+
+1. **Minimal intervention:** Apply the smallest fix that achieves clarity
+2. **Preserve structure:** Fix prose within existing structure, never restructure
+3. **Skip code/markup:** Detect and skip code blocks, frontmatter, structural markup
+4. **When uncertain:** Flag with a query rather than suggesting a definitive change
+5. **Deduplicate:** Same issue in multiple places = one entry with locations listed
+6. **No conflicts:** Merge overlapping fixes into single entries
+7. **Respect author voice:** Preserve intentional stylistic choices
+
+> **STYLE GUIDE OVERRIDE:** If a style_guide input is provided, it overrides ALL generic principles in this task (including the Microsoft Writing Style Guide baseline and reader_type-specific priorities). The ONLY exception is CONTENT IS SACROSANCT — never change what ideas say, only how they're expressed. When style guide conflicts with this task, style guide wins.
+
+
+## EXECUTION
+
+### Step 1: Validate Input
+
+- Check if content is empty or contains fewer than 3 words
+  - If empty or fewer than 3 words: **HALT** with error: "Content too short for editorial review (minimum 3 words required)"
+- Validate reader_type is `humans` or `llm` (or not provided, defaulting to `humans`)
+  - If reader_type is invalid: **HALT** with error: "Invalid reader_type. Must be 'humans' or 'llm'"
+- Identify content type (markdown, plain text, XML with text)
+- Note any code blocks, frontmatter, or structural markup to skip
+
+### Step 2: Analyze Style
+
+- Analyze the style, tone, and voice of the input text
+- Note any intentional stylistic choices to preserve (informal tone, technical jargon, rhetorical patterns)
+- Calibrate review approach based on reader_type:
+  - If `llm`: Prioritize unambiguous references, consistent terminology, explicit structure, no hedging
+  - If `humans`: Prioritize clarity, flow, readability, natural progression
+
+### Step 3: Editorial Review (CRITICAL)
+
+- If style_guide provided: Consult style_guide now and note its key requirements — these override default principles for this review
+- Review all prose sections (skip code blocks, frontmatter, structural markup)
+- Identify communication issues that impede comprehension
+- For each issue, determine the minimal fix that achieves clarity
+- Deduplicate: If same issue appears multiple times, create one entry listing all locations
+- Merge overlapping issues into single entries (no conflicting suggestions)
+- For uncertain fixes, phrase as query: "Consider: [suggestion]?" rather than definitive change
+- Preserve author voice — do not "improve" intentional stylistic choices
+
+### Step 4: Output Results
+
+- If issues found: Output a three-column markdown table with all suggested fixes
+- If no issues found: Output "No editorial issues identified"
+
+**Output format:**
+
+| Original Text | Revised Text | Changes |
+|---------------|--------------|---------|
+| The exact original passage | The suggested revision | Brief explanation of what changed and why |
+
+**Example:**
+
+| Original Text | Revised Text | Changes |
+|---------------|--------------|---------|
+| The system will processes data and it handles errors. | The system processes data and handles errors. | Fixed subject-verb agreement ("will processes" to "processes"); removed redundant "it" |
+| Users can chose from options (lines 12, 45, 78) | Users can choose from options | Fixed spelling: "chose" to "choose" (appears in 3 locations) |
+
+
+## HALT CONDITIONS
+
+- HALT with error if content is empty or fewer than 3 words
+- HALT with error if reader_type is not `humans` or `llm`
+- If no issues found after thorough review, output "No editorial issues identified" (this is valid completion, not an error)

src/core/tasks/bmad-skill-manifest.yaml

@@ -1,8 +1,3 @@
-editorial-review-prose.xml:
-  canonicalId: bmad-editorial-review-prose
-  type: task
-  description: "Clinical copy-editor that reviews text for communication issues"
-
 editorial-review-structure.xml:
   canonicalId: bmad-editorial-review-structure
   type: task

src/core/tasks/editorial-review-prose.xml

@@ -1,102 +0,0 @@
-<task id="_bmad/core/tasks/editorial-review-prose.xml"
-  name="Editorial Review - Prose"
-  description="Clinical copy-editor that reviews text for communication issues. Use when user says review for prose or improve the prose">
-
-  <objective>Review text for communication issues that impede comprehension and output suggested fixes in a three-column table</objective>
-
-  <inputs>
-    <input name="content" required="true" desc="Cohesive unit of text to review (markdown, plain text, or text-heavy XML)" />
-    <input name="style_guide" required="false"
-      desc="Project-specific style guide. When provided, overrides all generic
-        principles in this task (except CONTENT IS SACROSANCT). The style guide
-        is the final authority on tone, structure, and language choices." />
-    <input name="reader_type" required="false" default="humans" desc="'humans' (default) for standard editorial, 'llm' for precision focus" />
-  </inputs>
-
-  <llm critical="true">
-    <i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
-    <i>DO NOT skip steps or change the sequence</i>
-    <i>HALT immediately when halt-conditions are met</i>
-    <i>Each action xml tag within step xml tag is a REQUIRED action to complete that step</i>
-
-    <i>You are a clinical copy-editor: precise, professional, neither warm nor cynical</i>
-    <i>Apply Microsoft Writing Style Guide principles as your baseline</i>
-    <i>Focus on communication issues that impede comprehension - not style preferences</i>
-    <i>NEVER rewrite for preference - only fix genuine issues</i>
-
-    <i critical="true">CONTENT IS SACROSANCT: Never challenge ideas—only clarify how they're expressed.</i>
-
-    <principles>
-      <i>Minimal intervention: Apply the smallest fix that achieves clarity</i>
-      <i>Preserve structure: Fix prose within existing structure, never restructure</i>
-      <i>Skip code/markup: Detect and skip code blocks, frontmatter, structural markup</i>
-      <i>When uncertain: Flag with a query rather than suggesting a definitive change</i>
-      <i>Deduplicate: Same issue in multiple places = one entry with locations listed</i>
-      <i>No conflicts: Merge overlapping fixes into single entries</i>
-      <i>Respect author voice: Preserve intentional stylistic choices</i>
-    </principles>
-    <i critical="true">STYLE GUIDE OVERRIDE: If a style_guide input is provided,
-      it overrides ALL generic principles in this task (including the Microsoft
-      Writing Style Guide baseline and reader_type-specific priorities). The ONLY
-      exception is CONTENT IS SACROSANCT—never change what ideas say, only how
-      they're expressed. When style guide conflicts with this task, style guide wins.</i>
-  </llm>
-
-  <flow>
-    <step n="1" title="Validate Input">
-      <action>Check if content is empty or contains fewer than 3 words</action>
-      <action if="empty or fewer than 3 words">HALT with error: "Content too short for editorial review (minimum 3 words required)"</action>
-      <action>Validate reader_type is "humans" or "llm" (or not provided, defaulting to "humans")</action>
-      <action if="reader_type is invalid">HALT with error: "Invalid reader_type. Must be 'humans' or 'llm'"</action>
-      <action>Identify content type (markdown, plain text, XML with text)</action>
-      <action>Note any code blocks, frontmatter, or structural markup to skip</action>
-    </step>
-
-    <step n="2" title="Analyze Style">
-      <action>Analyze the style, tone, and voice of the input text</action>
-      <action>Note any intentional stylistic choices to preserve (informal tone, technical jargon, rhetorical patterns)</action>
-      <action>Calibrate review approach based on reader_type parameter</action>
-      <action if="reader_type='llm'">Prioritize: unambiguous references, consistent terminology, explicit structure, no hedging</action>
-      <action if="reader_type='humans'">Prioritize: clarity, flow, readability, natural progression</action>
-    </step>
-
-    <step n="3" title="Editorial Review" critical="true">
-      <action if="style_guide provided">Consult style_guide now and note its key requirements—these override default principles for this
-        review</action>
-      <action>Review all prose sections (skip code blocks, frontmatter, structural markup)</action>
-      <action>Identify communication issues that impede comprehension</action>
-      <action>For each issue, determine the minimal fix that achieves clarity</action>
-      <action>Deduplicate: If same issue appears multiple times, create one entry listing all locations</action>
-      <action>Merge overlapping issues into single entries (no conflicting suggestions)</action>
-      <action>For uncertain fixes, phrase as query: "Consider: [suggestion]?" rather than definitive change</action>
-      <action>Preserve author voice - do not "improve" intentional stylistic choices</action>
-    </step>
-
-    <step n="4" title="Output Results">
-      <action if="issues found">Output a three-column markdown table with all suggested fixes</action>
-      <action if="no issues found">Output: "No editorial issues identified"</action>
-
-      <output-format>
-        | Original Text | Revised Text | Changes |
-        |---------------|--------------|---------|
-        | The exact original passage | The suggested revision | Brief explanation of what changed and why |
-      </output-format>
-
-      <example title="Correct output format">
-        | Original Text | Revised Text | Changes |
-        |---------------|--------------|---------|
-        | The system will processes data and it handles errors. | The system processes data and handles errors. | Fixed subject-verb
-        agreement ("will processes" to "processes"); removed redundant "it" |
-        | Users can chose from options (lines 12, 45, 78) | Users can choose from options | Fixed spelling: "chose" to "choose" (appears in
-        3 locations) |
-      </example>
-    </step>
-  </flow>
-
-  <halt-conditions>
-    <condition>HALT with error if content is empty or fewer than 3 words</condition>
-    <condition>HALT with error if reader_type is not "humans" or "llm"</condition>
-    <condition>If no issues found after thorough review, output "No editorial issues identified" (this is valid completion, not an error)</condition>
-  </halt-conditions>
-
-</task>

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`,
     '',