bmad-method 6.2.1-next.29 → 6.2.1-next.30

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "$schema": "https://json.schemastore.org/package.json",
3
3
  "name": "bmad-method",
4
- "version": "6.2.1-next.29",
4
+ "version": "6.2.1-next.30",
5
5
  "description": "Breakthrough Method of Agile AI-driven Development",
6
6
  "keywords": [
7
7
  "agile",
@@ -53,7 +53,7 @@ When there is only one concern, omit the bold label — just list the stops dire
53
53
  1. Change `{spec_file}` status to `done` in the frontmatter.
54
54
  2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
55
55
  3. Open the spec in the user's editor so they can click through the Suggested Review Order:
56
- - Run `code -r "{spec_file}"` to open the spec in the current VS Code window (reuses the window where the project or worktree is open). Always double-quote the path to handle spaces and special characters.
56
+ - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
57
57
  - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
58
58
  4. Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators. Include:
59
59
  - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
@@ -36,7 +36,7 @@ If version control is available and the tree is dirty, create a local commit wit
36
36
  ### Present
37
37
 
38
38
  1. Open all changed files in the user's editor so they can review the code directly:
39
- - Run `code -r "{project-root}" <changed-file-paths>` — the project root as the first argument, then each changed file path. Always double-quote paths with spaces.
39
+ - Resolve two sets of absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) each changed file. Run `code -r "{absolute-root}" <absolute-changed-file-paths>` — the root first so VS Code opens in the right context, then each changed file. Always double-quote paths to handle spaces and special characters.
40
40
  - If `code` is not available (command fails), skip gracefully and list the file paths instead.
41
41
  2. Display a summary in conversation output, including:
42
42
  - The commit hash (if one was created).