zayn-cross-functional-collaboration

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

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