Stats
Actions
Tags
From adrianfernandezalv-skills
Generates a Product Requirements Document (PRD) from the current conversation context and codebase understanding, saving it to a configured backend (GitHub, Jira, or Inkdrop).
How this skill is triggered — by the user, by Claude, or both
Slash command
/adrianfernandezalv-skills:to-prdThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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.npx claudepluginhub adrianfernandezalv/skillsSynthesizes conversation context and codebase into a structured PRD with user stories, modules, testing plans, then publishes to project issue tracker. Use for creating PRDs from discussions.
Generates a PRD from the current conversation context and codebase understanding, then publishes it to the project's issue tracker (GitHub, GitLab, or local) after user confirmation.
Synthesizes conversation and codebase context into a structured PRD and publishes it to the project issue tracker.