ma-agents 3.4.9 → 3.5.1

package/lib/bmad-extension/skills/sprint-status-view/SKILL.md

@@ -1,202 +1,177 @@
 ---
 name: sprint-status-view
-description: Display sprint progress with assigned items, type distinction, and remaining capacity
+description: Display formatted sprint progress, backlog, and epic status from the unified sprint-status.yaml
 type: skill
 triggers:
   - "sprint status view"
   - "view sprint status"
+  - "/sprint-status-view"
 ---
 
-# Sprint Status View Workflow
-
-Extension workflow that displays sprint progress with assigned items (stories + bugs), type distinction, and remaining capacity.
-
-> **Architecture mandate:** This workflow is a NEW extension at `lib/bmad-extension/workflows/sprint-status-view/`. It does NOT modify any files under `_bmad/bmm/workflows/`.
-
-<workflow>
-
-<step n="1" goal="Discover all sprint artifact files">
-  <action>Glob `_bmad-output/implementation-artifacts/sprint-plan-*.yaml` to discover all sprint artifact files</action>
-  <check if="no sprint files found">
-    <output>
-ℹ️ **No Sprints Found**
-
-No sprint plan files exist yet (`sprint-plan-*.yaml`).
-
-**To get started:**
-- Run `/add-sprint` to create your first sprint
-- Run `/add-to-sprint` to assign backlog items to it
-    </output>
-    <action>Exit workflow</action>
-  </check>
-  <action>For each sprint file found, read the full YAML content and store as {{sprint_plans}} list</action>
-  <action>Sort {{sprint_plans}} by sprint_number ascending</action>
-</step>
-
-<step n="2" goal="Load sprint-status.yaml for user story execution statuses">
-  <action>Read `_bmad-output/implementation-artifacts/sprint-status.yaml`</action>
-  <check if="file not found">
-    <output>⚠️ `sprint-status.yaml` not found. User story execution statuses will not be available. Run `/sprint-planning` to initialize.</output>
-    <action>Set {{story_status_map}} = {} (empty — will show data integrity warnings per missing item)</action>
-  </check>
-  <check if="file found">
-    <action>Parse development_status section into {{story_status_map}} — key: story key, value: status</action>
-    <action>Exclude epic-* keys and *-retrospective keys from the map</action>
-  </check>
-</step>
-
-<step n="3" goal="Discover bug stories for type/severity data">
-  <action>Glob `_bmad-output/implementation-artifacts/bug-*.md` to discover all bug story files</action>
-  <check if="no bug files found">
-    <action>Set {{bug_metadata_map}} = {} (empty)</action>
-  </check>
-  <check if="bug files found">
-    <action>For each bug file, parse YAML frontmatter to extract: type, severity, title</action>
-    <action>Build {{bug_metadata_map}} — key: file basename (e.g., `bug-login-crash`), value: {severity, title}</action>
-  </check>
-</step>
-
-<step n="4" goal="Display sprint status for each sprint">
-  <action>For each sprint in {{sprint_plans}} (in order):</action>
-  <action>Calculate: {{assigned_count}} = length(sprint.assigned_items)</action>
-  <action>Calculate: {{remaining_capacity}} = sprint.capacity - {{assigned_count}}</action>
-
-  <action>For each item identifier in sprint.assigned_items, resolve item details:
-
-    **If item is a story (key matches regex `^\d+-\d+-.+`):**
-    - Look up status in {{story_status_map}}[item_key]
-    - If NOT found in {{story_status_map}}:
-      → Record as DATA INTEGRITY WARNING: "Item {item_key} has no status entry in sprint-status.yaml — run /sprint-planning to initialize status tracking for this item."
-      → Display item with marker: ⚠️ [status unknown]
-    - If found: display with current status label
-
-    **If item is a bug (key matches regex `^bug-.+`):**
-    - Look up in {{bug_metadata_map}}[item_key]
-    - If NOT found: display with title as item_key, severity as "unknown"
-    - If found: display with title and severity from frontmatter
-    - Bug execution status: use `status` from bug file frontmatter if present; otherwise "not-started"
-
-    **If item matches neither pattern:** display as type "Unknown" with raw identifier as title
-  </action>
-
-  <output>
+# Sprint Status View
+
+Display a formatted, read-only dashboard of all sprint, backlog, and epic data from the unified `sprint-status.yaml` file.
+
+> **READ-ONLY SKILL:** This skill NEVER writes to `sprint-status.yaml` or any other file. It is purely a display/reporting skill.
+
+---
+
+## Step 1 — Load sprint-status.yaml
+
+Resolve the path to `sprint-status.yaml` using the BMAD config:
+- Check `_bmad/bmm/config.yaml` for `sprint_management_path` (if configured for multi-repo mode)
+- Default path: `_bmad-output/implementation-artifacts/sprint-status.yaml`
+
+Read the file. If it does not exist:
+- Output: "No sprint-status.yaml found. Run `/bmad-sprint-planning` to initialize."
+- Exit without error.
+
+Parse all sections from the file:
+- **Metadata:** `project`, `last_updated` (plus `generated`, `project_key`, `tracking_system`, `story_location` if present)
+- **`epics`** — map of epic entries (keys: `epic-N`)
+- **`backlog`** — array of unassigned item objects
+- **`sprints`** — map of sprint entries (keys: `sprint-N`)
+
+If the file exists but uses the old flat `development_status` schema (no `epics`/`backlog`/`sprints` sections), output:
+"sprint-status.yaml uses the pre-Epic-17 schema. Run `/bmad-sprint-planning` to migrate to the unified schema."
+Then exit.
+
+---
+
+## Step 2 — Classify Sprints
+
+Partition the `sprints` map into three groups:
+- **active** — entries where `status: active`
+- **planning** — entries where `status: planning`
+- **closed** — entries where `status: closed`
+
+Sort each group by sprint key (`sprint-N`) ascending by numeric value of N.
+
+---
+
+## Step 3 — Render Header
+
+Output:
+
+```
+# Sprint Status — {project}
+*Last updated: {last_updated}*
+
 ---
+```
+
+---
+
+## Step 4 — Render Active Sprints
+
+If there are active sprints, output a `## Active Sprints` section header.
+
+For each active sprint (sorted by key ascending):
+
+1. Sprint header:
+   ```
+   ### {sprint.name}
+   **Status:** active | **Capacity:** {items.length} / {capacity} | **Start:** {start or "—"} | **End:** {end or "—"}
+   ```
+   If `items.length > capacity`, append inline: `⚠️ over capacity by {items.length - capacity} item(s)`
+
+2. Items table (if items array is non-empty):
+   ```
+   | Item | Title | Type | Status | Severity |
+   |------|-------|------|--------|----------|
+   | {id} | {title} | Story | {status} | — |
+   | {id} | {title} | Bug   | {status} | {severity} |
+   ```
+   - Type column: use "Story" for `type: story`, "Bug" for `type: bug`
+   - Severity column: show severity value for bugs, "—" for stories
+
+3. If items array is empty, output: `*(No items assigned to this sprint)*`
 
-## 🏃 {{sprint.sprint_name}} (Sprint {{sprint.sprint_number}})
-
-**Status:** {{sprint.status}} | **Capacity:** {{sprint.capacity}} items | **Assigned:** {{assigned_count}} | **Remaining:** {{remaining_capacity}}
-{{#if sprint.start_context}}**Start:** {{sprint.start_context}}{{/if}} {{#if sprint.end_context}}| **End:** {{sprint.end_context}}{{/if}}
-
-{{#if over_capacity}}
-⚠️ **Over capacity by {{overage}} item(s)**
-{{/if}}
-
-### Assigned Items
-
-| Item | Title | Type | Status / Severity |
-|---|---|---|---|
-{{#each resolved_items}}
-{{#if is_story}}
-| {{item_key}} | {{title}} | 📋 Story | {{status}} |
-{{/if}}
-{{#if is_bug}}
-| {{item_key}} | {{title}} | 🐛 Bug | Severity: {{severity}} / {{bug_status}} |
-{{/if}}
-{{/each}}
-
-{{#if data_integrity_warnings}}
-**⚠️ Data Integrity Warnings:**
-{{#each data_integrity_warnings}}
-- {{this}}
-{{/each}}
-{{/if}}
-
-{{#if assigned_items_empty}}
-*(No items assigned to this sprint)*
-{{/if}}
-  </output>
-</step>
-
-<step n="5" goal="Display unassigned backlog summary">
-  <action>Collect all item keys from {{story_status_map}} that are NOT in any sprint's assigned_items list — these are unassigned user stories</action>
-  <action>Collect all bug basenames from {{bug_metadata_map}} that are NOT in any sprint's assigned_items list — these are unassigned bugs</action>
-  <action>Count unassigned stories by status: {{unassigned_by_status}}</action>
-  <output>
 ---
 
-## 📦 Unassigned Backlog
-
-### 📋 Unassigned Stories
-
-| Status | Count |
-|---|---|
-| backlog | {{count_backlog}} |
-| ready-for-dev | {{count_ready}} |
-| in-progress | {{count_in_progress}} |
-| review | {{count_review}} |
-| done | {{count_done}} |
-
-*Total unassigned stories: {{total_unassigned}}*
-
-### 🐛 Unassigned Bugs
-
-{{#if unassigned_bugs}}
-| ID / File | Title | Severity |
-|---|---|---|
-{{#each unassigned_bugs}}
-| {{id}} | {{title}} | {{severity}} |
-{{/each}}
-{{else}}
-*(No unassigned bugs)*
-{{/if}}
-
-**Tip:** Use `/add-to-sprint` to assign unassigned items to a sprint.
-  </output>
-</step>
-
-<step n="6" goal="Offer next actions">
-  <ask>Options:
-1. Show full unassigned backlog item list (IDs + titles + statuses)
-2. Add items to a sprint — run `/add-to-sprint`
-3. Modify a sprint — run `/modify-sprint`
-4. Create a new sprint — run `/add-sprint`
-5. Exit
-
-Choice:</ask>
-  <check if="choice == 1">
-    <action>For each unassigned story key in {{story_status_map}} not assigned to any sprint, display: key, inferred title, status</action>
-    <action>For each unassigned bug in {{bug_metadata_map}} not assigned to any sprint, display: id, title, severity</action>
-    <output>
-### Full Unassigned Backlog
-
-**Stories:**
-| Key | Title | Status |
-|---|---|---|
-{{#each unassigned_story_items}}
-| {{key}} | {{title}} | {{status}} |
-{{/each}}
-
-**Bugs:**
-| ID | Title | Severity |
-|---|---|---|
-{{#each unassigned_bugs}}
-| {{id}} | {{title}} | {{severity}} |
-{{/each}}
-    </output>
-    <goto step="6" />
-  </check>
-  <check if="choice == 2">
-    <output>▶️ Run `/add-to-sprint` to assign backlog items to a sprint.</output>
-  </check>
-  <check if="choice == 3">
-    <output>▶️ Run `/modify-sprint` to add/remove items or change sprint settings.</output>
-  </check>
-  <check if="choice == 4">
-    <output>▶️ Run `/add-sprint` to create a new sprint.</output>
-  </check>
-  <check if="choice == 5">
-    <action>Exit workflow</action>
-  </check>
-</step>
-
-</workflow>
+## Step 5 — Render Planning Sprints
+
+If there are planning sprints, output a `## Planning Sprints` section header.
+
+For each planning sprint (sorted by key ascending), use the same format as Step 4 with `status: planning`.
+
+---
+
+## Step 6 — Render Closed Sprint Summaries
+
+If there are closed sprints, output a `## Closed Sprints` section header followed by a summary table:
+
+```
+| Sprint | Items | Start | End |
+|--------|-------|-------|-----|
+| {sprint.name} | {items.length} items (archived) | {start or "—"} | {end or "—"} |
+```
+
+Do NOT list individual items within closed sprints (collapsed view by default).
+
+---
+
+## Step 7 — Render Backlog
+
+Count total backlog items: `{backlog.length}`.
+
+Output a `## Backlog — {backlog.length} items` section header.
+
+If backlog is empty, output: `*(No items in backlog)*`
+
+Otherwise, output a table in array order (position = priority):
+
+```
+| # | Item | Title | Type | Status | Severity |
+|---|------|-------|------|--------|----------|
+| 1 | {id} | {title} | Story | {status} | — |
+| 2 | {id} | {title} | Bug   | {status} | {severity} |
+```
+
+- `#` column: 1-based position in the array (= priority rank)
+- Severity column: show severity for bugs, "—" for stories
+
+---
+
+## Step 8 — Render Epics Overview
+
+Output a `## Epics` section header.
+
+If the `epics` map is empty, output: `*(No epics defined)*`
+
+Otherwise, for each epic in the map (sorted by key ascending by numeric value of N):
+
+1. Count items referencing this epic across all sections:
+   - Scan `backlog` items where `epic == N` (N = epic number, e.g., `17` for `epic-17`)
+   - Scan all `sprints[*].items` where `epic == N`
+   - Tally counts by status
+
+2. Output a table row:
+   ```
+   | Epic | Status | Retrospective | Items (active) |
+   |------|--------|---------------|----------------|
+   | epic-4 | on-hold | optional | {count} total ({status breakdown}) |
+   ```
+   - Status breakdown: list non-zero status counts, e.g., "2 in-progress, 1 ready-for-dev"
+   - If no items reference the epic, show "0 total"
+   - `retrospective` field: show value or "—" if null
+
+---
+
+## Step 9 — Render Alerts (Conditional)
+
+Scan for alert conditions:
+
+1. **Over-capacity sprints:** Any sprint where `items.length > capacity`
+   - Alert: `Over capacity: {sprint.name} is over capacity by {items.length - capacity} item(s) ({items.length} / {capacity})`
+
+2. **Stale in-progress items:** Items with `status: in-progress` in **active** sprints where the sprint's `start` date is more than 14 days before today
+   - Alert: `Stale in-progress: {item.id} has been in-progress for {N} days ({sprint.name} started {start})`
+
+3. **Empty active sprints:** Active sprints with zero items
+   - Alert: `Empty active sprint: {sprint.name} is active but has no items assigned`
+
+If NO alert conditions exist, omit this section entirely (do not output "No alerts" or any placeholder).
+
+If alerts exist, output a `## Alerts` section header followed by a bulleted list.
+

package/lib/bmad-extension/skills/sqa-audit/SKILL.md

@@ -0,0 +1,279 @@
+---
+name: sqa-audit
+description: SQA Audit workflow — comprehensive project quality audit covering code-to-story traceability, story-to-architecture alignment, process compliance, sprint health, and release state
+type: skill
+triggers:
+  - "audit"
+  - "audit project"
+  - "run audit"
+---
+
+# SQA Audit Workflow
+
+## Purpose
+Perform a structured quality audit of the project, reporting findings per dimension with severity levels (PASS / WARNING / FAIL). The audit produces a written report saved to the output folder.
+
+---
+
+## Step 1 — Scope Selection
+
+Ask the user:
+
+> "Welcome to the SQA Audit. Would you like to run a **full audit** (all dimensions) or a **partial audit** (select specific areas)?
+>
+> Available audit dimensions:
+> 1. **Code ↔ Stories**: Verify that implemented code corresponds to active/done stories
+> 2. **Stories ↔ Architecture & PRD**: Verify that epics and stories align with the architecture and product requirements
+> 3. **Process Compliance**: Verify adherence to the defined development process (branching, commits, testing, reviews)
+> 4. **Sprint Health**: Analyze the state and health of active and recent sprints
+> 5. **Release State**: Review the status of releases, deployments, and delivery readiness
+>
+> Type **'full'** to run all dimensions, or list the numbers of the dimensions you want (e.g., '1,3,5')."
+
+Wait for user response. Store the selected dimensions as {audit_scope}.
+
+---
+
+## Step 2 — Data Collection
+
+Before running any audit dimension, collect the following project artifacts:
+
+### Required reads
+- `{project-root}/_bmad/bmm/config.yaml` — resolve {output_folder}
+- `{output_folder}/planning-artifacts/prd.md` — product requirements (if exists)
+- `{output_folder}/planning-artifacts/architecture.md` — architecture doc (if exists)
+- `{output_folder}/planning-artifacts/epics.md` — epics (if exists)
+- `{output_folder}/implementation-artifacts/sprint-status.yaml` — sprint and backlog state
+
+### Optional reads (load if they exist)
+- `{output_folder}/project-context.md` — project context summary
+- Any story files referenced in sprint-status.yaml that are relevant to active/done items
+
+Inform the user which artifacts were found and which were missing before proceeding. Missing artifacts for a dimension will result in a SKIPPED status for that dimension.
+
+---
+
+## Step 3 — Run Selected Audit Dimensions
+
+**Scope guard:** For each dimension below, only execute if that dimension's number is in {audit_scope}. Skip silently — do not mention skipped dimensions until the report.
+
+Run each selected dimension in order. For each dimension, produce a findings block (see format below).
+
+### Dimension 1 — Code ↔ Stories Traceability
+
+**Goal:** Verify that code in the repository corresponds to stories marked as done or in-progress, and that no significant code exists without a backing story.
+
+**Process:**
+1. Read the `done` and `in_progress` items from sprint-status.yaml
+2. For each story/task, check whether the described changes can be traced to actual code (ask the user to confirm or provide relevant file paths if direct code scanning is not feasible)
+3. Identify stories marked done but with no apparent code changes (ask user to verify)
+4. Identify significant recent commits (from git log summary if available) not linked to any story
+5. Report gaps
+
+**Findings format:**
+- List each story ID and its traceability status
+- Flag any untraced code changes
+- Flag any stories with no code evidence
+
+---
+
+### Dimension 2 — Stories ↔ Architecture & PRD Alignment
+
+**Goal:** Verify that the epics and stories correctly implement the requirements in the PRD and are consistent with the architecture.
+
+**Process:**
+1. For each epic in epics.md, identify the corresponding PRD section(s)
+2. Check that epic goals are derived from PRD requirements — flag any epic with no clear PRD backing
+3. For each epic/story with technical decisions, check alignment with architecture.md:
+   - Technology choices match the architecture
+   - System boundaries and component assignments are respected
+   - Non-functional requirements (NFRs) from the PRD are reflected in stories
+4. Flag any stories that introduce architectural decisions not documented in architecture.md
+5. Flag any PRD requirements with no corresponding epic/story
+
+**Findings format:**
+- PRD coverage table (requirement → epic/story mapping, with COVERED / MISSING / PARTIAL)
+- Architecture compliance issues list
+
+---
+
+### Dimension 3 — Process Compliance
+
+**Goal:** Verify that the team is following the defined development process.
+
+**Process:**
+1. Check for the presence of a git-workflow-skill or equivalent branching policy definition
+2. Retrieve recent git log using available git tools (run `git log --oneline -20` directly). Fall back to asking the user to paste the output only if tool execution fails or is not permitted:
+   - Are commit messages following conventional commit format?
+   - Are changes going through feature branches and PRs (not committed directly to main)?
+3. Check for test coverage evidence:
+   - Are test files present alongside implementation files for new code?
+   - Are there failing tests in the repository?
+4. Check for code review evidence (PR descriptions, review comments) if accessible
+5. Check that story files are being maintained (status updates, implementation notes)
+
+**Findings format:**
+- Process checklist with PASS / FAIL / UNKNOWN per item
+- Specific violation examples with file/commit references where available
+
+---
+
+### Dimension 4 — Sprint Health
+
+**Goal:** Assess the health of active and recent sprints.
+
+**Process:**
+1. Read sprint-status.yaml — load all sprints, backlog, and epics sections
+2. For each active sprint:
+   - Calculate completion percentage (done items / total items)
+   - Identify overdue items (items that should be done based on sprint timeline)
+   - Flag items that have been in-progress for an unusually long time (no status change)
+   - Identify blockers and high-priority items not yet started
+3. For the most recently closed sprint:
+   - Report carry-over items (items that were not completed and moved back to backlog)
+   - Report the final completion rate
+4. Assess backlog health:
+   - Is the backlog groomed? (items have priorities, estimates, and clear descriptions)
+   - Are there orphaned items not belonging to any epic?
+
+**Findings format:**
+- Per-sprint summary table (sprint name, total items, done, in-progress, not started, completion %)
+- Risk flags (overdue, stalled, blockers)
+- Backlog health summary
+
+---
+
+### Dimension 5 — Release State
+
+**Goal:** Assess the readiness and status of releases and deployments.
+
+**Process:**
+1. Ask the user: "Do you have a release tracking document, deployment pipeline, or version file? If so, please share the path or content."
+2. Check for version files in the project (package.json, version.txt, CHANGELOG.md, etc.)
+3. Identify which stories/epics are included in the current or upcoming release
+4. Verify that all stories slated for the release are marked done
+5. Check for open bugs or blockers tagged to the current release
+6. Ask about deployment status: "Has the current release been deployed to any environment? If so, which ones?"
+7. Identify any release-critical stories that are still in-progress or not started
+
+**Findings format:**
+- Release readiness summary (READY / AT RISK / NOT READY)
+- List of blocking items preventing release
+- Deployment status per environment (if available)
+
+---
+
+## Step 4 — Audit Report
+
+After running all selected dimensions, compile a full audit report.
+
+### Report format
+
+```
+# SQA Audit Report
+**Date:** {today's date}
+**Auditor:** Gad (SQA Agent)
+**Scope:** {list of audited dimensions}
+**Overall Status:** PASS | WARNING | FAIL
+
+---
+
+## Executive Summary
+{2-4 sentences summarizing the overall quality posture of the project}
+
+---
+
+## Findings by Dimension
+
+### [Dimension Name]
+**Status:** PASS | WARNING | FAIL | SKIPPED
+**Summary:** {one-line summary}
+
+#### Issues Found
+| Severity | Item | Detail | Recommendation |
+|----------|------|--------|----------------|
+| FAIL     | ...  | ...    | ...            |
+| WARNING  | ...  | ...    | ...            |
+
+#### Observations
+{Any noteworthy observations that are not blocking issues}
+
+---
+
+## Action Items
+{Prioritized list of recommended corrective actions}
+
+| Priority | Action | Owner (if known) | Related Dimension |
+|----------|--------|------------------|-------------------|
+| P1       | ...    | ...              | ...               |
+
+---
+
+## Skipped Dimensions
+{List dimensions that were skipped due to missing artifacts, and what artifacts are needed to run them}
+```
+
+### Severity definitions
+- **FAIL**: A clear gap or violation that should be resolved before continuing or releasing
+- **WARNING**: A concern that should be addressed but is not immediately blocking
+- **PASS**: The dimension meets quality expectations
+
+### Overall status rule
+- If any dimension is FAIL → overall is FAIL
+- If no FAIL but any WARNING → overall is WARNING
+- All PASS or SKIPPED → overall is PASS
+
+---
+
+## Step 5 — Save Report
+
+Save the report to:
+`{output_folder}/sqa-audit-report-{YYYY-MM-DD}.md`
+
+Inform the user of the saved path.
+
+Then, for each FAIL finding in the report, present it one at a time and ask:
+> "Would you like me to create a backlog story for this issue: [finding summary]? (yes/skip)"
+
+Wait for the user's response before proceeding to the next FAIL. If yes, invoke the `create-bug-story` workflow for that item. The user may accept or skip each item individually. Once all FAILs have been offered, ask:
+> "Would you like me to generate a remediation plan for all findings? This will produce a prioritized corrective-action document saved alongside the audit report."
+
+If yes, generate and save a remediation plan to:
+`{output_folder}/sqa-remediation-plan-{YYYY-MM-DD}.md`
+
+### Remediation Plan Format
+
+```
+# SQA Remediation Plan
+**Date:** {today's date}
+**Auditor:** Gad (SQA Agent)
+**Source Report:** sqa-audit-report-{YYYY-MM-DD}.md
+**Scope:** {audited dimensions}
+
+---
+
+## Summary
+
+{1-2 sentences: number of findings, overall risk level, key themes}
+
+---
+
+## Corrective Actions
+
+| Priority | Dimension | Finding | Corrective Action | Target State | Effort | Owner |
+|----------|-----------|---------|-------------------|--------------|--------|-------|
+| P1       | ...       | ...     | ...               | ...          | Low/Medium/High | ... |
+
+**Priority definitions:**
+- P1 — FAIL severity; must be resolved before next release or sprint boundary
+- P2 — WARNING severity; should be resolved within current or next sprint
+- P3 — Observation; address when capacity allows
+
+---
+
+## Resolution Tracking
+
+{Instructions to the team: update this table as items are resolved; re-run the audit after P1 items are addressed to verify closure}
+```
+
+Inform the user of the remediation plan path and ask if they want to review any finding in more detail.

package/lib/bmad-extension/skills/sqa-audit/bmad-skill-manifest.yaml

@@ -0,0 +1,3 @@
+type: skill
+name: sqa-audit
+module: ma-skills