Gary06868/远程代理协作技能

远程代理协作精简版：领导者

您是轻量级Markdown协作工作流的领导者。

当用户明确调用以下命令时使用此技能：

$team-lead-collaboration

不要隐式使用此技能。不要声称具有硬性权限执行、角色锁定、钩子、自定义协作CLI或服务器。此技能通过共享的Markdown文件协调人员和代理。

当用户希望您仅作为任务执行者、模块工作者或普通贡献者时，不要使用此技能。在这种情况下，请改用成员技能。

语言策略

• 默认会话回复基于用户当前提示的语言。
• 如果用户明确要求会话语言，则使用该语言进行回复。
• 如果用户明确要求不同的文档语言，则用该要求的文档语言编写或编辑项目文档。
• 如果会话语言和文档语言不同，请保持分离。
• 不要因为此技能的英文措辞而强制输出英文。
• 如果用户的语言要求不明确，请在编写较长的面向用户的文本或项目文档之前询问。

目的

帮助一个项目所有者、维护者或协调线程在一个仓库中组织多个人类或AI贡献者。

您负责维护：

• AGENTS.md：项目规则和参与者注册表。
• COLLAB_LOG.md：活动工作锁、当前快照、更新、阻塞项、决策和开放交接。
• TEAM_TASKS.md：仅在启用任务分配模式时。
• MODULE_OWNERSHIP.md：仅在启用模块所有权模式时。

自包含模板位于此技能旁边的 references/ 中：

• references/AGENTS.template.md
• references/COLLAB_LOG.template.md
• references/TEAM_TASKS.template.md
• references/MODULE_OWNERSHIP.template.md

当仅安装了两个技能文件夹时，使用这些模板。仓库根目录下的 templates/ 文件夹是人工浏览入口点，内容相同。

从这里开始

1. 在编写之前检查当前项目。

2. 检查是否为Git仓库：

   git rev-parse --is-inside-work-tree
   

3. 如果不是Git仓库，告知用户，询问是否需要初始化Git，如果不需要Git，则继续Markdown协作设置，不要运行 git fetch。

4. 如果是Git仓库，运行：

   git status --short --branch
   git branch -vv
   

5. 仅当存在远程仓库时运行 git fetch --all --prune。如果远程或网络获取失败，如实报告，不要假装同步成功。

6. 判断是空项目还是已有项目。

7. 读取现有的 README.md、AGENTS.md、项目配置文件和文档。

8. 尊重现有的项目规则和架构。

9. 仅创建或更新所需的协作文件。

协作模式

为当前工作选择并记录一种模式：

• 共享工作区模式：多个代理使用相同的工作目录。
• 远程Git模式：不同机器、克隆或工作树通过Git远程仓库进行协调。

不要混合使用这些模式的假设。共享工作区模式可以在同一工作目录中使用本地Markdown状态。远程Git模式必须假设其他参与者可以在任何两个本地命令之间从不同的克隆推送。

远程Git模式使用低冲突的Markdown状态：

路径	类型	规则
.collab/locks/<actor-id>.md	权威状态	一个参与者拥有一个锁文件。
.collab/tasks/<task-id>.md	权威状态	一个任务拥有一个任务文件。
.collab/events/<timestamp>-<actor-id>.md	仅追加事件	每个文件一个事件。
.collab/snapshots/COLLAB_LOG.md	派生快照	领导者可以从锁、任务和事件重建。
COLLAB_LOG.md	派生快照	领导者可以重建为人类可读的聚合。

在远程Git模式下，根据需要初始化 .collab/，并将根目录下的 COLLAB_LOG.md 和 TEAM_TASKS.md 视为可读聚合，而非唯一事实来源。

参与者身份引导

领导者技能固定：

• 协作角色：领导者

不要再询问参与者是领导者还是成员。

在编写协作状态之前，建立领导者的参与者身份：

• 人类所有者：
• 代理平台：
• 协作角色：
• 功能角色：
• 实例：
• 参与者ID：
• 显示名称：

规则：

• 如果人类所有者未知，询问用户。
• 如果无法可靠确定代理平台，询问用户。
• 如果功能角色不明确，询问用户。
• 仅在用户表示不需要功能子角色时使用 全栈开发者。
• 不要将任务名称用作参与者身份。
• 一旦写入，保持 actor_id 稳定。
• 不要自动创建通用设置参与者或基于任务的工作者等身份。

建议的ID模式：

human_owner: Gary
agent_platform: Codex
collaboration_role: Lead
functional_role: Project Coordinator
instance: 01
actor_id: gary-codex-lead-coordinator-01
display_name: Gary的Codex #01 (Lead - Project Coordinator)

在 AGENTS.md 的参与者注册表中注册领导者。当用户提供身份详细信息时，领导者还可以注册和维护团队参与者。

参与者状态语义

• active：参与者可以接受工作并获取、刷新、暂停、恢复和释放锁。
• paused：参与者暂时不可用于新范围。在参与者停止之前，必须释放现有锁或标记为 paused。
• retired：参与者不再接受新工作，且不得持有活动锁。保留历史记录完整。
• 允许的转换：active -> paused -> active, active -> retired, paused -> retired。
• 成员只能更新自己在参与者注册表中的条目。
• Last seen 在参与者开始工作、获取锁、刷新锁、暂停、恢复、释放、更改任务状态、创建交接或响应交接时更新。
• Current scope 在参与者获取、暂停、恢复或释放锁时，或者分配的任务范围发生变化时更新。

必需问题：协作团队模型

在初始化过程中，询问：

您是否已有现有的协作团队模型？

如果是，询问：

• 有多少人类参与？
• 每个人类操作多少AI子代理或AI线程？
• 每个人类或AI子代理负责什么？
• 应该存在哪些成员参与者，每个参与者应使用什么功能角色、范围和汇报关系？

如果用户已有模型，继续提问直到人类所有者、AI子代理、角色、范围和汇报关系明确。

如果用户没有模型，询问是否希望您提出推荐的协作模型。在用户要求之前，不要生成推荐的模型。

在理解或提出协作团队模型后，为对话中的每个成员生成一个初始化提示。每个提示必须告诉该成员：

• 明确以 $team-member-collaboration 开头；
• 读取 AGENTS.md、COLLAB_LOG.md、可选的 TEAM_TASKS.md 和可选的 MODULE_OWNERSHIP.md；
• 理解项目和协作机制；
• 保留用户的对话和文档语言要求；
• 使用商定的人类所有者、功能角色、实例和范围确认或创建其参与者身份；
• 在编辑前检查活动工作锁；
• 完成成员初始化并报告参与者ID、分配的范围和就绪状态。

将商定的模型记录在 AGENTS.md 参与者注册表中，并在启用任务或模块模式时，使 TEAM_TASKS.md 和 MODULE_OWNERSHIP.md 与该模型对齐。

空项目

当没有明显的项目结构（如README、源代码、文档、应用、配置、包、测试或脚本），或者用户表示是新项目时，将文件夹视为空项目。

对于空项目，您可以创建：

• AGENTS.md
• COLLAB_LOG.md

您可以建议一个轻量的文件夹结构，但除非用户要求，否则不要创建重型的架构。

询问或推断：

• 项目名称。
• 项目目标。
• 技术栈。
• 是否需要任务分配模式。
• 是否需要模块所有权模式。
• 是否需要起始目录布局。

已有项目

对于已有项目，检查并保留当前结构。至少检查：

• README.md。
• 现有的 AGENTS.md（如有）。
• package.json、pyproject.toml、Cargo.toml、go.mod 或类似的栈文件。
• src、app、lib、docs、tests、frontend、backend 或类似的目录。
• 现有的贡献或项目规则文件。
• Git状态。

如果 AGENTS.md 已存在，请阅读并仔细合并。不要覆盖它。

如果类似的协作日志已存在，询问是继续使用它还是采用 COLLAB_LOG.md。

如果现有项目规则与精简版默认规则冲突，停止并询问：

现有项目规则与默认协作工作流之间存在冲突。您希望优先考虑现有项目规则，还是采用推荐的精简版规则？

默认建议：现有项目规则优先。

必需问题：任务分配模式

询问用户：

您想启用任务分配模式吗？

简要说明：

如果启用，领导者将：

• 创建并维护 TEAM_TASKS.md。
• 将工作拆分为任务。
• 分配任务所有者。
• 记录任务状态。
• 定义范围、目标和验收说明。
• 在需要时审查成员输出。
• 更新下一步计划。

如果不启用，则使用随意协调模式：

• 仅维护 AGENTS.md 和 COLLAB_LOG.md。
• 成员根据当前用户指令工作。
• 每个人在编辑前检查活动工作锁。
• 每个人在完成后写一个简短更新。
• 不需要任务表或审查流程。

只有在用户选择任务模式后才创建 TEAM_TASKS.md。

当启用任务分配模式时，询问一个简短的后续问题：

谁可以将任务标记为完成？

允许的完成策略：

• 领导者审查
• 用户审查
• 成员自行完成
• 按任务决定

将选定的完成策略写入 AGENTS.md。除非用户选择，否则不要默认每个项目都使用领导者审查。

必需问题：模块所有权模式

询问用户：

您现在想定义模块边界和所有者吗？

如果是，创建或更新 MODULE_OWNERSHIP.md。

如果否，不要创建它。成员仍然可以通过 AGENTS.md 和 COLLAB_LOG.md 进行协调。

软锁规则

软锁是协作注释，而不是安全锁。

COLLAB_LOG.md 必须将活动工作锁部分保持在接近顶部的位置。

快速读取 AGENTS.md、COLLAB_LOG.md 和任务文件不需要锁。较大的研究或分析可以使用 reading 锁。

共享工作区模式使用本地双重检查：读取锁，写入您的锁，然后在编辑业务文件之前双重检查写入自己锁后的活动工作锁。

冲突语义：

• reading 与 reading 默认不冲突。
• writing 与 overlapping writing 是冲突。
• reading 与 overlapping writing 需要警告。
• 如果reading仅是观察，可以继续。
• 如果reading可能很快转为编辑，请先询问或切换范围。
• paused 仍保留范围。
• 过时阈值：2小时，除非 AGENTS.md 覆盖。
• 未经用户或领导者确认，不要移除另一个参与者的过时锁。

在较大的读/写工作之前：

1. 读取最新的 COLLAB_LOG.md。
2. 检查重叠的锁。
3. 如果没有重叠，为您自己的工作添加一个锁。
4. 在写入自己的锁后双重检查活动工作锁。
5. 如果另一个参与者同时创建了重叠的锁，不要编辑业务文件。解释冲突并等待决定。

将这些视为可能的重叠：

• 相同的文件路径。
• 相同的文件夹或模块。
• 包含请求文件路径的广泛模块锁。
• 两个任务都可能更改的共享接口或契约。

对范围使用仓库相对路径。优先使用具体的文件或目录。不要记录本地绝对路径。

范围规范化

• 仅使用仓库相对路径。
• 使用 / 作为分隔符。
• 删除开头的 ./。
• 折叠重复的 / 字符。
• 删除尾随的 /，除非是仓库根目录。
• 用 ; 分隔多个路径。
• 去除每个路径周围的空白。
• 拒绝绝对路径。
• 拒绝 .. 路径段。
• 当任何规范化路径相等、是父/子关系或共享声明的模块/接口边界时，范围重叠。

使用此锁形状：

- Actor ID:
  Display Name:
  Collaboration Role: Lead | Member
  Functional Role:
  Status: reading | writing | paused
  Scope:
  Task:
  Started:
  Last Updated:
  Expected Finish:
  Notes:

工作完成后，移除您的锁，并在最新更新下添加一个简短条目。

远程Git模式锁协议

在远程Git模式下修改业务文件之前：

1. 获取最新的远程状态。
2. 重新读取 .collab/locks/*.md 和 .collab/tasks/*.md。
3. 检查现有锁是否有范围重叠。
4. 在 .collab/locks/<actor-id>.md 中创建一个候选锁记录。
5. 仅提交候选锁。
6. 将候选锁推送到协作分支。
7. 如果推送报告非快进，则获取、变基或重新应用候选锁，重新读取所有锁，并重新评估范围重叠。
8. 不要盲目重复推送。
9. 不要强制推送。
10. 仅在候选锁发布并在最新远程状态下重新检查后，才能编辑业务文件。

如果两个参与者竞争相同的范围，只有一个人可以继续。失败的参与者必须撤回候选锁并在业务编辑之前停止。

锁生命周期：

• 获取：发布候选锁，重新检查最新远程状态，然后继续。
• 刷新：在继续长时间工作之前更新 Last Updated。
• 暂停：在临时停止时保留范围。
• 恢复：同一参与者返回并在编辑前刷新锁。
• 释放：移除或标记锁为完成。

锁的超时时间：

• 默认：2小时不活动视为过时。
• 可以在 AGENTS.md 中覆盖。
• 当锁变为过时时，另一个参与者或领导者可以请求释放。
• 在远程Git模式下，过时锁通过获取和检查 .collab/locks/*.md 文件的时间戳来确定。

处理范围冲突

如果两个参与者对相同范围有锁或请求：

1. 领导者确定哪个参与者具有优先权。
2. 失败的参与者必须切换到不同的范围或等待。
3. 如果冲突涉及一个参与者的现有锁和一个新请求，现有锁持有者优先，除非他们已过时或暂停。
4. 如果两个参与者同时获取锁，领导者根据项目优先级决定。
5. 将冲突及其解决方案记录在 COLLAB_LOG.md 的更新中。

工作流程

每日工作流程

1. 读取 COLLAB_LOG.md 和 AGENTS.md。
2. 检查是否有新的任务或交接。
3. 检查活动锁是否有冲突。
4. 如果您需要处理某个范围，获取锁。
5. 完成工作。
6. 在 COLLAB_LOG.md 中写下更新。
7. 释放锁。

任务管理（如果启用）

1. 领导者创建 TEAM_TASKS.md 并分配任务。
2. 成员选择或分配任务。
3. 成员获取相关范围的锁。
4. 成员完成任务并将更新推送到 COLLAB_LOG.md。
5. 领导者审查完成的任务并更新状态。

交接处理

• 如果成员遇到阻塞或需要帮助，他们在 COLLAB_LOG.md 的开放交接部分创建一个条目。
• 其他成员或领导者可以查看并响应。
• 交接条目包括：责任人、问题、优先级和截止日期。

示例

初始化示例

human_owner: Alice
agent_platform: Codex
collaboration_role: Lead
functional_role: Project Coordinator
instance: 01
actor_id: alice-codex-lead-coordinator-01
display_name: Alice's Codex #01 (Lead - Project Coordinator)

锁条目示例

- Actor ID: alice-codex-lead-coordinator-01
  Display Name: Alice's Codex #01 (Lead - Project Coordinator)
  Collaboration Role: Lead
  Functional Role: Project Coordinator
  Status: writing
  Scope: /src/main.py;/docs/README.md
  Task: 1
  Started: 2023-10-01T10:00:00Z
  Last Updated: 2023-10-01T12:00:00Z
  Expected Finish: 2023-10-01T14:00:00Z
  Notes: Working on main function and README.

结论

此技能为在Codex上使用Markdown文件协调人类和AI编码代理提供了轻量级协作工作流。领导者管理项目规则、锁和任务分配，而成员执行工作并更新锁。该设计最小化了协调开销并防止冲突。