context-budget
作者 affaan-mcontext-budget 技能会审计 Claude Code 在 agents、skills、rules 和 MCP servers 中的上下文使用情况。它能帮助识别臃肿内容、重复内容和高成本组件，并返回按优先级排序的清理建议。这个 context-budget 指南适合需要实际使用 context-budget 的场景，以及更大规模环境中的 Skill Testing。
该技能得分 78/100，属于很有价值的目录收录候选：它定义了一套可复用的 Claude Code 上下文消耗审计工作流，并为 agent 提供了识别 token 膨胀的具体启发式方法；但它仍主要是文档驱动流程，缺少配套自动化和安装说明。
- 触发条件清晰：技能明确说明了适用场景，包括会话变慢、组件近期增多，以及显式的 `/context-budget` 命令。
- 流程实用：它按阶段覆盖 agents、skills、rules 和 MCP servers 的分析，并给出具体阈值，例如大文件、冗长描述以及每个工具的 schema 估算开销。
- 安装决策价值高：仓库证据显示，非占位式的 SKILL.md 中包含大量工作流内容，并提供了以回收上下文余量为目标的实用建议。
- 执行仍需要人工判断，因为没有脚本、参考文件或自动化辅助来稳定完成审计。
- 部分分析依赖粗略估算和启发式方法（例如 words × 1.3 以及按工具固定的 schema 开销），因此结果更适合提供方向性判断，而非精确数值。
context-budget 技能概览
context-budget 技能是做什么的
context-budget 技能会审计 Claude Code 会话中 agents、skills、rules 和 MCP servers 各自消耗了多少上下文。它的任务很直接：找出 token 都花到哪里了，判断哪些内容真的“贵”，再把这些结果变成有优先级的清理动作，而不是笼统的“把 prompt 缩短一点”建议。
谁适合安装 context-budget
这个技能最适合维护非平凡 Claude Code 配置的人：有多个自定义 agent、逐渐变大的 skills/ 文件夹、层层叠加的 rule 文件，或者好几个 MCP server。如果你感觉会话变慢、输出开始跑偏，或者不确定再加一个工具会不会伤质量，context-budget 会非常对路。对于只有少量文件的精简配置，它的价值就没那么高。
为什么用户会选它，而不是通用 prompt
普通审计 prompt 可能只会让模型“看看哪里臃肿”，但 context-budget 提供的是一套结构化流程：先盘点组件，再估算 token 负载，标出常见热点，避免把复制的 skill 重复计费，最后输出按节省收益排序的优化机会。正因为这样，context-budget 技能很适合 Skill Testing：它减少了猜测，让评审路径可以重复执行、稳定复用。
安装前要先了解的限制
这是一项估算和分流优先级的技能，不是字节级精确 tokenizer，也不是自动重构工具。它关注的是实用层面的开销信号，比如文件过大、frontmatter 过长、rules 相互重叠，以及 tool 数量过多的 MCP servers。如果你需要精确的运行时 token 记账，把它的数字当作方向性参考，用来决定先人工检查什么。
如何使用 context-budget 技能
在你的技能工作流中安装 context-budget
这个仓库没有单独为该技能暴露一个独立包。实际使用中，用户通常是从父仓库安装它，然后从那里调用 context-budget 技能。一个常见的起步命令是：
npx skills add affaan-m/everything-claude-code --skill context-budget
然后确认该 skill 已出现在你安装的 skills 列表中；如果你想在运行前先理解它预期的审计流程，可以打开源仓库里的 skills/context-budget/SKILL.md。
context-budget 技能需要什么输入
context-budget 技能在你提供真实的 Claude Code 工作区结构时效果最好。比较有用的输入包括：
agents/*.mdskills/*/SKILL.mdrules/**/*.md.mcp.json或当前生效的 MCP 配置- 正常会话里实际会加载哪些组件的说明
不要只问“帮我审计上下文”。更好的问法是：Audit token overhead across agents/, skills/, rules/, and .mcp.json. 估算重文件、重复 skill、重叠规则，以及 MCP tool schema 的成本。按影响和工作量，给出前 5 个最值得节省的项。`
把粗略目标改写成强约束的 context-budget prompt
弱 prompt 只会要一个泛泛总结；强一点的 context-budget 使用 prompt 会明确范围、输出格式和判断标准。比如：
“用 context-budget skill 审计这个仓库。盘点所有 agents、skills、rules 和 MCP servers。基于清晰假设估算 token 消耗；如果 .agents/skills/ 下存在完全镜像的重复 skill，就跳过这些重复项；标出重量级文件和冗余 rule 内容；并推荐立即处理、中期处理、低优先级处理三类调整。说明每一项的预估节省和移除风险。”
这类 prompt 会明显提升质量，因为它强制 skill 把测量、去重和优先级排序分开处理。
最佳工作流以及先读什么
先读 SKILL.md；里面有完整方法。重点看：
When to UseHow It WorksPhase 1: InventoryPhase 2的分类和建议
实际使用时，最好的流程是：
- 先跑一次全量审计。
- 人工验证最大的热点。
- 一次只删除或合并一类内容。
- 每次改动后重新运行
context-budget技能。
这样能避免大规模清理把有用行为一起破坏掉，同时又能尽快回收上下文空间。
context-budget 技能 FAQ
小型配置值得用 context-budget 吗？
通常不值得。如果你只有少量 skills，也没有 MCP 膨胀问题，普通检查往往就够了。只有当环境里组件足够多，隐性开销开始影响质量，或者后续再加东西有风险时，context-budget 才会明显更有价值。
context-budget 和普通 repo review prompt 有什么不同？
普通 prompt 往往是在审内容质量；context-budget 审的是上下文成本。它专门针对容易漏掉的开销来源，比如重复安装的 skills、过长描述、重叠 rules，以及 MCP tool schema 的体积。正因为聚焦更窄，它通常比笼统的“优化我的配置”请求更有效。
新手可以用 context-budget 技能吗？
可以，只要能找到自己的 Claude Code 配置文件和文件夹就行。你不需要很深的 tokenization 知识。新手主要的风险，是看到“文件很大”之类的警告后，误删掉其实有用的指导内容。正确做法是先用该技能给候选项排序，再在删除前检查高影响项。
什么时候不该用 context-budget？
如果你的问题和上下文负载无关，比如任务指令太弱、示例不好、或者权限缺失，就先别用它。需要精确 tokenizer 计算或自动修改时也不适合；context-budget 指南用于诊断和优先级排序，不是精确记账或一键修复。
如何改进 context-budget 技能
提供更好的仓库上下文和实际加载假设
想让 context-budget 的结果更准，最有效的方法就是告诉它真实会话里到底加载了什么。要区分始终启用的 rules 和很少用的 rules，也要区分已配置但空闲的 MCP servers 和真正活跃的 MCP servers。没有这些信息，skill 可能会高估低影响组件，反而低估真正的瓶颈。
要求按优先级给出取舍，而不只是原始数字
单看 token 估算不够。应该让 context-budget skill 按影响、工作量和风险给结论打分。比如可以要求：Prefer recommendations that save meaningful context without removing unique capabilities. 这样能避免那种糟糕建议：一上来就删掉一个虽然很长但不可替代的 skill，却只去修剪重复的 rule 文本。
留意常见失败模式
最常见的失败模式包括：把镜像文件重复计数、把所有工具都当成同样昂贵，以及默认“大文件”就一定没价值。可以明确要求 skill 区分：
- 重复内容 vs 独特内容
- 静态开销 vs 高频使用上下文
- 臃肿的 frontmatter vs 必要的操作说明
这样输出会更接近可决策状态。
每次清理后都重新运行 context-budget
不要一次改很多，再寄希望于结果会自然变好。应该迭代使用 context-budget skill：审计、改一个簇、再审计、对比结果。这样才能看出清理是真正腾出了可用上下文，还是只是把复杂度挪到了别处。对于 Skill Testing 来说，迭代运行是最快验证 skill 是否真的改善了工作环境，而不是只生成一份一次性的报告的方法。