From evanflow
Synthesizes PRD for substantial new features from project context, ADRs, commits, and conversation. Validates modules/architecture, writes structured spec in docs/specs/. Asks before GH issue.
npx claudepluginhub evanklem/evanflow --plugin evanflowThis skill uses the workspace's default tool permissions.
See `evanflow` meta-skill.
Generates a PRD from conversation context and codebase analysis using a structured template, publishes to project issue tracker. Use to formalize features from chats.
Generates complete PRDs via guided feature discovery, product context integration, clarifying questions, and optional codebase analysis. Outputs user stories, Gherkin criteria, metrics, and launch plans.
Generates structured Product Requirements Documents (PRDs) by gathering project context from files and commits, asking 3-5 clarifying questions with lettered options, and producing sections like user stories, functional requirements, non-goals, and success metrics.
Share bugs, ideas, or general feedback.
See evanflow meta-skill.
SKIP when: the work is small enough for evanflow-brainstorming → evanflow-writing-plans directly.
The skill name is "to-prd" not "interview-to-prd" for a reason. Synthesize from what's already known:
CLAUDE.md for project conventionsCONTEXT.md for domain languagedocs/adr/ for prior architectural decisionsdocs/stakeholder/*.md for in-flight initiativesOnly ask the user for things you genuinely cannot derive.
Sketch the modules to build/modify, emphasizing deep modules (small interface, complex internals). Apply the deletion test to each — does this module earn its existence?
Confirm with the user:
Default location: docs/specs/YYYY-MM-DD-<feature>.md. Use the user's preferred path if they have one.
Structure:
# [Feature Name] PRD
## Problem
One paragraph: what's broken or missing in the current product, and who feels the pain.
## Solution
One paragraph: the shape of the answer, named in domain language.
## User stories
- As a <role>, I can <action> so that <outcome>.
- (List 5-15)
## Architecture
Module list with one-line responsibility per module. Reference existing files where relevant. No code paths.
## Testing strategy
What behaviors must be covered. Integration vs. unit. Real services vs. test doubles.
## Scope
In:
- ...
Out:
- ...
## Open questions
Things needing decision before the plan can be written.
If the user wants the PRD as a GitHub issue, ASK before running gh issue create. Never auto-file.
CONTEXT.md. Use canonical terms.gh issue create. No auto-file.evanflow-writing-plans. If the PRD's module list shows 3+ independent components sharing a contract, the plan should be structured for evanflow-coder-overseer.evanflow-glossary to update CONTEXT.mdevanflow-improve-architecture firstevanflow-design-interface before plan