# Story 17.18: Rework bmad-dev-story Skill (Moderate Rework -- Extension Override for Cross-Section Status Update)

Status: review

## Story

As a **Developer**,
I want the `bmad-dev-story` skill to read and update story status using the unified `sprint-status.yaml` schema (searching `backlog` and `sprints[].items` arrays by item `id`),
So that development progress is reflected correctly in the unified file regardless of whether the story resides in the backlog or a sprint.

## Acceptance Criteria

1. **Given** `bmad-dev-story` is a BMAD built-in skill (source: `node_modules/bmad-method/src/bmm-skills/4-implementation/bmad-dev-story/`),
   **When** the extension override files are created in `lib/bmad-extension/skills/bmad-dev-story/`,
   **Then** the extension version takes precedence over the built-in during BMAD deployment (via the `--custom-content` flag),
   **And** the built-in is NOT modified,
   **And** the override provides replacement files for ALL three built-in files (`SKILL.md`, `workflow.md`, `checklist.md`) plus a `bmad-skill-manifest.yaml`, so no built-in file leaks through.

2. **Given** the skill auto-discovers the next story to develop,
   **When** no explicit `story_path` is provided and `sprint-status.yaml` exists,
   **Then** the skill searches for the first item with `status: ready-for-dev` by checking:
     - All sprint `items` arrays (sprints with `status: active` first, then `planning`), then
     - The `backlog` array,
   **And** the first match becomes the story to develop,
   **And** items in `closed` sprints are skipped.

3. **Given** a developer starts working on a story via `bmad-dev-story`,
   **When** the story transitions from `ready-for-dev` to `in-progress`,
   **Then** the skill finds the item by its `id` field in `sprint-status.yaml` (searching both `backlog` array and all `sprints[].items` arrays),
   **And** updates the item's `status` field in-place to `in-progress` (FR135),
   **And** all other fields on the item (`id`, `type`, `epic`, `title`, `priority`, `severity`) are preserved,
   **And** all other sections of `sprint-status.yaml` are preserved,
   **And** the `last_updated` metadata field is updated to the current ISO-8601 timestamp.

4. **Given** a developer completes story implementation and all tasks pass,
   **When** the story transitions to `review`,
   **Then** the status is updated in-place to `review` in whichever section the item currently resides,
   **And** the same preservation guarantees from AC 3 apply.

5. **Given** the story ID is not found in any section of `sprint-status.yaml`,
   **When** the skill attempts to update status,
   **Then** it checks the `done/` archive folder for a file matching `{story_location}/done/{story_key}.md`,
   **And** if found in `done/`, reports: "Story {id} has been archived (done). It cannot be developed again without manual re-introduction to the backlog.",
   **And** if not found anywhere, reports: "Story {id} not found in sprint-status.yaml. It may not yet have been added to the backlog. Run sprint planning or generate-backlog first."

6. **Given** the developer story execution workflow (task sequencing, red-green-refactor, definition of done, review continuation),
   **When** the skill executes,
   **Then** ALL non-status-related workflow behavior is preserved unchanged from the built-in,
   **And** only the sprint-status discovery and status update mechanisms are modified.

7. **Given** this skill is tightly coupled to the BMAD methodology workflow (config loading from `_bmad/bmm/config.yaml`, BMAD-specific agent context, multi-step execution workflow with critical directives),
   **When** the implementation decision is made about IDE skill creation,
   **Then** NO standalone IDE skill is created in `skills/bmad-dev-story/`,
   **And** this decision is documented: the skill requires BMAD agent context (config resolution, skill delegation patterns, workflow XML semantics) that non-BMAD IDE agents cannot provide.

## Agent Discussion: IDE Skill Decision

**Winston (Architect):** `bmad-dev-story` is fundamentally different from sprint management skills like `add-to-sprint` or `generate-backlog`. Those skills perform a discrete operation on `sprint-status.yaml` that any agent can invoke. `bmad-dev-story` is an entire developer execution workflow -- it loads BMAD config, delegates to a workflow.md file, uses XML workflow semantics with `<step>`, `<check>`, `<critical>`, `<goto>` directives, and references BMAD-specific paths (`_bmad/bmm/config.yaml`). Non-BMAD agents wouldn't know how to execute this workflow format. The IDE skill pipeline (`lib/installer.js`) deploys flat SKILL.md files -- it doesn't handle multi-file workflow delegation.

**John (PM):** The acceptance criteria need to be clear that we are NOT creating an IDE skill. The user story is about the developer's workflow within the BMAD ecosystem. Developers using non-BMAD agents (pure Claude Code, Cursor without BMAD) wouldn't invoke this skill -- they'd either use `bmad-quick-dev` or implement stories manually. The BMAD extension override is the only deployment target.

**Mary (Analyst):** The PRD (FR135) says "Each item carries its own status field, updated in-place within the section where it resides." This requirement applies to the status update mechanism, not to which deployment pipeline delivers it. The skill's core value (in-place status update across sections) is correctly scoped to the BMAD extension override. No PRD requirement mandates IDE-agent availability for the dev story execution workflow. Agreed: BMAD extension only.

**Decision: BMAD extension override only. No IDE skill.**

## Tasks / Subtasks

### Task 1: Read and understand the built-in skill files (AC: 1, 6)

Before writing replacement files, study the three built-in files that the extension override must replace.

- [x] 1.1 Read `node_modules/bmad-method/src/bmm-skills/4-implementation/bmad-dev-story/SKILL.md` -- note: a thin entry point that delegates to `./workflow.md`
- [x] 1.2 Read `node_modules/bmad-method/src/bmm-skills/4-implementation/bmad-dev-story/workflow.md` -- the main implementation (~450 lines). Document:
  - INITIALIZATION section: config loading from `_bmad/bmm/config.yaml`, variable resolution
  - Step 1 (`tag="sprint-status"`): story discovery via `development_status` flat map with key pattern matching
  - Step 4 (`tag="sprint-status"`): mark story `in-progress` by writing `development_status[story_key] = "in-progress"`
  - Step 9 (`tag="sprint-status"`): mark story `review` by writing `development_status[story_key] = "review"`
  - Identify all `development_status` references (at least Steps 1, 4, 9)
- [x] 1.3 Read `node_modules/bmad-method/src/bmm-skills/4-implementation/bmad-dev-story/checklist.md` -- the definition-of-done checklist. Document which items reference sprint status (the "Sprint Status Updated" item in the Final Status Verification section)
- [x] 1.4 Create a change inventory: list every section/line in `workflow.md` that reads or writes `development_status` or references the flat map format. These are the surgical change points.

### Task 2: Create the BMAD extension override directory and manifest (AC: 1)

The extension override MUST provide replacements for ALL three built-in files plus a manifest.

- [x] 2.1 Create `lib/bmad-extension/skills/bmad-dev-story/bmad-skill-manifest.yaml`:
  ```yaml
  type: skill
  name: bmad-dev-story
  module: ma-skills
  ```

- [x] 2.2 Create `lib/bmad-extension/skills/bmad-dev-story/SKILL.md` -- override of the built-in SKILL.md. Preserve the same delegation pattern:
  ```markdown
  ---
  name: bmad-dev-story
  description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan"'
  ---

  Follow the instructions in ./workflow.md.
  ```

### Task 3: Rewrite story auto-discovery in workflow.md Step 1 (AC: 2)

The current Step 1 discovers the next story by scanning `development_status` keys. Replace with unified schema search.

- [x] 3.1 Replace the `development_status` flat-map parsing in Step 1 with a cross-section search:
  - Read and parse `sprint-status.yaml` fully (preserve all content for later write-back)
  - Search `sprints` map: for each sprint (prefer `active` sprints first, then `planning`; skip `closed`), iterate its `items` array looking for items with `status: ready-for-dev`
  - If not found in any sprint, search the `backlog` array for items with `status: ready-for-dev`
  - The first match (sprint items prioritized over backlog) becomes the story to develop
- [x] 3.2 When a story is found, extract its `id` as the `story_key` and record its location context:
  - If found in a sprint: `"in {sprint-id}"` (e.g., `"in sprint-3"`)
  - If found in backlog: `"in backlog (unassigned)"`
- [x] 3.3 Remove the old key-pattern matching logic (distinguishing epics from stories by key format like `number-number-name`). The unified schema uses the `type` field (`story` or `bug`) on each item explicitly -- no pattern matching needed.
- [x] 3.4 Update the "no ready-for-dev story found" output message to reference the unified schema:
  ```
  No ready-for-dev stories found in sprint-status.yaml.

  Current Sprint Status: {summary of active/planning sprints and backlog item count}

  What would you like to do?
  1. Run `create-story` to create next story from epics
  2. Run `*validate-create-story` to improve existing stories
  3. Specify a particular story file to develop (provide full path)
  4. Check sprint-status.yaml to see current sprint status
  ```
- [x] 3.5 Preserve the explicit `story_path` branch (when user provides a path directly) -- this code path does NOT read `sprint-status.yaml` for discovery and needs no change.
- [x] 3.6 Preserve the non-sprint discovery fallback (when `sprint-status.yaml` does not exist) -- search implementation artifacts for story files directly. This code path needs no change.

### Task 4: Rewrite status update in workflow.md Step 4 (AC: 3)

Step 4 marks the story `in-progress`. Replace the flat-map write with in-place item update.

- [x] 4.1 Replace the `development_status[story_key]` lookup with a cross-section search by item `id`:
  - Search `backlog` array: iterate items, match `item.id == story_key`
  - Search all `sprints` map entries: iterate each sprint's `items` array, match `item.id == story_key`
- [x] 4.2 When the item is found, update its `status` field in-place to `"in-progress"`
- [x] 4.3 Preserve ALL other fields on the item (`id`, `type`, `epic`, `title`, `priority` if in backlog, `severity`)
- [x] 4.4 Preserve ALL other sections and items in `sprint-status.yaml` (read-modify-write pattern)
- [x] 4.5 Update the `last_updated` metadata field to the current ISO-8601 timestamp
- [x] 4.6 If the item is not found, invoke the not-found handling (see Task 6)
- [x] 4.7 Include location context in the status output:
  ```
  Starting work on story {story_key} ({location_context})
  Status updated: ready-for-dev -> in-progress
  ```
  where `{location_context}` is e.g., "in sprint-3" or "in backlog"

### Task 5: Rewrite status update in workflow.md Step 9 (AC: 4)

Step 9 marks the story `review` on completion. Apply the same in-place pattern.

- [x] 5.1 Replace the `development_status[story_key] = "review"` write with a cross-section search by item `id` (same pattern as Task 4)
- [x] 5.2 Update the item's `status` field in-place to `"review"`
- [x] 5.3 Apply the same preservation guarantees (all other fields, all other sections, `last_updated` update)
- [x] 5.4 If the item is not found, report a warning but do NOT block completion:
  ```
  Story file updated to "review", but sprint-status.yaml update failed: {story_key} not found.
  Sprint-status.yaml may be out of sync.
  ```
- [x] 5.5 Include location context in the success output:
  ```
  Story status updated to "review" in sprint-status.yaml ({location_context})
  ```

### Task 6: Implement not-found handling (AC: 5)

- [x] 6.1 When the story `id` is not found in any section of `sprint-status.yaml`, check for a file at `{story_location}/done/{story_key}.md`
- [x] 6.2 If found in `done/`, report: "Story {id} has been archived (done). It cannot be developed again without manual re-introduction to the backlog."
- [x] 6.3 If not found anywhere, report: "Story {id} not found in sprint-status.yaml. It may not yet have been added to the backlog. Run sprint planning or generate-backlog first."
- [x] 6.4 In Step 4 (marking in-progress), this is a HALT condition -- the developer cannot proceed without status tracking.
- [x] 6.5 In Step 9 (marking review), this is a WARNING -- the story file itself still gets updated to "review" even if sprint-status update fails.

### Task 7: Update the checklist.md override (AC: 1, 6)

- [x] 7.1 Create `lib/bmad-extension/skills/bmad-dev-story/checklist.md` -- copy of the upstream checklist with one change:
  - In the "Final Status Verification" section, update the "Sprint Status Updated" item description from referencing the flat `development_status` map to: "Sprint status updated to 'review' in sprint-status.yaml (item found by id in backlog or sprint items)"
- [x] 7.2 Preserve all other checklist items unchanged -- they validate story implementation quality, not sprint-status schema format

### Task 8: Register the extension override in module-help.csv (AC: 1)

- [x] 8.1 Add a row to `lib/bmad-extension/module-help.csv`:
  ```csv
  ma-skills,4-implementation,Dev Story,bmad-dev-story,,skill:bmad-dev-story,bmad-dev-story,false,bmm-dev,,"Execute story implementation following a context filled story spec file.",_bmad-output/implementation-artifacts,"story implementation",
  ```
  The `agent` column is `bmm-dev` (Developer) because story execution is a Developer responsibility.

### Task 9: Remove legacy flat-map references from the workflow (AC: 3, 4, 6)

- [x] 9.1 Verify that NO references to `development_status` remain in the override `workflow.md` after Tasks 3-5
- [x] 9.2 Verify that NO key-pattern matching logic (distinguishing epics from stories by key format) remains -- the `type` field on items replaces this
- [x] 9.3 Verify that the `tag="sprint-status"` attribute on Steps 1, 4, and 9 is preserved -- other skills may reference these step tags for cross-skill awareness
- [x] 9.4 Verify that the sprint status summary display (in the "no ready-for-dev" output) uses the new schema sections rather than the flat map

### Task 10: Deployment verification (AC: 1)

- [x] 10.1 Run `npx ma-agents` (or `node lib/cli.js`) to trigger the installer
- [x] 10.2 Verify the BMAD extension override exists at `_bmad/extensions/ma-agents-skills/skills/bmad-dev-story/` after deployment, containing all four files (`SKILL.md`, `workflow.md`, `checklist.md`, `bmad-skill-manifest.yaml`)
- [x] 10.3 Verify the override takes precedence: the deployed `workflow.md` should contain cross-section search logic (references to `backlog` array and `sprints[].items`), NOT the flat `development_status` map
- [x] 10.4 Verify `bmad-dev-story` appears in the BMAD module help output
- [x] 10.5 Verify that NO `skills/bmad-dev-story/` directory exists in the IDE skill sources (`skills/` directory) -- confirming the IDE-skill-exclusion decision
- [x] 10.6 Verify the built-in at `node_modules/bmad-method/src/bmm-skills/4-implementation/bmad-dev-story/` is UNTOUCHED

## Dev Notes

### CRITICAL: Extension Override for Built-in Skill (Read This First)

`bmad-dev-story` is a **BMAD built-in skill** shipped by `bmad-method` at `node_modules/bmad-method/src/bmm-skills/4-implementation/bmad-dev-story/`. Per project policy (MEMORY: `feedback_bmad_builtin_override.md`), all changes to built-in skills MUST be done as extension overrides in `lib/bmad-extension/skills/`, never as upstream modifications.

The built-in contains **three files**:
1. `SKILL.md` -- thin entry point that delegates to `./workflow.md`
2. `workflow.md` -- main implementation (~450 lines, 10-step workflow with XML semantics)
3. `checklist.md` -- definition-of-done validation checklist

The extension override MUST provide replacements for ALL three files plus a `bmad-skill-manifest.yaml`. When `lib/bmad-extension/skills/` has a skill with the same name as a built-in, the extension takes precedence via the `--custom-content` deployment flag in `lib/bmad.js`.

### Why No IDE Skill

Unlike other Epic 17 skills (e.g., `generate-backlog`, `add-to-sprint`, `bmad-sprint-planning`) which perform discrete operations that any IDE agent can invoke, `bmad-dev-story` is an entire multi-step developer execution workflow that:

1. **Loads BMAD config** from `_bmad/bmm/config.yaml` (resolves `project_name`, `user_name`, `communication_language`, `user_skill_level`, etc.)
2. **Uses XML workflow semantics** (`<workflow>`, `<step>`, `<check>`, `<critical>`, `<goto>`, `<anchor>`) that are specific to the BMAD agent execution model
3. **Delegates to auxiliary files** (`./workflow.md`, `./checklist.md`) using BMAD's multi-file skill pattern
4. **Enforces BMAD execution directives** (no session pausing, continuous execution until HALT, red-green-refactor cycle)

Non-BMAD IDE agents (pure Claude Code, Cursor without BMAD, etc.) cannot execute this workflow format. The IDE skill pipeline (`lib/installer.js`) deploys flat `SKILL.md` files and does not support multi-file workflow delegation. Developers using non-BMAD agents would use `bmad-quick-dev` or implement stories manually.

### Scope of Changes -- Surgical, Not Full Rewrite

This is NOT a rewrite of the entire `bmad-dev-story` workflow. The developer execution workflow (task sequencing, red-green-refactor, definition of done, review continuation, etc.) remains unchanged. Only three aspects change:

1. **Story auto-discovery (Step 1):** Replace flat `development_status` key scan with cross-section search of `backlog` + `sprints[].items` arrays
2. **Status update to in-progress (Step 4):** Replace `development_status[key] = "in-progress"` with in-place update on the item object found by `id`
3. **Status update to review (Step 9):** Replace `development_status[key] = "review"` with in-place update on the item object found by `id`

Everything else in the 450-line workflow.md is preserved verbatim.

### Cross-Section Search Pattern

The search pattern is consistent with Story 17.19 (`story-status-lookup`):

```
function findItemById(sprintStatus, storyKey):
  // Search sprints first (active > planning; skip closed)
  for each sprint in sprints (sorted: active first, then planning):
    if sprint.status == "closed": skip
    for each item in sprint.items:
      if item.id == storyKey:
        return { item, location: "in {sprint-id}" }

  // Then search backlog
  for each item in backlog:
    if item.id == storyKey:
      return { item, location: "in backlog" }

  // Not found
  return null
```

For auto-discovery (Step 1), the search looks for `status: ready-for-dev` instead of matching by `id`. Active sprint items are prioritized over planning sprint items, which are prioritized over backlog items.

### In-Place Update Pattern

The status update follows the schema's in-place update rule (Section 6.2):

```
function updateItemStatus(sprintStatus, storyKey, newStatus):
  result = findItemById(sprintStatus, storyKey)
  if result is null:
    return checkDoneArchive(storyKey)  // fallback

  result.item.status = newStatus      // only status changes
  sprintStatus.last_updated = now()   // update timestamp
  writeFile(sprintStatus)             // atomic write, preserving all structure
```

### Workflow.md Change Points (Detailed)

**Step 1 (tag="sprint-status") -- Story Discovery:**
- CURRENT: Reads `development_status` section, iterates keys, uses regex to distinguish epics (`epic-X`) from stories (`N-M-name`), finds first `ready-for-dev`
- NEW: Reads full file, searches `sprints[].items` (active first, then planning) then `backlog` array for items with `status: ready-for-dev`
- PRESERVE: The `story_path` branch (explicit path), the non-sprint fallback (no `sprint-status.yaml`), the user prompting for options

**Step 4 (tag="sprint-status") -- Mark In-Progress:**
- CURRENT: `development_status[story_key] = "in-progress"`
- NEW: Find item by `id` across sections, update `status` in-place to `"in-progress"`, update `last_updated`
- PRESERVE: The `sprint_status` file existence check, the "already in-progress" detection, the "unexpected status" warning

**Step 9 (tag="sprint-status") -- Mark Review:**
- CURRENT: `development_status[story_key] = "review"`
- NEW: Find item by `id` across sections, update `status` in-place to `"review"`, update `last_updated`
- PRESERVE: The `sprint_status` file existence check, the "key not found" warning behavior, the "no sprint tracking" fallback

### Unified Schema Sections Touched

- **`backlog`** -- searched for story by `id`; `status` may be updated in-place
- **`sprints`** -- all sprint entries' `items` arrays are searched; `status` may be updated in-place
- **`epics`** -- NOT modified, but MUST be preserved during read-modify-write
- **Metadata** -- `last_updated` is updated on every write

### Reference Files

- **Built-in source:** `node_modules/bmad-method/src/bmm-skills/4-implementation/bmad-dev-story/` (SKILL.md, workflow.md, checklist.md)
- **Schema:** `_bmad-output/planning-artifacts/sprint-status-schema.md` (canonical schema for sprint-status.yaml)
- **Sprint status:** `_bmad-output/implementation-artifacts/sprint-status.yaml`
- **Done archive:** `_bmad-output/implementation-artifacts/done/`
- **BMAD skill reference:** `lib/bmad-extension/skills/add-to-sprint/` (SKILL.md + bmad-skill-manifest.yaml pattern)
- **Built-in override reference:** Story 17.15 (`bmad-sprint-planning`) -- same override pattern for a BMAD built-in
- **Module help CSV:** `lib/bmad-extension/module-help.csv`

### Cross-References

- **Story 17.9** (prerequisite, done): Defines the unified `sprint-status.yaml` schema this skill operates on
- **Story 17.15** (parallel): `bmad-sprint-planning` -- same built-in override pattern; reference for how to structure the extension override with multiple files
- **Story 17.19** (parallel): `story-status-lookup` -- same cross-section search pattern for finding items by `id`
- **Story 17.14** (downstream): `cleanup-done` -- handles archival of done items after this skill might set status to done (though currently the workflow only sets `in-progress` and `review`)
- **Story 17.21** (downstream): `close-sprint` -- may also update item statuses during sprint closure

### PRD Traceability

- **FR135:** "Each item carries its own status field, updated in-place within the section where it resides" -- this is the core requirement being implemented. The status update in Steps 4 and 9 now operates on item objects within the unified schema rather than on flat map keys.
- **FR65:** "All sprint, backlog, and epic status data is managed in a single sprint-status.yaml" -- the skill now reads from and writes to the unified three-section file.
- **FR134:** "Each item carries a consistent structure (id, type, epic, title, priority, status, severity)" -- the cross-section search matches items by their `id` field and preserves all other fields during status update.

### Architecture Reference

- Architecture Decision P2-11 in `_bmad-output/planning-artifacts/architecture.md` -- Unified Sprint-Status Data Architecture
- Architecture P2-5 in `_bmad-output/planning-artifacts/architecture.md` -- Pre-built Extension Workflows (deployment via `--custom-content`)
- Skill Integration Map in architecture doc -- `bmad-dev-story` is listed as "Moderate" rework, operating on `backlog:` or `sprints:` sections

### Gotchas and Warnings

1. **The workflow.md is large (~450 lines).** The override must be a complete copy with targeted edits to Steps 1, 4, and 9. Do NOT accidentally omit any steps or directives.
2. **XML workflow semantics** (`<workflow>`, `<step>`, `<check>`, `<critical>`, `<goto>`, `<anchor>`) must be preserved exactly. These are interpreted by the BMAD agent runtime.
3. **Step tags** (`tag="sprint-status"` on Steps 1, 4, 9) may be referenced by other skills for cross-skill awareness. Preserve these attributes.
4. **Review continuation logic** (Step 3) is unrelated to sprint-status and must be preserved unchanged.
5. **The checklist.md changes are minimal** -- only one line in the "Final Status Verification" section references sprint status format. All other items validate story implementation quality.
6. **Config variable resolution** (`{implementation_artifacts}`, `{sprint_status}`, etc.) must be preserved exactly as the built-in defines them.
7. **The `development_status` parsing in the current Step 1 uses key patterns to distinguish epics from stories.** The unified schema makes this distinction explicit via the `type` field on each item, so the pattern-matching logic is no longer needed and should be removed.

## Dev Agent Record

### Agent Model Used

claude-sonnet-4-6

### Debug Log References

None — implementation was straightforward surgical edit to the built-in workflow.

### Completion Notes List

- Read all three built-in files (`SKILL.md`, `workflow.md`, `checklist.md`) to understand the existing workflow structure
- Identified three change points in `workflow.md`: Step 1 (discovery), Step 4 (mark in-progress), Step 9 (mark review)
- Created BMAD extension override in `lib/bmad-extension/skills/bmad-dev-story/` with all four required files
- Step 1 rewritten: cross-section search (active sprints → planning sprints → backlog) replaces flat `development_status` key scan; `type` field replaces key pattern matching
- Step 4 rewritten: search by `item.id` across backlog and sprints; update status in-place; HALT on not-found (with done-archive check)
- Step 9 rewritten: same in-place update pattern; non-blocking warning on not-found
- `location_context` variable threaded through Steps 1→4→9 to show "in sprint-X" or "in backlog" in output
- Checklist "Sprint Status Updated" line updated to reference unified schema language
- `module-help.csv` row added for `bmad-dev-story` with agent `bmm-dev`
- Verified: zero `development_status` references in override `workflow.md`; all three `tag="sprint-status"` steps preserved; no IDE skill created; built-in untouched

### File List

- `lib/bmad-extension/skills/bmad-dev-story/bmad-skill-manifest.yaml` (created)
- `lib/bmad-extension/skills/bmad-dev-story/SKILL.md` (created)
- `lib/bmad-extension/skills/bmad-dev-story/workflow.md` (created)
- `lib/bmad-extension/skills/bmad-dev-story/checklist.md` (created)
- `lib/bmad-extension/module-help.csv` (modified — added bmad-dev-story row)
- `_bmad-output/implementation-artifacts/sprint-status.yaml` (modified — 17-18 marked in-progress then review)
- `_bmad-output/implementation-artifacts/17-18-rework-bmad-dev-story.md` (modified — tasks checked, status updated)

## Change Log

- 2026-04-06: Implemented Story 17.18 — created BMAD extension override for `bmad-dev-story` skill. Replaced flat `development_status` map operations in Steps 1, 4, and 9 with cross-section item search and in-place status update on the unified `sprint-status.yaml` schema (backlog array + sprints[].items arrays).
