|
| 1 | +# OpenPRD |
| 2 | + |
| 3 | +OpenPRD is a lightweight, open standard for **product requirements documents** authored by humans or AI agents. It is maintained by Profullstack, Inc. as part of the LogicSRC open-standards surface. |
| 4 | + |
| 5 | +Where [OpenSpec](./openspec-comparison.md) models a *change* as a multi-file bundle (proposal + design + specs + tasks + deltas), OpenPRD deliberately models a *product decision* as **one Markdown file**. It answers "what are we building and why", not "how the change is structured for implementation". The single-file shape is the point: it is the low-ceremony front door that a `prd` CLI command can produce in one step. |
| 6 | + |
| 7 | +## Privacy |
| 8 | + |
| 9 | +**PRD documents are private by convention.** Only this standard is published. Generated PRDs live under a repo-local `prd/` directory that SHOULD be listed in `.gitignore`. Tools that write OpenPRD documents MUST NOT publish them anywhere by default. |
| 10 | + |
| 11 | +## File layout |
| 12 | + |
| 13 | +```txt |
| 14 | +prd/ |
| 15 | + <slug>/ |
| 16 | + prd.md # one OpenPRD document (front-matter manifest + body) |
| 17 | +``` |
| 18 | + |
| 19 | +- `<slug>` is a kebab-case identifier, unique within the repo, and equal to the manifest `id`. |
| 20 | +- A repo MAY contain many PRDs; each is a self-contained directory so attachments (mockups, notes) can sit beside `prd.md`. |
| 21 | + |
| 22 | +## Manifest (front-matter) |
| 23 | + |
| 24 | +Every `prd.md` opens with a YAML front-matter block validated by |
| 25 | +[`openprd-prd.schema.json`](../packages/schemas/schemas/openprd-prd.schema.json): |
| 26 | + |
| 27 | +```yaml |
| 28 | +--- |
| 29 | +openprd: "0.1" # standard version (required) |
| 30 | +id: park-service-expansion # kebab-case slug == directory name (required) |
| 31 | +title: Parked-domain service expansion # (required) |
| 32 | +status: draft # draft | review | active | shipped | archived (required) |
| 33 | +owner: did:key:… # optional DID/handle of the accountable owner |
| 34 | +repo: moshcoder/moshcoding # optional target repo (owner/name) |
| 35 | +created: 2026-07-12 # optional ISO date |
| 36 | +updated: 2026-07-12 # optional ISO date |
| 37 | +tags: [growth, monetization] # optional labels |
| 38 | +supersedes: [old-slug] # optional ids this PRD replaces |
| 39 | +--- |
| 40 | +``` |
| 41 | + |
| 42 | +## Body sections |
| 43 | + |
| 44 | +The body is Markdown with a fixed, ordered set of `##` sections. All are required (a section MAY be a single line such as `_None._`), which keeps every PRD skimmable and diffable: |
| 45 | + |
| 46 | +1. `## Problem` — the user/business problem, and why it matters now. |
| 47 | +2. `## Goals` — what success looks like, as outcomes (not features). |
| 48 | +3. `## Non-Goals` — explicitly out of scope, to bound the work. |
| 49 | +4. `## Users` — who this is for; personas or segments. |
| 50 | +5. `## Requirements` — numbered `R1`, `R2`, … each prefixed with a priority tag `[P0]`/`[P1]`/`[P2]`. One capability per line. |
| 51 | +6. `## UX Notes` — flows, states, and constraints that shape the experience. |
| 52 | +7. `## Success Metrics` — how the goals will be measured. |
| 53 | +8. `## Risks & Open Questions` — known risks and decisions still owed. |
| 54 | + |
| 55 | +### Minimal example |
| 56 | + |
| 57 | +```markdown |
| 58 | +--- |
| 59 | +openprd: "0.1" |
| 60 | +id: launch-flip |
| 61 | +title: Coming-soon → live launch flip |
| 62 | +status: draft |
| 63 | +--- |
| 64 | + |
| 65 | +## Problem |
| 66 | +Parked domains have no one-click path from coming-soon to a live site. |
| 67 | + |
| 68 | +## Goals |
| 69 | +Owners flip a domain live and notify its waitlist in a single action. |
| 70 | + |
| 71 | +## Non-Goals |
| 72 | +_Building the live site itself._ |
| 73 | + |
| 74 | +## Users |
| 75 | +Domain owners running parked pages on the service. |
| 76 | + |
| 77 | +## Requirements |
| 78 | +- R1 [P0] A per-domain "go live" action publishes/redirects the domain. |
| 79 | +- R2 [P0] Flipping live emails that domain's waitlist. |
| 80 | +- R3 [P1] The action is reversible within a grace window. |
| 81 | + |
| 82 | +## UX Notes |
| 83 | +One button on the domain's admin row; confirm dialog shows the waitlist size. |
| 84 | + |
| 85 | +## Success Metrics |
| 86 | +Time-to-live per domain; waitlist → visit conversion after launch. |
| 87 | + |
| 88 | +## Risks & Open Questions |
| 89 | +- Email deliverability on bulk launch sends. |
| 90 | +- Should redirects preserve `?dn=` analytics? |
| 91 | +``` |
| 92 | + |
| 93 | +## Relationship to LogicSRC |
| 94 | + |
| 95 | +OpenPRD is intentionally decoupled from the rest of LogicSRC: a PRD is just a file and needs no service to exist. When coordination is wanted, a PRD's `Requirements` map cleanly onto LogicSRC `task` documents (each `R#` → one task), and the PRD `owner`/`repo` reuse LogicSRC identity and repo conventions. That bridge is optional and lives in tooling, not in this standard. |
| 96 | + |
| 97 | +## Conformance |
| 98 | + |
| 99 | +A document conforms to OpenPRD `0.1` when: |
| 100 | + |
| 101 | +- it lives at `prd/<slug>/prd.md`, |
| 102 | +- its front-matter validates against `openprd-prd.schema.json`, |
| 103 | +- `id` equals `<slug>`, and |
| 104 | +- all eight body sections are present in order. |
0 commit comments