context-manager

上下文管理器

健康区间（请先阅读）

此技能会根据健康窗口（即“智能区间”）来评估上下文，而不是模型的原始上下文窗口。

原始窗口可能有 200k 或 1M，但模型质量会在窗口填满前很久就开始下降（即上下文退化）。默认情况下，智能区间为 150k 个 token：在这个范围内，回忆、推理和遵循指令的能力都能保持敏锐。超过此范围后，无论窗口还剩多少空间，质量都会下降。因此，智能区间内的每个 token 都是黄金——这是你实际能够做好工作的预算，而此技能的目的就是尽可能减少启动开销对这部分预算的占用。

此处所有百分比、判断和进度条都以智能区间为基准，而非原始窗口。

健康窗口设置（所有模式均使用）。 智能区间的大小保存在 ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/context-manager.json 的 healthy_window_tokens 中。在任何模式开始时，都要运行随附的辅助脚本（与此 SKILL.md 位于同一目录）读取该值：

bash scripts/read-window.sh   # prints the token count, default 150000

如果使用默认的 150k，请明确说明（并说明模式 4 可以更改此设置）。如果用户设置了自定义值，则在所有地方使用该值并提及。

四种模式

选择与用户请求相符的模式；如果不明确，请使用以下确切标签询问用户要选择哪一种：

1. 分析启动上下文 — 会话开始时加载了什么、占用最多的项目，以及相对于智能区间的判断。
2. 清理上下文 — 关于如何释放智能区间空间的建议。请参阅 CLEANUP.md。
3. 状态栏模板 — 4 个可直接使用的模板，或自定义模板。请参阅 STATUSLINE.md。
4. 设置健康窗口大小 — 更改此技能用于衡量上下文的智能区间阈值。

未经用户确认，此技能绝不会运行 /clear、/compact，也不会编辑用户设置——这些操作由用户决定。

模式 1 — 分析启动上下文

目标：报告启动上下文总量、占用最多的 5 个组成部分、它们占用智能区间的比例，以及是否值得清理。

步骤 1 — 获取最新的 /context 明细

读取健康窗口 HW（scripts/read-window.sh）。然后从 /context 获取明细——此技能无法自行运行 /context，因此：

• 如果此对话中已显示 /context 明细，请解析该明细。
• 否则，请用户运行 /context（即时且免费），并等待结果。告诉用户然后发送“ok”或“continue”——输出只有在用户发送下一条消息时才会进入对话。如果不提示这一点，用户就会一直等待，误以为技能没有执行任何操作。

从结果中解析总量（X / Y tokens）以及每个类别：System prompt、System tools、MCP tools、Memory files、Skills、Messages、Free space。不要根据文件大小估算——/context 才是准确依据，用户多按一个键也胜过猜测。

步骤 2 — 对每个组成部分进行分类

• 固定项（无法缩减）：System prompt、内置的 System tools。
• 可调整项（可采取措施的项目）：MCP tools、Skills、Memory files、自定义 CLAUDE.md/AGENTS.md/全局规则。

步骤 3 — 对照智能区评估

所有计算都应以 HW 为基准，而非原始窗口：

• 启动时已占用的智能区 = 启动 Token 总数 ÷ HW。
• 剩余智能区空间 = HW − 启动 Token 总数（留给实际工作的宝贵空间）。
• 为便于排序，计算各组件占启动总量的百分比；并计算可自由调整部分占 HW 的百分比。

评估可自由调整的负载——也就是你可以控制的部分；每个 Token 都会在任何工作开始前消耗智能区预算（以下阈值以 150k 智能区为基准；请按 HW 缩放）：

可自由调整的启动负载	评估
< 10k Token（约占智能区的 7%）	精简 — 无需采取行动。
10k–25k Token（约占 7–17%）	适中 — 检查每个 MCP 服务 / 技能是否确实会用到。
> 25k Token（>17%）	偏重 — 精简；参见 CLEANUP.md。

然后，根据智能区占用标准检查总量上下文（即核心数字——它适用于整个会话，而不只是启动时）：

智能区占用率（总量 ÷ HW）	状态
< 50%（< 75k）	充足 — 质量不受影响，剩余空间充裕。
50–80%（75k–120k）	留意 — 计划在下一个大型任务前运行 /compact。
80–100%（120k–150k）	拥挤 — 继续进行繁重工作前，请压缩或清空上下文。
> 100%（> 150k）	超出智能区 — 可能出现上下文退化；立即运行 /clear 或 /compact。

提醒用户：启动负载只计算一次，而且适合缓存，但会永久压缩本次会话的智能区可用空间。会话中途影响更大的因素是对话增长（/compact 或 /clear），详见模式 2。

步骤 4 — 报告

简洁输出：

• 智能区：HW Token（注明是默认值还是用户设置）。
• 启动上下文总量：N Token — 占智能区的 P%，剩余约 H Token 的可用空间。
• 占用最多的 5 个组件，使用表格展示：组件 | Token 数 | 占总量的百分比 | 固定 / 可自由调整。
• 评估：可自由调整负载的评估结果 + 智能区占用状态 + 1–3 条具体、可执行的建议（例如“按需加载 context7 MCP — 很好”；“5 个未使用的技能占用了约 Xk 的宝贵 150k 空间 — 考虑移除”）。

模式 2 — 清理上下文

首先读取 HW。此模式需要 /context 明细来确认实际加载的内容：如果本次对话中已经显示了明细（例如来自模式 1），就使用它；否则请用户运行 /context 并等待——规则与模式 1 相同（包括提示用户回复“ok”或“continue”后再继续）；绝不要到其他地方查找。然后打开 CLEANUP.md。将所有内容定位为释放智能区空间：每项修复都能在 HW 下腾出宝贵的 Token 空间。逐一检查 10 个目标，标出适用于本次会话的目标（如果有模式 1 的调查结果，请加以利用），并优先推荐影响最大的修复。执行任何破坏性操作前都要确认——尤其是不可逆的 /clear。

模式 3 — 状态栏模板

打开 STATUSLINE.md。提供 4 种模板（精简 / 扩展 / 智能区进度条 / 仪表盘），也可以提供自定义模板。优先推荐智能区进度条，让状态栏根据 HW（默认 150k）而非原始窗口显示颜色——否则，即便 1M 窗口已用到 140k，状态也会显示为绿色，从而掩盖上下文退化。模板已打包为 scripts/ 下可直接运行的脚本；仅在向用户说明将发生的更改后才应用。

模式 4 — 设置健康窗口大小（智能区）

**目标：**让用户更改其他模式据以衡量的智能区阈值，并将其持久化。

1. 读取并报告当前值（scripts/read-window.sh）。说明它是默认的 150k 还是用户设置的，并用一句话说明其含义：“低于此值时，质量保持出色；超过此值后，上下文腐化会降低输出质量。”
2. **获取新值。**如果用户已提供数字，就使用该数字。否则提供以下选项：
   • 150k（默认，推荐） — 标准智能区，大多数模型在此范围内都能保持质量。
   • 120k（保守） — 适用于较长且注重细节的工作，可更早清理或压缩。
   • 200k — 适用于你观察到质量能维持更久的模型或任务。
   • 自定义 — 任意 token 数量。 接受 150k/150000 这样的简写，并将其规范化为 token 整数。拒绝非正数或不合理的值（< 10000 或 > 原始窗口），并再次询问。
3. 确认后，通过运行辅助脚本写入（保留其他键；如果缺少 jq，则回退到新建文件）：

   bash scripts/set-window.sh <tokens>
   

4. 确认结果：新的智能区为 N tokens，现在将用于驱动模式 1–3。询问是否要根据新阈值重新运行模式 1。