---
name: qa
description: "Generate QA test summary from current branch changes for PR handoff"
allowed-tools: Read, Grep, Glob, Bash, Write
---

# /qa - QA Test Summary Generator

Generate a QA handoff document from the current branch's changes. Output should be ready to paste as a **Jira comment** on the ticket.

**Write two versions of the output:**
1. **`.claude/qa-summary.md`** — Markdown version with proper headings, bold, checkboxes, and code formatting. Useful for GitHub PRs or reference.
2. **`.claude/qa-summary.txt`** — Plain text version following the Jira formatting rules below. This is the one that gets copied to clipboard.

After writing both files, run `cat .claude/qa-summary.txt | pbcopy` to copy the Jira version to the clipboard. Tell the user: "Copied to clipboard — paste into Jira with Cmd+V. Markdown version also saved to `.claude/qa-summary.md`."

## Instructions

1. **Discover changes**: Diff against the branch's parent, not production. Run `git diff development --stat` and `git log development..HEAD --oneline` to see only what this branch adds. Also run `git diff HEAD --stat` to catch any uncommitted work.
2. **Read changed files**: Read the key modified files to understand the actual changes, not just the diff stats
3. **Identify scope**: Determine which features, pages, and components are affected
4. **Discover test credentials**: For every persona a test case asks QA to sign in as, surface the actual credential values, not generic labels like "the seeded co-loaded persona." Look for:
   - Seed scenario names (e.g. `src/**/Seed*.cs`, `seeds/**`, `prisma/seed.ts`, fixtures)
   - Email patterns or templates in config (`appsettings*.json`, `.env*`, `config/**`)
   - OTP / password bypass mechanisms or where to read OTPs (Mailpit, MailHog, dev console, feature flags)
   - State / tenant env vars required to seed the right data (`STATE`, `TENANT`, etc.)
   - Any docs in `README.md` or `docs/**` that already enumerate test users
   Resolve patterns into concrete values — e.g. if `EmailPattern` is `sebt.dc+{0}@codeforamerica.org` and the scenario is `co-loaded`, the test credential is `sebt.dc+co-loaded@codeforamerica.org`.
5. **Generate test summary in plain text with light formatting.** The output will be pasted into Jira Cloud's rich text editor. Use this format:

```
QA Summary — [Branch Name]

What Changed
Brief 2-3 sentence description of the feature/fix.

Affected Areas
- All pages — page views and browser tab titles
- Sign in / Sign out flow

Test Cases

Happy Path
1. Step-by-step test case with expected result
2. Another test case...

Edge Cases
1. Edge case scenario with expected behavior

Regression Checks
1. Verify [related feature] still works as expected

Test Credentials
- Persona name — login email — how to retrieve OTP/password
- Another persona — login email — how to retrieve OTP/password

Environment Notes
- Environment setup needed
- Which environments to test on
```

### Formatting rules — CRITICAL
- Use plain text with simple numbered and bulleted lists
- NO markdown syntax (no ##, no **, no backticks, no [ ] checkboxes)
- NO Jira wiki markup (no h2., no *, no {{}}, no #)
- Section headers should be plain text on their own line, in ALL CAPS or Title Case to stand out
- Use dashes (-) for bullet lists and numbers (1. 2. 3.) for ordered lists
- For inline code references like event names, just use quotes: "page_view", "sign_in"
- For links, write the full URL on its own line

## Key Behaviors
- Focus on **user-facing behavior**, not implementation details
- Test cases should be actionable by someone who didn't write the code
- Use relative paths for navigation (e.g. "Navigate to Tools > Tag Generator"), never reference localhost or full URLs — QA knows their environment
- Assume QA is already signed in and on the app unless the test specifically involves auth
- Call out any data dependencies (specific campaigns, creatives, etc.)
- Always include a "Test Credentials" section listing every persona referenced in the test cases with the actual login email and a one-liner on how to retrieve the OTP/password (e.g. "Mailpit at http://localhost:8025" or "OTP bypass enabled in dev — any code works"). Never use generic phrases like "the seeded co-loaded persona" without the concrete email.
- If changes touch auth, API layer, or shared components, expand regression scope
- Keep it concise — QA doesn't need to know about refactors or code style changes
- Use checkboxes only in the markdown version (`qa-summary.md`); the plain-text Jira version uses numbered lists per the formatting rules above

## Language Rules — CRITICAL
- **NEVER reference file names, paths, components, stores, functions, or code concepts.** QA does not read code.
- Write everything in terms of **what the user sees and does in the browser** — pages, buttons, modals, fields, messages.
- Instead of "interceptors.js tracks CRUD operations", say "Creating, editing, or deleting any item should be tracked"
- Instead of "TableFilter.vue search is debounced", say "Type in a search bar, wait a second, and the search should be recorded"
- Instead of "Affected: src/features/analytics/...", say "Affected: Analytics reports page"
- The "Affected Areas" section should list **page names and UI areas**, not files or components
- Environment Notes should only include things QA needs to configure or be aware of — no technical implementation details