Menu
Turn the current conversation context into a PRD and save it. Use when user wants to create a PRD from the current context.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Break a plan, spec, or PRD into independently-grabbable slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
Write a handoff on the active issue so the next session can pick it up where you left off.
Log today's work by reconstructing it from git history across all your repos. Use at the end of a day to record what was done, optionally split by work vs personal.
| name | to-prd |
| description | Turn the current conversation context into a PRD and save it. Use when user wants to create a PRD from the current context. |
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.
The PRD is written to one backend, selected by output: in the project's CLAUDE.local.md:
output: github — default when the key is absent. Personal projects. The PRD becomes a GitHub tracking issue (the "Epic"), labelled epic, with the PRD as the issue body.output: jira — work projects. The PRD becomes the description of a Jira ticket.output: inkdrop — the PRD becomes a note in the project's Spec notebook.If output: names a backend not listed here, stop and tell the user: backend <x> not supported; supported: github, jira, inkdrop.
CLAUDE.local.md at the project root to determine the backend (default github).gh issue list --label epic --search "<feature>".search-notes for an existing Spec note.Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
Sketch out the major modules you will need to build or modify. 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.
Check with the user that these modules match their expectations, and which modules they want tests written for.
The problem the user is facing and the context, from the user's perspective. 2-4 sentences.
What is explicitly out of scope for this PRD.
The solution to the problem, from the user's perspective.
A LONG, numbered list of user stories, in the format:
This list should be extensive and cover all aspects of the feature.
Modules to build/modify, their interfaces, technical clarifications, architectural decisions, schema changes, API contracts, specific interactions.
Do NOT include specific file paths or code snippets — they go stale fast. 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 it came from a prototype. Trim to the decision-rich parts.
What makes a good test (test external behavior, not implementation details), which modules will be tested, and prior art for the tests in the codebase.
(populated by /to-issues after breakdown)
Links to related issues, PRs, ADRs, or external docs.
epic label exists (create on-demand, ignore error if present):
gh label create epic --color 5319E7 --description "Tracking issue / PRD" 2>/dev/null || truegh issue edit <n> --body-file <tmp>.
Otherwise: gh issue create --label epic --title "<feature>" --body-file <tmp>./to-issues will attach sub-issues to it.Spec notebook (under the project notebook in Solo Dev) via list-notebooks.none.