From 5f754a8f61529b4fa05fae22612dcac1907a6901 Mon Sep 17 00:00:00 2001 From: yumoqing Date: Sun, 16 Aug 2026 23:46:35 +0800 Subject: [PATCH] =?UTF-8?q?feat(skills):=20=E6=96=B0=E5=A2=9E=20task=20ski?= =?UTF-8?q?ll(SDLC=20=E7=8A=B6=E6=80=81=E6=9C=BA=E8=A7=84=E8=8C=83)=20+=20?= =?UTF-8?q?team-communication=20skill=20=E8=A7=92=E8=89=B2=E8=A7=84?= =?UTF-8?q?=E8=8C=83=E5=8C=96?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - task skill: 任务状态/合法流转/角色→操作权限(业务级RBAC)/门禁/人拍板点，配套 task 能力工具 - team-communication: 角色统一规范名 agent.{role}(agent角色) + {orgtype}.{role}(人角色)， SDLC 默认人角色=owner.superuser，新增 approval 问题类型(human gate) --- skills_library/all/task/SKILL.md | 79 +++++++++++++++++++ .../all/team-communication/SKILL.md | 58 ++++++-------- 2 files changed, 105 insertions(+), 32 deletions(-) create mode 100644 skills_library/all/task/SKILL.md diff --git a/skills_library/all/task/SKILL.md b/skills_library/all/task/SKILL.md new file mode 100644 index 0000000..16e8e98 --- /dev/null +++ b/skills_library/all/task/SKILL.md @@ -0,0 +1,79 @@ +--- +name: task +description: 任务状态机规范——定义任务状态、合法流转、角色→操作权限、门禁、人拍板点。agent 处理任务时据此操作，LLM 读本 skill 判断流转合法性。产线默认 SDLC 状态机，项目可同名覆盖。触发：认领/提交/审核/退回/完成/重试任务。 +--- + +# 任务状态机规范 + +本 skill 是**规范**（任务状态 + 流转规则 + 角色权限）。任务操作由系统固化的 **task 能力**（工具）执行， +本 skill 描述这些工具该怎么用、什么时候能用。 + +## 一、核心模型 + +- 任务 = 一个概念的实例，沿状态机流转。 +- **状态存表**（pipeline_tasks.state），**流转规则在本 skill**（LLM 读后判断合法性）。 +- 工具只做 CAS 原子迁移（`WHERE state=from`），**不校验合法性**——合法性由你读本 skill 判断。 +- 每次迁移自动写审计（audit_log，append-only）。 + +## 二、任务状态（SDLC 默认） + +| 状态 | 语义 | +|---|---| +| submitted | 待认领（新任务 / 被退回后重新认领） | +| running | 角色 agent 执行中 | +| review | 已提交产出，待审核 | +| approved | 审核通过 | +| completed | 全流程完成 | +| waiting | 挂起等回答（提问未答复） | +| failed | 失败 | + +## 三、合法流转图 + +``` +submitted ──claim──▶ running ──submit──▶ review ──approve──▶ approved ──complete──▶ completed + ▲ │ │ (最后一角色) + │ │ suspend │ reject + │ ▼ ▼ + │ waiting ──revive──▶ submitted + │ ▲ + └──retry────────── failed ◀──(任意状态执行失败)── running +``` + +明确规则： +- `claim`：submitted → running，仅认领自己角色的任务（claimed_by 原子，防并发）。 +- `submit`：running → review，产出交付件后提交。 +- `approve`：review → approved（仅审核角色）。 +- `reject`：review → submitted，附退回意见，被退角色重新认领响应。 +- `complete`：approved → completed（最后一个角色完成后）。 +- `suspend`/`revive`：提问挂起 / 回答后恢复认领。 +- `fail`/`retry`：执行失败 / 重试。 + +## 四、角色 → 操作权限（业务级 RBAC） + +| 角色 | 可执行操作 | +|---|---| +| agent.requirement / agent.design / agent.develop / agent.test / agent.deploy | claim、submit | +| agent.pm | approve、reject、complete | +| agent.main_agent | 问题路由、答复（见 team-communication） | +| owner.superuser（人，RBAC orgtype.role） | 最终确认、审批兜底 | + +## 五、门禁 + +- review 通过：交付件满足需求规格。 +- review 退回：附意见，任务回 submitted，被退角色重新认领。 +- 最后一角色（agent.deploy）approve 后 complete。 + +## 六、人拍板点（human gate） + +需要人审批/确认时，**不直接改状态**，而是走问题冒泡到 `owner.superuser`（见 team-communication skill， +problem_type 用 approval/confirm）。人答复后由 agent 再执行状态迁移。 + +## 七、配套能力（task 能力工具） + +`claim_task` / `submit_task` / `approve_task` / `reject_task` / `complete_task` / +`mark_failed` / `retry_task` / `suspend_task` / `revive_task` / `set_task_state`（通用 CAS 兜底）。 + +## 八、分层覆盖 + +本 skill 是产线默认（SDLC 状态机）；项目可放**同名 task skill** 覆盖：简化/扩展状态机、改角色权限。 +加载顺序：项目级 → 产线级 → 全局兜底。 diff --git a/skills_library/all/team-communication/SKILL.md b/skills_library/all/team-communication/SKILL.md index b782850..6f6b032 100644 --- a/skills_library/all/team-communication/SKILL.md +++ b/skills_library/all/team-communication/SKILL.md @@ -1,6 +1,6 @@ --- name: team-communication -description: 团队沟通规范（问题冒泡）——定义团队角色、问题类型、冒泡路径，agent 有问题时据此处理（提问题/找自己要处理的/回答/转交）。产线定义默认规范，项目可用同名 skill 覆盖。触发：agent 发现问题、角色缺信息、PM 退回、故障上报、客户提问、待处理问题>0。 +description: 团队沟通规范（问题冒泡）——定义团队角色、问题类型、冒泡路径，agent 有问题时据此处理（提问题/找自己要处理的/回答/转交）。角色用规范名：agent 角色 agent.{role}，人角色 {orgtype}.{role}。产线默认规范，项目可同名覆盖。触发：agent 发现问题、角色缺信息、PM 退回、故障上报、客户提问、待处理问题>0。 --- # 团队沟通（问题冒泡）规范 @@ -8,34 +8,33 @@ description: 团队沟通规范（问题冒泡）——定义团队角色、问 本 skill 是**规范**（团队结构 + 问题类型 + 冒泡路径）。问题操作的工具由系统固化， agent 读本 skill 理解规范后，用工具执行。 -## 一、核心模型 +## 一、角色命名规范（重要） -- **团队** = 一组不同角色的 agent + 人。多 agent 存在：同一角色可有多个 agent， - 处理方必须精确到 `角色 + agentid`（agentid 空 = 该角色任意 agent）。 -- **问题类型** = 一种问题 + 一条冒泡路径（处理方序列）。 -- **冒泡规则**：问题产生后从路径第一个处理方开始；处理方解决了→停（answered）； - 没解决→沿路径转给下一个处理方；路径尽头通常是「人」兜底。 +- **agent 角色**统一前缀 `agent.`：`agent.{role}`，如 `agent.main_agent`、`agent.pm`、`agent.develop`。 +- **人角色**用 RBAC 的 `{orgtype}.{role}` 模式：如 `owner.superuser`、`org.admin`。 +- 处理方 = 角色名 + agentid（多 agent 同角色须精确到 agentid；agentid 空 = 该角色任意 agent）。 -## 二、团队角色（产线默认） +## 二、团队角色（SDLC 默认） | 角色 | 类型 | 职责 | |---|---|---| -| main_agent | agent | 用户面对话 agent，回答问题、路由到客户 | -| pm | agent | 项目经理，审核交付件、退回意见 | -| requirement | agent | 需求分析师 | -| design | agent | 系统设计师 | -| develop | agent | 开发工程师 | -| test | agent | 测试工程师 | -| deploy | agent | 部署运维 | -| customer | human | 人类客户，最终兜底 | +| agent.main_agent | agent | 用户面对话 agent，回答问题、路由到人 | +| agent.pm | agent | 项目经理，审核交付件、退回意见 | +| agent.requirement | agent | 需求分析师 | +| agent.design | agent | 系统设计师 | +| agent.develop | agent | 开发工程师 | +| agent.test | agent | 测试工程师 | +| agent.deploy | agent | 部署运维 | +| owner.superuser | 人 | 客户/业主，最终兜底审批 | -## 三、问题类型与冒泡路径（产线默认） +## 三、问题类型与冒泡路径（SDLC 默认） | 问题类型 | 冒泡路径 | 说明 | |---|---|---| -| need_info | main_agent → customer | 角色缺信息向上提问，主 agent 答 / 转客户 | -| review_reject | 被退角色 → pm | PM 退回，被退角色响应后复审 | -| fault_report | main_agent → customer | 任务失败报障，主 agent / 客户人工介入 | +| need_info | agent.main_agent → owner.superuser | 角色缺信息向上提问 | +| review_reject | 被退角色 → agent.pm | PM 退回，被退角色响应后复审 | +| fault_report | agent.main_agent → owner.superuser | 任务失败报障，人兜底 | +| approval | agent.main_agent → owner.superuser | 需人审批/确认（human gate） | 冒泡路径是**规范**，由 agent 读后决策「下一个转给谁」，系统不把路径存进数据。 @@ -43,31 +42,26 @@ agent 读本 skill 理解规范后，用工具执行。 | 工具 | 作用 | |---|---| -| raise_problem(problem_type, question, first_handler_role, first_handler_agentid) | 提问题，显式指定首处理方 | +| raise_problem(problem_type, question, from_role, first_handler_role, first_handler_agentid) | 提问题，显式指定首处理方 | | list_problems_for(role, agentid) | 查「当前该我处理」的问题（确定性过滤） | | resolve_problem(question_id, answer) | 解决 → 停止冒泡 | | escalate_problem(question_id, next_handler_role, next_handler_agentid) | 没解决 → 显式转给下一个处理方 | -cockpit 侧包装：`list_questions`（查待我处理的）、`answer_question`（回答）、 -`escalate_question`（转给客户）。 +cockpit 侧包装：`list_questions`（查待我处理）、`answer_question`（回答）、`escalate_question`（转给人）。 ## 五、处理流程（agent 侧） -1. 我发现问题 → `raise_problem`，按问题类型 + 冒泡路径指定首处理方。 -2. 我可能被指派处理问题 → `list_problems_for(我的角色, 我的 agentid)` 查待办， - 不要只报统计数字，逐条读。 +1. 我发现问题 → `raise_problem`，按问题类型 + 冒泡路径指定首处理方（规范名）。 +2. 我可能被指派处理 → `list_problems_for(我的角色名, 我的 agentid)` 查待办，逐条读。 3. 我能解决 → `resolve_problem`（任务自动恢复，冒泡停止）。 -4. 我答不了 → `escalate_problem`，沿冒泡路径转给下一个处理方。 +4. 我答不了 → `escalate_problem`，沿冒泡路径转给下一个处理方（规范名）。 ## 六、分层与覆盖 -- 本 skill 是**产线级默认规范**（skills_library 模板）。 -- 项目可用**同名 team-communication skill** 放在项目 skills 目录覆盖： - 同名问题类型 → 项目覆盖；新增 → 追加；未定义 → 兜底到产线级。 +- 本 skill 是**产线级默认规范**；项目可用**同名 team-communication skill** 覆盖。 - 加载顺序：项目级 → 产线级 → 全局兜底。 ## 七、状态与归属 - 状态只有 `pending`（冒泡中）/ `answered`（已解决）。 -- 归属 = `current_handler_role` + `current_handler_agentid` 两列， - 由工具维护，查询走确定性 SQL，不靠 LLM 扫全文。 +- 归属 = `current_handler_role` + `current_handler_agentid` 两列，由工具维护，查询走确定性 SQL。