Prd To QA Cases

PRD to QA Cases

Pipeline Context

This skill generates QA test cases, typically as part of Stage 3 of the Spec Pipeline (Build Plan) to define detailed test coverage.

Related stages:

• Stage 1: Foundation Spec (What + Why) — See design/product-spec or use design/references/foundation-spec-template.md
• Stage 2: UX Spec (How it feels) — See design/product-spec or use design/references/ux-spec-template.md
• Stage 3: Build Plan (How we execute) — See design/product-spec or use design/references/build-plan-template.md

Shared references:

• design/references/build-plan-template.md — Build Plan template
• design/references/spec-linter-checklist.md — Quality gate checklist

Response format (strict)

The first line of any response MUST be ## Inputs.

Cognitive Support / Plain-Language

• Optimize for low cognitive load (TBI support): one task at a time, explicit steps.
• Use plain language first; define jargon in parentheses.
• Keep steps short and checklist-driven where possible.
• Externalize state: decisions, assumptions, and the next step.
• Provide ELI5 explanations for non-trivial logic.
• Ask one question at a time; prefer multiple-choice when possible.

Every response must include:

• ## Inputs
• ## Outputs
• ## When to use

Generate QA test cases from acceptance criteria.

Traceability matrix (required)

| Acceptance Criteria | Test Case ID | Test Type | Status |
| --- | --- | --- | --- |
| | | | |

Test case template (Given/When/Then)

**Test Case ID:** TC-001
**Given** ...
**When** ...
**Then** ...

Output location

Write QA cases in the same directory as the source PRD.

• feature-x.md -> feature-x-qa-cases.md

Required sections

1. Test case list (Given/When/Then + expected result)
2. Coverage map (criteria -> cases)
3. Manual vs automated split
4. Data and environment prerequisites

Constraints

• Keep each test case atomic and independent.
• Redact secrets/PII by default.

References

• Contract: references/contract.yaml
• Evals: references/evals.yaml

Scope and triggers

• Use this skill when the task matches its description and triggers.
• If the request is outside scope, route to the appropriate skill.

Required inputs

• User request details and any relevant files/links.

Deliverables

• A structured response or artifact appropriate to the skill.
• Include schema_version: 1 if outputs are contract-bound.

Constraints

• Redact secrets/PII by default.
• Avoid destructive operations without explicit user direction.

Validation

• If findings are disputed or high-risk, run LLM Council and merge outcomes per design/product-spec/references/llm-council.md.
• Run Golden Nuggets 2026 checklist in design/product-spec/SKILL.md (section: Golden Nuggets 2026).
• Run any relevant checks or scripts when available.
• Fail fast and report errors before proceeding.

Philosophy

• Favor clarity, explicit tradeoffs, and verifiable outputs.
• Given/When/Then is a contract—test cases must be executable and unambiguous.
• Atomic tests are maintainable—avoid interdependencies that make debugging impossible.
• Edge cases matter more than happy paths—bugs live in the shadows.

Empowerment

• The agent is capable of turning acceptance criteria into comprehensive, executable test cases.
• Use judgment to identify high-risk user flows that need deeper test coverage.
• Enable QA teams to ship with confidence through structured, verifiable test suites.

Variation

• Adapt test granularity to product stability: stable features need fewer regression tests, experimental features need exploratory tests.
• Vary automation focus: API-heavy products need automated integration tests, UX-heavy products need manual exploratory tests.
• For data products, expand on data validation and boundary condition tests.
• For security products, expand on auth, authorization, and attack surface tests.
• Adjust test case detail based on team skills—junior QA teams need more explicit steps.

Guiding questions (ask 2-3)

• What is the most critical user journey to protect?
• Which acceptance criteria have the highest risk of regression?
• What failures would be catastrophic in production?

Procedure

1. Clarify scope and inputs.
2. Execute the core workflow.
3. Summarize outputs and next steps.

Anti-patterns

• NEVER skip Given/When/Then structure—vague test cases are untestable and unmaintainable.
• DO NOT create dependent test cases—each test must be atomic and independent.
• Avoid testing happy paths only—edge cases and error states reveal the most bugs.
• DO NOT omit expected results—tests without assertions are meaningless.
• NEVER ship QA cases that do not map to acceptance criteria.

Response format (required)

The first line of any response MUST be ## Inputs. Every user-facing response must include these headings:

• ## Inputs
• ## Outputs
• ## When to use

Examples

• "Use this skill for a typical request in its domain."

Failure/out-of-scope template (use verbatim structure):

## Required inputs
Objective: <what you received>

Plan:
1) <brief>
2) <brief>

Next step: <single request>

## Deliverables
- <what would be produced if in scope>

## Scope and triggers
- <when this skill applies>

Philosophy and tradeoffs

• Use this skill when consistent decision-making matters more than one-off execution because project context should drive the approach.
• Principle and mindset: prioritize tradeoffs and constraints over rigid checklists; understand why each step exists.
• Ask this to keep outcomes robust: Why is this the right default, and what could change this outcome?
• How do we adapt if constraints shift?
• What evidence is needed before choosing one path over another?

Anti-patterns and caveats

• Avoid applying this playbook generically without checking repository-specific context.
• NEVER skip required validation gates when behavior changes.
• DO NOT use this skill as a rigid replacement for engineering judgment.
• DON'T ignore warnings or assume one pattern fits all repos.
• Common pitfall: treating anti-patterns as optional.
• Incorrect assumptions here can lead to fragile guidance.
• Warning: wrong sequencing can create avoidable regressions.

Variation and adaptation

• Vary the workflow by team size, risk, and deployment target.
• Use different strategies for small, medium, and large changes.
• Adapt recommendations to the specific environment and avoid repetitive templates.
• Avoid generic or cookie-cutter responses; craft context-specific alternatives.
• Keep outputs diverse and not repetitive.
• Converge on a custom path only after evidence review.
• Different constraints should produce different, non-generic recommendations.

Empowering execution style

• Be capable of exploring multiple options and enabling the team to make safe decisions.
• Unlock confidence by explaining options and tradeoffs clearly.
• Feel free to be creative while staying rigorous and precise.
• Push boundaries with practical alternatives when simple recipes fail.
• Enable outcomes-oriented problem solving.