Menu
QA test case coverage requirements for /start-issue plans. Surfaces /tcs-definition during planning.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Generate a compact grep-based affected tests for all integration tests changed on the current branch. Appends a "Affected Tests" block to the finish-issue note.
Draft new QA test cases for the current issue and insert approved ones into qa-test-cases.yaml. Iteration loop draft → review → approve. Pairs with `tc-implement`.
Analyze CHANGELOG [Unreleased] against QA YAML test cases and suggest new TCs for uncovered features. Zero-argument — auto-discovers all inputs from the project.
Guided wizard for creating RangeLink demo videos and promotional materials
Conventions for creating GitHub issues — labels, sub-issues, and content rules. Auto-consulted when Claude creates or modifies issues.
| name | start-issue-hook |
| description | QA test case coverage requirements for /start-issue plans. Surfaces /tcs-definition during planning. |
| user-invocable | false |
| allowed-tools | Read, Glob |
Consulted automatically by /start-issue during context gathering. Adds QA TC coverage awareness to every issue plan.
Read packages/rangelink-vscode-extension/qa/qa-test-cases.yaml to understand current TC coverage. Note which feature sections exist and the highest -NNN per slug. Optionally glob packages/rangelink-vscode-extension/src/__integration-tests__/suite/*.test.ts to map existing test IDs by slug — this helps the plan reference which TCs already exist vs which need drafting.
The plan must include EITHER:
/tcs-definition to draft new or updated QA test cases — placed BEFORE implementation steps when feasible..claude/ skills or agents that don't touch extension runtime code.If the issue introduces, modifies, or fixes user-visible behavior (new features, changed commands, changed output, new settings, behavior-altering bug fixes), the TC-definition step is REQUIRED — do not skip with an assumption.
Prefer placing /tcs-definition as the first plan step. The skill's draft phase is spec-elicitation — running it before implementation keeps the interview focused on what the feature should do rather than confirming what was built. The skill itself warns when the diff exceeds 1000 lines because the interview drifts from spec-elicitation to implementation-confirmation.
When the TC entries depend on implementation-defined details (schema, exact output format), move the /tcs-definition step after the implementation steps but still before /finish-issue.
The /tcs-definition step body should read:
Invoke /tcs-definition to draft QA test cases for the new/changed behavior.
Once TCs are approved and inserted into qa-test-cases.yaml, implement them
one at a time with the tc-implement agent.