agent-team

把“多会话 = 多部门”的协作机制落到项目文件夹里。它不是角色扮演,而是岗位制度:每个会话有固定职责、写入边界、收件箱、交接班和审核闸。

先守住的边界

先有适合业务场景的项目地基,再搭协作层。默认目标目录 = 当前工作目录;若缺 docs/ 或缺清晰的目标/进度/交接文件,先判断项目类型:互联网产品 / Vibe Coding 才优先建议 vibe-project-foundation;其他业务场景优先使用已有专用业务地基 Skill 或现有文件结构。若没有合适地基,先问清目标业务、交付物、验收标准、过程资源、风险/复核方式,再帮用户创建一个最小业务地基,然后搭协作层。
三层必须齐全:管理层 / 执行层 / 审核层。最小盘是 lead,do,review;不要为了“多 Agent”硬拆部门。
创建 docs/collaboration/、新增/删除/替换部门、首次创建部门会话、改变跨会话路由或通知模式前,必须先让用户确认;已登记为自动/人工的短唤醒按 部门表.md 执行,不每次重复确认。
不直接写业务代码;本 skill 只做团队诊断、协作层搭建、会话登记和协作规则维护。
已有 docs/collaboration/ 时不要覆盖;先读现状,再判断是增量加部门、登记会话、更新规则还是重建。
启动前硬闸:不得从“帮我搭建团队/部门”直接默认成互联网产品开发。必须先确认项目最终交付物和会话创建模式,再推荐部门。

运行铁律

这些规则必须写进生成物,且后续派活都要遵守:

三类节点闸:每个功能 / 环节只推进一个验收节点。部门完成节点后先回报统筹部;统筹部按三类判断:产品感知/重大边界节点必须请用户确认,流程性/技术性节点可自主推进,可自主推进但影响项目可见性的节点必须用简短节点卡汇报。
收件箱是真相源:任务详情和回报写对应部门 收件箱.md;每个部门会话在上岗/接班时只做一次通知能力登记,后续按登记的“自动/人工”模式执行。通知只表达三类状态:有新任务 / 任务已完成 / 遇到阻断。
完成回报四件套:产出路径、验证结果(含未验证项)、日志收据、错题自检。缺任一项,统筹部不能视为完成闭环。
统筹不吃长上下文:统筹部先读自己的收件箱,只核日志收据存在;只有回报不足、收据错误、部门结论冲突或用户要求时,才读最小必要正文。
审核层独立不等于盲审充分:审核部门亲自验证,不继承执行部门长上下文,不采信“已通过”转述;但也不能只沿执行部门 happy path 重跑一遍。凡涉及用户看到 / 提示 / 错误文案 / 进度 / 状态 / 弹窗 / 结果摘要 / 导出文件名 / 打包态窗口,必须测到 worker / UI / 用户最终出口;只测 engine/API/helper 层不算通过。每个关键风险至少设计一个反向探针。
派单必须写验收出口和必测失败路径:统筹派单必须写清 验收出口 和 必测失败路径。验收出口指用户最终在哪里看到结果 / 提示 / 错误 / 状态 / 弹窗 / 结果摘要 / 导出文件名 / 打包态窗口;凡涉及用户可见内容,不得只写 engine/API/helper 层。必测失败路径至少列 1-3 个打破 happy path 的失败、异常或边界场景。缺失时接收部门回统筹补齐,不得自行脑补。
体验先于测试:可运行功能先给用户体验;进入“需要用户体验 App”的节点时,统筹部默认直接帮用户打开 App,不先问“要不要打开”,然后给一张短体验卡。用户明确确认“体验 OK / 可以进测试”后,测试部才做专业质量关。
设计意图必须可视化:凡涉及 UI、交互、视觉呈现、页面布局、设计稿、用户体验路径的节点,设计部不能只交文字说明、ASCII 线框、Markdown 表格或抽象结论;必须提供用户可直接判断的设计意图预览。设计预览不得声称等同真实 App UI;真实 UI 验收以运行中的 App / 真实路由 / 构建或打包态截图为准。
设计确认独立于功能确认:用户确认功能方向 OK 不等于视觉 / 交互通过。用户确认设计视觉或交互方向前,统筹部不得派开发部正式实现;最多只能推进功能可行性或技术评估。
盲审/抽检按触发介入:同一功能链连续多轮无阻断通过(默认 3 轮,可解释调整)、链路跨 engine→worker→UI→用户出口、涉及错误文案/状态/发布/打包/安全/费用等高风险,或用户/统筹觉得结论依据不足时,触发子 Agent 盲审/抽检。子 Agent 只回报盲审/抽检结论,不直接改代码、不自动放行。
风险/成本按触发介入:安全部只在大阶段、上线/外发前或隐私、权限、密钥、授权、第三方平台、生产配置等风险出现时介入;财务部只在成本节点介入,只预警上报不卡死发布。
放行由用户拍板:审核层三关通过后,统筹部只给放行建议;标记完成、对外发布、付费等由用户确认。
路由口诀:澄清类(不改产物、不裁决、不推进状态)直连对方收件箱;要改 / 要裁决 / 要变状态 / 要放行 / 要增删部门,经统筹部。
测试不通过分流:用户已体验 OK 后进入测试,若测试部发现纯代码 / 质量 / 异常路径问题,测试部回写统筹部,统筹部先用节点卡向用户同步,随后可自主派开发部返工;只有涉及体验取舍、范围变化、成本/安全/发布、方案选择或重大事项时才停下等用户确认。

统筹部三类节点决策

统筹部的判断原则:

用户负责产品体验、功能取舍、设计判断和重大风险拍板;统筹部负责技术流程、部门调度、常规质量关和无争议推进。自主推进必须保留简短汇报,遇到产品感知或重大边界变化必须停下确认。

A. 必须用户确认

凡是影响产品体验、用户感知、功能取舍、界面设计、交互流程、视觉呈现、MVP 边界、产品路线、上线发布、外发交付、成本明显增加、隐私/安全/云端/密钥/授权风险的节点,统筹部必须停下来让用户确认。

典型情况:

功能做完后,需要用户上手体验。
UI / 交互 / 设计稿完成后,需要给用户看可视化预览。
设计部产出只包含文字说明、ASCII 线框、Markdown 表格或抽象结论时,不得视为完成设计节点。
用户只确认功能方向 OK、但未确认视觉 / 交互方向时,不得进入正式开发实现。
功能要新增、删除、后置、改变范围时,需要用户判断。
测试通过后是否正式收口、是否进入下一大阶段,需要用户确认。
涉及云端、上传、API Key、联网下载、费用、打包体积明显变化时,需要用户确认。

B. 统筹可以自主推进

凡是用户不适合判断、且不改变产品体验和重大边界的流程性 / 技术性节点,统筹部可以按专业判断推进,不必反复询问。

典型情况:

产品边界确认后,派设计部做最小交互草案。
设计草案完成后,派开发部做实现评估。
设计视觉 / 交互已由用户确认,且技术评估结论清楚、风险可控时,派开发部进入正式实现;UI 未确认前只能推进实现评估 / 技术可行性。
用户体验 OK 后,派测试部做质量关。
测试部在用户已体验 OK 后发现纯代码 / 质量 / 异常路径问题,统筹部节点卡同步后派开发部返工。
测试无 P0/P1/P2 阻断时,统筹部可以建议通过并进入收口确认。
日志、交接、共享错题集、进度记录、轻量验证、用户确认收口后的 commit 存档等常规动作。

C. 可以自主推进但必须汇报

这类不需要用户拍板,但统筹部要用简短节点卡告诉用户“我已经推进到哪一步”。

节点卡示例:

“开发评估完成,但 UI 未确认,我只派开发做技术可行性评估。”
“设计视觉 / 交互已确认且开发评估风险可控,已派开发正式实现。”
“你体验 OK 后,我已派测试部做质量关。”
“测试发现代码层问题,不涉及产品取舍;我已派开发部返工。”
“测试无阻断,我准备收口存档。”
“安全/财务本节点未触发,所以未介入。”

验收出口、失败路径与盲审抽检

统筹派单必须把“验收看哪里”和“怎么打破 happy path”写进任务,不能只写一个抽象验收目标。

派单必填:

验收出口:用户最终在哪里看到结果 / 提示 / 错误 / 状态 / 弹窗 / 结果摘要 / 导出文件名 / 打包态窗口。凡涉及用户可见内容,不得只写 engine / API / helper 层。
必测失败路径:至少 1-3 个失败、异常或边界场景,用于打破 happy path。

缺任一项时,接收部门应回统筹部补齐,不得自行脑补。

审核 / 测试报告必填:

验证层级:engine / adapter-service / worker-后台任务 / UI-用户可见出口 / 打包态 / 未覆盖层级。
用户可见出口:实际测到的最终出口。
自设计反向探针:每个关键风险至少一个,说明如何证明不是只沿 happy path 重跑。
未覆盖层级:没有覆盖的层级必须明写,没有则写无。
是否触发子 Agent 盲审 / 抽检:写触发结论和依据。

审核层独立不等于盲审充分。审核部门不能只沿执行部门 happy path 重跑一遍;凡是用户看到 / 提示 / 错误文案 / 进度 / 状态 / 弹窗 / 结果摘要 / 导出文件名 / 打包态窗口的验收,必须测到 worker / UI / 用户最终出口;只测底层不算通过。

盲审 / 抽检触发条件:

同一功能链连续多轮无阻断通过,默认 3 轮,可按项目说明调整。
链路跨 engine→worker→UI→用户出口。
涉及错误文案、状态、发布 / 打包、安全、费用等高风险。
用户或统筹感觉结论依据不足。

触发后子 Agent 只做盲审 / 抽检结论回报,不直接改代码、不自动放行。

测试不通过后的返工分流

用户体验 App 通过,只代表体验流程、功能预期和用户感知可进入专业测试;不代表代码质量、异常路径、打包态、日志、边界条件已经通过。测试部若发现 P0/P1/P2 或其他质量问题,先写审核报告和 [回报] 到统筹部收件箱。统筹部必须先用节点卡向用户同步结论,然后按问题性质分流:

可自主派开发部返工:纯代码 bug、异常路径、错误文案、日志、打包态、worker/UI 出口不一致、测试覆盖缺口等专业质量问题;这些问题不要求用户做代码判断。
必须停下等用户确认:需要改变产品体验、功能范围、设计方案、MVP 边界、数据保留策略、成本、安全、隐私、发布方式,或存在多个修复方案且会牺牲体验 / 范围 / 成本 / 速度。

节点卡要写清楚:测试结论、影响、返工原因、是否涉及用户取舍、统筹判断、下一步。自主返工只代表进入修复闭环,不代表最终放行;修复后仍回到用户体验 / 测试节点。

收口与 commit 存档

交班不等于 git commit。部门完成节点时先更新交接班、日志、收件箱回报和必要产出;commit 是用户确认正式收口后的版本库归档动作。

测试无 P0/P1/P2 阻断、风险/成本关无阻断时,统筹部可以给出放行建议并请求用户确认正式收口。用户确认后,统筹部应执行:

运行 git status --short。
若工作区只有本节点相关变更,执行 commit 存档。
若存在无关变更、用户未确认变更或无法判断归属,先向用户说明,不要混提交。
若项目不是 git 仓库,说明无法 commit,只完成协作层收口记录。

commit 存档不代表对外发布;发布、外发、付费、上线仍由用户拍板。

App 体验节点

进入“需要用户体验 App”的节点时,统筹部默认直接帮用户打开 App,不先问“要不要打开”。如果当前环境能启动 / 打开 App,就直接执行;如果启动失败,说明失败原因、已尝试命令和用户可手动打开的入口。

体验卡标准:

入口:
重点:
建议试法:
判断口径:

体验卡要求:

入口:告诉用户从哪里进,如“配音/克隆音 → IndexTTS2 情感配音 → 情感强度”。
重点:告诉用户这次主要看什么,只放 1-2 个重点。
建议试法:给 2-4 个具体操作,让用户不用自己想怎么测。
判断口径:告诉用户只需要回复“体验 OK”或指出哪里不顺。

示例:

入口:配音/克隆音 → IndexTTS2 情感配音 → 情感强度
重点:听三档差异是否明显、自然。
建议试法:
- 试 开心 + 克制 / 标准 / 鲜明。
- 试 活力口播 是否默认带入 开心 + 鲜明。
- 切到 自然 看是否固定标准并提示。
判断口径:你觉得好用就说“体验 OK”,不顺就告诉我具体点。

设计可视化确认节点

凡涉及 UI、交互、视觉呈现、页面布局、设计稿、用户体验路径的节点,设计部必须交付用户可以直接判断的设计意图预览,不能只交文字说明、ASCII 线框、Markdown 表格或抽象结论。设计意图预览用于判断方向、布局、信息层级和交互感觉,不得声称等同真实 App UI。

真实 UI 验收必须来自运行中的 App、真实路由、构建产物或打包态截图。设计部的 OpenDesign / Figma / HTML mock / PNG 只能作为设计意图依据;开发部实现后必须标注与设计意图的差异,测试部用真实 App 界面检查是否偏离。

设计部交付优先级:

优先使用 OpenDesign 等专用设计工具生成可编辑设计产物或 artifact。
如果当前会话未热加载 OpenDesign MCP、OpenDesign 没有 active project、权限不足、工具连接失败,设计部必须在回报里明确失败原因。
工具不可用时,必须用本地 HTML + PNG 截图、Figma、可打开图片预览等方式兜底,保证用户看到设计意图,但不得承诺这就是最终真实 UI。
如果用户不想安装、启动、授权、注册或修复 OpenDesign,或不愿意为当前会话重载 / 新开会话,设计部不得卡住,应按用户偏好直接选择本地 HTML + PNG、Figma 或可打开图片预览。

设计部完成回报四件套中的“产出路径”必须同时包含:

设计说明文档路径。
设计意图预览路径,如 OpenDesign artifact 链接 / 本地 HTML / PNG 截图 / Figma 链接 / 可打开图片。
若使用兜底方案,必须写清 OpenDesign 当前状态和后续恢复条件。

OpenDesign 接入规则:

先确认本机 OpenDesign App 是否运行,再确认 daemon 健康状态。
不要假设默认端口一定是 7456;应从 OpenDesign 日志或本机监听端口确认实际 daemon URL。
确认后将 open-design MCP 注册到 Codex;当前会话可能无法热加载新 MCP,必要时提示用户重载 / 新开会话。
若 OpenDesign artifact 写入提示没有 active project,要求用户在 OpenDesign 内创建或点进项目,或直接使用本地 HTML / PNG 兜底交付,不能卡住节点。
若发现未安装 / 未运行 OpenDesign、权限不足、连接失败或 MCP 未热加载,设计部必须主动询问用户是否需要帮忙安装 / 启动 / 授权 / 注册 MCP / 重载或新开会话;用户不处理时立即走兜底可视化方案。
最小排障顺序:查 App 是否运行 → 查监听端口或日志里的 daemon URL → 查 MCP 是否已注册 / 当前会话是否已热加载 → 查 active project → 查权限 / 连接错误;任一步失败都同时给兜底预览方案。
OpenDesign 只是增强设计表达和可视化确认能力,不代表自动扩大为完整 UI 重设计、品牌升级或开发实现。

统筹部收到设计回报后:

先展示设计意图预览,再给用户一张简短节点卡。
节点卡建议结构:成果 / 判断点 / 建议 / 风险 / 下一步。
不要把长技术说明或设计正文直接丢给用户判断。
用户确认设计视觉或交互方向前,不得派开发部进入正式实现;如果用户只反馈功能方向 OK 但 UI 未确认,只能推进功能可行性或技术评估。
开发完成后的 UI 通过判断,不得继续引用设计意图预览代替真实界面;必须回到真实 App / 真实路由 / 构建或打包态截图。

自主推进停止条件

统筹自主推进不等于无限连续推进。可以连续推进流程性节点,但遇到以下情况必须停下问用户:

结论有明显不确定。
部门之间判断冲突。
需要牺牲体验、范围、成本、速度中的任一项。
要新增依赖、云端、联网、模型、成本。
要改变用户之前确认过的产品方向。
要进入可运行功能体验、UI 视觉确认、发布/打包/外发、大阶段收口。

诊断流程

如果用户已经说清项目类型、交付物和会话创建模式,直接诊断;不要重复问。信息不足时一次只问一个关键问题。

第一问:

这个项目最终要交付的东西是什么:可运行软件、内容/课程、运营结果、调研方案、自动化流程、线下交付,还是其他?

第二问:

这次会话部门怎么创建:由当前 Codex 这类有会话管理工具的 Agent 自动创建,还是你会先手动创建好各部门会话窗口,我只负责生成部门文件和上岗引导?

第一问没有答清前,不得推荐 product/design/dev/test 软件常见盘。第二问没有答清前,不得声称已经创建部门会话。若项目缺少地基文件,还要先判断是否已有适用的场景地基 Skill;没有时再创建通用最小业务地基,不要把所有项目都导向 vibe-project-foundation。

诊断时固定三层,只判断执行层拆几个、审核层开几关:

触发维度	命中则影响	部门
软件 / 互联网产品 / Vibe Coding / 有可运行产物	启用软件盘	`product/design/dev/test`
UI/交互/视觉重	强化设计	`design`
资料收集、用户/市场/竞品/事实核验重	加研究	`research`
方案、流程、排期、资源配置重	加策划	`planning`
数据采集/清洗/导入导出/准确性重	加数据	`data`
批处理、定时、跨平台自动执行	加自动化	`auto`
文案/图片/视频/报告持续生产	加内容	`content`
增长、转化、留存、商业化运营	加增长运营	`growth`
账号、登录、隐私、合规、第三方平台、密钥、生产配置	开风险关	`security`
预算、成本敏感、付费项	开成本关	`finance`
复杂功能、需要 bug/异常覆盖	独立质量关	`test` 或 `review`
都不强烈	通用最小盘	`lead,do,review`

非软件项目不要硬套产品/设计/开发/测试;先按交付物、验收标准、过程资源、风险和复核方式判断。无法归类时用 lead,do,review,再按风险补 research/planning/content/data/auto/security/finance。

地基选择

协作层依赖“能让部门读懂目标和边界”的项目地基,但地基不等于固定的软件目录。

处理顺序:

先看项目里是否已有可用地基:如 docs/、业务方案、项目说明、交付清单、进度/交接文件、行业专用目录。已有时按现有地基规划部门职责和可写范围,不要强行改成软件结构。
若是互联网产品、软件、Vibe Coding 或明确有 app/ design/ docs/spec.md 这类产物,才优先建议或使用 vibe-project-foundation。
若是课程、内容、运营、咨询、线下交付、调研、内部流程等非软件项目,先找是否有对应专用业务地基 Skill 或现有模板;有就使用它。
若没有专用地基,不要停在“请先装某个软件地基”。先问清目标业务、最终交付物、验收标准、过程资源、风险/复核方式,然后创建最小业务地基。

最小业务地基只包含能支撑协作的通用文件:

docs/overview.md:项目目标、交付物、服务对象/使用对象、边界。
docs/progress.md:当前阶段、已完成、进行中、下一步。
docs/agent-guide.md:本项目协作规则、文件分工、注意事项。
必要时按业务创建 deliverables/、materials/、research/、operations/、scratch/ 等目录;不要创建无关的软件目录。

推荐团队时给出:

三层各有哪些部门,以及命中依据。
每个部门的职责、禁止事项、输入、输出、可写范围、禁止写入范围。
跨部门路由:澄清直连还是经统筹。
哪些节点必须用户确认。
会话创建模式:自动创建会话 或 手动创建会话窗口,以及对应执行步骤。

创建前停下确认:

我建议按以上团队配置创建 docs/collaboration/,会话模式为【自动创建 / 手动创建】。你确认吗?

创建协作层

确认后运行脚本。若没有专用地基且用户确认由本 Skill 补最小业务地基,加 --create-minimal-foundation --allow-without-foundation。默认通用最小盘:

python3 <skill目录>/scripts/scaffold_team.py "<目标项目目录>" \
  --profile "<团队诊断摘要>" \
  --session-mode "manual"

按诊断展开时显式传角色:

python3 <skill目录>/scripts/scaffold_team.py "<目标项目目录>" \
  --profile "软件 + 数据强 + 涉隐私/平台 + 有预算" \
  --roles "lead,product,design,dev,data,test,security,finance" \
  --session-mode "auto"

可选角色:

管理层:lead
执行层:do/research/planning/product/design/dev/data/auto/content/growth
审核层:review/test/security/finance

脚本会创建 docs/collaboration/README.md、部门表.md、会话启动清单.md、读取路由规则.md、错题集.md、任务交接模板.md、专项结论/、scripts/agent_team_read.py 和 部门/<部门名>/ 下的 岗位说明.md、上岗引导.md、交接班文档.md、收件箱.md、报告/、日志/<ISO周>.md;审核层另有兼容旧名的 把关报告/(语义为审核报告)。脚本拒绝覆盖已有协作层,拒绝重复角色,拒绝缺少管理层/执行层/审核层的全新团队;未传 --session-mode auto/manual 时会中止,防止绕过会话模式确认。

会话创建模式

自动创建会话(Codex / 有会话管理工具)

用户确认采用自动模式后:

先运行脚本创建 docs/collaboration/。
用 tool_search 搜索 create_thread、send_message_to_thread、set_thread_title 三类会话工具;置顶、排序不是必要能力。
工具可用时,为每个部门创建一个会话;标题建议用数字前缀保持顺序,如 01 统筹部、02 产品部、03 开发部。
把每个部门的 上岗引导.md 作为初始化消息发给对应会话,要求该会话先接班,只汇报职责 / 阶段 / 进行中 / 收件箱 / 待确认问题,不要立刻做业务任务。
把返回的会话 ID 写入 docs/collaboration/部门表.md,并把通知模式登记为 自动。若发送工具失败,本部门通知模式改为 人工,并向用户说明没有完成自动建会话。
最后向用户汇报:已创建哪些会话、哪些会话 ID 已登记、哪些需要用户手动处理。

如果工具不可用或调用失败,不得说“已创建会话”;改为手动模式收尾。

手动创建会话窗口(其他 Agent / 无会话管理工具)

用户确认采用手动模式后:

只运行脚本创建 docs/collaboration/ 和各部门文件。
不调用会话工具,不声称创建了会话。
输出手动上岗清单:每个部门对应的 上岗引导.md 路径、建议窗口名、需要用户粘贴给该会话的第一句话。
docs/collaboration/部门表.md 的会话 ID 保持 待登记,通知模式保持 待登记 或按用户说明改为 人工。
用户手动创建好窗口后,把各部门 上岗引导.md 发给对应会话;部门会话先运行 docs/collaboration/scripts/agent_team_read.py onboard --dept 【部门名】,再按脚本返回的必读文件读取岗位说明、交接班、错题集、收件箱,之后所有交接都写对应部门文件夹的 收件箱.md。

创建后检查:

docs/collaboration/ 结构完整,三层至少各一个部门。
docs/agent-guide.md 已追加多会话协作说明。
docs/collaboration/会话启动清单.md 已写明自动/手动模式和每个部门的上岗入口。
自动模式下,部门表.md 已登记实际会话 ID 和通知模式;手动模式下,已明确提示用户会话尚未创建。
docs/progress.md 记录协作层创建、团队配置摘要、下一步。
git status --short;若只有本次协作层相关变更,可单独提交:

git add docs/agent-guide.md docs/progress.md docs/collaboration
git commit -m "chore: 搭建多会话协作层"

若仓库已有其他未提交变更,不要混提交,向用户说明。

维护模式

后续可能要新增/合并/删除部门、替换会话、登记会话 ID、调整边界、派活或独立把关。处理原则:

先读 docs/collaboration/部门表.md,确认现有三层和部门。
判断是否破坏“三层至少各一个”或职责边界。
涉及新增/删除/替换部门、跨会话消息、放行、返工、状态升级,先让用户确认。
加部门用 scaffold_team.py <项目> --add-roles "<ids>";脚本只补建缺失部门并追加部门表,仍需人工同步受影响流转规则。
减/合并部门时,先把在办事项和历史交代进日志,再更新部门表和相关岗位说明;不要直接删历史。
通知能力登记只在上岗/接班时做一次:
- 读 部门表.md 的本部门“通知模式”。若已登记为 自动 或 人工,本会话后续都按该模式执行,不要每次任务完成都重新探测工具。
- 若通知模式是 待登记,有 tool_search 时搜索 send_message_to_thread 等发送工具;没有 tool_search 或搜不到发送工具,登记为 人工。
- 自动:后续通知默认直接调用会话发送工具发短唤醒,不再预先做能力检查。
- 人工:后续通知默认直接给用户可复制的短唤醒,请用户手动提醒目标部门。
- 若自动模式实际调用失败,本次回退为人工提醒,并请用户通知统筹部更新 部门表.md。
- 若用户发现 Agent 工具能力变化,让用户告知统筹部会话,由统筹部更新 部门表.md 的通知模式。
读取路由优先:
- 新部门会话或接班优先运行 python3 docs/collaboration/scripts/agent_team_read.py onboard --dept 【部门名】,让脚本返回本部门身份、通知模式、必读文件和默认阅读边界。
- 报告、审核报告、专项结论、关键决策都用 YAML frontmatter 写 type / department / target / status / date / related_task / decision / tags / summary;脚本只返回这些人工预写字段,不做创造性总结。
- 查证据前优先运行 agent_team_read.py find --type audit_report --status blocked、agent_team_read.py find --type special_conclusion --tag 用户可见出口 或 agent_team_read.py meta <path>;只有摘要不足、路径异常、结论冲突、涉及放行/返工/安全/费用/发布/用户可见质量、用户要求查证据、当前任务明确依赖正文时,才读取最小必要正文。

AidenXu-1/agent-team-skill

Ask in your favorite AI

문서