Prompt Engineering for Builders

ROLE: You are a {{role}} with expertise in {{domain}}.

CONTEXT: {{background about the project, users, constraints}}

TASK: {{specific action you need taken}}

FORMAT: Output as {{format}}. Include {{specific elements}}.
Keep it under {{length}} words. Use {{tone}} tone.

You are an expert {{domain}} consultant with 15+ years of experience.
You've worked with startups and enterprises. You give direct, actionable
advice — no fluff, no theory without examples.

When I ask a question:
1. First, clarify any ambiguities with 1-2 questions if needed
2. Give your recommendation with reasoning
3. Provide a concrete example or template
4. List potential pitfalls to avoid

Current project: {{brief description}}
My question: {{your question}}

Review the following {{document type}} with a critical eye.

Look for:
- Logical gaps or inconsistencies
- Missing edge cases or scenarios
- Unclear language or ambiguous requirements
- Assumptions that should be stated explicitly
- Opportunities to simplify or restructure

For each issue found:
1. Quote the problematic section
2. Explain why it's an issue
3. Suggest a specific fix

Be direct and thorough. Don't sugarcoat.

{{paste your content here}}

Transform the following {{input type}} into a {{output type}}.

Rules:
- Preserve all original meaning and intent
- Add structure where it's missing (headers, lists, tables)
- Remove redundancy and filler
- Use clear, professional language
- Keep the same level of detail — don't add or remove substance

Input:
{{paste rough notes, meeting transcript, or raw thoughts}}

Output format:
{{describe the desired structure}}

Explain {{concept/technology/code}} to me.

I am a {{your level — e.g., "mid-level developer who knows React but not Rust"}.

Requirements:
- Start with a one-paragraph overview
- Use analogies to things I already know
- Include a practical code example
- Explain the "why" — not just the "what"
- List the top 3 things I should know before using this
- Point me to the best resource for going deeper

Keep it under 800 words. Be specific, not generic.

Write a product spec for the following feature.

Context:
- Product: {{what you're building}}
- Users: {{who uses it}}
- Problem: {{what pain point this solves}}
- Constraints: {{tech stack, timeline, budget, etc.}}

The spec should include:
1. Overview — one paragraph summary
2. User Stories — 3-5 stories in "As a [user], I want [action] so that [benefit]" format
3. Requirements — functional requirements as a checklist
4. Non-Functional Requirements — performance, security, accessibility
5. Edge Cases — what could go wrong
6. Out of Scope — what we're explicitly NOT building
7. Success Metrics — how we'll know it worked
8. Open Questions — things we still need to figure out

Use clear, concise language. No marketing speak. Write for engineers.

# Make it more specific
"This is too generic. Rewrite the requirements section with
specific technical details. Assume we're using {{tech stack}}.
Include API endpoints, data models, and error handling."

# Challenge assumptions
"Challenge the assumptions in this spec. What are we taking
for granted that might be wrong? What could we build instead
that solves the same problem with less complexity?"

# Add edge cases
"List 10 edge cases we haven't considered. Focus on:
- User error scenarios
- Data edge cases (empty, huge, malformed)
- Concurrent access issues
- Network failures and timeouts"

Generate user stories for a feature that {{describe feature}}.

Our users:
- Primary: {{describe primary user persona}}
- Secondary: {{describe secondary user persona}}
- Their biggest pain point: {{describe the problem}}

For each user type, generate:
1. Happy path stories (the main flow works perfectly)
2. Edge case stories (things go wrong)
3. Admin/operational stories (managing the feature)

Format each story as:
"As a [type of user], I want [action] so that [benefit]."

Add acceptance criteria for each story as a bullet list.

Prioritize these user stories using the MoSCoW method:
- Must have (non-negotiable for launch)
- Should have (important but not critical)
- Could have (nice to have if time permits)
- Won't have (explicitly deferred)

Criteria for prioritization:
1. User impact — how many users does this affect?
2. Risk — what happens if we don't build this?
3. Dependencies — does this block other stories?
4. Effort — rough estimate (S/M/L)

{{paste your user stories here}}

# Project Context
Brief description of what this project is and who it's for.

# Tech Stack
- Frontend: {{framework}}
- Backend: {{framework}}
- Database: {{database}}
- Testing: {{framework}}

# Code Style
- Use {{language}} conventions
- Prefer {{pattern}} over {{alternative}}
- Naming: {{convention}}
- Imports: {{order}}

# Behavioral Rules
1. Always read the full file before making changes
2. Never delete code without explaining why
3. Ask before making destructive changes
4. Keep changes minimal and focused
5. Run tests after making changes

# Project-Specific Knowledge
- Key files and their purposes
- Important architectural decisions
- Common gotchas or quirks

# Make it shorter
"Condense this to half the length. Keep all key information
but remove examples and explanations that aren't essential."

# Make it more specific
"This is too generic. Rewrite it for {{specific context}}.
Include concrete examples from {{specific domain}}."

# Change the audience
"Rewrite this for {{audience}}. They know {{what they know}}
but not {{what they don't know}. Use {{tone}} tone."

# Add structure
"Restructure this with clear headers, bullet points, and
a summary table at the top. Make it scannable."

I'm building {{product description}} for {{target users}}.

Brainstorm 10 feature ideas that would delight these users.
For each idea:
- Name (3-5 words)
- One-line description
- User value (why they'd care)
- Complexity estimate (S/M/L/XL)
- One-sentence implementation approach

Prioritize ideas that are high-value and low-complexity.

Analyze the competitive landscape for {{product category}}.

Compare these competitors: {{list 3-5 competitors}}

For each, cover:
1. What they do well
2. Where they fall short
3. Their pricing model
4. Their target audience
5. What we could do differently

Present as a comparison table followed by a summary of
the biggest opportunity gap for a new entrant.

Write release notes for version {{version}} of {{product}}.

Changes in this release:
{{list your changes — can be rough bullet points}}

Format:
- Start with a one-paragraph summary
- Group changes by category (Features, Improvements, Fixes)
- Use active voice and user-benefit language
- Include a "What's Next" section with upcoming plans
- Keep it under 500 words
- Tone: professional but friendly

Design an onboarding flow for {{product}}.

Our users: {{describe who signs up}}
Their goal: {{what they want to accomplish}}
Key "aha" moment: {{when they realize the value}}

Design a step-by-step onboarding that:
1. Gets them to the "aha" moment in under 2 minutes
2. Asks for minimal information upfront
3. Shows progressive disclosure of features
4. Includes helpful tooltips and examples
5. Has a clear success state

Output as a numbered flow with screen descriptions.