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.

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
@@ -49,11 +50,10 @@ Never ask extra questions if you already understand what the user intends.
      - **Product Brief** (`*brief*`) — project vision and scope
    - Scan the listing for files matching these patterns. If any look relevant to the current intent, load them selectively — you don't need all of them, but you need the right constraints and requirements rather than guessing from code alone.
    - **Previous story continuity.** Using the intent and loaded context (especially any epics file), infer whether the current work is a story from an epic. Do not rely on filename patterns or regex — reason about the intent, the artifact listing, and epics content together. If the intent is an epic story:
-     1. Identify the epic and story number.
-     2. Scan `{implementation_artifacts}` for specs from the same epic with `status: done` and a lower story number.
-     3. Load the most recent one (highest story number below current).
-     4. 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. If the intent is not an epic story, or no previous spec exists, skip this silently.
+     1. Identify the epic number `{epic_num}` and story number `{story_num}`.
+     2. **Load continuity context.** 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) and 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. If no prior spec exists (e.g., first story of the epic), continue silently — this is not an error.
+     3. **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.
+     If the intent is not an epic story, skip this entire block silently and leave `{story_key}` unset.
 2. Clarify intent. Do not fantasize, do not leave open questions. If you must ask questions, ask them as a numbered list. When the human replies, verify that every single numbered question was answered. If any were ignored, HALT and re-ask only the missing questions before proceeding. Keep looping until intent is clear enough to implement.
 3. Version control sanity check. Is the working tree clean? Does the current branch make sense for this intent — considering its name and recent history? If the tree is dirty or the branch is an obvious mismatch, HALT and ask the human before proceeding. If version control is unavailable, skip this check.
 4. Multi-goal check (see SCOPE STANDARD). If the intent fails the single-goal criteria:

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.

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.

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)