- Home
- Skills
- Mattgierhart
- Prd Driven Context Engineering
- Prd V07 Test Planning
prd-v07-test-planning_skill
- Python
17
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill mattgierhart/prd-driven-context-engineering --skill prd-v07-test-planning- SKILL.md8.2 KB
Overview
This skill defines test cases before implementation to ensure every API, business rule, database table, and user journey has verifiable acceptance criteria during PRD v0.7 Build Execution. It converts EPIC-, API-, DBT-, BR-, and UJ- inputs into formal TEST- entries in Given–When–Then format. Use it to enforce a test-first contract that feeds the v0.7 Implementation Loop and CI/CD pipelines.
How this skill works
On trigger phrases like "define tests" or "test planning", the skill ingests EPIC- scope and linked IDs (API-, DBT-, BR-, UJ-) and generates TEST- entries. For each artifact it produces appropriate test types (Unit, Integration, E2E, Contract, Performance) with happy and error paths, boundary cases, and validation method and automation hints. Outputs follow a consistent TEST- template ready to be linked back to the EPIC and used for automation and review.
When to use it
- At PRD v0.7 Build Execution when scoping an EPIC
- When asking "what to test?" or requesting "test coverage" for APIs, rules, DB schema, or journeys
- Before any implementation work or PR to define acceptance criteria
- When preparing CI/CD test suites and automation plans
- To convert BR-, API-, DBT-, UJ- artifacts into traceable TEST- entries
Best practices
- Write TEST- entries before coding so tests become the contract for "done"
- Ensure every API- has at least one happy path and one error case test
- Create one BR- test per rule including positive, negative, and boundary cases
- Define one E2E TEST- per core UJ- to validate full user value flow
- Mark critical tests for automation and provide file path guidance for implementers
Example use cases
- Generate TEST- entries for a new user signup EPIC with API-, BR-, DBT-, and UJ- links
- Plan test coverage for an API surface: happy path, auth failure, validation error
- Define DB constraint tests for a new table and RLS policy enforcement
- Produce E2E onboarding tests that verify KPI events and session state
- Create unit tests for rule validation functions (password rules, uniqueness)
FAQ
Outputs are TEST- entries using Given–When–Then plus metadata (Type, Tests, EPIC, Validation Method, Automation path, Priority).
How many tests should an EPIC have?
Aim for a reasonable MVP count (typically 30–50 total). Every API- should have at least 2 TEST- entries; every BR- and UJ- at least one.