Test Case Writing Plus: Keep requirements, rules, and test cases traceable end to end
When cases come from requirements, API definitions, and a risk register, complete formatting does not prove trustworthy content. A field can disagree with the current API version, and an exception path marked in the risk register can have no matching step. If a case cannot return to its source, nobody knows which tests must change when the requirement changes.
The Test Case Writing Plus Skill builds a source ledger before it writes cases. Every important step and assertion keeps a traceable basis; conflicts and gaps remain open items instead of being quietly filled in by a model or author. It suits test assets that must be maintained over time and coordinated across several project sources.
Using an order scenario, this guide shows how to generate traceable cases from multiple sources, handle conflicts, and quickly find the tests that need review after a requirement changes.
Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with Testcase Writer Plus.
Read the source Skill first
The main prompt covers Diff vs baseline (test-case-writing), Case fields (structured; omit only with a reason), Quality Bar, Gotchas, Pre-delivery checklist. Those headings are navigation; the project artifacts still provide the facts.
The source directory contains 7 example files, 1 references, 8 script entries. Start with Analysis result example, testcase-writer-plus (EN) supporting references.
Start multiple inputs with a source ledger
Generate traceable cases from requirements, API definitions, and risks while exposing source conflicts
The plus Skills often read requirements, analysis, and planning files together. Record their authority first.
| source_id | File | Purpose | Conflict rule |
|---|---|---|---|
| RQ-01 | requirements.md | Business rules | Highest authority |
| AN-02 | analysis.xlsx | Risks and boundaries | Flag conflicts with requirements |
| PL-03 | release-plan.md | Dates and owners | Cannot override business rules |
Each strategy item or case should carry a source ID. Mark unsupported conclusions as assumptions.
Resolve version conflicts before combining files
The task is Generate traceable cases from requirements, API definitions, and risks while exposing source conflicts. Parsing is the easy part; the same fact may appear in three incompatible versions.
| Conflict | Treatment | Output status |
|---|---|---|
| Requirement supports refunds, plan has no work | Keep the rule and expose the delivery gap | blocked |
| Analysis and interface use different fields | Use the current interface version and request review | needs-review |
| Test data predates the requirement | Do not use it as evidence for new behavior | stale-source |
Store a source ID and version or update time. After generation, sample three strategy items or cases and trace them back. One unsupported item is enough to repair the source chain before handoff.
The deliverable includes a source ledger, conflict list, source-linked primary artifact, and a visible list of unparsed items.
A prompt you can adapt
Replace the bracketed fields with project facts. Specific material leaves less room for guessing.
Use the testcase-writer-plus Skill.
Task: Generate traceable cases from requirements, API definitions, and risks while exposing source conflicts
Version and environment: [requirement / build / environment]
Inputs: [file paths or links]
Scope: [included and excluded journeys]
Constraints: [accounts, data, time, compliance]
Build a source ledger and conflict order first. Add source_id to material outputs and label anything unsupported as an assumption.
Finish with open questions. Do not invent missing facts.Use the first pass to inspect structure and gaps. Supply missing material before asking for the handoff-ready artifact.
Advanced use, from one call to a maintained flow
Add a checksum or version to the source ledger. Recompute affected conclusions and emit changed, unchanged, and needs-review states.
A three-Skill chain
test-strategy-plus → testcase-writer-plus → test-case-reviewer-plus
| Handoff | Payload | Receiver check |
|---|---|---|
| Upstream to testcase-writer-plus | Source versions, scope, risks, open questions | Testcase Writer Plus staleness and conflicts |
| testcase-writer-plus to downstream | Primary artifact, evidence index, unfinished work | Testcase Writer Plus executability and owners |
| Feedback to testcase-writer-plus | Runs, defects, new risks | Testcase Writer Plus baseline and regression update |
Do not paste three complete outputs into one large prompt. Give Testcase Writer Plus a structured summary and accessible source artifacts. It saves context and makes defects traceable.
Team gates
| Gate | Check | Failure action |
|---|---|---|
| testcase-writer-plus input | Version, environment, owner, accessible sources | Stop Testcase Writer Plus and list gaps |
| testcase-writer-plus artifact | Material claims carry basis and status | Return Testcase Writer Plus for evidence |
| testcase-writer-plus execution | Command, exit status, report are reproducible | Classify infrastructure or test failure |
| testcase-writer-plus decision | Residual risks have accepter and date | Do not enter the next stage |
Review Testcase Writer Plus adoption, human edit rate, unsupported claims, and failure-to-diagnosis time each sprint. Record a baseline for several cycles before setting targets.
“Plus” does not mean “load every file”
Multi-format parsing expands context and creates version conflicts. Establish authoritative sources first. Every conclusion related to Diff vs baseline (test-case-writing) should resolve to a source ID.
Install and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/testcase-writer-plus -gInvoke it with “Use the testcase-writer-plus Skill,” then attach the real artifacts.
Two practical questions
When should I choose the plus version?
Use the basic Skill for one clear input. Choose plus when multiple files need parsing and traceability.
What if sources conflict?
Preserve the conflict, apply source authority, and mark affected conclusions.
When is human review mandatory?
Require an accountable person for scope trade-offs, risk acceptance, release decisions, and source conflicts.
What should be archived?
Keep the input version, Skill output, human edits, and final evidence so the conclusion can be reconstructed.
Run Testcase Writer Plus against one real artifact and keep the input, output, and review notes. The fragments here establish structure; project evidence must still come from the project.
References
- Awesome QA Skills project:https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills series overview:https://inaodeng.com/en/blog/ai-testing/introduction_of_awesome_qa_skills/
- Analysis result example:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/testcase-writer-plus/examples/analysis-sample.md
- testcase-writer-plus (EN) supporting references:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/testcase-writer-plus/references/local
- Awesome QA Skills: testcase-writer-plus (EN) Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/testcase-writer-plus
- Testcase Writer Plus Skill details:https://inaodeng.com/en/qaskills/testcase-writer-plus/