cawplan-testcase-generate

CawPlan TestCase Generate

Reply in the user's primary language; do not output Chinese and English simultaneously in the same paragraph. The use case content itself follows the language of the test point/five fields.

Bootstrap

cawplan skill check

Highest priority: source value fidelity

The specific wording, error codes, thresholds, counts, lengths, and enumerations in Title / Preconditions / Step / Expected may only come from the test point or the five fields.
If given verbatim in the source, carry it into Title / Expected as-is, without abstraction, paraphrase, or an added honesty tail; if not in the source, use a directional description or the fixed tail defined by the writing specification, and do not invent hard values.
For detailed determination and fixed tails, see references/testcase-writing-spec.md; design methods must not override this rule.

Read Reference by action

For each request, read the entire file once according to the current action; do not re-read for each TestPoint:

Current action	Read content
Generate or regenerate a Case set from a TestPoint	`references/test-design-methods.md` + `references/testcase-writing-spec.md`
Only expand the details of an existing Case	`references/testcase-writing-spec.md`
Trigger box 1 to box 5	Read completely `references/interaction-prompts.md`, use the corresponding box
`as_is` Export	`references/csv-template-mapping.md`
`fill_then_export`	Writing specification + CSV mapping; unless rebuilding the Case set, do not re-read the design method

The final template for the CSV column layout is assets/testcase-template.csv。

Interaction box execution contract

When box 1 to box 5 is matched, before any user-visible reply, read completely references/interaction-prompts.md, and actually call AskUserQuestion according to the corresponding box; do not replace the popup with numbered options in ordinary chat. Only when the current runtime environment does not provide AskUserQuestion, or the tool call explicitly fails, use the corresponding verbatim fallback in that Reference. "Render box N" below means executing this contract.

Workflow

1. Resolve target Requirement

For each generation request, fall through in order:

Priority	Condition	Action
P1	Explicit Requirement link,`display_id`、`requirement_id` or switch target	Cold handoff, full rebind
P2	Hot handoff phrasing and an existing valid binding	Use the current binding
P3	The session has a Requirement or TestPoint draft, but no valid `requirement_id`	Trigger box 3
Fallback	No link, no valid binding, no draft	Trigger box 1

A valid binding must simultaneously contain product_id and requirement_id. Hot handoff includes "generate test cases immediately", "generate use cases based on the above", "continue generating/expanding use cases" and equivalent English; when there is no binding, continue to fall through. Unarchived fast-path is not supported, and drafts must not be carried into GET.

Box 1 · Lock Requirement

When there is no target and no draft, read the interaction copy Reference and render box 1; valid P1/P2 does not trigger it. Do not add a "use the one produced above" option.

"Existing Requirement link or number" → wait for the link or REQ- number; after receiving it, parse it as below; if it cannot be parsed, restate the options or ask to reselect.
"No Requirement" → write resume_intent = testcase, read the cawplan-requirement-analyze Skill handoff.

Box 3 · Requirement is not yet saved

When P3 or a test point draft/table exists but there is no requirement_id , read the interaction copy Reference and render box 3.

"Save immediately" → write resume_intent = testcase, follow the save/archive and original confirmation gate of cawplan-requirement-analyze ; after success, return to §2.
"Do not save yet" → stop.
Other / free-form reply → handle or restate per instructions.

Routing and parsing

Test point outline/coverage/"generate test points" → cawplan-testpoint-generate。
Analyze requirements/five fields/archive Requirement → cawplan-requirement-analyze。
Generate, expand, or export test cases → this Skill.
Already have cases[] when the user again vaguely says "generate test cases", first ask "regenerate" or "adjust/expand based on the existing one", to avoid overwriting SQA edits.

Requirement references are resolved in the following order:

Valid product_id + requirement_id takes priority; use it directly, without calling a display-id lookup.
Legacy Portal URLs are only parsed as strings, never request the page:

/product/{product_id}/qa-insights/test-suites/requirements/{requirement_id}

Bare display_id must strictly be REQ- + number (^REQ-\d+$); or use a Browse URL:

/browse/product/{product_key}/qa/requirement/{display_id}

For bare display_id or Browse URL calls (full URLs must be shell-quoted):

cawplan qa-insights requirements resolve '<display_id_or_browse_url>'

This command first locally validates/extracts display_id; on malformed input it does not call the API. The Browse URL's product_key(such as CP) is not product_id, and must not be used to infer a UUID.
SUCCESS: complete rebind only when both meta.product_id and meta.requirement_id exist, and record this response's data directly as requirement_data. The CLI has validated and resolved these two IDs from the API data.url ; do not switch to data.redirect_url. Then enter the display-id fast-path in §2, and do not call requirements get。
FAILURE / validation: indicate that the display ID must be REQ- + number, and do not enter GET.
FAILURE / not_found: indicate that the Requirement does not exist and stop. For other FAILURE or UNKNOWN , report truthfully, do not guess an ID or continue.
SUCCESS but missing the two resolved IDs is treated as an abnormal response; stop.

All URLs are parsed as strings only; do not call cawplan api or HTTP on Portal/Browse pages. Only when requirement_id ask for product_id or the full reference, and do not scan the product. An explicit new target replaces the full context only after complete successful resolution; a failed resolution does not clear the old binding or cases[]. Bind only one Requirement at a time.

Cross-Skill handoff

Box 1 "no Requirement", box 3 "save now", and box 2 "generate test points now" write resume_intent = testcase。
After A1/A2 complete, return to §2 per that intent. A2 only generates and presents test points, and does not auto-archive; continue only after SQA confirms archiving. If the user only says "looks good" without archiving, box 2 should still be triggered again after refresh.
After A2's success receipt, under a valid binding, saying "generate test cases now" goes directly to P2 → §2, with no need to repost the data.

2. Refresh before expand

Silently obtain the latest Requirement data for this session, and uniformly record it as requirement_data：

If this session just successfully executed requirements resolve: use that command's datadirectly; it and requirements get return the same Requirement five-field structure. In this session, do not call again requirements get。
Valid product_id + requirement_id, legacy Portal URL, hot handoff, or cross-Skill recovery: execute:

cawplan qa-insights requirements get <product_id> <requirement_id>

After obtaining requirement_data via either of the above two paths, both must execute:

cawplan qa-insights testpoints list <product_id> <requirement_id>

Requirement data source SUCCESS: uniformly use the five fields in requirement_data ,module_tree_node_id , and metadata.
TestPoints SUCCESS: use according to data.test_points[].sort_order ; map id → TestPointId、title → TestPointTitle、tags[] → / Concatenate Tag,group → Group。
404 / not_found: Report truthfully; do not use stale session data.
FAILURE or UNKNOWN: Report truthfully; do not fake success, blindly retry, or guess.
The five fields, especially constraints and when the test point was created, have changed: before expanding, output a lightweight uncertainty note; do not silently ignore.

The display-id fast-path only eliminates duplicate GETs immediately adjacent to the resolver within the same request; it does not establish a cross-turn cache. Subsequent new hot-relay turns or recovery after A2 completion still follow the non-fast-path execution described above requirements get, then refresh TestPoints.

3. Hard stop without TestPoints

After refresh, test_points.length === 0 must not create a Case; read the interaction copy Reference and render Box 2; this branch is mutually exclusive with unarchived Box 3.

"Generate test points now" → write resume_intent = testcase, read cawplan-testpoint-generate; after successful archiving, return to §2.
"First look at the requirement content" → display the five fields already fetched in §2, then wait for a decision.
Other / free-form reply → handle as instructed or restate.

4. Build and expand `cases[]`

cases[] is the source of truth for work within the session. In the first turn, first generate the title-state Case set; thereafter, expand details only when named by the SQA.

Case admission invariants

A Case is a coherent, independently executable core verification scenario; one TestPoint can expand into multiple Cases. A Case may contain multiple Steps/Expected; do not split a Case merely because there are many checkpoints.
As long as inputs, boundaries, exceptions, roles, entry points, environments, and states directly affect the parent TestPoint's path, boundaries, or expected results, they may serve as necessary concretizations; keep only the minimal sufficient scenario and do not make a mechanical Cartesian product.
Each Case must be attached to an existing parent TestPoint, and the main path for archiving testPointId must be non-empty. Coverage gaps that cannot be attributed go into uncertainty and back to A2, and do not enter cases[], preview, or export; Cases verbally added by the SQA also follow this rule.
Splitting/merging, EP, multiple objects, discrete/continuous, and field wording follow the writing conventions. Proactive scenario construction belongs to Steps; each Step corresponds to exactly one non-empty, decidable Expected, and the signal is not limited to UI.

When there is no parent test point, the uncertainty copy follows the session language:

这一块没有对应的测试点,回去补一条测试点、刷新后再展开。 There's no matching test point for this — go back and add one, then refresh and expand it.

Per-TestPoint Completion Criterion

Do not process the next one until the same parent TestPoint satisfies all of the following conditions:

Values, branches, constraints, and states explicitly stated in the source have all been handled; discrete values or categories that the source explicitly requires to be covered have each been made into one Case item by item, not merged with "respectively/each/consistent with the selected".
Directly relevant and necessary equivalence classes, boundaries, exceptions, and state transitions have been covered with minimal sufficient scenarios, with no combinatorial explosion.
Each candidate is a coherent core scenario that can be executed independently; sequential checkpoints of the same execution are still paired within the same Case.
Duplicates of the same failure mode have been merged according to the writing conventions; candidates outside the parent goal have been moved to uncertainty/A2.

5. Content state and expansion routing

State	Output	Trigger
Title only	Four-column header table chunked by Group	Default first turn
Partial	Output only the expansion block for the Case named this time	"Expand item X", etc.
Full	After filling in Cases not yet expanded, output expansion blocks for all current Cases	SQA actively says "expand all"

The detailed Preconditions / Steps / Expected must be generated together with the Case; Partial does not proactively choose a Case on behalf of SQA.

Large-batch routing

Partial's batchCount is the number named this time; Full is the number not yet expanded currently, unrelated to the total pool size and the number already expanded.

batchCount <= 10: expand directly, do not ask.
batchCount > 10 and the request contains no no-routing statement stronger than "expand all": read the interaction copy Reference, render only Box 4, and do not lay out steps first. "Expand all" itself only selects the Full tier and does not count as no-routing.
The user has explicitly said things like "no matter how long it is, lay it all out; don't ask, expand all": treat as "lay it all out", and do not trigger Box 4.

Box 4 placement:

Choice	Action
Lay it all out	Expand this batch's Markdown, then output the Partial/Full hint
Export all with steps	Do not lay out the conversation; silently fill in the unexpanded Cases, set `exportMode = fill_then_export`, and after self-check directly export and send the receipt, skipping Box 5
Do not expand for now	stop, wait for a smaller scope

Box 4 is carrier routing, not a confirmation gate; it must not be changed to "whether to continue".

6. Preview and review

Sole rendering rule

Preview uses only in-conversation Markdown; do not use artifacts, interactive components, or HTML.
Title/Partial/Full must all be chunked by Group, even if there is only one Group. The chunk starts with ### {Group}; the title table has fixed columns # / 用例标题 / 优先级 / 父测试点, and a "Group" column must not be added.
Partial/Full use #### heading rows under the corresponding Group, retaining the number, Title, Priority, and parent test point, then list Preconditions / Step / Expected.
The "Parent test point" column is fixed to take cases[].testPointTitle, and must not display testPointId、display_id or other IDs. The first row of each Group must write the complete testPointTitle; only when this row is not the chunk start and the cases[].testPointTitle is verbatim identical to the immediately preceding row in the same chunk may the display layer write "same as above". Chunk boundaries reset, and "same as item N" is forbidden.
cases[], interim JSON, and CSV always save the complete testPointTitle and group; "same as above" belongs only to Markdown.
After SQA modifications, redraw only the affected areas: if the title is changed, redraw that Group's title table; if steps are changed, redraw only that Case's expanded block. Already expanded content still remains in cases[]。

Preview self-check

Before rendering, fix deterministic errors first, then output:

The parent test point column shows an ID, is empty, or the first row of a Group writes "same as above/same as item N" → directly use that Case's complete testPointTitle hard fix.
steps / expected If unequal in length or has empty elements → hard fix according to the writing conventions; if the source is insufficient for reliable pairing, stop and ask SQA to fix.
The title loses the source's verbatim value or is wrongly attached with an honesty tail → hard fix cases[].title. If the expanded Expected is suspected of not retaining the source value, only mark ⚠源已有文案未保留, do not automatically overwrite; retaining only the fragment relevant to that step in a long source sentence may be legitimate.
The parent test point or five fields explicitly require coverage of multiple discrete values/categories, but are summarized into one Case by "respectively/each/consistent with the selected" etc. → split item by item according to the writing conventions and then render; when the source only gives examples or it cannot be determined whether item-by-item coverage is required, do not expand on your own.

Other soft prompts: incorrect "same as above" reference is marked ⚠同上引用错误; Step mixed with a verification verb is marked ⚠疑似预期混入步骤; Expected using a suspected unsourced specific value is marked ⚠具体值待核. When the parent title has only a suspected multi-value signal but it cannot be confirmed whether it is a mandatory discrete checklist, return to the writing specification for review and may mark ⚠疑似未展开取值清单；Config/Idea/Storyboard and similar process stage names are not mis-split because of this.

Self-review timing

Execute once before the first title-state preview, and once before assembling the export JSON.fill_then_export The second check must come after the silent completion. Check the Completion Criterion, source value fidelity, and absence of orphan Cases, and reference the writing specification to verify splitting/merging and the field contract; do not show the checklist to SQA.

The line-start label for SQA edits is 【已调整】 / 【新增】 / 【存疑】. Deleted items retain a trace in the "Removed" section at the end of the preview, with an in-memory flag status: 'removed'. The doubtful list uses "〔points to what〕+〔why doubtful〕+〔suggested action〕"; if none, write "None".

Push Priority from P0–P3 per the writing specification.

7. Confirmation boundary

Action	Confirmed
Title state or expanded preview	No
SQA actively exports CSV	No file-write confirmation is added, but go through Box 5 first; except when Box 4 has already selected export
Delete, change title, or SQA-specified adjustment	No; update memory and partially redraw, do not auto-export
Regenerate the entire Case set	Yes; will clear `cases[]` and all manual edit/delete traces, then rebuild from the GET data

8. Export

Write CSV only when SQA actively requests export, or when Box 4 selects "Export all with steps". When directly saying "export CSV", read the interaction copy Reference and render Box 5; must not skip.

Box 5 landing options:

"Export current draft" → exportMode = as_is; keep unexpanded Cases as steps: [] / expected: [], and the receipt states it is not a final executable test case.
"Export all with steps" → exportMode = fill_then_export; per the writing specification, silently complete all unexpanded Cases, update cases[], do not lay them out in the conversation, then run the pre-export self-check.

After mode processing:

Filter status: 'removed'; do not write removed lines or status into the snapshot.
Perform a final fallback check on the expanded Step/Expected; fix cases[]first, and only when it cannot be reliably fixed reject the export and ask SQA to complete it in the preview; do not directly dump stderr.
Read references/csv-template-mapping.md, and call scripts/export_to_csv.jsper the interim JSON contract therein. Do not hand-write CSV, inline CSV, or temporarily rewrite the export logic.
When the script fails, report stderr truthfully, fix the upstream JSON, and retry. Export does not lock the working state and can be executed multiple times.

9. Present

Entry silence

From parsing and reading the Requirement, refreshing TestPoints, to before the first title list, do not output internal processes or IDs. Except for missing product_id, 404/read failure, Box 1/2/3 hard stops, and five-field drift doubts.

When successfully entering the first title round, the first visible output uses exactly one of the following verbatim, where{N} is the TestPoint count, without inserting the Requirement display title:

Read the requirement and {N} test points — listing test case titles by test point first (steps not yet expanded):

Output the corresponding Markdown preview, one status hint, and the doubtful list. Do not proactively lay out all Cases; whether Full is released is judged only by the result of §5 "Large-batch triage".

Hints (choose one of two based on session language):

Title：要改就直接说(改标题、增删);想看某条用例步骤说「展开第 X 条」;要导出就说「导出 CSV」。 / Just tell me if you want changes (edit title, add/remove); say "expand case X" to see its steps; say "export CSV" to export.
Partial：这 N 条的步骤已展开。想看别的就说「展开第 X 条」或「全部展开」;要导出就说「导出 CSV」(未展开条目只有标题,属于草稿)。 / Steps for these N cases are now expanded. Say "expand case X" or "expand all" to see more; say "export CSV" to export (un-expanded entries have titles only and remain draft items).
Full：全部 N 条已展开完毕。要导出就说「导出 CSV」。 / All N cases are now expanded. Say "export CSV" to export.

After export, output only the thin receipt and the questionable-items list; do not output the Case body:

Status:已导出:<路径>。 / Exported: <路径>.
Refs：CSV 已含 Refs 列;导入 TestRail 时映射到 References 后,可用 testrail-link 回链用例。 / The CSV includes a Refs column; map it to References when importing into TestRail, then use testrail-link to link cases.
fill_then_export Append:已把未展开用例补齐步骤后导出(对话未铺开)。 / Un-expanded cases had their steps auto-filled before export (not expanded inline in this conversation).
as_is And when there are still unexpanded entries, append:这是当前草稿;未展开条目只有标题,不作为最终可执行用例。 / This is the current draft; un-expanded entries have titles only and are not final executable cases.

Do not use "script/脚本" as product wording with SQA. CSV is an export snapshot; Markdown is the session working state.

Session state

Binding：product_id、requirement_id、requirement_data the latest five fields in module_tree_node_id, and the TestPoints obtained by GET.
Draft: in memory cases[]. Partial turns render only the rows named this time, and may include "Expanded: #1,#3"; previously expanded content continues to be retained.
No disk state: do not create .memory or cross-session cache; interim JSON exists only in /tmp/at the instant of export, and is deleted afterward.
v1 does not support offline CSV edit round-trip, no is_edited; A3 does not POST/PATCH CawPlan.

References

references/test-design-methods.md — discover necessary candidate scenarios from the parent TestPoint
references/testcase-writing-spec.md — fields, splitting/merging, priority, and calibration examples
references/interaction-prompts.md — complete bilingual text and fallback for Box 1 to Box 5
references/csv-template-mapping.md — interim JSON, 13 columns, script invocation, and export format