Prompt Search Find a prompt for [YOUR TASK]

Turn the meeting notes below into a record the team can act on.

<notes>
[PASTE NOTES OR TRANSCRIPT]
</notes>

Produce, in this order:
1. Decisions — each decision that was made, one line each. If something was discussed but not decided, it does not belong here.
2. Action items — a table with the columns: Action | Owner | Due | Source quote. Use only owners and dates that appear in the notes. Where either is missing, write "unassigned" or "no date" instead of guessing.
3. Open questions — what was left unresolved, and who needs to answer it.
4. A follow-up message of 120 words or fewer that I can send to attendees. Plain text, no greeting fluff.

Rules:
- Do not invent facts, names or deadlines. The "Source quote" column is a short verbatim phrase (under 15 words) showing where the action came from.
- If two people seem to own the same action, list it once and flag the ambiguity under Open questions.
- Leave out small talk and status updates that led to no decision or action.

Review the code change below the way a careful senior engineer would before approving a pull request.

<context>
What this change is meant to do: [WHAT THE CHANGE SHOULD DO]
Language and framework: [LANGUAGE AND FRAMEWORK]
</context>

<diff>
[PASTE DIFF OR CODE]
</diff>

Work in this order:
1. Restate in two sentences what the change actually does. If that differs from the stated intent, say so first.
2. Look for defects in priority order: incorrect behaviour and unhandled edge cases; security issues (injection, authorisation, secrets, unsafe deserialisation); data-loss or concurrency risks; performance problems that matter at realistic scale; missing or misleading tests.
3. Report findings as a list sorted by severity. For each one give: severity (blocker / should-fix / nit), location (file and line, or function), what goes wrong with a concrete input or scenario that triggers it, and the smallest fix as code.

Rules:
- Report only problems you can point to in the code shown. If a concern depends on code you cannot see, put it under "Needs checking" as a question, not as a finding.
- No style nits unless they hide a bug. No praise padding.
- If you find no blockers, say so plainly and name the single riskiest part I should test by hand.

editorial product photograph of [PRODUCT] on [SURFACE], [BACKGROUND COLOUR OR SETTING], soft window light from the left with a gentle shadow falling to the right, shallow depth of field, 85mm lens look, subtle reflections, generous empty space at the top of the frame for a headline, clean commercial styling --ar 4:5 --raw --s 50

Write a cold outreach email for the situation below.

Sender: [YOUR NAME, ROLE, COMPANY]
What we sell, in one sentence: [OFFER]
Recipient: [RECIPIENT NAME, ROLE, COMPANY]
What I know about them (recent news, a post they wrote, their tech stack, a hiring signal): [RESEARCH NOTES]
Proof I can cite truthfully (a customer result, a number, a name): [PROOF POINT]
The ask: [ASK, E.G. A 15-MINUTE CALL]

Requirements:
- 70 to 110 words in the body. Plain text. No bullet points, bold or emoji.
- Open with a specific observation about the recipient taken from my research notes — not a compliment, and not "I hope this finds you well".
- Connect that observation to one problem we solve. One problem only.
- Use the proof point exactly as given. Do not add numbers, customers or claims that I have not supplied.
- End with one low-friction question that can be answered in a single line.
- Write the way a thoughtful peer would, not a marketer: short sentences, and none of "synergy", "leverage", "revolutionise" or "I wanted to reach out".

Deliver:
1. Three subject lines, each under six words, lower case, no clickbait.
2. The email.
3. A 40-word follow-up to send four days later that adds one new piece of value instead of "just bumping this".

If my research notes are too thin to write a specific opening line, do not fake one — tell me what to look up instead.

Explore this repository and write an AGENTS.md file that will help a coding agent work here safely and quickly. (If this project uses Claude Code, write the same content to CLAUDE.md.)

Before writing, investigate — do not guess:
- Read the README, the package and build manifests, the CI configuration and any contributor docs.
- Find the real commands for install, build, run, test (the whole suite and a single test), lint and format. Run the cheap ones to confirm they work.
- Identify the top-level layout: where the main code, tests, generated files and configuration live.
- Look for conventions that are not obvious from a single file: naming, error handling, how modules talk to each other, migration or release steps.

Then write the file with these sections and nothing else:
1. Project in one paragraph — what it is and who uses it.
2. Commands — a copy-pasteable list. Mark any command you could not verify with "(unverified)".
3. Layout — the directories that matter, one line each.
4. Conventions — only the rules a newcomer would get wrong. Give each rule a one-line reason.
5. Boundaries — files and directories that must not be edited (generated code, vendored code, secrets, migrations already applied) and actions that need a human's go-ahead.
6. Definition of done — what must pass before a change counts as finished.

Constraints:
- Under 120 lines. Every line should change an agent's behaviour; cut anything it would work out on its own.
- State facts you verified. No aspirational rules and no generic advice such as "write clean code".
- Do not modify any other file. When finished, show me the file and list anything you were unsure about.

Extra context from me: [ANYTHING THE AGENT SHOULD KNOW, OR "NONE"]

Slow dolly-in, eye-level medium close-up with shallow depth of field. [PRODUCT, WITH COLOUR AND MATERIAL] stands on [SURFACE] in [SETTING]. [ONE SIMPLE ACTION, E.G. A HAND SETS THE CUP DOWN AND STEAM RISES FROM IT]. Early-morning light rakes in from a window on the right, giving warm highlights and soft shadows, with dust motes drifting in the beam. The background stays softly out of focus in muted, natural colours. Clean, premium commercial look with realistic textures and a steady camera. One continuous shot that holds on the product for the final two seconds. Ambient noise: [QUIET ROOM TONE FOR THE SETTING]. SFX: [ONE SOUND THAT MATCHES THE ACTION]. No dialogue, no subtitles, no on-screen text.

I want to actually understand [TOPIC], not just read an explanation. Act as my tutor for this session.

About me: [YOUR LEVEL AND WHAT YOU ALREADY KNOW]
Why I'm learning it: [GOAL, E.G. EXAM ON FRIDAY, NEW JOB, CURIOSITY]

How to run the session:
- Start by asking me two or three short questions to find out what I already know. Wait for my answers before teaching anything.
- Teach one idea at a time, in plain language, with a concrete example tied to my goal. Keep each turn under 150 words.
- After each idea, ask me one question that makes me use it, not repeat it. Wait for my answer.
- When I'm wrong, don't hand me the answer. Point to the step where my reasoning went off and ask a smaller question. Give the answer only if I'm still stuck after two attempts, or if I ask for it.
- When I'm right, say so in a sentence and raise the difficulty.
- Every four or five exchanges, give a three-line recap of what I've shown I understand and what is still shaky.

If I type "just tell me", give a direct explanation and then go back to questions. If I type "test me", give five mixed questions on everything so far, mark my answers, and tell me what to review.

I've attached a dataset. Act as a careful analyst doing a first pass. Use your code tool to inspect the whole file; do not estimate from a preview.

What the data is: [WHAT EACH ROW REPRESENTS AND WHERE IT CAME FROM]
The decision I'm trying to make: [QUESTION OR DECISION]

Step 1 — Audit before analysing. Report: row and column counts; each column's type, share of missing values and number of distinct values; duplicates; impossible or suspicious values (negative quantities, future dates, implausible outliers); and any sign that the file is truncated or mis-parsed. Tell me what you would fix and how, then apply only the fixes that are safe, and say which you applied.

Step 2 — Answer the question. Choose the simplest analysis that addresses my decision. Show the numbers in a small table, plus one chart only if it makes the point clearer than the table does.

Step 3 — Tell me how far to trust it. For each finding, state the sample size behind it, whether the difference could plausibly be noise, and the most likely confounder. Separate what the data shows from what you are inferring.

Finish with: three findings in plain English that a non-analyst could repeat, the one thing you would check next, and any question you need me to answer to go further.

Rules: never fabricate values. If a column's meaning is unclear, ask me; do not assume. Show code only if I ask for it.