plimeor/context-engineering-global

目的

帮助用户维护精简、稳定、可长期复用的全局上下文层。

这个 skill 只负责“全局常驻”的那一层，不负责项目局部规则和当前任务的临时上下文。

这个 skill 做四件事：

1. 审查和精简现有全局 rules file
2. 评估候选规则是否真的值得进入全局层
3. 给出可直接 apply 的改写文本和插入位置
4. 在出现协作摩擦时，先判断问题是否真的该落在全局层

官方标准来源（需要时重新获取最新版本）：

• https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• https://code.claude.com/docs/en/best-practices

边界

属于本 skill

• ~/.claude/CLAUDE.md 或等价的全局 rules file
• 跨任务、跨项目、跨会话都稳定成立的行为约束
• 角色设定、输出偏好、少量高杠杆协作规则
• “这条规则要不要进全局 prompt” 这类判断

不属于本 skill

• 仓库级或目录级 AGENTS.md / CLAUDE.md
• 新项目接入时的 context setup
• 当前任务要读哪些 spec、source、tests、errors
• 会话压缩、切换模块、任务级 context packing
• skill 误触发、漏触发、description 与 routing 修复

以上问题交给 context-engineering-project。

输入模式

用户通常会以四种方式触发：

模式 1：描述协作摩擦

用户描述一类长期重复出现的不顺心场景。

做法：

1. 先判断根因是不是全局层问题，而不是项目上下文、tooling、skill、模型能力边界或当前任务信息不足
2. 如果是全局层问题，提出具体的规则改动
3. 如果不是，明确指出真正应落的层级

模式 2：评估改动提案

用户直接给出想写进全局 rules file 的内容。

做法：

1. 读取当前全局 rules file
2. 用评估清单逐条检查提案内容
3. 对每条内容给出判定：适合全局 / 应放项目层 / 应放 skill / 应交给 tooling / 不需要
4. 对适合全局的内容，给出改写后的具体文本和插入位置
5. 对不属于全局的内容，说明真正落点

模式 3：审查现有全局上下文

用户没提供特定内容，要求直接优化现有全局文件。

做法：

1. 读取当前全局 rules file
2. 用评估清单逐条审查每条现有规则
3. 输出审查报告：保留 / 精简 / 删除 / 迁移到项目层或 skill，每条附理由
4. 给出改写后的完整全局上下文

模式 4：从信息中提取

用户给一个指令让你读文件、读对话、搜索资料或总结摩擦，然后从中提取全局上下文候选内容。

做法：

1. 执行用户要求的上下文收集
2. 从信息中筛出可能影响全局层的内容
3. 按模式 2 的评估流程处理

根因过滤

在建议“把它写进全局 prompt”之前，先排除以下更常见的真实原因：

1. 项目上下文缺失 — 需要 repo-local rules file、spec 摘要、相关源码或错误输出
2. 规则放错层级 — 明明是项目规则、skill 协议或 tooling 检查
3. 当前任务信息不足 — 模型没读到该读的文件
4. 模型能力边界 — 不是多写一条全局规则就能修

评估标准

对每条候选规则，依次检查：

1. 跨任务性 — 是否跨多数任务都成立？不是的话不要进全局层
2. 跨项目性 — 是否不依赖某个仓库、技术栈或团队局部约定？
3. 跨会话性 — 是否值得在每次对话都常驻？只在某阶段有效的不要常驻
4. 不可推断性 — 模型能否从请求、代码或上下文自行推断？能推断的不需要写
5. 可观察性 — 违反时能否从输出中看见？不可观察的规则很难验证
6. 非冗余性 — 是否明显区别于模型默认行为？重复默认值只会增噪
7. 精简性 — 是否已经是最短有效表述？
8. 带动机性 — 是否解释了 why？解释动机通常比堆 MUST 更有效
9. 无矛盾性 — 是否与已有全局规则冲突？

官方标准参考

全局 rules file 精简原则

来源：https://code.claude.com/docs/en/best-practices

• 把 rules file 当代码对待：review、prune、test
• 如果删掉某行不会导致模型犯错，就删掉它
• 过长的全局文件会导致规则被忽略

适合放在全局层的内容

1. 角色设定 — 聚焦行为和语气的单句角色描述
2. 清晰直接的协作规则 — 无歧义、可观察行为的约束
3. 带动机的偏好 — 解释 why，少用重锤命令
4. 少量输出偏好 — 只在偏好明显不同于默认值时才写
5. 高频且高杠杆的抑制项 — 比如过度工程化倾向

不适合放在全局层的内容

1. 专项工作流 — 应放入 skill，按需加载
2. 项目特定规则 — 应放项目级 AGENTS.md / CLAUDE.md
3. 任务级 context packing — spec、源码、错误输出应按任务提供
4. 可由 tooling 确定性约束的规则 — 用 hooks、tests、linters、scripts 替代
5. 过度指令 — 不需要用 CRITICAL/MUST 堆强调
6. 冗余规则 — 与默认行为一致的内容是噪音
7. 可从代码推断的内容 — 架构、文件路径、局部代码风格等

输出要求

无论哪种输入模式，最终输出都包含：

1. 全局层判定

对每条候选内容先给出结论：

• 进入全局层
• 不进入全局层，并注明真正落点

2. 全局上下文改动

对每条改动：

• 改动类型：新增 / 修改 / 删除
• 改动内容：具体的改写后文本
• 评估依据：引用评估清单中的哪些条目
• 插入位置：应放在现有文件的哪个 section

3. 非全局建议

对每条未进入全局层的内容：

• 应落在哪一层：项目层 / skill / tooling / 当前任务上下文
• 一句话理由
• 如有必要，给出下一步最小动作

4. 不采纳的内容

对每条不采纳的内容，说明原因。

执行纪律

• 读完现有全局文件再提建议，不要凭空写
• 全局上下文是寸土寸金的，宁可少一条，不可多一条
• 先排除项目上下文和工具层问题，再决定是否修改全局层
• 不要重复模型默认行为
• 解释 why，而不是用大写字母喊 MUST
• 改动要具体到可以直接 apply 的文本，不要只给抽象建议