fix(core): subordinate the coordinate skill's teammate count to the configured cap - #9403
Conversation
…onfigured cap The skill stated an absolute "one to three" while the real ceiling is `agents.team.maxTeammates` (default MAX_TEAMMATES = 10), enforced by a throw in spawnTeammate. team_create's own prompt already derives its number from the setting; the skill did not, so lowering the cap to one or two left the skill instructing a spawn that fails outright. Express the guidance relative to the cap rather than as a second absolute, and give the reason for preferring few teammates — past roughly three the leader spends more of its turn reconciling reports than working. Refs #9399
|
Thanks for the PR! Template: the substantive sections are all present and well filled in — what it does, why it's needed, and a reviewer test plan with before/after evidence. The boilerplate Problem: real, and I verified it against the code rather than taking the description's word. The binding ceiling is Direction: aligned. A self-consistency fix inside the agent-team feature, which is under active development (claude-code's CHANGELOG carries a steady stream of teammate-related entries). No direction concerns. Size: not applicable — one Markdown skill file, 3+/3-. It lives under Approach: minimal and exactly on goal. All three absolute-count statements are rewritten (frontmatter description, spawn step, bounded-coordination bullet) and nothing else is touched. The new wording also supplies the rationale for preferring fewer teammates that the old text asserted without support. Nothing I'd cut. Risk: no elevated risk signals (no high-risk path matches). Moving on to code review. 🔍 中文说明感谢贡献! 模板:核心章节齐全且填写完整——做了什么、为什么需要、以及带 before/after 证据的 reviewer test plan。样板章节 问题:真实存在,已对照代码核实而非仅凭描述。真正的上限是 方向:对齐。这是 agent-team 功能内部的自洽性修复,该功能正在活跃开发中(claude-code 的 CHANGELOG 有大量 teammate 相关条目)。无方向性问题。 规模:不适用——单个 Markdown skill 文件,3+/3-。文件位于 方案:最小改动,完全围绕目标。三处写死的人数表述全部改写(frontmatter 描述、spawn 步骤、bounded-coordination 条目),未触碰其他内容。新文案还补上了"为什么人少更好"的理由(旧文案只断言不论证)。没有可砍的部分。 风险:无升级风险信号(未命中高风险路径)。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewMy independent take before reading the diff: rewrite the absolute "three" statements so the configured cap is the binding constraint (keeping roughly three as a soft recommendation), and fix the frontmatter description that also hardcodes "up to three". The PR does exactly that — nothing more. Every claim in the description checks out against the code:
No code paths change, no blockers, no convention violations. The claim under review is what the skill says, and that is fully verified above; a docs-style wording change gives an A/B or sandboxed lane nothing behavioural to settle. TestingCI signal on the reviewed commit, fetched via API (never running PR code here). CI classified this commit as docs-only, so the heavy matrix is skipped by design and the ubuntu job runs the classifier/gate path: Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行(取最新一次运行),省略 skipped,失败项排在最前。 The 中文说明代码审查读 diff 前的独立方案:把写死的"three"改写为以配置上限为准(保留大约三个的软建议),并修正同样写死"up to three"的 frontmatter 描述。PR 的做法与此一致,且没有任何多余改动。 描述中的每项声明都已对照代码核实:
无代码路径变更、无阻塞问题、无规范违反。本次审查的对象是 skill 的表述内容,已在上文完整核实;docs 类措辞变更没有 A/B 或沙箱通道可以验证的运行时行为。 测试CI 信号来自 API 拉取(此处从不运行 PR 代码)。该提交被 CI 分类为 docs-only,因此重型矩阵按设计跳过,ubuntu 任务只跑分类/门槛步骤。 — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 5/5 — minimal wording fix from a maintainer, every factual claim verified against the code, and nothing in the diff can break a code path. Stepping back: this is the kind of small fix that's easy to eyeball and hard to fault. The skill and the runtime disagreed about who sets the teammate ceiling; the PR makes the runtime's configured number binding and keeps "roughly three" as a recommendation — now with the reason attached, which the old text lacked. Every claim checks out (cap default 10, spawn-time throw, Approval deferred until CI lands green on 中文说明置信度:5/5 —— 维护者提交的最小化措辞修复,每项事实声明均已对照代码核实,diff 不影响任何代码路径。 整体来看:这是一个无可挑剔的小修复。skill 与运行时在"谁决定 teammate 上限"上互相矛盾;PR 让运行时的配置值成为硬约束,并把"大约三个"保留为软建议——现在补上了旧文案缺失的理由。每项声明都与代码一致(默认上限 10、spawn 时 throw、 批准将延迟到 CI 在 — Qwen Code · qwen3.8-max Reviewed at |
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed. Suggestions are inline.
Not reviewed: reverse audit — stopped before round 3 by the review time budget.
— qwen3.8-max via Qwen Code /review (v0.21.13)
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Partially reviewed — gaps disclosed. Suggestions are inline.
2 Suggestion-level finding(s) this review confirmed are already reported on this PR and are not repeated:
- R1-1 "configured cap" not configurable through user settings — already reported at packages/core/src/skills/bundled/coordinate/SKILL.md:17 (comment 3803935495)
- R1-3 companion docs page still states the absolute "up to three" bound — already reported at packages/core/src/skills/bundled/coordinate/SKILL.md:17 (comment 3803935531)
Not reviewed: reverse audit — stopped before round 1 by the review time budget.
— qwen3.8-max via Qwen Code /review (v0.21.13)
|
Closeout summary for exact head
中文摘要PR body 已按最新模板整理,保留原有证据、明确尚未进行 live 验证并补齐中文。没有扩展运行时逻辑;取消的 |
|
Released in v0.22.2. |
What this PR does
Makes the bundled
coordinateskill express its teammate count relative to the configured cap instead of stating a second, independent number.The real ceiling is
agents.team.maxTeammates, defaulting toMAX_TEAMMATES = 10, enforced byTeamManager.spawnTeammate. Theteam_createworkflow prompt already derives its number from that setting. The skill did not: it said "one to three" and "no more than three for this workflow" as absolutes.The skill now says one teammate per workstream, prefer three at most, and never exceed the configured cap that
team_createreports. It also explains why fewer is preferred: past roughly three, the leader spends more of its turn reconciling reports than doing the work.Why it's needed
A hard ceiling and a workflow recommendation are different kinds of statement. Setting
agents.team.maxTeammatesto 1 or 2 left the skill instructing the model to spawn up to three, which fails at spawn time withMaximum number of teammates (N) reached.and forces recovery mid-workflow.Stating the rationale matters for the same reason: a model told only "no more than three" may trade the rule away under pressure, while a model told what degrades can make the correct tradeoff.
Reviewer Test Plan
Reviewers should confirm the skill treats the configured cap as binding while keeping three teammates as a preference rather than a second hard limit.
How to verify
packages/core/src/skills/bundled/coordinate/SKILL.mdand confirm no absolute teammate count is stated as a rule, and that the configured cap is named as the binding constraint.agents.team.maxTeammatesto2, run/coordinateon a goal with three obvious workstreams, and confirm the leader spawns at most two rather than attempting a third and handling a spawn failure.No runtime code paths change;
MAX_TEAMMATES, the setting, and thespawnTeammateguard are untouched. The behavioral scenario is not yet verified in a live run.Evidence (Before & After)
Before:
After:
Tested on
Environment (optional)
Not applicable.
Risk & Scope
Documentation-only change to the bundled
coordinateskill. It does not alter runtime limits, settings, tool schemas, or spawn enforcement.Linked Issues
Not applicable; this is a documentation consistency correction.
中文说明
本 PR 做了什么
让 bundled
coordinateskill 按已配置上限描述 teammate 数量,而不是再声明一个独立数字。真正的硬上限是agents.team.maxTeammates,默认值来自MAX_TEAMMATES = 10,并由TeamManager.spawnTeammate强制执行;team_create的 workflow prompt 已经从该设置派生数量,但 skill 之前把“一到三个”和“本工作流不超过三个”写成绝对规则。现在 skill 改为:每个 workstream 一个 teammate,通常优先不超过三个,同时绝不能超过
team_create报告的已配置上限。它也说明少量 teammate 的原因:大约超过三个后,leader 会把更多回合花在整合报告而不是推进工作。为什么需要
硬上限和工作流建议并不是同一种规则。当
agents.team.maxTeammates设置为 1 或 2 时,旧 skill 仍会指示模型最多创建三个 teammate,第三次 spawn 会报Maximum number of teammates (N) reached.,迫使模型在流程中途恢复。说明理由也能帮助模型在压力下保持正确取舍,而不是把没有依据的数字规则随意放弃。
Reviewer 测试计划
Reviewer 应确认:已配置上限始终是绑定约束,“三个”只是一项偏好而不是第二个硬限制。
如何验证
packages/core/src/skills/bundled/coordinate/SKILL.md,确认没有把固定 teammate 数写成绝对规则,并明确配置上限为最终约束。agents.team.maxTeammates设为2,对三个明显 workstream 运行/coordinate,确认最多创建两个 teammate,不会尝试第三次 spawn 后再恢复。运行时代码未变化,
MAX_TEAMMATES、设置项和spawnTeammateguard 均未修改;live 行为场景尚未验证。前后证据
修复前把“一到三个”和“不超过三个”写成绝对规则;修复后改为每个 workstream 一个、通常优先三个以内,并明确绝不能超过
team_create报告的配置上限。测试平台
macOS、Windows 与 Linux 均尚未进行 live 行为验证。
风险与范围
仅修改 bundled
coordinateskill 文档,不改变运行时限制、配置、工具 schema 或 spawn 强制逻辑。关联 Issue
不适用;这是文档一致性修正。