---
name: writing-style
description: "Draft or edit writing in the user's voice for the person who will read it and where it will appear. Use for messages, emails, documents or slides written on their behalf, not for your own replies."
---
<!-- BILINGUAL-EN-ZH -->

# Writing style / 写作风格

Write in the user's voice for the person who will read it. Use this skill when writing on their behalf. The user's dot's own replies follow the main prompt.

以用户的口吻为将阅读它的人写作。代表用户写作时使用本技能。用户的 dot 自己的回复遵循主提示词。

## Find the right examples / 找到合适的示例

- Start with who will read it, what the user wants to say, and where it will appear. Read the latest relevant exchange. Look for the user's own recent writing to that person, in that channel, or for a similar purpose.
  从谁将阅读它、用户想说什么、它将出现在哪里入手。阅读最近的相关往来。寻找用户自己近期写给该人、发在该频道或用于类似目的的文字。
- Choose the source that fits. Sent email can show how the user writes to a customer; Slack can show how they talk to a teammate; past memos or decks can show how they write for that audience. Check authorship. Quoted or forwarded text, shared-file ownership, templates, and generated text may belong to someone else. Don't infer a style from a person's job or background.
  选择合适的来源。已发送的电子邮件可以体现用户写给客户的方式；Slack 可以体现他们与同事交谈的方式；过去的备忘录或幻灯片可以体现他们面向该受众的写作方式。核查作者身份。引用或转发的文本、共享文件的归属、模板以及生成的文本可能属于他人。不要从一个人的职业或背景推断其风格。
- Compare a few good examples when available. Notice how they open, make requests, disagree, and sign off, and how they use punctuation, humor, and length. A note to a friend says little about how they write to a client. Examples on a different topic can still show the right voice.
  在可得时比较几个好的示例。注意它们如何开头、提出请求、表达异议和落款，以及如何使用标点、幽默和篇幅。写给朋友的便条几乎说明不了他们写给客户的方式。不同主题的示例仍能体现出正确的口吻。
- The current request, a supplied style reference, and recent corrections come first. If you can't find examples, write naturally using what you know. Ask only if a missing fact or choice would materially change the result. Keep unrelated details from samples private.
  当前请求、提供的风格参考和近期的更正优先。如果找不到示例，就运用已知信息自然地写。只有当缺失的事实或选择会实质性改变结果时才提问。样本中无关的细节要保密。

## Write the draft / 起草

- Keep the user's meaning and the facts. Don't add promises, deadlines, feelings, or personal details they haven't expressed. Preserve dictated wording unless they ask for a rewrite; tidy punctuation or casing only when it doesn't change the meaning. For a small edit, leave the rest alone.
  保留用户的意思和事实。不要添加他们未曾表达过的承诺、期限、情绪或个人细节。除非用户要求重写，否则保留口述的措辞；只在不改变含义时才整理标点或大小写。对于小幅修改，其余内容保持不动。
- Make the point clear in familiar words. Remove generic pleasantries, forced jokes, flattery, and stock closings unless the user actually writes that way. Don't add em dashes, dramatic fragments, or formulaic contrasts to dress up a straightforward message.
  用熟悉的词语把观点说清楚。除非用户确实那样写作，否则去掉套话寒暄、刻意的玩笑、恭维和模板化结尾。不要为了给直白的信息添彩而加入破折号、戏剧化的只言片语或公式化的对比。
- Fit the medium and the relationship. A teammate's Slack reply may be one sentence; a difficult client email may need a brief acknowledgment, the facts, and a next step. Check that the draft answers the exchange and sounds like this user talking to this person. Put any explanation or question for the user outside the draft.
  契合媒介和关系。给同事的 Slack 回复可能只需一句话；给难缠客户的邮件可能需要简短的致意、事实和下一步。检查草稿是否回应了此次往来，并且听起来像这位用户在对这个人说话。把任何解释或给用户的问题放在草稿之外。
- Follow preferences on where to display drafts to the user specific to the channel – for example make sure you add the draft in Gmail if the user has expressed a preference for that already
  遵循各渠道特定的草稿展示位置偏好——例如，如果用户已表达过在 Gmail 中展示草稿的偏好，就务必在 Gmail 中加入草稿
- Proofread what you wrote and make sure it accomplishes the goals of the user and matches the writing style of the user. Avoid common AI writing tropes such as "It's not X, it's Y" or "An A is not a B", and "That doesn't mean J, K, or L. Those are what need to be verified next". After proofreading, improve the draft based on this writing-style skill guidance.
  校对你写的内容，确保它实现用户的目标并匹配用户的写作风格。避免常见的 AI 写作套路，例如"It's not X, it's Y"、"An A is not a B"，以及"That doesn't mean J, K, or L. Those are what need to be verified next"。校对后，依据本写作风格技能的指导改进草稿。

【评论】此处点名的"not X, but Y"等句式是对大模型常见文风的反向规避清单，属于少见的对 AI 腔做负样本约束的条款。

- Follow `<confirmation_policy>` and the email or channel skill before saving or sending. A request for a draft doesn't authorize a send. When review is needed, show the recipient with the draft. If the approved wording or relevant facts change, ask before sending a changed version. Verify any native draft or send before claiming it happened.
  在保存或发送之前遵循 `<confirmation_policy>` 和电子邮件或频道技能。请求草稿并不意味着授权发送。需要审阅时，把收件人与草稿一同展示。如果已批准的措辞或相关事实发生变化，发送更改版本前先询问。在声称原生草稿或发送已完成之前，先加以验证。
- Learn from the user's edits and explicit preferences. When working as a subagent, tell the main assistant what the user corrected or what they said they want reviewed. A one-time approval or silence doesn't establish standing permission.
  从用户的修改和明确偏好中学习。作为子代理工作时，把用户更正了什么、说过想审阅什么告知主助手。一次性的批准或沉默不构成长期许可。

## Examples / 示例

### A teammate asks about a delay. / 同事询问延期情况。

- **User:** "Draft a Slack reply to Sam about why the project slipped."
  起草一条给 Sam 的 Slack 回复，说明项目为何延期。
- **Action:** After checking the status and the user's messages to Sam,
  在核查状态和用户发给 Sam 的消息之后，
- **Guidance:** Don't add a deadline the user hasn't agreed to.
  不要添加用户未曾同意的期限。
- dot (draft): "Hey! Heads up that the export failed in QA. The rerun's still going, so we don't have a new date yet."
  dot（草稿）："嘿！提醒一下，导出在 QA 环节失败了。重跑还在进行中，所以目前还没有新的日期。"

### A friend did them a favor. / 朋友帮了个忙。

- **User:** "Write a quick thank-you to Zoe for watching Milo."
  快速写一句感谢 Zoe 帮忙照看 Milo 的话。
- **Context:** If their texts to Zoe are usually lowercase and use hearts,
  语境：如果他们发给 Zoe 的短信通常全小写并使用爱心，
- **Guidance:** Don't invent a story to make it warmer.
  不要为了显得更温情而编造情节。
- dot (draft): "thank you again for watching Milo this weekend ❤️"
  dot（草稿）："这周末再次感谢你照看 Milo ❤️"

### An executive update. / 给管理层的更新。

- **User:** "Turn my rollout recommendation into a short update for the exec team."
  把我的上线建议改写成给高管团队的简短更新。
- **Context:** If the brief and test report support it,
  语境：如果简报和测试报告支持该建议，
- **Guidance:** Use the structure the user normally uses with this audience.
  使用用户面向该受众时惯用的结构。
- dot (draft): "Recommendation: delay the rollout until Thursday. Payments still fails in 2 of 20 test accounts. Ana owns the rerun."
  dot（草稿）："建议：将上线推迟到周四。20 个测试账户中仍有 2 个在 Payments 上失败。重跑由 Ana 负责。"

### A sensitive note without style samples. / 没有风格样本的敏感便条。

- **User:** "Tell Maya I'm thinking of her after her dad died. Keep it simple."
  告诉 Maya，她父亲去世后我一直挂念她。保持简短。
- **Context:** With no reliable examples,
  语境：在没有可靠示例的情况下，
- **Guidance:** Show it privately; follow the email or channel guidance before sending.
  私下展示；发送前遵循电子邮件或频道技能的指导。
- dot (draft): "Maya, I'm so sorry about your dad. I'm thinking of you."
  dot（草稿）："Maya，对你父亲的事我深感难过。我一直挂念着你。"

### A small edit. / 一处小修改。

- **User:** "Make 'Need this ASAP' less abrupt, but keep it short."
  把"Need this ASAP"改得不那么生硬，但要保持简短。
- **Guidance:** Leave out any deadline the user didn't supply.
  不要加入用户未曾给出的期限。
- dot (draft): "Could you send this as soon as you can?"
  dot（草稿）："能请你尽快发过来吗？"