Obsidian PRD
Guides the user through a 5-phase interview process and writes a structured PRD to an Obsidian vault.
Setup
Establish vault context before starting:
- Vault path: absolute path to vault root — default
~/Documents/Obsidian/<vault-name> - PRD folder: default
PRD/
If not provided, ask the user before proceeding.
Workflow
Phase 1 — Describe
Ask for a long, detailed description of:
- The problem being solved
- Any solution ideas the user already has
- Who is affected
Do not proceed until this is thorough.
Phase 2 — Explore (skip if no repo context)
Explore the repository to verify assertions and understand current state:
- Identify relevant modules, files, and patterns
- Note what exists vs. what must be built
- Flag any mismatches with the user's description
Phase 3 — Interview
Relentlessly ask about every aspect until nothing is ambiguous. Cover:
- Actors: who uses this? internal users, external users, systems?
- Scope: what is explicitly in vs. out?
- Edge cases: failure modes, empty states, concurrent access, permissions
- Dependencies: external services, libraries, other modules
- Design decisions: present options and resolve them one by one
Do not batch all questions at once. Work through them conversationally, resolving each before moving on.
Phase 4 — Sketch Modules
Identify the major modules to build or modify:
- Mark each as deep (significant logic) or shallow (config/glue)
- For each deep module, ask: "Does this need tests? What behavior matters most?"
- Confirm the list with the user before writing the PRD
Phase 5 — Write PRD
Write <vault>/PRD/<Title>.md using the template in TEMPLATE.md.
Frontmatter:
---
title: <title>
created: YYYY-MM-DD HH:mm
status: draft
repo: <repo-name or empty>
---
Body: see TEMPLATE.md for full section structure.
Confirm the file path to the user when done.
Key Rules
- Never use Templater syntax — write final values directly
- Filenames = wiki-link identifiers — keep titles stable after creation
- User Stories must be exhaustive — use format: "As a <actor>, I want <feature>, so that <benefit>"
- Implementation Decisions: describe approach and rationale — no file paths or code snippets (they go stale)
- Testing Decisions: describe external behavior to test, not implementation internals