Prologue · preview
The spec, before the code.
A home for your PRDs, TRDs, RFCs and ADRs that isn't a wiki tab no one opens. Specs live as specs/*.md in the repos that implement them; Prologue indexes them on every push into one project view, across every repo the work touches. Git is the record.
---
title: Auth rewrite — PRD
kind: prd
status: review
parent: auth-overview
---
# Auth rewrite — PRD
…Why Prologue
Typed, linked, and next to the code.
Specs are first-class
A PRD, TRD, RFC or ADR is a typed object with a status and a parent — a few lines of frontmatter, indexed — not a markdown file in /docs nobody validates.
Projects span repos
A project enrols one repo or five. Product specs can sit in a central specs repo and each TRD next to the service it changes; a shared repo can feed several projects.
PRD → TRD, linked
The why and the how, connected: parent: names the doc above, resolved across every repo in the project. Forward references settle on the next push.
Review on GitHub
A spec changes the way code does: a branch, a pull request, a merge. Your team reviews it with the tools they already use, and Prologue re-indexes on push.
Versioned by git
The history is git log. Every indexed document records the commit it came from, so what the console shows is always traceable to a sha.
Permission follows GitHub
The same model as the rest of Runsheet. Org admins manage projects; repo permissions gate what each member can read. No second access system.
How it works
Write where the code is, read in one place.
Repos are canonical; the console is the viewer. Nothing to publish, nothing to sync back.
- 01
Start a project
Name the initiative from your org in the console. A project is the unit of grouping — one effort, however many repos it touches.
- 02
Enrol the repos
From the project's settings. Prologue reads
specs/*.mdfrom each enrolled repo on enrolment and on every push after. - 03
Read the tree
Every document across the enrolled repos, with its kind, status, parent and the commit it came from. Ask for everything under a PRD and get the whole design surface.
Doc types
Four shapes, one default.
The kinds cover almost everything teams write before code. Without a kind in the frontmatter, a document is a plain spec.
PRD
Product requirements. Why we're building this, who it's for, what success looks like. One per initiative.
TRD
Technical design. How a specific service implements its share of the PRD, next to the code it changes.
RFC
Cross-cutting proposals that don't sit under a single PRD. Platform decisions, conventions, deprecations.
ADR
Architecture decision records. Short, narrow, retrospectively useful. The context behind a choice that's hard to reconstruct later.
How it compares
Every team writes specs somewhere.
Most of those places have one or two of these properties; almost none have all of them.
| Notion / Confluence | Markdown in one repo | Prologue | |
|---|---|---|---|
| Lives next to code | No | Yes | Yes |
| Typed docs (PRD, TRD, …) | Manual convention | Frontmatter, if you remember | Frontmatter, indexed |
| Spans multiple repos | Yes | No — one repo, one folder | Yes — a project enrols many |
| Review tools | Comments | PR review | PR review |
| History | Page history | Git history | Git history, indexed per commit |
| Auth model | Separate SaaS | GitHub repo perms | GitHub repo perms |
Want it early?
Prologue is in preview. If your team writes PRDs and would like to try it on real specs, get in touch.