Twenty reusable prompts. Each one is a proven pattern for a common task.
How prompts are organized here
Each prompt is its own file: NN-slug.md. The file contains:
1. Purpose — one sentence
2. When to use — trigger conditions
3. The prompt — copy-paste-ready
4. Variables — what to fill in
5. Model recommendation — which model handles this best
6. Example — one filled-in example
The 20 starters
#
Prompt
Category
01
Email reply drafter
Communication
02
Meeting summarizer
Communication
03
Decision memo
Communication
04
Slack message polisher
Communication
05
Executive update writer
Communication
06
Research brief generator
Research
07
Competitive teardown
Research
08
Article-to-notes extractor
Research
09
Fact-checker with citations
Research
10
Code reviewer
Engineering
11
Bug diagnostician
Engineering
12
Doc-from-code writer
Engineering
13
Test case generator
Engineering
14
SQL query builder
Engineering
15
Prompt improver
Meta
16
System prompt drafter
Meta
17
Copy rewriter (voice-preserving)
Writing
18
Structured document extractor
Writing
19
Weekly review generator
Personal ops
20
Decision journal entry
Personal ops
Extending the library
Every time you write a prompt more than twice, save it. Format:
- Copy _TEMPLATE.md
- Fill in the six sections
- Commit to your prompts repo
How to install the library
Once written, upload the entire folder as knowledge to:
- Your primary Custom GPT
- Your primary Claude Project
- Your primary Perplexity Space
Then any conversation can reference the library by name: "Use the meeting-summarizer prompt."
Purpose: Draft a reply to an email in my voice, matching the tone and length of the incoming message.
When to use: You've received an email and need a response drafted before you hit reply.
Category: Communication
Model recommendation: Claude Sonnet — best at matching voice and tone from examples.
The prompt
Draft a reply to the email below.
Incoming email:
---
{EMAIL_BODY}
---
Context you should know: {CONTEXT}
Constraints:
- Match the length of the incoming email (±25%).
- Match the formality level of the sender.
- Do not open with "Thanks for your email" or "I appreciate you reaching out".
- End with a concrete next step, not "Let me know your thoughts".
- If a decision is needed from me before replying, list the missing info as bullets after the draft.
Return the draft in a code block, then a two-line note on what tone I picked and why.
Variables
{EMAIL_BODY} — the full incoming email
{CONTEXT} — anything the model needs to know (relationship, prior thread, deadline)
Example use case
Client asked: 'Can you push our lease signing to next Friday?'
Expected output shape
Draft reply → two-line note explaining tone choice.
Purpose: Turn a meeting transcript or notes into a summary with decisions, action items, and open questions.
When to use: You have a transcript, Otter recording, or messy meeting notes to convert into a shareable summary.
Category: Communication
Model recommendation: Claude Opus or GPT-5 — best at extracting structure from long transcripts.
The prompt
Summarize the meeting below.
Transcript / notes:
---
{TRANSCRIPT}
---
Return exactly four sections, in this order:
## Decisions
- Bullet list of decisions made. If none, write "No decisions made."
## Action items
- Owner — action — due date (if mentioned). One per line.
## Open questions
- Questions raised but not resolved. Bullet list.
## Summary
Three sentences covering: what was discussed, what was decided, what happens next.
Rules:
- Do not include a "Next steps" section — those go in Action items.
- Do not include attendee list unless I ask.
- Preserve owner names exactly as spoken.
Purpose: Produce a short decision memo with the recommendation up front, then supporting logic.
When to use: You need to write up a decision for a stakeholder — a peer, boss, or client.
Category: Communication
Model recommendation: Claude Sonnet — cleanest at inverted-pyramid structure.
The prompt
Write a decision memo on the following.
Context:
{CONTEXT}
Options I'm considering:
{OPTIONS}
Constraints and criteria:
{CRITERIA}
Format:
## Recommendation
One sentence, plainly stated. No hedging.
## Why
Three bullets, each 1–2 sentences.
## Alternatives considered
For each alternative, one sentence on why it lost.
## Risks
Two or three specific risks with a one-line mitigation each.
## Next step
One sentence naming the concrete next action and its owner.
Length target: 250–400 words total.
Variables
{CONTEXT}, {OPTIONS}, {CRITERIA}
Example use case
Should we self-host the AI video pipeline or use Modal?
Purpose: Rewrite a rough Slack draft into a clean, punchy message.
When to use: You've typed a Slack message but it feels too long, too formal, or too passive.
Category: Communication
Model recommendation: Any model — this is fast and cheap. Use Groq or Haiku.
The prompt
Polish this Slack message. Preserve the meaning exactly.
Draft:
---
{DRAFT}
---
Rules:
- Cut greeting fluff.
- Move the ask to sentence 1 if there is one.
- Kill hedging ("just", "maybe we could", "if that's ok").
- Cap at 3 sentences unless there's a real reason.
- Match the channel tone: {CHANNEL_TONE}
Return only the polished message. No commentary.
Purpose: Convert your week's work into a 5-line update for an executive.
When to use: Weekly, when your boss or a stakeholder asks 'what's the status?'
Category: Communication
Model recommendation: GPT-5 — best at compression.
The prompt
Turn my week's work into an executive update.
My work this week:
{RAW_LOG}
Format:
**This week:** one sentence naming the biggest win or milestone.
**Shipped:** bullet list of things that went live. Max 5 items. If more, group them.
**In progress:** bullet list of active work. Max 3. Include % complete.
**Blockers:** bullet list. If none, write "None."
**Next week:** one sentence naming the top priority.
Rules:
- Total length under 150 words.
- No filler adjectives ("great progress", "exciting update").
- Numbers where possible.
Purpose: Produce a research brief on a topic — background, key facts, sources, open questions.
When to use: You need a fast primer on an unfamiliar topic before a meeting or decision.
Category: Research
Model recommendation: Perplexity Sonar Pro — search-grounded. Or Perplexity Computer with research subagent for depth.
The prompt
Produce a research brief on: {TOPIC}
Purpose I need it for: {PURPOSE}
Depth: {DEPTH — quick / standard / deep}
Format:
## TL;DR
Three sentences, direct.
## Key facts
5–10 bulleted facts, each cited inline with the source name as anchor text.
## Timeline (if relevant)
Bulleted dates, most recent first.
## Players
Table: Entity | Role | Why they matter | Source.
## Open questions
Things that couldn't be answered from public sources. Bulleted.
## Sources
Numbered list of primary sources with URLs.
Rules:
- Every claim gets a citation.
- Flag stale sources (>18 months old) with (dated).
- No speculation unless labeled "Analysis:".
Variables
{TOPIC}, {PURPOSE}, {DEPTH}
Example use case
GEO/AEO optimization landscape for a website audit.
Purpose: Analyze a competitor's product, positioning, and go-to-market.
When to use: Before a positioning meeting, a pitch, or a product decision.
Category: Research
Model recommendation: Perplexity Deep Research or Computer's research subagent.
The prompt
Do a competitive teardown of: {COMPANY}
My product / positioning: {MY_POSITIONING}
Focus areas: {FOCUS — product / pricing / GTM / all}
Format:
## Snapshot
One paragraph: what they do, who they serve, their size and stage.
## Product
- Core features (bulleted)
- Notable strengths (2–3)
- Notable gaps (2–3)
## Pricing and packaging
Table of tiers, prices, and included features. Note anything unusual.
## Positioning
- Their claimed differentiation (their words)
- Their actual differentiation (your read)
## GTM motion
Sales-led, product-led, community-led, or hybrid. How they acquire.
## Where we win / lose
Two columns. Be specific — no "we have better support".
## Threats to us
Ranked 1–3.
Sources cited inline with anchor-text names.
Variables
{COMPANY}, {MY_POSITIONING}, {FOCUS}
Example use case
Teardown of a competing property management platform.
Purpose: Extract the useful signal from an article into structured notes you can review later.
When to use: When you read a long article and want to keep only what matters.
Category: Research
Model recommendation: Claude Sonnet with the article pasted or URL fed.
The prompt
Extract structured notes from the article below.
Article:
---
{ARTICLE_OR_URL}
---
Format:
## What it's about
One sentence.
## The claim
The article's core argument in 2–3 bullets.
## Evidence they offer
Bulleted, with the strongest evidence first.
## What's new or non-obvious
2–3 bullets. Skip if the piece is a rehash.
## Quotes worth keeping
Up to 3 direct quotes with page/paragraph reference.
## My open questions
2–3 bullets — things the article raises but doesn't answer.
## Related to
Any of my active projects this connects to.
Purpose: Verify each factual claim in a document against public sources.
When to use: Before publishing anything with numbers, dates, or attributed statements.
Category: Research
Model recommendation: Perplexity — search-grounded, best for verification.
The prompt
Fact-check the document below. For every factual claim, verify against public sources.
Document:
---
{DOCUMENT}
---
Format:
For each claim, produce a row:
| # | Claim (as written) | Verdict | Correct fact (if different) | Source |
|---|---|---|---|---|
Verdicts:
- ✅ Correct
- ⚠️ Correct but misleading (explain why)
- ❌ Incorrect
- ❓ Unverifiable in public sources
At the end, a summary section:
## Summary
- Total claims checked: N
- Correct: N
- Misleading: N
- Incorrect: N
- Unverifiable: N
## Recommendations
Bulleted fixes, most critical first.
Purpose: Review code like a senior engineer — correctness, security, readability, and idiomatic style.
When to use: Before opening a PR, or when reviewing a teammate's PR.
Category: Engineering
Model recommendation: Claude Opus or GPT-5. For long files, Claude's larger context wins.
The prompt
Review the code below like a senior engineer.
Language / framework: {LANG_FRAMEWORK}
Change purpose: {PURPOSE}
Files to review:
---
{CODE}
---
Format:
## Summary
One sentence: overall verdict — ship, ship with nits, needs work, or block.
## Blocking issues
Numbered list. Each with: file:line, what's wrong, why it matters, suggested fix (code block).
## Non-blocking suggestions
Numbered list. Same format.
## Nits (optional)
Style-only observations.
## What's good
2–3 things done well. This is not filler — call out real strengths.
Rules:
- Cite file:line references exactly.
- Flag security issues with 🔒.
- Flag performance issues with ⚡.
- Do not rewrite the whole file — suggest diffs.
Purpose: Read source code and produce clean developer documentation.
When to use: When someone asks 'how does X work' and there are no docs.
Category: Engineering
Model recommendation: Claude Sonnet — long context handles multi-file reads.
The prompt
Read the code and produce documentation.
Codebase / module:
---
{CODE}
---
Audience: {AUDIENCE — new hire / external dev / self in 6 months}
Format:
## What this module does
One paragraph.
## Public API
Table: Function/class | Signature | Purpose | Example call
## Key concepts
Bulleted definitions of the 3–5 domain terms that matter here.
## How it fits into the system
One paragraph.
## Gotchas
Non-obvious behavior, edge cases, foot-guns. Bulleted.
## Example: end-to-end usage
One realistic example in a code block, fully runnable.
Rules:
- Do not document private methods.
- Preserve existing naming exactly.
- No filler like "This module is a great way to...".
Purpose: Generate a comprehensive test plan for a function or feature.
When to use: Before writing tests, or when reviewing test coverage.
Category: Engineering
Model recommendation: Claude Sonnet — deliberate about edge cases.
The prompt
Generate a test plan for:
Feature / function:
{CODE_OR_DESCRIPTION}
Test framework: {FRAMEWORK}
Format:
## Happy path
Numbered test cases. Each: name, input, expected output.
## Edge cases
Numbered. Include: empty inputs, boundary values, unicode, timezone edges, large payloads, concurrent calls.
## Error cases
Numbered. Include: invalid inputs, downstream failures, timeouts, auth failures.
## Not tested (by design)
Bulleted — things you're deliberately not covering, with one-line reasoning.
## Runnable stubs
Code block with `{FRAMEWORK}` test scaffolds for every case above, empty bodies with descriptive names.
Rules:
- Aim for property-based tests where useful.
- Flag flaky-test-prone cases with ⚠️.
Purpose: Rewrite a prompt to be more effective — clearer, more constrained, better output structure.
When to use: When a prompt you're using isn't producing what you want.
Category: Meta
Model recommendation: Claude Opus — best at prompt engineering reasoning.
The prompt
Improve this prompt.
Original prompt:
---
{PROMPT}
---
What the current output does wrong: {PROBLEM}
What I want it to do instead: {DESIRED}
Format:
## Diagnosis
2–3 bullets: what's causing the poor output.
## Improved prompt
[the rewritten prompt, fully drop-in ready]
## What changed
Bulleted — the specific edits and why each helps.
## Test cases
3 inputs I should run against the new prompt to verify it works.
Rules:
- Preserve the original intent.
- Prefer specificity over cleverness.
- Add explicit output format instructions.
- Add explicit "do not" rules where drift is likely.
Variables
{PROMPT}, {PROBLEM}, {DESIRED}
Example use case
Your current summarizer that keeps adding fluff.
Expected output shape
Diagnosis → improved prompt → change log → test cases.
Purpose: Draft a system prompt for a new Custom GPT / Project / agent.
When to use: When you're building a new assistant for a specific role or domain.
Category: Meta
Model recommendation: Claude Opus.
The prompt
Draft a system prompt for a new AI assistant.
Purpose: {PURPOSE}
Audience: {WHO_USES_IT}
Domain: {DOMAIN}
Voice: {VOICE — inherit mine or specific}
Key knowledge it should have: {KNOWLEDGE}
Behaviors that matter most: {BEHAVIORS}
Things it must never do: {NEVERS}
Format:
## System prompt
[the drafted system prompt, 400–800 words]
## Design notes
Bulleted — key choices you made and why.
## Test prompts
5 prompts to run against the assistant to validate its behavior.
## Suggested knowledge files to attach
Bulleted list of documents to upload as reference.
Rules:
- Structure: Identity → Behavior → Format → Voice → Constraints → Meta.
- No filler ("You are a helpful assistant" is banned).
- Include specific "do not" rules where drift is most likely.
Purpose: Rewrite marketing or product copy while preserving the author's voice.
When to use: Editing your own copy, or rewriting AI-generated copy that missed your voice.
Category: Writing
Model recommendation: Claude Sonnet with your style guide attached.
The prompt
Rewrite the copy below.
Original:
---
{COPY}
---
Voice reference (my writing samples):
---
{VOICE_SAMPLES}
---
Constraints:
- Preserve the meaning exactly.
- Match the voice reference above — sentence length, vocabulary, rhythm, energy.
- Cut AI tells: "delve", "in the ever-evolving", "it's important to note", "certainly".
- Cut hedging: "may help", "can potentially", "one of the".
- Preserve any specific claims, numbers, and CTAs.
Format:
## Rewrite
The rewritten copy, no commentary.
## Changes I made
Bulleted — what I cut, tightened, or reworded, and why.
## Alt headlines (if applicable)
3 alternate headlines/opens I considered.
Purpose: Pull specific fields from an unstructured document into a JSON or table format.
When to use: When you have a lease, contract, invoice, or spec and need specific fields extracted.
Category: Writing
Model recommendation: GPT-5 with JSON mode, or Claude with structured output.
The prompt
Extract structured data from the document below.
Document:
---
{DOCUMENT}
---
Fields to extract:
{FIELD_LIST — e.g., parties, effective_date, term_length, monthly_rent, security_deposit}
Output format: {JSON | Markdown table | CSV}
Rules:
- For each field, return: value, source_snippet (the exact text where you found it), confidence (high/medium/low).
- If a field isn't present, return null and explain why.
- Do not infer values that aren't stated.
- Normalize dates to ISO 8601.
- Normalize amounts to decimal numbers with currency code.
Format:
```json
{
"extracted": {
"field_1": {"value": ..., "source": "...", "confidence": "high"}
},
"missing_fields": ["field_5", "field_9"],
"notes": "any observations about the document quality"
}
Purpose: Turn a week's calendar, notes, and Slack activity into a personal weekly review.
When to use: Every Friday, to close the week.
Category: Personal ops
Model recommendation: Perplexity Computer or Claude Projects — needs to read multiple sources.
The prompt
Generate my weekly review.
Inputs (paste or link):
- Calendar this week: {CALENDAR}
- Slack messages I sent: {SLACK_ACTIVITY}
- Notes taken: {NOTES}
- Commits / PRs / tickets closed: {WORK_ARTIFACTS}
- Goals I set last Friday: {LAST_WEEK_GOALS}
Format:
## What went well
3 bullets, specific. Not "made progress" — say what shipped.
## What didn't
2–3 bullets, honest. Include one lesson per item.
## Wins to celebrate
Bulleted. Include size-appropriate ones — small wins count.
## Goal progress
Table: Last week's goal | Status | Notes
## People to follow up with
Bulleted — name, one-line context, target day.
## Next week's top 3
Ranked, with a one-sentence rationale for each.
## One thing to say no to
Bulleted — commitments I should decline or drop.
Rules:
- Be honest about misses. No "opportunities to improve" — say what didn't happen.
- Under 500 words.
Purpose: Log a decision with the reasoning at the moment you make it, for later review.
When to use: Every time you make a decision that's larger than trivial but smaller than a memo.
Category: Personal ops
Model recommendation: Any model — this is short.
The prompt
Log this decision in my decision journal.
Decision: {DECISION}
Context: {CONTEXT}
Options considered: {OPTIONS}
Chosen option: {CHOICE}
Reasoning: {REASONING}
Emotional state (0-10, honest): {EMOTIONAL_STATE}
Confidence (0-100%): {CONFIDENCE}
When to review: {REVIEW_DATE}
Format:
## Decision
Restated in one sentence.
## Reasoning at the time
2–3 bullets summarizing why I made this choice.
## What I expect to happen
The concrete outcome I'm betting on.
## What would tell me I was wrong
Specific signals — metrics, events, feedback — that would falsify this decision.
## Review checklist
- Date to revisit: {REVIEW_DATE}
- What to look at first when reviewing
Rules:
- Do not add analysis I didn't provide.
- Preserve my exact wording where possible.
- Keep under 200 words.