meeting-facilitate
用 meeting_* 工具跑一场多 Agent 会议:创建 → 亲自 spawn 参与者 → 推进轮次 → 签到 → conclude…
AI Team OS 里用 CC 内置 Workflow 的两件事:产出回写 OS 的标准模板(§1-2、§4),以及审查分级与派工档位纪律(§3/§3.1)。准备调用 Workflow 编排子 agent 时,或要判定一件事该按 L0/L1/L2 哪一档审查(含「这活要不要开 workflow」)时使用。
Claude Code
$ npx -y skills add CronusL-1141/AI-company --skill os-workflow --agent claude-code
Codex
$ npx skills add CronusL-1141/AI-company --skill os-workflow -a codex -y
Cursor
$ npx skills add CronusL-1141/AI-company --skill os-workflow -a cursor -y
Gemini CLI
$ npx skills add CronusL-1141/AI-company --skill os-workflow -a gemini-cli -y
GitHub Copilot
$ npx skills add CronusL-1141/AI-company --skill os-workflow -a github-copilot -y
OpenCode
$ npx skills add CronusL-1141/AI-company --skill os-workflow -a opencode -y
Windsurf
$ npx skills add CronusL-1141/AI-company --skill os-workflow -a windsurf -y
name: os-workflow description: AI Team OS 里用 CC 内置 Workflow 的两件事:产出回写 OS 的标准模板(§1-2、§4),以及审查分级与派工档位纪律(§3/§3.1)。准备调用 Workflow 编排子 agent 时,或要判定一件事该按 L0/L1/L2 哪一档审查(含「这活要不要开 workflow」)时使用。
调用 Workflow 后,每个内部 agent 会被 hook 自动注册成一个 OS 团队(`workflow-<wf_id>`, 一次 workflow = 一个团队)。追踪是自动的,但**工作内容不会自己入库**——下面两件事必须你做。
调用 Workflow **前**用 `task_create` 把这次工作方向登记上墙并置 running(§2 的回写指令要把它的 id 插进每个 agent 的 prompt,事后补建来不及),完成后 `task_update` 置 completed 并填 result。
把下面这段**粘进你写的 workflow 脚本里每个 `agent()` 的 prompt 末尾**(已验证 workflow agent 能调 OS 的 MCP 工具 + HTTP API,非沙盒):
【回写 OS(收尾必做)】 1. ToolSearch 加载:select:mcp__ai-team-os__task_memo_add,mcp__ai-team-os__report_save 2. 完成本职工作后: - task_memo_add(task_id="<总任务id>", content="<这步干了啥+关键结论>", memo_type="progress") - 重要产出再 report_save(...) 落库,并把 report_id 写进 memo 3. 你在项目目录运行,MCP 自动带项目头,无需关心端口/项目 id。
在脚本里把 `<总任务id>` 用第 1 步 `task_create` 拿到的 id 通过 prompt 字符串插值传进去。
// Leader 先 task_create 拿到 taskId(OS MCP),再写 workflow:
const WRITEBACK = `\n【回写 OS(收尾必做)】\n1. ToolSearch: select:mcp__ai-team-os__task_memo_add\n2. 完成后 task_memo_add(task_id="${taskId}", content="...", memo_type="progress")\n3. 项目目录运行,MCP 自动带项目头。`
const r = await agent('你的实际任务……' + WRITEBACK, { schema, label })不传 model 即继承主会话模型,所以每个 `agent()` 都**显式写 `model`**(层级别名如 `'opus'`、`'fable'`,浮动到最新,不写死型号)。选哪一档按使用者自己的派工策略(写在项目 CLAUDE.md 或用户规则里),本技能不预设档位。
// 每个 stage 显式写 model;用 fable 的那处配一条理由注释
const found = await parallel(ITEMS.map(x => () =>
agent(findPrompt(x) + WRITEBACK, { model: 'opus', schema: FINDINGS })))
// fable 理由: <这一步为什么要用这一档>
const verdict = await agent(judgePrompt(found) + WRITEBACK,
{ model: 'fable', effort: 'xhigh', schema: VERDICT })注:`effort` 与档位同按使用者自己的派工策略设(`agent()` 的 `effort?: 'low'|'medium'|'high'|'xhigh'|'max'`,省略即继承会话档位),S6 不校验 effort。**模型档位则是硬约束**:S6 对缺省 model、fable 无理由一律 `exit(2)` 拦下(见上一条)。
实证(0905 单日):133 个 agent 产出 274 万 token 却读了 2.02 亿缓存(74:1)——钱花在重复读同一批全文上,不是花在干活上。
**总原则**:限制的是「把任何问题都按最复杂方式做完」,不是把复杂问题做简单;**审查强度按风险定,不按预算定**——L2 该全文对抗就全文,省的是重复读、多余的镜头与反驳者、多余的轮次。**分级在前,模式在后**:ultracode 常开≠事事开 workflow(用户习惯常开;它的字面定义「每个实质任务都开 workflow」照做就是给每件事按最贵的价做),L0/L1 直接做,只有 L2 才开;开了也按下面七条控人数与读量。
1. **机检先行。** 哈希、数字一致性、措辞残留、编号连续、禁用字符、格式,凡能写成命令的检查先跑脚本,零 token 秒出。agent 只处理脚本查不了的:逻辑、措辞立不立得住、设计取舍。 2. **审查分级。** 派出的活按风险分三档,档位决定审不审、怎么审:
3. **反驳者配额。** 每条发现 1 个反驳者;它说"是真的"即接受,说"是假的"才加第二个复核(假反驳比假确认贵)。反驳者的档位按派工策略定;机械类发现(数字、哈希)用执行档即可。 4. **审查给定位。** prompt 写"看第 X 节,参照第 Y 行",禁止默认"读全文加全部参照文档"。多镜头并行时先按镜头切分对象,重叠的发现在派出前合并。 5. **停机规则。** 一轮折入后先跑机检;只有上一轮还剩脚本查不了的判断级 blocker 才开下一轮 agent 审查,否则一个终审即止。 6. **回传上限。** 执行者只回变更清单、验证结果、决策与风险,≤300 字;工具输出、调试记录、中间上下文用完即弃,不回传。 7. **Leader 不在大上下文里逐条改大文档。** 一份文档超过十处改动,Leader 写成改动清单(定位 + 旧文 + 新文 + 理由)派一个 opus 在小上下文里执行,或整节 Write 一次;Leader 只亲手改一两处。实锤:0905 Leader 70 次 Edit 各在 40 万 token 上下文里重读,1.27 亿缓存读比子 agent 总和还多一半。
// 分级示例:L2 全文对抗 = 一个审稿人 + 每条发现一个反驳者,被反驳才二审
const findings = await agent(reviewPrompt(SECTIONS), { model: 'opus', schema: FINDINGS }) // 定位到章节
const verified = await parallel(findings.map(f => () =>
agent(refutePrompt(f), { model: 'opus', schema: VERDICT })
.then(async v => v.refuted
? { ...f, votes: [v, await agent(refutePrompt(f), { model: 'opus', schema: VERDICT })] } // 被反驳才二审;此处档位按你的派工策略
: { ...f, votes: [v] })))给 agent 配 `schema` 时,prompt 里必须写**显式体量硬约束**(每字段字符上限、条目数上限、"宁可精炼不可超限")——只靠 schema 的 `maxLength` 拦不住:agent 超限会陷入 StructuredOutput 重试循环,耗尽重试上限(5)后整路阵亡返回 `null`。
Multi-agent team operating system for Claude Code. 108 MCP tools, 40+ agent templates, 10 lifecycle hooks, 7 pipeline workflows. Persistent teams, structured meetings, task wall, real-time React dashboard. No LangChain/AutoGen — pure CC native integration.
用 meeting_* 工具跑一场多 Agent 会议:创建 → 亲自 spawn 参与者 → 推进轮次 → 签到 → conclude…
你被派来参加 AI Team OS 会议(派你的 prompt 里带 meeting_id),且要在 Round 2 及之后发言时用:怎么拿到自己的 agent_id、怎么引用前人发言、round_number 怎么填。Round 1…
CC 与 Codex(或两个各自独立运行的 CC 会话)之间用 OS 信道留言、查未读、被新消息唤醒。触发:要跨 harness 把结论交给对端、给对端留言或清未读、用户问"能不能让 Claude 和 Codex 互相沟通"。不适用于派子 agent 或…
发布 AI Team OS 新版本的完整清单——预检、版本七处锁步、中英双语 CHANGELOG、双份 dist 构建、私有术语扫描、commit/tag、双仓推送、建 GitHub Release 条目并核对 latest…
Direct browser control via CDP for web interaction: automation, scraping, testing, screenshots, and site/app work. Also covers…
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling…