77 lines
6.6 KiB
Markdown
77 lines
6.6 KiB
Markdown
---
|
||
name: etunel-role-collaboration
|
||
description: 在 Etunel 多 Agent 项目中识别项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试或已登记的自定义角色，并按 Hub 唯一跨角色中介、依赖就绪任务波次、正式成果、人类负责人确认、成员与状态基线和 Etunel 消息流程推进项目。用于进入 Etunel 项目任务、确认职责边界、派发或完成任务、处理阻塞返工变更、阶段交接以及 Hub 钉钉进度汇报；不用于设计 Etunel 队列、投递、重试或去重机制。
|
||
---
|
||
|
||
# Etunel 多角色项目协作
|
||
|
||
一个 WORK_ID 使用一个持续的项目Hub会话贯穿生命周期。默认角色为项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试；已完成契约并由 Hub 真人负责人在 Etunel 中手动添加的自定义角色也可参与。
|
||
|
||
## 先确认身份与任务
|
||
|
||
从当前 Hook、Etunel 角色契约和入站任务确认：
|
||
|
||
- semantic role、实际 role ID、role member ID、session ID 和 human owner；
|
||
- WORK_ID、SUBTASK_ID、项目模式、流程基线、阶段、任务波次和本任务范围；
|
||
- 唯一主责角色与主责成员、协作角色、上游依赖和要求完成时间；
|
||
- 要求产出的文件或连贯成果包、最低内容、证据、完成条件和下游用途。
|
||
|
||
不要根据文件夹名、历史消息或记忆猜身份。成员、会话、职责或任务归属不清时，先报告边界问题，不自行换角色。
|
||
|
||
## 共享硬约束
|
||
|
||
1. 项目Hub是成员 Agent 之间唯一的跨角色中介。现阶段 Etunel 不支持成员间直接通信；成员只交 Hub，Hub 再定向路由，且不替角色改写或作出专业结论。
|
||
2. 正常阶段顺序为：业务需求、产品定义、方案设计、项目规划、软硬件实现、测试验证、业务验收、发布结项。阶段按有效流程基线和依赖推进。
|
||
3. 同一阶段中，依赖已满足的任务可组成任务波次；一个工具调用只有一个接收方，同一角色的多项工作可以内聚成任务包或连续派发多个 SUBTASK_ID。
|
||
4. 每个 SUBTASK_ID 只有一个主责角色、一个主责成员和一个可独立判定的结果。协作角色不等于共同主责。
|
||
5. Hub 给足当前任务需要的已登记信息，但不默认广播完整计划、全部资料或私有对话。缺口应聚合后经 Hub 定向补齐。
|
||
6. 正式执行任务必须要求具体产出文件或连贯成果包，且派发要求与预期产出一致。纯信息查询、确认或决定请求不虚构文件。
|
||
7. 角色 AI 收到任务后先与本角色 human owner 对齐，形成成果后完成专业自审并取得负责人确认，才可正式返回。
|
||
8. Hub 只校验身份、结构、版本、证据、确认状态、跨角色冲突、依赖和门禁，不替专业角色判断内容是否充分。
|
||
9. 项目模式、任务结果、成果生命周期、成果适用性、阶段门禁、测试结论、业务验收和消息通知是不同状态层；不适用项统一只写 NA，也不混用状态。
|
||
10. 正式项目只在已有成果覆盖且取得必要确认时受控跳转。明确的流程模拟可记录 BYPASSED_WITH_RISK 和 SIMULATION_ONLY，并只能以 SIMULATION_COMPLETED 结束。
|
||
11. Etunel 运行时负责队列、投递、重试、去重、会话授权和文件传输；本 Skill 不另造这些软件机制。
|
||
12. 当前 Hook、工具 schema、项目角色契约、成员登记和已确认流程基线高于本 Skill 的通用说明；不存在的工具、角色或参数不得伪造。
|
||
|
||
## 渐进式路由
|
||
|
||
只读取当前工作需要的引用：
|
||
|
||
- Hub：先读 [Hub 工作流](references/hub-workflow.md)。
|
||
- 创建项目、选择成员、配置自定义角色、成员交接、维护状态或发送状态快照：读 [成员与项目状态](references/project-status-and-membership.md)。
|
||
- 选择阶段、正式成果、任务波次或交接：读 [项目生命周期](references/project-lifecycle.md)。
|
||
- 成员：先读 [成员通用工作流](references/member-workflow.md)，再只读当前角色文件：
|
||
- [业务](references/roles/business.md)
|
||
- [产品](references/roles/product.md)
|
||
- [技术负责人](references/roles/technical-lead.md)
|
||
- [嵌入式应用层](references/roles/embedded-application.md)
|
||
- [嵌入式底层](references/roles/embedded-lowlevel.md)
|
||
- [硬件](references/roles/hardware.md)
|
||
- [测试](references/roles/testing.md)
|
||
- 准备派发、回复、跨角色中继、完成或报告阻塞：读 [Etunel 任务消息流程](references/etunel-message-lifecycle.md)。
|
||
- 定义或校验成果、状态、版本、证据、额外产出或豁免：读 [成果与完成判定](references/artifacts-and-evidence.md)。
|
||
- 缺信息、错投、阻塞、会议决定、返工、变更、流程跳转或模拟：读 [异常与协调](references/exceptions-and-coordination.md)。
|
||
- 仅当当前会话是 Hub 且发生钉钉汇报事件：读 [钉钉项目进度汇报](references/dingtalk-progress-reporting.md)。
|
||
- 测试角色仅在任务类型匹配时，按 [测试职责](references/roles/testing.md) 中的二级链接读取更深细则。
|
||
|
||
不要为“全面了解”一次加载全部引用或全部角色文件。Etunel Hook 源文件独立配置，不属于本 Skill 的渐进式发现树。
|
||
|
||
## 每项任务的控制循环
|
||
|
||
1. 确认身份、成员映射、有效流程与成果基线、任务目标、主责边界和 human owner。
|
||
2. 向负责人复述任务；一次核对输入、输出、证据、版本、期限、完成条件和下游用途。
|
||
3. 信息足够后执行本角色工作；缺少跨角色输入时，先走负责人路径，再向 Hub 提交聚合请求。
|
||
4. 形成产出文件或成果包，完成专业自审并取得负责人确认。
|
||
5. 通过当前 Hook 和 Etunel schema 对应的工具返回结果、补充请求或正式阻塞。
|
||
6. Hub 校验并登记；合格则更新成果、状态、依赖和下一波次，不合格则精确补齐或按异常流程路由。
|
||
|
||
## 提交前检查
|
||
|
||
- 身份、成员、会话、WORK_ID、SUBTASK_ID 和流程基线是否来自运行时？
|
||
- 是否只有一个主责角色和主责成员，且未越过其他角色专业或批准边界？
|
||
- 输入是否足够，输出文件、证据、期限和完成条件是否与任务要求一致？
|
||
- 自审、版本、负责人确认、开放项和风险是否明确？
|
||
- 状态层是否正确，NA、DEFERRED、WAIVED 和模拟状态是否被混用？
|
||
- 是否把并行任务波次误当成无依赖广播，或把消息排队、通知接受误当成业务完成？
|
||
- 是否只使用当前 schema 中与本次意图匹配的 Etunel 工具？
|