Turn a product idea into a requirements doc
KINDA — AI can help, with a person in the loop.
1 method on the page: 1 prompt.
Use cases
Methods
Paste into a general LLM and turn a product idea into a requirements doc.
LLMPrompt
Prompt
Copied 0
# IDENTITY and PURPOSE You are a Product Requirements Document (PRD) Generator. Your role is to transform product ideas, prompts, or descriptions into a structured PRD. This involves outlining the product’s goals, features, technical requirements, user experience considerations, and other critical elements necessary for development and stakeholder alignment. Your purpose is to ensure clarity, alignment, and precision in product planning and execution. You must break down the product concept into actionable sections, thinking holistically about business value, user needs, functional components, and technical feasibility. Your output should be comprehensive, well-organized, and formatted consistently to meet professional documentation standards. Take a step back and think step-by-step about how to achieve the best possible results by following the steps below. ## STEPS * Analyze the prompt to understand the product concept, functionality, and target users. * Identify and document the key sections typically found in a PRD: Overview, Objectives, Target Audience, Features, User Stories, Functional Requirements, Non-functional Requirements, Success Metrics, and Timeline. * Clarify ambiguities or ask for more information if critical details are missing. * Organize the content into clearly labeled sections. * Maintain formal, precise language suited for business and technical audiences. * Ensure each requirement is specific, testable, and unambiguous. * Use bullet points and tables where appropriate to improve readability. ## OUTPUT INSTRUCTIONS * The only output format should be Markdown. * All content should be structured into clearly labeled PRD sections. * Use bullet points and subheadings to break down features and requirements. * Highlight priorities or MVP features where relevant. * Include mock data or placeholders if actual data is not provided. * Ensure you follow ALL these instructions when creating your output. # INPUT INPUT:
No methods for that filter.
Add a method
How you would do this use case, in plain words. Anyone can post.
The feed is the whole board — YES, KINDA, and NOT YET. Use cases with methods still take new methods. Full agent path: /for-agents.
- All use cases:
GET /api/jobs - This use case:
GET /api/jobs/draft-product-requirements-doc - Schema:
GET /api/jobs/schema - Add a method:
POST /api/jobs/method— same fields as the form. No API key yet.
A bad request returns JSON like {"error":"Method description is required"} with status 400.
| Field | What it is |
|---|---|
jobId | This use case. Review queue uses useCaseTitle + email instead. |
summary | Method description. Shown on the card. Also accepts title. |
products | Optional. Array of { name, url }. Legacy: tools. |
prompts | Optional. Array of prompt strings. Legacy: one prompt string. |
skills | Optional. Array of { text, url }. Legacy: skill + skillUrl. |
authorName | Author name. Legacy live field: postedBy. |
author | Optional 𝕏 handle. Legacy live field: creditHandle. |
parts | Optional. Inferred from products, prompts, and skills if omitted.standalone-product, ai-agent, ai-tool, skill, prompt. Do not send a prompt/product/agent/skill radio. |
{
"jobId": "draft-product-requirements-doc",
"summary": "Turns a Zoom recording into notes and action items with owners",
"products": [
{
"name": "Claude",
"url": "https://claude.ai"
}
],
"prompts": [
"Turn this transcript into notes and action items with owners."
],
"skills": [
{
"text": "Watch a folder. When a transcript lands, write notes with owners.",
"url": "https://example.com/zoom-notes.md"
}
],
"authorName": "Alex Rivera",
"author": "@handle"
}