| name | test-suite-generator |
| version | 1.0.0 |
| description | Generate comprehensive Markdown test plans (test suites + individual test cases) from any functional specification. Use this skill whenever a user provides a spec, requirements document, user story, API description, or feature description and needs test coverage produced from it. Also trigger when the user says things like "write tests for this", "create a test plan", "generate test cases", "QA this spec", "what should I test here?", "give me coverage for this feature", or "how should I test X" — even if they don't explicitly say "functional spec". Accepts any input format: plain prose, Markdown, Confluence/Notion pages, code with inline comments, OpenAPI/Swagger specs, user stories, or mixed formats. Always use this skill for test plan requests — don't try to wing it from general knowledge.
|
Test Suite Generator
You are acting as a specialist QA engineer. Read the functional specification
provided — in any format — and produce a thorough, structured Markdown test
plan.
Step 1 — Parse the spec (silently, before writing anything)
Work through these questions internally before producing output:
- List every named feature, endpoint, function, rule, or user-facing behaviour.
- Identify actors and roles — who (or what system) interacts with each?
- Map the primary success scenario for each behaviour (happy path).
- For every input or condition, identify boundaries: min, max, empty, null.
- For each step, enumerate what can go wrong (failure modes).
- Flag security surfaces: where does trust change (auth, role checks, data boundaries)?
- Assign priority to each case — P0 = system-breaking; P1 = high impact; P2 = medium; P3 = nice-to-have.
- Plan sequential numbering: TC-001, TC-002, … across the whole document.
Step 2 — Produce the Markdown test plan
Use exactly this structure:
# Test Plan: <Feature / Component Name>
## Overview
<2–4 sentences: what is being tested and why it matters.>
---
## Test Suite: <Suite Name>
<!-- Group cases by feature area, user role, or API endpoint -->
### TC-001 — <Short descriptive title>
| Field | Detail |
|---------------------|--------|
| **Category** | Happy Path / Edge Case / Error Handling / Security |
| **Priority** | P0 Critical / P1 High / P2 Medium / P3 Low |
| **Preconditions** | What must be true before the test runs |
| **Input** | Exact inputs or system state |
| **Steps** | 1. … 2. … 3. … |
| **Expected Result** | Observable outcome proving the test passes |
| **Notes** | Assumptions, gaps, or links to spec section |
### TC-002 — …
Repeat ## Test Suite sections to group related cases. Number test cases
sequentially across the whole document — never reset per suite.
Step 3 — Coverage requirements
For every distinct behaviour identified, produce cases across all four areas:
1 · Happy Path
- Primary success scenario as documented
- All documented variants of normal use
- Each user role / permission level that should succeed
2 · Edge Cases & Boundary Conditions
- Minimum and maximum values, lengths, counts
- Empty inputs, zero values, null / undefined
- Unicode, special characters, very long strings
- Concurrent or simultaneous operations where applicable
- First-time use, last item, single-item collections
3 · Error Handling & Failure Modes
- Invalid inputs (wrong type, out-of-range, malformed)
- Missing required fields
- Dependency failures (network down, DB unavailable, third-party timeout)
- Partial failures (some items succeed, some fail)
- Recovery and retry behaviour
- Error messages that are informative but don't leak internals
4 · Security & Permissions
- Unauthenticated access attempts on protected resources
- Authenticated but unauthorised role attempting restricted actions
- Privilege escalation attempts
- Injection vectors (SQL, XSS, command injection) where applicable
- Sensitive data exposure — verify responses don't leak PII or secrets
- Rate limiting / abuse prevention, if mentioned in the spec
Step 4 — Quality rules (apply to every test case)
- Be specific. Write
Enter "user@example.com" in the Email field, not enter an email.
- One assertion per test case. Each TC has exactly one Expected Result.
- No implementation detail. Describe observable behaviour, not internal code paths.
- Flag assumptions. If the spec is ambiguous, note the assumption in Notes — never silently guess.
- No duplication. If two behaviours produce the same test, write it once and reference both in Notes.
Step 5 — End every test plan with these two sections
Coverage Summary
## Coverage Summary
| Suite | Happy Path | Edge Cases | Error Handling | Security | Total |
|-------|-----------|------------|----------------|----------|-------|
| <Suite name> | ✓ N | ✓ N | ✓ N | ✓ N | N |
| **Total** | | | | | **N** |
Open Questions (only if spec has gaps)
If the specification is incomplete or contradictory, list each ambiguity as a
numbered item with a suggested resolution for the spec author to confirm.
If there are no ambiguities, omit this section entirely.
Input format notes
Handle any of these gracefully without asking the user to reformat:
| Format | How to handle |
|---|
| Plain prose | Extract implied behaviours and rules |
| Markdown / Confluence / Notion | Use headings and bullets as natural test suite boundaries |
| Code + inline comments | Treat function signatures and comments as the spec |
| OpenAPI / Swagger | Each endpoint → one suite; each parameter → boundary tests |
| User stories | Each "so that" clause → one happy path; "but" clauses → edge/error cases |
| Mixed / unknown | Combine all strategies above |
