Back to Details

professional-communication

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Professional Communication Skill

专业沟通转化Skill

Operator Context

操作上下文

This skill operates as an operator for technical communication transformation, configuring Claude's behavior for structured information extraction and business formatting. It implements the Deterministic Template architectural pattern -- extract all propositions, categorize by type, apply structured template -- with Domain Intelligence embedded in the status classification and tone transformation methodology.
本Skill作为技术沟通转化的操作器，用于配置Claude的行为以实现结构化信息提取和商业格式转换。它采用Deterministic Template架构模式——提取所有命题、按类型分类、应用结构化模板——并在状态分类和语气转换方法中嵌入了Domain Intelligence。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

  • CLAUDE.md Compliance: Read and follow repository CLAUDE.md before transformation
  • Over-Engineering Prevention: Only transform what's directly requested. No speculative sections, no "nice to have" formatting not asked for
  • Complete Proposition Extraction: NEVER lose technical details during transformation
  • Status Indicators: Always use GREEN/YELLOW/RED in output (non-negotiable for executive readability)
  • Template Structure: Always follow "Status -> Key Point -> Summary -> Technical Details -> Next Steps" format
  • Four-Phase Process: PARSE -> STRUCTURE -> TRANSFORM -> VERIFY (mandatory workflow)
  • CLAUDE.md 合规性: 转化前需阅读并遵循仓库中的CLAUDE.md文件
  • 避免过度设计: 仅转化用户直接要求的内容，不添加未被请求的推测性章节或“锦上添花”的格式
  • 完整命题提取: 转化过程中绝对不能丢失技术细节
  • 状态标识: 输出中必须使用GREEN/YELLOW/RED（为保证高管可读性，此要求不可协商）
  • 模板结构: 必须遵循「状态 -> 核心要点 -> 摘要 -> 技术细节 -> 下一步计划」的格式
  • 四阶段流程: 必须执行PARSE（解析）-> STRUCTURE（结构化）-> TRANSFORM（转化）-> VERIFY（验证）的工作流

Default Behaviors (ON unless disabled)

默认行为（默认开启，可关闭）

  • Communication Style: Report transformation results factually without self-congratulation
  • Executive Summary: Include executive-friendly overview by default
  • Action Item Extraction: Extract and list next steps with ownership implications
  • Context Bridging: Make implicit knowledge explicit for non-technical audiences
  • Professional Tone: Transform casual/defensive language into neutral business language
  • Temporary File Cleanup: Remove intermediate analysis files at completion
  • 沟通风格: 如实报告转化结果，不添加自夸内容
  • 高管摘要: 默认包含适合高管阅读的概述
  • 行动项提取: 提取并列出带有归属影响的下一步计划
  • 上下文衔接: 将隐含知识明确化，以便非技术受众理解
  • 专业语气: 将随意/防御性语言转化为中立的商业语言
  • 临时文件清理: 完成后删除中间分析文件

Optional Behaviors (OFF unless enabled)

可选行为（默认关闭，需开启）

  • Technical Deep Dive: Include extended technical details beyond 2-3 sentence summary
  • Comparative Analysis: Add historical comparison sections
  • Multi-Stakeholder Variants: Generate multiple versions for different audiences
  • 技术深度剖析: 除2-3句话的摘要外，包含扩展的技术细节
  • 对比分析: 添加历史对比章节
  • 多利益相关方版本: 为不同受众生成多个版本

What This Skill CAN Do

本Skill可实现的功能

  • Extract all propositions from dense technical communication without information loss
  • Apply deterministic templates that produce consistent business-formatted output
  • Classify status indicators (GREEN/YELLOW/RED) based on objective severity criteria
  • Transform defensive or emotional language into neutral business language
  • Generate specific, actionable next steps with ownership and timeline markers
  • 从密集的技术沟通中提取所有命题，不丢失任何信息
  • 应用确定性模板，生成格式一致的商业风格输出
  • 根据客观严重程度标准对状态标识（GREEN/YELLOW/RED）进行分类
  • 将防御性或情绪化语言转化为中立的商业语言
  • 生成带有归属和时间标记的具体、可执行的下一步计划

What This Skill CANNOT Do

本Skill无法实现的功能

  • Write new content from scratch (use appropriate writing skill instead)
  • Generate documentation that doesn't transform an existing input
  • Skip proposition extraction and jump straight to formatting
  • Create multi-stakeholder variants by default (enable optional behavior first)
  • Transform without verifying information completeness in Phase 4
  • 从零开始创作新内容（请使用对应的写作Skill）
  • 生成无需基于现有输入进行转化的文档
  • 跳过命题提取直接进行格式转换
  • 默认生成多利益相关方版本（需先开启可选行为）
  • 未经过第4阶段的信息完整性验证就进行转化

Instructions

操作说明

Phase 1: PARSE

第一阶段：PARSE（解析）

Goal: Extract every proposition from the input before structuring anything.
Step 1: Classify input type
Identify the communication type:
  • Technical update (progress report with embedded facts)
  • Debugging narrative (stream-of-consciousness problem-solving)
  • Status report (project state with blockers/dependencies)
  • Dependency discussion (constraints buried in defensive language)
Step 2: Extract all propositions
Parse each sentence systematically:
  1. Facts: All distinct statements of truth
  2. Implications: Cause-effect relationships
  3. Temporal markers: Past/present/future actions
  4. System references: All mentioned components
  5. Blockers: Hidden dependencies and constraints
  6. Emotional context: Frustration/satisfaction/urgency indicators
Step 3: Document implicit context
Surface assumptions the author takes for granted but the audience needs stated:
  • Technical acronyms or project names the audience may not know
  • Timeline context (when things happened relative to milestones)
  • Organizational context (team relationships, reporting structures)
Step 4: Count and validate propositions
markdown
undefined
目标: 在进行任何结构化处理前，提取输入内容中的所有命题。
步骤1：分类输入类型
识别沟通类型：
  • 技术更新（包含事实的进度报告）
  • 调试记录（意识流式的问题解决过程）
  • 状态报告（包含阻塞点/依赖项的项目状态）
  • 依赖项讨论（隐藏在防御性语言中的约束条件）
步骤2：提取所有命题
系统地解析每个句子：
  1. 事实: 所有明确的真实陈述
  2. 隐含关联: 因果关系
  3. 时间标记: 过去/现在/未来的行动
  4. 系统引用: 所有提及的组件
  5. 阻塞点: 隐藏的依赖项和约束条件
  6. 情绪上下文: 沮丧/满意/紧急程度的标识
步骤3：记录隐含上下文
明确作者默认但受众需要了解的假设：
  • 受众可能不知道的技术缩写或项目名称
  • 时间线上下文（事件相对于里程碑的发生时间）
  • 组织上下文（团队关系、汇报结构）
步骤4：统计并验证命题
markdown
undefined

Parsing Result

解析结果

Input type: [technical update | debugging narrative | status report | dependency discussion] Proposition count: [N distinct facts/claims] Emotional markers: [frustration | satisfaction | urgency | neutral]
Extracted Propositions:
  1. [Fact/claim 1]
  2. [Fact/claim 2] ... (ALL propositions - NO information loss)
Implicit Context:
  • [Assumption 1]
  • [Assumption 2]

**Gate**: ALL propositions extracted with zero information loss. Proceed only when gate passes.
输入类型: [技术更新 | 调试记录 | 状态报告 | 依赖项讨论] 命题数量: [N个不同的事实/声明] 情绪标记: [沮丧 | 满意 | 紧急 | 中立]
提取的命题:
  1. [事实/声明1]
  2. [事实/声明2] ...（所有命题 - 无信息丢失）
隐含上下文:
  • [假设1]
  • [假设2]

**准入条件**: 所有命题已提取，无信息丢失。仅当满足此条件时才可进入下一阶段。

Phase 2: STRUCTURE

第二阶段：STRUCTURE（结构化）

Goal: Categorize and prioritize all extracted propositions.
Step 1: Categorize propositions
markdown
Status:   [items with current state]
Actions:  [completed, in-progress, planned]
Impacts:  [business and technical consequences]
Blockers: [dependencies, constraints]
Next:     [required actions]
Step 2: Priority order
  1. Business Impact (revenue, customer, strategic)
  2. Technical Functionality (core operation)
  3. Project Timeline (schedule implications)
  4. Resource Requirements (personnel, infrastructure)
  5. Risk Management (potential issues)
Step 3: Identify information gaps
Flag any propositions that need clarification before transformation:
  • Ambiguous severity (could be GREEN or YELLOW)
  • Missing ownership for action items
  • Undefined technical terms critical to business impact
Gate: All propositions categorized and prioritized. Proceed only when gate passes.
目标: 对所有提取的命题进行分类和优先级排序。
步骤1：命题分类
markdown
状态:   [与当前状态相关的内容]
行动:  [已完成、进行中、计划中的事项]
影响:  [业务和技术后果]
阻塞点: [依赖项、约束条件]
下一步: [所需行动]
步骤2：优先级排序
  1. 业务影响（收入、客户、战略）
  2. 技术功能（核心操作）
  3. 项目时间线（进度影响）
  4. 资源需求（人员、基础设施）
  5. 风险管理（潜在问题）
步骤3：识别信息缺口
标记转化前需要澄清的命题：
  • 严重程度模糊（可能为GREEN或YELLOW）
  • 行动项缺少归属方
  • 对业务影响至关重要的技术术语未定义
准入条件: 所有命题已分类并排序。仅当满足此条件时才可进入下一阶段。

Phase 3: TRANSFORM

第三阶段：TRANSFORM（转化）

Goal: Apply output template with professional tone.
Step 1: Apply standard template
markdown
**STATUS**: [GREEN|YELLOW|RED]
**KEY POINT**: [Single most important business takeaway]

**Summary**:
- [Primary accomplishment/issue]: [Business impact]
- [Current focus/blocker]: [Expected outcome/resolution need]
- [Secondary consideration]: [Implications]

**Technical Details**:
[2-3 sentences maximum preserving technical accuracy]

**Next Steps**:
1. [Specific action with timeline if available]
2. [Secondary action with ownership implications]
3. [Follow-up considerations]
Step 2: Tone adjustment
  • Strip hedging, defensive language, and filler
  • Preserve urgency markers and severity indicators
  • Keep technical terms intact (do NOT oversimplify)
  • Maintain causal chains and specific metrics
Step 3: Status classification
  • GREEN: Fully complete with no follow-up, all verification done
  • YELLOW: Resolved with follow-up needed, blocked on dependencies, partial completion
  • RED: Active critical issues, production impact, urgent intervention needed
  • Document reasoning: "Status: YELLOW (deployment successful but monitoring pending)"
Step 4: Action item specificity
Every next step MUST include:
  • Specific action verb (investigate, deploy, coordinate, document)
  • Clear scope (what exactly needs doing)
  • Ownership implication (who or which team)
  • Timeline marker when available (IMMEDIATE, by EOW, this sprint)
Gate: Output follows template structure with professional tone. Proceed only when gate passes.
目标: 应用输出模板并调整为专业语气。
步骤1：应用标准模板
markdown
**状态**: [GREEN|YELLOW|RED]
**核心要点**: [最重要的业务结论]

**摘要**:
- [主要成就/问题]: [业务影响]
- [当前重点/阻塞点]: [预期结果/解决需求]
- [次要考虑因素]: [影响]

**技术细节**:
[最多2-3句话，保留技术准确性]

**下一步计划**:
1. [具体行动，如有时间线请注明]
2. [次要行动，带有归属影响]
3. [后续考虑事项]
步骤2：语气调整
  • 去除含糊其辞、防御性语言和冗余内容
  • 保留紧急程度标记和严重程度指标
  • 完整保留技术术语（不得过度简化）
  • 保留因果链和具体指标
步骤3：状态分类
  • GREEN: 完全完成，无后续工作，所有验证已完成
  • YELLOW: 问题已解决但需后续跟进、依赖项阻塞、部分完成
  • RED: 存在活跃的关键问题、对生产环境有影响、需要紧急干预
  • 记录理由: "状态: YELLOW (部署成功但监控待完成)"
步骤4：行动项具体化
每个下一步计划必须包含：
  • 具体的动作动词（调查、部署、协调、记录）
  • 明确的范围（具体需要做什么）
  • 归属影响（对应人员或团队）
  • 时间标记（如有）（立即、本周结束前、本迭代）
准入条件: 输出遵循模板结构且语气专业。仅当满足此条件时才可进入下一阶段。

Phase 4: VERIFY

第四阶段：VERIFY（验证）

Goal: Confirm transformation quality before delivery.
Step 1: Compare output against extracted propositions -- NO information loss
Step 2: Verify technical accuracy -- terms, metrics, causal chains preserved
Step 3: Confirm status indicator matches actual severity
Step 4: Validate action items are specific (who, what, when) not vague
Step 5: Check appropriate detail level for target audience
Step 6: Document transformation summary
markdown
undefined
目标: 交付前确认转化质量。
步骤1: 对比输出与提取的命题——无信息丢失 步骤2: 验证技术准确性——术语、指标、因果链均保留 步骤3: 确认状态标识与实际严重程度匹配 步骤4: 验证行动项具体明确（包含谁、做什么、何时做），而非模糊表述 步骤5: 检查细节级别是否适合目标受众 步骤6: 记录转化摘要
markdown
undefined

Transformation Summary

转化摘要

Input type: [type] Propositions extracted: [N] Status assigned: [GREEN|YELLOW|RED] ([reasoning]) Information loss: None Template applied: [standard | executive | technical manager]

**Gate**: All verification checks pass. Transformation is complete.

---
输入类型: [类型] 提取的命题数量: [N] 分配的状态: [GREEN|YELLOW|RED] ([理由]) 信息丢失情况: 无 应用的模板: [标准 | 高管 | 技术经理]

**准入条件**: 所有验证检查通过。转化完成。

---

Examples

示例

Example 1: Multi-Propositional Sentence

示例1：多命题句子

User says: "I fixed the database issue but then the API started failing so I had to rollback and now we're investigating the connection pool settings which might be related to the recent Kubernetes upgrade." Actions:
  1. Extract 5 propositions: DB fix, API failure, rollback, pool investigation, K8s link (PARSE)
  2. Categorize: Status=rollback done, Blockers=pool+K8s, Actions=investigating (STRUCTURE)
  3. Apply template with YELLOW status, specific next steps (TRANSFORM)
  4. Verify no facts lost, technical terms preserved (VERIFY) Result: Structured update with clear status and actionable next steps
用户输入: "我修复了数据库问题，但随后API开始故障，所以我不得不回滚，现在我们正在调查连接池设置，这可能与最近的Kubernetes升级有关。" 操作:
  1. 提取5个命题：数据库修复、API故障、回滚、连接池调查、与K8s的关联（PARSE阶段）
  2. 分类：状态=回滚完成，阻塞点=连接池+K8s，行动=调查中（STRUCTURE阶段）
  3. 应用模板，状态设为YELLOW，添加具体的下一步计划（TRANSFORM阶段）
  4. 验证无事实丢失、技术术语保留（VERIFY阶段） 结果: 结构化更新，包含清晰的状态和可执行的下一步计划

Example 2: Defensive Blocker Communication

示例2：防御性阻塞点沟通

User says: "I can't make progress because the API team hasn't responded in 3 days and my sprint is at risk" Actions:
  1. Extract urgency, duration, dependency, impact propositions (PARSE)
  2. Categorize: Blocker=API spec, Impact=sprint risk, Timeline=3 days (STRUCTURE)
  3. Apply template with YELLOW status, escalation-focused next steps (TRANSFORM)
  4. Verify urgency preserved, defensive tone neutralized (VERIFY) Result: Neutral status report with clear escalation path
用户输入: "我无法取得进展，因为API团队已经3天没有回复，我的迭代进度面临风险。" 操作:
  1. 提取紧急程度、时长、依赖项、影响命题（PARSE阶段）
  2. 分类：阻塞点=API规范，影响=迭代风险，时间线=3天（STRUCTURE阶段）
  3. 应用模板，状态设为YELLOW，添加以升级为重点的下一步计划（TRANSFORM阶段）
  4. 验证紧急程度保留、防御性语气已中和（VERIFY阶段） 结果: 中立的状态报告，包含清晰的升级路径

Example 3: Crisis Communication

示例3：危机沟通

User says: "The latest deploy broke checkout completely, users are getting 500 errors, we rolled back but some orders might be lost" Actions:
  1. Extract severity, system affected, user impact, rollback status, data risk (PARSE)
  2. Categorize: Status=rolled back, Impact=orders lost, Blocker=data recovery (STRUCTURE)
  3. Apply template with RED status, IMMEDIATE/URGENT tiered next steps (TRANSFORM)
  4. Verify crisis severity reflected, no false reassurance in tone (VERIFY) Result: RED status report with tiered emergency response actions
用户输入: "最新部署完全破坏了结账功能，用户收到500错误，我们已回滚但部分订单可能丢失。" 操作:
  1. 提取严重程度、受影响系统、用户影响、回滚状态、数据风险（PARSE阶段）
  2. 分类：状态=已回滚，影响=订单丢失，阻塞点=数据恢复（STRUCTURE阶段）
  3. 应用模板，状态设为RED，添加分层次的紧急下一步计划（TRANSFORM阶段）
  4. 验证危机严重程度已体现、语气无虚假安慰（VERIFY阶段） 结果: RED状态报告，包含分层次的应急响应行动

Error Handling

错误处理

Error: "Missing Context in Input"

错误："输入缺少上下文"

Cause: Technical terms or acronyms critical to business impact are undefined Solution:
  1. Ask user for clarification on terms critical to status classification
  2. Make reasonable inferences for minor details
  3. Note all assumptions explicitly in Technical Details section
原因: 对业务影响至关重要的技术术语或缩写未定义 解决方案:
  1. 向用户请求对状态分类至关重要的术语的澄清
  2. 对次要细节做出合理推断
  3. 在技术细节部分明确记录所有假设

Error: "Ambiguous Status Classification"

错误："状态分类模糊"

Cause: Input contains mixed signals (e.g., issue resolved but monitoring incomplete) Solution:
  1. Default to YELLOW when unclear between GREEN/YELLOW
  2. Default to RED only with clear critical indicators (production impact, data loss)
  3. Document reasoning in parenthetical after status indicator
原因: 输入包含混合信号（例如，问题已解决但监控未完成） 解决方案:
  1. 当GREEN和YELLOW之间不明确时，默认设为YELLOW
  2. 仅当存在明确的关键指标（生产环境影响、数据丢失）时，默认设为RED
  3. 在状态标识后的括号中记录理由

Error: "Multi-Thread Update Contamination"

错误："多线程更新混淆"

Cause: Input contains multiple unrelated topics that could cross-contaminate Solution:
  1. Process each thread as separate proposition set
  2. Apply template independently to each thread
  3. Combine with clear thread identification in final output
  4. Ensure status indicators are thread-specific
原因: 输入包含多个不相关的主题，可能互相干扰 解决方案:
  1. 将每个线程作为单独的命题集处理
  2. 为每个线程独立应用模板
  3. 在最终输出中通过清晰的线程标识进行合并
  4. 确保状态标识针对每个线程

Anti-Patterns

反模式

Anti-Pattern 1: Skipping Proposition Extraction

反模式1：跳过命题提取

What it looks like: Jumping straight to template formatting without parsing all embedded facts Why wrong: Loses technical details, misses causal relationships, assigns wrong status Do instead: Complete Phase 1 fully. Extract ALL propositions before any formatting.
表现: 未解析所有嵌入事实就直接进行模板格式化 危害: 丢失技术细节、遗漏因果关系、状态分配错误 正确做法: 完整完成第一阶段。在进行任何格式化前提取所有命题。

Anti-Pattern 2: Adding Unsolicited Sections

�模式2：添加未被请求的章节

What it looks like: Adding "Risk Assessment", "Mitigation Strategies", "Historical Context" not in the original Why wrong: Over-engineering that changes meaning, increases length, violates hardcoded behavior Do instead: Apply ONLY the standard template. Let user request additional analysis.
表现: 添加原始内容中没有的「风险评估」、「缓解策略」、「历史上下文」等章节 危害: 过度设计会改变原意、增加篇幅、违反硬编码行为 正确做法: 仅应用标准模板。如有额外分析需求，由用户主动提出。

Anti-Pattern 3: Losing Technical Accuracy for Simplicity

反模式3：为简化而丢失技术准确性

What it looks like: "Redis cluster failover with 15-second timeout" becomes "database problems caused delays" Why wrong: Strips specificity needed for technical teams to act. Violates complete proposition extraction. Do instead: Keep technical terms, preserve metrics, maintain causal chains in Technical Details section.
表现: "Redis集群故障转移超时15秒" 被简化为 "数据库问题导致延迟" 危害: 技术团队失去采取行动所需的具体信息。违反完整命题提取要求。 正确做法: 保留技术术语、指标和因果链，在技术细节部分准确呈现。

Anti-Pattern 4: Vague Action Items

反模式4：模糊的行动项

What it looks like: "Fix the issue", "Follow up on dependencies", "Improve the system" Why wrong: No ownership, no timeline, no scope. Stakeholders cannot act on vague items. Do instead: "Complete Redis failover testing in staging (DevOps team, by EOW)"
表现: "修复问题"、"跟进依赖项"、"改进系统" 危害: 无归属、无时间线、无范围。利益相关方无法根据模糊的行动项采取行动。 正确做法: 例如写成 "在预演环境完成Redis故障转移测试（DevOps团队，本周结束前）"

Anti-Pattern 5: Inconsistent Status Indicators

反模式5：状态标识不一致

What it looks like: 2-hour outage marked GREEN, successful deploy with incomplete monitoring marked GREEN Why wrong: Inconsistency confuses stakeholders and erodes trust in the status system Do instead: Apply status criteria consistently. Document reasoning in parenthetical.
表现: 2小时的停机标记为GREEN，成功部署但监控未完成标记为GREEN 危害: 不一致会混淆利益相关方，削弱对状态系统的信任 正确做法: 一致应用状态标准。在括号中记录理由。

References

参考

This skill uses these shared patterns:
  • Anti-Rationalization - Prevents shortcut rationalizations
  • Verification Checklist - Pre-completion checks
本Skill使用以下共享模式：
  • 反合理化 - 防止捷径式合理化
  • 验证清单 - 完成前的检查

Domain-Specific Anti-Rationalization

领域特定反合理化

RationalizationWhy It's WrongRequired Action
"I can summarize without extracting first"Summarizing skips propositions, loses factsComplete Phase 1 extraction
"Status is obviously GREEN"Obvious ≠ verified against criteriaApply status classification rules
"Technical details aren't needed here"Non-technical audience ≠ no technical sectionInclude Technical Details section always
"Action items are implied"Implied ≠ actionable for stakeholdersWrite explicit next steps with ownership
"Close enough tone"Professional tone requires specific transformationsApply defensive->neutral, casual->professional rules
合理化借口错误原因要求动作
"我可以直接总结，无需先提取命题"总结会跳过命题，丢失事实完成第一阶段的命题提取
"状态显然是GREEN"显然 ≠ 符合标准验证应用状态分类规则
"这里不需要技术细节"非技术受众 ≠ 不需要技术章节始终包含技术细节部分
"行动项是隐含的"�含 ≠ 对利益相关方可执行编写明确的带有归属的下一步计划
"语气差不多就行"专业语气需要特定的转化规则应用防御性→中立、随意→专业的规则

Reference Files

参考文件

  • ${CLAUDE_SKILL_DIR}/references/templates.md
    : Status-specific templates, section formats, phrase transformations
  • ${CLAUDE_SKILL_DIR}/references/examples.md
    : Complete transformation examples with proposition extraction
  • ${CLAUDE_SKILL_DIR}/references/templates.md
    : 特定状态模板、章节格式、短语转化规则
  • ${CLAUDE_SKILL_DIR}/references/examples.md
    : 包含命题提取的完整转化示例