Prompt cookbook

You are an expert in assertive business communication and negotiation. Write a polite but absolutely firm reply to the email below. I want to turn this request down, but I must not make an enemy of this person (I want to keep a professional relationship).

Rules for the reply:
1. Decline confidently, without apologising. Leave out phrases like “Unfortunately”, “I'm terribly sorry” or “I really regret”, they weaken your decision.
2. Start by appreciating their work or thanking them for the offer.
3. Decline clearly and briefly in one sentence (e.g. “Because of my workload I need to focus fully on X right now…”).
4. Offer a small alternative (a so-called “soft no”), e.g. pointing them to someone else, a link to a resource, or asking them to get back in touch in six months.

The reason I'm declining (internal, just for you): [I don't have time / They don't have the budget for me / It's not my priority]

Original email:
[Paste the original email]

You are a B2B copywriter who writes cold emails for small and medium-sized businesses. Write a cold email to a potential client.
I offer: [WHAT YOU SELL]
Client: [CEOs of online shops / HR managers in manufacturing / Restaurant owners]
A real result I can back up: [E.G. “we saved a client 12 hours a week”, or leave empty]

Avoid old sales templates. Stick to this method:
1. **Subject:** 3–4 words. It should sound like an email from a colleague, not a newsletter, so no words like discount, offer or partnership.
2. **Opener (hook):** Start straight with an observation about their business or market, not an introduction (“My name is XY and we do…”).
3. **Pain point:** Name one specific problem that probably annoys them and costs money.
4. **Value:** Say in one sentence how we solve it. Only use the number I wrote above. If there isn't one, write the value without a number and don't make one up.
5. **Soft CTA (call to action):** Don't push for a 30-minute call straight away. Ask whether it's a topic for them right now, or offer a short resource (a PDF or a video).

Write 2 different versions. Each 5 sentences at most, so it can be read on a phone in a few seconds.

Act as a Senior Copywriter and Editor with 10 years of experience. Shorten and improve the following text by ~40% for maximum readability and punch.

Rules:
1. Cut the fluff, filler words and empty claims (so-called corporate BS).
2. Rewrite the passive voice into the active voice.
3. Use short sentences (max 20 words) and paragraphs (max 3–4 lines).
4. Replace marketing clichés (“world-unique”, “best on the market”, “innovative solution”) with specific information from the text.
5. Keep the original meaning and tone.

Split the output into two parts:
- [IMPROVED VERSION] the text itself
- [WHAT I CHANGED AND WHY] 3 short points explaining the main edits.

Text to edit:
[PASTE THE TEXT HERE]

You are a Senior Content Strategist. Your task is to design an outline for a high-quality, in-depth blog article (a so-called pillar page). I don't want shallow, generic texts.

Article topic: [PASTE THE TOPIC]
Target audience: [B2B professionals / Complete beginners / Everyday consumers]
Target length: [about 1,500 words]
Tone: [Expert and pragmatic / Relaxed and funny / Empathetic]

Suggest 3 completely different concepts (angles) for the article (e.g. 1. A step-by-step guide, 2. A case study/story, 3. Busting myths).

For EACH of these 3 concepts, generate:
1. A working title (catchy, click-worthy, but not clickbait).
2. A hook: the first sentence or paragraph that pulls the reader in.
3. A complete outline (H2 and H3 headings). For each heading, write 1 sentence explaining what value the reader gets there.
4. A recommended Call To Action (CTA) for the end.

This code doesn't work or throws an error. You are an experienced developer used to hunting bugs systematically. Go through the code and find the cause.

Method:
1. Before you write a fix, explain in 3 sentences what the code does now.
2. Find the difference between what it should do and what it does. Name the specific lines.
3. When the bug may come from external input (an API, a database) or you're missing important context (logs, the error message), don't guess. Ask me like a colleague what you need to find out before you suggest a change.
4. Suggest a fix and briefly explain why it's more robust.
5. When you can run the code (for example in Cursor), reproduce the bug first and after the fix check that it's gone.

Code to analyse:
[PASTE THE CODE HERE]

Expected behaviour (what it should do):
[DESCRIBE WHAT YOU EXPECT]

Current behaviour (what it does, the error message):
[ERROR / BEHAVIOUR]

Explain this piece of code to me line by line. You are a patient Senior Mentor and I'm your Junior Developer. I want to understand it deeply, not just on the surface.

Rules for your explanation:
1. Go through the code step by step and break down the logical blocks. For each block, write at most 3 sentences in plain language.
2. Where it fits, use a real-world analogy (the so-called Feynman technique) so I take in the concept better.
3. Point out any edge cases or weak spots (security, performance) that could cause problems in production.
4. Finally, suggest one small homework task for trying out or improving how this code works myself, so I learn it.

Code to explain:
[PASTE THE CODE]

Refactor this code or function so that the way the rest of the project uses it doesn't change. You are a developer who cares about clean, readable code (Clean Code).

Refactoring rules:
1. **Keep the public API:** Function names, arguments and the return type stay the same, so the surrounding modules don't break.
2. **Same behaviour:** The same inputs give the same outputs. When you find a bug the code already has, tell me about it, but don't fix it without my approval. A fix would change the behaviour.
3. **One function, one job:** Split a giant function into smaller helper functions (Single Responsibility).
4. **Name the magic numbers and strings:** Replace them with constants with a clear name.
5. **Simplify the logic:** Replace deep nesting (`if` inside `if`) with early returns (guard clauses). Merge repeated logic.
6. **Tests:** When the code has tests and you can run them, run them before and after the refactor.

At the end, list the main changes and for each one write in one sentence why the code is now more readable or easier to maintain.

Code to refactor:
[PASTE THE CODE]

You are a copywriter who writes LinkedIn posts for people in [YOUR FIELD] and knows how to tell stories. Write 3 different posts on the topic: [TOPIC / WHAT I WANT TO SHARE].

My real story or experience: [2–3 SENTENCES ABOUT WHAT HAPPENED]
Stick only to what I write here. Don't add numbers, names or events I didn't write.

Each post:
1. **Hook:** Start with a strong claim, a counter-opinion, a number from my story or the beginning of the story (12 words at most). Leave out phrases like “I'm thrilled to share” or “Today I want to tell you”. Reason: people scroll and the first sentence has to stop them so they click “See more”.
2. **Structure:** A blank line between paragraphs. Bullet points yes, 2–3 emoji per post at most.
3. **Value:** Instead of generic phrases, one specific thing I took away from it, or a practical tip.
4. **Ending (CTA):** One open question for the discussion, so people comment.
5. **Hashtags:** 3 at most, right at the very end of the post.

Versions:
*   Version 1: A personal story from the experience above (what it gave me).
*   Version 2: A practical how-to in points.
*   Version 3: A contrarian opinion that sparks a debate.

Tone (pick one, or a different one for each version): [Assertive expert / Humble learner who shares / Humorous startup founder]

Find what people have been writing on X over the last 7 days about [TOPIC]. Summarise the 3 main opinions and give links to posts for each.

Then suggest 3 posts for X (each under 280 characters) that bring my view into the debate: [MY OPINION]. Write in your own words, don't copy other people's wording. For each suggestion, say which of the opinions it responds to.

Write a product description for an online shop.

Product: [name and 2 sentences about what it does]
Target audience: [who buys it and why]
Key benefits: [3–5 points]
Technical specs: [specs from the manufacturer, or leave empty]
Tone: [salesy / expert / playful]

Output:
1. A title (60 characters at most)
2. A short teaser (2 sentences, for the product listing)
3. The main description (150–200 words)
4. Bullet points “Why you'll want it” (5 points)
5. Technical specs only from my list above. If it's empty, leave this part out. Don't fill anything in by guessing.

Explain [topic] to me with the Feynman method:

1. A simple definition (1 sentence, as if for a 12-year-old)
2. An analogy from everyday life
3. Key terms (max 5) with a short definition
4. A common misconception people have
5. The takeaway (1 sentence)

Language: plain English, no needless jargon. When you need a technical term, add a short explanation.

Put together a 30-day plan for learning: [topic/skill]

About me:
- level: [beginner / intermediate]
- time: [how many minutes a day]
- goal: [what I should be able to do after 30 days]
- I prefer: [video / text / interactive]

Output as a table:
| Day | Topic | Activity (specific) | Time | How I'll check I can do it |

At the end: 3 projects I can do to really “nail it”.

In the table [Sales_2026], find the 3 months with the biggest drop in sales compared with the previous month.
For each, write by what percentage sales dropped and what those months have in common ([product, region]).
Give the result as a new table on a separate sheet with one column chart.
Don't change anything in the original data.

Summarise this document for [the management team, who have 2 minutes to read it].
Put 3 main conclusions at the top, each in one sentence. Below them, the risks and what we need them to decide.
Stick only to what's in the document. Where something is missing, write “not in the document”.
Half a page at most.

Write a reply to this email. I want to [move the deadline by a week because we're waiting for material from a supplier].
Tone: [matter-of-fact and friendly], polite and formal.
5 sentences at most. At the end, one clear question that can be answered yes or no.
Don't make up facts that aren't in the email.

You are my work partner. Rules:

## Language
- Answer in English, keep it informal. My name: [name].

## Style
- Brief and straight to the point, no apologies or opening phrases (“certainly”, “happy to help”…).
- Put code in code blocks, with a short comment on “why”.
- Be specific and use plain words, no marketing phrases.

## Facts
- When you're not sure, say so. Don't make anything up.
- Give a source for facts and separate what you know for sure from what you're estimating.

## Process
- Complex task: first a short plan (3–5 points), then ask whether to continue.
- When you're missing information, ask before you start writing.
- When you can't do something, say so honestly and suggest what's possible instead.

Before you start solving, ask me about the 3–5 most important things you need to know. Each question on its own line, numbered. Wait for my answers, and only then suggest a solution.

If the task is completely trivial (1–2 lines of code, a translation, simple advice), skip the questions and answer straight away.