Anthony Ettinger
7f9e493929
Published as @logicsrc/openprd@0.2.0 — the first release of this package, and the first carrying OpenPRD 0.3 (Tech Stack and Monetization, #144). Two things had to change for the publish to be usable: - The @logicsrc/validators dependency was `file:../validators`. npm publishes that spec verbatim, so every install outside this monorepo would have failed to resolve it. It is now `^0.1.0`, which is what is on the registry; npm workspaces still links the local package for development, since 0.1.0 satisfies the range. - Added a README. Without one the npm page reads "No README data found", which is a poor landing surface for the reference implementation of a public standard. @logicsrc/schemas already ships one. Verified by installing 0.2.0 from the registry into an empty project: it resolves @logicsrc/validators@0.1.0 and @logicsrc/schemas@0.1.0, and the runtime reports OPENPRD_VERSION 0.3 with ten sections, eight for 0.2. Claude-Session: https://claude.ai/code/session_017XRNNm6pK6nPi7rJ6bJNHu Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
@logicsrc/openprd
Reference implementation of OpenPRD, a lightweight open standard for product requirements documents authored by humans or AI agents.
A repo keeps a numbered, committed collection under prd/ — one Markdown file
per product decision, with YAML front-matter, a fixed set of body sections, and
an enforced lifecycle. Where a change-oriented format models a change as a
multi-file bundle, OpenPRD models a product decision as one numbered file you
can read a year later to recover the why.
A PRD is just a file. Nothing here is required for a document to conform; this package exists to check and generate them.
Install
npm install @logicsrc/openprd
Or use it through the LogicSRC CLI, which wraps this package as logicsrc prd.
Usage
import { parsePrd, validatePrdDocument, loadPrdCollection, SECTIONS } from "@logicsrc/openprd";
const doc = parsePrd(source, "0001-expand-the-service.md");
const findings = validatePrdDocument(doc, { strict: true });
// Collection-level rules: contiguous numbering, unique ids, resolvable
// supersession links, a fresh index.
const collection = loadPrdCollection("prd");
The ten sections (OpenPRD 0.3)
Problem, Goals, Non-Goals, Users, Requirements, UX Notes,
Tech Stack, Monetization, Success Metrics, Risks & Open Questions — in
that order, all required. A section may be a single line such as _None._, but
it may not be missing. That is what keeps every PRD skimmable and diffable.
Versioning
A document is validated against the section list its own openprd: key fixes,
not against the newest version:
| Version | Sections |
|---|---|
0.2 |
eight |
0.3 |
ten — adds Tech Stack and Monetization after UX Notes |
So a 0.2 document keeps conforming. sectionsForVersion(version) exposes the
rule directly.
Conformance
A document conforms when it lives at prd/<id>-<slug>.md with a four-digit id,
its front-matter validates against openprd-prd.schema.json, id equals the
filename's numeric prefix, and every body section for its declared version is
present in order.
Everything else the validator reports is lint — an empty section, a requirement
missing its priority tag, numbering that skips, a stale index, a one-sided
supersession link. Findings carry stable codes (OP-C-SECTION-ORDER,
OP-L-REQ-DUPLICATE, …), the file, the line, and a remediation hint. strict
promotes lint to errors.
Links
MIT © Profullstack, Inc.