fix: bmad-help reads project docs and respects communication_language (#1535)

* fix: bmad-help agent reads project docs and respects communication_language

The help task fabricated tech stack information instead of reading actual
project documentation (#1460) and ignored communication_language config
(#1457). Three changes:

1. Step 2 now also extracts communication_language and project_knowledge
   from the active module's config.yaml
2. New step 3 scans project_knowledge path for documentation and uses
   discovered facts as grounding context, with anti-hallucination guard
3. Step 7 enforces {communication_language} in all output

Chose inline config resolution over workflow.yaml conversion to match
existing core task patterns (index-docs, shard-doc).

Fixes #1460
Relates to #1457

* fix: clarify config extraction wording in help task

Remove "active module" reference from step 2 — config extraction
happens during the all-modules scan, before module detection in
step 4. Changed to "each scanned module's config" to match the
existing iteration pattern.

Addresses CodeRabbit review feedback on PR #1535.

---------

Co-authored-by: Brian <bmadcode@gmail.com>
This commit is contained in:
Michael Pursifull 2026-02-05 19:04:31 -06:00 committed by GitHub
parent 311b237d85
commit 420e720242
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 6 deletions

View File

@ -54,13 +54,15 @@ Determine what was just completed:
1. **Load catalog** — Load `{project-root}/_bmad/_config/bmad-help.csv`
2. **Resolve output locations** — Scan each folder under `_bmad/` (except `_config`) for `config.yaml`. For each workflow row, resolve its `output-location` variables against that module's config so artifact paths can be searched.
2. **Resolve output locations and config** — Scan each folder under `_bmad/` (except `_config`) for `config.yaml`. For each workflow row, resolve its `output-location` variables against that module's config so artifact paths can be searched. Also extract `communication_language` and `project_knowledge` from each scanned module's config.
3. **Detect active module** — Use MODULE DETECTION above
3. **Ground in project knowledge** — If `project_knowledge` resolves to an existing path, read available documentation files (architecture docs, project overview, tech stack references) for grounding context. Use discovered project facts when composing any project-specific output. Never fabricate project-specific details — if documentation is unavailable, state so.
4. **Analyze input** — Task may provide a workflow name/code, conversational phrase, or nothing. Infer what was just completed using INPUT ANALYSIS above.
4. **Detect active module** — Use MODULE DETECTION above
5. **Present recommendations** — Show next steps based on:
5. **Analyze input** — Task may provide a workflow name/code, conversational phrase, or nothing. Infer what was just completed using INPUT ANALYSIS above.
6. **Present recommendations** — Show next steps based on:
- Completed workflows detected
- Phase/sequence ordering (ROUTING RULES)
- Artifact presence
@ -74,9 +76,10 @@ Determine what was just completed:
- **Agent** title and display name from the CSV (e.g., "🎨 Alex (Designer)")
- Brief **description**
6. **Additional guidance to convey**:
7. **Additional guidance to convey**:
- Present all output in `{communication_language}`
- Run each workflow in a **fresh context window**
- For **validation workflows**: recommend using a different high-quality LLM if available
- For conversational requests: match the user's tone while presenting clearly
7. Return to the calling process after presenting recommendations.
8. Return to the calling process after presenting recommendations.