feat(skills): 新增 task skill(SDLC 状态机规范) + team-communication skill 角色规范化
- task skill: 任务状态/合法流转/角色→操作权限(业务级RBAC)/门禁/人拍板点，配套 task 能力工具
- team-communication: 角色统一规范名 agent.{role}(agent角色) + {orgtype}.{role}(人角色)，
SDLC 默认人角色=owner.superuser，新增 approval 问题类型(human gate)
This commit is contained in:
parent
d30fa89b51
commit
5f754a8f61
79
skills_library/all/task/SKILL.md
Normal file
79
skills_library/all/task/SKILL.md
Normal file
@ -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** 覆盖：简化/扩展状态机、改角色权限。
|
||||
加载顺序：项目级 → 产线级 → 全局兜底。
|
||||
@ -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。
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user