zayn-cross-functional-collaboration

SKILL.md

---
name: zayn-cross-functional-collaboration
description: 处理跨部门协同、进度确认、信息补充、风险同步和内部沟通表达，区分已确认事实、用户判断和待确认信息，避免过早承诺、推责、情绪化表达和未经确认的责任认定。
---
# CROSS_FUNCTIONAL_COLLABORATION() 跨部门协同

## 1. 基本信息

```text
Skill ID: zayn-cross-functional-collaboration
Display Name: CROSS_FUNCTIONAL_COLLABORATION()
Chinese Name: 跨部门协同
Project: WorkFn
Author Prefix: zayn
Category: Internal Collaboration
Version: 0.1.0
Status: Draft for testing
```

## 2. 解决的问题

整理跨部门事项中的事实、缺失信息、风险、责任边界、下一步动作和沟通方式。适用于需要确认项目进度、请求其他部门补充信息、同步风险阻塞、明确负责人和时间点、避免对外过早承诺，以及把零散内部信息整理为清晰可执行协同内容的场景。

本 Skill 不替用户决定责任，不自动承诺时间，不把内部讨论方案写成最终结论。

## 3. 适用场景

适用于销售、运营、产品、技术、项目管理、行政、人力资源、采购、客服、财务及其他需要跨部门协同的岗位。

典型场景包括：

1. 跨部门确认项目进度
2. 请求补充资料、评估、账号、报价、排期或审批信息
3. 同步当前风险、阻塞和影响
4. 明确下一步负责人、动作和反馈时间
5. 内部对齐后再对客户、供应商或外部对象回复
6. 将情绪化、推责式表达改为事实描述、影响说明和下一步请求

## 4. 不适用场景

1. 单纯向某部门提出明确请求，且不需要风险和承诺判断时，使用 `zayn-request`。
2. 已超出权限或影响重大，需要正式向上升级时，使用 `zayn-escalate`。
3. 需要领导在多个方案中做选择时，使用 `zayn-decision`。
4. 会前议题整理使用 `zayn-meeting`；会后纪要使用 `zayn-minutes`。
5. 对外客户回复最终文本使用 `zayn-reply`。
6. 不用于认定责任、处罚个人、替代正式审批或自动承诺交期。

## 5. 输入参数

### 必填参数

1. 当前事项
2. 涉及部门或角色
3. 已确认事实
4. 当前需要协同的目标
5. 希望生成的输出形式

### 建议参数

1. 尚未确认的信息
2. 当前阻塞或风险
3. 希望对方提供什么
4. 期望反馈时间
5. 是否已经对外承诺
6. 需要避免的表达
7. 已有内部沟通记录
8. 当前负责人或责任角色
9. 备选方案或临时方案
10. 使用渠道：邮件、飞书、企业微信、微信、Slack 或会议同步

## 6. 参数运行要求

正式输出前必须先解析输入并输出参数状态表。参数状态只使用：`已命中`、`部分命中`、`缺失`、`冲突`、`待验证`。

最低运行条件：

1. 当前事项基本明确。
2. 至少一个涉及部门或角色明确。
3. 至少有一项已确认事实。
4. 本次协同目标基本明确。
5. 能判断是否存在过早承诺、推责或信息不足风险。

未满足最低运行条件时，只输出缺失信息、最少量补问和可暂时使用的保守沟通版本，不生成完整协同结论。

## 7. 信息识别规则

将输入拆成三类：

1. 已确认事实：用户明确提供、资料中明确存在或人工已确认的信息。
2. 用户判断：用户对原因、责任、影响或可能结果的主观判断。
3. 待确认信息：缺少来源、尚未由责任部门确认、时间或结果未定的信息。

输出中必须清楚区分三类信息。待确认信息不得写成事实，用户判断不得写成正式结论。

## 8. 判断流程

1. 识别事项和协同目标。
2. 映射涉及部门、角色和责任边界。
3. 区分已确认事实、用户判断和待确认信息。
4. 检查是否存在未经确认的时间、结果、责任或方案承诺。
5. 检查是否存在指责、推责、情绪化催促或不必要暴露内部问题。
6. 判断推进内容是否具备当前状态、待确认事项、责任角色、下一步动作和反馈时间。
7. 根据信息完整度选择分析模式、直接回复模式或协同推进模式。

详细判断细则见 `references/decision_rules.md`。

## 9. 风险检查

重点检查：

1. 是否未经相关部门确认就承诺时间。
2. 是否未经评估就承诺结果。
3. 是否把预计时间表达为确定时间。
4. 是否把内部讨论方案表达为最终方案。
5. 是否把他人建议表达为正式结论。
6. 是否指责某个部门动作慢或暗示个人失职。
7. 是否暴露不必要的内部矛盾、资源不足、人员失误或管理问题。
8. 是否缺少负责人、反馈时间或超时更新方式。
9. 是否需要先内部确认再对外回复。

## 10. 输出模式

### 分析模式

只分析事项、缺失信息、风险和下一步，不生成完整沟通文本。适用于用户要求“帮我判断”“先分析一下”的场景。

### 直接回复模式

生成可直接发送的内部沟通内容。适用于用户明确要求“帮我写给某部门/同事”的场景。

### 协同推进模式

默认模式。输出当前状态、待确认事项、责任角色、时间节点、沟通文本和后续跟进建议。

## 11. 输出结构

默认输出：

1. 参数完整度结论
2. 参数状态表
3. 事项判断
4. 已确认事实
5. 用户判断与待验证信息
6. 待确认事项
7. 风险提醒
8. 建议推进动作
9. 内部沟通版本
10. 简短版本
11. 后续跟进建议

可直接发送的沟通版本必须清楚、客观、不情绪化、不推责、不过度客套，不使用模糊空话，不做未经确认的承诺。

输出模板见 `references/output_templates.md`。

## 12. 禁止事项

1. 不自动认定某个部门或个人应承担责任。
2. 不自动承诺明确交期、上线时间、解决时间或完成结果。
3. 不把推测、预计、内部讨论或用户判断写成确定事实。
4. 不暴露不必要的内部矛盾、资源不足、人员失误或管理问题。
5. 不为了输出完整而强行补全缺失信息。
6. 不覆盖现有人工判断。
7. 不修改用户提供的原始材料。
8. 不使用指责、抱怨、施压或情绪化语言。
9. 不把复杂问题简化成单一责任人问题。
10. 不越过 `zayn-request`、`zayn-escalate`、`zayn-decision`、`zayn-reply` 的职责边界。

## 13. 示例

更多场景见 `references/scenario_examples.md`。

### 项目提前上线

设计稿未最终确认、技术未评估开发和测试时间时，不得直接承诺新上线日期。可表达为：当前正在加急评估，建议先同步待确认项，并约定下一次更新时间。

### 系统权限未开通

一个账号已开通、另一个账号预计下周一完成时，不得直接认定 IT 延误。应先确认培训是否依赖未开通账号，并给出临时替代安排或后续更新时间。

## 14. 测试要求

测试至少覆盖：

1. 信息完整，可直接生成沟通内容。
2. 信息不足，需要先提问。
3. 用户试图未经确认承诺时间。
4. 用户表达带有明显指责。
5. 用户未明确责任人和时间点。
6. 用户只需要简短内部消息。

每个测试必须检查：输入识别、预期识别结果、不允许出现的内容、预期输出结构和参考输出。

## 15. 当前状态

```text
Version: 0.1.0
Status: Draft for testing
```