Agent Skills
› fanfan-de/anybox
› outlook-email-reply-drafting
outlook-email-reply-drafting
GitHub用于安全起草Outlook邮件回复。通过读取上下文理解最新请求，默认生成纯文本草稿。支持判断是否回复所有人，严禁捏造事实或承诺HTML格式，确保内容准确且符合商务礼仪。
Trigger Scenarios
用户希望回复邮件线程
决定是否需要回复所有人
将最新Outlook消息转化为得体回复
Install
npx skills add fanfan-de/anybox --skill outlook-email-reply-drafting -g -y
SKILL.md
Frontmatter
{
"name": "outlook-email-reply-drafting",
"description": "Draft Outlook email replies safely from connected mailbox context. Use when the user wants to reply to a thread, decide whether to reply-all, prepare a draft before sending, or turn the latest Outlook message into a polished response."
}
Outlook Email Reply Drafting
Overview
Use this skill when the reply itself is the task. Read enough mailbox context to understand the latest ask, then default to a draft unless the user clearly asked you to send.
Outlook reply writes are plain-text only. If the user asks for HTML formatting, styled sections, or layout-specific markup, say briefly that Outlook reply actions here only support plain text, then convert the request into a clean plain-text reply instead of planning an HTML body.
Relevant Actions
- Use
search_messagesorlist_messagesto find the right thread when the user names a topic rather than a concrete message. - Use
fetch_messageorfetch_messages_batchwhen the latest snippet is not enough to understand tone, commitments, or the actual ask. - Use
create_reply_draftfor reply and reply-all drafts tied to an existing message. - Use
reply_to_emailonly when the user explicitly asked to send and the content is fully grounded. - Use
draft_emailonly for net-new messages or when the task is not a direct reply to an existing message.
Workflow
- Identify the exact source message or thread before drafting.
- Read the most recent message first, then enough nearby context to understand participants, status, commitments, and tone.
- Decide whether reply-all is necessary based on shared context, not just recipient count.
- Draft the reply in the thread's tone unless the user asks for a deliberate change, but keep the draft plain text.
- If the draft depends on missing facts, produce the best draft you can and list the unresolved details separately.
- If the user later approves sending, reuse the thread-grounded draft instead of recreating the reply from scratch.
Safety
- Preserve dates, commitments, names, links, and quoted facts unless the user asks to change them.
- Do not invent availability, approvals, ownership, or promises that are not already established in mailbox context.
- Treat reply-all as a deliberate choice. If the audience is ambiguous, explain the safest default.
- If the user says "send" but the content still depends on unstated choices, stop and ask the narrowest necessary confirmation question.
- Do not promise HTML email formatting or markup-specific rendering. Express structure with plain-text paragraphs, lists, and raw links, and tell the user when that means a requested formatting detail cannot be preserved exactly.
Output
- Provide a ready-to-send plain-text draft with greeting, body, and closing when appropriate.
- If important assumptions remain, list them immediately after the draft.
- If you are recommending a reply-all decision, say why in one short line.
Version History
- 08dc189 Current 2026-07-05 19:04
