Imported from VirtoCommerce/vc-mcp-testing-module (.claude/skills/qa-checklist/SKILL.md). Install upstream with npx skills add VirtoCommerce/vc-mcp-testing-module --skill qa-checklist. Copyright stays with the author.

/qa-checklist — Test Case Writing Checklist Creation

Generate or retrieve domain-specific checklists that ensure complete test case coverage. Each checklist item maps to at least one test case.

Usage

/qa-checklist auth                     # Retrieve Auth storefront checklist
/qa-checklist "product configurations" # Retrieve Product Configs & Variations checklist
/qa-checklist loyalty                  # Retrieve Loyalty & Rewards (Storefront) checklist
/qa-checklist graphql                  # Retrieve GraphQL xAPI checklist (separate file)
/qa-checklist admin catalog            # Retrieve Catalog Admin checklist (backend file)
/qa-checklist admin pricing            # Retrieve Pricing Admin checklist
/qa-checklist VCST-1234                # Generate checklist for JIRA ticket scope
/qa-checklist new "push messages"      # Create new checklist for unlisted domain
/qa-checklist all                      # List every domain checklist with item counts

Supporting Files

• domain-checklists.md — the storefront domain checklists. Source of truth for storefront UI domains.
• backend-admin-checklists.md — the Admin module checklists + the two API checklists, aligned with Bundle v14.0.8. Source of truth for Admin SPA and Platform API/xAPI domains.
• graphql-checklist.md — the per-query/mutation GraphQL xAPI checklist covering every xAPI module (xCatalog, xCart, xOrder, xProfile, xCMS, xFrontend, xQuote, xMarketing) + a per-change verification template.
• checklist-creation-guide.md — Methodology for creating new checklists: structure rules, quality criteria, VC-specific patterns, cross-layer verification, and examples.

Counts are derived, never transcribed here. npm run checklists:count prints every section and its item count across the three files (-- --json for machine use); that script's own header records why it exists. The tables below carry only what does not drift with an edit: id, name, suites.

Cross-Skill References (consult when items derive test cases)

Checklist items are written to be testable; they assume readers will resolve test data and verify schemas via the canonical sources, not hardcode values:

Oracle Grounding (mandatory)

A checklist is the release-time walk of a domain, so it has exactly two jobs the two shared oracles already answer, and it must read them rather than re-derive them from the UI:

npm run bl:lint / npm run ecl:lint print how many of each exist and validate every citation.

Why this is mandatory and not advisory. An item written only from UI exploration encodes what the build currently does; an item grounded in a BL-* encodes what it is supposed to do — only the second can fail on a regression the UI presents confidently. And an un-cited edge-case item is invisible to ecl:lint / bl:lint, so a checklist can neither be credited for oracle coverage nor be repaired when /qa-review-oracles amends the entry it was silently paraphrasing. Charter A of ../qa-sbtm/charter-library.md was a verbatim un-cited restatement of ECL 1.1/1.2/1.3 for exactly this reason.

[OBSERVED] → checklist, [THEORETICAL] → exploratory. The ECL marks every pattern as one or the other. A checklist is walked on every release under the 6–15-item budget, so only [OBSERVED] patterns — confirmed on this platform — earn a slot; a [THEORETICAL] pattern has no failure history here and belongs to /qa-exploratory, whose job is discovery. This mirrors /qa-test-cases-generator §Do not add edge cases speculatively: the checklist re-verifies what has bitten us, the session hunts what hasn't yet.

IDs are a citation contract. Cite an ID that exists; never invent, renumber or guess one — a dangling ref reads as coverage and is none (the ecl:lint ECLC-001 class, whose first run found 20 of them, one citing a section that has never existed). Neither oracle is edited from here: an item needing an invariant or pattern the oracle lacks is a proposal for /qa-review-oracles, whose sole writer is ba-system-analyzer. A reserved id (one the oracle skips deliberately, e.g. BL-LOY-011) has nothing to cite and is not a gap.

Built-in Domain Checklists

Run npm run checklists:count for the per-domain item counts. The tables below are the routing index.

Storefront Domains — domain-checklists.md

Backend & Admin Modules — backend-admin-checklists.md

Aligned with Bundle v14.0.8 (Platform 3.1007.2).

GraphQL xAPI Detail — graphql-checklist.md

One checklist, suite 15. Sections: xCatalog · xCart Lifecycle & Checkout · xCart Configurable Products · xCart Wishlists & Saved for Later · xOrder · xProfile · xQuote · xCMS & xFrontend · xMarketing — Promotion Coupons · Cross-Cutting · New Query/Mutation Verification.

Loyalty has no section here. The loyalty xAPI surface is 3 queries and 0 loyalty-specific mutations, and its invariants are walked from storefront domain 34 — except BL-LOY-013 (order.orderTotals per-currency), which belongs in this file and is not yet written.

Execution

Mode 1: Retrieve Existing Checklist

1. Match the user's argument to a domain:
   • Storefront domains: fuzzy match ("payment" → #9, "cart" → #8, "variations" → #14, "pickup" → #19, "pdp" → #15, "loyalty"/"points"/"rewards"/"missions" → #34, "sales rep"/"salesrep"/"rep hub" → #35, and admin sales rep → A28)
   • Admin domains: admin <module> prefix routes to backend-admin-checklists.md ("admin catalog" → A1, "admin pricing" → A2, "admin orders" → A4)
   • GraphQL: "graphql" / "xapi" → graphql-checklist.md for detailed query/mutation checklist, or API2 for high-level xAPI coverage
   • API: "platform api" / "rest api" → API1
2. Read the checklist from domain-checklists.md, backend-admin-checklists.md, or graphql-checklist.md
3. Present the checklist with markdown checkboxes
4. Suggest related checklists (e.g., storefront "Cart/Checkout" pairs with admin "Orders Admin" and "Pricing Admin"; storefront "Search" pairs with admin "Search & Indexing"; storefront "Loyalty" pairs with "Cart/Checkout" and "Orders")
5. Report oracle coverage — list the BL-* / ECL-<n>.<m> the retrieved items cite, then name the domain's [OBSERVED] ECL sections that NO item covers, and any outcome-asserting item carrying no BL-*. These are back-annotation candidates: offer to add the citations (and any missing [OBSERVED] item) to the stored checklist file, confirm before writing. Nearly every item predates §Oracle Grounding, so this is how the corpus is burned down a domain at a time rather than in one unreviewable pass. Never silently present an un-grounded checklist as complete.

Mode 2: Generate Checklist for JIRA Ticket

1. Fetch JIRA ticket via Atlassian MCP — extract feature scope, acceptance criteria
2. Map the ticket to affected domains (a ticket may touch 2-4 domains)
3. Merge relevant checklist items from each domain into a combined checklist
4. If the ticket involves API/GraphQL changes, also pull items from graphql-checklist.md — include the "New Query/Mutation Verification" section for any new or modified queries/mutations
5. Load the oracles for those domains (§Oracle Grounding), BEFORE step 6: an AC states what the ticket promises, a BL-* states what the surrounding system already guarantees, and the second is where the regression risk lives — a ticket's own AC never mentions the invariant it breaks.
6. Add ticket-specific items derived from acceptance criteria not covered by existing checklists
7. Add the oracle-derived items step 5 surfaced that steps 3–6 left uncovered — each cited: an outcome item carries its BL-*, an edge-case item carries its ECL-<n>.<m> ([OBSERVED] only)
8. Output a single unified checklist with domain section headers, and state which BL-* / ECL-* the ticket's surface touches that this checklist deliberately does NOT cover, with the reason — an omission and an oversight must not look the same to the reader

Mode 3: Create New Checklist (new keyword)

1. Read checklist-creation-guide.md for methodology
2. Identify the domain scope from the user's argument
3. Load the oracles for the domain (§Oracle Grounding) — the BL-* invariants and the ECL-<n>.<m> sections covering this surface. Before the UI walk, not after: exploration shows what the build does, the oracles say what it must do, and a checklist authored from the first alone canonises current behaviour as the expectation. Read first and the walk becomes a check of the invariants and [OBSERVED] patterns against the live build, rather than a transcript of it.
4. Read the domain map if one exists — knowledge/domain/<slug>.md. It gives the surface inventory, the routes, the layer disagreements and the existing coverage shape, so the walk starts from what is known instead of rediscovering it. It does not substitute for the walk: its live rows are dated, and a label it records may have changed since (measured 2026-09-18, one had). A map row your walk contradicts is a DRIFT to report back, not a number to quote.
5. Explore the UI (mandatory) — navigate to the feature in the storefront or admin using Playwright to discover real labels, interactions, states. Leave the environment as you found it: a fixture account's cart, balance or data is shared with the suites that run against it.
6. Apply the methodology in checklist-creation-guide.md Steps 3–5 — map interactions to items, add cross-layer verification, add the VC-specific patterns. Two constraints that are this skill's, not the guide's: a state-transition or business-rule item comes from business-logic.md, cited by ID (a rule you inferred from the UI and cannot tie to a BL-* is a /qa-review-oracles proposal, not a fact), and an error/edge-case item is derived from an [OBSERVED] ECL section and cites its ECL-<n>.<m> ([THEORETICAL] goes to /qa-exploratory)
7. Structure with markdown checkboxes, 6-15 items per domain. State the invariants this checklist deliberately does not cover and where they belong instead
8. Propose adding the new checklist to domain-checklists.md (UI domains) or as a separate file (API/backend domains) — ask user for confirmation. On write: add the summary-table row, the section, and re-derive the header count with npm run checklists:count rather than incrementing by hand

Mode 4: List All (all keyword)

1. Run npm run checklists:count — it reads all three files and prints every section with its item count
2. Present the summary table with domain names, item counts, and key focus areas
3. Highlight which domains are most relevant to current sprint work (if context available)

Output Format

### [Domain Name] — Test Case Writing Checklist

> X items | Related suites: XX, XX | Priority: P0/P1

- [ ] Item description (specific, actionable, uses real UI labels) (BL-XXX-NNN)
- [ ] Edge case derived from the library (ECL-<n>.<m>)
- ...

**Oracle coverage:** BL-* cited: … | ECL-* cited: … | `[OBSERVED]` ECL sections in this domain not covered: … (reason)
**Not covered, deliberately:** <ID> (reason / where it belongs instead)

**Cross-layer checks:**
- [ ] Storefront UI reflects expected state
- [ ] No console errors or failed network requests
- [ ] Admin confirms data persisted correctly

**Related checklists:** [Domain A], [Domain B]

Rules

• Every checklist item must be specific enough to derive at least one test case from it
• Every outcome-asserting item cites its BL-*; every edge-case/error-path item cites its ECL-<n>.<m> (§Oracle Grounding). Pure UI-presence items may omit both — that is the same carve-out /qa-test-cases-generator gives the Business_Rule column
• Only [OBSERVED] ECL patterns become checklist items, and never invent, renumber or guess an oracle ID — both per §Oracle Grounding. Verify with npm run bl:lint / npm run ecl:lint
• Never transcribe a count into this file or into a checklist's prose. npm run checklists:count prints them; a number typed here is correct once and stale thereafter
• Use REAL UI labels discovered from exploration (not generic terms)
• Keep items actionable — start with a verb or UI element name
• 6-15 items per domain (fewer = incomplete, more = too granular). Over the band is allowed when the domain spans several surfaces — say so and say why, rather than dropping a P0 invariant to fit
• Always include cross-layer verification items for P0/P1 domains
• New checklists must be validated against the live environment before delivery
• Link back to E2E scenario catalog (../qa-plan/e2e-scenario-catalog.md) for related scenarios — and only to an E2E-* id that exists there; leave the column empty rather than coining one
• For GraphQL checklists: always include the "New Query/Mutation Verification" section when a ticket introduces new queries or mutations

Integration with Other Skills