Prompt Library

I just joined a team and I'm reading this part of the codebase for the first time.
Here are the files from {{folder or module name}}:

{{paste files, each starting with its path}}

Explain it like a helpful teammate on my first day:

1. What this module is for, in two sentences.
2. A map: each file in one line, grouped by role.
3. How a typical request or job flows through it, step by step,
   naming the functions involved.
4. The three things most likely to confuse a newcomer.
5. Anything that looks fragile, surprising or "don't touch this",
   with your reasoning.

Only describe what's actually in the code. If something depends on files
I haven't shown you, say which ones you'd want to see next.

The question: {{contested question}}

I lean towards: {{your current view, or "undecided"}}

1. Write the strongest case FOR, as its most thoughtful supporter would
   make it. 150 words, no strawmen.
2. Write the strongest case AGAINST, the same way. 150 words.
3. List the key factual disagreements versus the key value disagreements.
   (Facts can be checked; values have to be argued.)
4. Name the single piece of evidence that would most change the debate,
   and whether it exists.
5. Point out where my current lean might be weakest.

Stay neutral in sections 1 and 2. Be candid in section 5.

Here are real things customers have said about {{product}}
(reviews, support emails, interview quotes):

"""
{{customer quotes}}
"""

Write landing-page copy that sounds like our customers, not like an ad.

1. Headline (max 10 words), built from a phrase customers actually used.
2. Subheading that names the problem in their words.
3. Three benefit blocks, each with a short title, two sentences and the
   customer quote that inspired it.
4. One honest line about who this is NOT for.
5. A call to action button label (max 4 words).

Avoid: "seamless", "powerful", "revolutionary", "all-in-one", exclamation marks.

I need to make a decision: {{decision}}.
Deadline: {{when}}. Who's affected: {{people or teams}}.

Here's my messy thinking so far:
{{brain dump}}

Write a one-page decision memo with these sections:
- The decision in one sentence
- Options (two to four), each with cost, upside, downside and reversibility
- What we know vs. what we're guessing
- Recommendation, with the main reason in one sentence
- What would make us change our minds
- Next step, owner and date

Write in plain language for someone who has two minutes. If my brain dump
is missing something essential to decide, list it at the top as "Open questions".

Here is a draft I wrote for {{audience}}:

"""
{{draft}}
"""

Cut it by roughly 30% without making it sound like someone else wrote it.

Rules:
- Keep every concrete detail, number and name unless it's repeated.
- Keep my sentence rhythm. If I use short punchy lines, keep them short.
- Remove throat-clearing, hedges ("I think", "kind of", "it's worth noting"),
  and any sentence that only restates the one before it.
- Do not add new words, metaphors or transitions of your own.

Return:
1. The trimmed version.
2. A list of the five biggest cuts, each with a one-line reason.
3. The word count before and after.

I want to refactor {{what}} because {{why: the pain it causes today}}.

Context:
- Codebase: {{language / framework}}
- Constraints: {{e.g. no downtime, can't change the public API, small team}}
- Current test coverage of this area: {{rough description}}

Don't write the refactored code. Write a plan:

1. The end state in three sentences.
2. A sequence of small steps, each one safe to merge on its own.
   For each step: what changes, how we'll know it worked, how to roll it back.
3. The tests we should add before step 1.
4. The riskiest step, and how to make it less risky.
5. What we should explicitly NOT change during this refactor.

Keep the plan to one screen. If a step feels too big, split it.

I want help writing clear rules for {{an email assistant / my email filters}}.

My job: {{role}}
People whose emails always matter: {{names, domains or roles}}
What wastes my time: {{e.g. newsletters, cold sales pitches, automated alerts}}
Things that must never be sent without me: {{e.g. anything to clients, money, dates}}

Write:
1. A short set of plain-language rules (maximum 12), grouped as
   archive / label / draft a reply / ask me first / never touch.
2. For each "draft a reply" rule, one example of the tone I want.
3. Three edge cases where these rules could go wrong, and how to handle them.
4. A one-line curfew rule for when the assistant should not send anything.

I want to learn the basics of {{skill}} in one week.
Why: {{goal, e.g. to follow conversations at work, to build a small project}}
Time available: {{minutes}} minutes a day, {{best time of day}}.
I learn best by: {{reading / doing / watching / talking it through}}.

Create a 7-day plan:
- Each day: one focus, one short activity, one tiny output I can show.
- Day 7: a small project that uses everything.
- Build in one review day for what didn't stick.
- Suggest the kind of free resource that would help each day
  (describe it; don't invent specific titles or links).

Keep it realistic for someone tired after work.

Here is the draft pricing for {{product}}, which {{one-line description}}:

"""
{{pricing tiers, limits and prices}}
"""

Our main customer is {{customer}} and our biggest cost per user is {{cost driver}}.

Read it three times, as three different people:
1. A first-time visitor who has 20 seconds. What do they think they're buying?
   What confuses them?
2. A power user trying to get maximum value for minimum money. How would
   they game this?
3. Our finance lead. Which customer could cost us more than they pay?

Then:
- Rewrite the tier names and one-line descriptions to be clearer.
- Suggest one change that protects our margins without punishing normal users.

Here's a bug report:

"""
{{bug report}}
"""

And here's the relevant code:

"""
{{code}}
"""

Do not fix the bug yet. Instead:

1. Restate the bug as: "When {{condition}}, the code does X but should do Y."
2. List what you'd need to know to reproduce it that isn't in the report.
3. Write the smallest failing test that demonstrates the bug, using
   {{test framework}}. Name it after the behaviour, not the ticket number.
4. Explain why the test fails with the current code, pointing to the line.

Only after I confirm the test is right will we discuss a fix.

We're launching {{feature or product}} for {{audience}}.
What it does: {{one sentence}}
Why it matters to them: {{the problem it solves}}
Proof: {{a number, quote or example}}
Call to action: {{what we want them to do}}

Write the launch email three times:
A) Plain and practical: like a helpful note from a colleague.
B) Story-led: open with a specific customer moment (use the proof above;
   don't invent people).
C) Playful: one light joke maximum, still clear by line two.

Each: subject line, preheader, body under 150 words, one button label.
Then tell me which tone fits the audience best and why.

I need ideas for {{what: campaign, name, event, post}} for {{audience}}.

Step 1: Give me ten deliberately terrible ideas. Make them bad in different ways:
too literal, too expensive, wrong decade, wrong audience, too boring,
too weird, technically illegal-sounding (but not actually harmful), and so on.
Label each with how it's bad.

Step 2: For each terrible idea, find the one interesting thing hiding in it.

Step 3: Turn the three most interesting hidden things into real, workable ideas,
each with a one-line pitch and a cheap way to test it this week.

A grid of six small rough composition thumbnails for an image of {{subject}}.

Each thumbnail tries a different composition:
1. extreme close-up  2. tiny subject in a huge space  3. strong diagonal
4. framed through a doorway or window  5. view from below  6. symmetrical, centred

Style: loose grey-scale marker sketches, three values only (light, mid, dark),
no detail, no colour, thin border around each thumbnail
Purpose: exploring layout and value, not finished art

I'm researching {{topic}} for {{purpose: essay, report, decision}}.
Here are my notes and sources so far:

"""
{{notes}}
"""

Act as a tough but fair reviewer. Tell me:

1. The three biggest gaps: questions my notes don't answer but should.
2. Claims resting on a single source.
3. Perspectives or stakeholders missing entirely.
4. Anything that looks outdated or that I should double-check.
5. Two specific kinds of sources that would strengthen this most
   (describe them; don't invent titles or authors).

Rank everything by how much it would hurt the final piece if left unfixed.