bmad-quick-dev: replace hardcoded code -r editor opens with OS-aware/configurable file-opening behavior

[thecontstruct]

Summary

The bmad-quick-dev workflow currently hardcodes code -r when opening review artifacts/files for the user. This assumes VS Code is the correct editor and breaks on machines where code points at a different editor than the one the user is actively using.

This should be replaced with an OS-aware opening strategy, plus an override for workflows that truly need a specific editor command.

Affected locations

Exact hardcoded opener instructions found in the repo:

1. .claude/skills/bmad-quick-dev/step-05-present.md

   • Current instruction:

   code -r "{absolute-root}" "{absolute-spec-file}"

2. .claude/skills/bmad-quick-dev/step-oneshot.md

   • Current instruction:

   code -r "{absolute-root}" <absolute-changed-file-paths>

Related VS Code-specific wording:

3. .claude/skills/bmad-quick-dev/step-03-implement.md
   • Refers to links being “clickable in VS Code”.
   • This is not the main bug, but it shows the workflow is biased toward one editor.

Problem

The workflow currently conflates two separate concerns:

• opening a file for the user
• opening a repo/workspace in a specific IDE

Hardcoding code -r causes several issues:

• Assumes VS Code is installed.
• Assumes code is the desired editor.
• Ignores the OS-configured default app for the target file type.
• Opens the wrong editor on systems where code exists but is not the active IDE.
• Is not portable across macOS, Linux, and Windows as a “default opener” strategy.

Expected behavior

When a workflow says “open this file for the user”, it should use an OS-appropriate default opener unless the workflow explicitly requires a specific IDE.

Proposed fix

Introduce a small abstraction for “open path for user” and make it OS-specific.

Suggested default behavior:

• macOS:

  open "{path}"

• Linux:

  xdg-open "{path}"

• Windows:

  start "" "{path}"

  or an equivalent PowerShell Start-Process

If the workflow explicitly needs a specific editor/workspace command, that should be configurable rather than hardcoded.

Suggested override options:

• environment variable such as BMAD_OPEN_COMMAND
• workflow config
• user-level config
• frontmatter setting for workflows that truly require a specific editor

Design guidance

The fallback/default should be:

• OS-specific
• editor-agnostic
• based on the system-configured default app for the file type

It should not simply be changed from code -r to the macOS-only open, because that just swaps one hardcoded platform assumption for another.

Suggested acceptance criteria

• step-05-present.md no longer hardcodes code -r.
• step-oneshot.md no longer hardcodes code -r.
• Default open behavior is OS-specific and uses the platform’s default file opener.
• There is a documented override for workflows/users that want a specific editor command.
• The workflow distinguishes between:
  • “open this file/path for the user”
  • “open in a specific IDE/workspace”
• Failure messaging reflects the new open strategy.

Notes

A fair counterargument is that opening both the repo root and changed files in a single IDE can improve navigation. That’s valid, but it should be an explicit configured mode, not the universal default.

[coderabbitai]

🔗 Related PRs

#1185 - refactor: convert create-tech-spec to sharded workflow with orient-first pattern [merged]
#2039 - feat(quick-dev): add VS Code opening ergonomics to step 5 [merged]
#2049 - feat(quick-dev): clickable spec link at step-02 checkpoint and CWD-relative path convention [merged]
#2085 - fix(quick-dev): make file path references clickable [merged]
#2087 - fix(quick-dev): use absolute paths in code -r invocations [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!

[bmadcode]

Going to mark this wontfix for now. Reasoning:

1. The current code -r invocation already has a fallback path for non-VSCode environments, so the editor-open step doesn't hard-block users without VSCode.
2. The Quick Dev workflow is being merged into the unified single dev skill in an upcoming release, where editor-open behavior will be customizable as part of the broader customization layer.

Closing now to keep the queue clean — please reopen if the fallback doesn't work in your environment and we'll revisit ahead of the merge.