Cold Email Writer
Published by osspakistan in agent-skills
What this skill does
Write, rewrite, and critique cold outreach emails that get replies. Covers investor/fundraising outreach, customer and sales prospecting, partnership asks, recruiting, press and advisor intros, and follow-ups. Use this skill whenever the user asks for a cold email, cold DM, outreach message, investor email, intro request, "email to a stranger", follow-up to an ignored email, or wants a draft reviewed or tightened, even if they never say "cold email". Also use it when they paste a draft and ask w
Add Cold Email Writer to your agent
Review the source and files first. When you are ready, copy the prompt instruction or use the CLI command supported by your environment.
Install with a prompt
Paste this into a compatible coding agent:
add this skill "cold-email-writer" from https://github.com/osspakistan/agent-skillsInstall with the CLI
Run this command in a controlled environment after reviewing the repository:
npx skills add https://github.com/osspakistan/agent-skills --skill cold-email-writerSkill instructions
Cold Email Writer
Write cold emails a busy stranger will actually answer. Distilled from Y Combinator's cold-email advice, OpenVC's critique of the "custom hook" template, a 5-rule founder slide, Alex Hormozi's offer and sales advice, and the terse style of ~200 documented Musk emails.
Core idea: a cold email earns a reply with proof and clarity, not flattery or fake personalization. AI and mail-merge made the "Heard you on the podcast, congrats on X, since you're big on Y..." hook free, so recipients now read it as a template.
Workflow
- Gather inputs. Need: sender (founder or SDR/agent?), recipient, what you do, best proof, the ask. If something is missing, draft anyway with
[placeholders]and list what to fill in. Ask at most one question, only if the draft can't be written sensibly without it. 1b. Check the offer (sales, services, agency outreach). If there is no concrete offer (outcome, mechanism, timeline), fix that first. Readreferences/offer-and-sales.md. - Decide on personalization. Read
references/personalization.md. Default is no hook. Include one only if it passes the "could this be pasted onto another recipient?" test. - Draft using the structure below. Read
references/principles.mdfor the full rule set andreferences/examples.mdto calibrate length and tone. - Run the self-check below and fix failures silently.
- Deliver in the output format.
If the user pastes a draft, keep their facts, diagnose in 3-5 bullets (what reads as template, what's buried, what's unverifiable), then give the rewrite.
Structure (3-5 sentences, under 60 seconds to read)
- What you do, plain words, zero jargon. Say what the product does, not the category.
- Best proof, one or two checkable facts: paid pilots, revenue, growth, launch, named customers, a technical team with relevant credentials. Put the strongest first.
- Why it matters to them (only if real and specific). Their pain in their words, or one genuine reason it's them. For sales, lead with the outcome and name the pain accurately (see
references/offer-and-sales.md). - The ask, explicit and on its own line right before the sign-off. Ask for something small: a reply, advice, an intro, permission to send a short demo or deck. Not a 30-minute meeting from a stranger.
- Sign off with name and role. Short, casual subject line (what + proof, e.g. "Automated bank QA, 2 paid pilots").
Self-check before delivering
- Under ~100 words? Readable aloud in under a minute?
- First sentence says what the company does, with no warm-up?
- Zero flattery, zero backstory, zero origin story?
- Every claim checkable? No "proven 10x ROI" or "$18B market" without a source or definition.
- Any hook passes the swap test, or is removed?
- One goal, one ask, on its own line, smaller than a meeting?
- Sounds like a person talking, not an AE or a pitch deck? ("Cheers", "I'd love to pick your brain", "game-changing" = cut.)
- Subject line short and casual?
- (Sales) Is there a real offer: outcome, mechanism, timeline? Scarcity or guarantee only if true?
Output format
- The email (subject + body) in a block.
- Under it, 2-4 lines: what's placeholder, what claim needs a source, and one optional variant (e.g. shorter, or with a real hook) only if useful.
- Add the follow-up (see
references/followups-and-delivery.md) only if asked or if the user is sending a sequence.
Keep commentary tight. Don't lecture about the rules unless asked.
Sender matters
Founder-sent emails get away with more brevity because the sender is the proof. An SDR, agent, or AI sender has to earn the reply from the email alone: stronger proof, clearer fit, borrowed credibility (customer names, YC, past employers). Ask or infer who is sending and adjust.
Tone
Default: plain, direct, founder-voice. If the user wants it blunter or more "Musk-style", read references/musk-tone.md. This is style only. Never present output as a real Musk email, and note that his emails are mostly warm or internal, so brevity there leaned on existing credibility.
Reference files
references/principles.md: the consolidated rule set and where sources agree or conflictreferences/personalization.md: when and how to personalize, the swap testreferences/examples.md: before/after rewrites (investor, sales) and a bad-vs-good checklistreferences/offer-and-sales.md: Hormozi offer rules mapped onto email copy, value equation, sales-process rules, how they reconcile with YC/OpenVCreferences/musk-tone.md: terse-style moves and their limits for cold usereferences/followups-and-delivery.md: follow-up cadence, ignored emails, SPF/DKIM/DMARC check
Files included
- README.md
- references/examples.md
- references/followups-and-delivery.md
- references/musk-tone.md
- references/offer-and-sales.md
- references/personalization.md
- references/principles.md
- SKILL.md

