--- name: qa-handoff-package description: "Turn a story and its change into a clean 'ready for QA' package — test scenarios, edge cases, the data and environment setup, and what's explicitly out of scope. Use when asked to prep a QA handoff, what should QA test here, write test scenarios for this story, or make this ready for QA. Produces the scenarios mapped to acceptance criteria, the edge/negative cases devs forget, the exact data and environment setup to reproduce, the risk areas to probe, and the out-of-scope list so QA doesn't chase the wrong things." --- # QA Handoff Package The "ready for QA" that isn't — a story tossed over the wall with no test data, no edge cases, and no idea what changed — is how bugs slip and QA burns a day setting up. This turns the story and its change into a real handoff: scenarios tied to the acceptance criteria, the negative and edge cases developers reliably forget, the exact data/environment to reproduce, and a clear line around what's *not* in scope, so testing is focused, not archaeology. ## What This Skill Produces - **Test scenarios mapped to acceptance criteria** — every AC has at least one way to verify it - **Edge & negative cases** — empty/boundary/invalid inputs, permissions, concurrency, the forgotten paths - **Data & environment setup** — the exact accounts, feature flags, seed data, and env needed to reproduce - **Risk areas to probe** — where this change is most likely to have broken something (incl. nearby regressions) - **Out of scope** — what QA should *not* spend time on for this change ## Required Inputs Ask for these if not provided: - **The story & acceptance criteria** — what it's meant to do - **The change** — what was built (a summary or the MR/PR diff), so scenarios match reality - **Environments & data** — where QA tests, and what setup/flags/accounts are needed - **Known risk/complexity** — anything the dev is worried about, or areas the change touches indirectly ## Framework: A Handoff QA Can Run 1. **Cover every AC.** Each acceptance criterion gets a concrete scenario — no AC left unverified. 2. **The happy path is the easy 30%.** The value is the edge and negative cases: empty, max, invalid, unauthorised, offline, concurrent, mid-migration. 3. **Reproducibility is setup.** Name the exact data, accounts, roles, and flags — "test it" without setup wastes QA's morning. 4. **Point at the risk.** Where the diff touches shared code or a fragile area, call it out — including regressions in neighbouring features. 5. **Bound it.** State what's out of scope so QA doesn't test the whole app for a small change. 6. **Ground in the actual change.** Scenarios match what was built, not what the story wished for. ## Output Format ### QA Handoff — [story] · build: [MR/PR ref] ### Scenarios (by acceptance criterion) | AC | Scenario | Expected | |---|---|---| ### Edge & negative cases - [empty / boundary / invalid / permission / concurrency / offline …] ### Setup to reproduce - Environment: … · Accounts/roles: … · Feature flags: … · Seed data: … ### Risk areas / possible regressions - [where this change might have broken something nearby]. ### Out of scope - [what not to test for this change]. ## Quality Checks - [ ] Every acceptance criterion has at least one scenario - [ ] Edge and negative cases are included, not just the happy path - [ ] Exact data/environment/flag setup is specified for reproducibility - [ ] Risk areas and possible regressions are called out - [ ] An explicit out-of-scope list bounds the testing - [ ] Scenarios reflect what was actually built, not just the story text ## Anti-Patterns - **Happy-path only** — the bugs live in the edges. - **"Just test the story"** with no data/environment setup — a lost QA morning. - **No scope boundary** — QA re-tests the whole app for a one-line change. - **Ignoring regressions** in features the change touches indirectly. - **Scenarios from the story, not the build** — testing what was wished, not what shipped. ## Example Trigger Phrases - "Prep a QA handoff for this story and its MR." - "What should QA test here, including edge cases and setup?" - "Write test scenarios mapped to these acceptance criteria." - "Make this ready for QA — what's in and out of scope?"