Test Case Generation
Capability routing
| Capability | Trigger | Output | Details |
|---|---|---|---|
| Generate cases | PRD / technical design / spec / code available; first-time case library | Complete case set with unique IDs and engineering info | generation/generate-skill.md |
| Update cases | PRD / technical design / code changed | Updated cases | maintenance/update-skill.md |
Identify the capability, then Read the corresponding document and follow it. Do not expand execution details in this file. Generate loads generation/generate-skill.md first — that file is an orchestrator; it tells you which single phase file to open next. Do not open every generation/phase-*.md up front.
Documents (load on demand)
Human-facing docs are not needed by the agent.
| File | Load when |
|---|---|
SKILL.md (this file) |
always: routing, hand-off, scripts |
generation/generate-skill.md |
generate capability: overview, global rules, resume table, checklist |
generation/phase-0-init.md … phase-3-cases.md |
only the current generate phase (see the resume table) |
generation/subagent-gen-duty.md |
dispatching a case-generation subagent; quote it verbatim |
maintenance/update-skill.md |
update capability |
README.md, HOW_IT_WORKS.md, KNOWN_LIMITATIONS.md (and their .zh-CN.md) |
human-facing; not needed by the agent |
User confirmation phrases used in the generate flow:
Confirm follow PRDItem N follow technical design
Conflict handling
- Both generate and update mentioned → ask which one to run
- Intent unclear → ask once with the two options above
Hand off instead of running this skill
This skill designs and writes cases. Three neighbouring jobs look similar in phrasing but have a different owner, and taking them on here produces work the other tool would have to redo:
| Request | Owner | Why not here |
|---|---|---|
Build the data that fills case {placeholder}s; prepare preconditions or case materials |
testdata-generation |
Cases ship with placeholders on purpose; that skill talks to real backends and backfills them |
| Write unit tests, automation scripts, or a framework harness | Write the code directly | Output here is human-executable Markdown cases, not runnable test code |
| Find defects in a branch, PR, or test plan | defect-detection |
That skill reviews code; this one never reads code for correctness, only for engineering identifiers |
A request may legitimately span two of these — "generate cases for this PRD and
prepare their data" is generate here, then hand the finished caseId list to
testdata-generation. Run this skill to completion first: placeholders can only
be backfilled once the cases exist.
Scripts
All three are plain Node with no npm install, and they exist so the agent does not have to do deterministic work by eye:
| Script | Use |
|---|---|
scripts/validate_integrations.ts |
Phase 0 of both flows: validates config and writes integrations-resolved.json |
scripts/call_integration.ts |
The only sanctioned path for spec / knowledge / config / environment lookups |
generation/quality-gates/lint_case_documents.ts |
Deterministic R4 structure checks on generated case .md; run it before judging structure by reading |
External systems
Runtime and Node flags are in compatibility above. Zero-config reads prd/ and knowledge/ only (no outbound HTTP). Enterprise HTTP: copy config/integrations.example.yaml to {workspace}/.ai-testcase/integrations.yaml; secrets only as ${ENV_VAR}. Contract: references/integration-api.md. Calls go through scripts/call_integration.ts only.