jaktestowac/prd-generator
skills/prd-generator/SKILL.md
Produces production-ready Product Requirements Documents (PRDs) for software systems and AI-powered features, with clear problem framing, measurable outcomes, scoped functionality, testable requirements, and explicit risks. Use when the user wants to write a PRD, define requirements, plan a feature, or turn a vague product idea into an implementation-ready specification.
$ install --global
skillsauthnpx skillsauth add jaktestowac/awesome-copilot-for-testers prd-generatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Aug 26, 2026, 2:18 AM175.5s2 files scanned
SKILL.md
- name:
- prd-generator
- description:
- Produces production-ready Product Requirements Documents (PRDs) for software systems and AI-powered features, with clear problem framing, measurable outcomes, scoped functionality, testable requirements, and explicit risks. Use when the user wants to write a PRD, define requirements, plan a feature, or turn a vague product idea into an implementation-ready specification.
- argument-hint:
- Product or feature idea, target users, known constraints, and any existing requirements
- user-invocable:
- true
- license:
- MIT
Product Requirements Document (PRD) Generator
This skill produces high-quality, professional PRDs that serve as a single source of truth for product, design, engineering, QA, and leadership teams.
The PRD balances business goals, user needs, and technical execution, and supports both traditional software systems and AI-driven products.
Adapted from the prd skill in github/awesome-copilot (MIT).
What This Skill Does
When invoked, this skill:
- Elicits missing context through structured discovery
- Translates ambiguous ideas into clear, actionable requirements
- Produces a complete, testable, and measurable PRD
- Makes assumptions and risks explicit
- Adapts depth and rigor to product maturity and risk
- Treats the PRD as a living, versioned artifact
When to Use
Use this skill when the user wants to:
- "Write a PRD", "define requirements", or "plan a feature"
- Turn a vague idea into an implementation-ready specification
- Align multiple stakeholders before development
- Document requirements for AI / ML-enabled systems
- Create a reference document that evolves with the product
Operational Workflow
A PRD must never be generated immediately from a single prompt. Reduce uncertainty and align expectations first.
Phase 0: PRD Strategy Selection
Before discovery, classify the PRD to adapt structure and rigor:
- Product Stage: MVP / Growth / Scale
- Risk Level: Low / Medium / High
- AI Criticality: None / Supporting / Core
- Primary Audience: Engineering / Product / Exec / External
The chosen strategy determines depth, level of detail, and validation rigor.
Phase 1: Discovery - Structured Elicitation
Ask clarifying questions before drafting, using a structured approach (Who / What / Why / When / How):
- Problem & Context - what problem are we solving, and why now?
- Users & Value - who are the primary users, and what outcome do they care about?
- Success & Measurement - how will success be measured; what does "good" look like?
- Constraints - deadlines, budget, tech stack, compliance?
- Stakeholders - who needs alignment or approval?
Ask targeted questions only where the answer would change the PRD. When answers are unavailable or the user wants to move fast, record the gaps as explicit entries in the Assumptions section and proceed.
Phase 2: Draft the PRD
Produce the PRD following the mandatory output schema in ./resources/prd-template.md - exact section structure, order, and the worked example live there.
Phase 3: Self-Review
Before finalizing, verify:
- [ ] All success metrics are measurable
- [ ] Assumptions are explicitly listed
- [ ] Non-goals are clearly stated
- [ ] Risks include mitigation strategies
- [ ] Requirements are testable
- [ ] No undefined terms remain
PRD Quality Standards
Requirements Must Be Measurable
Avoid subjective language.
Bad: "Fast", "Easy to use", "High quality"
Good: "P95 latency ≤ 200ms for 10k records", "100% Lighthouse accessibility score", "≥90% precision on benchmark queries"
Testability by Design
Every major requirement must indicate:
- How it will be validated
- What can be automated
- What signals indicate failure
AI systems must define offline evaluation and runtime monitoring.
Iteration & Collaboration Rules
- Treat the PRD as a living document
- Track versions and changes
- Incorporate feedback from product, engineering, QA, and stakeholders
- Revisit assumptions as new information emerges
Resource Map
./resources/prd-template.md- the mandatory PRD output schema, section-by-section guidance, and a worked example
Related Skills
requirements-test-coverage-mapper- when the finished PRD should be mapped to test coverageverifying-acceptance-criteria- when acceptance criteria from the PRD need verification against a builddesigning-functional-tests- when the PRD should expand into concrete test scenarios
Definition of Done
This skill is complete when:
- the PRD follows the mandatory schema in the template, in order
- every requirement is measurable and testable
- assumptions, risks (with mitigations), and non-goals are explicit
- AI/ML sections are present when AI is a supporting or core capability
- the self-review checklist passes
Related Skills
jaktestowac/testing-agent-skills
testing
VerifiedTrustedCommunity
Tests the customization assets themselves - skills, prompts, custom agents, instructions - the way a product is tested: activation cases that check an asset fires when it should and stays quiet when it should not, output-contract cases, safety cases, collision cases between assets competing for the same trigger, a weighted rubric scored blind, and a baseline-versus-candidate gate before an edit ships. Use when a skill is edited and nobody knows whether behaviour changed, when two skills fight over the same request, when a description is being tuned for discoverability, when a collection has grown past manual spot-checking, or when the request mentions skill evals, prompt regression, or "does this skill actually work".
113SKILL.mdUpdated Aug 29, 2026
jaktestowac/communicating-quality-findings
development
VerifiedTrustedCommunity
Shapes QA output for the person who has to act on it: result and blocker in the first two lines, one decision per report, findings ordered by what they cost, the long artifact in a file and the decisions in the message, and magnitude stated in units the reader can count. Use when a report is accurate but nobody acts on it, when a finding set is too long to read under time pressure, when the same findings must be retold for a developer, a release manager, and an on-call engineer, or when the request mentions "too long", "make this readable", "just tell me what to do", "so what", or "summarize this for stakeholders". Pairs with unslop-answers, which makes the same report honest.
113SKILL.mdUpdated Aug 29, 2026
jaktestowac/verifying-change-coverage
testing
VerifiedTrustedCommunity
Verifies that the lines and branches a change actually touched are executed by tests, using LCOV or Cobertura diff coverage instead of whole-repo percentages, and escalates uncovered high-risk changes into a blocking finding. Use when a pull request needs a coverage gate that unrelated tests cannot satisfy, when total coverage looks healthy but the diff is untested, when wiring diff coverage into CI, or when someone claims a change is covered because the suite is green.
113SKILL.mdUpdated Aug 26, 2026
jaktestowac/unslop-tests
development
VerifiedTrustedCommunity
Cuts AI tells from test code: tests that pass without proving anything, tautological assertions, mock-only tests, hardcoded waits, coverage theater, vague names, swallowed errors, retries used as fixes. Use whenever test code is written, changed, or reviewed, including tests produced as a side effect of a feature task, and when the request mentions "review these tests", "are these tests any good", "this test always passes", "this suite is flaky", or "clean up these tests". Must always apply to test code.
113SKILL.mdUpdated Aug 26, 2026