Professional Communication 是一个面向软件开发者的专业沟通技能，提供在软件研发协作场景中撰写与组织职场信息的框架和指导。其核心原则是：有效沟通的重点不在于证明自己知道多少，而在于确保信息被接收并理解。
用途方面，该技能适用于以下场景：撰写发给同事、管理者或干系人的邮件；撰写团队聊天消息或异步沟通内容；准备会议议程或会议总结；把技术概念翻译给非技术受众；组织状态更新或报告的结构；提升书面表达的清晰度。相关关键词包括 email、chat、teams、slack、discord、message、writing、communication、meeting、agenda、status update、report。
主要框架方面，文档给出三类核心方法。第一是 What-Why-How 结构，用于组织任何职业信息：What 清晰陈述主题或请求，例如“我们需要将发布推迟一周”；Why 解释原因，例如“支付处理中发现严重缺陷”；How 列出下一步或行动项，例如“QA 将在周四前重新测试，我将在周五更新干系人”。该结构可应用于邮件、状态更新、会议要点和技术说明。第二是书面沟通三条黄金法则：以清晰的主题或目的开头，让收件人立刻明白信息内容；使用要点、标题和可扫读的排版，避免大段文字；关键信息前置，让忙碌的读者高效获取重点。第三是受众校准，在沟通前先问自己：写给谁（技术同行、管理者、干系人还是客户）；对方需要多高的细节层级（高层概览还是实现细节）；对他们有什么价值（会如何影响其工作或决策）。
邮件最佳实践方面，文档给出主题行公式，例如将“Project updates”改为“Project X: Status Update and Next Steps”，将“Question”改为“Quick question: API rate limiting approach”，将“FYI”改为“FYI: Deployment scheduled for Tuesday 3pm”。邮件结构模板包括：主题行写明项目或话题与具体目的；开头一到两句话直接说明关键点或请求；上下文或背景用要点列出；明确需要对方做什么，包括具体行动或决策以及时间要求；可选的后续步骤或跟进计划；结尾署名。常见邮件类型包括状态更新（进度摘要、阻塞项、下一步、时间线）、请求（明确诉求、背景、截止时间、重要性）、升级（问题摘要、影响、已尝试的解决方案、所需决策）、通知或公告（变化内容、受影响对象、是否需要行动）。更多模板见 references/email-templates.md。
团队消息礼仪方面，文档说明虽然示例使用 Slack 术语，但这些原则同样适用于 Microsoft Teams、Discord 或任何团队消息平台。何时用聊天、何时用邮件：聊天适合有简短答案的快速问题、实时协调、非正式团队讨论、时间敏感更新；邮件适合需要记录的详细文档、面向干系人的正式沟通、需要仔细审阅的消息、包含多部分的复杂说明。团队消息最佳实践包括：使用线程，保持主频道可扫读，后续讨论放在线程中；谨慎使用 @提及，避免不必要的打扰；按主题选择合适的频道；表达直接，例如“你能审阅我的 PR 吗？”优于“嘿，你在忙吗？”；编写异步友好、不要求立即回复的消息。文档还提出“No Hello”原则，不要只发“你好”“你在吗”“我能问你个事吗”然后等待，而应一次性给出背景与问题，例如直接说明关于部署脚本的权限错误并附上错误内容。
技术与非技术沟通方面，文档按受众给出不同策略：面对工程同行，可使用技术细节、代码示例和架构细节；面对技术管理者，平衡细节与高层影响；面对非技术干系人，强调业务影响、类比和结果，而非实现细节；面对客户，使用平实语言，说明对他们意味着什么，避免行话。简化表达的三条策略是：先讲大局再讲细节；在不失准确的前提下简化，使用类比并把行话换成平实语言；知道何时切换表达方式，根据提问和参与度调整。文档还给出术语翻译示例，例如把“Microservices architecture”解释为系统被拆分为更小、独立、可分别扩展的部分；把“Asynchronous message processing”解释为任务被排队并在后台处理；把“CI/CD pipeline”解释为自动测试和部署代码的流程；把“Database migration”解释为更新数据的组织和存储方式。更多示例见 references/jargon-simplification.md。
写作清晰度方面，文档建议优先使用主动语态而非被动语态，例如“The team identified a bug”优于“A bug was identified by the team”；去除冗余词，例如用“Now”替代“At this point in time”，用“If”替代“In the event that”，用“Because”替代“Due to the fact that”，用“To”替代“In order to”，用“Can you”替代“I just wanted to check if”；并使用“So what?”检验，写完后自问这对读者为什么重要，若无法清楚回答，就应重构信息、把价值和影响前置。
会议沟通方面，会前议程最佳实践要求每个会议邀请包含清晰目标、带时间估算的议程项、需要准备的内容、预期结果（需要决策、信息共享还是头脑风暴）。会中引导技巧包括为讨论设定时间盒、实时记录行动项（谁在何时前完成什么）、设置 parking lot 记录跑题事项留待后续。会后总结格式包含会议主题与日期、参会人、关键决策、行动项（负责人、任务、截止日期）、后续步骤（如需要跟进会议或待分享文档）。按会议类型划分的结构见 references/meeting-structures.md。
文档还提供发送任何职业沟通前的快速检查清单：目的是否清晰，收件人能否在 5 秒内理解意图；受众是否正确，是否选对了人或渠道；关键信息是否前置；是否可扫读，是否有要点、标题和短段落；行动是否明确，收件人是否知道需要做什么；行话检查，受众是否能理解所有术语；语气是否合适，是否专业但不冷漠；是否已校对错别字或不清表达。
附加工具包括 references/email-templates.md（按类型划分的即用邮件模板）、references/meeting-structures.md（站会、回顾、评审等会议结构）、references/jargon-simplification.md（技术到平实语言的翻译）。相关配套技能包括 feedback-mastery（用于困难对话和反馈传达）以及 /draft-email（使用这些框架生成邮件）。
关于收费、价格、平台支持范围等信息，资料中暂未提供。