email-draft
The email-draft skill generates professional email compositions when users request drafting, replying to, polishing, or translating email messages. It produces a formatted output with subject line, personalized greeting, focused body paragraphs, explicit call to action, and appropriate sign-off, followed by a pre-send checklist covering specificity, clarity, tone, and security to catch common errors before sending.
git clone --depth 1 https://github.com/shiwenwen/hope-agent /tmp/email-draft && cp -r /tmp/email-draft/skills/email-draft ~/.claude/skills/email-draftSKILL.md
# Email Draft
## When to Use
Trigger phrases: "draft an email", "reply to this email", "polish this email", "翻译这封邮件", "write an email to <X>".
Don't trigger for: chat messages, Slack DMs, in-app notifications, marketing copy. Those are different formats.
## Output Format
Always produce the draft in this layout. Use a fenced code block so the user can copy it cleanly:
```
Subject: <concise, action-oriented, ≤60 chars>
Hi <Name>,
<opening line — context or thanks>
<body — one focused paragraph per point, max 3 paragraphs>
<call to action / next step / explicit ask>
Best,
<Sender>
```
If the language isn't English, adapt greeting and sign-off to the local convention:
- 中文: `<Name>，你好` / `祝好，<Sender>`
- 日本語: `<Name>様` / `よろしくお願いいたします。<Sender>`
- Français: `Bonjour <Name>,` / `Cordialement, <Sender>`
- 한국어: `<Name>님께` / `감사합니다, <Sender>`
## Workflow
1. **Clarify minimal essentials** via `ask_user_question` if missing:
- Recipient and rough relationship (peer / manager / external client / cold outreach)
- One-sentence purpose ("schedule a meeting" / "decline a vendor" / "ask for clarification")
- Tone (formal / collegial / brief)
- Preferred language
- Any constraints to mention (deadline, budget, link to attachment)
2. **Subject line first** — the subject is what gets read. Make it specific and action-oriented:
- Bad: "Quick question"
- Good: "Q3 budget approval — need sign-off by Friday"
- Bad: "Following up"
- Good: "Followup on June 12 design review action items"
3. **Body** — three paragraph max:
- **Paragraph 1**: context / why you're writing
- **Paragraph 2**: the specific request, decision, or information
- **Paragraph 3**: clear next step (what you want them to do, by when)
4. **Pre-Send Self-Check** — after producing the draft, run through this checklist out loud (in your reply to the user, before the draft):
- [ ] Subject is specific and action-oriented (not "Hi" / "Question")
- [ ] Recipient name is correct (no "Hi <Name>" placeholder left)
- [ ] Purpose stated in the first 2 sentences
- [ ] Concrete ask with deadline, not vague
- [ ] No internal jargon if recipient is external
- [ ] Tone matches relationship (formal vs collegial)
- [ ] No accidental "Reply All" implications (if forwarding, mention)
- [ ] No PII / secrets that shouldn't be in email
- [ ] Attachments mentioned in body if any
- [ ] Sign-off matches the user's actual name
If any box fails, revise the draft before showing it.
## Common Patterns
### Cold outreach (asking for time)
```
Subject: 15 min on <topic>?
Hi <Name>,
I'm <role> at <company>. We're working on <one-sentence context>, and I noticed your work on <specific thing>.
Would you have 15 minutes in the next two weeks for a quick call? I'm happy to share <X> in return / send a written question if that's easier.
Either way, thanks for considering.
Best,
<Sender>
```
### Decline (politely)
```
Subject: Re: <original subject>
Hi <Name>,
Thanks for thinking of me / sending this.
I've decided to pass for now because <one-sentence reason>. Specifically, <constraint>.
Happy to revisit if <condition>.
Best,
<Sender>
```
### Status escalation (to manager)
```
Subject: <Project> blocked on <decision>
Hi <Name>,
Quick heads-up: <project> is blocked on <specific decision> as of <when>.
Context: <2 sentences max — what's happening and what's at stake>.
I'd recommend <option>. Can you confirm by <date>, or shall we discuss live? Open to your input.
Thanks,
<Sender>
```
### Reply with action items
```
Subject: Re: <original subject>
Hi <Name>,
Thanks for the call/email. To make sure we're aligned:
- <decision 1>
- <decision 2>
Action items on my side:
1. <action> — by <date>
2. <action> — by <date>
Action items on your side:
1. <action> — by <date>
Let me know if I missed anything.
Best,
<Sender>
```
## Style Rules
- **Front-load the ask** — most readers skim. The first sentence after greeting should set context; the second should hint at the action.
- **Don't apologize unless needed** — drop "Sorry to bother you" / "I hope this isn't a stupid question". Just ask.
- **One ask per email** — multiple requests dilute response rate. Split into separate emails or use a numbered list.
- **No "per my last email"** — replace with "to recap" or restate the question.
- **Keep paragraphs short** — 2-4 lines max. Wall-of-text emails get archived unread.
- **Active voice** — "I'll send the draft Monday" beats "the draft will be sent Monday".
## Translation Mode
When the user asks to translate an email:
1. Preserve the structure (subject / greeting / body / sign-off)
2. Adapt greeting and sign-off to target language conventions (see top of skill)
3. Note any culturally-tricky phrasings — flag with a `[note]` comment outside the draft
4. If the source has tonal markers (formal Japanese keigo, polite Korean, etc.), preserve register
## Common Pitfalls
| Mistake | Fix |
|---|---|
| Generic subject ("Hi", "Followup") | Specific subject naming the topic + action |
| Burying the ask in paragraph 4 | Move to paragraph 1 or 2 |
| "Hope you're well" filler when familiar | Skip — go straight to topic |
| Vague deadline ("when you can") | Specific date or "no rush, just FYI" |
| Mixing 3 unrelated asks | Split into 3 emails |
| Auto-translation kept English greeting | Localize properly (`你好`, `안녕하세요`) |>
Use when the user mentions 飞书 / Feishu / Lark workspace operations: docx (云文档) read/write, bitable (多维表格) records / views / dashboards, drive (云盘) upload/download, wiki (知识库) link resolution, approval (审批) instance create/cancel/query, calendar (日历) event create/list/update + attendees, contact (联系人) user/department lookup, hire (招聘) job/talent/application listing. Trigger on phrases like 'OKR 周报', '把这份文档发到飞书云盘', '给团队拉个评审会议', '查 [姓名] 的联系方式', '撤销那条审批', '/wiki 链接', or any request that mentions a feishu / lark URL / token (doxcn.../bascn.../wikcn.../boxcn.../om_...).
Hope Agent browser automation — the standard `status → tabs → snapshot → act` loop, stale-ref recovery rules, and what to do when login / 2FA / captcha / camera-prompt / dialog blocks progress. Load this skill whenever you reach for the `browser` tool. Trigger on: user asks the agent to open / control / click / scrape / log into / verify something in a web app ('open X and click Y', '打开 X 然后点击 Y', 'log into my Gmail', 'scrape this page', 'fill out the form on X'); user reports a flow that requires real browser context (cookies, JS-rendered content, OAuth).
Discover and install third-party skills from external registries when the user needs a capability that no currently-active skill covers. Trigger when: (1) the user explicitly asks 'find a skill for X', 'is there a skill that does X', 'install a skill to X', (2) the user requests a well-known integration (Slack, Notion, Trello, GitHub, Hue, Sonos, iMessage, weather, TTS, transcription …) that isn't in the active skill catalog, (3) you are about to hand-write ad-hoc shell / API code for a domain that almost certainly has a published skill. Do NOT trigger if an active skill already covers the need — scan the visible skill catalog first.
Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / async jobs) directly via the `exec` tool to investigate problems, analyze usage, and locate root causes. Trigger on: user reports something broken / failing / slow / stuck / not responding ('X 不工作', 'X 报错', 'X 卡住', '为什么 X 失败', 'why did X fail', 'show me the logs', 'check what happened'); ad-hoc data analysis ('this week's token usage', '最近调用最多的工具', 'how many subagent runs failed', 'tool error rate', 'find sessions where X happened'); verifying a fix ('did the error stop after I changed Y'). Use BEFORE asking the user to paste log snippets — the data is on disk, query it directly. Read-only — SELECT only, never UPDATE/DELETE/INSERT/DROP.
Hope Agent native macOS desktop control — the standard `mac_control` status / diagnostics / apps / dock / spaces / snapshot / visual / windows / menu / clipboard / dialog loop, target-first action rules, no-blind-coordinate policy, and recovery for stale AX/window/menu/dialog state. Load whenever using `mac_control`, or when the user asks to control local Mac apps, Dock, Spaces, click/type/menu/window/dialog/clipboard, automate Finder/TextEdit/System Settings, visually locate UI, or says 控制 Mac, macOS 自动化, 点按钮, 打开应用, Dock, Space, 关闭窗口, 菜单点击, 视觉定位.
Self-understanding and issue reporting for Hope Agent itself. Use when the user asks how Hope Agent works internally, asks about its own source code/docs/runtime behavior, reports a bug/failure/slowness/crash, asks to diagnose logs, or asks to create/submit a GitHub issue for a bug, feature request, or improvement (including when there is no bug). Chinese triggers: 自查, 了解自己, 自我诊断, 排查 Hope Agent, 提交 issue, 需求 issue, 功能改进.
Check for and install Hope Agent updates through conversation. Use whenever the user asks about upgrades, new versions, release notes, or reports a bug that might already be fixed upstream — phrases like 'upgrade Hope Agent', 'update hope agent', 'check for new version', '升级一下', '有新版本吗', '帮我升级', 'is there a newer build', 'check release notes', 'install the latest'. Also use proactively when an `app_update(action=\"check\")` result shows `has_update: true` and the user hasn't been told yet. Covers all three formfactors: desktop GUI bundle (DMG/MSI/AppImage), `hope-agent server` daemon installed via Homebrew/Scoop/AUR/apt/dnf, and headless single-binary deployments. The upgrade is always user-confirmed via `ask_user_question` — never silent.