Merge 2e1949df76 into 35a7f101dd

* feat(quick-flow): add quick-dev2 unified workflow

Add the quick-dev2 workflow that unifies clarify, plan, implement,
review, and present into a single flow. Register it in the agent
menu, module-help catalog, and test fixtures.

* fix(quick-flow): rename QD2 trigger to QQ for schema compliance

COMPOUND_TRIGGER_PATTERN only allows uppercase letters in shortcuts.
Rename to QQ so quick-dev2 passes agent schema validation.

* fix(quick-flow): address PR review findings for quick-dev2

- step-04-review: fix copy-paste fallback text to say "perform all
  three reviews inline sequentially" instead of "implement directly"
- workflow.md: add missing planning_artifacts to initialization list,
  matching quick-spec and quick-dev siblings
- quick-flow-solo-dev.agent.yaml: change QD and QQ menu entries from
  workflow: to exec: for .md files, matching the exec-for-md convention

* fix(quick-flow): use human-in-the-loop fallback for review without subagents

Sequential inline reviews in the same context suffer from anchoring
bias and context blowout. Instead, generate separate review prompt
files and ask the human to run each in a separate session.

* refactor(quick-flow): rename quick-dev2 to quick-dev-new-preview

Rename directory, update all references in agent menu, module-help,
and workflow internals.

.github/instructions/*.instructions.md

@@ -0,0 +1,3 @@
+# Rules
+* Never creates PRs for altering  code after review. Always offer a fix and the option to commit.
+* Qualify the severity of the change requested. NORMAL | IMPROVEMENT | FIX | CRITICAL

src/bmm/agents/analyst.agent.yaml

@@ -41,3 +41,7 @@ agent:
     - trigger: DP or fuzzy match on document-project
       workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
       description: "[DP] Document Project: Analyze an existing project to produce useful documentation for both human and LLM"
+
+    - trigger: KS or fuzzy match on knowledge-sync
+      exec: "{project-root}/_bmad/bmm/workflows/4-implementation/genai-knowledge-sync/workflow.md"
+      description: "[KS] Knowledge Sync: Build a RAG-ready knowledge index from project artifacts for optimized AI agent retrieval"

src/bmm/agents/quick-flow-solo-dev.agent.yaml

@@ -24,9 +24,13 @@ agent:
       description: "[QS] Quick Spec: Architect a quick but complete technical spec with implementation-ready stories/specs"
 
     - trigger: QD or fuzzy match on quick-dev
-      workflow: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md"
+      exec: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md"
       description: "[QD] Quick-flow Develop: Implement a story tech spec end-to-end (Core of Quick Flow)"
 
+    - trigger: QQ or fuzzy match on quick-dev-new-preview
+      exec: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/workflow.md"
+      description: "[QQ] Quick Dev New (Preview): Unified quick flow — clarify intent, plan, implement, review, present (experimental)"
+
     - trigger: CR or fuzzy match on code-review
       workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml"
       description: "[CR] Code Review: Initiate a comprehensive code review across multiple quality facets. For best results, use a fresh context and a different quality LLM if available"

src/bmm/module-help.csv

@@ -3,6 +3,7 @@ bmm,anytime,Document Project,DP,,_bmad/bmm/workflows/document-project/workflow.y
 bmm,anytime,Generate Project Context,GPC,,_bmad/bmm/workflows/generate-project-context/workflow.md,bmad-bmm-generate-project-context,false,analyst,Create Mode,"Scan existing codebase to generate a lean LLM-optimized project-context.md containing critical implementation rules patterns and conventions for AI agents. Essential for brownfield projects and quick-flow.",output_folder,"project context",
 bmm,anytime,Quick Spec,QS,,_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md,bmad-bmm-quick-spec,false,quick-flow-solo-dev,Create Mode,"Do not suggest for potentially very complex things unless requested or if the user complains that they do not want to follow the extensive planning of the bmad method. Quick one-off tasks small changes simple apps brownfield additions to well established patterns utilities without extensive planning",planning_artifacts,"tech spec",
 bmm,anytime,Quick Dev,QD,,_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md,bmad-bmm-quick-dev,false,quick-flow-solo-dev,Create Mode,"Quick one-off tasks small changes simple apps utilities without extensive planning - Do not suggest for potentially very complex things unless requested or if the user complains that they do not want to follow the extensive planning of the bmad method, unless the user is already working through the implementation phase and just requests a 1 off things not already in the plan",,,
+bmm,anytime,Quick Dev New Preview,QQ,,_bmad/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/workflow.md,bmad-bmm-quick-dev-new-preview,false,quick-flow-solo-dev,Create Mode,"Unified quick flow (experimental): clarify intent plan implement review and present in a single workflow",implementation_artifacts,"tech spec implementation",
 bmm,anytime,Correct Course,CC,,_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml,bmad-bmm-correct-course,false,sm,Create Mode,"Anytime: Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories",planning_artifacts,"change proposal",
 bmm,anytime,Write Document,WD,,_bmad/bmm/agents/tech-writer/tech-writer.agent.yaml,,false,tech-writer,,"Describe in detail what you want, and the agent will follow the documentation best practices defined in agent memory. Multi-turn conversation with subprocess for research/review.",project-knowledge,"document",
 bmm,anytime,Update Standards,US,,_bmad/bmm/agents/tech-writer/tech-writer.agent.yaml,,false,tech-writer,,"Update agent memory documentation-standards.md with your specific preferences if you discover missing document conventions.",_bmad/_memory/tech-writer-sidecar,"standards",

src/bmm/workflows/4-implementation/genai-knowledge-sync/knowledge-index-template.md

@@ -0,0 +1,86 @@
+---
+project_name: ''
+user_name: ''
+date: ''
+total_chunks: 0
+sources_indexed: 0
+tag_vocabulary_size: 0
+retrieval_tested: false
+status: 'draft'
+---
+
+# Knowledge Index for {{project_name}}
+
+_RAG-optimized knowledge base for AI agent retrieval. Each chunk is self-contained and tagged for semantic search._
+
+---
+
+## Index Summary
+
+- **Total Chunks:** {{total_count}}
+- **Critical:** {{critical_count}} | **High:** {{high_count}} | **Standard:** {{standard_count}} | **Reference:** {{ref_count}}
+- **Sources Indexed:** {{source_count}}
+- **Last Synced:** {{date}}
+
+---
+
+## Critical Knowledge
+
+<!-- Critical-priority chunks go here. These are retrieved for every implementation task. -->
+
+---
+
+## Architecture Knowledge
+
+<!-- Architecture decisions, system design patterns, and technology choices. -->
+
+---
+
+## Requirements Knowledge
+
+<!-- Business rules, acceptance criteria, and constraints. -->
+
+---
+
+## Implementation Knowledge
+
+<!-- Coding patterns, conventions, and implementation rules. -->
+
+---
+
+## Domain Knowledge
+
+<!-- Business domain concepts, terminology, and definitions. -->
+
+---
+
+## Operations Knowledge
+
+<!-- Deployment, monitoring, and workflow rules. -->
+
+---
+
+## Quality Knowledge
+
+<!-- Testing patterns, review standards, and anti-patterns. -->
+
+---
+
+## Retrieval Configuration
+
+### Query Mapping
+
+| Query Pattern | Target Categories | Priority Filter | Expected Chunks |
+|---|---|---|---|
+| "how to implement \*" | implementation, architecture | critical, high | 3-5 |
+| "testing requirements for \*" | quality, implementation | critical, high | 2-4 |
+| "business rules for \*" | requirements, domain | all | 2-3 |
+| "architecture decision for \*" | architecture | all | 1-3 |
+| "deployment process for \*" | operations | all | 1-2 |
+
+### Embedding Recommendations
+
+- **Model:** Use an embedding model that handles technical content well
+- **Chunk Overlap:** 50-100 characters overlap between adjacent chunks from the same source
+- **Metadata Filters:** Always filter by category and priority for focused retrieval
+- **Top-K:** Retrieve 3-5 chunks per query for optimal context balance

src/bmm/workflows/4-implementation/genai-knowledge-sync/steps/step-01-discover.md

@@ -0,0 +1,179 @@
+# Step 1: Artifact Discovery & Catalog
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+- ✅ ALWAYS treat this as collaborative discovery between technical peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on discovering and cataloging all relevant project artifacts
+- 🎯 IDENTIFY sources that provide high-value knowledge for RAG retrieval
+- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- 📖 Read existing project files to catalog available artifacts
+- 💾 Initialize document and update frontmatter
+- 🚫 FORBIDDEN to load next step until discovery is complete
+
+## CONTEXT BOUNDARIES:
+
+- Variables from workflow.md are available in memory
+- Focus on existing project artifacts and documentation
+- Identify documents that contain reusable knowledge for AI agents
+- Prioritize artifacts that prevent implementation mistakes and provide domain context
+
+## YOUR TASK:
+
+Discover, catalog, and classify all project artifacts that should be indexed for RAG retrieval by AI agents.
+
+## DISCOVERY SEQUENCE:
+
+### 1. Check for Existing Knowledge Index
+
+First, check if a knowledge index already exists:
+
+- Look for file at `{project_knowledge}/knowledge-index.md` or `{project-root}/**/knowledge-index.md`
+- If exists: Read complete file to understand existing index
+- Present to user: "Found existing knowledge index with {{chunk_count}} chunks across {{source_count}} sources. Would you like to update this or create a new one?"
+
+### 2. Scan Planning Artifacts
+
+Search `{planning_artifacts}` for documents containing project knowledge:
+
+**Product Requirements:**
+
+- Look for PRD files (`*prd*`, `*requirements*`)
+- Extract key decisions, constraints, and acceptance criteria
+- Note sections with high reuse value for agents
+
+**Architecture Documents:**
+
+- Look for architecture files (`*architecture*`, `*design*`)
+- Extract technology decisions, patterns, and trade-offs
+- Identify integration points and system boundaries
+
+**Epic and Story Files:**
+
+- Look for epic/story definitions (`*epic*`, `*stories*`)
+- Extract acceptance criteria, implementation notes, and dependencies
+- Identify cross-cutting concerns that appear across stories
+
+### 3. Scan Implementation Artifacts
+
+Search `{implementation_artifacts}` for implementation knowledge:
+
+**Sprint and Status Files:**
+
+- Look for sprint status, retrospectives, and course corrections
+- Extract lessons learned and pattern changes
+- Identify recurring issues and their resolutions
+
+**Code Review Findings:**
+
+- Look for code review artifacts
+- Extract quality patterns and anti-patterns discovered
+- Note corrections that should inform future implementation
+
+### 4. Scan Project Knowledge
+
+Search `{project_knowledge}` for existing knowledge assets:
+
+**Project Context:**
+
+- Look for `project-context.md` and similar files
+- Extract implementation rules and coding conventions
+- These are high-priority sources for RAG retrieval
+
+**Research Documents:**
+
+- Look for research outputs (market, domain, technical)
+- Extract findings that inform implementation decisions
+- Identify domain terminology and definitions
+
+### 5. Scan Source Code for Patterns
+
+Identify key code patterns worth indexing:
+
+**Configuration Files:**
+
+- Package manifests, build configs, linting rules
+- Extract version constraints and tool configurations
+- These provide critical context for code generation
+
+**Key Source Files:**
+
+- Identify entry points, shared utilities, and core modules
+- Extract patterns that define the project's coding style
+- Note any non-obvious conventions visible only in code
+
+### 6. Classify and Prioritize Sources
+
+For each discovered artifact, assign:
+
+**Knowledge Category:**
+
+- `architecture` - System design decisions and patterns
+- `requirements` - Business rules and acceptance criteria
+- `implementation` - Coding patterns and conventions
+- `domain` - Business domain concepts and terminology
+- `operations` - Deployment, monitoring, and workflow rules
+- `quality` - Testing patterns, review standards, and anti-patterns
+
+**Retrieval Priority:**
+
+- `critical` - Must be retrieved for every implementation task
+- `high` - Should be retrieved for related implementation tasks
+- `standard` - Available when specifically relevant
+- `reference` - Background context when explicitly needed
+
+### 7. Present Discovery Summary
+
+Report findings to user:
+
+"Welcome {{user_name}}! I've scanned your project {{project_name}} to catalog artifacts for your RAG knowledge base.
+
+**Artifacts Discovered:**
+
+| Category | Count | Priority Breakdown |
+|---|---|---|
+| Architecture | {{count}} | {{critical}}/{{high}}/{{standard}} |
+| Requirements | {{count}} | {{critical}}/{{high}}/{{standard}} |
+| Implementation | {{count}} | {{critical}}/{{high}}/{{standard}} |
+| Domain | {{count}} | {{critical}}/{{high}}/{{standard}} |
+| Operations | {{count}} | {{critical}}/{{high}}/{{standard}} |
+| Quality | {{count}} | {{critical}}/{{high}}/{{standard}} |
+
+**Source Files Cataloged:** {{total_files}}
+
+**Recommended Chunking Strategy:**
+Based on your artifact types, I recommend {{strategy}} chunking:
+- {{strategy_rationale}}
+
+Ready to index and chunk your project knowledge for RAG retrieval.
+
+[C] Continue to knowledge indexing"
+
+## SUCCESS METRICS:
+
+✅ All relevant project artifacts discovered and cataloged
+✅ Each artifact classified by category and retrieval priority
+✅ Source file paths accurately recorded
+✅ Chunking strategy recommended based on artifact analysis
+✅ Discovery findings clearly presented to user
+✅ User ready to proceed with indexing
+
+## FAILURE MODES:
+
+❌ Missing critical artifacts in planning or implementation directories
+❌ Not checking for existing knowledge index before creating new one
+❌ Incorrect classification of artifact categories or priorities
+❌ Not scanning source code for pattern-level knowledge
+❌ Not presenting clear discovery summary to user
+
+## NEXT STEP:
+
+After user selects [C] to continue, load `{project-root}/_bmad/bmm/workflows/4-implementation/genai-knowledge-sync/steps/step-02-index.md` to index and chunk the discovered artifacts.
+
+Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and discovery catalog is confirmed!

src/bmm/workflows/4-implementation/genai-knowledge-sync/steps/step-02-index.md

@@ -0,0 +1,243 @@
+# Step 2: Knowledge Indexing & Chunking
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+- ✅ ALWAYS treat this as collaborative indexing between technical peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on creating self-contained, retrievable knowledge chunks
+- 🎯 EACH CHUNK must be independently useful without requiring full document context
+- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- 📝 Focus on creating atomic, self-contained knowledge chunks
+- ⚠️ Present A/P/C menu after each major category
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter with completed categories
+- 🚫 FORBIDDEN to load next step until all categories are indexed
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices for each knowledge category:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to explore nuanced knowledge relationships
+- **P (Party Mode)**: Bring multiple perspectives to identify missing knowledge connections
+- **C (Continue)**: Save the current chunks and proceed to next category
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml
+- When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Discovery catalog from step-1 is available
+- All artifact paths and classifications are identified
+- Focus on creating chunks optimized for embedding and retrieval
+- Each chunk must carry enough context to be useful in isolation
+
+## YOUR TASK:
+
+Index each discovered artifact into self-contained knowledge chunks with metadata tags, source tracing, and retrieval-optimized formatting.
+
+## CHUNKING PRINCIPLES:
+
+### Chunk Design Rules
+
+1. **Self-Contained**: Each chunk must be understandable without reading the source document
+2. **Tagged**: Every chunk has category, priority, source path, and semantic tags
+3. **Atomic**: One concept or decision per chunk - no compound knowledge
+4. **Traceable**: Every chunk links back to its source artifact and section
+5. **Contextual**: Include enough surrounding context for accurate retrieval
+6. **Deduplicated**: Avoid redundant chunks across different source artifacts
+
+### Chunk Format
+
+Each chunk follows this standard format:
+
+```markdown
+### [CHUNK-ID] Chunk Title
+
+- **Source:** `{relative_path_to_source_file}`
+- **Category:** architecture | requirements | implementation | domain | operations | quality
+- **Priority:** critical | high | standard | reference
+- **Tags:** comma-separated semantic tags for retrieval matching
+
+**Context:** One-line description of when this knowledge is relevant.
+
+**Content:**
+The actual knowledge content - specific, actionable, self-contained.
+```
+
+## INDEXING SEQUENCE:
+
+### 1. Index Critical-Priority Artifacts
+
+Process all artifacts marked as `critical` priority first:
+
+**For each critical artifact:**
+
+- Read the complete source file
+- Identify distinct knowledge units (decisions, rules, constraints)
+- Create one chunk per knowledge unit
+- Apply semantic tags for retrieval matching
+- Present chunks to user for validation
+
+**Present results:**
+"I've created {{chunk_count}} critical-priority chunks from {{source_count}} sources:
+
+{{list_of_chunk_titles_with_tags}}
+
+These chunks will be prioritized in every retrieval query.
+
+[A] Advanced Elicitation - Explore deeper knowledge connections
+[P] Party Mode - Review from multiple implementation perspectives
+[C] Continue - Save these chunks and proceed"
+
+### 2. Index High-Priority Artifacts
+
+Process all `high` priority artifacts:
+
+**For each high-priority artifact:**
+
+- Read source file and identify knowledge units
+- Create chunks with appropriate tags
+- Cross-reference with critical chunks for consistency
+- Identify any overlaps and deduplicate
+
+### 3. Index Standard-Priority Artifacts
+
+Process `standard` priority artifacts:
+
+**For each standard artifact:**
+
+- Read source file for domain-specific knowledge
+- Create chunks focused on contextual information
+- Tag for specific retrieval scenarios
+
+### 4. Index Reference-Priority Artifacts
+
+Process `reference` priority artifacts:
+
+**For each reference artifact:**
+
+- Extract background context and terminology
+- Create lighter-weight chunks for supplementary retrieval
+- Tag for broad topic matching
+
+### 5. Cross-Reference and Deduplicate
+
+After all categories are indexed:
+
+**Deduplication Analysis:**
+
+- Identify chunks with overlapping content across sources
+- Merge or consolidate redundant chunks
+- Ensure cross-references between related chunks are tagged
+- Present deduplication summary to user
+
+**Relationship Mapping:**
+
+- Identify chunks that frequently co-occur in implementation contexts
+- Tag related chunks for retrieval grouping
+- Create chunk clusters for common query patterns
+
+### 6. Generate Knowledge Index Document
+
+Compile all validated chunks into the knowledge index file:
+
+**Document Structure:**
+
+```markdown
+# Knowledge Index for {{project_name}}
+
+_RAG-optimized knowledge base for AI agent retrieval. Each chunk is self-contained and tagged for semantic search._
+
+---
+
+## Index Summary
+
+- **Total Chunks:** {{total_count}}
+- **Critical:** {{critical_count}} | **High:** {{high_count}} | **Standard:** {{standard_count}} | **Reference:** {{ref_count}}
+- **Sources Indexed:** {{source_count}}
+- **Last Synced:** {{date}}
+
+---
+
+## Critical Knowledge
+
+{{critical_chunks}}
+
+## Architecture Knowledge
+
+{{architecture_chunks}}
+
+## Requirements Knowledge
+
+{{requirements_chunks}}
+
+## Implementation Knowledge
+
+{{implementation_chunks}}
+
+## Domain Knowledge
+
+{{domain_chunks}}
+
+## Operations Knowledge
+
+{{operations_chunks}}
+
+## Quality Knowledge
+
+{{quality_chunks}}
+```
+
+### 7. Present Indexing Summary
+
+"Knowledge indexing complete for {{project_name}}!
+
+**Chunks Created:**
+
+| Category | Critical | High | Standard | Reference | Total |
+|---|---|---|---|---|---|
+| Architecture | {{n}} | {{n}} | {{n}} | {{n}} | {{n}} |
+| Requirements | {{n}} | {{n}} | {{n}} | {{n}} | {{n}} |
+| Implementation | {{n}} | {{n}} | {{n}} | {{n}} | {{n}} |
+| Domain | {{n}} | {{n}} | {{n}} | {{n}} | {{n}} |
+| Operations | {{n}} | {{n}} | {{n}} | {{n}} | {{n}} |
+| Quality | {{n}} | {{n}} | {{n}} | {{n}} | {{n}} |
+
+**Deduplication:** Removed {{removed_count}} redundant chunks
+**Cross-References:** {{xref_count}} chunk relationships mapped
+
+[C] Continue to optimization"
+
+## SUCCESS METRICS:
+
+✅ All discovered artifacts indexed into self-contained chunks
+✅ Each chunk has proper metadata tags and source tracing
+✅ No redundant or overlapping chunks remain
+✅ Cross-references between related chunks are mapped
+✅ A/P/C menu presented and handled correctly for each category
+✅ Knowledge index document properly structured
+
+## FAILURE MODES:
+
+❌ Creating chunks that require reading the full source document
+❌ Missing semantic tags that prevent accurate retrieval
+❌ Not deduplicating overlapping chunks from different sources
+❌ Not cross-referencing related knowledge units
+❌ Not getting user validation for each category
+❌ Creating overly large chunks that reduce retrieval precision
+
+## NEXT STEP:
+
+After completing all categories and user selects [C], load `{project-root}/_bmad/bmm/workflows/4-implementation/genai-knowledge-sync/steps/step-03-optimize.md` to optimize the knowledge base for retrieval quality.
+
+Remember: Do NOT proceed to step-03 until all categories are indexed and user explicitly selects [C]!

src/bmm/workflows/4-implementation/genai-knowledge-sync/steps/step-03-optimize.md

@@ -0,0 +1,289 @@
+# Step 3: Knowledge Base Optimization & Completion
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+- ✅ ALWAYS treat this as collaborative optimization between technical peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on optimizing chunks for retrieval quality and accuracy
+- 🎯 ENSURE every chunk is retrieval-ready and well-tagged
+- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- 📝 Review and optimize chunks for retrieval precision
+- 📖 Update frontmatter with completion status
+- 🚫 NO MORE STEPS - this is the final step
+
+## CONTEXT BOUNDARIES:
+
+- All knowledge chunks from step-2 are indexed
+- Cross-references and deduplication are complete
+- Focus on retrieval quality optimization and finalization
+- Ensure the knowledge index is ready for RAG pipeline integration
+
+## YOUR TASK:
+
+Optimize the knowledge index for retrieval quality, validate chunk completeness, and finalize the knowledge base for AI agent consumption.
+
+## OPTIMIZATION SEQUENCE:
+
+### 1. Retrieval Quality Analysis
+
+Analyze the indexed chunks for retrieval effectiveness:
+
+**Tag Coverage Analysis:**
+
+- Review semantic tags across all chunks
+- Identify gaps where common queries would miss relevant chunks
+- Suggest additional tags for better retrieval matching
+- Present tag coverage report to user
+
+**Chunk Size Analysis:**
+
+- Identify chunks that are too large (reduce retrieval precision)
+- Identify chunks that are too small (lack sufficient context)
+- Recommend splits or merges for optimal retrieval size
+- Target: Each chunk should be 100-500 words for optimal embedding
+
+**Context Sufficiency Check:**
+
+- Verify each chunk is understandable without its source document
+- Add missing context where chunks reference undefined terms
+- Ensure technical terms are defined or tagged for glossary lookup
+
+### 2. Semantic Tag Optimization
+
+Optimize tags for retrieval accuracy:
+
+**Tag Standardization:**
+
+- Normalize similar tags (e.g., "api-design" and "api-patterns" → single standard)
+- Create a tag vocabulary for the project
+- Apply consistent tag format across all chunks
+
+**Tag Enrichment:**
+
+- Add technology-specific tags (framework names, library names)
+- Add pattern-type tags (e.g., "error-handling", "state-management")
+- Add lifecycle tags (e.g., "setup", "implementation", "testing", "deployment")
+
+**Present Tag Summary:**
+"I've optimized the semantic tags across {{chunk_count}} chunks:
+
+**Tag Vocabulary:** {{unique_tag_count}} standardized tags
+**Most Connected Tags:** {{top_tags_by_frequency}}
+**Coverage Gaps Fixed:** {{gaps_fixed}}
+
+Would you like to review the tag vocabulary? (y/n)"
+
+### 3. Retrieval Scenario Testing
+
+Validate retrieval quality with common query scenarios:
+
+**Test Queries:**
+
+Simulate these common developer queries against the knowledge index:
+
+1. "How should I structure a new feature?" → Should retrieve: architecture + implementation chunks
+2. "What are the testing requirements?" → Should retrieve: quality + implementation chunks
+3. "What technology versions are we using?" → Should retrieve: critical implementation chunks
+4. "How do I handle errors in this project?" → Should retrieve: implementation + quality chunks
+5. "What are the business rules for {{core_feature}}?" → Should retrieve: requirements + domain chunks
+
+**For each query, report:**
+
+- Chunks that would be retrieved (by tag matching)
+- Missing chunks that should be retrieved but aren't
+- False positive chunks that would be retrieved incorrectly
+- Recommended tag adjustments
+
+### 4. Generate Retrieval Configuration
+
+Create a retrieval configuration section in the knowledge index:
+
+```markdown
+## Retrieval Configuration
+
+### Query Mapping
+
+| Query Pattern | Target Categories | Priority Filter | Expected Chunks |
+|---|---|---|---|
+| "how to implement *" | implementation, architecture | critical, high | 3-5 |
+| "testing requirements for *" | quality, implementation | critical, high | 2-4 |
+| "business rules for *" | requirements, domain | all | 2-3 |
+| "architecture decision for *" | architecture | all | 1-3 |
+| "deployment process for *" | operations | all | 1-2 |
+
+### Embedding Recommendations
+
+- **Model:** Use an embedding model that handles technical content well
+- **Chunk Overlap:** 50-100 characters overlap between adjacent chunks from the same source
+- **Metadata Filters:** Always filter by category and priority for focused retrieval
+- **Top-K:** Retrieve 3-5 chunks per query for optimal context balance
+```
+
+### 5. Finalize Knowledge Index
+
+Complete the knowledge index with optimization results:
+
+**Update Frontmatter:**
+
+```yaml
+---
+project_name: '{{project_name}}'
+user_name: '{{user_name}}'
+date: '{{date}}'
+total_chunks: {{total_count}}
+sources_indexed: {{source_count}}
+tag_vocabulary_size: {{tag_count}}
+retrieval_tested: true
+status: 'complete'
+---
+```
+
+**Append Usage Guidelines:**
+
+```markdown
+---
+
+## Usage Guidelines
+
+**For AI Agents (RAG Retrieval):**
+
+- Query this index using semantic search against chunk tags and content
+- Always include critical-priority chunks in implementation context
+- Filter by category when the task type is known
+- Cross-reference related chunks using shared tags
+
+**For Humans (Maintenance):**
+
+- Re-run this workflow when new artifacts are created or significantly updated
+- Add new chunks manually using the standard chunk format above
+- Review and prune quarterly to remove outdated knowledge
+- Update tags when new patterns or technologies are adopted
+
+**For RAG Pipeline Integration:**
+
+- Parse chunks by the `### [CHUNK-ID]` delimiter
+- Extract metadata from the bullet-point headers (Source, Category, Priority, Tags)
+- Use Tags field for semantic search indexing
+- Use Priority field for retrieval ranking
+```
+
+### 6. Present Completion Summary
+
+Based on user skill level, present the completion:
+
+**Expert Mode:**
+"Knowledge index complete. {{chunk_count}} chunks across {{source_count}} sources, {{tag_count}} semantic tags. Retrieval-tested and RAG-ready.
+
+File saved to: `{project_knowledge}/knowledge-index.md`"
+
+**Intermediate Mode:**
+"Your project knowledge base is indexed and retrieval-ready!
+
+**What we created:**
+
+- {{chunk_count}} self-contained knowledge chunks
+- {{source_count}} source artifacts indexed
+- {{tag_count}} semantic tags for retrieval matching
+- Retrieval configuration for RAG pipeline integration
+
+**How it works:**
+AI agents can now search this index to find exactly the project knowledge they need for any implementation task, instead of loading entire documents.
+
+**Next steps:**
+
+- Integrate with your RAG pipeline using the retrieval configuration
+- Re-run this workflow when artifacts change significantly
+- Review quarterly to keep knowledge current"
+
+**Beginner Mode:**
+"Your project knowledge base is ready! 🎉
+
+**What this does:**
+Think of this as a smart library catalog for your project. Instead of AI agents reading every document from start to finish, they can now search for exactly the knowledge they need.
+
+**What's included:**
+
+- {{chunk_count}} bite-sized knowledge pieces from your project documents
+- Smart tags so agents can find the right knowledge quickly
+- Priority labels so the most important knowledge comes first
+
+**How AI agents use it:**
+When an agent needs to implement something, it searches this index for relevant knowledge chunks instead of reading entire documents. This makes them faster and more accurate!"
+
+### 7. Completion Validation
+
+Final checks before completion:
+
+**Content Validation:**
+✅ All discovered artifacts indexed into chunks
+✅ Each chunk has proper metadata and source tracing
+✅ Semantic tags are standardized and comprehensive
+✅ No redundant chunks remain after deduplication
+✅ Retrieval scenarios tested successfully
+✅ Retrieval configuration generated
+
+**Format Validation:**
+✅ Consistent chunk format throughout
+✅ Frontmatter properly updated
+✅ Tag vocabulary is standardized
+✅ Document is well-structured and scannable
+
+### 8. Completion Message
+
+"✅ **GenAI Knowledge Sync Complete!**
+
+Your retrieval-optimized knowledge index is ready at:
+`{project_knowledge}/knowledge-index.md`
+
+**📊 Knowledge Base Summary:**
+
+- {{chunk_count}} indexed knowledge chunks
+- {{source_count}} source artifacts cataloged
+- {{tag_count}} semantic tags for retrieval
+- {{category_count}} knowledge categories covered
+- Retrieval-tested with {{test_count}} query scenarios
+
+**🎯 RAG Integration Ready:**
+
+- Self-contained chunks with metadata headers
+- Standardized tag vocabulary for semantic search
+- Priority-based retrieval ranking
+- Query mapping configuration included
+
+**📋 Maintenance:**
+
+1. Re-sync when artifacts change significantly: run this workflow again
+2. Add individual chunks manually using the standard format
+3. Review quarterly to prune outdated knowledge
+4. Update tags when new patterns emerge
+
+Your AI agents can now retrieve precisely the project knowledge they need for any task!"
+
+## SUCCESS METRICS:
+
+✅ Knowledge index fully optimized for retrieval quality
+✅ Semantic tags standardized and comprehensive
+✅ Retrieval scenarios tested with good coverage
+✅ Retrieval configuration generated for RAG pipeline
+✅ Usage guidelines included for agents, humans, and pipelines
+✅ Frontmatter properly updated with completion status
+✅ User provided with clear maintenance guidance
+
+## FAILURE MODES:
+
+❌ Chunks too large or too small for effective retrieval
+❌ Semantic tags inconsistent or too sparse
+❌ Not testing retrieval scenarios before finalizing
+❌ Missing retrieval configuration for pipeline integration
+❌ Not providing maintenance and usage guidelines
+❌ Frontmatter not properly updated
+
+## WORKFLOW COMPLETE:
+
+This is the final step of the GenAI Knowledge Sync workflow. The user now has a retrieval-optimized knowledge index that enables AI agents to find and use exactly the project knowledge they need for any implementation task, improving both speed and accuracy of AI-assisted development.

src/bmm/workflows/4-implementation/genai-knowledge-sync/workflow.md

@@ -0,0 +1,50 @@
+---
+name: genai-knowledge-sync
+description: 'Build and maintain a RAG-ready knowledge base from project artifacts. Use when the user says "build knowledge base", "sync knowledge", or "create RAG context"'
+---
+
+# GenAI Knowledge Sync Workflow
+
+**Goal:** Create a structured, chunked knowledge index (`knowledge-index.md`) from project artifacts that is optimized for Retrieval-Augmented Generation (RAG) pipelines and AI agent context loading. This enables AI agents to retrieve the most relevant project knowledge at inference time rather than loading entire documents.
+
+**Your Role:** You are a technical knowledge architect working with a peer to catalog, chunk, and index project artifacts into a retrieval-optimized format. You ensure every knowledge chunk is self-contained, well-tagged, and traceable to its source.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **micro-file architecture** for disciplined execution:
+
+- Each step is a self-contained file with embedded rules
+- Sequential progression with user control at each step
+- Document state tracked in frontmatter
+- Focus on lean, retrieval-optimized content generation
+- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
+
+---
+
+## INITIALIZATION
+
+### Configuration Loading
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+
+- `project_name`, `output_folder`, `user_name`
+- `communication_language`, `document_output_language`, `user_skill_level`
+- `planning_artifacts`, `implementation_artifacts`, `project_knowledge`
+- `date` as system-generated current datetime
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Paths
+
+- `installed_path` = `{project-root}/_bmad/bmm/workflows/4-implementation/genai-knowledge-sync`
+- `template_path` = `{installed_path}/knowledge-index-template.md`
+- `output_file` = `{project_knowledge}/knowledge-index.md`
+
+---
+
+## EXECUTION
+
+Load and execute `{project-root}/_bmad/bmm/workflows/4-implementation/genai-knowledge-sync/steps/step-01-discover.md` to begin the workflow.
+
+**Note:** Artifact discovery, source cataloging, and chunking strategy selection are handled in step-01-discover.md.

src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-01-clarify-and-route.md

@@ -0,0 +1,51 @@
+---
+name: 'step-01-clarify-and-route'
+description: 'Capture intent, route to execution path'
+
+wipFile: '{implementation_artifacts}/tech-spec-wip.md'
+deferred_work_file: '{implementation_artifacts}/deferred-work.md'
+spec_file: '' # set at runtime before leaving this step
+---
+
+# Step 1: Clarify and Route
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- The prompt that triggered this workflow IS the intent — not a hint.
+- Do NOT assume you start from zero.
+
+## ARTIFACT SCAN
+
+- `{wipFile}` exists? → Offer resume or archive.
+- Active specs (`ready-for-dev`, `in-progress`, `in-review`) in `{implementation_artifacts}`? → List them and HALT. Ask user which to resume (or `[N]` for new).
+  - If `ready-for-dev` or `in-progress` selected: Set `spec_file`, set `execution_mode = "plan-code-review"`, skip to step 3.
+  - If `in-review` selected: Set `spec_file`, set `execution_mode = "plan-code-review"`, skip to step 4.
+- Unformatted spec or intent file lacking `status` frontmatter in `{implementation_artifacts}`? → Suggest to the user to treat its contents as the starting intent for this workflow. DO NOT attempt to infer a state and resume it.
+
+## INSTRUCTIONS
+
+1. Load context.
+   - List files in `{planning_artifacts}` and `{implementation_artifacts}`.
+   - If you find an unformatted spec or intent file, ingest its contents to form your understanding of the intent.
+2. Clarify intent. Do not fantasize, do not leave open questions. If you must ask questions, ask them as a numbered list. When the human replies, verify that every single numbered question was answered. If any were ignored, HALT and re-ask only the missing questions before proceeding. Keep looping until intent is clear enough to implement.
+3. Version control sanity check. Is the working tree clean? Does the current branch make sense for this intent — considering its name and recent history? If the tree is dirty or the branch is an obvious mismatch, HALT and ask the human before proceeding. If version control is unavailable, skip this check.
+4. Multi-goal check (see SCOPE STANDARD). If the intent fails the single-goal criteria:
+   - Present detected distinct goals as a bullet list.
+   - HALT and ask human: `[S] Split — pick first goal, defer the rest` | `[K] Keep as-is`
+   - On **S**: Append deferred goals to `{deferred_work_file}`. Narrow scope to the first-mentioned goal. Continue routing.
+   - On **K**: Proceed as-is.
+5. Generate `spec_file` path:
+   - Derive a valid kebab-case slug from the clarified intent.
+   - If `{implementation_artifacts}/tech-spec-{slug}.md` already exists, append `-2`, `-3`, etc.
+   - Set `spec_file` = `{implementation_artifacts}/tech-spec-{slug}.md`.
+6. Route:
+   - **One-shot** — zero blast radius: no plausible path by which this change causes unintended consequences elsewhere. Clear intent, no architectural decisions. `execution_mode = "one-shot"`. → Step 3.
+   - **Plan-code-review** — everything else. `execution_mode = "plan-code-review"`. → Step 2.
+   - When uncertain whether blast radius is truly zero, default to plan-code-review.
+
+
+## NEXT
+
+- One-shot / ready-for-dev: Read fully and follow `{installed_path}/steps/step-03-implement.md`
+- Plan-code-review: Read fully and follow `{installed_path}/steps/step-02-plan.md`

src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-02-plan.md

@@ -0,0 +1,39 @@
+---
+name: 'step-02-plan'
+description: 'Investigate, generate spec, present for approval'
+
+templateFile: '{installed_path}/tech-spec-template.md'
+wipFile: '{implementation_artifacts}/tech-spec-wip.md'
+deferred_work_file: '{implementation_artifacts}/deferred-work.md'
+---
+
+# Step 2: Plan
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- No intermediate approvals.
+
+## INSTRUCTIONS
+
+1. Investigate codebase. _Isolate deep exploration in sub-agents/tasks where available. To prevent context snowballing, instruct subagents to give you distilled summaries only._
+2. Read `{templateFile}` fully. Fill it out based on the intent and investigation, and write the result to `{wipFile}`.
+3. Self-review against READY FOR DEVELOPMENT standard.
+4. If intent gaps exist, do not fantasize, do not leave open questions, HALT and ask the human.
+5. Token count check (see SCOPE STANDARD). If spec exceeds 1600 tokens:
+   - Show user the token count.
+   - HALT and ask human: `[S] Split — carve off secondary goals` | `[K] Keep as-is`
+   - On **S**: Propose the split — name each secondary goal. Append deferred goals to `{deferred_work_file}`. Rewrite the current spec to cover only the main goal — do not surgically carve sections out; regenerate the spec for the narrowed scope. Continue to checkpoint.
+   - On **K**: Continue to checkpoint with full spec.
+
+### CHECKPOINT 1
+
+Present summary. If token count exceeded 1600 and user chose [K], include the token count and explain why it may be a problem. HALT and ask human: `[A] Approve` | `[E] Edit`
+
+- **A**: Rename `{wipFile}` to `{spec_file}`, set status `ready-for-dev`. Everything inside `<frozen-after-approval>` is now locked — only the human can change it. → Step 3.
+- **E**: Apply changes, then return to CHECKPOINT 1.
+
+
+## NEXT
+
+Read fully and follow `{installed_path}/steps/step-03-implement.md`

src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-03-implement.md

@@ -0,0 +1,35 @@
+---
+name: 'step-03-implement'
+description: 'Execute implementation directly or via sub-agent. Local only.'
+---
+
+# Step 3: Implement
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- No push. No remote ops.
+- Sequential execution only.
+- Content inside `<frozen-after-approval>` in `{spec_file}` is read-only. Do not modify.
+
+## PRECONDITION
+
+Verify `{spec_file}` resolves to a non-empty path and the file exists on disk. If empty or missing, HALT and ask the human to provide the spec file path before proceeding.
+
+## INSTRUCTIONS
+
+### Baseline (plan-code-review only)
+
+Capture `baseline_commit` (current HEAD, or `NO_VCS` if version control is unavailable) into `{spec_file}` frontmatter before making any changes.
+
+### Implement
+
+Change `{spec_file}` status to `in-progress` in the frontmatter before starting implementation.
+
+`execution_mode = "one-shot"` or no sub-agents/tasks available: implement the intent.
+
+Otherwise (`execution_mode = "plan-code-review"`): hand `{spec_file}` to a sub-agent/task and let it implement.
+
+## NEXT
+
+Read fully and follow `{installed_path}/steps/step-04-review.md`

src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-04-review.md

@@ -0,0 +1,57 @@
+---
+name: 'step-04-review'
+description: 'Adversarial review, classify findings, optional spec loop'
+
+adversarial_review_task: '{project-root}/_bmad/core/tasks/review-adversarial-general.xml'
+edge_case_hunter_task: '{project-root}/_bmad/core/tasks/review-edge-case-hunter.xml'
+deferred_work_file: '{implementation_artifacts}/deferred-work.md'
+specLoopIteration: 1
+---
+
+# Step 4: Review
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Review subagents get NO conversation context.
+
+## INSTRUCTIONS
+
+Change `{spec_file}` status to `in-review` in the frontmatter before continuing.
+
+### Construct Diff (plan-code-review only)
+
+Read `{baseline_commit}` from `{spec_file}` frontmatter. If `{baseline_commit}` is missing or `NO_VCS`, use best effort to determine what changed. Otherwise, construct `{diff_output}` covering all changes — tracked and untracked — since `{baseline_commit}`.
+
+Do NOT `git add` anything — this is read-only inspection.
+
+### Review
+
+**One-shot:** Skip diff construction. Still invoke `{adversarial_review_task}` in a subagent with the changed files — inline review invites anchoring bias.
+
+**Plan-code-review:** Launch three subagents without conversation context. If no sub-agents are available, generate three review prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the human to run each in a separate session (ideally a different LLM) and paste back the findings.
+
+- **Blind hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via `{adversarial_review_task}`.
+- **Edge case hunter** — receives `{diff_output}` and read access to the project. Invoke via `{edge_case_hunter_task}`.
+- **Acceptance auditor** — receives `{diff_output}`, `{spec_file}`, and read access to the project. Must also read the docs listed in `{spec_file}` frontmatter `context`. Checks for violations of acceptance criteria, rules, and principles from the spec and context docs.
+
+### Classify
+
+1. Deduplicate all review findings.
+2. Classify each finding. The first three categories are **this story's problem** — caused or exposed by the current change. The last two are **not this story's problem**. 
+   - **intent_gap** — caused by the change; cannot be resolved from the spec because the captured intent is incomplete. Do not infer intent unless there is exactly one possible reading.
+   - **bad_spec** — caused by the change, including direct deviations from spec. The spec should have been clear enough to prevent it. When in doubt between bad_spec and patch, prefer bad_spec — a spec-level fix is more likely to produce coherent code.
+   - **patch** — caused by the change; trivially fixable without human input. Just part of the diff.
+   - **defer** — pre-existing issue not caused by this story, surfaced incidentally by the review. Collect for later focused attention.
+   - **reject** — noise. Drop silently. When unsure between defer and reject, prefer reject — only defer findings you are confident are real.
+3. Process findings in cascading order. If intent_gap or bad_spec findings exist, they trigger a loopback — lower findings are moot since code will be re-derived. If neither exists, process patch and defer normally. Increment `{specLoopIteration}` on each loopback. If it exceeds 5, HALT and escalate to the human. On any loopback, re-evaluate routing — if scope has grown beyond one-shot, escalate `execution_mode` to plan-code-review.
+   - **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve, then re-run steps 2–4.
+   - **bad_spec** — Root cause is outside `<frozen-after-approval>`. Before reverting code: extract KEEP instructions for positive preservation (what worked well and must survive re-derivation). Revert code changes. Read the `## Spec Change Log` in `{spec_file}` and strictly respect all logged constraints when amending the non-frozen sections that contain the root cause. Append a new change-log entry recording: the triggering finding, what was amended, the known-bad state avoided, and the KEEP instructions. Read fully and follow `{installed_path}/steps/step-03-implement.md` to re-derive the code, then this step will run again.
+   - **patch** — Auto-fix. These are the only findings that survive loopbacks.
+   - **defer** — Append to `{deferred_work_file}`.
+   - **reject** — Drop silently.
+4. Commit.
+
+## NEXT
+
+Read fully and follow `{installed_path}/steps/step-05-present.md`

src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/steps/step-05-present.md

@@ -0,0 +1,19 @@
+---
+name: 'step-05-present'
+description: 'Present findings, get approval, create PR'
+---
+
+# Step 5: Present
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- NEVER auto-push.
+
+## INSTRUCTIONS
+
+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. Change `{spec_file}` status to `done` in the frontmatter.
+3. Display summary of your work to the user, including the commit hash if one was created. Advise on how to review the changes. Offer to push and/or create a pull request.
+
+Workflow complete.

src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/tech-spec-template.md

@@ -0,0 +1,90 @@
+---
+title: '{title}'
+type: 'feature' # feature | bugfix | refactor | chore
+created: '{date}'
+status: 'draft' # draft | ready-for-dev | in-progress | in-review | done
+context: [] # optional: max 3 project-wide standards/docs. NO source code files.
+---
+
+<!-- Target: 900–1300 tokens. Above 1600 = high risk of context rot.
+     Never over-specify "how" — use boundaries + examples instead.
+     Cohesive cross-layer stories (DB+BE+UI) stay in ONE file.
+     IMPORTANT: Remove all HTML comments when filling this template. -->
+
+# {title}
+
+<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
+
+## Intent
+
+<!-- What is broken or missing, and why it matters. Then the high-level approach — the "what", not the "how". -->
+
+**Problem:** ONE_TO_TWO_SENTENCES
+
+**Approach:** ONE_TO_TWO_SENTENCES
+
+## Boundaries & Constraints
+
+<!-- Three tiers: Always = invariant rules. Ask First = human-gated decisions. Never = out of scope + forbidden approaches. -->
+
+**Always:** INVARIANT_RULES
+
+**Ask First:** DECISIONS_REQUIRING_HUMAN_APPROVAL
+<!-- Agent: if any of these trigger during execution, HALT and ask the user before proceeding. -->
+
+**Never:** NON_GOALS_AND_FORBIDDEN_APPROACHES
+
+## I/O & Edge-Case Matrix
+
+<!-- If no meaningful I/O scenarios exist, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
+
+| Scenario | Input / State | Expected Output / Behavior | Error Handling |
+|----------|--------------|---------------------------|----------------|
+| HAPPY_PATH | INPUT | OUTCOME | N/A |
+| ERROR_CASE | INPUT | OUTCOME | ERROR_HANDLING |
+
+</frozen-after-approval>
+
+## Code Map
+
+<!-- Agent-populated during planning. Annotated paths prevent blind codebase searching. -->
+
+- `FILE` -- ROLE_OR_RELEVANCE
+- `FILE` -- ROLE_OR_RELEVANCE
+
+## Tasks & Acceptance
+
+<!-- Tasks: backtick-quoted file path -- action -- rationale. Prefer one task per file; group tightly-coupled changes when splitting would be artificial. -->
+<!-- If an I/O Matrix is present, include a task to unit-test its edge cases. -->
+<!-- AC covers system-level behaviors not captured by the I/O Matrix. Do not duplicate I/O scenarios here. -->
+
+**Execution:**
+- [ ] `FILE` -- ACTION -- RATIONALE
+
+**Acceptance Criteria:**
+- Given PRECONDITION, when ACTION, then EXPECTED_RESULT
+
+## Spec Change Log
+
+<!-- Append-only. Populated by step-04 during review loops. Do not modify or delete existing entries.
+     Each entry records: what finding triggered the change, what was amended, what known-bad state
+     the amendment avoids, and any KEEP instructions (what worked well and must survive re-derivation).
+     Empty until the first bad_spec loopback. -->
+
+## Design Notes
+
+<!-- If the approach is straightforward, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
+<!-- Design rationale and golden examples only when non-obvious. Keep examples to 5–10 lines. -->
+
+DESIGN_RATIONALE_AND_EXAMPLES
+
+## Verification
+
+<!-- If no build, test, or lint commands apply, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
+<!-- How the agent confirms its own work. Prefer CLI commands. When no CLI check applies, state what to inspect manually. -->
+
+**Commands:**
+- `COMMAND` -- expected: SUCCESS_CRITERIA
+
+**Manual checks (if no CLI):**
+- WHAT_TO_INSPECT_AND_EXPECTED_STATE

src/bmm/workflows/bmad-quick-flow/quick-dev-new-preview/workflow.md

@@ -0,0 +1,90 @@
+---
+name: quick-dev-new-preview
+description: 'Unified quick flow - clarify intent, plan, implement, review, present.'
+main_config: '{project-root}/_bmad/bmm/config.yaml'
+
+# Related workflows
+advanced_elicitation: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+party_mode_exec: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+
+# Review building block
+adversarial_review_task: '{project-root}/_bmad/core/tasks/review-adversarial-general.xml'
+---
+
+# Quick Dev New Preview Workflow
+
+**Goal:** Take a user request from intent through implementation, adversarial review, and PR creation in a single unified flow.
+
+**Your Role:** You are an elite developer. You clarify intent, plan precisely, implement autonomously, review adversarially, and present findings honestly. Minimum ceremony, maximum signal.
+
+
+## READY FOR DEVELOPMENT STANDARD
+
+A specification is "Ready for Development" when:
+
+- **Actionable**: Every task has a file path and specific action.
+- **Logical**: Tasks ordered by dependency.
+- **Testable**: All ACs use Given/When/Then.
+- **Complete**: No placeholders or TBDs.
+
+
+## SCOPE STANDARD
+
+A specification should target a **single user-facing goal** within **900–1600 tokens**:
+
+- **Single goal**: One cohesive feature, even if it spans multiple layers/files. Multi-goal means >=2 **top-level independent shippable deliverables** — each could be reviewed, tested, and merged as a separate PR without breaking the others. Never count surface verbs, "and" conjunctions, or noun phrases. Never split cross-layer implementation details inside one user goal.
+  - Split: "add dark mode toggle AND refactor auth to JWT AND build admin dashboard"
+  - Don't split: "add validation and display errors" / "support drag-and-drop AND paste AND retry"
+- **900–1600 tokens**: Optimal range for LLM consumption. Below 900 risks ambiguity; above 1600 risks context-rot in implementation agents.
+- **Neither limit is a gate.** Both are proposals with user override.
+
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+- **Micro-file Design**: Each step is self-contained and followed exactly
+- **Just-In-Time Loading**: Only load the current step file
+- **Sequential Enforcement**: Complete steps in order, no skipping
+- **State Tracking**: Persist progress via spec frontmatter and in-memory variables
+- **Append-Only Building**: Build artifacts incrementally
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Read the entire step file before acting
+2. **FOLLOW SEQUENCE**: Execute sections in order
+3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
+4. **LOAD NEXT**: When directed, read fully and follow the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- **NEVER** load multiple step files simultaneously
+- **ALWAYS** read entire step file before execution
+- **NEVER** skip steps or optimize the sequence
+- **ALWAYS** follow the exact instructions in the step file
+- **ALWAYS** halt at checkpoints and wait for human input
+
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Load and read full config from `{main_config}` and resolve:
+
+- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
+- `communication_language`, `document_output_language`, `user_skill_level`
+- `date` as system-generated current datetime
+- `project_context` = `**/project-context.md` (load if exists)
+- CLAUDE.md / memory files (load if exist)
+
+YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
+
+### 2. Paths
+
+- `installed_path` = `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev-new-preview`
+- `templateFile` = `{installed_path}/tech-spec-template.md`
+- `wipFile` = `{implementation_artifacts}/tech-spec-wip.md`
+
+### 3. First Step Execution
+
+Read fully and follow: `{installed_path}/steps/step-01-clarify-and-route.md` to begin the workflow.

src/core/module.yaml

@@ -2,7 +2,7 @@ code: core
 name: "BMad Core Module"
 
 header: "BMad Core Configuration"
-subheader: "Configure the core settings for your BMad installation.\nThese settings will be used across all modules and agents."
+subheader: "Configure the core settings for your BMad installation.\nThese settings will be used across all installed bmad skills, workflows, and agents."
 
 user_name:
   prompt: "What should agents call you? (Use your name or a team name)"
@@ -23,3 +23,13 @@ output_folder:
   prompt: "Where should output files be saved?"
   default: "_bmad-output"
   result: "{project-root}/{value}"
+
+tool_supports_subagents:
+  prompt: "Subagents are supported by the LLM or Tool I will be using?"
+  default: true
+  result: "{value}"
+
+tool_supports_agent_teams:
+  prompt: "Agent Teams are supported by the LLM or Tool I will be using?"
+  default: false
+  result: "{value}"

tools/cli/commands/status.js

@@ -11,7 +11,7 @@ const ui = new UI();
 module.exports = {
   command: 'status',
   description: 'Display BMAD installation status and module versions',
-  options: [],
+  options: [['-v, --verbose', 'Show detailed status including agent and workflow counts']],
   action: async (options) => {
     try {
       // Find the bmad directory
@@ -53,6 +53,23 @@ module.exports = {
         bmadDir,
       });
 
+      // Verbose mode: show agent and workflow counts per module
+      if (options.verbose) {
+        const { glob } = require('glob');
+        for (const mod of modules) {
+          const moduleName = typeof mod === 'string' ? mod : (mod.id || mod.name || '');
+          if (!moduleName) continue;
+
+          const modDir = path.join(bmadDir, moduleName);
+          if (!(await fs.pathExists(modDir))) continue;
+
+          const agents = await glob('agents/**/*.agent.yaml', { cwd: modDir });
+          const workflows = await glob('workflows/**/*.{yaml,yml,md}', { cwd: modDir });
+
+          await prompts.log.info(`Module "${moduleName}": ${agents.length} agent(s), ${workflows.length} workflow(s)`);
+        }
+      }
+
       process.exit(0);
     } catch (error) {
       await prompts.log.error(`Status check failed: ${error.message}`);

tools/cli/lib/config.js

@@ -7,8 +7,14 @@ const packageJson = require('../../../package.json');
  * Configuration utility class
  */
 class Config {
+  /** @type {Map<string, { data: Object, mtime: number }>} */
+  #cache = new Map();
+
   /**
-   * Load a YAML configuration file
+   * Load a YAML configuration file with in-memory caching.
+   * Cached entries are automatically invalidated when the file's
+   * modification time changes, so callers always receive fresh data
+   * after a file is written.
    * @param {string} configPath - Path to config file
    * @returns {Object} Parsed configuration
    */
@@ -17,8 +23,26 @@ class Config {
       throw new Error(`Configuration file not found: ${configPath}`);
     }
 
-    const content = await fs.readFile(configPath, 'utf8');
+    const resolved = path.resolve(configPath);
-    return yaml.parse(content);
+    const stat = await fs.stat(resolved);
+    const mtime = stat.mtimeMs;
+
+    const cached = this.#cache.get(resolved);
+    if (cached && cached.mtime === mtime) {
+      return cached.data;
+    }
+
+    const content = await fs.readFile(resolved, 'utf8');
+    const data = yaml.parse(content);
+    this.#cache.set(resolved, { data, mtime });
+    return data;
+  }
+
+  /**
+   * Clear the in-memory YAML cache.
+   */
+  clearCache() {
+    this.#cache.clear();
   }
 
   /**