Test cases from a ticket

Most test cases written from a ticket only cover what the ticket says. The useful ones cover the space between what was requested, what was built, and what the user actually needed — so this skill is deliberately structured to force that third column.

When it triggers

On a ticket URL, a pasted acceptance criteria block, or a request like “write test cases for CORE-1182”.

SKILL.md

---
name: test-cases-from-ticket
description: >
  Turn a ticket into a structured test case set. Use when given a Jira or
  GitHub issue, a set of acceptance criteria, or asked to write test cases
  for a feature or bug.
---

# Test cases from a ticket

## Read the ticket properly first

Before writing anything, establish:

1. **What changes** — the component, endpoint, or screen actually touched.
2. **What it touches** — dependencies, shared state, data it reads or writes.
3. **Who it affects** — which user roles, which permission levels.
4. **What it replaces** — the behaviour before this change.

If the ticket does not answer these, say which ones are missing and ask.
Do not invent acceptance criteria to fill the gap.

## Produce four groups, in this order

**Happy path** — the journey the ticket describes, as a user performs it.
One case per distinct route through the feature, not one per assertion.

**Negative** — invalid input, wrong permissions, expired state, missing
dependencies. Each case names the expected failure, not just "it errors".

**Edge** — boundary values, empty and maximum states, concurrency,
slow networks, interrupted flows. Prefer the boundary that the code is most
likely to have got wrong over an exhaustive sweep.

**Gaps** — the section that earns this skill its place. Behaviour the ticket
does not specify but a user will hit anyway: what happens on a second
submission, what the screen reader announces, what the audit log records,
what happens when the feature is disabled mid-flow. Mark each one
`NEEDS DECISION` and name who should decide.

## Format

A Markdown table per group: ID, title, preconditions, steps, expected result.
IDs follow the ticket key — `CORE-1182-HP-01`, `-NEG-01`, `-EDGE-01`, `-GAP-01`.

## Rules

- Steps are what a person does, not what the code does. "Click Save", not
  "call `POST /orders`".
- One expected result per case. A case asserting three things fails
  ambiguously.
- No case that cannot fail. If you cannot describe the failure, delete it.
- Never pad the count. Six real cases beat thirty generated ones, and a
  reviewer who finds filler stops reading the rest.

Why the “gaps” section matters

A feature can satisfy every acceptance criterion and still be wrong. The gaps group is the one that catches the defect nobody wrote a ticket for — and it is also the part a model will quietly drop if the prompt does not demand it, because it is the only section that requires reasoning about the product rather than re-reading the ticket.

Using it

Save as .claude/skills/test-cases-from-ticket/SKILL.md in the repository, or under ~/.claude/skills/ to have it everywhere.