Test Case Writer Skill

Good test cases are unambiguous and complete: anyone can run them and get the same result, and together they cover the ways the feature can succeed and fail. This skill derives test cases from a requirement or user story — happy path first, then the edge and negative cases that find real bugs — each written so it's directly executable.

Working from a brief

Given a user story or a one-line feature description, write the test cases anyway — infer the acceptance criteria, boundaries, and likely failure modes, labelling assumptions. Always include edge and negative cases, not just the happy path. Never hand back questions instead of cases.

Required Inputs

Ask for these only if they aren't already provided (else infer and label):

• The requirement — the feature/user story and its acceptance criteria.
• Inputs & rules — fields, valid/invalid values, limits, and business rules that define correct behaviour.
• Scope & environment — UI/API/both, platforms, and any preconditions (logged-in, data state).
• Priority — what matters most (critical paths), so cases can be ordered.

Output Format

Test Cases: [feature]

A short intro line, then cases in a table (or per-case blocks for complex flows):

ID	Title	Type	Preconditions	Steps	Test data	Expected result	Priority
TC-01	Valid login	Happy path	user exists	1. … 2. …	valid creds	logged in, lands on …	High
TC-02	Wrong password	Negative	user exists	…	bad password