From b6105ade41e900cc53c4d99668153b86322d3259 Mon Sep 17 00:00:00 2001 From: Alex Verkhovsky Date: Wed, 8 Apr 2026 19:10:18 -0700 Subject: [PATCH] feat(quick-dev): sync sprint-status.yaml on epic-story implementation When quick-dev infers the intent is an epic story, resolve the full sprint-status key during step-01's previous-story-continuity sub-step, then sync sprint-status.yaml at the two workflow boundaries code-review already owns the trailing half of: - step-03 start: flip the story to in-progress and lift the parent epic out of backlog if needed. - step-05 end: flip the story to review. Code-review keeps ownership of review -> done. Resolution uses exact numeric-segment equality on the {epic}-{story} prefix (never string-prefix match), so 1-1 no longer collides with 1-10. Both sync blocks are idempotent so step-04 loopbacks do not clobber human edits or bump last_updated without cause. Skips silently when sprint-status.yaml is missing or the intent is not an epic story. --- .../step-01-clarify-and-route.md | 5 ++- .../bmad-quick-dev/step-03-implement.md | 15 ++++++++ .../bmad-quick-dev/step-05-present.md | 36 ++++++++++++++----- .../bmad-quick-dev/workflow.md | 1 + 4 files changed, 48 insertions(+), 9 deletions(-) diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/step-01-clarify-and-route.md b/src/bmm-skills/4-implementation/bmad-quick-dev/step-01-clarify-and-route.md index aae1b3105..d54144b24 100644 --- a/src/bmm-skills/4-implementation/bmad-quick-dev/step-01-clarify-and-route.md +++ b/src/bmm-skills/4-implementation/bmad-quick-dev/step-01-clarify-and-route.md @@ -1,6 +1,7 @@ --- deferred_work_file: '{implementation_artifacts}/deferred-work.md' spec_file: '' # set at runtime for both routes before leaving this step +story_key: '' # set at runtime to the current story's full sprint-status key (e.g. 3-2-digest-delivery) when the intent is an epic story and sprint-status resolution succeeds --- # Step 1: Clarify and Route @@ -45,7 +46,7 @@ Never ask extra questions if you already understand what the user intends. **A) Epic story path** — if the intent is clearly an epic story: - 1. Identify the epic number and (if present) the story number. If you can't identify an epic number, use path B. + 1. Identify the epic number `{epic_num}` and (if present) the story number `{story_num}`. If you can't identify an epic number, use path B. 2. **Check for a valid cached epic context.** Look for `{implementation_artifacts}/epic--context.md` (where `` is the epic number). A file is **valid** when it exists, is non-empty, starts with `# Epic Context:` (with the correct epic number), and no file in `{planning_artifacts}` is newer. - **If valid:** load it as the primary planning context. Do not load raw planning docs (PRD, architecture, UX, etc.). Skip to step 5. @@ -59,6 +60,8 @@ Never ask extra questions if you already understand what the user intends. 5. **Previous story continuity.** Regardless of which context source succeeded above, scan `{implementation_artifacts}` for specs from the same epic with `status: done` and a lower story number. Load the most recent one (highest story number below current). Extract its **Code Map**, **Design Notes**, **Spec Change Log**, and **task list** as continuity context for step-02 planning. If no `done` spec is found but an `in-review` spec exists for the same epic with a lower story number, note it to the user and ask whether to load it. + 6. **Resolve `{story_key}` for sprint-status sync.** This runs for every epic story, independent of whether continuity context was found above. If `{sprint_status}` exists, load it, then walk every key in `development_status`, split each key on `-`, and collect matches where the first two segments parse as integers equal to `{epic_num}` and `{story_num}` (exact numeric equality — never string-prefix match, so `1-1` does not collide with `1-10`). Exactly one match → set `{story_key}` to that full key (e.g., `3-2-digest-delivery`). Zero matches or file missing → leave `{story_key}` unset (silent). Multiple matches → warn the user once (`"sprint-status lookup for {epic_num}-{story_num} is ambiguous; skipping sprint sync"`) and leave `{story_key}` unset. + **B) Freeform path** — if the intent is not an epic story: - Planning artifacts are the output of BMAD phases 1-3. Typical files include: - **PRD** (`*prd*`) — product requirements and success criteria diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/step-03-implement.md b/src/bmm-skills/4-implementation/bmad-quick-dev/step-03-implement.md index 96e6041bf..159347f70 100644 --- a/src/bmm-skills/4-implementation/bmad-quick-dev/step-03-implement.md +++ b/src/bmm-skills/4-implementation/bmad-quick-dev/step-03-implement.md @@ -24,6 +24,21 @@ Capture `baseline_commit` (current HEAD, or `NO_VCS` if version control is unava Change `{spec_file}` status to `in-progress` in the frontmatter before starting implementation. +#### Sync sprint status + +Skip this subsection if `{story_key}` is unset (the intent is not an epic story, or `step-01` could not resolve a sprint-status entry) or if `{sprint_status}` does not exist on disk. + +Otherwise: + +1. Load the FULL `{sprint_status}` file. +2. Find the `development_status` entry matching `{story_key}`. If not found, warn the user once (`"{story_key} not found in sprint-status; skipping sprint sync"`) and skip the remaining sub-steps. +3. Derive the parent epic key as `epic-{N}` where `{N}` is the leading numeric segment of `{story_key}` (e.g., `3-2-digest-delivery` → `epic-3`). +4. **Idempotency check.** If `development_status[{story_key}]` is already `in-progress` AND the parent epic entry is already `in-progress` or `done` (or missing), skip the remaining sub-steps — no write needed. This prevents step-04 loopbacks from clobbering human edits and from bumping `last_updated` without cause. +5. Set `development_status[{story_key}]` to `in-progress`. +6. If the parent epic entry exists and its current value is `backlog`, set it to `in-progress`. Leave it alone otherwise. +7. Refresh `last_updated` to the current date. +8. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS and WORKFLOW NOTES. + If `{spec_file}` has a non-empty `context:` list in its frontmatter, load those files before implementation begins. When handing to a sub-agent, include them in the sub-agent prompt so it has access to the referenced context. Hand `{spec_file}` to a sub-agent/task and let it implement. If no sub-agents are available, implement directly. diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md b/src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md index 3c0ba6c7e..9dc8c0ce9 100644 --- a/src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md +++ b/src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md @@ -48,16 +48,36 @@ Format each stop as framing first, link on the next indented line: When there is only one concern, omit the bold label — just list the stops directly. -### Commit and Present +### Mark Spec Done -1. Change `{spec_file}` status to `done` in the frontmatter. -2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title. -3. Open the spec in the user's editor so they can click through the Suggested Review Order: +Change `{spec_file}` status to `done` in the frontmatter. + +### Sync sprint status + +Skip this section if `{story_key}` is unset or `{sprint_status}` does not exist on disk. + +Otherwise: + +1. Load the FULL `{sprint_status}` file. +2. Find the `development_status` entry matching `{story_key}`. If not found, warn the user once (`"{story_key} not found in sprint-status; skipping sprint sync"`) and skip the remaining sub-steps. +3. **Idempotency check.** If `development_status[{story_key}]` is already `review` (or `done`), skip the remaining sub-steps — no write needed. Do not regress a `done` story back to `review`. +4. Set `development_status[{story_key}]` to `review`. Do not touch the parent epic entry — code-review owns the `review → done` transition and will decide whether the epic itself is done. +5. Refresh `last_updated` to the current date. +6. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS and WORKFLOW NOTES. + +### Commit and Open + +1. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title. +2. 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. - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead. -4. Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators. Include: - - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order. - - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop." - - Offer to push and/or create a pull request. + +### Display Summary + +Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators. Include: + +- A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order. +- **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop." +- Offer to push and/or create a pull request. Workflow complete. diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md b/src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md index 55b8fda72..8e13989fb 100644 --- a/src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md +++ b/src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md @@ -65,6 +65,7 @@ Load and read full config from `{main_config}` and resolve: - `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name` - `communication_language`, `document_output_language`, `user_skill_level` - `date` as system-generated current datetime +- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml` - `project_context` = `**/project-context.md` (load if exists) - CLAUDE.md / memory files (load if exist)