Turn AI conversation context into a clean PRD. #PRD #ProductRequirements #SpecWriting #ProductDesign #RequirementsDoc

README.md

conversation-to-prd AI Skill

Turn an AI conversation into a Product Requirements Document (PRD).

What it does

This skill reads the current conversation context and generates a single PRD from it. It is designed for conversations with AI where the goal is to capture requirements from what has already been discussed.

Intended use

Use this skill when a conversation has already defined enough product context and the next step is to convert that context into a clear PRD.

Behavior

The skill should:

1. Review the full conversation.
2. Extract the problem, solution, constraints, assumptions, and decisions already present.
3. Organize that information into a structured PRD.
4. Output only the PRD.

Output format

The PRD should contain these sections:

• Problem Statement
• Solution
• User Stories
• Requirements
• Implementation Decisions
• Out of Scope
• Open Questions
• Further Notes

Prompt.md

You are to turn the current conversation context into a single Product Requirements Document (PRD).

Do not interview the user. Do not ask follow-up questions. Do not inspect any repo or codebase. Do not reference issue trackers, labels, publishing workflows, or triage vocabulary. Do not produce anything except the PRD.

Your job is to synthesize only what is already present in the conversation and output a PRD in the format below.

Process

1. Review the full conversation context and identify:

   • The user’s problem
   • The desired outcome
   • The proposed solution
   • Constraints, assumptions, and decisions already stated
   • Open questions only if they are necessary to document in the PRD

2. Infer the feature or product requirements strictly from the conversation. Do not add implementation detail unless it was explicitly discussed or is required to make the PRD coherent.

3. Write the PRD using the template below.

4. Output only the PRD. Do not include commentary, preamble, follow-up questions, publishing steps, issue tracker references, labels, or extra explanation.

   <prd-template>
   
   ## Problem Statement
   
   Describe the problem the user is trying to solve, from the user's perspective.
   
   ## Solution
   
   Describe the proposed solution, from the user's perspective.
   
   ## User Stories
   
   Provide a numbered list of user stories in this format:
   
   1. As a <actor>, I want a <feature>, so that <benefit>
   
   Make the list extensive enough to cover the major workflows, edge cases, constraints, and expected outcomes discussed in the conversation.
   
   <user-story-example>
   1. As a returning customer, I want to save my preferences, so that I can complete future tasks faster.
   </user-story-example>
   
   ## Requirements
   
   List the functional and non-functional requirements implied or explicitly stated in the conversation.
   
   Include:
   - Core functionality
   - UX expectations
   - Inputs and outputs
   - Constraints
   - Success criteria
   
   ## Implementation Decisions
   
   Document the implementation decisions already established in the conversation.
   
   This can include:
   - Architectural choices
   - System behavior
   - Data shapes
   - API expectations
   - Interaction patterns
   - Technical constraints
   - Product rules
   
   Do NOT include file paths or code snippets.
   
   Exception: if the conversation already contains a prototype snippet, schema, reducer, state machine, or type shape that captures a decision more precisely than prose, include only the decision-relevant portion and note that it came from the conversation.
   
   ## Out of Scope
   
   List anything that is explicitly out of scope, deferred, excluded, or not yet decided based on the conversation.
   
   ## Open Questions
   
   List only the unresolved questions that materially affect implementation or scope and were not answered in the conversation.
   
   ## Further Notes
   
   Add any other important context, assumptions, or clarifications that should be preserved from the conversation.
   
   </prd-template>
   

SKILL.md

name	conversation-to-prd
description	Turn the current conversation context into a PRD. Use when the user wants a PRD generated from the conversation.

This skill takes the current conversation context and produces a PRD. Do NOT interview the user. Do NOT explore a repo, inspect a codebase, reference issue trackers, or publish anywhere. Only synthesize what is already present in the conversation.

Your job is to generate a single PRD from the conversation and nothing else.

Process

1. Review the full conversation context and identify:

   • The user’s problem
   • The desired outcome
   • The proposed solution
   • Constraints, assumptions, and decisions already stated
   • Open questions only if they are necessary to document in the PRD

2. Infer the feature or product requirements strictly from the conversation. Do not add implementation detail unless it was explicitly discussed or is required to make the PRD coherent.

3. Write the PRD using the template below.

4. Output only the PRD. Do not include commentary, preamble, follow-up questions, publishing steps, issue tracker references, labels, or extra explanation.

   <prd-template>
   
   ## Problem Statement
   
   Describe the problem the user is trying to solve, from the user's perspective.
   
   ## Solution
   
   Describe the proposed solution, from the user's perspective.
   
   ## User Stories
   
   Provide a numbered list of user stories in this format:
   
   1. As a <actor>, I want a <feature>, so that <benefit>
   
   Make the list extensive enough to cover the major workflows, edge cases, constraints, and expected outcomes discussed in the conversation.
   
   <user-story-example>
   1. As a returning customer, I want to save my preferences, so that I can complete future tasks faster.
   </user-story-example>
   
   ## Requirements
   
   List the functional and non-functional requirements implied or explicitly stated in the conversation.
   
   Include:
   - Core functionality
   - UX expectations
   - Inputs and outputs
   - Constraints
   - Success criteria
   
   ## Implementation Decisions
   
   Document the implementation decisions already established in the conversation.
   
   This can include:
   - Architectural choices
   - System behavior
   - Data shapes
   - API expectations
   - Interaction patterns
   - Technical constraints
   - Product rules
   
   Do NOT include file paths or code snippets.
   
   Exception: if the conversation already contains a prototype snippet, schema, reducer, state machine, or type shape that captures a decision more precisely than prose, include only the decision-relevant portion and note that it came from the conversation.
   
   ## Out of Scope
   
   List anything that is explicitly out of scope, deferred, excluded, or not yet decided based on the conversation.
   
   ## Open Questions
   
   List only the unresolved questions that materially affect implementation or scope and were not answered in the conversation.
   
   ## Further Notes
   
   Add any other important context, assumptions, or clarifications that should be preserved from the conversation.
   
   </prd-template>