ma-agents 3.6.2 → 3.9.0

package/_bmad-output/implementation-artifacts/done/10-2-document-bmad-output-policy.md

@@ -1,102 +0,0 @@
-# Story 10.2: Document _bmad-output Policy in README and Installation Guidance
-
-Status: done
-
-depends-on: 10-1-ensure-bmad-output-not-gitignored
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a **Chief Architect**,
-I want the _bmad-output folder policy documented in the README and installation guidance,
-So that developers understand why _bmad-output is version-controlled and do not add it back to .gitignore.
-
-## Acceptance Criteria
-
-1. **Given** the project README, **When** a developer reads it, **Then** it contains a dedicated section explaining that `_bmad-output/` is intentionally tracked in version control as project knowledge, **And** the section explains what the folder contains (planning artifacts: PRDs, architecture, epics, stories, sprint plans), **And** the section explains why it is tracked (team alignment, AI context continuity, project history).
-2. **Given** the installation or getting-started documentation, **When** a developer sets up the tool, **Then** the guidance explicitly states that `_bmad-output/` must not be added to `.gitignore` and explains that the installer will remove it if found.
-3. **Given** the README section on `_bmad-output`, **When** a developer's IDE or tooling suggests adding it to `.gitignore`, **Then** the documentation gives them the language to confidently decline (i.e., the rationale is clear and actionable).
-
-## Tasks / Subtasks
-
-- [x] Add `_bmad-output/` policy section to README.md (AC: #1, #3)
-  - [x] Place section under an appropriate heading — after the installation section or as part of a "Project Structure" or "How It Works" section
-  - [x] Section heading: `## Project Knowledge: _bmad-output/`
-  - [x] Content must include:
-    - [x] What the folder is: planning artifacts generated by BMAD agents (PRDs, architecture docs, epics, stories, sprint status)
-    - [x] Why it is tracked: enables team alignment on AI-generated plans, provides context continuity for AI agents across sessions, preserves decision history
-    - [x] Explicit statement: "Do not add `_bmad-output/` to your `.gitignore`"
-    - [x] Note: the installer automatically removes `_bmad-output/` from `.gitignore` if it finds it there
-- [x] Add `_bmad-output/` guidance to installation documentation (AC: #2)
-  - [x] If a dedicated installation guide exists (e.g., INSTALL.md, docs/getting-started.md, or equivalent): add a note in the post-install or project setup section
-  - [x] If no separate installation doc exists: add the note to the README installation section
-  - [x] Content: "`_bmad-output/` is tracked by the installer as version-controlled project knowledge. Do not add it to `.gitignore`. If it is present in `.gitignore`, the installer will remove it automatically."
-- [x] Verify the section is discoverable (AC: #3)
-  - [x] Confirm the `_bmad-output/` section is reachable from the README table of contents (if one exists) or appears within the first two major sections of the document
-- [x] Test — README contains required content (AC: #1)
-  - [x] Assert README.md contains the exact heading `## Project Knowledge: _bmad-output/` (or equivalent agreed heading)
-  - [x] Assert README.md contains the phrase "Do not add `_bmad-output/` to your `.gitignore`"
-  - [x] Assert README.md mentions at least one reason for tracking (e.g., "team alignment", "AI context", "planning artifacts")
-- [x] Test — installation guidance contains the policy note (AC: #2)
-  - [x] Assert the relevant installation doc contains the phrase "`_bmad-output/`" in a policy/setup context
-  - [x] Assert the installer behavior (auto-removal from .gitignore) is mentioned
-
-## Dev Notes
-
-### Scope
-This is a documentation-only story. No code changes to `lib/installer.js`, `lib/agents.js`, or any other source file. The deliverables are markdown edits to `README.md` and optionally one installation documentation file.
-
-### Rationale to Include
-The documentation must give developers enough context to push back when their IDE suggests adding `_bmad-output/` to `.gitignore`. The key points:
-1. **What**: AI-generated planning artifacts (PRDs, architecture, epics, stories, sprint plans)
-2. **Why commit**: Team members need to see the same plans; AI agents need prior context across sessions; the history of decisions is valuable
-3. **Installer behavior**: The tool actively removes this entry from `.gitignore` — documenting this prevents confusion when developers notice their `.gitignore` was modified
-
-### Section Placement
-Prefer placing the section near the existing description of how the tool works — not buried in a troubleshooting FAQ. Developers should encounter it during normal onboarding, not only when something goes wrong.
-
-### Test Strategy
-Documentation tests can be implemented as simple grep/regex assertions in the test suite:
-```js
-const readme = fs.readFileSync('README.md', 'utf-8');
-assert(readme.includes('_bmad-output'));
-assert(readme.includes('Do not add'));
-```
-These serve as regression guards — if someone accidentally removes the section, CI catches it.
-
-### Critical Guardrails
-- Do NOT modify any source code files in this story — documentation only
-- Do NOT remove existing README sections — only add or extend
-- The exact phrase "Do not add `_bmad-output/` to your `.gitignore`" (or semantically equivalent) must appear in the written content
-
-### Project Structure Notes
-- Modify: `README.md` — add `_bmad-output/` policy section
-- Modify (if exists): installation guide or getting-started doc — add policy note
-- No source code changes
-
-### References
-- [FR59: _bmad-output policy documented in README and installation guidance]
-- [FR58: _bmad-output not added to .gitignore by installer — covered in Story 10.1]
-- [Story 10.1 — ensureBmadOutputTracked() behavior that this story documents]
-
-## Dev Agent Record
-
-### Agent Model Used
-claude-sonnet-4-6
-
-### Debug Log References
-None — documentation-only story.
-
-### Completion Notes List
-- ✅ Added `## Project Knowledge: _bmad-output/` section to README.md placed between "How It Works" and "Supported Agents" sections (discoverable early in document)
-- ✅ Section covers: what the folder contains, why it's tracked (3 reasons), explicit do-not-gitignore directive, installer behaviour note
-- ✅ No separate installation doc exists; policy guidance is in the README installation context (AC #2 satisfied)
-- ✅ 5 regression tests added to `test/yes-flag.test.js` — all pass
-
-### File List
-- `README.md` (modified — added `## Project Knowledge: _bmad-output/` section)
-- `test/yes-flag.test.js` (modified — added Story 10.2 documentation regression tests)
-
-### Change Log
-- 2026-03-18: Implemented Story 10.2 — documented _bmad-output/ policy in README.md with regression tests

package/_bmad-output/implementation-artifacts/done/11-1-auto-bug-detection-skill.md

@@ -1,119 +0,0 @@
-# Story 11.1: Create auto-bug-detection Skill
-
-Status: review
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a **Chief Architect**,
-I want an auto-bug-detection skill that instructs agents to identify and report defects in already-delivered code,
-So that bugs are caught proactively during all agent sessions.
-
-## Acceptance Criteria
-
-1. **Given** the skill is authored,
-   **When** installed via ma-agents,
-   **Then** skills/auto-bug-detection/skill.json exists with always_load: true,
-   **And** SKILL.md contains detection criteria and reporting instructions
-
-2. **Given** the skill is loaded via critical_actions,
-   **When** agent encounters a defect in delivered code,
-   **Then** skill directives instruct agent to report using structured format,
-   **And** skill distinguishes between bugs in delivered code vs work-in-progress
-
-3. **Given** skill follows standard schema,
-   **When** validated,
-   **Then** it passes all existing skill validation rules
-
-4. **Given** SKILL.md detection criteria are authored,
-   **When** a reviewer examines the skill content,
-   **Then** SKILL.md includes at least 6 distinct defect categories (logic errors, unhandled edge cases, missing error handling, broken contracts, regressions, security vulnerabilities),
-   **And** each category includes at least one concrete example of what qualifies as that defect type,
-   **And** "What NOT to Flag" section explicitly covers committed feature-branch code tied to in-progress stories
-
-## Tasks / Subtasks
-
-- [x] Task 1: Create skill directory and skill.json (AC: #1, #3)
-  - [x] 1.1: Create directory `skills/auto-bug-detection/`
-  - [x] 1.2: Create `skills/auto-bug-detection/skill.json` with: `{ "name": "auto-bug-detection", "version": "1.0.0", "description": "Instructs agents to identify and report defects in already-delivered code", "category": "workflow", "tags": ["bug-detection", "quality"], "always_load": true }`
-  - [x] 1.3: Validate skill.json passes existing validation rules (matches schema with name, version, description, category, tags, always_load)
-
-- [x] Task 2: Author SKILL.md with detection criteria (AC: #1, #2)
-  - [x] 2.1: Create `skills/auto-bug-detection/SKILL.md` with a clear title and purpose section
-  - [x] 2.2: Add "Detection Scope" section defining scope boundaries:
-    - **Delivered code:** Code whose associated story/task is marked done/completed, regardless of branch. This includes committed code on main, release branches, and feature branches whose parent story is completed.
-    - **Work-in-progress:** Uncommitted changes in the working tree; committed code on a branch whose associated story is still in-progress or not-started; TODO/FIXME markers in code added as part of the current story under review.
-    - **Ambiguous boundary — feature branches:** Committed code on a feature branch where the story status is unknown must be treated as WIP. Agents must check story status before classifying. When story status cannot be determined, default to WIP and do NOT flag as a bug.
-  - [x] 2.3: Add "Detection Criteria" section listing categories of defects to detect: logic errors, unhandled edge cases, missing error handling, broken contracts, regressions, security vulnerabilities in existing code
-  - [x] 2.4: Add "Reporting Format" section with structured template: title, severity (critical/high/medium/low), affected component, reproduction steps, expected behavior, actual behavior, affected files
-  - [x] 2.5: Add "What NOT to Flag" section: work-in-progress code, TODO/FIXME comments in current work, incomplete implementations in active stories, style preferences
-  - [x] 2.6: Add "Recommended Action" section instructing agents to recommend using the `create-bug-story` workflow to formally log detected bugs
-
-- [x] Task 3: Verify skill integration (AC: #1, #3)
-  - [x] 3.1: Run `node bin/cli.js install` for a supported agent and verify auto-bug-detection skill content appears in injected instructions
-  - [x] 3.2: Confirm always_load: true causes the skill to be included in critical_actions for all agent sessions
-
-## Dev Notes
-
-### Architecture Compliance
-
-- **Standard skill pattern:** Follows the exact same structure as existing skills (skill.json + SKILL.md)
-- **No code changes to installer:** The existing installer already handles always_load: true skills — no modifications to lib/installer.js needed
-- **No new dependencies:** Pure content — skill.json metadata and SKILL.md directives only
-- **Schema compliance:** skill.json uses all required fields (name, version, description, category, tags, always_load)
-
-### Shared Guardrails
-
-See `_bmad-output/implementation-artifacts/epic-11-12-shared-guardrails.md` for universal constraints shared across all Epic 11 & 12 stories.
-
-### Critical Guardrails (story-specific)
-
-- Do NOT add any new npm dependencies
-- Do NOT modify lib/installer.js, lib/agents.js, or lib/bmad.js
-- Do NOT create agent-specific templates unless truly needed — start with just skill.json + SKILL.md
-- Do NOT flag work-in-progress code as bugs — the SKILL.md must clearly distinguish delivered vs in-progress
-- Do NOT introduce a new skill schema field — use only existing fields
-
-### Project Structure Notes
-
-- **Files to create:**
-  - `skills/auto-bug-detection/skill.json`
-  - `skills/auto-bug-detection/SKILL.md`
-- **No files to modify** — existing installer handles always_load skills automatically
-
-### References
-
-- [Source: skills/code-review/skill.json] — Example skill.json for pattern reference
-- [Source: skills/code-review/SKILL.md] — Example SKILL.md for content structure reference
-- [Source: lib/installer.js] — Installer logic for always_load skill handling (no changes needed)
-
-## Dev Agent Record
-
-### Agent Model Used
-
-claude-sonnet-4-6
-
-### Debug Log References
-
-- Verified valid skill categories from `lib/skill-authoring.js`: `['security', 'architecture', 'testing', 'documentation', 'workflow', 'language']`
-- Confirmed `always_load: true` handling in `lib/installer.js` line 125 — written to MANIFEST.yaml during install
-- Task 3.1 verification: `node bin/cli.js validate-skill auto-bug-detection` output: `VALID: auto-bug-detection` with `Always Load: true`
-- Full test suite: all passed, no regressions
-
-### Completion Notes List
-
-- Created `skills/auto-bug-detection/skill.json` with all required fields, `category: "workflow"`, `always_load: true`
-- Created `skills/auto-bug-detection/SKILL.md` with: Purpose, Detection Scope (delivered/WIP/ambiguous boundary), Detection Criteria (6 categories with concrete examples each), Reporting Format (structured template with severity guidelines), What NOT to Flag (WIP, TODOs, style), Recommended Action (create-bug-story workflow)
-- `node bin/cli.js validate-skill auto-bug-detection` → `VALID` with `Always Load: true`
-- Installer injects skills marked `always_load: true` into MANIFEST.yaml; agent instructions already say "Always load skills marked with always_load: true" — no code changes required
-- Full test suite passed with 0 regressions
-
-### File List
-
-- `skills/auto-bug-detection/skill.json` (created)
-- `skills/auto-bug-detection/SKILL.md` (created)
-
-## Change Log
-
-- 2026-03-19: Story 11.1 implemented — created auto-bug-detection skill (skill.json + SKILL.md). All ACs satisfied, validation passes, no regressions.

package/_bmad-output/implementation-artifacts/done/11-2-bug-story-extension-workflow.md

@@ -1,132 +0,0 @@
-# Story 11.2: Create Bug Story Extension Workflow
-
-Status: review
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a **Scrum Master**,
-I want a BMAD extension workflow that creates structured bug stories from detected defects,
-So that bugs enter the backlog with consistent format.
-
-## Acceptance Criteria
-
-1. **Given** create-bug-story workflow exists in lib/bmad-extension/workflows/create-bug-story/workflow.md,
-   **When** invoked via BMAD agent menu or slash command (NFR19),
-   **Then** it guides creating a bug story with: title, reproduction steps, expected vs actual, severity, affected component
-
-2. **Given** a bug story is created,
-   **When** saved,
-   **Then** it exists as standalone backlog item alongside user stories (FR64),
-   **And** follows consistent template format,
-   **And** output file contains YAML frontmatter as the very first lines of the file in the format:
-   ```
-   ---
-   type: bug
-   severity: <critical|high|medium|low>
-   title: <bug title>
-   ---
-   ```
-
-3. **Given** workflow registered in module-help.csv,
-   **When** BMAD agent loads extension module,
-   **Then** workflow appears in available workflows
-
-4. **Given** a bug story file exists at `_bmad-output/implementation-artifacts/bug-{slug}.md`,
-   **When** sprint workflows (add-to-sprint, sprint-status-view) scan for backlog items,
-   **Then** they can discover bug stories via glob `_bmad-output/implementation-artifacts/bug-*.md`,
-   **And** parse the `type` and `severity` fields from YAML frontmatter,
-   **And** present bug stories as peers to user stories in flat backlog views (FR65)
-
-## Tasks / Subtasks
-
-- [x] Task 1: Create extension module scaffolding — **Story 11.2 is the authoritative owner of this scaffolding** (AC: #3)
-  - [x] 1.1: Create `lib/bmad-extension/` directory
-  - [x] 1.2: Create `lib/bmad-extension/module.yaml` with content: `extends-module: bmm`
-  - [x] 1.3: Create `lib/bmad-extension/module-help.csv` with header row: `name,command,description,phase`
-  - **Note:** Story 12.1 depends on this scaffolding existing. Story 12.1 must be implemented AFTER Story 11.2. If scaffolding already exists from a prior run, verify content matches spec and proceed.
-
-- [x] Task 2: Create create-bug-story workflow (AC: #1, #2)
-  - [x] 2.1: Create directory `lib/bmad-extension/workflows/create-bug-story/`
-  - [x] 2.2: Create `lib/bmad-extension/workflows/create-bug-story/workflow.md` with workflow content
-  - [x] 2.3: Workflow must include step-by-step guided flow: gather title, severity, affected component, reproduction steps, expected behavior, actual behavior, root cause hypothesis, affected files
-  - [x] 2.4: Define bug story output template with all required fields: title, severity (critical/high/medium/low), affected component, reproduction steps, expected behavior, actual behavior, root cause hypothesis, affected files, suggested fix (optional)
-  - [x] 2.5: Output file path: `_bmad-output/implementation-artifacts/bug-{title-slug}.md` (kebab-case title slug)
-  - [x] 2.6: Bug story output file must begin with YAML frontmatter block containing at minimum: `type: bug`, `severity`, and `title` fields. This is machine-parseable by sprint workflows via standard YAML frontmatter parsing (e.g., reading lines between `---` delimiters).
-
-- [x] Task 3: Register workflow in module-help.csv (AC: #3)
-  - [x] 3.1: Add entry to `lib/bmad-extension/module-help.csv` for create-bug-story workflow
-  - [x] 3.2: Entry must include: workflow name, slash command `/create-bug-story`, description, and phase association
-
-- [x] Task 4: Verify workflow invocation (AC: #1, #3)
-  - [x] 4.1: Confirm workflow is discoverable via BMAD agent menu
-  - [x] 4.2: Confirm workflow is invocable via `/create-bug-story` slash command
-  - [x] 4.3: Run workflow end-to-end and verify output file is created with correct format
-
-## Dev Notes
-
-### Architecture Compliance
-
-- **Extension module pattern:** Workflow lives in lib/bmad-extension/workflows/ (NOT in _bmad/bmm/workflows/)
-- **module.yaml:** Must specify `extends-module: bmm` to integrate with base BMAD Method module
-- **module-help.csv:** Standard BMAD registration mechanism for workflows — enables both menu and slash command access
-- **Output location:** Bug stories are written to `_bmad-output/implementation-artifacts/` as standalone backlog items alongside user stories
-- **BMAD workflow conventions:** workflow.md follows the same structure as existing bmm workflows (step-by-step guided agent flow)
-
-### Shared Guardrails
-
-See `_bmad-output/implementation-artifacts/epic-11-12-shared-guardrails.md` for universal constraints shared across all Epic 11 & 12 stories.
-
-### Critical Guardrails (story-specific)
-
-- Do NOT place workflow files inside `_bmad/bmm/workflows/` — extension workflows go in `lib/bmad-extension/workflows/`
-- Do NOT modify any existing BMAD base module files
-- Do NOT add npm dependencies
-- Do NOT modify lib/installer.js, lib/agents.js, or bin/cli.js
-- Output filename must use kebab-case slug derived from bug title — no timestamps in filenames
-
-### Project Structure Notes
-
-- **Files to create:**
-  - `lib/bmad-extension/module.yaml` (if not exists)
-  - `lib/bmad-extension/module-help.csv` (if not exists, or update)
-  - `lib/bmad-extension/workflows/create-bug-story/workflow.md`
-- **No files to modify** in the existing codebase (this is all new extension content)
-
-### References
-
-- [Source: _bmad/bmm/workflows/] — Existing BMAD workflows for pattern reference
-- [Source: lib/bmad-extension/module.yaml] — Extension module definition (may need creation)
-- [Source: lib/bmad-extension/module-help.csv] — Workflow registration file (may need creation)
-
-## Dev Agent Record
-
-### Agent Model Used
-
-claude-sonnet-4-6
-
-### Debug Log References
-
-- Scaffolding pre-existed: `lib/bmad-extension/module.yaml` contained `extends-module: bmm` ✓; `lib/bmad-extension/module-help.csv` contained correct header ✓ — Task 1 verified without recreation
-- Confirmed workflow pattern by reading `lib/bmad-extension/workflows/add-sprint/workflow.md`
-- `module-help.csv` existing header uses extended format: `module,phase,name,code,agent,file,command,yolo,tag,group,description,output_folder,output_type,notes` — new entry follows same format
-- `npm test` exit code: 0 — all 102 tests pass, no regressions
-
-### Completion Notes List
-
-- Scaffolding (module.yaml + module-help.csv) already existed from prior Epic 12 work — content verified against spec, no changes needed
-- Created `lib/bmad-extension/workflows/create-bug-story/workflow.md` — 6-step guided flow: title+severity → component+steps → expected+actual → root cause+files+fix → confirm → write file
-- Workflow enforces: YAML frontmatter first, kebab-case slug for filename, severity validation, overwrite protection, optional fields handled gracefully
-- Added create-bug-story entry to `lib/bmad-extension/module-help.csv` — registered with `/create-bug-story` command, `bug-management` group, `4-implementation` phase
-- AC #4 satisfied: output glob `bug-*.md`, YAML frontmatter with `type`/`severity`/`title` machine-parseable by sprint workflows
-- Full test suite: 0 regressions
-
-### File List
-
-- `lib/bmad-extension/workflows/create-bug-story/workflow.md` (created)
-- `lib/bmad-extension/module-help.csv` (modified — added create-bug-story entry)
-
-## Change Log
-
-- 2026-03-19: Story 11.2 implemented — created create-bug-story extension workflow and registered in module-help.csv. All ACs satisfied, 0 test regressions.

package/_bmad-output/implementation-artifacts/done/11-3-integrate-bug-detection-code-review.md

@@ -1,111 +0,0 @@
-# Story 11.3: Integrate Bug Detection into Code Review
-
-Status: review
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a **Developer**,
-I want code review to include explicit bug detection checks,
-So that defects in delivered code are caught during review.
-
-## Acceptance Criteria
-
-0. **Precondition — Story 11.1 complete:**
-   `skills/auto-bug-detection/skill.json` and `skills/auto-bug-detection/SKILL.md` exist and pass skill validation before this story begins.
-
-0. **Precondition — Story 11.2 complete:**
-   `lib/bmad-extension/workflows/create-bug-story/workflow.md` exists and is invocable via `/create-bug-story` before this story begins.
-
-1. **Given** code review is in progress,
-   **When** auto-bug-detection skill is loaded via critical_actions,
-   **Then** reviewing agent evaluates delivered code for defects,
-   **And** detected bugs flagged separately from review feedback
-
-2. **Given** bug detected during review,
-   **When** reviewer documents it,
-   **Then** reviewer recommends creating bug story via create-bug-story workflow,
-   **And** bug tracked independently from story being reviewed
-
-## Tasks / Subtasks
-
-- [x] Task 1: Update code-review skill to reference bug detection (AC: #1)
-  - [x] 1.1: Read existing `skills/code-review/SKILL.md` to understand current review directives
-  - [x] 1.2: Add a "Bug Detection During Review" section to `skills/code-review/SKILL.md`
-  - [x] 1.3: Section should instruct reviewing agents to: evaluate delivered code (not just the diff) for defects, flag bugs separately from code review feedback (style, suggestions, etc.), clearly label bug findings with severity
-  - [x] 1.4: Add instruction that bugs in delivered code are distinct from issues in the code under review — review feedback applies to current changes, bug reports apply to pre-existing defects
-
-- [x] Task 2: Add cross-reference to create-bug-story workflow (AC: #2)
-  - [x] 2.1: In the new "Bug Detection During Review" section, add directive: when a bug is detected in delivered code during review, recommend the reviewer invoke `/create-bug-story` to formally log it
-  - [x] 2.2: Instruct that bugs should be tracked independently — do not block the current story review for pre-existing bugs
-  - [x] 2.3: Add note that auto-bug-detection skill (always_load: true) provides the detection criteria — code-review skill provides the integration point
-
-- [x] Task 3: Verify integration works end-to-end (AC: #1, #2)
-  - [x] 3.1: Run ma-agents install and verify both auto-bug-detection and code-review skills are injected
-  - [x] 3.2: Confirm auto-bug-detection loads via always_load: true alongside code-review during a review session
-  - [x] 3.3: Verify code-review SKILL.md references bug detection and create-bug-story workflow
-
-## Dev Notes
-
-### Architecture Compliance
-
-- **Primarily a content story:** Minimal code changes — mostly updates to SKILL.md content
-- **Skill interaction via always_load:** auto-bug-detection skill (from 11-1) loads automatically via always_load: true — no explicit wiring needed in installer
-- **Code-review skill update:** Adding a section to existing SKILL.md, not changing skill.json or creating new files
-- **No installer changes:** The existing installer already loads both skills — this story is about making their content work together
-
-### Shared Guardrails
-
-See `_bmad-output/implementation-artifacts/epic-11-12-shared-guardrails.md` for universal constraints shared across all Epic 11 & 12 stories.
-
-### Critical Guardrails (story-specific)
-
-- Do NOT modify lib/installer.js, lib/agents.js, or bin/cli.js
-- Do NOT change the code-review skill.json — only update SKILL.md content
-- Do NOT add npm dependencies
-- Do NOT duplicate bug detection criteria in code-review SKILL.md — reference the auto-bug-detection skill instead
-- Do NOT make code review block on bug reporting — bugs are tracked independently
-
-### Project Structure Notes
-
-- **File to modify:**
-  - `skills/code-review/SKILL.md` — add "Bug Detection During Review" section
-- **Dependencies:**
-  - Story 11-1 (auto-bug-detection skill must exist) ✓
-  - Story 11-2 (create-bug-story workflow must exist for cross-reference) ✓
-
-### References
-
-- [Source: skills/code-review/SKILL.md] — Existing code review skill content to update
-- [Source: skills/auto-bug-detection/SKILL.md] — Bug detection criteria (created in 11-1)
-- [Source: lib/bmad-extension/workflows/create-bug-story/workflow.md] — Workflow to cross-reference (created in 11-2)
-
-## Dev Agent Record
-
-### Agent Model Used
-
-claude-sonnet-4-6
-
-### Debug Log References
-
-- Precondition check: `node bin/cli.js validate-skill auto-bug-detection` → VALID ✓
-- Precondition check: `lib/bmad-extension/workflows/create-bug-story/workflow.md` exists ✓
-- `node bin/cli.js validate-skill code-review` after update → VALID ✓
-- Cross-reference verification: "Bug Detection During Review" ×1, "create-bug-story" ×2, "auto-bug-detection" ×2 in code-review SKILL.md ✓
-- `npm test` exit code: 0 — all tests pass, no regressions
-
-### Completion Notes List
-
-- Added "Bug Detection During Review" section to `skills/code-review/SKILL.md`
-- Section covers: scope distinction (review feedback vs bug reports), detection during review (defer to auto-bug-detection skill for criteria), `[BUG]` label format with severity, `/create-bug-story` recommendation, non-blocking policy for pre-existing bugs
-- Deliberately did NOT duplicate detection criteria from auto-bug-detection SKILL.md — code-review skill references it instead
-- Both skills validate VALID; full test suite passes with 0 regressions
-
-### File List
-
-- `skills/code-review/SKILL.md` (modified — added Bug Detection During Review section)
-
-## Change Log
-
-- 2026-03-19: Story 11.3 implemented — added bug detection integration section to code-review skill. Both preconditions confirmed, all ACs satisfied, 0 test regressions.

package/_bmad-output/implementation-artifacts/done/12-1-add-sprint-workflow.md

@@ -1,126 +0,0 @@
-# Story 12.1: Create Add Sprint Extension Workflow
-
-Status: done
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a **Scrum Master**,
-I want an extension workflow to create new sprints with capacity limits,
-So that sprint planning uses realistic capacity-based constraints.
-
-## Acceptance Criteria
-
-1. **Given** add-sprint workflow exists in lib/bmad-extension/workflows/add-sprint/workflow.md,
-   **When** invoked via menu or slash command (NFR19),
-   **Then** it guides creation with: sprint name/number, capacity (item count), start/end context,
-   **And** sprint created as trackable artifact
-
-2. **Given** sprint capacity defined by item count (FR66),
-   **When** sprint created,
-   **Then** capacity expressed as max items (stories + bugs),
-   **And** workflow validates capacity is positive integer
-
-## Tasks / Subtasks
-
-- [x] Task 1: Verify extension module scaffolding exists — **depends on Story 11.2 being complete** (AC: #1)
-  - [x] 1.1: Verify `lib/bmad-extension/module.yaml` exists with `extends-module: bmm` — this file is created by Story 11.2. If it does not exist, Story 11.2 has not been completed; do not proceed.
-  - [x] 1.2: Verify `lib/bmad-extension/module-help.csv` exists with header row `name,command,description,phase` — created by Story 11.2.
-
-- [x] Task 2: Create add-sprint workflow (AC: #1, #2)
-  - [x] 2.1: Create directory `lib/bmad-extension/workflows/add-sprint/`
-  - [x] 2.2: Create `lib/bmad-extension/workflows/add-sprint/workflow.md` with guided flow
-  - [x] 2.3: Workflow step 1: Gather sprint number/name (e.g., "Sprint 5")
-  - [x] 2.4: Workflow step 2: Gather capacity as positive integer (max items including stories + bugs)
-  - [x] 2.5: Workflow step 3: Gather optional start/end context (dates or milestones)
-  - [x] 2.6: Workflow step 4: Validate capacity is a positive integer — reject zero or negative values
-  - [x] 2.7: Workflow step 5: Generate sprint artifact file
-
-- [x] Task 3: Define sprint artifact format (AC: #1, #2)
-  - [x] 3.1: Sprint artifact output path: `_bmad-output/implementation-artifacts/sprint-plan-{number}.yaml`
-    - **Naming rationale:** The `sprint-plan-` prefix ensures sprint artifacts never collide with `sprint-status.yaml` when glob patterns like `sprint-plan-*.yaml` are used.
-  - [x] 3.2: Sprint artifact YAML structure: sprint_number, sprint_name, capacity (integer), assigned_items (empty list initially), status (planning), start_context, end_context, created_date, last_modified (ISO timestamp — updated on every write)
-  - [x] 3.3: Ensure artifact format is compatible with add-to-sprint (12-2) and modify-sprint (12-3) workflows
-
-- [x] Task 4: Register workflow in module-help.csv (AC: #1)
-  - [x] 4.1: Add entry to `lib/bmad-extension/module-help.csv` for add-sprint workflow
-  - [x] 4.2: Entry must include: workflow name, slash command `/add-sprint`, description, phase association
-
-- [x] Task 5: Verify workflow (AC: #1, #2)
-  - [x] 5.1: Invoke via `/add-sprint` and verify guided flow completes
-  - [x] 5.2: Verify sprint artifact YAML file is created at expected path
-  - [x] 5.3: Verify capacity validation rejects non-positive-integer values
-
-## Dev Notes
-
-### Architecture Compliance
-
-- **Extension module pattern:** Workflow lives in lib/bmad-extension/workflows/add-sprint/ (NOT in _bmad/bmm/workflows/)
-- **YAML artifact format:** Sprint artifacts use YAML for structured data — consistent with sprint-status.yaml pattern
-- **Capacity as item count:** FR66 specifies capacity as item count (not story points or hours) — keep it simple
-- **BMAD workflow conventions:** Step-by-step guided agent flow, invocable via menu and slash command
-
-### Shared Guardrails
-
-See `_bmad-output/implementation-artifacts/epic-11-12-shared-guardrails.md` for universal constraints, data authority rules, sprint artifact naming, and story implementation order.
-
-### Critical Guardrails (story-specific)
-
-- Do NOT place workflow in `_bmad/bmm/workflows/` — use `lib/bmad-extension/workflows/`
-- Do NOT modify any existing BMAD base module files
-- Do NOT add npm dependencies
-- Do NOT use story points or hours for capacity — use item count only (FR66)
-- Do NOT modify lib/installer.js, lib/agents.js, or bin/cli.js
-- Capacity MUST be validated as a positive integer
-
-### Project Structure Notes
-
-- **Files to create:**
-  - `lib/bmad-extension/workflows/add-sprint/workflow.md`
-- **Files to update:**
-  - `lib/bmad-extension/module-help.csv` — add workflow registration entry
-- **Files to create if not existing (from 11-2):**
-  - `lib/bmad-extension/module.yaml`
-  - `lib/bmad-extension/module-help.csv`
-
-### References
-
-- [Source: _bmad/bmm/workflows/] — Existing BMAD workflows for pattern reference
-- [Source: _bmad-output/implementation-artifacts/sprint-status.yaml] — Existing sprint status for format reference
-- [Source: lib/bmad-extension/module-help.csv] — Workflow registration file
-
-## Dev Agent Record
-
-### Agent Model Used
-claude-sonnet-4-6
-
-### Debug Log References
-None — clean implementation. Extension module scaffolding (module.yaml, module-help.csv) verified present from Story 11.2.
-
-### Completion Notes List
-- Verified extension scaffolding: `lib/bmad-extension/module.yaml` (extends-module: bmm) and `lib/bmad-extension/module-help.csv` ✓
-- Created `lib/bmad-extension/workflows/add-sprint/workflow.md` with 5-step guided flow
-- Sprint artifact YAML format: sprint_number, sprint_name, capacity (int), assigned_items (empty list), status (planning), start_context, end_context, created_date, last_modified (ISO)
-- Capacity validation: rejects zero, negative, and non-integer values; loops back to step 2
-- `sprint-plan-{number}.yaml` naming prefix ensures no glob collision with sprint-status.yaml
-- Registered in module-help.csv with `/add-sprint` command, phase 4-implementation, agent bmm-sm
-- No existing BMAD base module files modified; no new npm dependencies added
-
-### Verification Record (Tasks 5.1–5.3)
-These tasks verify the workflow via static analysis of the instruction set (the deliverable is an LLM-executed workflow, not executable code). Verification performed as follows:
-
-- **5.1 — Guided flow completes:** Traced all step paths in `workflow.md`. Step 1→2→3→4→5 produces a complete sprint artifact. Edit path in step 4 routes to targeted field re-asks (fixed post-review) and returns to step 4 for re-confirmation. Cancel path in step 4/5 exits cleanly. No dead-end branches.
-- **5.2 — Artifact created at expected path:** Step 5 explicitly specifies output path `_bmad-output/implementation-artifacts/sprint-plan-{{sprint_number}}.yaml` with all required YAML fields: sprint_number, sprint_name, capacity, assigned_items (empty list), status (planning), start_context, end_context, created_date, last_modified.
-- **5.3 — Capacity validation rejects non-positive integers:** Step 2 validates `{{capacity_input}}` as a positive integer (greater than zero, no decimals, no non-numeric characters). Invalid input triggers error output and `<goto step="2" />` loop. Zero, negative, and non-numeric values are all rejected by this gate.
-
-### File List
-- `lib/bmad-extension/workflows/add-sprint/workflow.md` (created)
-- `lib/bmad-extension/module-help.csv` (updated — added add-sprint entry)
-- `_bmad-output/implementation-artifacts/12-1-add-sprint-workflow.md` (updated — status, tasks, record)
-- `_bmad-output/implementation-artifacts/sprint-status.yaml` (updated — epic-12 in-progress, 12-1 in-progress→review)
-
-## Change Log
-
-- 2026-03-18: Story 12.1 implemented — add-sprint extension workflow created and registered
-- 2026-03-18: Addressed code review findings — L1 (edit flow field targeting), M5 (verification record added)