Claude-Code-Workflow/.claude/skills/team-edict/SKILL.md

name, description, allowed-tools

name	description	allowed-tools
team-edict	三省六部 multi-agent 协作框架，完整复刻 Edict 架构。 太子接旨 -> 中书省规划 -> 门下省审议(多CLI并行) -> 尚书省调度 -> 六部并行执行。 强制看板状态上报（state/flow/progress），支持 Blocked 一等公民状态，全流程可观测。 Triggers on "team edict", "三省六部", "edict team".	TeamCreate(*), TeamDelete(*), SendMessage(*), TaskCreate(*), TaskUpdate(*), TaskList(*), TaskGet(*), Agent(*), AskUserQuestion(*), Read(*), Write(*), Edit(*), Bash(*), Glob(*), Grep(*)

Team Edict — 三省六部

受古代三省六部制启发的多 agent 协作框架。核心设计：严格的级联审批流 + 实时看板可观测性 + 多 CLI 并行分析。

Architecture

+----------------------------------------------------------+
|  Skill(skill="team-edict")                               |
|  args="任务描述"                                          |
+------------------------+---------------------------------+
                         |
              Coordinator (太子·接旨分拣)
              Phase 0-5 orchestration
                         |
         +---------------+--------------+
         |                              |
    [串行审批链]                   [看板 State Bus]
         |                              |
    中书省(PLAN)                  ← 所有 agent 强制上报
         |                         state/flow/progress
    门下省(REVIEW) ← 多CLI审议
         |
    尚书省(DISPATCH) ← 路由分析
         |
    +----+----+----+----+----+----+
    工部  兵部  户部  礼部  吏部  刑部
   (IMPL)(OPS)(DATA)(DOC)(HR)(QA)
   [team-worker × 6, 按需并行]

Role Router

此 skill 为 coordinator-only。所有 worker 直接以 team-worker agent 形式 spawn。

输入解析

直接解析 $ARGUMENTS 作为任务描述，始终路由至 coordinator。

Role Registry

角色	别名	Spec	Task Prefix	Inner Loop	职责
coordinator	太子	roles/coordinator/role.md	(none)	-	接旨分拣、驱动流程
zhongshu	中书省	role-specs/zhongshu.md	PLAN-*	false	分析旨意、起草执行方案
menxia	门下省	role-specs/menxia.md	REVIEW-*	false	多维审议、准奏/封驳
shangshu	尚书省	role-specs/shangshu.md	DISPATCH-*	false	分析方案、派发六部
gongbu	工部	role-specs/gongbu.md	IMPL-*	true	功能开发、架构设计、代码实现
bingbu	兵部	role-specs/bingbu.md	OPS-*	true	基础设施、部署、性能监控
hubu	户部	role-specs/hubu.md	DATA-*	true	数据分析、统计、资源管理
libu	礼部	role-specs/libu.md	DOC-*	true	文档、规范、UI/UX、对外沟通
libu-hr	吏部	role-specs/libu-hr.md	HR-*	false	Agent 管理、培训、考核评估
xingbu	刑部	role-specs/xingbu.md	QA-*	true	代码审查、测试验收、合规审计

门下省 — 多 CLI 审议配置

门下省审议使用多 CLI 并行分析，同时从多个维度评估方案：

审议维度	CLI Tool	Focus
可行性审查	gemini	技术路径、依赖完备性
完整性审查	qwen	子任务覆盖度、遗漏识别
风险评估	gemini (second call)	故障点、回滚方案
资源评估	codex	工作量合理性、部门匹配度

六部路由规则

尚书省（DISPATCH）根据任务内容将子任务路由至对应部门：

关键词信号	目标部门	说明
功能开发、架构、代码、重构、实现	工部 (gongbu)	工程实现
部署、CI/CD、基础设施、容器、性能监控	兵部 (bingbu)	运维部署
数据分析、统计、成本、报表、资源	户部 (hubu)	数据管理
文档、README、API文档、UI文案、规范	礼部 (libu)	文档规范
测试、QA、Bug、审查、合规	刑部 (xingbu)	质量保障
Agent管理、培训、技能优化、考核	吏部 (libu-hr)	人事管理

Dispatch

始终路由至 coordinator (太子)。

Orchestration Mode

用户只提供任务描述。

调用: Skill(skill="team-edict", args="任务描述")

生命周期:

用户提供任务描述
  -> coordinator Phase 1-2: 接旨判断 -> 简单问答直接回复 | 正式任务建 PLAN 任务
  -> coordinator Phase 3: TeamCreate -> spawn 中书省 worker (PLAN-001)
  -> 中书省执行 -> 生成执行方案 -> SendMessage callback
  -> coordinator spawn 门下省 worker (REVIEW-001) <- 多CLI并行审议
  -> 门下省审议 -> 准奏/封驳 -> SendMessage callback
    -> 封驳: coordinator 通知中书省修改 (最多3轮)
    -> 准奏: coordinator spawn 尚书省 worker (DISPATCH-001)
  -> 尚书省分析路由 -> 生成六部任务清单 -> SendMessage callback
  -> coordinator 按任务清单 spawn 六部 workers (按依赖并行/串行)
  -> 六部执行 -> 各自 SendMessage callback
  -> coordinator 汇总所有六部产出 -> Phase 5 报告

用户命令 (唤醒暂停的 coordinator):

命令	动作
check / status	输出看板状态图，不推进
resume / continue	检查 worker 状态，推进下一步
revise PLAN-001 <反馈>	触发中书省重新起草 (封驳循环)

看板状态协议

所有 worker 必须遵守以下状态上报规范（强制性）：

状态机

Pending -> Doing -> Done
              |
           Blocked (可随时进入，需上报原因)

状态上报调用

每个 worker 使用 team_msg 进行看板操作（替代 kanban_update.py）：

// 接任务时
team_msg(operation="log", session_id=<session_id>, from=<role>,
  type="state_update", data={state: "Doing", current_step: "开始执行[任务]"})

// 进度上报 (每个关键步骤)
team_msg(operation="log", session_id=<session_id>, from=<role>,
  type="impl_progress", data={
    current: "正在执行步骤2：实现API接口",
    plan: "步骤1分析✅|步骤2实现🔄|步骤3测试"
  })

// 任务交接 (flow)
team_msg(operation="log", session_id=<session_id>, from=<role>, to="coordinator",
  type="task_handoff", data={from_role: <role>, to_role: "coordinator", remark: "✅ 完成：[产出摘要]"})

// 阻塞上报
team_msg(operation="log", session_id=<session_id>, from=<role>, to="coordinator",
  type="error", data={state: "Blocked", reason: "[阻塞原因]，请求协助"})

Specs Reference

文件	内容	使用方
specs/team-config.json	角色注册表、六部路由规则、pipeline 定义、session 目录结构、artifact 路径	coordinator（启动时读取）
specs/quality-gates.md	各阶段质量门标准、跨阶段一致性检查规则、消息类型对应关系	coordinator（Phase 8 汇总验收时）、xingbu（QA 验收时）

Session Directory

.workflow/.team/<session-id>/
├── plan/
│   ├── zhongshu-plan.md       # 中书省起草的执行方案
│   └── dispatch-plan.md       # 尚书省生成的六部任务清单
├── review/
│   └── menxia-review.md       # 门下省审议报告（含多CLI结论）
├── artifacts/
│   ├── gongbu-output.md       # 工部产出
│   ├── xingbu-report.md       # 刑部测试报告
│   └── ...                    # 各部门产出
├── kanban/
│   └── state.json             # 看板状态快照
└── wisdom/
    └── contributions/         # 各 worker 知识沉淀

Spawn Template

Coordinator 使用以下模板 spawn worker：

Agent({
  subagent_type: "team-worker",
  name: "<role>",
  team_name: "<team_name>",
  prompt: `role: <role>
role_spec: .claude/skills/team-edict/role-specs/<role>.md
session: <session_path>
session_id: <session_id>
team_name: <team_name>
requirement: <original_requirement>
inner_loop: <true|false>`,
  run_in_background: false
})