EvanFlow: PRD
SkillDocs & knowledgeSynthesize a PRD (Product Requirements Document) for a big new feature. Synthesis (not interview) — uses existing project context and explicit ADRs. Asks before gh issue create. Use when scoping a substantial new feature in PRD shape (e.g., before a sprint).
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the EvanFlow: PRD skill
What this skill tells your AI
The instructions your AI receives, as published by evanklem/evanflow in skills/evanflow-prd/SKILL.md and read by ahel’s review.
Vocabulary
See evanflow meta-skill.
When to Use
- Substantial new feature requiring stakeholder alignment
- Pre-sprint scoping
- A spec exists in conversation but needs structured form for the team
SKIP when: the work is small enough for evanflow-brainstorming → evanflow-writing-plans directly.
The Flow
1. Read Context (don't interview)
The skill name is "to-prd" not "interview-to-prd" for a reason. Synthesize from what's already known:
CLAUDE.mdfor project conventionsCONTEXT.mdfor domain languagedocs/adr/for prior architectural decisions- Recent commits and
docs/stakeholder/*.mdfor in-flight initiatives - The conversation up to this point
Only ask the user for things you genuinely cannot derive.
2. Identify Major Modules
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?
3. Validate Architecture
Confirm with the user:
- The module list (correct, exhaustive, no gaps)
- Which components require test coverage (you can't test everything)
- Which existing patterns to follow vs. diverge from
4. Write the PRD
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.
5. Optional: Create GitHub Issue
If the user wants the PRD as a GitHub issue, ASK before running gh issue create. Never auto-file.
Hard Rules
- Synthesize, don't interrogate. Ask only for genuinely unknown things.
- Domain language from
CONTEXT.md. Use canonical terms. - External behavior over implementation. Testing strategy describes what to verify, not how.
- Asks before
gh issue create. No auto-file. - Never auto-commit. PRD doc gets staged; user confirms before commit.
Hand-offs
- PRD approved, ready for plan →
evanflow-writing-plans. If the PRD's module list shows 3+ independent components sharing a contract, the plan should be structured forevanflow-coder-overseer. - New domain terms emerged →
evanflow-glossaryto updateCONTEXT.md - PRD reveals architecture concerns →
evanflow-improve-architecturefirst - PRD's interface design needs more thought →
evanflow-design-interfacebefore plan
Signals
- GitHub stars
- 418
- Forks
- 18
- Last commit
- May 2026
Advanced
- Catalog kind
- skill
- Gateway key
evanflow-prd- Source
- github.com/evanklem/evanflow