product-requirements-doc — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited product-requirements-doc (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
A PRD translates a vague or complex feature request into a structured artifact that complements task.md. The questioner produces it when intent is rich enough to need explicit scope, acceptance criteria, and constraints, rather than a one-page task summary alone.
The goal is precision, not exhaustive documentation: clear scope, unambiguous acceptance criteria, and explicit boundaries that prevent scope creep when the design-author later turns the task into an approach.
The questioner produces a PRD (in addition to the standard task.md and questions.md) when the feature request is:
like ("improve the onboarding experience" has no clear scope boundary)
than one distinct workflow, or multiple independent but related capabilities
interaction between them needs explicit specification
scope of "existing" needs to be defined before research can begin
For simple, well-scoped requests ("add a --verbose flag to the CLI"), the standard task.md is sufficient — no PRD needed.
Write the PRD to docs/plans/<id>/prd.md. Reference its path from task.md so the design-author knows to read it.
One to three sentences: what problem does the user have? Why does it exist? Why does it matter to solve it now? Ground every subsequent section in this.
Enumerate the user workflows the feature must support. Use this format:
As a [user type], I want to [action], so that [outcome].Every user story that is in scope gets listed. User stories that are explicitly out of scope get listed in Non-Goals. Stories that might be in scope later get listed in Future Scope.
Keep stories at the "what" level, not the "how" level. "As a developer, I want to see syntax errors highlighted in the editor" is a story. "As a developer, I want the parser to return an AST node with error metadata" is an implementation detail.
For each user story, define the conditions that prove it is implemented correctly. Acceptance criteria are written as verifiable statements:
GIVEN [initial context]
WHEN [user action]
THEN [expected outcome]Or as a checklist when the story is simple:
- [ ] The user can do X without doing Y first
- [ ] Doing X with invalid input shows error message Z
- [ ] Doing X is reflected in the audit log within 1 secondAcceptance criteria must be:
Explicit statement of what is and is not in scope.
In Scope:
Out of Scope:
they might be assumed. "Does not support X" is more valuable than silence.
Future Scope:
prevents them from being lost while keeping them out of the current scope.
Non-negotiable requirements the implementation must satisfy:
When the design-author finds a PRD path referenced in task.md, it should:
feature request.
one or more decisions in the design document.
plan must not add slices for out-of-scope items.
When the structure-planner reads the design, the PRD's acceptance criteria become the source of vertical-slice acceptance tests.
author what users need; the design tells the implementer how to build it.
test for it, it is not an acceptance criterion — it is an aspiration.
for this feature, regardless of how easy it seems to add.
questions about acceptance criteria interactively but may not change them unilaterally.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.