Skip to content
mif-docs

Skill reference: prd

Skill reference: prd

Section titled “Skill reference: prd”

The prd skill authors one document genre: a Product Requirements Document — a problem-first statement of what to build and why, with success metrics, explicit non-goals, and functional requirements expressed as testable criteria. This reference describes what that document type is, how the skill produces one, when it earns its place, and the provenance and sources behind it.

PropertyValue
AuthorsA Product Requirements Document
Purpose groupProduct & feature specs
MIF conceptTypesemantic
Target MIF level3
Primary sourceAtlassian — PRD

What this document type is

Section titled “What this document type is”

A PRD scopes a product or feature before design begins: it leads with the problem and the user need, defines success metrics that say how the team will know it worked, draws non-goals that fence the scope, and then lists the functional requirements the solution must satisfy. PRDs have no single canonical standard; the skill frames the widely-taught industry practice — represented here by Atlassian’s guidance — and sharpens it on one point: functional requirements are written as EARS criteria (the Easy Approach to Requirements Syntax) so each requirement is unambiguous and gradable identically by a human and an agent.

A PRD is therefore not a description of the technical how. Once the problem and requirements are settled, the design belongs in a feature-spec or a design doc, and a single hard-to-reverse choice belongs in an adr. The PRD answers what and why; it deliberately stops short of prescribing the implementation, leaving engineers room to design against clear, testable targets.

How the skill produces one

Section titled “How the skill produces one”

prd is a genre skill: it carries the PRD pattern as durable instructions plus exemplars, and writes the artifact over a MIF floor so the result is at once a human-readable spec and a machine-conformant unit.

  • Pattern, made operational. The skill encodes the problem-first structure — problem, success metrics, non-goals, requirements — and enforces EARS phrasing on the functional requirements, refusing anti-triggered work by redirecting the technical how to a feature-spec or design doc.
  • Exemplars set the bar. Like every genre in the suite it ships good-l1.md (the MIF Level-1 floor), good.md (the Level-3 target), bad.md (a counter-example), and evals/evals.json. The check-exemplars gate proves good-l1.md validates at L1 and good.md at L3, so the pattern the skill teaches is itself continuously verified.
  • MIF projection. The PRD is authored with MIF frontmatter (via the shared mif-frontmatter substrate) and a conceptType of semantic, reflecting that a requirements document is declarative knowledge about intent rather than a sequence of steps. mif-validate proves the Markdown ↔ JSON-LD round-trip is lossless before the document is considered done.

When it is beneficial

Section titled “When it is beneficial”

Reach for prd at the front of a build, when the team needs to agree on the problem, the measure of success, and the scope before anyone designs or estimates. A good PRD prevents the most expensive class of mistake — building the wrong thing well — by forcing the problem and its success metrics into writing and by drawing non-goals that keep scope from creeping.

Do not use it to capture the technical design (that is a feature-spec or design doc), to record a settled architectural decision (an ADR), or to enumerate fine-grained implementation tasks. The cost of a PRD is the discipline of writing testable requirements and honest non-goals; skip it only when the problem is trivial or already universally understood.

Example

Section titled “Example”

A PRD titled “Self-serve API key rotation” opens with the problem — support tickets to rotate compromised keys take days and frustrate customers — sets a success metric (median rotation time under one minute, ticket volume down 80%), and lists non-goals (no change to the key format, no bulk rotation in v1). Its functional requirements read as EARS criteria — “When a user requests rotation, the system shall issue a new key and invalidate the old key within 60 seconds” — each one a target an engineer can design against and a tester can grade.

Provenance & citations

Section titled “Provenance & citations”