Test Cases Generator
Turns PRDs or user requirements into structured test cases covering functional, edge, error and state transition scenarios.
The skill only reads a user-provided PRD and writes markdown into tests/: least privilege, no external side effects, no dependencies or network calls, transparent data flow. Deducted for: no explicit confirmation/rollback guidance for overwriting existing files or for sensitive data leaking into generated test cases; publisher attribution unverified.
Workflow steps are self-consistent with complete templates and checklists, plausible on the happy path; but it is a pure prompt skill with no own tests, and failure feedback for abnormal inputs (empty PRD, bad file path) relies solely on AskUserQuestion — error handling is thin, so no score above 10.
Triggers are clearly described (test case generation, QA planning), output format explicit with a Chinese summary requirement; no reliance on overseas services. Deducted for: undeclared non-fit boundaries (e.g., performance/security testing only hinted via prefixes) and no evidence of precise semantic triggering.
Well-layered docs (SKILL.md plus references) with examples and checklists. Deducted for: license contradiction — frontmatter says MIT while the repository is AGPL-3.0; no versioning, changelog, or explicit maintenance responsibility for this skill.
Core goal (requirements to structured test cases) is sensible with usable templates; but static review cannot confirm outputs are directly usable, and there is no representative-output evidence for complex PRDs, so capped at 7.
Only author-authored instructions and a reference doc; the CI tests target codeagent-wrapper and the harness skill, not this skill's key paths. No third-party execution evidence covers this skill, leaving only thin auditable material.
- Note the license conflict: SKILL.md declares MIT while the repository is AGPL-3.0; verify the applicable terms before use.
- The skill writes directly into tests/ and may overwrite same-named files; back up first.
- Generated test case quality depends on PRD input quality; manually review the coverage matrix.
- Publisher identity is unverified; reliance on future maintenance is uncertain.
What does this skill do, and when should you use it?
test-cases is one of the standalone skills bundled in the stellarlinkco/myclaude repository. It transforms product requirement documents or verbally described requirements into structured Markdown test case documentation. It follows a pragmatic testing philosophy: every requirement must map to at least one test case, and requirement-to-test traceability is maintained throughout. Output is organized into functional (TC-F), edge case (TC-E), error handling (TC-ERR), and state transition (TC-ST) categories, complete with a coverage matrix. The skill ships as part of the repository's 11-skill collection installed via an interactive installer.
Reads a PRD file or captures verbally described requirements; when requirements are unclear, it asks the user (via AskUserQuestion) about core flows, acceptance criteria, edge cases, and state transitions. It then extracts four scenario categories — functional, edge case, error, and state transition — annotating each with preconditions, test steps, expected results, and postconditions. It generates test cases with unique IDs (TC-F/TC-E/TC-ERR/TC-ST), priority levels, and requirement traceability links; validates that every requirement has at least one covering test case and produces a coverage matrix. Finally it writes the document to tests/<name>-test-cases.md using the Write tool and summarizes the case count and coverage breakdown in Chinese.
- A QA engineer receiving a product manager's PRD who needs a complete test case document covering functional, edge, and error scenarios before manual testing begins
- A test lead who wants to verify every requirement has corresponding coverage, using the coverage matrix to surface testing gaps
- A developer who just built a stateful feature (order flow, session management) and needs to systematically enumerate all valid state transition tests
- A team member with vague requirements who benefits from the skill's built-in clarifying questions (core flows, acceptance criteria, boundary conditions) before case generation
- Teams that want test documentation archived in a consistent Markdown template under tests/ for version control and collaboration
What are this skill's strengths and limitations?
- Enforces requirement-to-test traceability; the coverage matrix makes testing gaps immediately visible
- Clean four-category structure (functional, edge, error, state) with a consistent ID convention
- Output is plain Markdown with no script dependencies — easy to review, archive, and version
- Built-in clarification step asks the user questions instead of guessing on vague input
- Includes a self-check quality checklist and coverage validation before finalizing
- Produces only static test case documents — it executes no actual tests or automation scripts
- Output quality is bounded by input quality; a vague PRD yields vague test cases
- References references/testing-principles.md, whose contents are not in the source, so depth cannot be verified
- SKILL.md is marked MIT while the repository is AGPL-3.0 — an inconsistent license situation requiring clarification before commercial use
- No dedicated test suite or user feedback evidence for this skill in the repository
How do you install this skill?
Install the whole collection: run npx github:stellarlinkco/myclaude for the interactive installer, or run npx github:stellarlinkco/myclaude --list first to see installable items (test-cases appears in the skills list). Default install directory is ~/.claude; use --install-dir to change it and --force to overwrite. The source does not document whether test-cases can be installed standalone.
How do you use this skill?
Trigger it in Claude Code with natural language, e.g.: "Generate test cases for the user authentication feature in docs/auth-prd.md". The skill reads the PRD, extracts requirements, and writes results to tests/auth-test-cases.md. You can also describe requirements verbally; incomplete requirements prompt clarifying questions. Any request mentioning "generate test cases", "create test scenarios", or "plan QA" triggers the skill.