agentleFS
xiongxianfeixiongxianfei/skillsmith/skills/email-writer/SKILL.md

email-writer

Skill2 starsChanged 12 days agoMITView on GitHub

Write, draft, reply to, shorten, or polish workplace emails using a clear structure (subject, greeting, summary, details, closing action, sign-off, signature) and a goal-based writing strategy (request, follow-up, decline, bad news, complaint, thanks, FYI). Use this skill whenever the user asks to write or draft an email, reply to an email, improve or shorten an email, get email writing tips, or asks about email format, font, tone, or what parts an email should have, even if they don't say "skill". Signature details are left as blanks because many different people use this skill.

7 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Add one line of strategy: after the draft, then one line offering an adjustment (shorter, more formal, translated).

    line 17
  2. Distinctive:

    If the user pastes an existing email, keep their facts and intent.

    line 19
  3. Distinctive:

    When reviewing a user's own draft, name the one or two changes that matter most, not every edit.

    line 45
  4. Distinctive:

    Details: only what the reader needs to decide or act.

    line 54
  5. Distinctive:

    If no action is needed, say so: "No reply needed.

    line 59
  6. Distinctive:

    Signature: leave as blanks for the user to fill in:

    line 61
  7. Very specific:

    Never invent a name, title, company, phone, or email.

    line 69
  8. Distinctive:

    When asked, or when it helps:

    line 73
  9. Distinctive:

    If the user's company has a style guide or standard signature, that comes first.

    line 78

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Email Writer

Help the user write emails that are short, specific, and easy to act on.

Workflow

  1. Collect the essentials. Use the supplied recipient, main point or request, and any deadline. For missing facts, use clear placeholders or ask one short question when the answer is needed to draft accurately. Never invent names, dates, amounts, commitments or deadlines. Omit a deadline if none is needed.
  2. Identify the goal and pick a strategy (see Writing strategy below). Do this silently.
  3. Choose the tone. Formal (clients, executives, first contact, external parties) or casual (teammates, regular contacts). If unclear, default to polite-neutral.
  4. Draft using the structure below. Output the email ready to copy.
  5. Run the pre-send checklist silently. Fix problems before showing the draft.
  6. Add one line of strategy after the draft, then one line offering an adjustment (shorter, more formal, translated). If the user requests only the email or no commentary, omit both lines and any other explanation.

If the user pastes an existing email, keep their facts and intent. Restructure and tighten it, and say briefly what changed.

Writing strategy

Pick the approach by the email's goal. Apply it silently inside the draft.

These strategies organize supplied facts; they do not authorize inventing deadlines, reasons, fixes, impacts, alternatives or commitments. Use a placeholder or a focused question for essential unknowns, and omit optional unknown details. Mention attachments as included only when confirmed.

GoalStrategy
RequestLead with the ask and any supplied deadline. Make it easy to say yes: state the exact decision and identify supporting material needed.
Follow-upReference the supplied earlier message. Restate the ask in one line. Use an agreed deadline or a simple next step. Stay polite, never blaming.
DeclineSay no clearly in the first lines. Give a short reason. Offer an alternative if one exists.
Bad news or delayState it plainly first. Then give the known impact, confirmed fix and revised date if available. No excuses or long apologies.
Complaint or issueFacts first, then the desired outcome and any supplied deadline. Keep emotion out.
Thanks or praiseBe specific about what they did and the result. Keep it short.
FYI or updateLead with the key change. Say "no reply needed" only when no response or action is expected.

Unless the user requests email only or no commentary, add one line explaining one key choice after the draft, for example: "I put the supplied deadline in the subject so it's seen first." Do not lecture or list every choice.

Offer two variants only for high-stakes or sensitive emails (disagreement, refusal, a late project, a complaint to a senior person). Label each with a short goal and say what it trades off, for example "Direct: fastest to resolve, but firmer" vs "Softer: protects the relationship, but slower." For routine emails give one draft.

Honor a request for one draft or email-only output with one copyable email. When offering variants, describe tone differences as potential trade-offs, not guaranteed effects on the recipient.

Add a short "Why this works" note (2-3 bullets max) only when the user asks for tips or feedback. Otherwise skip it.

When reviewing a user's own draft, name the one or two changes that matter most, not every edit.

Structure

  1. Subject: 5-10 words, topic plus action, with the deadline if there is one. Example: Please approve: Q4 equipment budget (by Friday)
  2. Greeting: Dear Anna, for formal or first contact; Hi Anna, for colleagues. If the name is unknown, use Dear [Name/Team], or a supplied role; use Dear Hiring Manager, only for a hiring context.
  3. Summary: 1-2 sentences. Why I'm writing and what I need. Conclusion first, no background. Test: if the reader stops here, can they act? Openers: "Please approve...", "I'm writing to ask...", "Following up on...", "Please find attached...", "I'd like to confirm..."
  4. Details: only what the reader needs to decide or act. Bullets for 3 or more points, most important first, short lines. Skip this part if the summary covers everything.
  5. Closing line (the action): state who does what, and by when if a deadline was supplied. Use [deadline] if one is necessary but unknown. Then one polite line.
    • Vague: "Let me know your thoughts."
    • Clear: "Could you confirm by Friday, 5 pm?"
    • With several people: "Anna, please approve. Tom, please prepare the purchase order."
    • If no action is needed, say so: "No reply needed; just for your information."
  6. Sign-off: formal Kind regards, / Best regards,; casual Thanks, / Best,. Never use "Kindly" alone as a sign-off.
  7. Signature: leave as blanks for the user to fill in:
[Full name]
[Title | Company]
[Phone | Email]

Never invent a name, title, company, phone, or email. Casual short emails may use just [Your name].

Format and font guidance

When asked, or when it helps:

  • Font: one standard font (Calibri, Arial, or Helvetica), 11-12 pt, black or dark gray.
  • Left-aligned, short paragraphs (2-4 lines), blank line between them.
  • Bold only for a key item such as the deadline or main ask. Avoid color, underline, all caps, large images, and heavy templates.
  • HTML (rich text) is fine for most work email. Use plain text for very formal or technical messages, or when the recipient's client is unknown.
  • If the user's company has a style guide or standard signature, that comes first.

Pre-send checklist

  • Can the reader understand the point from the subject and first two lines alone?
  • Is any deadline supplied by the user or clearly marked as a placeholder, and omitted when unnecessary?
  • Is it clear who must do what?
  • Claim an attachment is included only when the user confirms it or available tools verify it. Otherwise use [attach file before sending]; when commentary is allowed, also flag the reminder outside the email. Do not assert that a file is attached.
  • Are names spelled consistently? Is the length as short as it can be?

Templates

Full template

Subject: [Topic]: [action needed] (by [date])

Dear [Name],

[Summary: why I'm writing and what I need, in 1-2 sentences.]

[Details: only what they need to decide or act.]
- [Point 1]
- [Point 2]
- [Point 3]

[Who] + [what action] + [by when]. [One polite line.]

[Sign-off],
[Full name]
[Title | Company]
[Phone | Email]

Worked example

Fictional example: assume the sender supplied the facts and confirmed that the quote is attached.

Subject: Please approve: Q4 equipment budget (by Friday)

Dear Anna,

Please approve the $50,000 equipment budget by Friday so we can order before prices rise on Monday.

- Total: $50,000 (5% above Q3)
- Reason: replacing two worn machines on Line 2
- Supplier's current price is valid until Sunday
- Quote attached

Anna, could you confirm approval by Friday, 5 pm? Tom will then place the order on Monday morning. Happy to discuss if helpful.

Kind regards,
[Full name]
[Title | Company]
[Phone | Email]

Short version (quick requests)

Subject: Quick question: meeting time on Thursday

Hi Tom,

Could we move Thursday's meeting from 2 pm to 3 pm? I have a client call that runs late.

Please let me know by tomorrow noon. Thanks!

Best,
[Your name]

Language

Write the email in the language the user asks for, or the language of the email they pasted. If neither specifies a language, use the language of their request. Keep the same structure in any language, adjusting greetings and sign-offs to local business convention. Provide translations only when requested; keep strategy commentary within the limits above.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.