context-management

本 Skill 用于指导 LLM/Agent 在复杂项目中:

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "context-management" with this command: npx skills add no-trade-no-life/yuan/no-trade-no-life-yuan-context-management

上下文与指令管理 Skill

本 Skill 用于指导 LLM/Agent 在复杂项目中:

  • 明确“指令 vs 信息”的区分

  • 把长期记忆外化到文件(AGENTS.md / SESSION_NOTES.md)

  • 在接受新指令时做冲突检测

  • 控制上下文长度,避免无脑堆日志

  • 提供可追踪、可审计的决策记录

  1. 何时使用本 Skill

当满足以下任一条件时,应主动启用本 Skill 的行为规范:

  • 任务跨越多轮调用或多个 Agent,需要「记住前情」;

  • 需要在一个仓库/项目内固化规则与工作流;

  • 用户或其他 Agent 提到:

  • AGENTS.md 、SESSION_NOTES.md 、会话笔记 、交接文档 等;

  • “帮我管理上下文 / 指令 / 规则”;

  • 上下文变长,模型开始显得遗忘、反复、指令不一致;

  • 存在不同人(或 Agent)反复参与同一项目,容易跑偏。

如果当前任务只是一次性、几句话就能完成的小活,可以不主动使用本 Skill(除非用户明确要求)。

  1. 核心理念(Skill 的设计哲学)

指令与信息分离

  • 指令(Instructions):

  • 规定“要怎么做事”的元规则;

  • 如风格偏好、安全约束、不能做的事、阶段性侧重点。

  • 信息(Facts/State):

  • 描述“世界/项目当前是什么样”的事实;

  • 如架构设计、实现细节、TODO 列表、已知 bug 记录等。

本 Skill 要求:

  • 指令写在 AGENTS.md
  • SESSION_NOTES.md 的「指令与约束」部分;
  • 项目状态与事实写在「重要背景」「近期工作记录」「TODO」。

渐进式信息披露(Progressive Disclosure)

  • 不要一股脑把所有历史对话、全部文档塞进上下文;

  • 优先:

  • 定位:找到相关文件和章节;

  • 概括:在内部思考中做小结;

  • 引用:对用户使用“指向 + 摘要”的方式回答;

  • 只有在确实需要时,才展开详细内容。

文件系统即外部记忆

  • 把稳定的知识放在文件里,而不是只放在一段长聊天中;

  • Skill 的指令短小清晰,把复杂细节拆到:

  • AGENTS.md :Agent 行为准则;

  • SESSION_NOTES.md :项目当前状态与会话笔记;

  • 其他专门文档(如 docs/xxx.md );

  • 这样做有三个目的:

  • 减少 token 压力;

  • 提供可版本控制的“记忆”;

  • 让多 Agent / 多人都能共享同一套认知。

明确、可审计的决策与指令变更

  • 每次指令变化、冲突解决、重大架构决策

必须以“可追踪文字”形式写入文档,而不是只说在对话里;

  • 方便日后复盘:

“当时为什么这么决定?谁改的指令?覆盖了什么旧规则?”

将复杂任务拆分为阶段并外化成计划文档

  • 对于复杂/跨多轮的工作,建议使用 IMPLEMENTATION_PLAN.md :

  • 按 3–5 个 Stage 拆分目标;

  • 为每个 Stage 约定可验证的成功标准与测试;

  • 在推进过程中更新 Stage 状态;

  • 完成后可删除或归档该计划文件。

  • 这样做可以让多个 Agent / 人类在多轮对话中保持同一认知。

  1. 入口流程:启动本 Skill 时你要做的事

当本 Skill 被触发时,Agent 应该遵循以下步骤:

检查并读取关键文档

  • 尝试读取根目录的:

  • AGENTS.md (如果不存在,可提示用户用模板新建);

  • 尝试读取当前项目/代码仓内的:

  • codex/SESSION_NOTES.md 或类似约定路径;

  • 如果不存在,可使用 SESSION_NOTES.template.md 作为起点。

在内部整理出三类列表

(可在你的“隐藏思考”中完成,不必全部回显给用户):

  • 指令类(来自 AGENTS + SESSION_NOTES:指令与约束)

  • 长期通用指令

  • 当前阶段指令

  • 临时/一次性指令

  • 事实类(来自 SESSION_NOTES:背景、决策、近期工作等)

  • 任务类(来自 TODO / Next steps + 用户最新请求)

解析用户本轮请求

  • 把用户最新消息拆成:

  • 新增指令?(例如“之后都用中文回答”)

  • 本轮任务?(例如“帮我重构 X 文件”)

  • 对已有指令的修订?(例如“之前说不要改 DB,现在可以改了”)

对新指令进行“冲突检测”

  • 将本轮新指令与已有指令列表比对;

  • 如果存在明显冲突或覆盖关系:

  • 在回复中明确指出冲突点;

  • 停止执行与冲突相关的操作;

  • 请用户选择:

  • 覆盖旧指令;

  • 作为特殊例外(附范围说明);

  • 或维持旧指令、忽略新请求中某部分。

  • 只有在用户明确确认后,才更新指令列表并执行工作。

形成本轮的“工作计划”

  • 结合:

  • 已确认的指令集合;

  • 当前项目事实;

  • 用户本轮具体任务;

  • 在内部列出 3–7 个步骤的小计划后再开始动手。

  1. 执行阶段:在任务中如何使用本 Skill

在具体执行工作(写代码、改文档、分析数据等)时,应遵循:

优先查文档后再推理

  • 对于:

  • 项目约定;

  • 目录结构;

  • 已存在设计决策;

  • 不要直接瞎猜,应先在文件系统中查找相关信息:

  • AGENTS.md

  • SESSION_NOTES.md

  • docs/ 目录

  • 其他明显相关文件(如 DESIGN.md 、ARCHITECTURE.md )。

小步修改 + 明确说明

  • 每次只改少量相关文件;

  • 在对话中简单说明:

  • 改了哪些文件;

  • 主要改动点;

  • 影响范围;

  • 如果能运行测试或检查命令,也应说明命令和结果。

控制上下文长度

  • 不要在对话中无脑贴巨大文件原文;

  • 优先:

  • 用「文件路径 + 小节标题 + 摘要」的方式指代;

  • 在需要用户确认时,可以粘贴必要片段(非整篇)。

尊重指令层级与来源

  • 默认层级排序(从高到低):

  • 系统/平台级指令(不在此 Skill 内,但你应遵守);

  • AGENTS.md 中的长期指令;

  • SESSION_NOTES 中明确记录的阶段性指令;

  • 本轮用户的临时指令;

  • 你自己的常识与默认偏好。

  • 如下层指令与上层冲突,以上层为准,并向用户说明。

遇到卡壳时的处理方式

  • 对同一思路连续尝试的次数不宜超过 3 次:

  • 如果发现自己在“重复同一种做法但一直失败”,应主动停下来;

  • 停止继续 brute force,改为:

  • 写下尝试过的方案和错误现象;

  • 从代码库中找 2–3 个类似实现做对比;

  • 重新评估抽象层级和拆分方式;

  • 必要时向用户汇报当前困境并请求决策;

  • 执行新的方案前,可在 SESSION_NOTES 中简要记录“思路切换”的原因。

  1. 收尾阶段:更新会话笔记与指令

在你准备结束本轮工作(或预期需要交给下一位 Agent)时:

更新 SESSION_NOTES

  • 在 最近几轮工作记录 中增加一条:

  • 总结本轮实际完成的内容;

  • 列出修改的文件;

  • 记录测试命令和结果;

  • 提醒任何临时绕过或技术债。

  • 在 当前 TODO / 任务列表 中:

  • 勾选已完成任务;

  • 补充新的后续任务;

  • 调整优先级(高/中/想法)。

记录指令变更与冲突决议

  • 如本轮存在新的长期/阶段性指令,或有冲突处理:

  • 在 指令与约束 一节的合适小节更新;

  • 在「指令冲突与变更记录」中写清:

  • 旧指令;

  • 新指令;

  • 冲突点;

  • 用户最终决议;

  • 对 2.x 小节做了怎样的更新。

明确下一位 Agent 的建议步骤

  • 在 下一位 Agent 的建议行动 中写出 3–5 条:

  • 从哪一个文件/任务开始;

  • 哪些是必须先做的;

  • 有什么坑要特别注意;

  • 本轮未完成但已分析过的部分。

  1. 与模板文件的配合方式

本 Skill 依赖两个可重用的模板:

  • AGENTS.template.md

  • SESSION_NOTES.template.md

当你检测到项目中还没有正式的 AGENTS.md 或 SESSION_NOTES.md 时,你应当:

  • 向用户建议:

  • 基于模板复制一份正式文件:

  • AGENTS.template.md → AGENTS.md

  • SESSION_NOTES.template.md → codex/SESSION_NOTES.md 或项目约定路径;

  • 如果环境允许自动写文件:

  • 先基于模板创建文件;

  • 再在文件中补充当前项目的具体信息。

之后,所有对指令和项目状态的修改,应通过这两个正式文件来完成,而不是修改模板本身。

  1. 示例使用场景(简化示例)

以下是一些你应该“自动想到使用本 Skill”的典型场景。

场景 1:多次调用同一个 Agent 维护同一项目

用户第一次:

“帮我这个仓库写一个 AGENTS.md 和 SESSION_NOTES.md,用于后续所有工作。”

你:

  • 使用模板生成并填充初始内容;

  • 指示用户之后所有复杂任务都以此为基础。

用户第二次:

“我们改主架构了,现在 HTTP 层不直接访问数据库了,你帮我重构,并更新交接文档。”

你:

  • 先读现有 AGENTS / SESSION_NOTES;

  • 分析哪些指令/背景需要更新;

  • 重构代码;

  • 在 SESSION_NOTES 的决策、最近工作、TODO 中记录变更。

场景 2:新指令与旧安全约束冲突

旧指令:AGENTS.md 中写明“不要直接修改生产数据库相关配置”;

新指令:用户说“你直接把生产的 DB host 改一下就行”。

你应当:

  • 指出新旧指令冲突;

  • 请用户明确是否要修改安全规则,并说明风险;

  • 在得到明确确认后:

  • 更新 AGENTS 中相关指令;

  • 在 SESSION_NOTES 的“指令冲突与变更记录”写清决议;

  • 再执行变更。

  1. 你在使用本 Skill 时的自检清单

在你自觉“本轮任务需要上下文管理”时,可以在内部快速检查:

  • 我是否已经读取了 AGENTS.md 和 SESSION_NOTES.md ?

  • 我是否把“指令 / 信息 / TODO”分清楚了?

  • 新指令是否与旧指令有冲突?如果有,我是否已经明确地向用户指出并请求决策?

  • 我是否避免把无关历史对话全部塞进上下文,而是依赖文件和摘要?

  • 我是否在结束前更新了 SESSION_NOTES 的:

  • 最近工作记录;

  • TODO;

  • 指令变更;

  • 下一位 Agent 的建议行动?

  • 我是否使用了中文输出?

如果以上大部分都能回答“是”,说明你正确使用了本 Skill。

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

git-changes-reporter

No summary provided by upstream source.

Repository SourceNeeds Review
General

vendor-implementation

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

context-management

No summary provided by upstream source.

Repository SourceNeeds Review
General

context-management

No summary provided by upstream source.

Repository SourceNeeds Review