refactor(skills): convert party-mode to native skill directory#1906
refactor(skills): convert party-mode to native skill directory#1906bmadcode merged 1 commit intobmad-code-org:mainfrom
Conversation
- Rename party-mode → bmad-party-mode (canonical ID convention) - Change bmad-skill-manifest.yaml from type:workflow to type:skill - Add SKILL.md with frontmatter for installer discovery - Remove installed_path, use relative ./steps/ refs internally - Update module-help.csv to skill:bmad-party-mode - Update compiler.js hardcoded PM menu path - Update 43 cross-references to IDE-agnostic _bmad/ path - Update test fixtures for renamed directory Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
🤖 Augment PR SummarySummary: Converts “party-mode” from a workflow redirect into a first-class native skill directory. 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
|
|
||
| - When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md | ||
| - When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode | ||
| - When 'P' selected: Execute {project-root}/_bmad/core/workflows/bmad-party-mode |
There was a problem hiding this comment.
This executes {project-root}/_bmad/core/workflows/bmad-party-mode as a directory; since party-mode is now a type: skill, can you confirm the executor resolves a directory to the correct entrypoint (e.g., SKILL.md/workflow.md) so this reference can’t break?
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
📝 WalkthroughWalkthroughThis PR updates workflow references across 48+ files in the BMM (BMAD Method) workflows directory, transitioning from the legacy Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (10)
src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-01-validate-prerequisites.md (1)
12-20:⚠️ Potential issue | 🟠 MajorRemove the duplicate
epicsTemplatekey from the frontmatter block.The key appears at line 13 and again at line 20 with identical values. YAML parsers use last-wins semantics for duplicate keys, creating silent failure modes if one copy drifts during future maintenance. Keep a single declaration.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-01-validate-prerequisites.md` around lines 12 - 20, The frontmatter contains a duplicate key epicsTemplate: remove the second occurrence so only a single epicsTemplate declaration remains in the frontmatter block; ensure the remaining epicsTemplate line uses the intended value '{workflow_path}/templates/epics-template.md' and delete the redundant duplicate to avoid last-wins YAML ambiguity.src/core/workflows/bmad-party-mode/workflow.md (1)
114-124:⚠️ Potential issue | 🟡 Minor
workflowTypenot updated to match renamed workflow.Line 117 still references
workflowType: 'party-mode'while the workflow was renamed tobmad-party-mode. This inconsistency could cause confusion or issues if downstream tooling relies on theworkflowTypematching the canonical workflow name.🔧 Proposed fix
--- stepsCompleted: [1] -workflowType: 'party-mode' +workflowType: 'bmad-party-mode' user_name: '{{user_name}}' date: '{{date}}'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/core/workflows/bmad-party-mode/workflow.md` around lines 114 - 124, Update the YAML metadata so the workflowType value matches the renamed workflow: change the workflowType field (currently 'party-mode') to 'bmad-party-mode' to keep the canonical name consistent with the workflow rename; check the surrounding keys (stepsCompleted, user_name, agents_loaded, party_active, exit_triggers) for any other stale references and update if needed.src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-02-design-epics.md (1)
198-198:⚠️ Potential issue | 🟠 MajorMenu handling assumes Party Mode always returns cleanly.
Line 198 says "Read fully and follow: {partyModeWorkflow}" and line 206 says "After other menu items execution completes, redisplay the menu." This assumes the Party Mode workflow will:
- Complete execution (not hang or infinite loop)
- Return control to this step (not exit or navigate elsewhere)
- Leave the agent in a state where it can redisplay the menu
But there's no timeout, no cancellation mechanism, and no validation that the workflow completed successfully. If Party Mode enters an error state or infinite loop, the user has no recovery path.
Consider adding:
- Maximum execution time limit for invoked workflows
- Cancellation command (e.g., user types "exit party mode")
- Health check after workflow returns before redisplaying menu
- Fallback to original content if workflow fails
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-02-design-epics.md` at line 198, The menu flow assumes {partyModeWorkflow} always returns cleanly; update the step that invokes partyModeWorkflow (the "IF P: Read fully and follow: {partyModeWorkflow}" branch and the logic that "redisplay the menu") to enforce a bounded execution: invoke partyModeWorkflow with a maximum execution timeout, support a user-triggered cancellation token/command (e.g., "exit party mode") that aborts the workflow, validate the workflow result/health before redisplaying the menu (check for successful completion or explicit error state), and implement a fallback path that restores the original content or shows an error message and returns to the main menu if the workflow fails or times out.src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-08-scoping.md (1)
187-187:⚠️ Potential issue | 🟡 MinorMissing error handling when Party Mode workflow fails to load.
Line 187 invokes
{partyModeWorkflow}but provides no fallback if the workflow fails to load. The instruction says "Read fully and follow" but doesn't specify what happens if the read fails, if the workflow halts with an error, or if the workflow returns malformed content.According to the EXECUTION RULES at line 192, "After other menu items execution, return to this menu," but this assumes the workflow completes successfully. If it crashes, the user is left in an undefined state.
Add explicit error handling contract: "If Party Mode workflow fails to load or errors during execution, inform the user and redisplay the A/P/C menu with the original content."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-08-scoping.md` at line 187, The {partyModeWorkflow} invocation lacks error handling; update the step to explicitly catch load/execute failures or malformed results and implement a fallback: if {partyModeWorkflow} fails to load or errors during execution, display a clear user-facing error message, preserve the original content, and redisplay the A/P/C menu (do not apply any changes), then allow the user to continue; ensure this contract is enforced wherever {partyModeWorkflow} is called in this step and that any returned value is validated before use.src/bmm/workflows/1-analysis/create-product-brief/steps/step-02-vision.md (1)
160-160:⚠️ Potential issue | 🟡 MinorParty Mode invocation doesn't specify which content to pass.
Line 160 says "Read fully and follow: {partyModeWorkflow} to bring different perspectives to positioning and differentiation" but doesn't explicitly state WHAT content is passed to the Party Mode workflow.
Based on context, it should be "with the current vision content" (similar to line 159's Advanced Elicitation invocation: "with current vision content to dive deeper and refine"). Without this clarity, the agent might invoke Party Mode without properly contextualizing the conversation.
🔧 Add explicit content parameter
-- IF P: Read fully and follow: {partyModeWorkflow} to bring different perspectives to positioning and differentiation +- IF P: Read fully and follow: {partyModeWorkflow} with the current vision content to bring different perspectives to positioning and differentiation🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/1-analysis/create-product-brief/steps/step-02-vision.md` at line 160, The Party Mode invocation "{partyModeWorkflow}" is missing the content to pass; update the instruction so it explicitly invokes {partyModeWorkflow} with the current vision content (e.g., "with current vision content" or equivalent) to ensure Party Mode receives the same context used by the Advanced Elicitation step and can bring alternative perspectives to positioning and differentiation; modify the step text that currently reads "Read fully and follow: {partyModeWorkflow}" to include the explicit content parameter "with current vision content" alongside {partyModeWorkflow}.src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md (5)
230-235:⚠️ Potential issue | 🟡 MinorMenu options lack usage context.
The menu presents "[A] Advanced Elicitation [P] Party Mode [C] Continue" with no explanation of what each option does or when it's appropriate to select it. A user completing Step 3 has no guidance on whether they need Advanced Elicitation, when Party Mode is beneficial, or what happens if they choose incorrectly.
At minimum, add a one-line hint for each non-obvious option (A and P) describing its purpose or trigger condition.
📋 Example: Add context to menu display
-Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue" +Display: "**Select an Option:** +[A] Advanced Elicitation (refine requirements via deeper questioning) +[P] Party Mode (multi-step epic/story review with celebration) +[C] Continue to validation"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` around lines 230 - 235, The menu lacks context for options A and P; update the prompt string or nearby copy where "Display: \"**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue\"" is defined so that each non-obvious option includes a one-line hint (e.g., append or replace labels with short clarifiers like "[A] Advanced Elicitation — run when requirements are incomplete or ambiguous; elicits deeper details" and "[P] Party Mode — use for rapid brainstorming with multiple stakeholders; relaxed validation"), and ensure the branching references advancedElicitationTask and partyModeWorkflow remain unchanged so selecting A triggers advancedElicitationTask and P triggers partyModeWorkflow.
173-181:⚠️ Potential issue | 🟠 MajorCollaborative review omits critical dependency validation.
The Collaborative Review section (lines 173-181) asks three validation questions after each story but omits the most critical check from line 52: verifying that the story has no dependencies on future stories within the epic. Given that forward dependencies are marked CRITICAL and extensively documented (lines 52, 90-96, 134-135), this validation must be included in the review checklist.
Add a fourth question: "Does this story depend only on previous stories (no forward dependencies)?"
🔍 Proposed addition to collaborative review
- "Does this story capture the requirement correctly?" - "Is the scope appropriate for a single dev session?" - "Are the acceptance criteria complete and testable?" +- "Does this story depend ONLY on previous stories (no forward dependencies within epic)?"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` around lines 173 - 181, In the "D. Collaborative Review" section (the three bullet questions after writing each story) add a fourth checklist item that enforces the documented rule against forward dependencies: insert the question "Does this story depend only on previous stories (no forward dependencies)?" so reviewers explicitly verify the story has no dependencies on future stories (per the CRITICAL forward-dependency guidance referenced elsewhere in the document).
236-236:⚠️ Potential issue | 🟡 MinorAmbiguous "update frontmatter" instruction.
The instruction "Save content to {outputFile}, update frontmatter, then read fully and follow: {nextStepFile}" is unclear. The
{outputFile}is{planning_artifacts}/epics.md, which is the collaborative output document being built throughout the workflow, not this step file. It's unclear:
- What frontmatter exists in
epics.mdthat needs updating- What specific frontmatter fields should be changed
- Whether this refers to updating the step file's own frontmatter (unlikely, as that would break the step's definition)
This appears to be either a copy-paste artifact or a missing specification. Clarify which file's frontmatter is being updated and what fields change.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` at line 236, Clarify and replace the ambiguous "update frontmatter" step to say exactly which file and which fields to modify: explicitly state that the frontmatter in {outputFile} (i.e., {planning_artifacts}/epics.md) should be updated, and enumerate the fields to set (for example: updated_at: <timestamp>, epics_count: <number>, epics_index: <list/summary> or add a new metadata field like last_modified_by). Modify the instruction in step-03-create-stories.md so it reads: "IF C: Save content to {outputFile} ({planning_artifacts}/epics.md), update {outputFile} frontmatter fields [list fields] with their new values, then read the file fully and proceed to {nextStepFile}"; ensure the fields named match the code that consumes them elsewhere in this workflow.
65-70:⚠️ Potential issue | 🟡 MinorMissing prerequisite validation before file load.
The instruction "Load {outputFile} and review:" assumes the file exists and contains the approved epics_list from Step 2, with no validation or error handling. If Step 2 was skipped, failed, or produced malformed output, this step would fail ungracefully.
Add a validation instruction: "IF {outputFile} does not exist or lacks 'Approved Epic Structure' section, HALT and instruct user to complete Step 2 first."
🛡️ Proposed validation guard
### 1. Load Approved Epic Structure +**Prerequisite Check:** +- Verify {outputFile} exists and contains section "## Epic List" +- IF missing: HALT with message "Step 2 incomplete. Run step-02-design-epics.md first." + Load {outputFile} and review:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` around lines 65 - 70, Before attempting to "Load {outputFile} and review", add a prerequisite validation that checks whether {outputFile} exists and contains the "Approved Epic Structure" section; if the file is missing or the "Approved Epic Structure" section is absent or malformed, HALT the step and instruct the user to complete Step 2 first (do not proceed to FR coverage map or requirements review). Implement this guard immediately before the file load in the step logic that references {outputFile} so the step fails fast with a clear user-facing message directing them to Step 2.
186-189:⚠️ Potential issue | 🟡 MinorFile append operation lacks error handling.
The instruction "Append it to {outputFile} following template structure" (line 186) has no validation or error handling. File writes can fail due to permissions, disk space, or I/O errors. If the append silently fails, approved stories are lost with no user notification or recovery mechanism.
Add: "After appending, confirm content was written successfully. On failure, HALT and report error to user."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` around lines 186 - 189, The append step that writes approved stories to {outputFile} must validate the write: after performing the append described in the "Append it to {outputFile} following template structure" step, verify the write succeeded (e.g., check returned status/bytes written or re-read the tail of {outputFile}) and confirm the content matches the expected template (Epic N, Story M). If verification fails or an I/O error occurs, immediately HALT further processing and surface a clear error to the user describing the failure and remediation (permissions, disk space, retry). Ensure this verification and error path is documented in the step (step-03-create-stories.md) so the workflow never silently loses approved stories.
🧹 Nitpick comments (32)
src/bmm/workflows/generate-project-context/steps/step-02-generate.md (1)
30-34: Stop hand-inlining protocol targets in step prose.This file already drifted from the rest of the rename because the Party Mode path lives as a raw literal in the instructions. Pull it behind one local/workflow variable instead of repeating raw paths in prose, or the next rename will be another repo-wide cleanup.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/generate-project-context/steps/step-02-generate.md` around lines 30 - 34, The step prose currently hardcodes the Party Mode workflow path ("{project-root}/_bmad/core/workflows/bmad-party-mode")—replace that literal with a local reference/variable defined at top of this markdown (e.g., PROTOCOL_PARTY_MODE or workflow_party_mode) and use that variable in the "When 'P' selected" line so the protocol target is referenced symbolically (similar to how the A path uses {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md); ensure the variable name is unique in this file and update the "When 'P' selected" sentence to reference that variable instead of the raw path.src/bmm/workflows/3-solutioning/create-architecture/steps/step-05-patterns.md (1)
33-38: Single-source the Party Mode path inside this step.You now have the same
bmad-party-mode/workflow.mdliteral in two places in this file. That is needless churn and it is exactly how one copy gets renamed while the other is missed later. Define the reference once and reuse it in both protocol branches.Also applies to: 314-320
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-architecture/steps/step-05-patterns.md` around lines 33 - 38, The file duplicates the literal path "bmad-party-mode/workflow.md" in multiple protocol branches; define a single reference variable or anchor at the top of this step (e.g., PARTY_MODE_PATH = "bmad-party-mode/workflow.md" or a Markdown reference link) and replace both occurrences under the PROTOCOL INTEGRATION section (and the similar block around lines 314-320) to reuse that single reference so future renames only need one update.src/bmm/workflows/3-solutioning/create-architecture/steps/step-07-validation.md (1)
33-38: This migration still leaves two copies of the same Party Mode reference here.Both updated blocks point at the exact same
bmad-party-mode/workflow.mdstring. Collapse that to one reusable reference before the next path change turns into another scavenger hunt.Also applies to: 314-320
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-architecture/steps/step-07-validation.md` around lines 33 - 38, The PROTOCOL INTEGRATION section contains duplicate references to the exact same path string "bmad-party-mode/workflow.md"; remove the redundant occurrence and collapse both A/P references to a single reusable reference (e.g., keep one bullet pointing to {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md and remove or replace the duplicate with a short pointer such as "see above" or the single reference), updating the PROTOCOLS bullets for 'P' and any other repeated mention so they all reference that single canonical path; do the same cleanup for the other matching duplicate block noted elsewhere in this file (the other repeated bmad-party-mode reference).src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md (1)
4-6: This alias only helps if the quick-flow steps actually consume it.If downstream quick-flow steps keep inlining the Party Mode path instead of referencing
party_mode_exec, this variable is just decorative and the next rename will drift again. Make the alias the only Party Mode entrypoint for this workflow family.Based on learnings, "workflow.md persists as root context throughout all step execution. Step files can reference standards and configuration defined in workflow.md."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/workflow.md` around lines 4 - 6, The alias party_mode_exec defined in this workflow.md is currently decorative; update downstream quick-flow step files to import and use party_mode_exec as the single Party Mode entrypoint instead of inlining the path string. Search for any step or file that currently references the Party Mode path literal (e.g., occurrences of '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md') and replace those with a reference to the workflow-level variable party_mode_exec so all steps consume the central alias defined in this workflow.md.src/bmm/workflows/3-solutioning/create-architecture/steps/step-06-structure.md (1)
33-38: This step duplicates the same Party Mode target twice.Both the protocol block and the
Pbranch hardcode the samebmad-party-mode/workflow.mdpath. Keep that reference in one place; otherwise the next rename will miss one of the two copies again.Also applies to: 334-340
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-architecture/steps/step-06-structure.md` around lines 33 - 38, The PROTOCOL INTEGRATION block duplicates the same Party Mode path (bmad-party-mode/workflow.md) in both the general protocol list and the 'P' branch; consolidate the reference so the path appears only once by removing the hardcoded duplicate in the 'P' branch and referencing the centralized PROTOCOL INTEGRATION entry instead (update any wording in the 'P' branch that currently hardcodes bmad-party-mode/workflow.md to point to or rely on the PROTOCOL INTEGRATION item), ensuring the menu behavior and "return to A/P/C" and user accept/reject logic remain unchanged.src/bmm/workflows/3-solutioning/create-architecture/steps/step-03-starter.md (1)
32-37: Please stop duplicating the Party Mode path in the same step file.The protocol section and the
Pbranch both inlinebmad-party-mode/workflow.md. That buys nothing and makes this migration harder to maintain than it needs to be.Also applies to: 285-291
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-architecture/steps/step-03-starter.md` around lines 32 - 37, The PROTOCOL INTEGRATION section is duplicating the Party Mode path by inlining bmad-party-mode/workflow.md in both the protocol list and the `P` branch; remove the duplicate inline content and replace it with a single canonical include/reference to bmad-party-mode/workflow.md (same for the other occurrence noted later), keeping the `P` branch as a pointer to that single include; ensure the PROTOCOLS behavior (return to A/P/C menu) and the user accept/reject step remain intact after consolidation, and update any headings or comments in the `PROTOCOL INTEGRATION` and `P` branch blocks to reference only the shared bmad-party-mode/workflow.md entry.src/bmm/workflows/3-solutioning/create-architecture/steps/step-02-context.md (1)
32-37: Duplicate path literals in one step are asking for drift.This step now hardcodes the same
bmad-party-mode/workflow.mdreference in both the integration section and thePbranch. One source of truth would be enough here; two copies just create another rename hazard.Also applies to: 179-185
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-architecture/steps/step-02-context.md` around lines 32 - 37, The step duplicates the same "bmad-party-mode/workflow.md" literal in both the PROTOCOL INTEGRATION block and the P branch, risking drift; consolidate to a single reference (e.g., remove the duplicated literal from the integration list and instead point to the P branch or introduce one canonical token like "{protocol-p-workflow}" used in both places) so only one source of truth exists for the bmad-party-mode workflow; update the PROTOCOL INTEGRATION lines that currently mention bmad-party-mode/workflow.md and the P branch entry to use that single canonical reference and ensure the note about returning to the A/P/C menu and user acceptance remains unchanged.src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-02-discovery.md (1)
140-158: Menu presentation inconsistency (pre-existing).The COLLABORATION MENUS section (lines 23-29) defines A, P, and C options, but the "Present Content and Menu" section at lines 149-150 only shows
[C] Continue. This means users aren't presented with the A or P options that are described in the protocols.However, this inconsistency appears pre-existing and is not introduced by this PR's path updates. Per the project convention of addressing behavioral issues in dedicated follow-up PRs, this is noted but not blocking.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-02-discovery.md` around lines 140 - 158, The "Present Content and Menu" block currently only shows the "[C] Continue" option while the COLLABORATION MENUS protocol defines A, P, and C; update the "Present Content and Menu" section in step-02-discovery.md so the displayed menu includes the A (Ask a question / Amend), P (Pause / Discuss), and C (Continue) options exactly as listed in the COLLABORATION MENUS section, and ensure the subsequent "Handle Menu Selection" instructions reference and handle A and P branches in addition to the existing C branch (so functions/steps that append to `{planning_artifacts}/ux-design-specification.md`, update `stepsCompleted`, and load `step-03-core-experience.md` remain tied to C while A and P route to their respective behaviors).src/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md (2)
43-43: Renameparty_mode_execto something type-agnostic.The target is now a native skill, but the handle still reads like an executable workflow artifact. That leaves old assumptions in the root workflow and makes future grep-based maintenance noisier than it needs to be.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md` at line 43, Rename the `party_mode_exec` handle to a type-agnostic name (e.g., `party_mode_target` or `party_mode_ref`) in the quick-dev workflow entry where `party_mode_exec = {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md` so it no longer implies an executable; update every usage and reference of `party_mode_exec` in this workflow and any upstream/root workflows or scripts to the new identifier to keep semantics consistent and avoid grep noise, and ensure the referenced path/value remains unchanged except for the identifier rename.
43-43: This root workflow still hardcodes Party Mode's physical location.
quick-devis a high-traffic entrypoint, so pinning it to_bmad/core/workflows/bmad-party-mode/workflow.mdkeeps the storage layout as part of the public contract. Please route this through a single shared alias/lookup so the next rename does not require another repo-wide edit.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md` at line 43, The quick-dev root workflow currently hardcodes party_mode_exec to `{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md`; change this to reference a single shared alias (e.g., `party_mode_exec = "bmad_party_mode"`) and resolve that alias at runtime via the central workflow lookup/registry (create or update a central mapping like `workflows_registry` that maps `bmad_party_mode` -> `_bmad/core/workflows/bmad-party-mode/workflow.md`); update the resolution logic used by the workflow loader to accept alias names and fall back to file paths so future renames only require updating the registry entry rather than edits to quick-dev's `party_mode_exec`.src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-07-project-type.md (1)
14-14: This migration should not add yet another hardcoded Party Mode location.
partyModeWorkflowis a good indirection inside the step, but the value is still the raw install path. If the skill moves again, this step joins the next mass-edit. Please source the value from a single canonical alias instead of repeating the concrete location here.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-07-project-type.md` at line 14, The hardcoded path assigned to the partyModeWorkflow key should be replaced with a canonical alias lookup instead of the concrete install path; update step-07-project-type.md to set partyModeWorkflow to the centralized alias/value (e.g., reference the project's workflow alias registry such as workflowAliases.bmadPartyMode or a single source like aliases.bmad-party-mode) so all usages read from that single canonical symbol rather than repeating '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'.src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-03-core-experience.md (1)
34-35: Don't duplicate the same Party Mode target twice in one step.The PROTOCOL INTEGRATION section and the
If 'P'branch now have to stay synchronized by hand. Define the Party Mode target once near the top of the step and reuse it in both places; otherwise the next rename can drift inside this single file.Also applies to: 170-173
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-03-core-experience.md` around lines 34 - 35, The step duplicates the Party Mode target path in two places (the PROTOCOL INTEGRATION section and the "If 'P'" branch), risking drift when renaming; define the Party Mode target once near the top of step-03-core-experience.md (e.g., a single explicit target line or a named anchor/placeholder) and replace the duplicated string in both the PROTOCOL INTEGRATION block and the "If 'P'" branch with a reference to that single definition so both locations always use the same identifier ({project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md is the canonical target to consolidate).src/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md (2)
8-8: Avoid hardcoding the Party Mode path in another top-level workflow.This repeats the exact install-path literal in a second quick-flow entrypoint. The current migration already touched a large number of files because the reference is not centralized; adding more copies keeps that churn permanent.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md` at line 8, The quick-spec entry currently hardcodes the Party Mode path under the party_mode_exec key ('{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'), which duplicates the install-path; replace that literal with the centralized reference used elsewhere (for example the shared workflow registry/variable that points to the bmad-party-mode workflow) so this file reads party_mode_exec: <centralized-reference> instead of the full path; update quick-spec to use the existing single source-of-truth identifier for the bmad-party-mode workflow (or create one if missing) and remove the hardcoded literal.
8-8:party_mode_execstill reflects the pre-conversion model.Now that Party Mode is represented as a skill, this name bakes obsolete semantics into the workflow contract. A neutral name would make the migration clearer and reduce confusion the next time this area is touched.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md` at line 8, The workflow key party_mode_exec still implies the old "exec" model; rename it to a neutral name (e.g., party_mode_skill) everywhere it appears in the workflow contract and documentation, update any references that consume that key (so consumers looking up party_mode_exec now use party_mode_skill), and ensure the mapping value ('{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md') remains correct or is updated to the skill's canonical path; adjust tests or callers that expect party_mode_exec accordingly.src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-04-emotional-response.md (1)
34-35: This step duplicates the Party Mode reference in two execution paths.Both the protocol summary and the concrete
If 'P'branch now carry the same hardcoded target. Keep a single local reference and reuse it; otherwise one half of the step will eventually drift from the other.Also applies to: 173-176
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-04-emotional-response.md` around lines 34 - 35, The step duplicates the Party Mode workflow target in two places (the protocol summary and the "If 'P'" branch); extract a single local reference (e.g., PARTY_MODE_REF or a Markdown reference link) at the top of this step file and replace both hardcoded occurrences ("When 'P' selected: Read fully and follow: {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md" and the PROTOCOLS line that points to the same path) to reference that single symbol so both paths always use the same source of truth.src/bmm/workflows/1-analysis/create-product-brief/steps/step-03-users.md (1)
11-11: Stop baking the Party Mode install path into step metadata.This is another copy of a storage-path literal that now has to be kept in sync across the repo. The next directory/layout change will force another sweep like this one, and any miss becomes a runtime dead link. Please resolve Party Mode through a shared alias or manifest-driven reference instead of repeating the concrete
_bmad/core/workflows/...path here.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/1-analysis/create-product-brief/steps/step-03-users.md` at line 11, The metadata currently hardcodes the Party Mode path in the partyModeWorkflow field ('{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'), which creates a brittle duplicate; change this to reference the shared alias/manifest entry instead (e.g., replace the literal value with a manifest lookup or alias such as a workflow manifest key like workflows.partyMode or call to getWorkflowPath('partyModeWorkflow')) so the step reads from the central workflow manifest/aliases rather than embedding the concrete '_bmad/core/workflows/...' path; update any loader code that reads step metadata to resolve this alias via the central manifest if necessary (ensure you modify the metadata value in step-03-users.md from the literal path to the agreed manifest key and wire it to the manifest resolver).src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-05-inspiration.md (1)
34-35: The Party Mode path is duplicated inside this step.You now have the same literal in the protocol overview and in the
If 'P'handler. That is needless drift surface for a reference that already changed repo-wide in this PR. Hoist it once and reuse it.Also applies to: 188-191
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-05-inspiration.md` around lines 34 - 35, The same "Party Mode" workflow path literal is duplicated between the protocol overview and the "If 'P'" handler in step-05-inspiration.md (and again in the other occurrence). Replace both hard-coded literals by hoisting a single Markdown reference/link or top-of-file variable (e.g., a named reference like [party-mode-workflow]: <...>) and use that reference in the protocol overview and the If 'P' handler; update the other duplicated block the same way so both places consume the single source of truth.src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-02c-executive-summary.md (1)
11-11: This frontmatter still hardcodes Party Mode's filesystem path.The variable name is fine, but the value is another embedded
_bmad/core/workflows/...literal. Given how many files this rename already touched, this wants a single canonical source rather than one more copy in step frontmatter.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-02c-executive-summary.md` at line 11, Replace the hardcoded path value in the frontmatter of step-02c-executive-summary.md so it doesn't duplicate the filesystem literal; instead have the frontmatter use the canonical partyModeWorkflow variable reference (remove the '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md' literal and point to the single source-of-truth partyModeWorkflow definition used across the repo), ensuring the frontmatter's partyModeWorkflow key references that centralized value rather than embedding the path locally.src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-11-component-strategy.md (1)
34-34: Deduplicate the party-mode path inside this step.Right now the protocol section and the
Pbranch each carry their own copy of the same route. That is exactly the kind of split-brain drift this rename PR is trying to clean up.Also applies to: 204-204
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-11-component-strategy.md` at line 34, This step duplicates the same party-mode route in both the protocol section and the 'P' branch; remove the duplicate by referencing the single canonical path {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md instead of repeating it in the 'P' branch within step-11-component-strategy.md—update the 'P' branch to point to or call the protocol entry (or a single named constant/section) so the route exists only once and both places read from that canonical source.src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md (1)
12-12: RenamepartyModeWorkflowto something skill-neutral.After this PR the target is a skill entry point, not a workflow registration. Keeping the old name bakes the retired abstraction into every later search/refactor.
partyModeEntryFileorpartyModePathwould be clearer.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md` at line 12, Rename the configuration key and any references from partyModeWorkflow to a skill-neutral name such as partyModeEntryFile or partyModePath; update the key in the file where it appears (the string "partyModeWorkflow" in the diff) and then search for and replace all usages (variable names, config lookups, tests, docs, imports) to the new identifier to ensure consistency, keeping the value '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md' unchanged and run tests to confirm no broken references.tools/cli/lib/agent/compiler.js (1)
160-160: Extract the PM launcher into a shared constant/helper.This route is now duplicated as raw text in the compiler and across multiple prompt files. Another rename will trigger another repo-wide sweep unless this is centralized.
Possible refactor
+const PARTY_MODE_ROUTE = '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'; +const PARTY_MODE_CMD = 'PM or fuzzy match on party-mode, party mode, or bmad-party-mode'; + function buildMenuXml(menuItems) { let xml = ' <menu>\n'; @@ - xml += ` <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md">[PM] Start Party Mode</item>\n`; + xml += ` <item cmd="${PARTY_MODE_CMD}" exec="${PARTY_MODE_ROUTE}">[PM] Start Party Mode</item>\n`;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/cli/lib/agent/compiler.js` at line 160, Extract the duplicated PM launcher XML string into a shared exported constant (e.g., PM_ITEM_XML) or a small helper function (e.g., getPmItemXml(projectRootPlaceholder)) and replace the raw inline string in compiler.js (the xml += `... [PM] Start Party Mode ...`) and all prompt files to import and use that constant/helper; ensure the helper accepts or preserves the "{project-root}" placeholder so callers can substitute or leave it intact and update imports/usages accordingly across the repo.src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-02b-vision.md (1)
11-11: Rename the local handle to match the new abstraction.
partyModeWorkflowis now semantically stale: this PR converts the target into a skill entry, not a workflow registration. A neutral name likepartyModeEntryFileorpartyModePathwill save the next maintainer from grepping the wrong manifest pipeline.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-02b-vision.md` at line 11, The local handle partyModeWorkflow is semantically incorrect now that the target is a skill entry; rename it to a neutral identifier such as partyModeEntryFile or partyModePath across the diff (update the key from partyModeWorkflow to partyModeEntryFile/partyModePath and adjust any references in the same document or related manifest blocks), ensuring the value '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md' is preserved and any code that reads the key uses the new name.src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-04-journeys.md (1)
11-11: Rename the frontmatter key to match the converted asset type.This file now points at a skill entry file, but
partyModeWorkflowstill encodes the old workflow-era mental model. Using a neutral name here will make future manifest work much less error-prone.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-04-journeys.md` at line 11, Rename the frontmatter key "partyModeWorkflow" to a neutral name that reflects the converted asset type (e.g., "skill" or "skillEntry") so it no longer implies a workflow-era mental model; update the frontmatter key where it appears (the entry referencing '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md') to the chosen neutral key and ensure any code or manifests that read "partyModeWorkflow" are updated to use the new key name ("skill" or "skillEntry") to keep naming consistent with the asset type.src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-10-user-journeys.md (1)
34-34: Stop repeating the party-mode route inline.The same literal path is embedded in both the protocol overview and the
Phandler. One missed edit on the next rename will desync what the step advertises from what it actually executes. Hoist this into a single local reference/frontmatter entry, like the other converted step files do.Also applies to: 198-198
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-10-user-journeys.md` at line 34, The step repeats the literal path "{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md" inline which risks desync; add a single frontmatter variable (e.g., party_mode_path) at the top of this markdown and reference that variable both in the protocol overview and in the 'P' handler text instead of hardcoding the path so renames only need one edit; update the 'P' handler text to use that frontmatter reference consistently (matching the pattern used in the other converted step files).src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-05-domain.md (1)
12-12: Use a neutral entry-path name here too.
partyModeWorkflowstill reads like a workflow-manifest reference, but this PR moves the target into the skill pipeline. Renaming the local key now will make the rest of the conversion less misleading.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-05-domain.md` at line 12, Rename the local manifest key partyModeWorkflow to a neutral entry name (for example entryWorkflow or entryPath) in step-05-domain.md and update any references to that key in the same document or related conversion steps so it no longer implies a workflow manifest; ensure you change the identifier partyModeWorkflow wherever referenced (e.g., in mapping or pipeline conversion notes) to the chosen neutral name so the new skill pipeline target is not misleading.src/bmm/workflows/1-analysis/create-product-brief/steps/step-04-metrics.md (1)
166-166: The menu option description is vague and doesn't explain when to use Party Mode.Line 166 says "bring different perspectives to validate comprehensive metrics" but doesn't explain what "Party Mode" actually is, who the "different perspectives" are, or when a user should choose this option over Advanced Elicitation. A user encountering this menu for the first time has no context for making an informed choice.
📝 Consider adding a brief inline explanation
-- IF P: Read fully and follow: {partyModeWorkflow} to bring different perspectives to validate comprehensive metrics +- IF P: Read fully and follow: {partyModeWorkflow} (Party Mode brings multiple BMAD agents with diverse expertise to collaboratively validate your metrics from different angles)Or add a help hint to the menu presentation at line 161:
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue" + +(Hint: Party Mode = multi-agent collaborative review, Advanced Elicitation = deeper discovery questions)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/1-analysis/create-product-brief/steps/step-04-metrics.md` at line 166, Update the menu option text for "Party Mode" in step-04-metrics to explain what Party Mode is, who the "different perspectives" are (e.g., cross-functional stakeholders, domain experts, customers), and when to choose it versus "Advanced Elicitation"; change the line beginning with "IF P:" (the Party Mode menu entry) to a concise sentence that states the purpose, participants, and ideal use-case, and add a short help hint adjacent to the menu presentation that contrasts Party Mode with Advanced Elicitation (e.g., collaborative validation session vs. deep individual analysis).src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md (6)
252-271: Success metrics missing validation for critical dependency rule.Line 52 marks "Stories MUST NOT depend on future stories" as CRITICAL and provides extensive examples (lines 90-96, 134-135), yet the Success/Failure Metrics section (lines 252-271) omits any validation criterion for this rule. There's no step in the workflow that checks or enforces the no-forward-dependency constraint.
Add an explicit success criterion: "✅ Stories have no forward dependencies within epic (each story completable based only on previous stories)" to make this critical requirement verifiable.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` around lines 252 - 271, The SYSTEM SUCCESS/FAILURE METRICS section (heading "🚨 SYSTEM SUCCESS/FAILURE METRICS") is missing a validation for the critical rule "Stories MUST NOT depend on future stories"; add an explicit success criterion line under ✅ SUCCESS such as "✅ Stories have no forward dependencies within epic (each story completable based only on previous stories)" so the no-forward-dependency constraint is verifiable and enforced alongside the other success checks.
248-248: Inconsistent variable reference formatting.Line 248 wraps
{nextStepFile}in backticks, but line 236 and other variable references throughout the file (e.g.,{outputFile},{partyModeWorkflow}) do not use backticks. This formatting inconsistency serves no semantic purpose and creates visual noise.Remove the backticks for consistency:
read fully and follow: {nextStepFile}.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` at line 248, The line uses inconsistent backtick formatting around the variable {nextStepFile}; remove the backticks so the text reads "read fully and follow: {nextStepFile}" to match other variable references like {outputFile} and {partyModeWorkflow}; update the occurrence in the sentence starting "ONLY WHEN [C continue option]..." to drop the backticks and keep variable formatting consistent across the file.
241-244: Menu return behavior doesn't clarify state preservation.Line 243 states "After other menu items execution, return to this menu," but doesn't specify whether changes made during the branched workflow (e.g., Party Mode) are preserved or discarded when returning. If Party Mode modifies
{outputFile}or other artifacts, are those changes integrated into the main flow or treated as a side excursion?Clarify: "After other menu items execution (changes to {outputFile} are preserved), return to this menu."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` around lines 241 - 244, Update the menu-return behavior paragraph to explicitly state that state changes made during branched workflows are preserved: when returning from any menu item (e.g., Party Mode) modifications to {outputFile} and other artifacts must be integrated into the main flow rather than discarded; keep the existing requirements that the menu always halts for user input, only proceeds on 'C', and that after executing other items you redisplay the menu, but append the parenthetical clarification "(changes to {outputFile} and other workflow artifacts are preserved and applied to the main flow)" to the line "After other menu items execution, return to this menu."
84-88: Database creation principle assumes database-backed architecture.The "DATABASE/ENTITY CREATION PRINCIPLE" (lines 84-88) provides valuable guidance for incremental data model evolution but assumes the project uses a database. For non-database projects (e.g., static sites, libraries, CLIs), this section is irrelevant and could confuse users.
Consider generalizing to "RESOURCE CREATION PRINCIPLE" and include database tables as one example alongside other resources (API endpoints, config files, components), or make it conditional: "For database-backed projects, create tables/entities ONLY when needed..."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` around lines 84 - 88, The "DATABASE/ENTITY CREATION PRINCIPLE" heading and guidance assume a database-backed project; update the heading and copy to be generic by renaming the principle to "RESOURCE CREATION PRINCIPLE" (or add a conditional note), and replace the database-only examples with a short list of resource types (e.g., database tables/entities, API endpoints, config files, UI components) or add a parenthetical phrase such as "For database-backed projects..." so the advice applies to non-database projects as well while preserving the original intent.
14-17: Inconsistent terminology: "Task References" section with mixed naming.The section header declares "Task References," yet
partyModeWorkflowuses the "Workflow" suffix whileadvancedElicitationTaskuses "Task." If bmad-party-mode is now type:skill per the PR objectives, the variable name should reflect its actual type consistently—either both use "Task," both use "Workflow," or adopt a "Skill" suffix for the converted item.This terminology drift creates confusion about whether these are tasks, workflows, or skills, hindering code maintainability.
♻️ Standardize naming convention
# Task References advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md' -partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md' +partyModeTask: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'Then update references at line 235:
-- IF P: Read fully and follow: {partyModeWorkflow} +- IF P: Read fully and follow: {partyModeTask}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` around lines 14 - 17, Rename the inconsistent identifier and update the section heading: change the header from "Task References" to "Task and Skill References" (or "Task/Skill References"), rename partyModeWorkflow to partyModeSkill to reflect that bmad-party-mode is now type:skill, and update every usage of partyModeWorkflow (including the reference near the create-stories step) to partyModeSkill; keep advancedElicitationTask as-is since it remains a Task.
187-187: Ambiguous story numbering notation.The instruction "Use correct numbering (Epic N, Story M)" at line 187 could be misinterpreted. The template at line 100 and examples at lines 119-122 use the format "Story 1.1" (i.e., "Story N.M"), not separate "Epic N" and "Story M" labels. The phrase "Story M" here could suggest omitting the epic number prefix, which contradicts the template.
Clarify: "Use correct numbering (Story N.M where N=epic, M=story number within epic)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md` at line 187, The phrase "Use correct numbering (Epic N, Story M)" is ambiguous and conflicts with the template/examples using "Story 1.1"; update the instruction text to explicitly state the required format by replacing that phrase with: "Use correct numbering (Story N.M where N = epic number, M = story number within that epic)" so all references (e.g., the template "Story 1.1" and examples) unambiguously match this Story N.M convention.
| nextStepFile: './step-v-02-format-detection.md' | ||
| advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md' | ||
| partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md' | ||
| partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md' |
There was a problem hiding this comment.
AI summary contradicts the actual change.
The AI summary states this file "Added a new frontmatter declaration partyModeWorkflow...as an additional (alternate) path alongside the existing partyModeWorkflow entry," suggesting duplicate YAML keys. However, the annotated code shows only one partyModeWorkflow declaration at line 8.
YAML does not permit duplicate keys (the second would silently overwrite the first). Either:
- The summary is incorrect and this is a simple replacement (most likely)
- The original file had two entries and one was removed (which would be correct)
- There's a YAML parsing issue not caught by validation
This discrepancy indicates either inaccurate change documentation or a potential validation gap.
Clarify: is this a replacement or an addition? The PR description should accurately describe the change to avoid confusion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md`
at line 8, The PR summary is inconsistent about whether the frontmatter key
partyModeWorkflow was added or replaced; verify the git diff/commit to confirm
whether you replaced an existing partyModeWorkflow value or intended to add a
second key, then update the PR description to explicitly state "replaced
partyModeWorkflow value with '<new value>'" or "added partyModeWorkflow as an
additional alternate entry" as appropriate; finally run a YAML linter/validator
against the markdown frontmatter (the file containing the partyModeWorkflow key)
to ensure there are no duplicate YAML keys and correct the file if duplicates
are present.
|
|
||
| - When 'A' selected: Read fully and follow: {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md | ||
| - When 'P' selected: Read fully and follow: {project-root}/_bmad/core/workflows/party-mode/workflow.md | ||
| - When 'P' selected: Read fully and follow: {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Duplicate workflow path creates maintenance burden.
The path {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md appears twice in this file (lines 34 and 210). If the workflow path changes again in the future, both locations must be updated. This violates DRY principle.
The frontmatter already declares partyModeWorkflow as a variable, but it's not shown in this file's frontmatter. Either the frontmatter declaration is missing from this file, or the inline references should use the variable consistently.
Verify this file's frontmatter includes the partyModeWorkflow declaration. If it's missing, add it. If it's present, ensure both line 34 and 210 use {partyModeWorkflow} instead of the hardcoded path.
Also applies to: 210-210
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-07-defining-experience.md`
at line 34, The file step-07-defining-experience.md contains a hardcoded
workflow path used in multiple places; ensure the frontmatter declares the
partyModeWorkflow variable and replace all literal occurrences of
`{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md` with the
frontmatter variable reference `{partyModeWorkflow}` so the file consistently
uses partyModeWorkflow (add the frontmatter entry if missing and update every
inline reference to use `{partyModeWorkflow}`).
|
|
||
| - When 'A' selected: Read fully and follow: {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md | ||
| - When 'P' selected: Read fully and follow: {project-root}/_bmad/core/workflows/party-mode/workflow.md | ||
| - When 'P' selected: Read fully and follow: {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md |
There was a problem hiding this comment.
Hardcoded path duplicated across 43+ files creates maintainability burden.
This file is one of 43+ cross-references updated in this PR (per PR description). All references hardcode the full path {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md.
If the bmad-party-mode skill moves, is renamed, or requires a different invocation pattern in the future, all 43+ files must be updated again. This creates:
- High risk of inconsistency (missed updates, typos)
- Brittle coupling between workflow steps and skill location
- No single source of truth for the party-mode workflow path
Consider whether a centralized configuration or path alias mechanism could reduce this duplication. For example, a well-known skill ID resolved at runtime rather than a hardcoded file path.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-09-design-directions.md`
at line 34, This step file hardcodes the party-mode workflow path; replace the
literal "{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md" with a
reference that resolves at runtime from the centralized registry/alias (e.g.,
use a well-known skill ID like "bmad-party-mode" looked up via the existing
skills map or config constant SKILL_BMAD_PARTY_MODE), update the text in
step-09-design-directions.md to reference that alias/token instead of the file
path, and ensure the consumer code that renders or resolves these step
references uses the resolver (e.g.,
skillsRegistry.getPath(SKILL_BMAD_PARTY_MODE) or similar) so future
moves/renames only require updating the single registry constant.
No validation that bmad-party-mode workflow exists before delegation.
Lines 34 and 180 both delegate to {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md without verifying the file exists or is loadable. If the skill directory is incomplete or the path is wrong, the agent will fail at runtime when the user selects 'P', likely with an unhelpful error.
Additionally, the path is hardcoded in two locations within this file. Consider whether this duplication is necessary or if the frontmatter variable partyModeWorkflow could be referenced inline in the menu handling section.
Also applies to: 180-180
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-09-design-directions.md`
at line 34, The menu handling currently delegates to the hardcoded path
"{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md" when 'P' is
selected (two occurrences) without checking the file; update the logic to (1)
reference the frontmatter variable partyModeWorkflow instead of the hardcoded
string in both places and (2) perform a pre-delegation existence/loadability
check (e.g., use your environment's file/load check where delegation happens)
and handle failure gracefully by showing a clear error to the user or falling
back, rather than allowing an unhandled runtime error.
| - When 'A' selected: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md | ||
| - When 'P' selected: Execute {project-root}/_bmad/core/workflows/party-mode | ||
| - When 'P' selected: Execute {project-root}/_bmad/core/workflows/bmad-party-mode | ||
| - PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n '\{project-root\}/_bmad/core/workflows/bmad-party-mode(?:/workflow\.md)?' \
src/bmm/workflows tools testRepository: bmad-code-org/BMAD-METHOD
Length of output: 11622
Fix the bare directory reference on line 33 to include /workflow.md.
Line 33 uses {project-root}/_bmad/core/workflows/bmad-party-mode without a trailing /workflow.md, while every other reference to Party Mode across 50+ workflow files uses the canonical form {project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md. This is the only bare reference in the entire codebase. Normalize this to match the canonical entry point and prevent execution ambiguity.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/bmm/workflows/generate-project-context/steps/step-02-generate.md` around
lines 32 - 34, Replace the bare Party Mode directory reference
`{project-root}/_bmad/core/workflows/bmad-party-mode` with the canonical entry
`{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md` so this step
uses the same workflow file as all other Party Mode references; update the
string in the step-02-generate.md A/P menu to include the trailing
`/workflow.md` to normalize execution and remove ambiguity.
| } | ||
|
|
||
| xml += ` <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/party-mode/workflow.md">[PM] Start Party Mode</item>\n`; | ||
| xml += ` <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md">[PM] Start Party Mode</item>\n`; |
There was a problem hiding this comment.
Update the PM trigger vocabulary to include the renamed skill.
The launcher now executes bmad-party-mode, but the fuzzy-match text still only mentions party-mode. If menu matching/search keys off this field, the new canonical token is invisible here.
Possible fix
- xml += ` <item cmd="PM or fuzzy match on party-mode" exec="{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md">[PM] Start Party Mode</item>\n`;
+ xml += ` <item cmd="PM or fuzzy match on party-mode, party mode, or bmad-party-mode" exec="{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md">[PM] Start Party Mode</item>\n`;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tools/cli/lib/agent/compiler.js` at line 160, The menu item's fuzzy-match
label still references "party-mode" while the launcher runs the renamed skill
"bmad-party-mode"; update the item text inside the xml string (the <item ...>
text for the PM trigger) to include the new canonical token — e.g., change the
label to mention "bmad-party-mode" (or include both "bmad-party-mode" and
"party-mode") so fuzzy matching and search can find the renamed skill for the
entry with cmd="PM or fuzzy match on party-mode" and exec path
"_bmad/core/workflows/bmad-party-mode/workflow.md".
|
thanks! |
…code-org#1906) - Rename party-mode → bmad-party-mode (canonical ID convention) - Change bmad-skill-manifest.yaml from type:workflow to type:skill - Add SKILL.md with frontmatter for installer discovery - Remove installed_path, use relative ./steps/ refs internally - Update module-help.csv to skill:bmad-party-mode - Update compiler.js hardcoded PM menu path - Update 43 cross-references to IDE-agnostic _bmad/ path - Update test fixtures for renamed directory Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2 participants
Summary
type:workflow(launcher redirect) totype:skill(verbatim copy) so the full multi-file skill (workflow.md + 3 step files) is self-contained in.claude/skills/bmad-party-mode/party-mode→bmad-party-modeto match canonical ID convention_bmad/path (not.claude/skills/which is Claude-Code-specific)compiler.jsagent PM menu itemTest plan
npm testpasses (215 tests, all linting, all formatting).claude/skills/bmad-party-mode/with SKILL.md, workflow.md, bmad-skill-manifest.yaml, steps/skill-manifest.csvhas entry,workflow-manifest.csvdoes notworkflows/party-modepath.claude/skills/cross-references in source (IDE-agnostic)/tmp/, simulated-human walkthrough of all 3 steps — config loads, agent manifest parses, relative step paths resolve, farewells complete🤖 Generated with Claude Code