Merged
Conversation
Captures decisions, phased execution plan, and verification checkpoints for syncing bmad-module-game-dev-studio against BMAD-METHOD@main (6b964acd). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…new-preview
Replaces divergent gds-quick-dev (mode-detection/context-gathering/execute
style) with a 1:1 port of upstream bmad-quick-dev — the hardened
clarify/plan/implement/review/present flow plus step-oneshot variant.
Removes gds-quick-spec (absorbed into step-02-plan of the new quick-dev)
and gds-quick-dev-new-preview (superseded by the ported implementation).
Adaptations to upstream:
- main_config uses game-dev {module_config} variable (vs upstream's
hardcoded _bmad/bmm path)
- step-02 editor note references gds-code-review (game-dev's local skill)
instead of bmad-code-review
- bmad-advanced-elicitation, bmad-party-mode, bmad-review-adversarial-general,
and bmad-review-edge-case-hunter remain unchanged (core skills installed
alongside via bmad core)
Also updates gds-agent-game-solo-dev capability table and module-help.csv
to drop TS/QQ entries and point QD at the new unified workflow.
Part of SYNC-PLAN.md Phase 1.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Splits the consolidated create-prd/ directory (containing workflow-create-prd.md, workflow-edit-prd.md, workflow-validate-prd.md with shared data/, steps-c/, steps-e/, steps-v/) into three independent skill directories mirroring upstream bmad-create-prd, bmad-edit-prd, and bmad-validate-prd: src/workflows/2-design/gds-create-prd/ src/workflows/2-design/gds-edit-prd/ src/workflows/2-design/gds-validate-prd/ Each new directory has its own SKILL.md (with gds-* name), a minimal bmad-skill-manifest.yaml (type: skill), and a renamed workflow.md. Cross-skill references updated to use skill-invocation syntax: - steps-c/step-12-complete.md validationWorkflow -> skill:gds-validate-prd - steps-e/step-e-04-complete.md validationWorkflow -> skill:gds-validate-prd data/ distributed per upstream pattern (create + validate need all three reference files; edit only needs prd-purpose.md). templates/ goes to create-prd only. Part of SYNC-PLAN.md Phase 2a. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mirrors the PRD split from the prior commit: GDD now lives in three parallel skill directories. - gds-create-gdd/ (existing): rename steps/ to steps-c/ for consistency with gds-create-prd; update workflow.md nextStep reference; fix name frontmatter from "create-gdd" to "gds-create-gdd" - gds-edit-gdd/ (new): structural placeholder that delegates to gds-edit-prd until GDD-specific edit flow is authored - gds-validate-gdd/ (new): structural placeholder that delegates to gds-validate-prd until GDD-specific 13-check validation flow is authored The delegation approach keeps game-dev's "GDD as PRD by default" pattern working end-to-end while the split is in place. A TODO.md entry tracks the GDD-specific step body work required to complete Phase 2b. module-help.csv registers gds-validate-gdd (code VG) and gds-edit-gdd (code EG) under the 2-design phase. Part of SYNC-PLAN.md Phase 2b. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Ports substantive content changes from upstream BMAD-METHOD@6b964acd
into the PRD skill family, while preserving game-dev frontmatter and
variable-indirection conventions.
step-08-scoping (gds-create-prd/steps-c/):
- Reframe from MVP/Growth/Vision phasing-by-default to user-chosen
delivery mode (phased OR single-release)
- Add SCOPE CHANGE CONFIRMATION GATE — block silent de-scoping of
user-specified requirements
- Add explicit rules against inventing phasing when user didn't request it
- Add dual content templates (phased vs single-release) to the output
- Expand FAILURE MODES with the four CRITICAL scope-confirmation gates
- Add releaseMode frontmatter tag (phased | single-release)
step-11-polish (gds-create-prd/steps-c/):
- Update scope-decisions capture to reflect phased-or-single-release
framing with consent-critical evidence (confirmations + rationales)
step-e-01, step-e-02, step-e-03 (gds-edit-prd/steps-e/):
- Add `document_output_language` rule: artifacts written in configured
document output language (vs agent communication language, which is
separate)
Not ported: upstream's convention drift from variable-indirected
file refs ({nextStepFile}) to direct paths (./file.md), and from
{advancedElicitationTask} vars to "Invoke the ... skill" prose.
Game-dev uses variable indirection throughout — staying consistent
within game-dev outweighs matching upstream style.
Part of SYNC-PLAN.md Phase 2c.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…locate gametest
Mirrors upstream BMAD-METHOD's consolidation of QA and SM agents into
the single Developer agent (commits 48c2324b, 003c979d). Game-dev Phase 4
now runs through one agent — Link Freeman — instead of three.
Agent consolidation:
- Delete src/agents/gds-agent-game-qa/ (GLaDOS)
- Delete src/agents/gds-agent-game-scrum-master/ (Max)
- gds-agent-game-dev/SKILL.md expanded to own all three roles:
- Kept: DS, CR, QD, QP (core dev)
- Absorbed from QA: TF, TD, TA, ES, PP, PT, TR (seven gds-test-* skills)
- Absorbed from SM: SP, SS, CS, ER, CC (sprint + story ceremony)
- Kept: AE (advanced elicitation)
- Persona stays Link Freeman; Principles + Critical Actions merged from
all three source agents. Overview explicitly flags the consolidation.
gametest relocation:
- Move src/gametest/ (17 knowledge fragments + qa-index.csv) into
src/agents/gds-agent-game-dev/gametest/
- Reason: _bmad-output/ is being deprecated as a runtime location; the
QA knowledge the dev agent uses should live with the dev agent.
- Path refs updated: {module_root}/gametest/* -> {skill_root}/gametest/*
- src/workflows/gametest/gds-test-design/test-design-template.md
references qa-index.csv — annotated to clarify it's loaded via the
dev agent from the new location.
Earlier phase 1 commit already cleaned up gds-agent-game-solo-dev's
capability table and module-help.csv — no stale refs remain.
Part of SYNC-PLAN.md Phase 2.5.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Ports seven production-phase skills from upstream BMAD-METHOD@6b964acd
to fulfill the "mirror BMAD for Phase 4" directive:
- gds-code-review (adopts upstream's step-file architecture: steps/step-01..04)
- gds-correct-course (upstream workflow + checklist updates)
- gds-create-story (upstream workflow + checklist updates)
- gds-dev-story (upstream workflow updates)
- gds-retrospective (full rewrite from upstream — substantial)
- gds-sprint-planning (upstream workflow updates)
- gds-sprint-status (upstream workflow updates)
Adaptations applied uniformly:
- {project-root}/_bmad/bmm/config.yaml -> {module_config}
- bmad-agent-dev -> gds-agent-game-dev (all story execution refs)
- Phase 4 skill names bmad-* -> gds-* (code-review, sprint-*, etc.)
- Game-dev-specific files (backlog-template.md, sprint-status-template.yaml)
and language/skill-level tailoring preserved where upstream lacks them.
Part of SYNC-PLAN.md Phase 3.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Captures the four major changes landed in this sync under a single "Unreleased" section pending a release cut: - Phase 4 agent consolidation (QA + SM -> dev agent; gametest relocation) - Quick-dev overhaul (delete old + quick-spec; port upstream bmad-quick-dev) - PRD + GDD 3-skill split (consolidated create-prd/ -> gds-create-prd, gds-edit-prd, gds-validate-prd; GDD gains edit + validate placeholders that delegate to PRD counterparts pending GDD-specific step bodies) - Phase 4 workflow mirror (all seven production-phase skills ported from upstream; gds-code-review adopts step-file architecture) Completes SYNC-PLAN.md Phase 4. No functional code changes in this commit beyond CHANGELOG — manifests were verified clean, no stale refs to removed agents or skills remain, and `npm test` passes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- package.json version: 0.2.4 -> 0.3.0 (minor bump reflecting removed
agents, new skills, and Phase 4 workflow rearchitecture)
- marketplace.json plugin version: 0.2.4 -> 0.3.0
- marketplace.json skills list synced:
- Removed: gds-agent-game-qa, gds-agent-game-scrum-master,
gds-quick-dev-new-preview, gds-quick-spec
- Added: gds-create-prd, gds-edit-prd, gds-validate-prd,
gds-edit-gdd, gds-validate-gdd
- CHANGELOG "Unreleased" section promoted to "v0.3.0 - Apr 14, 2026"
Completes the upstream BMAD-METHOD v6.3.0 sync.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
User edits softening framing — "Quick-dev update" instead of "overhaul", collapse the delete/replace narrative into a single update bullet, note that PRD creation in GDS is optional (external tool compatibility), and drop the step-08-scoping porting detail that's already covered by the mirror bullet. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
This pull request is abnormally large and would use a significant amount of tokens to review. If you still wish to review it, comment |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 11 minutes and 54 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (36)
WalkthroughThis PR synchronizes Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Poem
🚥 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 |
Collaborator
Author
augment review |
🤖 Augment PR SummarySummary: This PR syncs the game-dev-studio module with BMAD-METHOD v6.3.0, bringing major structural and content changes across agents, workflows, and skill definitions. Changes:
Technical Notes: Version bumped to 0.3.0. The retrospective workflow changed its input from GDD/narrative to PRD, which may be incorrect for this GDD-centric module. 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| | DS | Execute Dev Story workflow, implementing tasks and tests | gds-dev-story | | ||
| | CR | Perform a thorough clean-context QA code review on a story flagged Ready for Review | gds-code-review | | ||
| | QD | Clarify, plan, implement, review, and present any intent end-to-end | gds-quick-dev | | ||
| | QP | Rapid game prototyping — test mechanics and ideas quickly | bmad-gds-quick-prototype | |
There was a problem hiding this comment.
The skill name bmad-gds-quick-prototype does not match the actual registered skill name. The solo-dev agent and game designer agent both reference it as gds-quick-prototype, and module-help.csv also uses bmad-gds-quick-prototype. One of these is wrong — consider verifying against the actual bmad-skill-manifest.yaml for the quick-prototype skill to ensure consistency.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| - `party_mode_exec` = `skill:bmad-party-mode` | ||
| - `advanced_elicitation` = `skill:bmad-advanced-elicitation` | ||
| - `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name` | ||
| - `communication_language`, `document_output_language`, `user_skill_level` |
There was a problem hiding this comment.
The config variable user_skill_level does not exist in src/module.yaml — the actual variable name is game_dev_experience. All other workflows in this PR (code-review, retrospective, create-story, dev-story, etc.) correctly use game_dev_experience. This will result in an unresolved variable at runtime.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| | architecture | System architecture for context | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | FULL_LOAD | | ||
| | gdd | Game Design Document for context | whole: `{planning_artifacts}/*gdd*.md`, sharded: `{planning_artifacts}/*gdd*/*.md` | FULL_LOAD | | ||
| | narrative | Narrative design for context (optional) | whole: `{planning_artifacts}/*narrative*.md`, sharded: `{planning_artifacts}/*narrative*/*.md` | FULL_LOAD | | ||
| | prd | Product requirements for context | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | FULL_LOAD | |
There was a problem hiding this comment.
The input file was changed from gdd (Game Design Document) + narrative to prd (Product Requirements Document). However, in the GDS module the GDD is the primary design document — PRD is explicitly optional (the gds-create-prd description says "Optional"). This looks like an upstream PRD-centric reference that wasn't adapted to GDS's GDD-centric workflow. The retrospective will now fail to load the GDD for context, which is the document most GDS projects will actually have.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| @@ -0,0 +1,197 @@ | |||
| # BMAD PRD Purpose | |||
|
|
|||
| **The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.** | |||
There was a problem hiding this comment.
Typo: "in rhw BMad Method" should be "in the BMad Method". This is user-facing reference content loaded during PRD editing workflows.
Severity: low
Other Locations
src/workflows/2-design/gds-validate-prd/data/prd-purpose.md:3
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Nitpick comments (9)
src/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.md (2)
19-23: Token limit enforcement creates a hard checkpoint for scope control.The 1600-token threshold with mandatory user decision (
[S] Splitor[K] Keep) is a thoughtful safeguard against context rot. The split behavior correctly:
- Proposes the split and names secondary goals
- Appends deferred goals to
{deferred_work_file}- Regenerates the spec for narrowed scope (not surgical carving)
However, the instruction "do not surgically carve sections out; regenerate the spec for the narrowed scope" on line 22 is crucial but could be missed. Consider making it more prominent or adding a verification step after regeneration to ensure the spec truly covers only the main goal.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.md` around lines 19 - 23, Emphasize and enforce the "do not surgically carve sections out; regenerate the spec for the narrowed scope" rule by adding a verification checkpoint after regeneration: when handling the Token count branch in step-02-plan (the 1600-token check and the `[S] Split` flow), require the agent that regenerates the spec for the main goal (the regenerated spec routine) to run a concise scope-validation step that compares the regenerated spec against the original to confirm only the main goal is retained (list named secondary goals appended to `{deferred_work_file}`) and flag any remaining secondary content for re-regeneration before continuing to checkpoint; make this verification explicit in the `[S] Split` instructions and ensure the phrase about not surgically carving is highlighted as a required invariant for the regeneration routine.
1-3: Missingspec_filevariable definition in frontmatter.The frontmatter only defines
deferred_work_file, but the workflow heavily uses{spec_file}throughout (lines 14, 16, 27, 39-41, etc.). According to the context snippets,spec_fileis initialized bystep-01-clarify-and-route.mdbefore routing to this step, but it's not declared here.While the variable may be inherited from the calling context, explicitly declaring it in this step's frontmatter improves clarity and prevents issues if the step is invoked incorrectly:
📋 Proposed fix to add spec_file to frontmatter
--- deferred_work_file: '{implementation_artifacts}/deferred-work.md' +spec_file: '' # set by step-01 before routing here ---🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.md` around lines 1 - 3, Add an explicit spec_file frontmatter variable to this step so templates referencing {spec_file} resolve correctly; update the frontmatter in step-02-plan.md to include a spec_file key (the same variable that step-01-clarify-and-route.md initializes) and ensure its placeholder name matches usages throughout the file (e.g., references on lines that use {spec_file}) so the step can be executed standalone without relying on implicit inheritance.src/workflows/4-production/gds-sprint-planning/SKILL.md (1)
3-3: Consider broadening the skill description to include planning output, not only tracking.Line 3 currently reads as status-tracking-first, which may underrepresent the planning function of this workflow.
Proposed wording tweak
-description: 'Generate sprint status tracking from epics. Use when the user says "run sprint planning" or "generate sprint plan"' +description: 'Generate a sprint plan and sprint status tracking from epics. Use when the user says "run sprint planning" or "generate sprint plan"'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/4-production/gds-sprint-planning/SKILL.md` at line 3, The SKILL.md description is too narrowly focused on status tracking; update the description in SKILL.md (the description field) to mention both sprint planning output and status tracking so the workflow reflects planning purpose as well as tracking (e.g., change wording to reference generating sprint plans, backlog prioritization, and status tracking from epics). Ensure the description remains concise and includes trigger phrases like "run sprint planning" or "generate sprint plan" if present.src/workflows/2-design/gds-edit-prd/steps-e/step-e-04-complete.md (1)
7-7: Use the declaredvalidationWorkflowvariable at invocation time to avoid config drift.Line 7 defines a reusable workflow reference, but Line 123 bypasses it with a hardcoded skill name.
Proposed fix
- - Invoke the `gds-validate-prd` skill — it will run its complete 13-step validation process on the updated PRD + - Invoke `{validationWorkflow}` — it will run its complete 13-step validation process on the updated PRDAlso applies to: 123-123
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/2-design/gds-edit-prd/steps-e/step-e-04-complete.md` at line 7, The workflow declares validationWorkflow: 'skill:gds-validate-prd' but the invocation still uses the hardcoded skill name; update the invocation that currently calls 'skill:gds-validate-prd' (the call around the step that references the validator at Line 123) to reference the validationWorkflow variable instead (e.g., use the validationWorkflow identifier where the skill name is passed) so the reusable variable is actually used and prevents config drift.src/workflows/2-design/gds-validate-prd/data/prd-purpose.md (1)
1-197: Consider consolidating duplicate prd-purpose.md filesThis file is identical to
src/workflows/2-design/gds-edit-prd/data/prd-purpose.md. While the duplication may be intentional to keep each skill self-contained, it creates a maintenance burden where any future updates must be synchronized across both locations.Consider one of these approaches:
- Use a symbolic link if the build/deployment system supports it
- Add a comment noting the duplication and referencing the canonical source
- Document in the README that these files must be kept in sync
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/2-design/gds-validate-prd/data/prd-purpose.md` around lines 1 - 197, The file prd-purpose.md is duplicated (identical to the one under gds-edit-prd); remove the maintenance burden by choosing one canonical source and making the other reference it: either replace the duplicate with a symbolic link to the canonical prd-purpose.md, or leave the duplicate but add a top-of-file comment in each prd-purpose.md pointing to the canonical file and update the repo README to document that these two files must be kept in sync; update CI/docs to validate duplication policy if available.src/workflows/4-production/gds-code-review/steps/step-04-present.md (1)
94-106: Consider reusing the shared sprint sync sub-step to avoid behavior drift.This section re-implements sprint-status updates inline, while
src/workflows/gds-quick-flow/gds-quick-dev/sync-sprint-status.mdalready defines idempotency and non-regression rules. Duplicated logic will likely diverge over time.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/4-production/gds-code-review/steps/step-04-present.md` around lines 94 - 106, Replace the inline "Sync sprint-status" subsection in step-04-present.md with a call to the existing shared sub-step defined in sync-sprint-status.md to avoid duplicated logic; remove the ad-hoc load/update/save steps and instead invoke the shared sync procedure so idempotency and non-regression rules (as implemented in the shared sub-step) are preserved; ensure the subsection still documents skip behavior when {story_key} is absent and retains the same user-facing messages for "file missing" and "story not found" cases by forwarding parameters (story_key, sprint_status path, new_status) to the shared sub-step.src/workflows/gds-quick-flow/gds-quick-dev/step-oneshot.md (2)
53-53: Clarify path variable derivation and fix punctuation.Line 53 has two clarity issues:
- The em-dash (—) in the git comment may render inconsistently across terminals and editors. Use a standard double-hyphen (
--) or parenthetical instead.- The variables
{absolute-root}and{absolute-spec-file}appear without explicit definition. While the intent is clear from context (derive from git command output and{spec_file}), explicitly stating the derivation would prevent confusion.📝 Proposed clarification
-1. Open the spec in the user's editor so they can click through the Suggested Review Order: - - 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. +1. Open the spec in the user's editor so they can click through the Suggested Review Order: + - Resolve two absolute paths: (1) Set `{absolute-root}` = repository root via `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) Set `{absolute-spec-file}` = the absolute path to `{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.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/gds-quick-flow/gds-quick-dev/step-oneshot.md` at line 53, Replace the em-dash in the git comment with a standard double-hyphen or parentheses and explicitly define how the two path variables are derived: set {absolute-root} to the output of git rev-parse --show-toplevel (fall back to the current working directory if that command fails) and set {absolute-spec-file} to the absolute path of {spec_file} (resolved relative to the current working directory or the repo root as appropriate); then instruct to run code -r "{absolute-root}" "{absolute-spec-file}" with both paths double-quoted to handle spaces/special characters.
22-22: Break down the complex subagent invocation instruction.The sentence spanning line 22 is long and contains multiple instructions: subagent invocation parameters, context isolation rationale, model capability matching, and fallback behavior. This could lead to implementation errors or misinterpretation.
✂️ Proposed refactor for improved clarity
-Invoke the `bmad-review-adversarial-general` skill in a subagent with the changed files. The subagent gets NO conversation context — to avoid anchoring bias. Launch at the same model capability as the current session. If no sub-agents are available, write the changed files to a review prompt file in `{implementation_artifacts}` and HALT. Ask the human to run the review in a separate session and paste back the findings. +Invoke the `bmad-review-adversarial-general` skill in a subagent with the changed files: + +- The subagent gets NO conversation context (to avoid anchoring bias). +- Launch at the same model capability as the current session. +- **Fallback:** If sub-agents are unavailable, write the changed files to a review prompt file in `{implementation_artifacts}` and HALT. Ask the human to run the review in a separate session and paste back the findings.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/gds-quick-flow/gds-quick-dev/step-oneshot.md` at line 22, The long instruction invoking the bmad-review-adversarial-general subagent is overloaded and should be split into clear, ordered steps: (1) state "Invoke the bmad-review-adversarial-general skill in a new subagent" as the action, (2) explicitly list invocation parameters — "provide only the changed files, pass NO conversation context, and set the subagent model capability equal to the current session's capability", (3) add a separate sentence explaining the rationale for "NO conversation context" (avoid anchoring bias), and (4) describe the fallback behavior in its own sentence: "If no sub-agents are available, write the changed files to a review prompt file in {implementation_artifacts} and HALT, then ask the user to run the review in a separate session and paste back findings." Ensure each requirement is atomic and in the same order as execution to avoid misinterpretation of subagent invocation, context handling, capability matching, and fallback.src/workflows/gds-quick-flow/gds-quick-dev/step-01-clarify-and-route.md (1)
57-59: Clarify the "no file in planning_artifacts is newer" validation.Line 57 states a cached epic context is valid when "no file in
{planning_artifacts}is newer." This freshness check requires comparing file modification times, but the instruction doesn't specify:
- Whether "newer" means mtime, ctime, or birthtime
- How to handle newly added planning files that didn't exist when the cache was created
- What to do if the timestamp comparison fails (e.g., filesystem doesn't support reliable timestamps)
Consider adding explicit guidance for edge cases to ensure consistent cache invalidation behavior.
📋 Proposed clarification
- 2. **Check for a valid cached epic context.** Look for `{implementation_artifacts}/epic-<N>-context.md` (where `<N>` is the epic number). A file is **valid** when it exists, is non-empty, starts with `# Epic <N> Context:` (with the correct epic number), and no file in `{planning_artifacts}` is newer. + 2. **Check for a valid cached epic context.** Look for `{implementation_artifacts}/epic-<N>-context.md` (where `<N>` is the epic number). A file is **valid** when it exists, is non-empty, starts with `# Epic <N> Context:` (with the correct epic number), and no file in `{planning_artifacts}` has a modification time (mtime) later than the cache file. If timestamp comparison is unavailable or fails, treat the cache as invalid.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/workflows/gds-quick-flow/gds-quick-dev/step-01-clarify-and-route.md` around lines 57 - 59, Clarify and tighten the freshness rule for the cached epic context so the phrase "no file in {planning_artifacts} is newer" is deterministic: specify that compare the modification time (mtime) of {implementation_artifacts}/epic-<N>-context.md against the mtimes of all files in {planning_artifacts}; treat any planning file that did not exist when the cache was created (i.e., present now but absent at cache time) as "newer" and therefore invalidate the cache; if any mtime comparison cannot be performed (filesystem lacks reliable timestamps or an error occurs), conservatively invalidate the cache and surface a warning message; update the text around "{implementation_artifacts}/epic-<N>-context.md" and the "no file in {planning_artifacts} is newer" line to include these explicit rules and the fallback behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/workflows/2-design/gds-create-gdd/workflow.md`:
- Line 2: The workflow was renamed to "gds-create-gdd" but references still
instruct users to run the old "create-gdd" command; update all dependent
references to the new name (or add a compatibility alias) by replacing
occurrences of "create-gdd" with "gds-create-gdd" in the documentation and step
files (notably step-08-complete and step-01-init) and update the workflow name
in the reference tables (workflows and agents) so links/commands match, or
implement an alias entry that maps "create-gdd" to "gds-create-gdd" to preserve
backward compatibility.
In `@src/workflows/2-design/gds-create-prd/steps-c/step-12-complete.md`:
- Line 7: The step introduces a new variable validationWorkflow but the
completion option still references checkImplementationReadinessWorkflow; update
the option text and any occurrences in step-12-complete.md that show or invoke
the validation path to use {validationWorkflow} instead of
{checkImplementationReadinessWorkflow} (and ensure any surrounding copy or
action/button metadata uses the new variable name so the PRD completion path
advertises/invokes the correct workflow).
In `@src/workflows/2-design/gds-edit-gdd/workflow.md`:
- Around line 38-57: This delegation won't work because gds-edit-prd only
accepts {main_config} and prompts for a PRD path, so either (A) extend the
gds-edit-prd workflow to accept and honor a target document path and mapping
parameters (add inputs like {target_doc_path} and {field_mappings} to
src/workflows/2-design/gds-edit-prd/workflow.md and propagate those into its
edit steps so substitutions such as "Product vision -> Game vision" are applied
and the HALT condition can be detected), or (B) implement GDD-specific edit flow
inside src/workflows/2-design/gds-edit-gdd/workflow.md by replacing the
delegation with explicit steps that load the GDD at {planning_artifacts}/gdd.md,
apply the substitution table (Product vision→Game vision, Personas→Player
persona, etc.) when following the editWorkflow steps, and perform the
HALT/ask-user behavior when a GDD schema mismatch is encountered.
In `@src/workflows/2-design/gds-edit-prd/data/prd-purpose.md`:
- Line 3: Replace the typo phrase "rhw BMad Method" in the PRD header sentence
with "the BMAD Method" so the line reads: "The PRD is the top of the required
funnel that feeds all subsequent product development work in the BMAD Method.";
update the text in the prd-purpose.md content where the sentence appears.
In `@src/workflows/2-design/gds-validate-gdd/workflow.md`:
- Around line 39-46: The delegation in gds-validate-gdd to the gds-validate-prd
workflow is invalid because gds-validate-prd (name: gds-validate-prd,
main_config: '{module_config}', validateWorkflow:
'./steps-v/step-v-01-discovery.md') does not accept a target document path;
either modify gds-validate-prd to accept an optional parameter like
document_path (and thread it through its discovery step/validateWorkflow to use
the provided path instead of prompting), or remove the delegation from
gds-validate-gdd and implement GDD-specific validation here (add a validate_gdd
step or workflow that loads {planning_artifacts}/gdd.md, runs the same checks as
gds-validate-prd, and performs the required post-processing: prefixing the
report title with "GDD Validation Report" and annotating GDD-vs-PRD schema false
positives).
In `@src/workflows/2-design/gds-validate-prd/data/prd-purpose.md`:
- Line 3: Replace the typo "rhw BMad Method" with "the BMAD Method" in the
string "**The PRD is the top of the required funnel that feeds all subsequent
product development work in rhw BMad Method.**" in this file and also update the
duplicate file `gds-edit-prd/data/prd-purpose.md` so both copies match; ensure
the corrected phrase reads "**the BMAD Method**" exactly in both files.
In `@src/workflows/4-production/gds-code-review/steps/step-04-present.md`:
- Line 11: The step-04-present.md uses a different finding bucket name
(`decision-needed`) than step-03-triage.md (`decision_needed`), which can cause
items to be skipped; update all occurrences in step-04-present.md to the
canonical `decision_needed` (and similarly normalize any other docs referenced)
so the bucket name is consistent across steps, ensuring checks that reference
`decision_needed` match the triage output.
In `@src/workflows/4-production/gds-sprint-status/workflow.md`:
- Line 132: The workflow currently computes next_agent (DEV) but doesn't export
it and hardcodes DEV for all recommendation paths; update the template-output
exports to include next_agent and change the assignments inside the
recommendation selection logic (the places that set next_story_id,
next_workflow_id, next_agent) so each path maps to the correct role — e.g.,
dev-story => DEV, code-review => REVIEWER (or CODE_REVIEWER), create-story =>
PRODUCT_OWNER (or PM), retrospective => FACILITATOR (or TEAM_LEAD) — and ensure
the exported variable name matches what downstream consumers expect (e.g.,
gds-document-project's {{next_agent}}).
In `@src/workflows/gds-quick-flow/gds-quick-dev/spec-template.md`:
- Line 6: Update the spec docs and/or add runtime validation so context entries
clearly use the "{project-root}/" prefix: add guidance to step-02-plan.md
explaining that "{project-root}" is a placeholder resolved to the
workspace/project root and examples for valid values (e.g.,
"{project-root}/standards/README.md"), and implement a validation function
validateContextPaths(context: string[]) that checks each entry
startsWith("{project-root}/"), returns or throws clear errors listing offending
paths and suggested fixes, and ensure the loader used by
step-03-implement/step-04-review calls validateContextPaths before attempting to
load files.
In `@src/workflows/gds-quick-flow/gds-quick-dev/step-05-present.md`:
- Around line 53-56: The frontmatter status for `{spec_file}` is set to `done`
while the sync step calls `./sync-sprint-status.md` with `{target_status}` =
`review`, causing inconsistent lifecycle states; pick one state and make both
places match: either change the `{spec_file}` frontmatter status to `review` or
change the `./sync-sprint-status.md` invocation `{target_status}` to `done` so
the spec and sprint sync are identical, updating the status token in
step-05-present.md accordingly.
---
Nitpick comments:
In `@src/workflows/2-design/gds-edit-prd/steps-e/step-e-04-complete.md`:
- Line 7: The workflow declares validationWorkflow: 'skill:gds-validate-prd' but
the invocation still uses the hardcoded skill name; update the invocation that
currently calls 'skill:gds-validate-prd' (the call around the step that
references the validator at Line 123) to reference the validationWorkflow
variable instead (e.g., use the validationWorkflow identifier where the skill
name is passed) so the reusable variable is actually used and prevents config
drift.
In `@src/workflows/2-design/gds-validate-prd/data/prd-purpose.md`:
- Around line 1-197: The file prd-purpose.md is duplicated (identical to the one
under gds-edit-prd); remove the maintenance burden by choosing one canonical
source and making the other reference it: either replace the duplicate with a
symbolic link to the canonical prd-purpose.md, or leave the duplicate but add a
top-of-file comment in each prd-purpose.md pointing to the canonical file and
update the repo README to document that these two files must be kept in sync;
update CI/docs to validate duplication policy if available.
In `@src/workflows/4-production/gds-code-review/steps/step-04-present.md`:
- Around line 94-106: Replace the inline "Sync sprint-status" subsection in
step-04-present.md with a call to the existing shared sub-step defined in
sync-sprint-status.md to avoid duplicated logic; remove the ad-hoc
load/update/save steps and instead invoke the shared sync procedure so
idempotency and non-regression rules (as implemented in the shared sub-step) are
preserved; ensure the subsection still documents skip behavior when {story_key}
is absent and retains the same user-facing messages for "file missing" and
"story not found" cases by forwarding parameters (story_key, sprint_status path,
new_status) to the shared sub-step.
In `@src/workflows/4-production/gds-sprint-planning/SKILL.md`:
- Line 3: The SKILL.md description is too narrowly focused on status tracking;
update the description in SKILL.md (the description field) to mention both
sprint planning output and status tracking so the workflow reflects planning
purpose as well as tracking (e.g., change wording to reference generating sprint
plans, backlog prioritization, and status tracking from epics). Ensure the
description remains concise and includes trigger phrases like "run sprint
planning" or "generate sprint plan" if present.
In `@src/workflows/gds-quick-flow/gds-quick-dev/step-01-clarify-and-route.md`:
- Around line 57-59: Clarify and tighten the freshness rule for the cached epic
context so the phrase "no file in {planning_artifacts} is newer" is
deterministic: specify that compare the modification time (mtime) of
{implementation_artifacts}/epic-<N>-context.md against the mtimes of all files
in {planning_artifacts}; treat any planning file that did not exist when the
cache was created (i.e., present now but absent at cache time) as "newer" and
therefore invalidate the cache; if any mtime comparison cannot be performed
(filesystem lacks reliable timestamps or an error occurs), conservatively
invalidate the cache and surface a warning message; update the text around
"{implementation_artifacts}/epic-<N>-context.md" and the "no file in
{planning_artifacts} is newer" line to include these explicit rules and the
fallback behavior.
In `@src/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.md`:
- Around line 19-23: Emphasize and enforce the "do not surgically carve sections
out; regenerate the spec for the narrowed scope" rule by adding a verification
checkpoint after regeneration: when handling the Token count branch in
step-02-plan (the 1600-token check and the `[S] Split` flow), require the agent
that regenerates the spec for the main goal (the regenerated spec routine) to
run a concise scope-validation step that compares the regenerated spec against
the original to confirm only the main goal is retained (list named secondary
goals appended to `{deferred_work_file}`) and flag any remaining secondary
content for re-regeneration before continuing to checkpoint; make this
verification explicit in the `[S] Split` instructions and ensure the phrase
about not surgically carving is highlighted as a required invariant for the
regeneration routine.
- Around line 1-3: Add an explicit spec_file frontmatter variable to this step
so templates referencing {spec_file} resolve correctly; update the frontmatter
in step-02-plan.md to include a spec_file key (the same variable that
step-01-clarify-and-route.md initializes) and ensure its placeholder name
matches usages throughout the file (e.g., references on lines that use
{spec_file}) so the step can be executed standalone without relying on implicit
inheritance.
In `@src/workflows/gds-quick-flow/gds-quick-dev/step-oneshot.md`:
- Line 53: Replace the em-dash in the git comment with a standard double-hyphen
or parentheses and explicitly define how the two path variables are derived: set
{absolute-root} to the output of git rev-parse --show-toplevel (fall back to the
current working directory if that command fails) and set {absolute-spec-file} to
the absolute path of {spec_file} (resolved relative to the current working
directory or the repo root as appropriate); then instruct to run code -r
"{absolute-root}" "{absolute-spec-file}" with both paths double-quoted to handle
spaces/special characters.
- Line 22: The long instruction invoking the bmad-review-adversarial-general
subagent is overloaded and should be split into clear, ordered steps: (1) state
"Invoke the bmad-review-adversarial-general skill in a new subagent" as the
action, (2) explicitly list invocation parameters — "provide only the changed
files, pass NO conversation context, and set the subagent model capability equal
to the current session's capability", (3) add a separate sentence explaining the
rationale for "NO conversation context" (avoid anchoring bias), and (4) describe
the fallback behavior in its own sentence: "If no sub-agents are available,
write the changed files to a review prompt file in {implementation_artifacts}
and HALT, then ask the user to run the review in a separate session and paste
back findings." Ensure each requirement is atomic and in the same order as
execution to avoid misinterpretation of subagent invocation, context handling,
capability matching, and fallback.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3d562710-a4cf-4a1f-941f-9c4b67b110ff
⛔ Files ignored due to path filters (6)
src/agents/gds-agent-game-dev/gametest/qa-index.csvis excluded by!**/*.csvsrc/module-help.csvis excluded by!**/*.csvsrc/workflows/2-design/gds-create-prd/data/domain-complexity.csvis excluded by!**/*.csvsrc/workflows/2-design/gds-create-prd/data/project-types.csvis excluded by!**/*.csvsrc/workflows/2-design/gds-validate-prd/data/domain-complexity.csvis excluded by!**/*.csvsrc/workflows/2-design/gds-validate-prd/data/project-types.csvis excluded by!**/*.csv
📒 Files selected for processing (146)
.claude-plugin/marketplace.jsonCHANGELOG.mdSYNC-PLAN.mdTODO.mdpackage.jsonsrc/agents/gds-agent-game-dev/SKILL.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/balance-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/certification-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/compatibility-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/e2e-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/godot-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/input-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/localization-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/multiplayer-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/performance-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/playtesting.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/qa-automation.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/regression-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/save-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/smoke-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/test-priorities.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/unity-testing.mdsrc/agents/gds-agent-game-dev/gametest/knowledge/unreal-testing.mdsrc/agents/gds-agent-game-qa/SKILL.mdsrc/agents/gds-agent-game-qa/bmad-skill-manifest.yamlsrc/agents/gds-agent-game-scrum-master/SKILL.mdsrc/agents/gds-agent-game-scrum-master/bmad-skill-manifest.yamlsrc/agents/gds-agent-game-solo-dev/SKILL.mdsrc/workflows/2-design/create-prd/bmad-skill-manifest.yamlsrc/workflows/2-design/gds-create-gdd/steps-c/step-01-init.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-01b-continue.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-02-context.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-03-platforms.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-04-vision.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-05-core-gameplay.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-06-mechanics.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-07-game-type.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-08-progression.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-09-levels.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-10-art-audio.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-11-technical.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-12-epics.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-13-metrics.mdsrc/workflows/2-design/gds-create-gdd/steps-c/step-14-complete.mdsrc/workflows/2-design/gds-create-gdd/workflow.mdsrc/workflows/2-design/gds-create-prd/SKILL.mdsrc/workflows/2-design/gds-create-prd/bmad-skill-manifest.yamlsrc/workflows/2-design/gds-create-prd/data/prd-purpose.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-01-init.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-01b-continue.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-02-discovery.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-02b-vision.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-02c-executive-summary.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-03-success.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-04-journeys.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-05-domain.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-06-innovation.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-07-project-type.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-08-scoping.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-09-functional.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-10-nonfunctional.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-11-polish.mdsrc/workflows/2-design/gds-create-prd/steps-c/step-12-complete.mdsrc/workflows/2-design/gds-create-prd/templates/prd-template.mdsrc/workflows/2-design/gds-create-prd/workflow.mdsrc/workflows/2-design/gds-edit-gdd/SKILL.mdsrc/workflows/2-design/gds-edit-gdd/bmad-skill-manifest.yamlsrc/workflows/2-design/gds-edit-gdd/workflow.mdsrc/workflows/2-design/gds-edit-prd/SKILL.mdsrc/workflows/2-design/gds-edit-prd/bmad-skill-manifest.yamlsrc/workflows/2-design/gds-edit-prd/data/prd-purpose.mdsrc/workflows/2-design/gds-edit-prd/steps-e/step-e-01-discovery.mdsrc/workflows/2-design/gds-edit-prd/steps-e/step-e-01b-legacy-conversion.mdsrc/workflows/2-design/gds-edit-prd/steps-e/step-e-02-review.mdsrc/workflows/2-design/gds-edit-prd/steps-e/step-e-03-edit.mdsrc/workflows/2-design/gds-edit-prd/steps-e/step-e-04-complete.mdsrc/workflows/2-design/gds-edit-prd/workflow.mdsrc/workflows/2-design/gds-validate-gdd/SKILL.mdsrc/workflows/2-design/gds-validate-gdd/bmad-skill-manifest.yamlsrc/workflows/2-design/gds-validate-gdd/workflow.mdsrc/workflows/2-design/gds-validate-prd/SKILL.mdsrc/workflows/2-design/gds-validate-prd/bmad-skill-manifest.yamlsrc/workflows/2-design/gds-validate-prd/data/prd-purpose.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-01-discovery.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-02-format-detection.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-02b-parity-check.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-03-density-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-04-brief-coverage-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-05-measurability-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-06-traceability-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-07-implementation-leakage-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-08-domain-compliance-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-09-project-type-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-10-smart-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-11-holistic-quality-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-12-completeness-validation.mdsrc/workflows/2-design/gds-validate-prd/steps-v/step-v-13-report-complete.mdsrc/workflows/2-design/gds-validate-prd/workflow.mdsrc/workflows/4-production/gds-code-review/SKILL.mdsrc/workflows/4-production/gds-code-review/steps/step-01-gather-context.mdsrc/workflows/4-production/gds-code-review/steps/step-02-review.mdsrc/workflows/4-production/gds-code-review/steps/step-03-triage.mdsrc/workflows/4-production/gds-code-review/steps/step-04-present.mdsrc/workflows/4-production/gds-code-review/workflow.mdsrc/workflows/4-production/gds-correct-course/SKILL.mdsrc/workflows/4-production/gds-correct-course/checklist.mdsrc/workflows/4-production/gds-correct-course/workflow.mdsrc/workflows/4-production/gds-create-story/workflow.mdsrc/workflows/4-production/gds-dev-story/workflow.mdsrc/workflows/4-production/gds-retrospective/SKILL.mdsrc/workflows/4-production/gds-retrospective/workflow.mdsrc/workflows/4-production/gds-sprint-planning/SKILL.mdsrc/workflows/4-production/gds-sprint-planning/workflow.mdsrc/workflows/4-production/gds-sprint-status/SKILL.mdsrc/workflows/4-production/gds-sprint-status/workflow.mdsrc/workflows/gametest/gds-test-design/test-design-template.mdsrc/workflows/gds-quick-flow/gds-quick-dev-new-preview/SKILL.mdsrc/workflows/gds-quick-flow/gds-quick-dev-new-preview/steps/step-01-clarify-and-route.mdsrc/workflows/gds-quick-flow/gds-quick-dev-new-preview/steps/step-02-plan.mdsrc/workflows/gds-quick-flow/gds-quick-dev-new-preview/steps/step-03-implement.mdsrc/workflows/gds-quick-flow/gds-quick-dev-new-preview/steps/step-05-present.mdsrc/workflows/gds-quick-flow/gds-quick-dev-new-preview/workflow.mdsrc/workflows/gds-quick-flow/gds-quick-dev/SKILL.mdsrc/workflows/gds-quick-flow/gds-quick-dev/compile-epic-context.mdsrc/workflows/gds-quick-flow/gds-quick-dev/spec-template.mdsrc/workflows/gds-quick-flow/gds-quick-dev/step-01-clarify-and-route.mdsrc/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.mdsrc/workflows/gds-quick-flow/gds-quick-dev/step-03-implement.mdsrc/workflows/gds-quick-flow/gds-quick-dev/step-04-review.mdsrc/workflows/gds-quick-flow/gds-quick-dev/step-05-present.mdsrc/workflows/gds-quick-flow/gds-quick-dev/step-oneshot.mdsrc/workflows/gds-quick-flow/gds-quick-dev/steps/step-01-mode-detection.mdsrc/workflows/gds-quick-flow/gds-quick-dev/steps/step-02-context-gathering.mdsrc/workflows/gds-quick-flow/gds-quick-dev/steps/step-03-execute.mdsrc/workflows/gds-quick-flow/gds-quick-dev/steps/step-04-self-check.mdsrc/workflows/gds-quick-flow/gds-quick-dev/steps/step-05-adversarial-review.mdsrc/workflows/gds-quick-flow/gds-quick-dev/steps/step-06-resolve-findings.mdsrc/workflows/gds-quick-flow/gds-quick-dev/sync-sprint-status.mdsrc/workflows/gds-quick-flow/gds-quick-dev/workflow.mdsrc/workflows/gds-quick-flow/gds-quick-spec/SKILL.mdsrc/workflows/gds-quick-flow/gds-quick-spec/steps/step-01-understand.mdsrc/workflows/gds-quick-flow/gds-quick-spec/steps/step-02-investigate.mdsrc/workflows/gds-quick-flow/gds-quick-spec/steps/step-03-generate.mdsrc/workflows/gds-quick-flow/gds-quick-spec/steps/step-04-review.mdsrc/workflows/gds-quick-flow/gds-quick-spec/tech-spec-template.mdsrc/workflows/gds-quick-flow/gds-quick-spec/workflow.md
💤 Files with no reviewable changes (24)
- src/workflows/gds-quick-flow/gds-quick-spec/SKILL.md
- src/agents/gds-agent-game-qa/bmad-skill-manifest.yaml
- src/workflows/gds-quick-flow/gds-quick-dev/steps/step-03-execute.md
- src/agents/gds-agent-game-scrum-master/SKILL.md
- src/workflows/gds-quick-flow/gds-quick-dev-new-preview/SKILL.md
- src/agents/gds-agent-game-scrum-master/bmad-skill-manifest.yaml
- src/workflows/gds-quick-flow/gds-quick-dev/steps/step-06-resolve-findings.md
- src/workflows/gds-quick-flow/gds-quick-dev-new-preview/steps/step-03-implement.md
- src/workflows/gds-quick-flow/gds-quick-spec/workflow.md
- src/agents/gds-agent-game-qa/SKILL.md
- src/workflows/gds-quick-flow/gds-quick-dev/steps/step-04-self-check.md
- src/workflows/gds-quick-flow/gds-quick-spec/tech-spec-template.md
- src/workflows/gds-quick-flow/gds-quick-dev/steps/step-02-context-gathering.md
- src/workflows/gds-quick-flow/gds-quick-dev-new-preview/workflow.md
- src/workflows/gds-quick-flow/gds-quick-dev/steps/step-01-mode-detection.md
- src/workflows/gds-quick-flow/gds-quick-dev-new-preview/steps/step-02-plan.md
- src/workflows/gds-quick-flow/gds-quick-dev-new-preview/steps/step-05-present.md
- src/workflows/gds-quick-flow/gds-quick-spec/steps/step-01-understand.md
- src/workflows/gds-quick-flow/gds-quick-spec/steps/step-03-generate.md
- src/workflows/gds-quick-flow/gds-quick-spec/steps/step-02-investigate.md
- src/workflows/gds-quick-flow/gds-quick-spec/steps/step-04-review.md
- src/workflows/gds-quick-flow/gds-quick-dev/steps/step-05-adversarial-review.md
- src/workflows/2-design/create-prd/bmad-skill-manifest.yaml
- src/workflows/gds-quick-flow/gds-quick-dev-new-preview/steps/step-01-clarify-and-route.md
| @@ -1,5 +1,5 @@ | |||
| --- | |||
| name: create-gdd | |||
| name: gds-create-gdd | |||
There was a problem hiding this comment.
Workflow rename introduced cross-file command drift (create-gdd vs gds-create-gdd).
Renaming name to gds-create-gdd is fine, but dependent references still instruct users to run create-gdd, which can break workflow handoff/discovery. Please update linked references (or add a compatibility alias) in:
src/workflows/1-preproduction/gds-create-game-brief/steps/step-08-complete.md(old command text)src/workflows/3-technical/gds-game-architecture/steps/step-01-init.md(old command text)docs/reference/workflows.mdanddocs/reference/agents.md(old workflow name in tables)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/workflows/2-design/gds-create-gdd/workflow.md` at line 2, The workflow
was renamed to "gds-create-gdd" but references still instruct users to run the
old "create-gdd" command; update all dependent references to the new name (or
add a compatibility alias) by replacing occurrences of "create-gdd" with
"gds-create-gdd" in the documentation and step files (notably step-08-complete
and step-01-init) and update the workflow name in the reference tables
(workflows and agents) so links/commands match, or implement an alias entry that
maps "create-gdd" to "gds-create-gdd" to preserve backward compatibility.
| # File References | ||
| outputFile: '{planning_artifacts}/prd.md' | ||
| validationFlow: '../steps-v/step-v-01-discovery.md' | ||
| validationWorkflow: 'skill:gds-validate-prd' |
There was a problem hiding this comment.
validationWorkflow is introduced but not wired into the validation option text.
Line 7 adds validationWorkflow, but the step still presents {checkImplementationReadinessWorkflow} at Line 74, so the PRD completion path may advertise/invoke the wrong workflow.
🔧 Proposed wiring fix
-**Option 1: Check Implementation Readiness** (`{checkImplementationReadinessWorkflow}`)
-- Validates PRD has all information needed for development
-- Checks epic coverage completeness
-- Reviews UX alignment with requirements
-- Assesses epic quality and readiness
-- Identifies gaps before architecture/design work begins
+**Option 1: Validate PRD** (`{validationWorkflow}`)
+- Validates PRD structure and content quality
+- Checks requirements completeness and consistency
+- Verifies downstream readiness before implementation planning
+- Identifies gaps before architecture/design work begins🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/workflows/2-design/gds-create-prd/steps-c/step-12-complete.md` at line 7,
The step introduces a new variable validationWorkflow but the completion option
still references checkImplementationReadinessWorkflow; update the option text
and any occurrences in step-12-complete.md that show or invoke the validation
path to use {validationWorkflow} instead of
{checkImplementationReadinessWorkflow} (and ensure any surrounding copy or
action/button metadata uses the new variable name so the PRD completion path
advertises/invokes the correct workflow).
| @@ -0,0 +1,197 @@ | |||
| # BMAD PRD Purpose | |||
|
|
|||
| **The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.** | |||
There was a problem hiding this comment.
Fix typo: "rhw BMad Method" should be "the BMAD Method"
Line 3 contains a typo that should be corrected for professional documentation.
📝 Proposed fix
-**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
+**The PRD is the top of the required funnel that feeds all subsequent product development work in the BMAD Method.**📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| **The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.** | |
| **The PRD is the top of the required funnel that feeds all subsequent product development work in the BMAD Method.** |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/workflows/2-design/gds-edit-prd/data/prd-purpose.md` at line 3, Replace
the typo phrase "rhw BMad Method" in the PRD header sentence with "the BMAD
Method" so the line reads: "The PRD is the top of the required funnel that feeds
all subsequent product development work in the BMAD Method."; update the text in
the prd-purpose.md content where the sentence appears.
| @@ -0,0 +1,197 @@ | |||
| # BMAD PRD Purpose | |||
|
|
|||
| **The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.** | |||
There was a problem hiding this comment.
Fix typo: "rhw BMad Method" should be "the BMAD Method"
This file is a duplicate of gds-edit-prd/data/prd-purpose.md and contains the same typo on line 3.
📝 Proposed fix
-**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
+**The PRD is the top of the required funnel that feeds all subsequent product development work in the BMAD Method.**📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| **The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.** | |
| **The PRD is the top of the required funnel that feeds all subsequent product development work in the BMAD Method.** |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/workflows/2-design/gds-validate-prd/data/prd-purpose.md` at line 3,
Replace the typo "rhw BMad Method" with "the BMAD Method" in the string "**The
PRD is the top of the required funnel that feeds all subsequent product
development work in rhw BMad Method.**" in this file and also update the
duplicate file `gds-edit-prd/data/prd-purpose.md` so both copies match; ensure
the corrected phrase reads "**the BMAD Method**" exactly in both files.
| created: '{date}' | ||
| status: 'draft' # draft | ready-for-dev | in-progress | in-review | done | ||
| context: [] # optional: max 3 project-wide standards/docs. NO source code files. | ||
| context: [] # optional: `{project-root}/`-prefixed paths to project-wide standards/docs the implementation agent should load. Keep short — only what isn't already distilled into the spec body. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check if step-02-plan fills context field with proper prefixes
# Search for context field handling in step-02-plan
rg -n -A5 -B5 'context.*project-root' src/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.md
# Check for any context field population logic
rg -n 'context:' src/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.mdRepository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 67
🏁 Script executed:
# First, let's check if the files mentioned exist and their content
cd src/workflows/gds-quick-flow/gds-quick-dev/ 2>/dev/null && ls -la *.md || echo "Directory check"
# Read spec-template.md to see the full context
cat -n src/workflows/gds-quick-flow/gds-quick-dev/spec-template.md | head -30
# Read step-02-plan.md to understand its structure
cat -n src/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.md | head -50Repository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 1026
🏁 Script executed:
# Search for {project-root} across the entire workflow directory
rg -n '{project-root}' src/workflows/gds-quick-flow/gds-quick-dev/
# Also search in parent directories
rg -n '{project-root}' src/workflows/gds-quick-flow/Repository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 264
🏁 Script executed:
# Look for any validation or processing logic related to context field
rg -n -A3 'context' src/workflows/gds-quick-flow/gds-quick-dev/*.mdRepository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 15564
🏁 Script executed:
# Check if there's any documentation about path resolution or validation
fd -e md -e txt -e json src/workflows/gds-quick-flow/ | head -20Repository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 506
🏁 Script executed:
cat -n src/workflows/gds-quick-flow/gds-quick-dev/spec-template.mdRepository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 4091
🏁 Script executed:
cat -n src/workflows/gds-quick-flow/gds-quick-dev/step-02-plan.mdRepository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 3336
🏁 Script executed:
# Use escaped curly braces for rg search
rg -n -F '{project-root}' src/workflows/gds-quick-flow/Repository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 339
🏁 Script executed:
# Check step-03-implement.md around the context usage
sed -n '25,35p' src/workflows/gds-quick-flow/gds-quick-dev/step-03-implement.mdRepository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 967
🏁 Script executed:
# Check step-04-review.md around the context usage
sed -n '25,35p' src/workflows/gds-quick-flow/gds-quick-dev/step-04-review.mdRepository: bmad-code-org/bmad-module-game-dev-studio
Length of output: 1165
Clarify and document the {project-root}/ path prefix convention for the context field.
The template comment specifies that context paths must be prefixed with {project-root}/, but the workflow lacks explanation of:
- Whether
{project-root}is a literal string or a placeholder variable - How
{project-root}is resolved at runtime - What happens if paths don't follow this convention
- How step-02-plan should populate this field
Step-02-plan.md provides no specific guidance for filling the context field. Step-03-implement and step-04-review expect these files to be loaded but don't document the path resolution mechanism.
Add either:
- Documentation in step-02-plan.md explaining how to format context paths, or
- A validation function that ensures paths conform to the convention and provides clear error messages if they don't
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/workflows/gds-quick-flow/gds-quick-dev/spec-template.md` at line 6,
Update the spec docs and/or add runtime validation so context entries clearly
use the "{project-root}/" prefix: add guidance to step-02-plan.md explaining
that "{project-root}" is a placeholder resolved to the workspace/project root
and examples for valid values (e.g., "{project-root}/standards/README.md"), and
implement a validation function validateContextPaths(context: string[]) that
checks each entry startsWith("{project-root}/"), returns or throws clear errors
listing offending paths and suggested fixes, and ensure the loader used by
step-03-implement/step-04-review calls validateContextPaths before attempting to
load files.
Comment on lines
+53
to
+56
| Change `{spec_file}` status to `done` in the frontmatter. | ||
|
|
||
| Follow `./sync-sprint-status.md` with `{target_status}` = `review`. | ||
|
|
There was a problem hiding this comment.
Align spec and sprint statuses (done vs review).
This step sets the spec to done but syncs sprint status to review, which leaves state inconsistent across artifacts. Pick one lifecycle state for this checkpoint and apply it consistently.
Possible alignment (if this phase is truly complete)
-Follow `./sync-sprint-status.md` with `{target_status}` = `review`.
+Follow `./sync-sprint-status.md` with `{target_status}` = `done`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| Change `{spec_file}` status to `done` in the frontmatter. | |
| Follow `./sync-sprint-status.md` with `{target_status}` = `review`. | |
| Change `{spec_file}` status to `done` in the frontmatter. | |
| Follow `./sync-sprint-status.md` with `{target_status}` = `done`. | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/workflows/gds-quick-flow/gds-quick-dev/step-05-present.md` around lines
53 - 56, The frontmatter status for `{spec_file}` is set to `done` while the
sync step calls `./sync-sprint-status.md` with `{target_status}` = `review`,
causing inconsistent lifecycle states; pick one state and make both places
match: either change the `{spec_file}` frontmatter status to `review` or change
the `./sync-sprint-status.md` invocation `{target_status}` to `done` so the spec
and sprint sync are identical, updating the status token in step-05-present.md
accordingly.
- README.md:116 — wrap contact@bmadcode.com in autolink brackets to clear the MD034 lint failure (email line arrived via origin/main merge into this branch) - gds-retrospective input files — replace PRD-only input with GDD (primary design doc in GDS), narrative (optional), and PRD (optional, for external-tool compatibility). Updates the step 0.5 content-variable list and the change-impact checklist accordingly. - docs/reference/agents.md — rewrite for v0.3.0 agent roster: 6 -> 5 agents, Scrum Master + QA sections removed, Game Developer section expanded to cover the absorbed sprint / story / retrospective / testing capabilities with a full command table, knowledge-base path updated to new location under the agent dir. By-Phase and By-Task tables updated; handoff diagram simplified. - src/module.yaml module_version: 0.2.0 -> 0.3.0 - Reference consistency for quick-prototype: module-help.csv and gds-agent-game-dev SKILL.md were using the source name bmad-gds-quick-prototype; standardized to the installed/invocable name gds-quick-prototype to match designer and solo-dev agents. - gds-quick-dev/workflow.md — user_skill_level -> game_dev_experience (the variable name that actually exists in module.yaml; left over from upstream bmm port). - prd-purpose.md (x3) — typo: "rhw" -> "the". Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Six findings verified; four required fixes, two were correct as-shipped:
VERIFIED + FIXED:
- gds-create-prd/steps-c/step-12-complete.md: body referenced an undefined
variable {checkImplementationReadinessWorkflow}. Frontmatter had the
wrong variable (validationWorkflow, leftover from Phase 2a split, never
consumed). Replaced with checkImplementationReadinessWorkflow pointing
to skill:gds-check-implementation-readiness, matching upstream's
Option-1 readiness-check semantics.
- gds-edit-gdd and gds-validate-gdd: previously delegated to the PRD
variants, which doesn't work — neither gds-edit-prd nor gds-validate-prd
accepts a target-document parameter. Replaced both placeholder stubs
with full GDD-specific implementations modeled on the PRD variants
but rewritten for game-design content (mechanics, gameplay loop,
pillars, genre conventions, engine constraints). 23 new files,
~5,000 lines:
* gds-edit-gdd: 5-step edit flow + gdd-purpose data
* gds-validate-gdd: 13-step validation flow + gdd-purpose +
genre-complexity.csv (24 genres mapped to complexity tiers,
signals, key concerns)
Validate-gdd reuses gds-create-gdd/game-types.csv via {module_root}
rather than duplicating it.
TODO.md: removed the GDD-specific step bodies entry now that they
exist.
- gds-code-review/steps/step-04-present.md: bucket name inconsistent
with step-03-triage.md. Triage uses decision_needed (underscore);
step-04 mixed underscore and hyphen forms. Normalized all 8
occurrences in step-04 to underscore form.
- gds-sprint-status/workflow.md: next_agent was hardcoded to "DEV"
for all five recommendation paths and never exported as a
template-output. Now sets per-path role labels (DEVELOPER, REVIEWER,
STORY_AUTHOR, FACILITATOR) and adds {{next_agent}} to the
template-output exports. Note clarifies that in the consolidated
Phase 4 model all role labels resolve to the same agent
(gds-agent-game-dev), kept distinct for downstream semantic use.
VERIFIED + NO FIX NEEDED:
- spec-template.md context-prefix guidance: matches upstream exactly.
The reviewer's "implement validateContextPaths()" suggestion doesn't
fit upstream's LLM-driven workflow architecture (no JS validators,
prefix contract is the inline frontmatter comment). Diverging from
upstream to add prose validators would conflict with the upstream-
mirror directive.
- gds-quick-dev/step-05-present.md spec-vs-sprint status: upstream
intent is two distinct lifecycles. {spec_file} status=done means the
artifact is finished from quick-dev's perspective; sprint-status
story status=review means the story still needs human/code review
before being marked done. sync-sprint-status.md line 15 explicitly
codifies this ordering (review > in-progress, done > review).
- gds-create-gdd "create-gdd" -> "gds-create-gdd" rename: grep
returns zero bare references; rename was fully propagated in Phase 2b.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
sjennings
added a commit
that referenced
this pull request
Apr 15, 2026
Unblocks markdownlint MD034/no-bare-urls failure on CI. Same fix as the one already on main (via PR #21). Cherry-picked here so this branch's CI passes; a future rebase onto main will absorb it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge latest changes
Summary by CodeRabbit
Release Notes
New Features
Changes
Version