feat: v7.0.0 — 6 new engineering skills, badges, milestone tracker, SKILL_REQUEST.md

New skills added to pm-engineering bundle (now 10 skills total): - debugging-log-analyser: stack trace → structured root cause diagnosis + fix - pr-description-writer: diff/commits → reviewer-ready PR description - system-design-interview: full system design with capacity, components, trade-offs - changelog-generator: git log → polished Keep a Changelog entry - test-strategy-doc: spec/PRD → complete test strategy with P0/P1 test cases - runbook-writer: operational runbooks with exact commands, rollback, and escalation README updates: - 5 shields.io badges (stars, skill count, version, install, license) - "See It in Action" demo section - pm-engineering added to Quick Install list - Star Milestone Tracker (100/250/500/1000 stars roadmap) - Engineering table extended from 4 to 10 skills (41–50) - Article 14 link resolved from remote merge Config updates: - marketplace.json: v6.0.0 → v7.0.0, "106 skills" - pm-engineering plugin.json: v1.0.0 → v2.0.0 New file: SKILL_REQUEST.md — community skill voting board Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-23 15:21:43 +01:00
parent ce35e8c5c0
commit c0544fb76a
16 changed files with 1447 additions and 26 deletions
@@ -0,0 +1,82 @@
+---
+name: changelog-generator
+description: "Convert a git log, commit list, or release notes into a polished, user-facing changelog. Use when writing release notes, generating a CHANGELOG.md entry, or documenting what changed in a version. Produces a structured changelog section with version header, categorised changes, and migration notes. Optimised for Opus 4.7 and newer models."
+---
+
+# Changelog Generator Skill
+
+Converts raw git commits, a diff summary, or developer release notes into a polished changelog entry — categorised, user-facing, and following Keep a Changelog conventions.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **Commits or release notes** (paste `git log --oneline`, raw commit messages, or a description of what changed)
+- **Version number** (e.g. 2.4.0, v1.0.0-beta.2)
+- **Release date** (or "today")
+- **Audience** (developers using an API / end users of a product / internal team — affects language)
+- **Any breaking changes** (flag these explicitly if known)
+
+## Output Structure
+
+Follow [Keep a Changelog](https://keepachangelog.com) format:
+
+---
+
+## [X.Y.Z] — YYYY-MM-DD
+
+### Breaking Changes ⚠️
+[Only include if there are breaking changes]
+- **[Breaking change]:** [What changed and what it breaks]
+- **Migration required:** [Specific action the user must take]
+
+### Added
+- [New feature or capability, written from the user's perspective]
+- [Another addition]
+
+### Changed
+- [Changed behaviour — what it did before vs. what it does now]
+- [Performance improvement with measurable impact if known]
+
+### Fixed
+- [Bug fixed — describe what was broken, not the fix implementation]
+- [Another fix]
+
+### Deprecated
+- [Deprecated thing] — use [replacement] instead. Will be removed in [version].
+
+### Removed
+- [Removed thing] — was deprecated in [version]
+
+### Security
+- [Security fix — describe the vulnerability class, not exploit details]
+
+---
+
+## Formatting Rules Applied
+
+**Language:** Write for the reader, not the committer. "Add dark mode support" not "implement ThemeProvider with dark palette variant".
+
+**Breaking changes:** Always call these out first with ⚠️. Include a migration path.
+
+**Bug fixes:** Describe what was broken, not what was changed. "Fix crash when user has no profile picture" not "null-check avatar URL before rendering".
+
+**Granularity:** Group related commits into one line. Don't list every micro-commit separately.
+
+**Tone:** Active voice, imperative mood. "Add", "Fix", "Remove" — not "Added", "Fixed", "Removed".
+
+**Empty sections:** Omit any section with no entries. Don't include empty `### Fixed` blocks.
+
+## Quality Checks
+- [ ] Breaking changes are at the top with migration instructions
+- [ ] All entries are user-facing language (no internal variable names or implementation details)
+- [ ] Related commits are grouped into single entries (not listed individually)
+- [ ] Version and date header is correct
+- [ ] Empty sections are omitted
+- [ ] Tone is imperative mood throughout
+
+## Example Trigger Phrases
+- "Write a changelog for version [X]" + [paste commits]
+- "Generate release notes from these commits"
+- "Turn this git log into a CHANGELOG entry"
+- "Write the CHANGELOG.md update for this release"
+- "What changed in this release?" + [paste commit list]
@@ -0,0 +1,79 @@
+---
+name: debugging-log-analyser
+description: "Parse error logs, stack traces, and crash reports into a structured root cause diagnosis. Use when sharing a log, stack trace, error output, or crash dump. Produces a structured diagnosis with probable root cause, affected code path, suggested fix, and next debugging steps. Optimised for Opus 4.7 and newer models."
+---
+
+# Debugging Log Analyser Skill
+
+Parses raw error logs, stack traces, and crash reports into a structured diagnosis with probable root cause, affected code path, and specific next steps — no hand-waving.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **The log / stack trace / error output** (paste directly or describe the error)
+- **Language and framework** (e.g. Node.js + Express, Python + Django, Java Spring, Go)
+- **Context** (what the user was doing when the error occurred)
+- **Environment** (local dev / staging / production)
+- **What they've already tried** (if anything)
+
+## Output Structure
+
+### 1. Error Classification
+**Error type:** [Runtime exception / Build error / Config error / Network error / Memory/resource error / Unknown]
+**Severity:** [Fatal / Critical / Warning / Informational]
+**Recurrence pattern:** [One-off / Intermittent / Consistent / On-startup / Under load]
+
+### 2. Stack Trace Analysis
+
+Walk the stack frame by frame, starting from the origin:
+- **Origin frame:** [File, line, function where it started]
+- **Propagation path:** [How it travelled through the call stack]
+- **Crash point:** [Where it ultimately threw/panicked/exited]
+
+For each significant frame, note whether it is:
+- User code (fixable here)
+- Framework/library code (usually a misuse issue)
+- System/runtime code (usually a config or environment issue)
+
+### 3. Root Cause Assessment
+**Probable root cause:** [1–2 sentence plain English statement]
+**Confidence:** [High / Medium / Low — and why]
+**Alternative causes to rule out:** [If confidence is not high]
+
+### 4. Affected Code Path
+**Entry point:** [Where the triggering call began]
+**Key function(s) involved:** [Specific functions/methods named in the trace]
+**Data that triggered it:** [If inferable from the log — e.g. null value, malformed JSON]
+
+### 5. Suggested Fix
+Provide a concrete, code-level suggestion:
+- What to change (the minimal fix)
+- Why this fixes the root cause
+- Any trade-offs or risks in the fix
+- A short code snippet if helpful
+
+### 6. Next Debugging Steps
+If the root cause is uncertain, provide an ordered list of 3–5 specific debugging actions:
+1. [Specific thing to check — file, log line, config value]
+2. [Specific reproduction step or isolation test]
+3. [Specific tool command — e.g. `strace`, `pprof`, `--verbose`, add logging at X]
+
+### 7. Prevention
+One or two concrete things that would prevent this class of error recurring:
+- Better input validation at [point]
+- Add monitoring/alerting for [condition]
+- Test that covers [scenario]
+
+## Quality Checks
+- [ ] Root cause is specific (not "there might be a null pointer issue")
+- [ ] At least one concrete code-level fix is suggested
+- [ ] Next steps are actionable commands, not vague advice
+- [ ] Language-specific idioms are used correctly
+- [ ] Prevention is proactive (not just "add error handling")
+
+## Example Trigger Phrases
+- "Why is this crashing?" + [paste log]
+- "Can you analyse this stack trace?"
+- "I'm getting this error, what does it mean?"
+- "Debug this log for me"
+- "What's causing this exception?"
@@ -0,0 +1,87 @@
+---
+name: pr-description-writer
+description: "Write a clear, structured pull request description from a git diff, branch summary, or commit list. Use when asked to write a PR description, draft a pull request, or document code changes. Produces a description with summary, motivation, changes made, testing steps, and reviewer guidance. Optimised for Opus 4.7 and newer models."
+---
+
+# PR Description Writer Skill
+
+Writes structured, reviewer-friendly pull request descriptions from a diff, commit list, or informal notes. Covers the what, why, and how-to-review so reviewers can start immediately.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **What changed** (paste a git diff, `git log --oneline`, or describe the changes in plain English)
+- **Why it was changed** (the problem being solved or feature being added)
+- **How to test it** (any specific steps a reviewer needs to verify it works)
+- **Risk level** (low / medium / high — affects how much reviewer guidance to include)
+- **PR type** (feature / bug fix / refactor / dependency upgrade / config change / hotfix)
+
+## Output Structure
+
+### Title
+A clear, imperative-mood title under 72 characters:
+`[type]: [concise description of what changed]`
+
+Examples:
+- `feat: add rate limiting to the public API`
+- `fix: resolve race condition in session expiry`
+- `refactor: extract payment logic into PaymentService`
+
+### Summary
+2–3 sentences covering:
+- What this PR does (the change)
+- Why it was needed (the problem or goal)
+- The approach taken (at a high level)
+
+### Changes Made
+Bullet list of specific changes — one bullet per logical change, not per file:
+- Added [X] to handle [Y]
+- Refactored [A] to reduce [B]
+- Removed [C] as it was replaced by [D]
+- Updated [E] to fix [F]
+
+### Screenshots / Demo
+[If UI change: include before/after screenshots or a screen recording]
+[If API change: include example request/response]
+[If no visual change: this section can be omitted]
+
+### How to Test
+Step-by-step instructions a reviewer can follow:
+1. [Setup step if needed]
+2. [Action to take]
+3. [What to verify]
+4. [Edge case to check]
+
+Include any specific commands, test data, or environment flags needed.
+
+### Testing Checklist
+- [ ] Unit tests added/updated
+- [ ] Integration tests added/updated
+- [ ] Edge cases covered
+- [ ] Manual testing completed
+- [ ] No regressions in existing tests
+
+### Reviewer Notes
+Flag anything that warrants extra attention:
+- Areas of uncertainty where a second opinion is welcome
+- Deliberate trade-offs made (and why)
+- Out-of-scope items noticed but not addressed
+- Dependencies on other PRs (link them)
+
+### Related
+- Closes #[issue number] (if applicable)
+- Related to #[PR/issue number]
+
+## Quality Checks
+- [ ] Title is imperative mood and under 72 characters
+- [ ] Summary explains what AND why (not just what)
+- [ ] Changes list describes logical changes (not file-by-file changes)
+- [ ] Testing steps are reproducible by someone unfamiliar with the code
+- [ ] Risk-appropriate reviewer guidance is included
+
+## Example Trigger Phrases
+- "Write a PR description for these changes" + [paste diff or description]
+- "Draft a pull request for [feature]"
+- "I need a PR description — here's what I changed"
+- "Summarise these commits into a PR description"
+- "Write the PR body for this branch"
@@ -0,0 +1,144 @@
+---
+name: runbook-writer
+description: "Write an operational runbook for a service, incident type, or deployment procedure. Use when asked to write a runbook, create an ops guide, document an operational procedure, or prepare an incident response playbook. Produces a runbook with overview, prerequisites, step-by-step procedures, rollback steps, troubleshooting table, and escalation paths. Optimised for Opus 4.7 and newer models."
+---
+
+# Runbook Writer Skill
+
+Produces operational runbooks for services, incident types, and deployment procedures — structured so an on-call engineer who's never touched the system can follow them under pressure.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **What the runbook is for** (e.g. deploying the payment service, responding to a database failover, rotating API keys)
+- **Runbook type** (Deployment / Incident Response / Maintenance / Disaster Recovery)
+- **System/service name and what it does** (brief description)
+- **Audience** (new on-call engineers / experienced SREs / DevOps team)
+- **Tech stack** (where relevant — e.g. Kubernetes, AWS RDS, Node.js)
+
+## Output Structure
+
+---
+**Runbook:** [Runbook Title]
+**Service:** [Service Name]
+**Type:** [Deployment / Incident Response / Maintenance / DR]
+**Last Updated:** [Date]
+**Owner:** [Team or person]
+**Severity:** [P1 / P2 / P3 — if incident-type]
+
+---
+
+### Overview
+**What this runbook covers:**
+[1–2 sentences on the scenario this runbook handles]
+
+**When to use this runbook:**
+- [Specific trigger condition 1 — e.g. PagerDuty alert: `high-error-rate-payment-service`]
+- [Specific trigger condition 2 — e.g. Deploy needed after PR merged to `main`]
+
+**Estimated time to complete:** [X minutes / X–Y minutes depending on outcome]
+
+**Impact if not completed correctly:** [e.g. Payment processing degraded / Data loss risk / Users locked out]
+
+---
+
+### Prerequisites
+
+**Access required:**
+- [ ] [System/tool access — e.g. AWS Console: `production-account`]
+- [ ] [Credential — e.g. `vault read secret/payment-service`]
+- [ ] [VPN / bastion access if needed]
+
+**Tools required:**
+- [ ] [Tool name and version — e.g. `kubectl` v1.28+]
+- [ ] [CLI or dashboard name]
+
+**Before you start:**
+- [ ] [Prerequisite check — e.g. Verify current deployment is healthy in Grafana]
+- [ ] [Prerequisite action — e.g. Announce in `#ops-live` that you're starting]
+
+---
+
+### Procedure
+
+Number every step. Use exact commands. Do not paraphrase tool names or flags.
+
+**Step 1: [Action name]**
+[What you're doing and why — one sentence]
+```bash
+# Exact command
+[command here]
+```
+**Expected output:** `[what should appear if this worked]`
+**If this fails:** [Exact error message to look for] → [What to do, or see Troubleshooting]
+
+**Step 2: [Action name]**
+[Same structure as Step 1]
+
+**Step 3: Verify**
+Always include a verification step after the main procedure:
+```bash
+[verification command]
+```
+**Expected state:** [What a healthy system looks like after this runbook completes]
+
+---
+
+### Rollback
+
+How to undo this procedure if something went wrong:
+
+**Step R1: [Rollback action]**
+```bash
+[rollback command]
+```
+**Verify rollback:** `[command to confirm rollback succeeded]`
+
+---
+
+### Troubleshooting
+
+| Symptom | Likely Cause | Resolution |
+|---|---|---|
+| [Error message or observable symptom] | [Why this happens] | [Exact fix or next step] |
+| [Another symptom] | [Cause] | [Resolution] |
+
+---
+
+### Escalation
+
+If this runbook does not resolve the issue:
+
+| Condition | Who to Contact | How |
+|---|---|---|
+| [e.g. DB unavailable after 10 min] | [DBA on-call] | [PagerDuty policy: `db-oncall`] |
+| [e.g. Payment provider unresponsive] | [Vendor contact] | [Contact in 1Password: `vendor-escalation`] |
+
+**Always update the incident timeline in [tool] before escalating.**
+
+---
+
+### Post-Procedure Checklist
+
+After completing the runbook:
+- [ ] Announce completion in `#ops-live` with outcome
+- [ ] Update the incident ticket / deploy log
+- [ ] Verify alerts have resolved in monitoring dashboard
+- [ ] If this revealed a gap in this runbook — update it now (link to edit process)
+
+---
+
+## Quality Checks
+- [ ] Every step has an exact command (no "run the deploy script")
+- [ ] Expected output is specified for each step so engineer knows if it worked
+- [ ] Failure path is explicit for each step (not "if it fails, investigate")
+- [ ] Rollback procedure is complete and independently testable
+- [ ] Escalation paths name specific contacts, not just team names
+- [ ] Runbook can be followed by someone who has never touched this system
+
+## Example Trigger Phrases
+- "Write a runbook for [service] deployment"
+- "Create an incident response runbook for [alert type]"
+- "I need a runbook for [procedure]"
+- "Document the operational procedure for [X]"
+- "Write an ops playbook for [scenario]"
@@ -0,0 +1,135 @@
+---
+name: system-design-interview
+description: "Structure a complete system design answer for interview questions or real architecture sessions. Use when asked to design a system, answer a system design interview question, or architect a solution at scale. Produces a structured answer covering requirements, capacity estimates, high-level design, component deep-dives, trade-offs, and follow-up considerations. Optimised for Opus 4.7 and newer models."
+---
+
+# System Design Interview Skill
+
+Structures a complete, interview-grade system design response — covering clarifying questions, requirements, capacity estimates, architecture, component design, and trade-offs. Works equally well for real architecture sessions.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **The system to design** (e.g. "design a URL shortener", "design a notification service", "design Twitter's feed")
+- **Scope** (interview prep / real architecture decision / practice run)
+- **Scale target** (rough numbers: DAU, requests/sec, data volume — or "assume typical web scale")
+- **Constraints or priorities** (e.g. prioritise availability over consistency, minimise cost, low-latency reads)
+
+## Output Structure
+
+### 1. Clarifying Questions
+Before designing, list 4–6 questions that would change the design. Examples:
+- Read-heavy or write-heavy? (affects caching and DB choice)
+- Global or single-region? (affects latency requirements)
+- Strong or eventual consistency? (affects storage and replication)
+- Acceptable latency targets? (p50 / p99)
+- Any existing infrastructure constraints?
+
+Then proceed with stated assumptions if answering an interview question.
+
+### 2. Functional Requirements
+**Core features (must have):**
+- [Feature 1]
+- [Feature 2]
+- [Feature 3]
+
+**Out of scope (for this design):**
+- [What's deliberately excluded and why]
+
+### 3. Non-Functional Requirements
+| Requirement | Target |
+|---|---|
+| Availability | [e.g. 99.9% / 99.99%] |
+| Latency | [e.g. p95 < 100ms for reads] |
+| Throughput | [e.g. 10k writes/sec peak] |
+| Consistency | [Strong / Eventual] |
+| Durability | [e.g. 99.999% — no data loss] |
+
+### 4. Capacity Estimation
+**Traffic:**
+- DAU: [X]
+- Reads/sec: [X] (peak: [X])
+- Writes/sec: [X] (peak: [X])
+
+**Storage:**
+- Per record size: [X bytes]
+- Records per day: [X]
+- 5-year storage: [X GB/TB]
+
+**Bandwidth:**
+- Inbound: [X MB/s]
+- Outbound: [X MB/s]
+
+### 5. High-Level Architecture
+
+```
+[Client] → [CDN/Edge] → [Load Balancer] → [API Servers] → [Cache] → [DB]
+                                                         → [Message Queue] → [Workers]
+```
+
+Describe each layer in 1–2 sentences explaining its role and technology choice.
+
+### 6. Component Deep-Dive
+
+Pick the 2–3 most critical/interesting components and go deep:
+
+**[Component 1: e.g. Database Layer]**
+- Choice: [Technology and why — e.g. PostgreSQL for ACID guarantees, Cassandra for write throughput]
+- Schema design (high-level): [Key tables/collections and their structure]
+- Indexing strategy: [What gets indexed and why]
+- Replication: [Primary-replica / Multi-primary — and why]
+
+**[Component 2: e.g. Caching Strategy]**
+- Cache type: [Redis / Memcached — and why]
+- What gets cached: [Hot data — e.g. user sessions, frequent reads]
+- Cache invalidation: [TTL / Write-through / Write-behind — trade-offs]
+- Cache hit rate target: [e.g. 95%]
+
+**[Component 3: e.g. API Design]**
+- Key endpoints: [List the 3–5 most important API calls]
+- Authentication: [JWT / OAuth / API keys]
+- Rate limiting: [Where and at what rate]
+
+### 7. Data Flow
+Walk through the two most critical paths end-to-end:
+
+**Write path:** [Step 1 → Step 2 → Step 3...]
+**Read path:** [Step 1 → Step 2 → Step 3...]
+
+### 8. Scaling Bottlenecks and Mitigations
+| Bottleneck | Mitigation |
+|---|---|
+| [e.g. DB write throughput] | [e.g. sharding by user_id, write batching] |
+| [e.g. Hot-key cache misses] | [e.g. local in-process cache, probabilistic early expiry] |
+| [e.g. Single region latency] | [e.g. multi-region deployment, GeoDNS routing] |
+
+### 9. Trade-offs and Alternatives
+Be explicit about what was chosen and what was sacrificed:
+
+| Decision | Why | Trade-off |
+|---|---|---|
+| [e.g. Eventual consistency] | [Higher availability, lower latency] | [Stale reads possible] |
+| [e.g. SQL over NoSQL] | [Complex queries, ACID transactions] | [Harder to shard horizontally] |
+| [e.g. Async processing via queue] | [Decoupled, more resilient] | [Eventual delivery, harder to debug] |
+
+### 10. Follow-up Considerations
+Things to tackle in production but out of scope for this design session:
+- Monitoring and alerting (what metrics matter)
+- Disaster recovery and backup strategy
+- Security (auth, encryption at rest/transit, rate limiting)
+- Cost optimisation at scale
+- Gradual rollout and feature flagging
+
+## Quality Checks
+- [ ] Clarifying questions are design-changing (not generic filler)
+- [ ] Capacity estimates use real numbers (not just "it scales")
+- [ ] At least 2 component deep-dives with technology choices justified
+- [ ] Trade-offs section is honest (not just benefits of chosen approach)
+- [ ] Data flow is described end-to-end for the critical path
+
+## Example Trigger Phrases
+- "Help me answer a system design interview: [question]"
+- "Design [system] for a system design interview"
+- "How would I architect [system] at scale?"
+- "I have a system design interview — the question is [X]"
+- "Design a [URL shortener / chat system / notification service / feed]"
@@ -0,0 +1,127 @@
+---
+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. Optimised for Opus 4.7 and newer models."
+---
+
+# 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, framework, testing tools already in use if known)
+- **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 Structure
+
+### 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 only if risk is medium+)*
+- **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)
+- [ ] P0 test cases cover the highest-risk paths specifically
+- [ ] Each test type names a concrete tool (not "some testing framework")
+- [ ] Definition of Done is measurable (not "tests are done when QA is happy")
+
+## Example Trigger Phrases
+- "Write a test strategy for [feature]" + [paste spec or PRD]
+- "Create a test plan for [system]"
+- "How should we test [feature]?"
+- "I need a QA plan for this sprint"
+- "What tests do we need for [X]?"