You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(openprd): revise standard to DIP-style numbered proposals (0.2)
Reshape OpenPRD from a private single-file (prd/<slug>/prd.md, gitignored) into a
published, numbered proposal collection like BIP/EIP/DIP: prd/NNNN-slug.md +
0000-template.md + a README index, committed to the repo, with a lifecycle
(Draft → Review → Accepted → Final; Rejected/Withdrawn/Superseded).
Tools (e.g. moshcode /prd) consume this to publish PRDs into whatever repo the
user is working in.
- docs/openprd.md — rewritten: numbering, lifecycle, directory layout, conformance.
- docs/openprd/0000-template.md — the canonical template.
- packages/schemas/schemas/openprd-prd.schema.json — 4-digit id, status enum,
authors, discussion/implementation, supersedes/superseded-by.
- fixture updated to 0.2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
3
+
OpenPRD is a lightweight, open standard for **product requirements documents** authored by humans or AI agents, maintained by Profullstack, Inc. as part of the LogicSRC open-standards surface.
4
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.
5
+
It borrows the shape of a BIP/EIP/DIP process: a repo keeps a **numbered, committed collection** of PRDs under `prd/`, each one a single Markdown file with a fixed set of sections and a lifecycle. Where [OpenSpec](./openspec-comparison.md) models a *change* as a multi-file bundle, OpenPRD models a *product decision* as **one numbered file** you can read a year from now to recover the *why*.
6
6
7
-
## Privacy
7
+
Tools such as the moshcode CLI consume this standard to publish PRDs into whatever repo you're working in.
8
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.
9
+
## When to write one
10
10
11
-
## File layout
11
+
Write a PRD when a change introduces or reshapes a product capability — a new feature, surface, or user-facing behavior whose requirements deserve to be agreed *before* code lands. Small, obvious changes just get a PR. If you're unsure, write a short one; three paragraphs is fine.
12
+
13
+
## Directory layout
12
14
13
15
```txt
14
16
prd/
15
-
<slug>/
16
-
prd.md # one OpenPRD document (front-matter manifest + body)
17
+
README.md # index of PRDs (generated/maintained by tooling)
18
+
0000-template.md # the OpenPRD template — copy to start a new PRD
19
+
0001-<slug>.md # numbered PRDs, one file each
20
+
0002-<slug>.md
17
21
```
18
22
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`.
23
+
- PRDs are **committed to the repo** (public within that repo) — like `dips/`, not gitignored.
24
+
- One file per PRD: `prd/<id>-<slug>.md`, where `<id>` is the four-digit number and `<slug>` is a kebab-case summary of the title.
25
+
26
+
## Numbering
27
+
28
+
Four-digit, zero-padded, monotonically increasing, no gaps: `0001`, `0002`, `0003`. `0000` is reserved for the template. Assign the next free number when the PRD is created — don't reserve in advance.
29
+
30
+
## Lifecycle
31
+
32
+
```txt
33
+
Draft → Review → Accepted → Final
34
+
↘ Rejected
35
+
↘ Withdrawn
36
+
↘ Superseded by NNNN
37
+
```
38
+
39
+
-**Draft** — author is still iterating.
40
+
-**Review** — open for discussion (typically on the PR that introduces the PRD).
41
+
-**Accepted** — requirements agreed; implementation may begin.
42
+
-**Final** — implementation shipped; the PRD is now historical record. Don't edit a Final PRD except for typos — open a follow-up that supersedes it.
43
+
-**Rejected / Withdrawn / Superseded** — kept on disk; the *why* is part of the record.
44
+
45
+
Status lives in the front-matter and is the source of truth.
21
46
22
47
## Manifest (front-matter)
23
48
24
-
Every `prd.md` opens with a YAML front-matter block validated by
49
+
Every PRD opens with a YAML front-matter block validated by
implementation: # optional URL to the impl PR/tracking issue
65
+
tags: [growth] # optional labels
66
+
supersedes: # optional 4-digit id this PRD replaces
67
+
superseded-by: # optional 4-digit id that replaces this PRD
39
68
---
40
69
```
41
70
@@ -52,53 +81,17 @@ The body is Markdown with a fixed, ordered set of `##` sections. All are require
52
81
7.`## Success Metrics` — how the goals will be measured.
53
82
8.`## Risks & Open Questions` — known risks and decisions still owed.
54
83
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
-
```
84
+
See [`0000-template.md`](./openprd/0000-template.md) for the copy-paste template.
92
85
93
86
## Relationship to LogicSRC
94
87
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.
88
+
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 `owner`/`repo` reuse LogicSRC identity and repo conventions. That bridge is optional and lives in tooling, not in this standard.
96
89
97
90
## Conformance
98
91
99
-
A document conforms to OpenPRD `0.1` when:
92
+
A document conforms to OpenPRD `0.2` when:
100
93
101
-
- it lives at `prd/<slug>/prd.md`,
94
+
- it lives at `prd/<id>-<slug>.md` with a four-digit `<id>`,
102
95
- its front-matter validates against `openprd-prd.schema.json`,
"description": "The front-matter manifest of an OpenPRD document. OpenPRD is a deliberately lightweight, single-file PRD standard: one prd/<slug>/prd.md per product decision, authored by a human or an AI agent. The document body is Markdown with a fixed set of sections; this schema governs only the YAML front-matter. PRD documents are private by convention (gitignored) — only the OpenPRD standard itself is published.",
5
+
"description": "The front-matter manifest of an OpenPRD document. OpenPRD is a lightweight, DIP-style proposal standard: a repo publishes a numbered collection of PRDs under prd/ (prd/NNNN-slug.md), with a 0000-template.md and a README index, committed to the repo like a BIP/EIP/DIP process. This schema governs the YAML front-matter; the body is Markdown with a fixed set of sections.",
6
6
"type": "object",
7
7
"required": ["openprd", "id", "title", "status"],
8
8
"additionalProperties": false,
9
9
"properties": {
10
10
"openprd": {
11
11
"type": "string",
12
12
"pattern": "^\\d+\\.\\d+(\\.\\d+)?$",
13
-
"description": "OpenPRD standard version this document conforms to, e.g. '0.1'."
13
+
"description": "OpenPRD standard version this document conforms to, e.g. '0.2'."
14
14
},
15
15
"id": {
16
16
"type": "string",
17
-
"pattern": "^[a-z0-9][a-z0-9-]*$",
18
-
"description": "Kebab-case slug, unique within the repo. Also the directory name: prd/<id>/prd.md."
17
+
"pattern": "^\\d{4}$",
18
+
"description": "Four-digit zero-padded number, monotonically increasing with no gaps. Matches the filename prefix: prd/<id>-<slug>.md."
0 commit comments