# Spec Test Generator > Converts PRDs/user stories into stable-ID requirements (REQ-xxxx), a structured test plan, a test case catalog (TEST-xxxx), and a traceability matrix. Supports iterative updates without renumbering IDs. Ships with pragmatic internal default and strict preset. - Skill: `tomevault-io/spec-test-generator` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/spec-test-generator` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/spec-test-generator/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/spec-test-generator --- # Spec & Test Generator Skill ## Scope Use this skill when you want to transform informal requirements (PRD, user stories, notes) into **auditable engineering artifacts**: - `REQUIREMENTS.md` with stable IDs (`REQ-0001...`) - `TEST_PLAN.md` aligned to a pragmatic test pyramid - `TEST_CASES.md` with stable test IDs (`TEST-0001...`) - `TRACEABILITY.csv` linking REQ <-> TEST Default mode is **pragmatic internal**: sufficient rigor without heavy compliance overhead. A strict preset is included for regulated/high-assurance workflows. ## Inputs expected Provide one or more of: - PRD markdown file (recommended): `prd.md` - User story list / tickets export (markdown or text) - Existing spec artifacts (optional), to preserve stable IDs Optional: - Target stack info: language/framework (pytest, jest, junit, etc.) - Quality constraints (latency, security, privacy, reliability) ## Outputs produced (stable contract) Write outputs to `spec/` (or a user-specified directory): 1) `REQUIREMENTS.md` (always) - Requirements grouped by feature area - Each requirement has: ID, statement, rationale, priority, acceptance criteria, edge cases, notes 2) `TEST_PLAN.md` (always) - Unit/integration/e2e strategy - Test data strategy - Environment and CI assumptions - Non-functional test considerations (security, performance) as applicable 3) `TEST_CASES.md` (always) - Each test has: ID, title, type, priority, preconditions, steps, expected, requirements covered 4) `TRACEABILITY.csv` (always) Columns: `REQ_ID,TEST_ID,TYPE,PRIORITY` Optional: - `tests/` skeletons in the selected framework (if requested) ## Stable ID rules (critical) - Do not renumber existing REQ/TEST IDs when rerunning. - If an item is edited, keep its ID unless the meaning changes substantially. - If a requirement splits into two, keep original ID on the closest match and allocate a new ID for the new split requirement. - Maintain an internal ID map file if present (recommended): `spec/.idmap.json`. ## Procedure ### Step 1 — Parse and segment input - Identify feature areas / epics. - Extract functional requirements and non-functional constraints. - Record assumptions and clarifications needed (but do not block output). ### Step 2 — Generate requirements with stable IDs For each feature area: - Produce `REQ-xxxx` items with: - Statement (testable) - Priority (Must/Should/Could; or P0/P1/P2) - Rationale - Acceptance Criteria (Given/When/Then OR bullet checks) - Edge Cases (data bounds, concurrency, failure modes) - Notes (dependencies, open questions) ### Step 3 — Generate test plan - Propose a pragmatic test pyramid: - Unit tests for pure logic and validators - Integration tests for service boundaries (DB, cache, external APIs) - E2E tests for top user flows (not everything) - Include environment, data, and CI considerations. ### Step 4 — Generate test cases and traceability For each requirement: - Create at least one test mapped to it. - Include negative tests for meaningful failure modes. - If security/auth exists, include authz + abuse-path tests where applicable. ### Step 5 — Validate coverage - Ensure every requirement has at least one test in `TRACEABILITY.csv`. - Ensure test cases reference at least one requirement. - If strict preset: enforce stronger criteria (see policy). ## Quality gates - Every `REQ-xxxx` has at least one `TEST-xxxx`. - Acceptance criteria are objectively verifiable (avoid subjective language). - Edge cases include at least: invalid input, boundary values, and error handling. - Keep artifacts concise enough to be useful, but complete enough to implement. ## Failure modes & recovery - If input is ambiguous: list clarifications in an "Open Questions" section, but still produce best-effort requirements/tests. - If scope is huge: produce an MVP slice first and explicitly mark what is deferred. ## Templates and examples See: - `resources/examples/` for demo PRD and expected artifacts. - `resources/catalogs/` for edge-case libraries. - `policy/` for default internal policy and strict preset. --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/akz4ol) — claim your Tome and manage your conversions.