A place to write down what you're building, and why — before anyone builds it.
Most teams decide what to build in meetings, Slack threads, and half-remembered hallway conversations. Six months later nobody can say why the feature works the way it does, the person who knew has left, and the same argument happens again from scratch.
A PRD — Product Requirements Document — is the fix. One page that says what problem you're solving, who has it, what "done" looks like, and what you're deliberately not doing. Write it before the work starts, and the team argues about the idea while it's still cheap to change.
This repo gives you three things:
- Templates that force the right questions — what's the actual problem? what number moves? what's out of scope?
- A review process built on pull requests, so decisions get discussed and recorded instead of assumed
- Claude Code as a writing partner that knows the format, drafts from a conversation, and reviews your work before anyone else sees it
You do not need to be technical to use it. If you can write in a text box and click a button, you can use this. Claude handles the Git parts.
curl -fsSL https://claude.ai/install.sh | bash # install Claude Code
git clone https://github.com/YOUR_ORG/prd-template.git && cd prd-template
claude # start itThen type:
/setup
Claude configures the repo with you — asks what you need, sets up keys and integrations, and offers to draft your first document. You never have to open a config file.
Already set up? Type /guide to see what you can do, or just say what you need:
"I need a PRD for letting users mute notification categories."
The right skill activates on its own.
| Say this | Or type | And you get |
|---|---|---|
| "Write a PRD for X" | /new-prd |
A full PRD drafted from the template |
| "We're choosing between A and B" | /new-decision |
A decision record with alternatives and trade-offs |
| "Research how competitors handle X" | /new-research |
A cited research brief with a recommendation |
| "Is this PRD ready?" | /review-prd |
A scored checklist with specific fixes |
| "What job is the user hiring this for?" | /jtbd-analysis |
A Jobs-to-be-Done analysis of the PRD |
| "Help me set this up" | /setup |
Guided configuration |
| "What can I do here?" | /guide |
The tour |
1. Branch -> 2. Write -> 3. Pull request -> 4. Review -> 5. Merge
Ask Claude to do any of it — "open a PR for this" works. The full process, including the document status lifecycle, lives in the workflow skill.
Documents land in one of three folders, all named
YYYY-MM-DD_short-description.md:
| Folder | For | Example |
|---|---|---|
prds/ |
New features and initiatives | 2026-08-26_notification-preferences.md |
decisions/ |
Key choices — build vs buy, tech picks, scope cuts | 2026-08-26_markdown-over-google-docs.md |
research/ |
Interviews, competitive analysis, market data | 2026-08-26_competitor-pricing.md |
Bugs go in GitHub Issues, not here.
Before writing your first document, read a finished one:
- PRD example — a notification preferences feature
- Decision example — choosing markdown over Google Docs
prd-template/
├── prds/ # Active PRDs — one per feature or initiative
├── decisions/ # Decision records — key product and tech calls
├── research/ # Research, analysis, interview notes
│
├── docs/
│ ├── guide.md # Setup guide (Claude reads this during /setup)
│ ├── templates/ # PRD, decision, and research templates
│ └── examples/ # Filled-in examples
│
├── .claude/
│ ├── skills/ # What Claude knows how to do here
│ └── commands/ # Slash-command entrypoints
│
├── .github/ # PR and issue templates, CI
├── AGENTS.md # Instructions for Claude and other agents
└── .mcp.json # Integrations (GitHub, web search, and more)
Capabilities live in .claude/skills/. They're plain markdown — readable by you,
loaded by Claude when the work matches. No slash command required.
| Skill | Covers |
|---|---|
prd-authoring |
Writing PRDs — job stories, metrics, scope |
decision-records |
Capturing choices and trade-offs |
research-briefs |
Evidence-backed research with citations |
prd-review |
Quality review before a PR |
jtbd-analysis |
Jobs-to-be-Done framework |
prd-workflow |
Branches, PRs, status lifecycle |
repo-setup |
Onboarding and configuration |
Click Use this template on GitHub. You get a fresh repo with its own history, and the CI activates automatically — it's deliberately dormant in this template repo so it doesn't run against the examples.
Then claude and /setup. Claude will offer to connect the tools your team
already uses — HubSpot, Google Drive, Gmail, Notion, Slack, Linear — so research
and PRDs can draw on real customer data instead of guesses. Full list and manual
instructions in the setup guide.
Runs on every pull request in your copy of this repo:
| Check | What it does |
|---|---|
| Secret Guard | Blocks API keys and credential files from ever entering the repo |
| Markdown Lint | Formatting on changed .md files |
| Document Checks | Enforces the YYYY-MM-DD_short-description.md naming; warns on missing PRD sections |
| Auto-Label | Tags PRs as prd, decision, research, or docs |
Naming is enforced. Structure checks are warnings only — they nudge, they don't block. See CI setup for labels and CODEOWNERS.
Your API keys stay on your machine. They live in
.claude/settings.local.json, which is gitignored, guarded by a pre-commit
hook, and re-checked in CI. Run git config core.hooksPath .githooks once per
clone to enable the hook — /setup does it for you.
Everything still works. Copy a template, write in any editor, open a PR:
cp docs/templates/prd-template.md prds/2026-08-26_my-feature.mdThe templates are the product. The AI is a convenience.
MIT — use this however you like.