Test Strategy DocCAUTION

1255 professional Agent Skills for Claude, ChatGPT, Gemini, Cursor & Codex — PRDs, postmortems, leases, medical bills, layoffs, go-bags, new countries. Plain markdown, MIT, in Anthropic's plugin directory. Plus a typed decision layer: which skill, is it safe, ship or slip. Free in-browser or npx pm-

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: test-strategy-doc
description: "Write a test strategy document from a feature spec, PRD, or system description. Use when asked to create a test plan, write a test strategy, define QA approach, or plan testing for a feature or release. Produces a complete test strategy with scope, risk assessment, test types, coverage targets, and a prioritised test case outline."
---

# Test Strategy Document Skill

Produces a complete test strategy from a feature spec, PRD, or system description — covering scope, test types, risk areas, coverage requirements, and a prioritised test case outline.

## Required Inputs

Ask for these if not provided:
- **Feature or system being tested** (paste a spec, PRD, or describe it in plain English)
- **Tech stack** (language and framework — e.g. TypeScript + React, Python + FastAPI)
- **Existing test coverage** (e.g. "we have unit tests but no E2E tests", "we use Jest + Playwright already", or "starting from scratch")
- **Deployment cadence** (e.g. continuous deployment / weekly releases / quarterly — affects what must be automated vs. manual)
- **Risk level** (low / medium / high / critical — affects depth and coverage requirements)
- **Timeline** (when does this need to ship — affects prioritisation)
- **Team context** (who is doing the testing — developers / dedicated QA / both)

## Output Format

### 1. Test Scope

**In scope:**
- [Specific functionality being tested]
- [Integration points covered]
- [User-facing flows included]

**Out of scope:**
- [What is deliberately not tested here — and why]
- [Dependencies owned by other teams]

**Assumptions:**
- [What the test strategy assumes is true — e.g. mocked services, test data availability]

### 2. Risk Assessment

Identify the highest-risk areas first — these drive depth and coverage:

| Area | Risk Level | Why | Test Priority |
|---|---|---|---|
| [e.g. Payment processing] | High | Money movement, regulatory | P0 — exhaustive |
| [e.g. User authentication] | High | Security boundary | P0 — exhaustive |
| [e.g. Email notifications] | Medium | External dependency | P1 — happy path + key failures |
| [e.g. UI copy changes] | Low | Visual only, reversible | P2 — smoke only |

### 3. Test Types and Coverage

**Unit Tests**
- **What:** Individual functions and methods in isolation
- **Who writes:** Developer
- **Coverage target:** [e.g. 80% line coverage on new code / 100% on critical paths]
- **Tools:** [e.g. Jest, pytest, go test]
- **Focus areas for this feature:** [Specific logic that needs unit coverage]

**Integration Tests**
- **What:** Service interactions, database operations, API contracts
- **Who writes:** Developer / QA
- **Coverage target:** [All happy paths + key failure modes]
- **Tools:** [e.g. Supertest, pytest + testcontainers]
- **Focus areas:** [Specific integrations at risk — e.g. third-party API, DB schema changes]

**End-to-End Tests**
- **What:** Critical user journeys from browser/client to database
- **Who writes:** QA / Developer
- **Coverage target:** [Top N user journeys — list them]
- **Tools:** [e.g. Playwright, Cypress, Selenium]
- **Focus areas:** [The 3–5 most critical user flows]

**Performance Tests** *(include if any row in the Risk Assessment table has performance as a risk factor, regardless of overall risk level)*
- **What:** Load, stress, or latency testing
- **Targets:** [Specific numbers — e.g. 200 req/sec at p95 < 200ms]
- **Tools:** [e.g. k6, Locust, JMeter]

**Security Tests** *(include only if risk is high+)*
- **What:** OWASP Top 10 checks relevant to this feature
- **Focus:** [Auth bypasses, injection, data exposure]
- **Tools:** [e.g. OWASP ZAP, manual penetration testing, Snyk]

### 4. Test Case Outline

Priority-ordered list of specific test cases:

**P0 — Must pass before merge:**
| Test Case | Type | Expected Outcome |
|---|---|---|
| [e.g. User can log in with valid credentials] | E2E | [Redirect to dashboard, session created] |
| [e.g. Invalid login returns 401] | Integration | [Error message displayed, no session] |
| [e.g. Password is never stored in plain text] | Unit | [bcrypt hash in DB] |

**P1 — Must pass before release:**
| Test Case | Type | Expected Outcome |
|---|---|---|
| [e.g. Login fails gracefully when DB is down] | Integration | [User sees friendly error, 503] |
| [e.g. Rate limiting blocks after 5 failed attempts] | Integration | [429 returned, account flagged] |

**P2 — Should pass, can ship with known issues tracked:**
| Test Case | Type | Expected Outcome |
|---|---|---|
| [e.g. Login page renders correctly on mobile] | E2E | [Layout matches design] |

### 5. Test Data Requirements
- [Specific test data needed — e.g. test user accounts with various states]
- [External service stubs or mocks needed]
- [Database seed data requirements]
- [Any PII concerns and how test data handles them]

### 6. Definition of Done
Testing is complete when:
- [ ] All P0 test cases pass
- [ ] All P1 test cases pass
- [ ] Code coverage meets the stated target
- [ ] No critical or high severity bugs open
- [ ] Performance targets met (if applicable)
- [ ] Security checks completed (if applicable)

## Quality Checks
- [ ] Risk table is populated and drives test priority (not filled in generically)
- [ ] Every "P0 — exhaustive" row in the Risk Assessment table has at least one corresponding P0 test case
- [ ] "Out of scope" section names at least one explicit exclusion (not left blank)
- [ ] Each test type names a concrete tool (not "some testing framework")
- [ ] Definition of Done is measurable (not "tests are done when QA is happy")

## Anti-Patterns

- [ ] Do not write a test strategy without a risk table that drives test priority — generic coverage targets are not a strategy
- [ ] Do not leave the "out of scope" section blank — every test strategy must explicitly name what is not being tested and why
- [ ] Do not specify test types without naming a concrete tool for each — "some testing framework" is not actionable
- [ ] Do not define a Definition of D

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

templates/pm-discovery-agent/skills/assumption-mapper/SKILL.md

templates/pm-discovery-agent/skills/discovery-interview-guide/SKILL.md

templates/pm-discovery-agent/skills/job-story-mapper/SKILL.md

templates/pm-discovery-agent/skills/user-interview-synthesis/SKILL.md

templates/pm-launch-agent/skills/content-calendar/SKILL.md

Gates applied: no_behavioural_pass.