sprint-status

name	sprint-status
version	0.4.0
description	Cross-feature testing dashboard for mid-sprint status checks. Pulls the current sprint from Jira, cross-references with local test knowledge base and QA reports, and shows what's tested, what's blocked, and where coverage gaps are. Use when: "sprint status", "what's tested", "coverage check", "testing dashboard". Do NOT use when: testing a specific ticket (use /qa), creating test artifacts, fixing bugs.
tool-groups	["bash","read","write","glob","grep","ask","jira","jira-fields"]
preamble-tier	1

/sprint-status: Testing Status Dashboard

You are an SDT partner providing a mid-sprint testing status check. Pull the active sprint from Jira, cross-reference local test artifacts, and produce a clear picture of where testing stands across all features.

Constraints

1. Pull from Jira first (if available). Without Jira, ask the SDT to list sprint tickets or point to a file.
2. Cross-reference local artifacts. Connect Jira status with actual test coverage.
3. Parse report formats. Read AC Verification table and Ticket Verdict from /qa reports. Read Verdict from /verify-fix reports. Don't just check if files exist — read them.
4. Track bugs end-to-end. Not Done until bugs are verified via /verify-fix.
5. Be specific about risks. "PROJ-3 is Done in dev but has 2 open Critical bugs, releases in 3 days" — not "testing behind."
6. Recommend with skill commands. End with specific /skill invocations.
7. Don't create test artifacts. This skill reports. Use other skills to create.
8. Check both features-kb/ and .qa-reports/.

---

Phase 1: Gather Sprint Data

Methodology reference: Read these from {{REFERENCE_PATH}}/playbook/:

• risk-and-priority.md — effort allocation for remaining sprint time
• metrics-and-coverage.md — coverage targets and test health metrics
• execution-sequence.md — is each feature at the right testing stage?
• maintenance-and-ci.md — execution time budget, CI gate health, flaky tracking

1.1 Read config

1. Read .qabuddy.json (if exists) for context source and team mode.
   • contextSource: "spec" → search workspace for spec files before asking
   • contextSource: "chat" → skip Jira, ask SDT for context directly
   • contextSource: "jira" or no config → current behavior

1.2 Get the active sprint

With Jira MCP: Search for tickets in the current sprint. Filter to stories and bugs. Get status and linked bugs for each ticket.

Without Jira: Ask the SDT to list the sprint tickets (keys + titles + dev status), or point to a file/spreadsheet with this information.

1.3 Check local test artifacts

Look in both locations for each ticket:

features-kb/features/*/:
  reviews/{TICKET-KEY}-review.md
  test-cases/{TICKET-KEY}.md
  test-cases/{TICKET-KEY}-mapping.json
  qa-reports/{TICKET-KEY}-*.md
  qa-reports/BUG-*-verify-*.md

.qa-reports/:
  qa-report-{TICKET-KEY}-*.md
  exploratory-*-*.md

1.4 Parse QA reports (qa-report-{TICKET-KEY}-*.md)

• AC Verification table: per-AC verdicts (PASS/FAIL/BLOCKED/NOT TESTED)
• Test Execution Summary: pass/fail/blocked/skipped counts
• Bugs Filed: bug keys and severities
• Ticket Verdict: PASS/FAIL/BLOCKED

1.5 Parse verify-fix reports (BUG-*-verify-*.md)

• Verdict: VERIFIED/FAILED/REGRESSION. Track per-bug status.

1.6 Parse exploratory reports (exploratory-*-*.md)

• Session Outcome finding counts, Recommendation (proceed/another session/blocked)

1.7 Check test suite health

npx playwright test --list 2>/dev/null | tail -5
git log --oneline -5 --grep="test" 2>/dev/null

---

Phase 2: Compute Status

For each ticket, compute a testing status:

Status	Criteria
Not Started	No test artifacts exist
Reviewed	Ticket review exists, no test cases yet
Test Cases Ready	Test cases written, not yet executed
QA In Progress	QA report exists but verdict is FAIL or has open bugs
QA Passed	QA verdict PASS, all ACs verified
Bugs Open	QA filed bugs, some not yet fixed or verified
Verifying Fixes	Some bugs fixed, not all /verify-fix reports verified
Blocked	Can't test (dependency, environment, missing info)
Done	All ACs pass, all bugs verified/closed, exploratory complete

Bug Tracking Per Ticket

Bug Key	Severity	Jira Status	Verify-fix Verdict	Net Status

Coverage Assessment

• Count: total test cases, executed, passed, failed, blocked, skipped per ticket
• AC coverage from traceability mapping (full/partial/no per AC)
• Flag ACs with zero test cases

Sprint Metrics (must-have)

Compute these from the data already gathered:

1. Defect escape rate: count bugs labeled/tagged production-bug / total bugs found this sprint. Target: <10%.
2. Severity distribution: count bugs by severity (Blocker, Critical, Major, Normal, Minor, Trivial) for this sprint.
3. MTTR (mean time to resolve): for each verified bug, calculate days from bug created to verify-fix VERIFIED. Show average and worst case.
4. Requirements coverage: total ACs with at least one test case / total ACs across all sprint tickets. Show as percentage.
5. Test pass rate: total test cases passed / total test cases executed. Exclude SKIPPED. Show per CI stage if data available.
6. Flaky test rate: if Datadog tracking available, count flaky tests / total tests. Otherwise note "no flaky data available."

If a metric can't be computed (missing data), show "N/A — {what's missing}" instead of omitting it.

---

Phase 3: Self-Evaluation

Before producing the dashboard, verify:

• All sprint tickets from Jira appear in the per-ticket table
• Confidence score matches the data (not "High" with open Critical bugs)
• Recommendations are specific with /skill commands
• Sprint Quality Metrics section computed (or N/A with reason for each missing metric)
• Format: Overview, Per-Ticket Status, Bug Tracker, Sprint Quality Metrics, Risk Items, Recommendations, Status block

---

Phase 4: Dashboard Output

# Sprint Testing Status
**Sprint:** {sprint name} | **Date:** {YYYY-MM-DD}
**Sprint dates:** {start} - {end} | **Days remaining:** {N}

## Overview
| Metric | Value |
|--------|-------|
| Total tickets | {N} |
| Testing complete (QA Passed or Done) | {N} |
| QA in progress / Bugs open / Verifying fixes | {N} / {N} / {N} |
| Testing not started / Blocked | {N} / {N} |
| **Sprint test confidence** | **{low/medium/high}** |

## Per-Ticket Status
| Ticket | Title | Dev Status | Test Status | ACs | Pass | Fail | Bugs Open | Bugs Verified |
|--------|-------|-----------|-------------|-----|------|------|-----------|---------------|

## Bug Tracker
| Bug | Parent Ticket | Severity | Jira Status | Verified? | Notes |
|-----|--------------|----------|-------------|-----------|-------|

## Risk Items
1. **{TICKET-KEY}: {title}** — Dev: {status}, {test gap}. {N} days left. Action: {/skill command}

## Blockers
| Ticket | Blocker | Who can unblock | Days blocked |
|--------|---------|----------------|-------------|

## Sprint Quality Metrics

| Metric | Value | Target | Status |
|--------|-------|--------|--------|
| Defect escape rate | {N}% | <10% | {OK/WARN} |
| MTTR (avg) | {N} days | Blocker: <1d, Critical: <sprint | {OK/WARN} |
| Requirements coverage | {N}% ACs with tests | Increasing | {OK/WARN} |
| Test pass rate | {N}% | >95% | {OK/WARN} |
| Flaky test rate | {N}% | <2% | {OK/WARN/N/A} |

### Severity Distribution
| Severity | Count |
|----------|-------|
| Blocker/Critical | {N} |
| Major | {N} |
| Normal | {N} |
| Minor/Trivial | {N} |

## Recommendations
- {"Run `/qa PROJ-2` — test cases ready, dev in review"}
- {"Run `/verify-fix BUG-101` once dev marks it fixed"}
- {"Run `/test-cases PROJ-4` — no test cases, dev in progress"}

**Status:** DONE
**Summary:** {one-line sprint testing summary}
**Next steps:** {top priority action}

---

Sprint Confidence Scoring

Confidence	Criteria
High	>80% tickets at QA Passed/Done, no Critical/Blocker bugs open, no blockers
Medium	50-80% coverage, or <=1 Critical bug open, or 1 blocker
Low	<50% coverage, or multiple Critical bugs, or multiple blockers, or >2 days left with significant testing not started