# To Prd > Turn the current conversation context into a PRD, saved as a local markdown file by default (published to the project issue tracker only when the user asks). Use when user wants to create a PRD from the current context. - Skill: `davie521/to-prd` (Agent Skill) - Install (CLI): `npx skillmds@latest add davie521/to-prd` - Raw SKILL.md: https://api.skillmd.com/api/skills/davie521/to-prd/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: Davie521 (https://skillmd.com/u/davie521) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/davie521/to-prd --- This skill takes the current conversation context and codebase understanding and produces a PRD. **Do NOT interview the user** — just synthesize what you already know. If the conversation has not produced enough context yet, say so explicitly and suggest `/grill-with-docs` first; do not start interviewing from this skill. ## Process 1. **Domain glossary check.** Before drafting the PRD: - If the project has a `CONTEXT.md` / domain glossary, read it and use the glossary's vocabulary throughout the PRD. - **If `CONTEXT.md` does NOT exist, surface this once** — say: "No `CONTEXT.md` yet. The PRD will use the most domain-precise terms I can extract from the conversation; want me to also seed a `CONTEXT.md` with the 3-5 load-bearing terms before publishing?" Don't block — proceed if AFK. - If `docs/adr/` exists, respect any ADRs in the area you're touching. 2. **Sketch the major modules** you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation. A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes. (See `improve-codebase-architecture/LANGUAGE.md` for the full vocabulary.) Check with the user that these modules match their expectations. Check with the user which modules they want tests written for. 3. **Write the PRD** using the template below, then save it: - **Default**: save to `docs/prds/PRD-{slug}.md` and tell the user the path. - **Publish as a GitHub issue only if the user asked for it, or confirms when you offer.** `gh auth status` succeeding means you *can* publish, not that you *should* — an issue on a shared or public repo is outward-facing. When publishing, apply the triage label vocabulary if one is configured (e.g. `ready-for-agent`). Otherwise, no label. ## Problem Statement The problem that the user is facing, from the user's perspective. ## Solution The solution to the problem, from the user's perspective. ## User Stories A LONG, numbered list of user stories. Each user story should be in the format of: 1. As an , I want a , so that 1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending This list of user stories should be extremely extensive and cover all aspects of the feature. ## Implementation Decisions A list of implementation decisions that were made. This can include: - The modules that will be built/modified - The interfaces of those modules that will be modified - Technical clarifications from the developer - Architectural decisions - Schema changes - API contracts - Specific interactions Do NOT include specific file paths or code snippets. They may end up being outdated very quickly. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits. ## Testing Decisions A list of testing decisions that were made. Include: - A description of what makes a good test (only test external behavior, not implementation details) - Which modules will be tested - Prior art for the tests (i.e. similar types of tests in the codebase) ## Out of Scope A description of the things that are out of scope for this PRD. ## Further Notes Any further notes about the feature. ## Use with - `grill-with-docs` — the *interview* counterpart to this skill. Run grill-with-docs first when the conversation hasn't established enough context; run `to-prd` to crystallise that context once it has. If the PRD's Implementation Decisions contain hard-to-reverse architectural choices, those should also become ADRs (criteria and format in its `ADR-FORMAT.md`). - `deep-plan` — once the PRD is published, run `deep-plan` to turn it into a phased implementation plan. ## Origin Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) — `engineering/to-prd`. License: MIT.