Use cold-email after identifying a potential customer and deciding why a first business message could be relevant. It focuses on the recipient, a genuine research signal, supported value, and one easy response. It does not itself find email addresses, run a sending campaign, or establish whether every prospect is suitable to contact.
Install and invoke
Run this in your project terminal to install only this skill for Claude Code:
npx skills add coreyhaines31/marketingskills --skill cold-email -a claude-code
Node.js and npx must be available. For Codex, replace -a claude-code with -a codex. In the agent conversation, explicitly ask it to use cold-email and supply your material. The installation command belongs in the terminal, not in your content brief.
Explain why this recipient
Start with one identifiable prospect. That is easier to review than an email intended for every company. Provide a real hiring signal, product change, or published discussion, including its source and date. Do not turn unverified research into a flattering opening. Reuse .agents/product-marketing.md for your own product background.
Example brief:
Use cold-email to draft an English B2B first message only.
The recipient manages studio delivery. Their public careers page shows remote-team expansion; see research.md.
We centralize client annotations. Approved evidence is in proof.md.
Ask whether a delivery checklist would help, rather than requesting a thirty-minute meeting.
Add two follow-ups, each with new value. Do not invent personal experience.
Check whether the opening observation naturally leads to the problem you discuss. If deleting that sentence leaves a message you could send unchanged to anyone, the personalization is probably decorative. Technical and executive recipients may care about different constraints; shortening one generic product description is not enough to address both.
Make every sentence support a reply
Observation, problem, proof, and ask can provide a useful shape, but do not force four rigid paragraphs. Keep the subject ordinary and concise. Do not fake an existing conversation with Re: or Fwd:. Make one low-friction request, such as permission to share something relevant, rather than combining a meeting, registration, and introduction.
With limited evidence, narrow the claim and ask a better question. Follow-ups should offer another useful resource, relevant case, or new observation. Repeated reminders add no reason to respond. Each message should remain understandable without the previous one, and a declared final touch should actually be final.
Read the drafts aloud and remove long introductions, feature lists, and template language. Verify personalized facts, permission to use evidence, and link destinations before making a separate sending decision. List quality, delivery configuration, and real replies are not solved merely by finishing the copy. Treat the sample as a draft to adapt, not a record of a successful customer conversation.
Move from a prospect sheet to a sendable draft
Separate five fields for each recipient: role, a recent verifiable change, the work problem that change might create, your relevant proof, and a reasonable next step. “I saw you on LinkedIn” is not meaningful personalization. A better brief is: “This company has posted an implementation-manager role. We have permission to cite this customer example. Ask whether handoffs during onboarding are a current priority; do not assume they are.” The skill can then distinguish an observation from your hypothesis.
Request a subject line, a short body, one low-friction ask, and a note showing the source of every personalized sentence. The subject only needs to signal the topic; it does not need to carry the pitch. Put the recipient’s situation before your product. If you lack an approved customer result, do not manufacture one to make the note seem stronger.
Review every draft before sending: company and person, role, timing, permission to use proof, and whether a second request has slipped into the email. Check that a reply has an obvious path. A follow-up should contribute a genuinely new angle or resource, rather than paraphrase “just checking in.” When you have nothing relevant to add, stop or wait for a real change.
Example: ask a relevant question about a new integration
Imagine a software company has announced an integration related to your product in a public changelog. You want to offer a troubleshooting checklist to the team responsible. Give the agent the changelog URL, the recipient’s known role, the checklist, and a clear statement about whether you actually have a customer case. Ask: “Use cold-email to draft a short note for review. Refer accurately to the announced integration without assuming they have a problem. Explain one specific check the resource helps with. End by asking only whether they want the checklist link. Show the source of each factual sentence below the draft.”
Read the result aloud. If replacing the company name makes it fit any prospect, the observation is not connected to their work. If an unsupported “customers saved 30%” claim appears, delete it. If the recipient’s responsibility is unknown, ask for a courteous team-level question rather than a fake account of their project. Confirm facts, sender identity, and applicable outreach requirements yourself before sending; the skill’s output is a draft.
Know what the draft actually proves
One user ran the Skill on a fictional vitamin C serum and got a three-email influencer outreach sequence. That demonstrates a drafting workflow, not sent mail or replies. For your own sequence, ask the agent to label each email’s purpose, evidence, and single action. Then verify that the recipient really discussed the relevant problem and that any case study is approved for use. Keep unsent examples as drafts; only real replies belong in performance records.