feat: Add command line flag for non-interactive BMM project knowledge directory selection

[wsmoak]

Description

When installing with --modules bmm --yes, the long-term project knowledge location always defaults to docs in non-interactive mode.
There is currently no CLI flag to override this value.

In interactive mode, this is configurable via the prompt:

• Where should long-term project knowledge be stored? (docs, research, references)

A new CLI flag (for example, --project-knowledge <path>) would allow setting this explicitly during unattended installs.

Example usage

npx bmad-method install \
  --directory /path/to/project \
  --modules bmm \
  --tools codex \
  --project-knowledge research \
  --yes

Concerns

Should it be --bmm-project-knowledge since this is specific to the BMM module? Do we have a pattern for this when modules want to accept command-line flags?

Relevant code

• module.yaml (project_knowledge default is docs)
• install.js (add CLI option definition)
• ui.js (map CLI option into collected config)
• non-interactive-installation.md (document new flag)

[coderabbitai]

🔗 Related PRs

#1520 - feat: add non-interactive installation support [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[dracic]

Question: Scope of BMM CLI flags for non-interactive install

@wsmoak @bmadcode — Before implementing --project-knowledge, I wanted to raise the question of whether we should expand scope to cover all BMM module options that are currently only available in interactive mode.

Current State

Core options already have CLI flag support:

• --user-name
• --communication-language
• --document-output-language
• --output-folder

BMM module options have zero CLI flag support — all 5 silently use defaults when --yes is passed:

BMM Option	Interactive Prompt	Default (non-interactive)	Proposed Flag
project_name	"What is your project called?"	directory name	--project-name
user_skill_level	"What is your development experience level?"	intermediate	--user-skill-level
planning_artifacts	"Where should planning artifacts be stored?"	{output}/planning-artifacts	--planning-artifacts
implementation_artifacts	"Where should implementation artifacts be stored?"	{output}/implementation-artifacts	--implementation-artifacts
project_knowledge	"Where should long-term project knowledge be stored?"	docs	--project-knowledge

Options

1. Minimal — Only add --project-knowledge (as this issue requests)
2. Full coverage — Add CLI flags for all 5 BMM options
3. Selective — Pick a subset that makes sense for unattended installs (e.g. --project-knowledge + --project-name)

Context

• Suggestion: BMM is the only module we plan to support via CLI switches — other modules will use JSON/YAML config loading
• The plumbing in config-collector.js already has a mechanism for pre-filled/"static" answers that can be extended
• Adding all 5 flags is not significantly more work than adding 1

What are your thoughts — go full coverage, or keep it scoped?

[wsmoak]

Is there a design doc or info on how the yaml config will work? I'm not set on command line options, I just need a way to keep bmad out of the docs directory.

[thecontstruct]

what if we left the cli args to only install the module defaults as is, and alternatively allow for passing in a json config file that replaces the cli args entirely (one or the other, not both). Then people can configure it however they want once and reuse that config for any updates, etc.

That's usually the next step when building CLI's whose args start to proliferate.