refactor: consolidate workflows to src/bmm/ and update test scripts

- Move epic-execute, epic-chain, uat-validate from src/modules/bmm/ to src/bmm/
- Add validate:refs to test script chain
- Enable --strict mode for file reference validation
- Update docs and workflow references

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

README.md

@@ -56,6 +56,8 @@ Bug fixes, small features, clear scope — 3 commands - 1 Optional Agent:
 2. `/dev-story` — implements each story
 3. `/code-review` — validates quality
 
+> **Tip:** For existing codebases, run `/generate-project-context` first to capture implementation rules AI agents should follow.
+
 ### Full Planning Path (BMad Method)
 
 Products, platforms, complex features — structured planning then build:
@@ -65,7 +67,8 @@ Products, platforms, complex features — structured planning then build:
 3. `/create-architecture` — technical decisions and system design
 4. `/create-epics-and-stories` — break work into prioritized stories
 5. `/sprint-planning` — initialize sprint tracking
-6. **Repeat per story:** `/create-story` → `/dev-story` → `/code-review`
+6. **For established projects:** `/generate-project-context` — capture codebase conventions for AI agents
+7. **Repeat per story:** `/create-story` → `/dev-story` → `/code-review`
 
 Every step tells you what's next. Optional phases (brainstorming, research, UX design) are available when you need them — ask `/bmad-help` anytime. For a detailed walkthrough, see the [Getting Started Tutorial](http://docs.bmad-method.org/tutorials/getting-started/).
 

docs/how-to/established-projects.md

@@ -34,7 +34,17 @@ Your `docs/` folder should contain succinct, well-organized documentation that a
 
 For complex projects, consider using the `document-project` workflow. It offers runtime variants that will scan your entire project and document its actual current state.
 
-## Step 3: Get Help
+## Step 3: Generate Project Context
+
+Before implementation, create `project-context.md` so AI agents follow your codebase conventions:
+
+Run `generate-project-context` (`/bmad-bmm-generate-project-context`). This scans your codebase and creates a lean file with critical implementation rules — naming conventions, patterns, constraints, and anti-patterns.
+
+All implementation workflows (`/dev-story`, `/code-review`, `/quick-dev`, etc.) automatically load this file. Without it, AI agents may miss your project's established patterns.
+
+For comprehensive project documentation beyond implementation rules, use `document-project` (`/bmad-bmm-document-project`) instead.
+
+## Step 4: Get Help
 
 Get help to know what to do next based on your unique needs
 

docs/reference/workflow-map.md

@@ -77,7 +77,16 @@ Skip phases 1-3 for small, well-understood work.
 
 Each document becomes context for the next phase. The PRD tells the architect what constraints matter. The architecture tells the dev agent which patterns to follow. Story files give focused, complete context for implementation. Without this structure, agents make inconsistent decisions.
 
-For established projects, `document-project` creates or updates `project-context.md` - what exists in the codebase and the rules all implementation workflows must observe. Run it just before Phase 4, and again when something significant changes - structure, architecture, or those rules. You can also edit `project-context.md` by hand.
+### Creating Project Context
+
+Before Phase 4 implementation, **especially for established projects**, create `project-context.md` to ensure AI agents follow your codebase conventions:
+
+| Workflow                     | Purpose                                                          | Best For                        |
+| ---------------------------- | ---------------------------------------------------------------- | ------------------------------- |
+| `generate-project-context`   | Lean, LLM-optimized implementation rules, patterns, constraints  | Most projects (quick and focused) |
+| `document-project`           | Comprehensive project scan including `project-context.md`        | Thorough documentation needs    |
+
+Run again when significant changes occur — structure, architecture, or implementation rules. You can also edit `project-context.md` by hand. For greenfield projects, this is optional — create it when patterns emerge.
 
 All implementation workflows load `project-context.md` if it exists. Additional context per workflow:
 

docs/tutorials/getting-started.md

@@ -122,6 +122,16 @@ Epics and stories are now created *after* architecture. This produces better qua
 2. Run `check-implementation-readiness` (`/bmad-bmm-check-implementation-readiness`)
 3. Validates cohesion across all planning documents
 
+### Project Context (Recommended for Existing Codebases)
+
+If you're working on an existing codebase, generate `project-context.md` before implementation:
+
+1. Load the **Analyst agent** (`/bmad-agent-bmm-analyst`) in a new chat
+2. Run `generate-project-context` (`/bmad-bmm-generate-project-context`)
+3. Output: `project-context.md` with coding standards, patterns, and constraints
+
+All Phase 4 workflows automatically load this file if it exists, ensuring AI agents follow your project's conventions. For new greenfield projects, this is optional.
+
 ## Step 2: Build Your Project
 
 Once planning is complete, move to implementation. **Each workflow should run in a fresh chat.**
@@ -173,6 +183,7 @@ your-project/
 | `create-architecture`            | `/bmad-bmm-create-architecture`            | Architect | Create architecture document         |
 | `create-epics-and-stories`       | `/bmad-bmm-create-epics-and-stories`       | PM        | Break down PRD into epics            |
 | `check-implementation-readiness` | `/bmad-bmm-check-implementation-readiness` | Architect | Validate planning cohesion           |
+| `generate-project-context`       | `/bmad-bmm-generate-project-context`       | Analyst   | Capture codebase rules for AI agents |
 | `sprint-planning`                | `/bmad-bmm-sprint-planning`                | SM        | Initialize sprint tracking           |
 | `create-story`                   | `/bmad-bmm-create-story`                   | SM        | Create a story file                  |
 | `dev-story`                      | `/bmad-bmm-dev-story`                      | DEV       | Implement a story                    |

package.json

@@ -39,12 +39,12 @@
     "lint:md": "markdownlint-cli2 \"**/*.md\"",
     "prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
     "rebundle": "node tools/cli/bundlers/bundle-web.js rebundle",
-    "test": "npm run test:schemas && npm run test:refs && npm run test:install && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
+    "test": "npm run test:schemas && npm run test:refs && npm run test:install && npm run validate:schemas && npm run validate:refs && npm run lint && npm run lint:md && npm run format:check",
     "test:coverage": "c8 --reporter=text --reporter=html npm run test:schemas",
     "test:install": "node test/test-installation-components.js",
     "test:refs": "node test/test-file-refs-csv.js",
     "test:schemas": "node test/test-agent-schema.js",
-    "validate:refs": "node tools/validate-file-refs.js",
+    "validate:refs": "node tools/validate-file-refs.js --strict",
     "validate:schemas": "node tools/validate-agent-schema.js"
   },
   "lint-staged": {

repo-structure-review.md

@@ -0,0 +1,168 @@
+# Repository Structure Review: Enhancements for Real-World Coding Projects
+
+After a thorough review of the entire repo, here are the structural issues and enhancement opportunities, organized by impact level.
+
+---
+
+## 1. ~~CRITICAL: Dual Module Location Creates Broken References~~ RESOLVED
+
+**Status:** Fixed.
+
+The repo had two overlapping locations for BMM content (`src/bmm/` and `src/modules/bmm/`), causing 6 broken file references across 2 agent files. Agents referenced workflows that only existed in `src/modules/bmm/`, so the SM and UAT Validator agents would fail at runtime.
+
+**What was done:**
+
+- Moved `epic-execute/`, `epic-chain/`, and `uat-validate/` from `src/modules/bmm/` into `src/bmm/workflows/` (their correct locations)
+- Created `src/bmm/workflows/5-validation/` for the UAT validation phase
+- Fixed `.bmad/` → `_bmad/` path inconsistencies in the moved epic-chain and epic-execute files
+- Removed the `uat-report` menu entry from `uat-validator.agent.yaml` (workflow never existed anywhere)
+- Removed the `uat-automation-patterns` knowledge reference from `uat-validator.agent.yaml` (data file never existed)
+- Deleted the now-empty `src/modules/bmm/` directory
+- All tests pass (schema validation, file refs, installation components, lint, markdown lint, formatting)
+
+---
+
+## 2. ~~HIGH: No Guardrail for Broken File References in CI~~ RESOLVED
+
+**Status:** Fixed.
+
+The repo already had a comprehensive file reference validator (`tools/validate-file-refs.js`) that catches broken references, but it ran in warning mode (exit 0) so issues were never blocking. There were also 6 pre-existing broken references preventing strict mode from being enabled.
+
+**What was done:**
+
+- Fixed 6 broken file references across 3 workflow files:
+  - `create-architecture/workflow.md` — wrong directory name (`architecture` → `create-architecture`)
+  - `create-story/checklist.md` — wrong filename (`validate-workflow.xml` → `workflow.xml`)
+  - `document-project/instructions.md` — removed 3 references to non-existent `workflow-status` workflow
+- Switched `validate:refs` to strict mode (`--strict` flag) so broken references now fail with exit code 1
+- Added `validate:refs` to the `npm test` script chain, so it runs in both pre-commit hooks and CI
+- CI workflow (`.github/workflows/quality.yaml`) already ran `validate:refs` — the `--strict` flag now makes it a blocking check
+- All 471 file references across 242 source files now validate cleanly
+
+---
+
+## 3. HIGH: `project-context.md` Is a Hidden Prerequisite
+
+Every Phase 4 implementation workflow declares:
+
+```yaml
+project_context: "**/project-context.md"
+```
+
+But there's no clear documentation on what this file is, when to create it, or how. The `generate-project-context` workflow exists but:
+
+- It's not mentioned in the Quick Start path in the README
+- The Getting Started tutorial doesn't flag it as a prerequisite before Phase 4
+- The Quick Flow path (`/quick-spec` → `/dev-story` → `/code-review`) doesn't mention it either
+
+**Impact:** Developers hit Phase 4 workflows and get confusing results because the project context file doesn't exist yet.
+
+**Recommendation:** Either auto-generate `project-context.md` during installation (even a minimal scaffold), or add a prominent step in the README's workflow paths and in the Quick Flow docs. Alternatively, make it optional in workflow configs with a graceful fallback.
+
+---
+
+## 4. HIGH: Artifact Storage Strategy Is Confusing
+
+Three layers of configuration overlap:
+
+- `core/module.yaml` defines `output_folder` (default: `_bmad-output`)
+- `bmm/module.yaml` defines `planning_artifacts`, `implementation_artifacts`, `project_knowledge` (nested under output_folder)
+- Individual workflows use different variable names (`{sprint_status}`, `{sprint_artifacts}`, `{output_folder}`)
+- `.gitignore` ignores both `_bmad/` and `_bmad-output/`
+
+**The confusion for real projects:**
+
+1. Are artifacts meant to be version-controlled? The `.gitignore` says no, but `project_knowledge` defaults to `docs/` which *is* typically committed.
+2. Some workflows reference `sprint_artifacts` which isn't defined in any `module.yaml` config.
+3. A developer doesn't know where to look for generated PRDs, architecture docs, or sprint tracking files.
+
+**Recommendation:**
+
+- Add a clear section in the README or a post-install message explaining the folder structure and which folders to commit
+- Standardize variable names across all workflows (audit `sprint_artifacts` vs `sprint_status`)
+- Consider generating a `_bmad-output/README.md` during installation that explains the folder layout
+
+---
+
+## 5. HIGH: Inconsistent Workflow File Format
+
+Workflows use two different formats with no documented rationale:
+
+| Format | Examples |
+|--------|----------|
+| `workflow.yaml` (structured) | dev-story, code-review, sprint-planning, correct-course |
+| `workflow.md` (markdown) | quick-spec, quick-dev, create-architecture, create-prd |
+| Custom names | `workflow-create-prd.md`, `workflow-validate-prd.md` |
+
+Some workflows have both a `workflow.yaml` and a separate `instructions.md`, while others put everything in a single `workflow.md`.
+
+**Impact:** IDE integrations, the manifest generator, and agent command generators all need to handle multiple formats. Contributors don't know which format to use when adding workflows.
+
+**Recommendation:** Document the rationale (e.g., `.yaml` for machine-parseable configs with `input_file_patterns`, `.md` for pure instructional workflows). Consider standardizing on `.yaml` as the entry point with `.md` for instructions only.
+
+---
+
+## 6. ~~MEDIUM: Missing Data Files Referenced by Agents~~ RESOLVED
+
+**Status:** Fixed as part of item #1. The `uat-automation-patterns.yaml` reference and the `uat-report` menu entry were removed from `uat-validator.agent.yaml` since neither resource existed anywhere in the repo.
+
+---
+
+## 7. MEDIUM: No Example Project or Post-Install Scaffold
+
+After running `npx bmad-method install`, developers get agents and workflows but no example of what a successful project looks like. There's no:
+
+- Example `project-context.md`
+- Sample PRD or architecture doc showing expected output format
+- Starter `.claude/commands/` or equivalent showing what commands were generated
+- Post-install "what to do next" guide in the terminal
+
+**Recommendation:** Consider adding:
+
+- A `_bmad-output/GETTING-STARTED.md` generated at install time with next steps specific to the chosen modules/IDE
+- Example outputs in the docs site showing what a completed PRD, architecture doc, or sprint plan looks like
+- A `bmad status` CLI command that shows what phase the project is in and what the next recommended workflow is (the `status` command exists but appears minimal)
+
+---
+
+## 8. MEDIUM: Test Suite Doesn't Use a Standard Test Runner
+
+Tests in `test/` use raw `node:assert` and `node:test` with custom scripts rather than a standard test framework. While Jest is in devDependencies, the actual tests don't use it. The test runner is bare `node test/test-agent-schema.js`.
+
+**Impact for contributors:** No test watch mode, no standard patterns for adding tests, no IDE test integration. The Jest dependency appears unused.
+
+**Recommendation:** Either migrate to Jest (since it's already a dependency) or remove Jest and document the `node:test` approach. Either way, add test watch capabilities for contributor DX.
+
+---
+
+## 9. MEDIUM: `src/utility/agent-components/` Is Undocumented
+
+The `src/utility/` directory contains shared agent components but isn't mentioned in the README, CLAUDE.md, or CONTRIBUTING.md. Its relationship to the module system is unclear.
+
+**Recommendation:** Document this directory's purpose and how components are shared across modules.
+
+---
+
+## 10. LOW: CONTRIBUTING.md References Non-Existent Scripts
+
+The contribution workflow likely references `npm run validate:refs` which doesn't exist as a standalone script in `package.json`. The actual ref validation is `test:refs` (which runs `test-file-refs-csv.js`).
+
+**Recommendation:** Audit CONTRIBUTING.md to ensure all referenced commands exist.
+
+---
+
+## 11. ~~LOW: Workflow Phase Numbering Gap~~ RESOLVED
+
+**Status:** Fixed as part of item #1. Phase 5 (`5-validation/uat-validate/`) has been moved into `src/bmm/workflows/`, completing the phase 1-5 progression in the main module.
+
+---
+
+## Summary: Top 5 Actionable Improvements
+
+| Priority | Enhancement | User Impact |
+|----------|------------|-------------|
+| ~~**1**~~ | ~~Consolidate `src/bmm/` and `src/modules/bmm/`~~ | **RESOLVED** |
+| ~~**2**~~ | ~~Add file reference validation to CI pipeline~~ | **RESOLVED** |
+| **3** | Document and scaffold `project-context.md` in onboarding flow | Unblocks Phase 4 workflows for new users |
+| **4** | Standardize artifact folder strategy with clear commit guidance | Developers understand where outputs go and what to version control |
+| **5** | Add post-install guidance with example outputs | Reduces time-to-first-workflow from "confused" to "productive" |

src/bmm/agents/uat-validator.agent.yaml

@@ -29,23 +29,12 @@ agent:
     - "Generate validation report with clear go/no-go recommendation"
     - "Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`"
 
-  # Knowledge sources for test execution
-  conversational_knowledge:
-    - name: "uat-automation-patterns"
-      description: "Patterns for automating common UAT scenario types"
-      path: "{project-root}/_bmad/bmm/data/uat-automation-patterns.yaml"
-
   menu:
     # Primary: Execute UAT validation for a completed epic
     - trigger: UV or fuzzy match on uat-validate
       workflow: "{project-root}/_bmad/bmm/workflows/5-validation/uat-validate/workflow.yaml"
       description: "[UV] Execute UAT scenarios and validate epic against acceptance criteria (triggers self-healing on failure)"
 
-    # Review and summarize UAT results
-    - trigger: UR or fuzzy match on uat-report
-      exec: "{project-root}/_bmad/bmm/workflows/5-validation/uat-report/workflow.md"
-      description: "[UR] Generate UAT validation report with pass/fail summary and recommendations"
-
     # Quick validation - just check automatable scenarios
     - trigger: UQ or fuzzy match on uat-quick
       action: |

src/bmm/workflows/3-solutioning/create-architecture/workflow.md

@@ -36,7 +36,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 ### Paths
 
-- `installed_path` = `{project-root}/_bmad/bmm/workflows/3-solutioning/architecture`
+- `installed_path` = `{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture`
 - `template_path` = `{installed_path}/architecture-decision-template.md`
 - `data_files_path` = `{installed_path}/data/`
 

src/bmm/workflows/4-implementation/create-story/checklist.md

@@ -33,7 +33,7 @@ This is a COMPETITION to create the **ULTIMATE story context** that makes LLM de
 
 ### **When Running from Create-Story Workflow:**
 
-- The `{project-root}/_bmad/core/tasks/validate-workflow.xml` framework will automatically:
+- The `{project-root}/_bmad/core/tasks/workflow.xml` framework will automatically:
   - Load this checklist file
   - Load the newly created story file (`{story_file_path}`)
   - Load workflow variables from `{installed_path}/workflow.yaml`
@@ -63,7 +63,7 @@ You will systematically re-do the entire story creation process, but with a crit
 
 1. **Load the workflow configuration**: `{installed_path}/workflow.yaml` for variable inclusion
 2. **Load the story file**: `{story_file_path}` (provided by user or discovered)
-3. **Load validation framework**: `{project-root}/_bmad/core/tasks/validate-workflow.xml`
+3. **Load validation framework**: `{project-root}/_bmad/core/tasks/workflow.xml`
 4. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
 5. **Resolve all workflow variables**: story_dir, output_folder, epics_file, architecture_file, etc.
 6. **Understand current status**: What story implementation guidance is currently provided?

src/bmm/workflows/4-implementation/epic-chain/epic-chain-launcher.md

@@ -86,17 +86,17 @@ If approved, provide the shell command:
 
 **Dry run (recommended first):**
 ```bash
-./.bmad/scripts/epic-chain.sh 36 37 38 --dry-run --verbose
+./_bmad/scripts/epic-chain.sh 36 37 38 --dry-run --verbose
 ```
 
 **Full execution:**
 ```bash
-./.bmad/scripts/epic-chain.sh 36 37 38
+./_bmad/scripts/epic-chain.sh 36 37 38
 ```
 
 **Resume from specific epic:**
 ```bash
-./.bmad/scripts/epic-chain.sh 36 37 38 --start-from 37
+./_bmad/scripts/epic-chain.sh 36 37 38 --start-from 37
 ```
 
 ### Step 6: Explain Execution Flow
@@ -130,4 +130,4 @@ This ensures each subsequent epic benefits from learnings without context window
 - **standard**: Full epic/story analysis, pattern detection, risk assessment
 - **thorough**: Deep code analysis, test coverage review, performance considerations
 
-Set via: `./.bmad/scripts/epic-chain.sh 36 37 38 --analysis thorough`
+Set via: `./_bmad/scripts/epic-chain.sh 36 37 38 --analysis thorough`

src/bmm/workflows/4-implementation/epic-chain/instructions.md

@@ -1,7 +1,7 @@
 # Epic Chain - Analysis and Execution Instructions
 
-<critical>The workflow execution engine is governed by: {project-root}/.bmad/core/tasks/workflow.xml</critical>
-<critical>You MUST have already loaded and processed: {project-root}/.bmad/bmm/workflows/4-implementation/epic-chain/workflow.yaml</critical>
+<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
+<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmm/workflows/4-implementation/epic-chain/workflow.yaml</critical>
 
 ## Overview
 
@@ -255,13 +255,13 @@ Provide commands:
 
 ```bash
 # Dry run (recommended first)
-./.bmad/scripts/epic-chain.sh {epic_ids} --dry-run --verbose
+./_bmad/scripts/epic-chain.sh {epic_ids} --dry-run --verbose
 
 # Full execution
-./.bmad/scripts/epic-chain.sh {epic_ids}
+./_bmad/scripts/epic-chain.sh {epic_ids}
 
 # With specific options
-./.bmad/scripts/epic-chain.sh {epic_ids} --skip-done --verbose
+./_bmad/scripts/epic-chain.sh {epic_ids} --skip-done --verbose
 ```
 
 <action>Explain what will happen:</action>

src/bmm/workflows/4-implementation/epic-chain/workflow.md

@@ -157,16 +157,16 @@ This workflow uses shell orchestration similar to epic-execute:
 
 ```bash
 # Analyze and plan (no execution)
-./.bmad/scripts/epic-chain.sh 36 37 38 --analyze-only
+./_bmad/scripts/epic-chain.sh 36 37 38 --analyze-only
 
 # Execute with analysis
-./.bmad/scripts/epic-chain.sh 36 37 38
+./_bmad/scripts/epic-chain.sh 36 37 38
 
 # Resume from specific epic
-./.bmad/scripts/epic-chain.sh 36 37 38 --start-from 37
+./_bmad/scripts/epic-chain.sh 36 37 38 --start-from 37
 
 # Skip already-done epics
-./.bmad/scripts/epic-chain.sh 36 37 38 --skip-done
+./_bmad/scripts/epic-chain.sh 36 37 38 --skip-done
 ```
 
 ## Context Handoff Between Epics
@@ -204,7 +204,7 @@ Via SM Agent:
 
 Via Shell (after planning):
 ```bash
-./.bmad/scripts/epic-chain.sh 36 37 38
+./_bmad/scripts/epic-chain.sh 36 37 38
 ```
 
 ## Configuration

src/bmm/workflows/4-implementation/epic-chain/workflow.yaml

@@ -3,7 +3,7 @@ description: "Analyze and execute multiple epics in sequence with intelligent de
 author: "BMad"
 
 # Critical variables from config
-config_source: "{project-root}/.bmad/bmm/config.yaml"
+config_source: "{project-root}/_bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
@@ -11,7 +11,7 @@ date: system-generated
 sprint_artifacts: "{config_source}:sprint_artifacts"
 
 # Workflow components
-installed_path: "{project-root}/.bmad/bmm/workflows/4-implementation/epic-chain"
+installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/epic-chain"
 instructions: "{installed_path}/instructions.md"
 launcher: "{installed_path}/epic-chain-launcher.md"
 

src/bmm/workflows/4-implementation/epic-execute/epic-execute-launcher.md

@@ -23,17 +23,17 @@ Tell the user to run one of these commands:
 
 **Dry run (recommended first):**
 ```bash
-./.bmad/scripts/epic-execute.sh {epic_id} --dry-run --verbose
+./_bmad/scripts/epic-execute.sh {epic_id} --dry-run --verbose
 ```
 
 **Full execution:**
 ```bash
-./.bmad/scripts/epic-execute.sh {epic_id}
+./_bmad/scripts/epic-execute.sh {epic_id}
 ```
 
 **With verbose output:**
 ```bash
-./.bmad/scripts/epic-execute.sh {epic_id} --verbose
+./_bmad/scripts/epic-execute.sh {epic_id} --verbose
 ```
 
 ### Step 4: Explain What Happens

src/bmm/workflows/document-project/instructions.md

@@ -10,47 +10,9 @@
 
 <step n="1" goal="Validate workflow and get project info">
 
-<invoke-workflow path="{project-root}/_bmad/bmm/workflows/workflow-status">
-  <param>mode: data</param>
-  <param>data_request: project_config</param>
-</invoke-workflow>
-
-<check if="status_exists == false">
-  <output>{{suggestion}}</output>
-  <output>Note: Documentation workflow can run standalone. Continuing without progress tracking.</output>
-  <action>Set standalone_mode = true</action>
-  <action>Set status_file_found = false</action>
-</check>
-
-<check if="status_exists == true">
-  <action>Store {{status_file_path}} for later updates</action>
-  <action>Set status_file_found = true</action>
-
-  <!-- Extract brownfield/greenfield from status data -->
-  <check if="field_type == 'greenfield'">
-    <output>Note: This is a greenfield project. Documentation workflow is typically for brownfield projects.</output>
-    <ask>Continue anyway to document planning artifacts? (y/n)</ask>
-    <check if="n">
-      <action>Exit workflow</action>
-    </check>
-  </check>
-
-  <!-- Now validate sequencing -->
-  <invoke-workflow path="{project-root}/_bmad/bmm/workflows/workflow-status">
-    <param>mode: validate</param>
-    <param>calling_workflow: document-project</param>
-  </invoke-workflow>
-
-  <check if="warning != ''">
-    <output>{{warning}}</output>
-    <output>Note: This may be auto-invoked by prd for brownfield documentation.</output>
-    <ask>Continue with documentation? (y/n)</ask>
-    <check if="n">
-      <output>{{suggestion}}</output>
-      <action>Exit workflow</action>
-    </check>
-  </check>
-</check>
+<output>Note: Documentation workflow running in standalone mode. Continuing without progress tracking.</output>
+<action>Set standalone_mode = true</action>
+<action>Set status_file_found = false</action>
 
 </step>
 
@@ -177,18 +139,6 @@ Your choice [1/2/3]:
 
 <step n="4" goal="Update status and complete">
 
-<check if="status_file_found == true">
-  <invoke-workflow path="{project-root}/_bmad/bmm/workflows/workflow-status">
-    <param>mode: update</param>
-    <param>action: complete_workflow</param>
-    <param>workflow_name: document-project</param>
-  </invoke-workflow>
-
-  <check if="success == true">
-    <output>Status updated!</output>
-  </check>
-</check>
-
 <output>**✅ Document Project Workflow Complete, {user_name}!**
 
 **Documentation Generated:**
@@ -197,23 +147,10 @@ Your choice [1/2/3]:
 - Scan Level: {{scan_level}}
 - Output: {output_folder}/index.md and related files
 
-{{#if status_file_found}}
-**Status Updated:**
-
-- Progress tracking updated
-
 **Next Steps:**
 
-- **Next required:** {{next_workflow}} ({{next_agent}} agent)
-
-Check status anytime with: `workflow-status`
-{{else}}
-**Next Steps:**
-Since no workflow is in progress:
-
 - Refer to the BMM workflow guide if unsure what to do next
 - Or run `workflow-init` to create a workflow path and get guided next steps
-  {{/if}}
   </output>
 
 </step>