Token导航 LogoToken导航

Agent Skill · 研究检索

context-management(上下文管理)

context-management 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

context-management 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证为 MIT,暂无第三方扫描结果,按安装量在研究检索类的 73,675 个 Skill 里排第 73,276。

总安装 98周安装 4GitHub Stars 公开资料未说明下载 31核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:context-management(上下文管理)
来源仓库:https://github.com/no-trade-no-life/yuan
仓库路径:skills/context-management
安装命令:
npx skills add no-trade-no-life/yuan --skill "context-management"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add no-trade-no-life/yuan --skill "context-management"

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

管理 AI 代理的技能发现与安装流程,提升工具链集成效率。适用于需要动态加载和管理各类技能插件的开发环境。通过标准化接口发现和部署新技能,简化扩展功能的过程。安装时需确认宿主环境的兼容性,注意技能间的依赖关系。context-management 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/context-management

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add no-trade-no-life/yuan --skill "context-management";命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

context-management 怎么安装?

在终端执行 npx skills add no-trade-no-life/yuan --skill "context-management"。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

context-management 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

context-management 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

context-management 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

context-management 用的人多吗?

公开数据是累计安装 98 次,近一周安装 4 次,下载 31 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

context-management 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
context-management

上下文管理 · 本页

98—需要联网MIT未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

上下文与指令管理 Skill

本 Skill 用于指导 LLM/Agent 在复杂项目中: - 明确“指令 vs 信息”的区分 - 把长期记忆外化到文件(AGENTS.md / SESSION_NOTES.md) - 在接受新指令时做冲突检测 - 控制上下文长度,避免无脑堆日志 - 提供可追踪、可审计的决策记录

1. 何时使用本 Skill

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

  • 任务跨越多轮调用或多个 Agent,需要「记住前情」;
  • 需要在一个仓库/项目内固化规则与工作流;
  • 用户或其他 Agent 提到:

- AGENTS.md、SESSION_NOTES.md、会话笔记、交接文档 等; - “帮我管理上下文 / 指令 / 规则”;

  • 上下文变长,模型开始显得遗忘、反复、指令不一致;
  • 存在不同人(或 Agent)反复参与同一项目,容易跑偏。

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


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

  1. 指令与信息分离 本 Skill 要求:

- 指令(Instructions): - 规定“要怎么做事”的元规则; - 如风格偏好、安全约束、不能做的事、阶段性侧重点。 - 信息(Facts/State): - 描述“世界/项目当前是什么样”的事实; - 如架构设计、实现细节、TODO 列表、已知 bug 记录等。 - 指令写在 AGENTS.md + SESSION_NOTES.md 的「指令与约束」部分; - 项目状态与事实写在「重要背景」「近期工作记录」「TODO」。

  1. 渐进式信息披露(Progressive Disclosure)

- 不要一股脑把所有历史对话、全部文档塞进上下文; - 优先: 1. 定位:找到相关文件和章节; 2. 概括:在内部思考中做小结; 3. 引用:对用户使用“指向 + 摘要”的方式回答; - 只有在确实需要时,才展开详细内容。

  1. 文件系统即外部记忆

- 把稳定的知识放在文件里,而不是只放在一段长聊天中; - Skill 的指令短小清晰,把复杂细节拆到: - AGENTS.md:Agent 行为准则; - SESSION_NOTES.md:项目当前状态与会话笔记; - 其他专门文档(如 docs/xxx.md); - 这样做有三个目的: - 减少 token 压力; - 提供可版本控制的“记忆”; - 让多 Agent / 多人都能共享同一套认知。

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

- 每次指令变化、冲突解决、重大架构决策 必须以“可追踪文字”形式写入文档,而不是只说在对话里; - 方便日后复盘: “当时为什么这么决定?谁改的指令?覆盖了什么旧规则?”

  1. 将复杂任务拆分为阶段并外化成计划文档
  • 对于复杂/跨多轮的工作,建议使用 IMPLEMENTATION_PLAN.md:

- 按 3–5 个 Stage 拆分目标; - 为每个 Stage 约定可验证的成功标准与测试; - 在推进过程中更新 Stage 状态; - 完成后可删除或归档该计划文件。

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

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

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

  1. 检查并读取关键文档

- 尝试读取根目录的: - AGENTS.md(如果不存在,可提示用户用模板新建); - 尝试读取当前项目/代码仓内的: - codex/SESSION_NOTES.md 或类似约定路径; - 如果不存在,可使用 SESSION_NOTES.template.md 作为起点。

  1. 在内部整理出三类列表 (可在你的“隐藏思考”中完成,不必全部回显给用户):

- 指令类(来自 AGENTS + SESSION_NOTES:指令与约束) - 长期通用指令 - 当前阶段指令 - 临时/一次性指令 - 事实类(来自 SESSION_NOTES:背景、决策、近期工作等) - 任务类(来自 TODO / Next steps + 用户最新请求)

  1. 解析用户本轮请求

- 把用户最新消息拆成: - 新增指令?(例如“之后都用中文回答”) - 本轮任务?(例如“帮我重构 X 文件”) - 对已有指令的修订?(例如“之前说不要改 DB,现在可以改了”)

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

- 将本轮新指令与已有指令列表比对; - 如果存在明显冲突或覆盖关系: - 在回复中明确指出冲突点; - 停止执行与冲突相关的操作; - 请用户选择: - 覆盖旧指令; - 作为特殊例外(附范围说明); - 或维持旧指令、忽略新请求中某部分。 - 只有在用户明确确认后,才更新指令列表并执行工作。

  1. 形成本轮的“工作计划”

- 结合: - 已确认的指令集合; - 当前项目事实; - 用户本轮具体任务; - 在内部列出 3–7 个步骤的小计划后再开始动手。


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

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

  1. 优先查文档后再推理

- 对于: - 项目约定; - 目录结构; - 已存在设计决策; - 不要直接瞎猜,应先在文件系统中查找相关信息: - AGENTS.md - SESSION_NOTES.md - docs/ 目录 - 其他明显相关文件(如 DESIGN.md、ARCHITECTURE.md)。

  1. 小步修改 + 明确说明

- 每次只改少量相关文件; - 在对话中简单说明: - 改了哪些文件; - 主要改动点; - 影响范围; - 如果能运行测试或检查命令,也应说明命令和结果。

  1. 控制上下文长度

- 不要在对话中无脑贴巨大文件原文; - 优先: - 用「文件路径 + 小节标题 + 摘要」的方式指代; - 在需要用户确认时,可以粘贴必要片段(非整篇)。

  1. 尊重指令层级与来源

- 默认层级排序(从高到低): 1. 系统/平台级指令(不在此 Skill 内,但你应遵守); 2. AGENTS.md 中的长期指令; 3. SESSION_NOTES 中明确记录的阶段性指令; 4. 本轮用户的临时指令; 5. 你自己的常识与默认偏好。 - 如下层指令与上层冲突,以上层为准,并向用户说明。

  1. 遇到卡壳时的处理方式
  • 对同一思路连续尝试的次数不宜超过 3 次:

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

  • 停止继续 brute force,改为:

- 写下尝试过的方案和错误现象; - 从代码库中找 2–3 个类似实现做对比; - 重新评估抽象层级和拆分方式; - 必要时向用户汇报当前困境并请求决策;

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

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

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

  1. 更新 SESSION_NOTES

- 在 最近几轮工作记录 中增加一条: - 总结本轮实际完成的内容; - 列出修改的文件; - 记录测试命令和结果; - 提醒任何临时绕过或技术债。 - 在 当前 TODO / 任务列表 中: - 勾选已完成任务; - 补充新的后续任务; - 调整优先级(高/中/想法)。

  1. 记录指令变更与冲突决议

- 如本轮存在新的长期/阶段性指令,或有冲突处理: - 在 指令与约束 一节的合适小节更新; - 在「指令冲突与变更记录」中写清: - 旧指令; - 新指令; - 冲突点; - 用户最终决议; - 对 2.x 小节做了怎样的更新。

  1. 明确下一位 Agent 的建议步骤

- 在 下一位 Agent 的建议行动 中写出 3–5 条: - 从哪一个文件/任务开始; - 哪些是必须先做的; - 有什么坑要特别注意; - 本轮未完成但已分析过的部分。


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

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

  • AGENTS.template.md
  • SESSION_NOTES.template.md

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

  1. 向用户建议:

- 基于模板复制一份正式文件: - AGENTS.template.md → AGENTS.md - SESSION_NOTES.template.md → codex/SESSION_NOTES.md 或项目约定路径;

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

- 先基于模板创建文件; - 再在文件中补充当前项目的具体信息。

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


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

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

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

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

- 使用模板生成并填充初始内容; - 指示用户之后所有复杂任务都以此为基础。

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

- 先读现有 AGENTS / SESSION_NOTES; - 分析哪些指令/背景需要更新; - 重构代码; - 在 SESSION_NOTES 的决策、最近工作、TODO 中记录变更。

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

  • 旧指令:AGENTS.md 中写明“不要直接修改生产数据库相关配置”;
  • 新指令:用户说“你直接把生产的 DB host 改一下就行”。
  • 你应当:

- 指出新旧指令冲突; - 请用户明确是否要修改安全规则,并说明风险; - 在得到明确确认后: - 更新 AGENTS 中相关指令; - 在 SESSION_NOTES 的“指令冲突与变更记录”写清决议; - 再执行变更。


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

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

  • 我是否已经读取了 AGENTS.md 和 SESSION_NOTES.md?
  • 我是否把“指令 / 信息 / TODO”分清楚了?
  • 新指令是否与旧指令有冲突?如果有,我是否已经明确地向用户指出并请求决策?
  • 我是否避免把无关历史对话全部塞进上下文,而是依赖文件和摘要?
  • 我是否在结束前更新了 SESSION_NOTES 的:

- 最近工作记录; - TODO; - 指令变更; - 下一位 Agent 的建议行动?

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

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

平台分布

trae

60.45%
按下载量换算19

Cursor

27.73%
按下载量换算9

安全审计

暂无安全审计结果可展示。

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills