| name | test-case-generator |
| description | Generate structured QA artifacts from requirements and code changes, including phased test plans, bucketed test scenarios, and executable-style test cases. Use when Codex needs to turn a PR, diff, spec, ticket, Jira story, or pasted requirement text into thorough manual or automation-ready test coverage with traceability back to the requested behavior. |
Test Case Generator
Create a test plan first, then generate test cases from that plan. Keep the plan and the cases traceable to the requirement source and to the changed code.
Workflow
1. Gather the minimum viable inputs
Collect as many of these as the user already has:
- requirement source: Jira ticket, issue URL, spec doc, or pasted requirement text
- code-change source: PR URL, commit range, patch file, or pasted diff
- repository or relevant files if local code inspection is needed
- target output shape: test plan only, test cases only, or both
- target format: markdown, JSON, XML, CSV, or framework-ready cases
If a remote system cannot be accessed because auth, tooling, or network is unavailable, ask for pasted text or an exported diff instead of blocking.
2. Normalize the source material
Create a short working summary before generating artifacts:
- primary user goals and acceptance criteria
- impacted surfaces, roles, and workflows
- changed modules, endpoints, UI areas, or data paths
- explicit risks, edge cases, and non-goals
- missing information that should be called out as assumptions
Treat this summary as the contract for the rest of the workflow.
3. Build the test plan
When the user wants a structured plan, read planning_prompt.md and adapt it to the task.
Use the planning phase to:
- map requirements to changed code
- identify gaps between the story and the implementation
- decide which coverage buckets are actually relevant
- define scope, environment, data, risks, and exit criteria
- avoid duplicating previously covered scenarios when the user provides existing tests
Return the plan in the format the user asked for. If no format is specified, prefer markdown or JSON over XML for the planning artifact.
4. Generate test cases from the plan
When the user wants concrete scenarios, read generation_prompt.md and adapt it to the requested output format.
Generate tests bucket by bucket. Prefer quality over volume:
- do not invent functionality not described in the requirement or implied by the code
- stop when unique, relevant scenarios are exhausted
- include clear preconditions, steps, and measurable expected results
- keep every test traceable to a requirement or changed behavior
- write automation-friendly language when the user wants Playwright, API, or PyTest style cases
5. Deliver a useful result
Match the deliverable to the request:
- concise exploratory checklist for lightweight asks
- structured markdown table for manual QA reviews
- XML only when the user explicitly needs importable XML or an XML-like schema
- framework-oriented cases when the user wants automation guidance
Include assumptions, uncovered risks, and any blocked areas caused by missing access or missing acceptance criteria.
Operating Guidance
Prefer local inspection first. If the repo is available, inspect the changed files directly in addition to any PR summary.
If the user provides a PR URL and local git checkout is unavailable, use gh pr diff only when authentication and network access are available. Otherwise ask for a pasted diff.
If the user provides a Jira ticket and it cannot be fetched, ask for the story text rather than halting the workflow.
For large requests, segment coverage into buckets such as:
- installation or setup
- deletion or teardown
- API key or credential handling
- generation quality or business logic accuracy
- interfaces and integrations
- traceability
- performance and limits
- reliability and resilience
- security and compliance
- accessibility
- end-to-end workflows
- concurrency and race conditions
Only include buckets that are relevant to the story and code changes.
Output Standards
Keep the final artifact actionable:
- title each case so it is meaningfully distinct
- use specific data, selectors, payloads, limits, or responses when known
- call out whether a case is manual, API-driven, UI-driven, or automation-ready
- note coverage gaps explicitly instead of padding with low-value scenarios
When generating XML, ensure special characters are escaped and the document is well formed before returning it.
