chief-of-staff

1. Bilingual SKILL.md

左右滑动可直接切换英文版与中文版；两种语言按段落自动对齐。英文中的蓝色虚线词语可点击查看解释。共标记 12 处。

Entry SHA-256: f91be032f9eec977e3e349fce33e20f768b7767c603491351d9efa3e358a2f40

2. Why This Skill Is Clever

一句话核心机制

chief-of-staff 把主会话定义为长期战略记忆与决策中枢，把所有战术执行隔离到子智能体，并用可复核的上下文指针压缩双向沟通。

触发与边界

• Direct source： frontmatter 中的 disable-model-invocation: true 表明它必须由用户主动调用，不能由模型隐式启动。
• Supporting context： agents/openai.yaml 同时设置 allow_implicit_invocation: false，在另一套 harness 策略中重复确认同一边界。
• Direct source： 适用对象是“a long-running goal”，而不是一个可直接完成的短任务。
• Direct source： “All work should be done in subagents”把主会话限制为战略协调者，不承担战术执行。
• Supporting context： 该路径位于 skills/in-progress/，仓库规则将其定义为 beta、未随插件发布且可能随时变化；本次报告据此标为 Beta。

信息架构 / 执行顺序

1. 先建立长期身份：主会话是 chief of staff，负责积累跨阶段知识和长期决策。
2. 再切分责任：主会话拥有战略全局，子智能体拥有战术与一线观察。
3. 在 harness 支持时引入周期性计划，让长期目标获得重复执行节奏。
4. 把所有实际工作放进子智能体，避免主会话被日志和实现细节吞没。
5. 用研究笔记、历史提交等 context pointers 回传证据，只传必要结论，不复制已有材料。
6. 每轮工作都反观执行环境，通过增加或修剪约束来改善后续结果。

最巧妙的设计点

1. “You own the strategic view” 对照 “Your subagents own the tactical, on-the-ground view”
   - Direct source： 权责不是按任务列表切，而是按决策层级切。
   - Interpretation： 这让主会话持续承担取舍与方向一致性，同时让专业执行在隔离上下文中展开，避免 Owner 退化成只派单、不负责结果的调度器。

2. “All work should be done in subagents. Protect your context window.”
   - Direct source： 对委派采用强约束，而不是“需要时可以委派”的软建议。
   - Interpretation： 极端规则让长期会话的稀缺资源得到优先保护；代价是非常短、低风险的动作也必须委派，可能增加通信成本。

3. “Communicate primarily through context pointers”
   - Direct source： 研究笔记和历史提交是首选通信载体。
   - Interpretation： 指针让证据保留在其原始载体中，可由后续智能体复核，也避免摘要被多次转述后逐渐失真。

4. “Don't duplicate information already available via pointers”
   - Direct source： 不只要求使用指针，还禁止重复传输指针后的内容。
   - Interpretation： 它把“节省上下文”变成可执行的不变量；但委派 brief 仍必须包含目标、边界和验收标准，否则指针会退化成让子智能体自行猜测的资料堆。

5. “Restrictions lead to better results. You are the gardener of this environment.”
   - Direct source： chief of staff 还负责持续改善智能体所处环境。
   - Interpretation： 它把学习闭环从“记住经验”推进到“改造约束”：修剪错误自由度、补充检查与导航，让下一次执行从更好的土壤开始。

防失败机制与 trade-off

• 显式不变量： 战略归主会话、战术归子智能体；实际工作全部委派；沟通保持稀疏；已有指针可达的信息不重复复制。
• 防失败机制： disable-model-invocation 与 allow_implicit_invocation: false 双重限制，避免一个昂贵、长寿命的协调模式被模型随意开启。
• Trade-off： 强制“所有工作都在子智能体完成”能保护上下文，却可能在简单动作上付出比直接执行更高的委派与验证成本。
• Trade-off： tribal knowledge 被累积在长会话里，如果没有同时沉淀到持久笔记和提交，主会话一旦丢失就会成为单点故障。
• 可移植性风险： schedules、长会话和 subagents 都依赖 harness；“Harness-permitting”只说明可以建议计划，不等于系统有权创建或持续运行计划。
• Beta 风险： 仓库的 in-progress 规则明确该技能可能更改或消失，因此当前责任划分适合作为实验设计，不应未经验证直接当作稳定生产协议。

可迁移原则

1. 按决策层级定义 Owner 与执行者，而不是把 Owner 写成任务转发器。
2. 为长期会话设置明确的上下文预算，执行细节放到隔离环境，主会话只保留决策与关键证据。
3. 用持久、可复核的上下文指针传递证据，避免反复复制和有损转述。
4. 把环境改进列为每轮工作的固定检查项，让经验最终变成约束、工具或检查。
5. 对依赖 harness 的能力显式加条件，不把“建议调度”冒充“调度已生效”。

今日实践题

如果一个长期项目今天只有一项 10 分钟、低风险且容易验证的修改，你会严格遵守“所有工作都由子智能体完成”，还是为 Owner 设计一个直接执行例外？请写出例外的边界与验证条件。

Evidence note

角色分工、调度条件、子智能体规则、context pointers 和环境园丁隐喻均来自本次选中的 chief-of-staff/SKILL.md。agents/openai.yaml 只用于确认隐式调用策略，skills/in-progress/README.md 只用于确认 Beta 发布状态；二者都没有被当作选中原文。关于委派成本、单点故障和持久化的判断属于设计解读。