Back to Details

written-communication

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Written Communication

书面沟通

Before Starting

开始之前

Check for EM context first. If 
.agents/em-context.md
exists, read it. If a person is mentioned, check 
.agents/reports/[name].md
.
If 
.agents/em-context.md
does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and 
.agents/reports/[name].md
does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update 
.agents/em-context.md
or 
.agents/reports/[name].md
automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先确认工程经理（EM）的相关背景信息。如果存在
.agents/em-context.md
文件，请阅读该文件。如果提及了特定人员，请查看
.agents/reports/[name].md
文件。
如果
.agents/em-context.md
文件不存在，请先询问并保存一份基础的经理信息档案，再给出详细建议：职位头衔、团队规模、团队使命或负责领域，以及当前面临的挑战或优先事项。
如果对话核心涉及特定人员且
.agents/reports/[name].md
文件不存在，请先询问并保存该人员的基础信息档案，再给出详细建议：职位头衔/级别、任职年限、优势，以及当前面临的挑战或成长方向。

如果后续对话中出现可长期留存的新背景信息，请自动更新
.agents/em-context.md
或
.agents/reports/[name].md
文件。仅保存稳定的事实和规律，不要记录猜测内容、暂时的情绪或未明确的解读。

Response Style

响应风格

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
  • State the likely diagnosis or recommendation first
  • Ask at most 2-3 targeted questions only if the missing context changes the advice
  • Give the next concrete action and, when useful, exact wording the manager can use
  • Mention the relevant framework briefly, but do not explain every part of it
  • Offer a deeper version only after the direct answer
首次回答需简洁实用。除非用户要求深入讲解，否则不要直接抛出完整框架。
默认遵循以下原则：
  • 先说明可能的诊断结论或建议
  • 仅当缺失的背景信息会影响建议内容时，最多提出2-3个针对性问题
  • 给出具体的下一步行动，必要时提供经理可直接使用的精准措辞
  • 简要提及相关框架，但无需解释每个细节
  • 在直接回答之后，再提供深入版本的选项

How to Use This Skill

技能使用场景

  • Need to write or draft a message → The 3-Step Framework
  • High-stakes announcement or sensitive policy change → When Stakes Are High
  • Writing for different audiences (engineers vs. stakeholders vs. leadership) → The 3-Step Framework → Step 1: Prepare
  • Someone is calling out missed messages in Slack ("as I already said…") → The Async Re-Explanation Trap
  • Message wasn't understood the way you intended → The Compression/Decompression Model
  • 需要撰写或草拟消息 → 三步写作框架
  • 高风险公告或敏感政策变更 → 高风险场景处理方案
  • 面向不同受众写作（工程师/利益相关者/领导层） → 三步写作框架→第一步：准备
  • 有人在Slack中指出消息被遗漏（“正如我之前所说…”） → 异步重复解释陷阱
  • 消息未按预期被理解 → 压缩/解压模型

Default Response Shape

默认响应结构

When helping with written communication, draft the actual message:
  1. Intent: what the message must accomplish.
  2. Audience calibration: what this audience knows, fears, and needs.
  3. Draft: concise, direct, and ready to send.
  4. Why it works: short notes on structure or wording.
  5. Risk check: what could be misread and how to reduce it.
If the user asks for wording, put the draft before the explanation.
在协助进行书面沟通时，需草拟实际消息内容：
  1. 意图： 消息必须达成的目标。
  2. 受众校准： 该受众已知的信息、担忧点和需求。
  3. 草稿： 简洁、直接、可直接发送的内容。
  4. 有效性说明： 关于结构或措辞的简短说明。
  5. 风险检查： 可能被误读的点及降低风险的方法。
如果用户要求提供措辞，需将草稿放在解释内容之前。

The 3-Step Framework

三步写作框架

Writing code for machines is predictable — you know the language, version, and libraries. Writing for people isn't: the same message lands completely differently depending on who reads it. This framework reduces that gap.
为机器编写代码是可预测的——你清楚使用的语言、版本和库。但面向人的写作并非如此：同一消息在不同读者眼中的接收效果可能截然不同。本框架旨在缩小这一差距。

Step 1: Prepare

第一步：准备

Before writing a single word, answer three questions:
Why are you writing? What triggered this message? Make sure the reason is in the message if it matters. Also: if you're writing while frustrated, stop. The goal of most messages isn't to win an argument — it's to get a result. Understanding your own intent often causes you to completely rewrite the message.
What do you want to achieve? Be specific. "I want my team to follow the new deployment rule" is a goal. "I want to communicate about deployments" is not. If you can't state the goal, the message won't have one.
Who is your audience? Different groups need different vocabulary and depth:
  • Engineers — technical detail appropriate, assume domain context
  • Business stakeholders — explain what matters to them, avoid jargon
  • Support team — they want all scenarios and edge cases
  • Fellow managers — share most context, be concise
The more you know about your audience, the more you can anticipate misunderstanding before it happens.
在写下任何一个字之前，先回答三个问题：
你为什么要写这条消息？ 是什么触发了你写这条消息？如果原因重要，请在消息中说明。另外：如果你带着情绪写消息，请先停下来。大多数消息的目的不是赢得争论——而是获得结果。明确自己的意图往往会让你彻底重写消息。
你想要达成什么目标？ 目标要具体。“我希望团队遵守新的部署规则”是明确的目标。“我想要沟通部署相关事宜”则不是。如果你无法明确目标，那么消息也不会有清晰的方向。
你的受众是谁？ 不同群体需要不同的词汇和深度：
  • 工程师 —— 适合使用技术细节，默认对方具备领域背景
  • 业务利益相关者 —— 解释对他们重要的内容，避免术语
  • 支持团队 —— 需要了解所有场景和边缘情况
  • 其他经理 —— 共享大部分背景信息，保持简洁
你对受众了解越多，就越能提前预判可能出现的误解。

Step 2: Write Simply

第二步：简洁写作

Write the way you speak. Simple words carry the same meaning as complex ones, with less cognitive load on the reader. Complex sentences aren't a sign of intelligence — they're a sign that the writing wasn't edited.
Specific rules that help:
  • Use active voice. "I pushed to production" instead of "The production environment was updated."
  • Put the most important thing first. Don't bury the headline.
  • Avoid walls of text. Use paragraph breaks, 3–4 sentences each.
  • Structure for skimming. If it's long, use headers or bullets.
用日常说话的方式写作。简单词汇和复杂词汇表达的含义相同，但给读者带来的认知负担更小。复杂句子并非智慧的体现——而是说明写作未经编辑。
有助于实现简洁写作的具体规则：
  • 使用主动语态。 比如用“我已推送至生产环境”代替“生产环境已被更新”。
  • 最重要的内容放在最前面。 不要把核心信息藏在后面。
  • 避免大段文字。 使用段落分隔，每段3-4句话。
  • 为快速阅读优化结构。 如果内容较长，使用标题或项目符号。

Step 3: Run a Garbage Collector

第三步：冗余清理

Before sending: remove every word that doesn't add information. Shorter messages get read. Longer messages get skimmed, misread, or ignored.
Example:
"We are changing the current rule for merging our pull requests: you now need at least one approval to merge your changes, instead of two approvals — we trust you, and we want to move our things a bit faster."
After the garbage collector:
"We are changing the rule for merging pull requests: you need one approval, instead of two — we trust you, and we want to move faster."
Same message. Less friction.
发送前：删除所有不增加信息的词汇。更短的消息会被完整阅读，更长的消息则会被快速浏览、误读或忽略。
示例：
"我们正在更改当前的合并拉取请求规则：现在你只需要至少一个批准即可合并变更，而不是之前的两个批准——我们信任你，希望推进速度能更快一些。"
经过冗余清理后：
"我们将更改拉取请求的合并规则：只需一个批准即可合并，无需两个——我们信任你，希望加快推进速度。"
传达的信息相同，却减少了阅读阻力。

When Stakes Are High

高风险场景处理

For messages with significant consequences — a policy change, a team restructure, a difficult announcement — ask someone from your target audience to read it before you send. You'll catch misunderstandings before they reach everyone.
Don't aim for perfection. A clear, timely message is better than a perfect delayed one.
对于具有重大影响的消息——政策变更、团队重组、棘手公告——请先让目标受众中的一员阅读后再发送。这样可以在消息扩散前发现可能的误解。
不要追求完美。清晰及时的消息比完美但延迟的消息更有价值。

The Async Re-Explanation Trap

异步重复解释陷阱

The most damaging Slack pattern is not bad grammar or long messages — it is calling out when someone missed a prior message: "as I already said," "I clearly wrote above," "I explained this last week."
The recipient feels humiliated. Repeat exposure destroys working relationships. The root cause is a false assumption: that because you wrote something clearly, the other person read and processed it the same way.
A corrective mental model: assume the other person has ten times as many active threads as you do. This reframes their miss as expected, not negligent — and produces two improvements: you write more concise, context-complete messages upfront, and you respond to misses with patience rather than public correction.
If a pattern of missed messages becomes a systemic problem, address it directly and privately, never in-thread.
Slack中最具破坏性的行为不是语法错误或长消息——而是指出他人遗漏了之前的消息：“正如我之前所说”“我上面写得很清楚”“我上周就解释过了”。
接收者会感到羞辱。反复出现这种情况会破坏工作关系。根本原因是一个错误的假设：你认为自己写得很清楚，对方就会以同样的方式阅读和理解。
纠正性思维模型：假设对方的活跃对话线程数量是你的十倍。这会将对方的遗漏重新定义为预期情况，而非疏忽——进而带来两个改进：你会在最初就写出更简洁、上下文完整的消息，并且在面对遗漏时会耐心回应，而非公开指责。
如果消息被遗漏的情况成为系统性问题，请直接私下解决，不要在对话线程中处理。

The Compression/Decompression Model

压缩/解压模型

All communication is lossy. The speaker compresses rich internal experience or technical context into transmittable language. The listener decompresses it through their own lens. The received message is never identical to the sent one.
Two failure modes follow:
  • Over-compression: too little context; the recipient fills gaps wrong
  • Over-explanation: past a clarity peak, adding more detail actually reduces understanding by introducing noise
Compression skill means finding the minimum set of words that reliably produces an "aha" moment in the specific listener — not the most complete explanation, but the most efficient one for that audience. This applies to feedback, technical proposals, and stakeholder updates.
Decompression skill means actively working to receive what was actually meant, not what you expected to hear. The more confident you feel you understood, the more likely you are wrong.
A calibration tool: after delivering a message, ask the other person to reflect back what they heard. The gap between your intent and their summary is your compression error. Technical managers are often weakest here — precision in code does not transfer to precision in communication.
所有沟通都会存在信息损耗。发送者将丰富的内部经验或技术背景压缩为可传递的语言，接收者则通过自己的视角进行解压。接收的消息永远与发送的消息不完全相同。
由此产生两种失败模式：
  • 过度压缩： 上下文信息过少，接收者会错误地填补信息空白
  • 过度解释： 超过清晰阈值后，添加更多细节反而会引入干扰，降低理解度
压缩技巧是找到能让特定接收者产生“恍然大悟”感的最少词汇量——不是最完整的解释，而是针对该受众最有效的解释。这适用于反馈、技术提案和利益相关者更新等场景。
解压技巧是主动尝试理解对方实际想表达的内容，而非你预期听到的内容。你越确信自己理解了，就越可能是错误的。
校准工具：发送消息后，请对方复述他们听到的内容。你的意图与他们总结内容之间的差距就是你的压缩误差。技术经理往往在这方面表现薄弱——代码中的精准性无法直接转化为沟通中的精准性。

Dive Deeper

深入拓展

If the user asks where a framework came from or wants more context on any topic in this skill — read 
references/sources.md
.
如果用户询问某个框架的来源，或希望了解本技能中任何主题的更多背景信息——请阅读
references/sources.md
文件。

Related Skills

相关技能

  • feedback
    — Specific principles for written and verbal feedback delivery
  • managing-yourself
    — Communication finesse with senior leadership
  • working-with-pm
    — Stakeholder communication is central to the PM–EM relationship
  • influence
    — Written communication as a tool for building organizational influence
  • feedback
    —— 书面和口头反馈传递的具体原则
  • managing-yourself
    —— 与高层领导沟通的技巧
  • working-with-pm
    —— 利益相关者沟通是产品经理（PM）与工程经理（EM）关系的核心
  • influence
    —— 书面沟通作为构建组织影响力的工具