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

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.27",
4
+ "version": "6.2.1-next.29",
5
5
  "description": "Breakthrough Method of Agile AI-driven Development",
6
6
  "keywords": [
7
7
  "agile",
@@ -26,6 +26,8 @@ Change `{spec_file}` status to `in-progress` in the frontmatter before starting
26
26
 
27
27
  Hand `{spec_file}` to a sub-agent/task and let it implement. If no sub-agents are available, implement directly.
28
28
 
29
+ **Path formatting rule:** Any markdown links written into `{spec_file}` must use paths relative to `{spec_file}`'s directory so they are clickable in VS Code. Any file paths displayed in terminal/conversation output must use CWD-relative format with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/` in either case.
30
+
29
31
  ## NEXT
30
32
 
31
33
  Read fully and follow `./step-04-review.md`
@@ -22,7 +22,7 @@ Build the trail as an ordered sequence of **stops** — clickable `path:line` re
22
22
  2. **Lead with the entry point** — the single highest-leverage file:line a reviewer should look at first to grasp the design intent.
23
23
  3. **Inside each concern**, order stops from most important / architecturally interesting to supporting. Lightly bias toward higher-risk or boundary-crossing stops.
24
24
  4. **End with peripherals** — tests, config, types, and other supporting changes come last.
25
- 5. **Every code reference is a clickable workspace-relative link** (project-root-relative for clickability in the editor). Format each stop as a markdown link: `[short-name:line](/project-root-relative/path/to/file.ts#L42)`. The link target uses a leading `/` (workspace root) with a `#L` line anchor. Use the file's basename (or shortest unambiguous suffix) plus line number as the link text.
25
+ 5. **Every code reference is a clickable spec-file-relative link.** Compute each link target as a relative path from `{spec_file}`'s directory to the changed file. Format each stop as a markdown link: `[short-name:line](../../path/to/file.ts#L42)`. Use a `#L` line anchor. Use the file's basename (or shortest unambiguous suffix) plus line number as the link text. The relative path must be dynamically derived — never hardcode the depth.
26
26
  6. **Each stop gets one ultra-concise line of framing** (≤15 words) — why this approach was chosen here and what it achieves in the context of the change. No paragraphs.
27
27
 
28
28
  Format each stop as framing first, link on the next indented line:
@@ -33,17 +33,19 @@ Format each stop as framing first, link on the next indented line:
33
33
  **{Concern name}**
34
34
 
35
35
  - {one-line framing}
36
- [`file.ts:42`](/src/path/to/file.ts#L42)
36
+ [`file.ts:42`](../../src/path/to/file.ts#L42)
37
37
 
38
38
  - {one-line framing}
39
- [`other.ts:17`](/src/path/to/other.ts#L17)
39
+ [`other.ts:17`](../../src/path/to/other.ts#L17)
40
40
 
41
41
  **{Next concern}**
42
42
 
43
43
  - {one-line framing}
44
- [`file.ts:88`](/src/path/to/file.ts#L88)
44
+ [`file.ts:88`](../../src/path/to/file.ts#L88)
45
45
  ```
46
46
 
47
+ > The `../../` prefix above is illustrative — compute the actual relative path from `{spec_file}`'s directory to each target file.
48
+
47
49
  When there is only one concern, omit the bold label — just list the stops directly.
48
50
 
49
51
  ### Commit and Present
@@ -53,7 +55,7 @@ When there is only one concern, omit the bold label — just list the stops dire
53
55
  3. Open the spec in the user's editor so they can click through the Suggested Review Order:
54
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.
55
57
  - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
56
- 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 `/`) for terminal clickability — this differs from spec-file links which use project-root-relative paths. Include:
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:
57
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.
58
60
  - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
59
61
  - Offer to push and/or create a pull request.
@@ -40,7 +40,7 @@ If version control is available and the tree is dirty, create a local commit wit
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).
43
- - List of files changed with one-line descriptions.
43
+ - List of files changed with one-line descriptions. Use CWD-relative paths with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/`.
44
44
  - Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
45
45
  3. Offer to push and/or create a pull request.
46
46
 
@@ -704,21 +704,12 @@ class ManifestGenerator {
704
704
  continue;
705
705
  }
706
706
 
707
- // Check if this looks like a module (has agents, workflows, or tasks directory)
707
+ // Check if this looks like a module (has agents directory or skill manifests)
708
708
  const modulePath = path.join(bmadDir, entry.name);
709
709
  const hasAgents = await fs.pathExists(path.join(modulePath, 'agents'));
710
- const hasWorkflows = await fs.pathExists(path.join(modulePath, 'workflows'));
711
- const hasTasks = await fs.pathExists(path.join(modulePath, 'tasks'));
712
- const hasTools = await fs.pathExists(path.join(modulePath, 'tools'));
713
-
714
- // Check for native-entrypoint-only modules: recursive scan for SKILL.md
715
- let hasSkills = false;
716
- if (!hasAgents && !hasWorkflows && !hasTasks && !hasTools) {
717
- hasSkills = await this._hasSkillMdRecursive(modulePath);
718
- }
710
+ const hasSkills = await this._hasSkillMdRecursive(modulePath);
719
711
 
720
- // If it has any of these directories or skill manifests, it's likely a module
721
- if (hasAgents || hasWorkflows || hasTasks || hasTools || hasSkills) {
712
+ if (hasAgents || hasSkills) {
722
713
  modules.push(entry.name);
723
714
  }
724
715
  }
@@ -27,7 +27,7 @@ async function loadSkillManifest(dirPath) {
27
27
  /**
28
28
  * Get the canonicalId for a specific file from a loaded skill manifest.
29
29
  * @param {Object|null} manifest - Loaded manifest (from loadSkillManifest)
30
- * @param {string} filename - Source filename to look up (e.g., 'pm.md', 'help.md', 'pm.agent.yaml')
30
+ * @param {string} filename - Source filename to look up (e.g., 'pm.md', 'help.md')
31
31
  * @returns {string} canonicalId or empty string
32
32
  */
33
33
  function getCanonicalId(manifest, filename) {
@@ -36,12 +36,6 @@ function getCanonicalId(manifest, filename) {
36
36
  if (manifest.__single) return manifest.__single.canonicalId || '';
37
37
  // Multi-entry: look up by filename directly
38
38
  if (manifest[filename]) return manifest[filename].canonicalId || '';
39
- // Fallback: try alternate extensions for compiled files
40
- const baseName = filename.replace(/\.(md|xml)$/i, '');
41
- const agentKey = `${baseName}.agent.yaml`;
42
- if (manifest[agentKey]) return manifest[agentKey].canonicalId || '';
43
- const xmlKey = `${baseName}.xml`;
44
- if (manifest[xmlKey]) return manifest[xmlKey].canonicalId || '';
45
39
  return '';
46
40
  }
47
41
 
@@ -57,12 +51,6 @@ function getArtifactType(manifest, filename) {
57
51
  if (manifest.__single) return manifest.__single.type || null;
58
52
  // Multi-entry: look up by filename directly
59
53
  if (manifest[filename]) return manifest[filename].type || null;
60
- // Fallback: try alternate extensions for compiled files
61
- const baseName = filename.replace(/\.(md|xml)$/i, '');
62
- const agentKey = `${baseName}.agent.yaml`;
63
- if (manifest[agentKey]) return manifest[agentKey].type || null;
64
- const xmlKey = `${baseName}.xml`;
65
- if (manifest[xmlKey]) return manifest[xmlKey].type || null;
66
54
  return null;
67
55
  }
68
56
 
@@ -78,12 +66,6 @@ function getInstallToBmad(manifest, filename) {
78
66
  if (manifest.__single) return manifest.__single.install_to_bmad !== false;
79
67
  // Multi-entry: look up by filename directly
80
68
  if (manifest[filename]) return manifest[filename].install_to_bmad !== false;
81
- // Fallback: try alternate extensions for compiled files
82
- const baseName = filename.replace(/\.(md|xml)$/i, '');
83
- const agentKey = `${baseName}.agent.yaml`;
84
- if (manifest[agentKey]) return manifest[agentKey].install_to_bmad !== false;
85
- const xmlKey = `${baseName}.xml`;
86
- if (manifest[xmlKey]) return manifest[xmlKey].install_to_bmad !== false;
87
69
  return true;
88
70
  }
89
71