prd

Files (2)

• SKILL.md
• prd-new.mjs · scripts/

SKILL.md (first lines)

# PRD Skill

Manages Product Requirements Documents — the contract between vault planning
and code execution. PRDs live at `2. Areas/Product Manager/PRDs/<Name>.md`
and follow a schema that lets braynee seed beads issues from the
Acceptance Criteria section.

## Commands

```bash
# Scaffold a new PRD with the canonical schema
node {baseDir}/scripts/prd-new.mjs "<Name>"

# Same, but as a multi-file folder PRD (hub + section files)
node {baseDir}/scripts/prd-new.mjs "<Name>" --folder-form

# Convert an existing monolithic PRD into the folder form
node {pluginRoot}/scripts/prd-split.mjs "<Name>" [--sections "A,B"] [--all] [--dry-run]

# Audit every PRD against the schema (re-runnable; reports gaps)
node {pluginRoot}/scripts/prd-audit.mjs

# Seed beads issues from a PRD's Acceptance Criteria section
node {pluginRoot}/scripts/prd-seed.mjs "<Name>" [--dry-run]
# ...then, after every real (non-dry-run) seed, dispatch the enricher —
# see "Seed, then enrich" below. The seed is not finished until it has run.
```

## Two shapes: single-file and folder PRDs

A PRD is either one file or a folder of files. Both are first-class — `audit`
and `seed` treat a folder PRD as ONE document, not as many.

```
monolithic:  PRDs/<Name>.md
folder:      PRDs/<Name>/<Name>.md      <- the hub: frontmatter lives here
             PRDs/<Name>/Architecture.md   <- section files (no frontmatter)
             PRDs/<Name>/Scope.md
```

**Rules that make the folder form work:**

- **The hub is named after its folder** (`Foo/Foo.md`), and is the ONLY file in
  the folder with `type: prd` frontmatter. That is how the hub is identified;
  a second `type: prd` file in the same folder makes it ambiguous.
- **Section files carry no PRD frontmatter.** They are chapters, not PRDs, and
  are never audited or seeded on their own.
- **Acceptance Criteria may live in the hub or in a section file** — `prd-seed`
  and `prd-audit` both read across the hub and all its sections. Keeping them in
  the hub is still preferred, since the hub then reads as a complete summary.
- **Reach for the folder form** when a PRD outgrows one screen of scrolling, or
  when a section (architecture, competitive research, an API reference) is
  substantial enough that people will link to it directly.

`prd-split` never rewrites prose: it moves whole `##` sections into files, leaves
a wikilink in the hub where each one was, and aborts before writing if any line
of the original would be unaccounted for. Use `--dry-run` to see the plan first.

## PRD Schema

### Frontmatter (required fields)

```yaml
---
type: prd
name: <Name> PRD
project: "[[1. Projects/<Name>]]"      # backlink to project file
folder: <slug>                         # project repo dir name — the join key (see note below)
version: "1.0"
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: draft | active | shipped | archived
build_status: not-started | planning | drafting | in-progress | blocked | shipped
client: <optional>                     # only when category=client
seeded: false                          # flips to true after prd-seed runs
seeded_at: ""                          # ISO timestamp set by seeder
seeded_count: 0                        # how many bd issues were created
tags: [prd, ...]
---
```

### Body section order (canonical)

1. Hero / Tagline
2. **MVP Definition** ← Auth, Freemium, 3–5 Core Features (forcing function)
3. Triple-Purpose Asset
4. North Star Metric (with Activation Moment + OKRs table)
5. Lean Canvas
6. Personas / JTBD
7. User Journeys
8. Scope (In / Out / Future)
9. Architecture
10. Milestones
11. **Acceptance Criteria** ← seed source
12. Risks & Open Questions
13. Appendix / Links

### MVP Definition — the gate

A PRD without this section is not ready to seed. Forces three decisions:

```markdown
## MVP Definition

### Auth
<approach: Clerk / Supabase / custom; SSO needs; org/team support>

### Freemium
<free tier limits, paid tier pricing, usage gates, signup-to-paywall path>

### Core Features (3–5)
1. <feature>
2. <feature>
3. <feature>
```

Acceptance Criteria should map back to the Core Features. If a criterion isn't
in service of one of the 3–5 listed features, ask whether the feature list is
incomplete or the criterion is out of scope.

From hamchowderr/braynee, MIT.

More from hamchowderr/braynee