write-a-prd
This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.
-
Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions. The user may also provide links to external resources — Linear issues, Figma designs, or Notion documents.
-
Gather external context. If the user provided references to external tools, use the available MCP tools to pull in rich context before continuing:
- Linear: The user may provide a ticket code (e.g.,
EO-1234) or a URL. Use the Linear MCP tools to fetch issue details, comments, and status to understand requirements, acceptance criteria, and prior discussion. - Figma: The user may provide a Figma URL. Fetch design context and screenshots to understand the intended UI, component structure, and design constraints.
- Notion: The user may provide a page title or a URL. Search Notion by title if no URL is given. Fetch the document to pull in specs, meeting notes, or background research.
Use this external context alongside the user's description to form a more complete picture of the problem space. If no external references are provided, skip this step.
- Linear: The user may provide a ticket code (e.g.,
-
Explore the repo to verify their assertions and understand the current state of the codebase.
-
Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. Refer back to any external context gathered in step 2 to avoid re-asking questions that are already answered in Linear issues, Figma designs, or Notion docs.
-
Sketch out 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.
More from evans-sam/skills
grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
15git-guardrails-claude-code
Set up Claude Code hooks to block dangerous git and gh CLI commands before they execute. Use when user wants to prevent destructive git operations, block dangerous GitHub CLI actions (repo delete, pr merge, secret management, API mutations), or add git/gh safety hooks to Claude Code.
14request-refactor-plan
Create a detailed refactor plan with tiny commits via user interview, then save it as a local markdown RFC document. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.
13prd-to-issues
Turn a PRD into independent ticket artifacts — GitHub issues, Linear tickets, local files, or Notion pages — with HITL/AFK tags and dependency links. Each ticket is a tracer-bullet vertical slice. Use when user wants to produce standalone work items from a PRD. Not for a live feature-building workflow.
12design-an-interface
Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".
12ubiquitous-language
Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD".
11