【本次运行参数】
处理范围：当前打开的这一个项目及它实际使用的规则；不扩展到其他项目。
处理方式：先生成可使用的候选文件，放到当前项目中新建的“规则整理结果”目录。保留正式文件和现有未完成改动。
执行方式：本次只使用当前助手，不启动子 Agent。先读取相关入口，再按问题深入检查，复用有效结果。
完成要求：连续完成盘点、改写、文件生成和必要检查。交付使用说明、变化表、检查记录和恢复步骤；不能验证的行为如实列出。

以下为完整整理要求：

请帮我整理当前项目适用的 AGENTS.md 和 Skills，使 AI 更容易选对方法、读到相关资料，并把已经交代的工作完成。

AGENTS.md 是给 AI 的工作约定，例如素材位置和回答语言；Skill 是某一类任务的专门说明，例如写文章或检查表格的方法。Skill 的 `name` 是标识，例如 `article-writer`；`description` 写清何时使用，例如“从零起草完整文章时使用”。

我不追求固定行数、删减比例或停用数量。需要保留真正有用的信息，改掉重复、过时、冲突和让简单任务变复杂的要求。

【项目范围】未填写时，使用当前打开的项目。先核对实际目录，不搜索整个电脑来猜测我要处理的项目。
【交付位置】未填写时，在当前项目下新建一个不覆盖已有内容的“规则整理结果”目录。
【处理方式】默认在交付目录生成完整、可使用的新版。如果我已经明确授权修改某些正式文件，则按已有授权处理那些文件，保留可恢复的原版，并保护原有未完成改动。其他文件仍输出独立新版或明确建议。
【常用任务】优先从当前项目和我已经提供的信息中识别，不清楚的部分注明；不要要求我先填写一份冗长问卷。

以下是完整任务要求，可以直接开始，不需要另找文章来补足步骤。

一、先找到真正相关的规则

1. 检查当前工具提供的实际采用规则的信息，列出适用的全局说明、项目及子目录的 AGENTS.md、已安装 Skills 的 `name` 和 `description`，以及相关的 `SKILL.md`、`references`、`scripts` 和其他被引用文件。`SKILL.md` 存放核心要求；`references` 存放按需读取的资料，例如发布清单；`scripts` 存放可执行脚本，例如链接检查程序。全局说明是多个项目共用的要求，例如默认回答语言；项目说明只管当前项目，例如这篇文章的素材目录。
2. 区分“文件存在”“本次主动读过”“工具确实把它作为指令使用”三种情况。有证据才写已生效；工具不提供证据就写无法确认，不要靠文件名猜。
3. 检查是否有多个重复入口，以及类似快捷方式、实际指向另一处文件的链接。找到真正维护正文的位置，避免改错副本。遵守本机现有存放约定，不修改系统内置文件，不把同一份私有 Skill 复制到多个安装目录。
4. 先看 Skills 的 `name` 和 `description`，再深入检查与本次任务有关、`description` 重叠或存在问题的内容。不需要把所有无关资料一次读完。若范围较大，可分批处理，并列明已检查、尚未检查和无法读取的部分。
5. 如果现有环境有多个 AI 助手、独立的助手配置或交接说明，一并确认它们和规则文件的关系。没有这些配置就跳过，不为了整理规则新搭一套系统。

二、逐条判断，留下处理依据

对范围内的规则分别标记“保留、删除、改写、移动、暂不确定”，注明原文件、位置、原句、影响、建议和新去向。没有问题的内容可以合并说明，值得修改的问题按实际影响排序。

判断时区分这些情况：多个项目都需要的稳定约定；重复内容；已经过时的要求；仅当前项目需要的信息；只适合某个模型的指导；本应放到助手配置里的职责；已经有另一份正式文档维护的流程；暂时无法判断的内容。

保留 AI 无法猜出的事实，例如真正的素材位置、需要使用的账号、特殊命令、业务口径、我的语言与解释偏好、不能覆盖的已有改动和实际授权范围。当前聊天里出现了同一句话，不足以证明以后新对话可以删掉那条长期规则。保留账号和凭据的使用要求，但不要把密码、登录凭据等秘密原文写进规则文件。

没有反复使用价值的旧案例可以删除，不必为每段删除内容另建一个文件。需要移动的内容，先安排真实可用的新位置并检查引用，再从原处移走。重要规则尽量只维护一份正文，其他入口指向它。

三、整理 Skills：先改入口，再改正文

1. 说明每个相关 Skill 提供什么额外价值：专门工具的用法、项目特殊知识、必须遵守的业务要求、经过验证的方法或稳定输出格式。没有额外信息的通用提醒可以减少。不能仅因它为旧模型编写，就判定整套方法无效。
2. 检查 `name` 和 `description`。`description` 要短且准确，例如“从零起草完整公众号文章时使用”，不堆长步骤和能力宣传。大量过长的 `description` 可能影响模型看到的信息；只在有证据时说明具体截断情况，不虚构容量数字。
3. 改掉适用范围过宽的 `description`。例如，将“所有写作任务都先访谈”改为“从零写完整文章且关键信息不足时先访谈”；必要时补一句“只改标题或错字时不用”。不要为每个 Skill 堆一长串无关排除条件。
4. 把相关 Skills 放在一起检查：是否都要求先使用自己，是否重复问问题，是否一份要求继续、另一份要求停下。将 `name`、`description` 和 `SKILL.md` 中的要求一起核对和调整，不能只换一句措辞却保留后面的冲突步骤。
5. 将处理方式具体分为：保留原用法；只在更合适的任务中自动使用；只在我点名要求时使用；暂停使用；合并或删除无价值的重复内容。解释每项选择，并使用当前工具真实支持的方式实现。仅修改 `name` 或文件名、把文件留在原目录或写一句“不再使用”，不能直接宣称已经停用成功。同组多份说明若通过相同流程自动参与任务、共同造成冲突，可以按一组调整其使用方式；不必先证明每份文件都没有价值。
6. 检查是否多做了我没有要求的事，例如：简单修改前固定访谈；普通检查前配置额外工具；强制替换项目惯用词；做完后自动记录版本、提交全部已有改动或发布。Git 是记录代码版本的工具，记录一个版本也不等于发布到网站。按实际任务和授权处理这些步骤，不把它们自动连在所有工作后面。
7. 有价值的专门方法可以保留为点名使用。例如，TDD 是先写检查程序、再写功能的方法；若它不适合每次小改动，可在用户明确要求时使用。独立审查和调试也按任务需要决定，不因为停用一套自动流程就丢掉所有有效方法。
8. 一个 Skill 包含多种任务时，在 `SKILL.md` 中先说明“做什么任务去读哪份资料”，详细步骤再按需读取。例如，写正文时读 `references/drafting.md`，准备发布时才读 `references/publishing.md`；这些只是路径示例，实际引用必须存在。单一小 Skill 不必强行拆成多个文件。
9. 同步检查 `references` 和 `scripts`。`SKILL.md` 删掉的要求若仍在这些文件中，问题可能继续存在。核对所需文件是否可读、路径是否正确、步骤是否仍适用；发现缺失或过时内容如实列出。
10. 保留真实的业务先后关系，放宽无必要的固定操作顺序。例如，先取得完整原文才能比较资料，是必要条件；必须提十个问题、固定调用五个工具，不应在所有任务中强制执行。
11. 如果这套 Skills 确实由不同人、不同模型共用，保留共同需要的业务事实，必要时区分模型相关指导。不要把只在一个模型上成立的删减结论直接套给所有使用者。
12. 若使用 `skill-creator` 等工具，先核对实际来源和当前指导；在 Codex 中优先使用当前可用的系统内置版本，不将同名私有版本直接视为同一份，也不修改系统内置 Skill 本身。`skill-creator` 用于创建或调整 Skill，例如帮助生成 `SKILL.md`。检查生成结果是否仍有 `description` 太宽、步骤过多、文件引用失效等问题。不要因为是工具生成的就默认正确，也不因缺少辅助生成工具而停止能够完成的改写。

四、重写 AGENTS.md：把长期要求写清楚

1. 按实际需要组织沟通习惯、要求之间的适用关系、执行方式、检查方式、工具与协作、正式资料位置。小文件可以合并表达，不强制六个标题。稳定通用习惯放全局；项目事实放项目；专项长流程放对应 Skill 或资料；历史决定、进度与交接信息放工作记录。
2. 删改没有具体作用的口号和过时补丁。例如，“认真思考、遵守最佳实践”若没有额外信息，可以缩短；特殊业务约束不能一并删掉。不把容易变化的模型名称、运行状态写成永久事实。
3. 把“每次都先读所有文档”改成按任务读取。例如，改产品价格时查价格表，准备发布时查发布清单，改一个错字不强制先读全项目。核对被指向的文件是否存在、内容是否仍适用。
4. 程序项目还要核对安装、检查和运行命令。依据当前配置、实际可用脚本、记录依赖版本的文件及自动检查配置交叉确认。例如，旧说明中的安装命令，应与项目现在采用的安装工具一致。不要仅因旧文件写了某条命令就照做。
5. 保留项目必做检查，检查范围与本次变化相称。改标题可以核对文字和保存结果；修复程序行为需要检查问题是否解决及相关功能是否受影响。不要只为重复证明显而易见的实现而新增测试。
6. 必要检查通过后，只有新改动、新失败或未解决的具体疑点，才扩大或重复检查。同一代码、输入和环境状态下的有效结果可以复用；相关状态变化后重查受影响部分。调试先确认现象，必要时用能重现问题的最小例子查原因，不凭猜测扩大修改。
7. 在环境前提真实成立时，写清可以连续做的工作。例如，本地检查只使用临时测试数据、不连接正式服务时，可以在既有修复授权内运行检查、修复本次引起的问题、再查受影响部分，无需每一步重新询问。
8. 保留系统和平台约束，按当前工具的实际机制处理用户要求、项目说明和 Skill 的关系。Skill 中的默认流程不能自行增加本次授权，也不应把已经授权的工作无故停住。涉及权限变化的改写单列说明。
9. 沟通面向我的理解程度：先用日常语言解释；标准字段名、文件名和工具名保留原文，例如 `name`、`description`、`SKILL.md`、`references`、`scripts`，不要用中文称呼替换；首次出现时解释用途并给例子。已熟悉的基础知识不反复讲。明确偏好可以保留短句，不为追求更短而删除。

五、再按八类用途查缺补漏

只检查当前实际存在、与任务相关的类别；缺少某类不代表必须安装。以下是检查方向，不是预先决定全部删除或新增。

1. 网页与电脑操作：能否减少重复的点击说明，同时保留账号、独立浏览器环境、工具参数和下载位置？例如，AI 会打开网页，也不代表知道应该登录哪个账号。
2. 代码检查：减少通用口号，保留项目特殊要求和真实错误案例。需要判断效果时，用包含已知问题的小样例检查能否发现它。
3. 长文档：区分“因为一次装不下而分段”和“为了读齐、定位出处而分段”。一次能读更多文字，不代表图片、附件和被工具截掉的内容已经取得。扫描图片需要识别其中的文字；视频需要逐句记录的文字稿。资料未取得不能声称读完。
4. 数据分析：保留计算口径、单位和输出格式；确有需要时扩展更复杂的计算。用已知答案或独立计算检查结果，不凭未经核验的模型分数增加承诺。
5. 多步骤工作：保留必须先完成的业务条件及质量要求，普通实现顺序按任务选择。对有争议的固定流程，可用同一任务比较，不预设步骤越多越好或越少越好。
6. 操作安全：检查读取、记忆和实际行动的范围是否清楚，针对真实缺口补规则。区分本地临时数据与真实业务数据，不为所有低影响任务增加同一套冗长审查。
7. 提示词模板：删重复催促，保留目标、已有资料、可用工具、交付物、完成条件和停止范围。不要要求必须减半。
8. 跨对话衔接：优先利用已有工作记录保存已确认的决定、依据、待办和何时需要重新核对。例如，记录选择了哪份稿件、原因和下一步，而不是抄全部聊天。个人偏好若要存入跨任务使用的长期记忆，应按用户实际授权办理；没有必要就不新增记忆系统。

六、让任务做到约定结果，合理使用工具

1. 为常用任务给出简短模板，包含：目标、已有资料、可用工具和操作范围、实际交付物、怎样检查、完成后在哪里停。例如，“把两份资料整理成一篇面向新手的文章，核对事实并保存到指定位置，交付后结束，不自行发布”。
2. 已授权工作持续到目标完成、必要检查结束或遇到真实阻塞。不要默认在第一次写完后停住，也不要在目标完成后凭空增加后续任务。用户中途补充、纠正或询问进度时，回应后继续原任务，除非用户明确取消或替换目标。
3. 只对会实质改变结果、范围或授权的缺失信息提问，能独立做的部分继续。如果规则导致停顿，给出具体文件位置和原句，解释它是明确要求还是你的理解，不笼统说“按规定必须确认”。
4. 工具选择以当前可用能力为准，优先适合目标的专用工具；互不等待对方结果的读取和查询可以批量执行，不把共享状态操作强行同时进行。
5. 如果现有工具支持且用户授权允许使用多个 AI 助手，只把真正独立的工作交出去。例如，两份互不依赖的材料可以分别阅读；同一份稿件的最终改写由一个助手统一处理。交代输入、输出、读写范围和完成标准，汇总后核对，不让多个助手同时改同一文件。没有这项能力就由当前助手完成。
6. 本次整理保持当前有效的模型和思考档位，方便判断规则修改的效果。思考档位是工具允许模型投入多少推理的设置，例如日常小任务和复杂分析可能适合不同档位。只有用户要求另行比较或迁移模型时，再核对工具当前支持的选择，不把统一调低当成整理规则的必做项。

七、用少量真实任务检查，而不只比较字数

先检查新文件格式、所需引用、冲突及内容是否完整。再选择与实际改动有关的代表任务，不为没有变化或不适用的项目强行增加检查。

至少为以下三类行为给出适用检查，并在具备真实启用条件和授权时执行：

- 应该用某个 Skill 的任务能选中它；相近但不需要的任务不会误用。例如，从零写文章和只改一个标题应区别处理。
- 一个小改动不会读大量无关资料、额外找多个助手或反复扩大检查。
- 一个明确交付任务能继续到文件生成、结果核对完成；关键个人偏好和项目规则仍被遵守。

有条件时再检查：已授权任务是否重复询问；适合并行的只读任务能否正常分工；是否避免同时改同一文件；是否仍读取正确的项目和工作说明；未授权的发布、删除、真实业务修改是否保留边界。边界检查采用不会产生真实破坏或外部发布的方式。

运行对比前，先确认工具真正支持怎样临时使用新版，保留原版与恢复方式。名为 AGENTS.candidate.md 的候选文件不会仅因这个名字就自动成为正式规则；模型按要求读一次，也不能直接证明以后会自动生效。如果临时替换配置测试，结束后恢复并核对；如果已经授权正式采用，保留恢复副本并核验实际启用状态。

比较时尽量使用相同任务、资料、模型和思考档位。优先看交付质量、误用方法、无关读取和不必要停顿，再记录行数或字数变化。工具不提供用量或内部助手的真实运行信息时，写“无法取得该证据”，必要时标记 NOT_EXPOSED；不要猜。没有多助手功能就跳过相关项，不临时搭建复杂配置。

如果不能验证真实启用后的行为，交付完整新版和准确的手动试用步骤，并明确“文件已生成，行为尚未验证”，不要用模拟结果冒充实际效果。

八、交付可使用的文件及简短说明

请连续完成：盘点、改写、生成文件、必要检查和交付，不在每个小阶段重复等待确认。

最终给我：

1. 完整的新版 AGENTS.md，以及确实需要调整的 `SKILL.md`、`references` 或 `scripts`。保持它们之间的引用可用；文件名冲突时另建位置，不覆盖无关内容。不只提供摘要或建议清单。
2. 一份变化表：原文件与位置、旧规则、处理方式、新表达或去向、理由、预期影响。会改变操作权限的项目单列，无法判断的项目说明缺什么证据。
3. 一份检查记录：实际做了什么、结果如何、哪些没有执行或无法验证。根据结果说明可以试用、还要修改、宜保留原版或当前无法验证；没有足够证据不宣称提效或没有退化。
4. 一份新手使用说明：文件在哪里、如何按当前工具的真实方式启用、怎样确认启用、如何恢复。独立新版生成完不等于已经安装或生效。
5. 一个适合当前项目的任务提示示例，写清目标、输入、范围、交付和完成标准。

遇到打不开的文件、失效位置、缺少工具、读取被截断或规则冲突，说明卡在哪里、影响了哪部分、尝试过什么，以及继续所需的最少信息；其他可以完成的部分继续。

这是一项有范围的整理任务，不因发现其他可改善事项就无限扩展。完成后，以后只针对真实出现的问题补充必要规则，并安排能判断该问题是否解决的检查，避免把文件重新堆满通用提醒。