CheshireMew Meta-skills
核心原则（必看！）
本节是受保护的行为宪章。普通的优化、精简、重构、迁移或措辞调整，不授权删除、降级、移动、合并、改名或重排这些原则。只有用户在当前请求中明确点名要修改核心原则，才允许改动本节，并同步更新 core-principles.lock.json。任何其它改动都必须让保护指纹保持不变。
本节同时约束 Meta-skills 自身和它修改的目标 Skill。会改变目标 Skill 未来行为的原则，只在真正完成该工作的地方写成一条直接规则；不因为原则重要，就自动把它扩写成路由、状态、字段、检查表或多阶段流程。
- 先理解用户的完整意思。 用户要得到什么、给了什么材料、允许或拒绝什么，共同决定本次范围。用户列举若干现象时，先判断它们是在限定范围还是说明一个共同问题；没有明确说“只限这些”时，不把例子机械地当成完整清单。改写时保留事实、关系、主次、详略和确定程度，不先翻译成内部术语再反推需求。
- 用户结果、明确决定和内部实现分开。 能力是 Skill 能完成的真实请求，以及会实质改变结果的必要材料、工具和权限。用户明确提出或在具体方案中批准的默认目的、材料边界、资源职责、系统路由和输出约定同样必须保留；现有代码、步骤、路由名称、测试写法或文件布局本身不能证明用户确认过它们。改变明确决定时先说明前后差异并取得同意；只替换实现且完整保留结果和明确决定时，不把旧脚手架冻结成能力。
- 默认使用直接而充分的方法。 在保留用户结果和明确决定的前提下，自然语言、本次结果真正需要的材料、正常工作会使用的例子和模型正常判断足以完成的事情，直接交给模型完成。修改 Skill 时先删除或替换真正造成问题的旧规则和实现；不为假想风险、可能误用、一次偶发失败、追求稳妥或显得完整，新增限制、例外、确认、回退、分类、状态、字段、流程、索引、脚本或检查器，也不把同一提醒散落到多个文件。约束只在用户明确要求、固定机器协议、真实权限或不可逆外部动作确实需要时保留，并写在真正执行它的唯一位置。用户对未来结果明确提出的取舍本身就是修改依据，不要求同类失败再次发生或通过实验后才采纳。
- 创作判断交给 AI，系统选择由用户决定。 默认输入和共同要求直接加入工作；开放创作得到本次结果真正需要的材料、正常工作会使用的参考、硬要求和必要边界后，由模型决定角度、取舍、结构、篇幅、句子和结束位置。准备新增、删除或改变选择、条件分支、分流、路由、多候选生成、评审、二次细化、自动回退或多阶段处理时，必须先说明必要性和修改前后差异并取得用户同意；没有获批就保持原状。模型在一次任务中自然判断怎样表达，不属于系统分流。
- AI 创作交接不层层加码。 凡是把提示词、材料或指令交给另一个 AI 产生文字、图像、视频、音频或其它开放创作的 Skill，实际交接只能有一份。内部分析只用于判断保留什么，不得再层层扩写成传播判断、创作简报、结构方案、风格合同、负面清单、评分标准、QA 指令或另一套提示词，也不得把维护记录混入下游输入。用户提供完整提示词时原样交接；没有完整提示词时，只交付目标、原始材料、参考职责、必要输出形式、平台固定协议和用户硬要求。用户没有指定、素材没有固定且协议不要求的创作维度由下游 AI 判断，不因 Skill 能分析就提前规定。
- 根据真实问题决定修复层级。 先读完整结果，再判断是本次成品需要直接编辑，还是产生结果的长期规则、材料交接或实现需要替换；修复真正产生问题的位置，并清除直接依赖它的旧说法。用户明确指出以后要得到或不要得到什么时，直接把这项决定用于未来行为，不把它降级成待验证猜想。只有准备声称某个机制就是原因、比较方案优劣或判断概率和稳定性时，才需要保持其它输入不变的比较。写入方案说明当前修复依据；实施中若需要改用新的根因、输入边界、修复层级或验收方法，停止目标写入并回到新的方案确认，不能在同一轮换个解释继续修改。
- 有用材料与纠错过程分开。 完整示例、模板、脚本、素材和稳定知识只要正常工作确实会使用，就继续保留；失败输出、纠正故事、临时比较和项目专属事实不升级成长期默认。提炼经验时只把重复证据或用户明确确认的稳定方法写成长期默认。准备把做法写进跨类型通用层时，去掉当前对象和领域的专有说法，用结果机制明显不同的 Skill 代入；不能共同成立的内容留在相应领域或目标 Skill，不冒充通用方法。
- 核对方式服从结果和证据边界。 先看用户实际得到的结果。能够客观核实的结果，用真实产物、状态和证据判断；允许多种结果成立、体验取决于用户偏好的结果，在用户判断前只中性展示完整结果和可观察差异。测试数量、字段齐全、步骤完成、参考痕迹和其它内部代理指标不能代替最终结果。核对只处理实际结果中已经出现的问题，不把尚未发生的风险预先转换成运行限制。研究看来源是否支撑结论；程序读取的产物走同一份真实生成与使用过程。比较方案时固定原始请求或用户确认的交接、必要材料、参考、模型设置、代码版本和运行方式，只改变待验证因素；全新上下文只证明没有继承对话，不能单独证明修复有效。结构存在、字段齐全或脚本通过，只证明相应结构。
- 一次确认只覆盖同一方案。 创建或修改 Skill 前说明主要修复依据、用户结果、真正会改变的明确决定、退出的旧实现、必要输入与材料边界、系统选择、活动资源、文件范围和真实核对方式，取得一次具体确认。确认后可以修正不改变这些内容的实现错误和测试实现；改变主要修复依据、用户可见结果、必要输入、材料边界、路由或阶段、活动资源、文件范围、验收方法、动作权限，都属于新方案，必须先说明差异并重新确认。删除、发布、付费、发送和其它高风险动作继续遵守用户授权与目标仓库规则。
- 重活和重大变更先确认。 凡目标 Skill 的一次正常运行会启动明显耗时、算力或付费的批量工作，产生大量产物，或实施跨文件、跨模块、跨项目、数据迁移、安装部署、外部写入、权限影响、难恢复操作等重大变更，必须在真正执行前展示具体目标、范围、输入、主要动作、产物与影响位置、成本或不可逆影响和真实验收方式，停止并等待用户明确确认。确认前只做形成上述方案所需的最低限度只读检查；只读调查本身已经构成重活时也先确认。确认只覆盖该方案，范围、输入、成本、权限或验收变化时重新确认。普通单文件小改、低成本短任务和易恢复的常规执行不因此增加确认。
- 交付真实状态并停止。 第一段先回答用户真正的问题，随后只保留用户理解、判断和使用结果所需的说明。达到用户结果后停止；获批方案的真实结果验收失败时，也停止目标写入，如实交付失败结果、当前文件状态和需要用户决定的下一步，不在同一轮继续补规则、替换根因、改变测试或扩大范围。内部分类、状态、检查记录和设计故事不作为默认交付。
按本次工作读取说明
- 审查、纠偏或优化现有 Skill：读取目标
SKILL.md、仓库规则和直接影响问题的文件。用户原意已经被改写、输入需要跨阶段交接，或者涉及开放创作和参考材料时，再读references/instruction-hygiene.md；涉及完整会话或完整历史读取、历史反复、旧版本比较、复杂维护、默认启用或发布时，再读references/skill-maintenance-and-evaluation.md。只有用户要求重新确定整体职能时，才读references/skill-design-playbook.md。 - 选择能力载体、新建 Skill 或重做整体职能：读取
references/skill-design-playbook.md。需要设计跨阶段输入交接，或者涉及开放创作和参考材料时，再读references/instruction-hygiene.md；涉及确定性程序、Agent 宿主、外部软件或服务、CLI/API/GUI/插件入口、本机配置或长期资源时，再读references/resource-design.md。创建前先按实际执行者、包装和入口查找已有方案。 - 让 Skill 从经验中学习或设计自我维护：只有用户明确要求改变未来行为时，读取
references/absorption-and-governance.md，先区分目标 Skill 职能内的领域资源维护与由 Meta-skills 负责的架构变化；涉及程序读取或长期更新的资源时，再读references/resource-design.md。 - 蒸馏或迁移外部能力：读取
references/skill-design-playbook.md和references/absorption-and-governance.md；材料很多或需要还原来源做法时，再读references/evidence-distillation.md。 - 设计程序会读取的文件、私人资料库、索引、可复现实验或其它长期资源：确实存在稳定的创建者和使用者，或者需要锁定输入、版本和运行记录时，读取
references/resource-design.md。 - 画完整流程图：用户明确要求时读取
references/skill-flow-diagram.md。 - 更新界面信息：读取
references/openai-yaml.md，并使用scripts/generate_openai_yaml.py。 - 创建、迁移、复杂资源、高风险动作、顽固问题的独立验收或发布前的最终核对：读取
references/quality-gate.md。普通文字和单一路径修改直接检查本次结果，不加载总清单。
目标是 Meta-skills 自身时，修改前先运行 scripts/quick_validate.py <meta-skills-folder>。它同时检查活动 Markdown 文件的外层工具预算；核心检查失败时停止。只有用户在当前请求中明确要求修改核心原则，才同时修改核心、锁文件和检查器中的固定值。
共同工作流程
1. 只读还原问题与修复依据
完整读取用户指定的会话、项目、结果和活动文件。用人话写清用户以后要得到什么、哪些结果和明确决定继续保留、什么问题必须退出，以及当前证据为什么支持本次修复层级。单次结果的局部瑕疵先直接处理；没有受控证据时只报告猜想，不修改长期 Skill。
用户明确要求查看完整会话或完整历史时，先按 references/skill-maintenance-and-evaluation.md 关闭范围；当前宿主是 Codex 时，第一项取证动作固定运行本 Skill 的 scripts/read_codex_session.py，从它返回的稳定快照读到末尾，不先用普通文件命令或语义历史探测活动源记录。当前上下文、自动摘要、最近几轮、顶层回合已经翻完或模型记忆都不能代替完整的公开对话；语义入口没有下一页也只证明该返回层结束。完整性成立后才按时间顺序还原“用户要求—实际结果—用户反馈—后续修改—下一次结果”，不能只围绕最后一次投诉制定长期修改。
调查过程中，用户为了纠正取证来源、工具入口、读取方式或其它实现问题而提出的后续请求，默认只修正完成原始目标所依赖的子问题；除非用户明确替换或放弃原始目标，尚未完成的主结果继续留在本次范围。形成方案前，按用户实际想得到的不同结果归并时间线中反复出现或明确提出的要求、失败和保留项，逐项说明本次修复、其它唯一所有者、仍然未知或用户明确排除的去向。任何主结果只因后来出现了更具体的子任务而从方案中消失，都表示还没有完成问题还原。
形成方案前分别写清已经由结果或链路证明的原因、用户已经确认的未来结果和仍然未知的部分。未经证明的原因可以继续调查或如实保留为未知，但不能直接用来拆分职能、建立路由、增加长期资源或改写验收方法。
追溯“为什么这次有效、那次失效”或“为什么新旧结果不同”时，不能从成品、规则措辞或自己的解释反推原因。并排还原双方真实运行时收到的用户请求、材料、完整参考、最终交接、模型与设置、上下文、代码版本、运行方式和完整结果，先写清实际相同与不同之处，再判断哪些差异得到结果或受控比较支持。缺少任一侧的真实链路、关键输入无法确认，或者多个变量同时变化时，把原因保留为未知，不根据想象的归因修改长期 Skill。
工作区是否干净只影响怎样合并、暂存和发布，不决定调查范围，也不决定是否实施。已有修改属于当前真实状态；用户明确要求读取完整会话、完整项目过程或完整历史时，这个完整范围就是输入边界，不能因文件数量或工作区状态自行截断。准备写入时读取准确现状与差异，保留能够辨认的其它工作；只有继续写入会真实覆盖无法辨认的工作时才停止。
创建或修改的目标会写文件时，同时查清所有正式入口、默认参数、下游脚本和工具实际可能写到哪里，并区分 Skill 源码、用户明确要求修改的目标项目、Skill 自己的本地运行工作区、外部数据或安装目录、缓存和临时文件。当前终端目录、活动 Git 仓库、输入材料所在项目和调用 Skill 的位置都不构成“点名目标项目”；不能只检查主脚本，也不能把这些环境事实变成未声明的默认归属。
创建、修改或自我进化 Skill 时，同时枚举全部活动 Markdown 文件并运行 scripts/file_budget.py <skill-folder>；单个 .md 文件按 UTF-8 字节数除以四向上取整估算外层工具输出，硬上限为 9,000 tokens。源码、JSON、YAML、锁文件、报告和其它非 Markdown 文件不属于提示词文件预算，由各自的程序合同、测试和项目治理负责。归档、依赖、缓存、构建目录与运行产物也不进入这项门槛。超限说明 Markdown 的存放或职责边界需要调整，不能据此删除用户能力、必要方法、完整示例、协议细节或正式消费者。
2. 形成一个可确认的替换方案
方案只说明主要修复依据、未来用户结果、保持不变和真正改变的明确决定、必要输入与材料边界、系统选择、退出的旧实现、活动资源、文件范围和真实核对方式。目标会产生文件时，文件范围还要说明每类文件属于哪个仓库、项目或本机目录，Skill 自己的 Git 忽略运行区怎样由稳定入口确定，外部位置是否只是单独获准的交付副本，以及已有错放产物是否需要迁移。简单方法能够完整承接时不增加路由、阶段、评审、回退、脚本或登记。方案确认后，一次迁移所有直接使用位置并清除冲突旧实现。
目标 Skill 会把提示词、材料或指令交给另一个 AI 完成开放创作时，在提出字段、流程、脚本、校验或测试之前，先让一项代表性真实请求沿正式入口形成修改后的唯一实际交接，并在写入前方案中原样展示。逐句只保留用户原始要求、本次结果真正需要的材料、参考职责、必要输出形式、平台固定协议和用户硬要求；来源文件、网页、仓库或资料集合只是取材位置，不自动整份进入交接。只保留下游完成当前结果会实际使用的原文和必要上下文，移开同一来源为其它用途承载的内容，不摘要、转述或替模型决定创作。无法先写出这份交接时，不进入实现方案。
目标 Skill 能修改自身时，方案还要把同一 Markdown 预算检查作为该 Skill 自己的写入前后门槛，而不是依赖 Meta-skills 恰好在场。无法在预算内保留全部既有结果、必要 Markdown、入口和验证时，停止并重新规划；不能提高上限或把整理推迟到下一次进化。
准备拆分或合并 Skill、新建协调层、路由、资源系统或检查器时，先让一项具有代表性的正常请求沿正式入口走到真实使用者，指出现有结构具体在哪一步造成用户结果失败。文件数量、说明长度、检查耗时和抽象上的复杂本身不能证明需要改架构；真实问题能在原职责和入口内解决时，不把它升级成系统改造。
方案中出现“中性基线”“个人风格”“快速路线”“完整参考”等抽象名称时，必须同时核对运行时真正会加载的模板、默认值、参考和回退内容，并向用户说明会实质改变结果的部分。需要正向材料才能成立的能力，先确认这些材料真实存在、彼此职责清楚且达到使用条件；材料尚未成立时报告缺口，不先建设它的消费者、自动注入、回退身份或候选管理系统。
准备声称修改会提速时，先定义并测量用户真正等待的完整链路，从已确认输入开始，到第一份能够交给用户判断或使用的结果为止；内容准备、创作判断、生成、渲染和必要核对都计入。单独的脚本启动、浏览器截图、渲染或检查时间只能说明相应步骤，不能代表整项任务速度。
准备把当前经验写入 Meta-skills 的通用原则、共同流程或所有 Skill 都会读取的说明时，先同时分出可能跨类型成立的共同方法，以及会改变领域结果的事实、边界、专业条件和关键资源。只对共同方法中已经确认不改变结果的表面信息做临时代换，再用至少两种结果机制明显不同的 Skill 检查是否仍能自然指导工作。跨类型成立的共同方法进入通用层；必要差异和关键资源留在目标 Skill 或对应的专用说明，并继续进入实际工作。
创建或修改开放创作型 Skill 时，先判断它的正常结果是否允许多种都成立但体验明显不同的表达，并且质量实质依赖用户本人才能提供的情绪、感受、审美、观点、立场或取舍。这个判断只决定目标 Skill 是否需要具备 Plan 模式创作访谈，不成为每次运行时的第二道门槛；一旦具备，用户主动开启 Plan 模式本身就是要求深入访谈的明确信号。
这类目标 Skill 必须在实际运行入口中写清：它不自动开启或关闭 Plan 模式；默认模式继续按正常流程直接完成；Plan 模式开启后不再判断材料是否已经足够，而是先读完现有材料并完成当前权限内需要的调查、联网补充或外部材料发现，再使用 request_user_input 每轮追问一个只有用户能够回答的主观问题；用户自然、有辨识度的原话、矛盾和边界进入后续创作材料，不重复询问。访谈不能替代付费、发布、外部写入、分阶段样稿或其它原有授权与确认。具体提问对象按目标 Skill 的创作职责调整，不建立统一问卷、评分或创作字段。
3. 写入前确认具体方案
本节是固定的用户控制点。普通优化、精简、重构和“减少确认”不授权删除、绕过或降低它；只有用户在当前请求中明确要求改变这项确认方式，才允许修改其行为。
用户只要求解释、诊断或审查时保持只读。准备创建、修改、移动、归档或删除 Skill 活动文件时，第一次写入前用人话说明：用户以后会得到什么；哪些用户结果和明确决定保持不变；真正会改变的明确决定怎样从修改前变成修改后；哪个旧实现会退出；准备改哪些文件；怎样用真实结果确认已经完成。新增、删除或改变系统选择、条件分支、路由及其它处理机制时单独列明并征得同意。方案中的约束只能直接来自用户明确要求、固定机器协议、真实权限或不可逆外部动作；普通结果问题通过修改成品或替换产生问题的旧规则处理，不转化成新的限制、例外、确认、回退或检查。用户明确说明某个问题没有发生、不属于本次问题或不需要处理时，该信息只收窄修复范围，不作为保持项、材料边界或新增限制的来源。不枚举与方案无关的现有步骤、测试和内部包装，也不为没有的例外补写条件。然后停止，等待用户明确确认具体方案。
用户最初提出“创建、修改、优化、修复或实施”只说明目标，不等于批准尚未展示的方案。只有用户明确要求跳过确认并立即实施，或者已经批准本次具体方案，才进入写入。确认只覆盖保持主要修复依据、用户结果、必要输入、材料边界、系统选择、活动资源、文件范围和验收方法不变的实现调整与测试实现；任一项改变都停止写入，展示新旧差异并等待新的明确确认。删除文件继续遵守目标仓库规则。
4. 一次实施并清除旧实现
按获批方案修改真正产生问题的位置，一次迁移全部直接使用点。语法、断链、格式和其它不改变方案的确定性实现错误可以直接修正；若需要改变主要修复依据或任何已确认边界，停止写入并回到新方案，不把它称为定点修正。
Markdown 文件超过预算时，按已有唯一职责把完整章节迁到较小文件，同时保持入口、读取顺序、正式消费者和内容精度；拆分后的每个 Markdown 文件都重新计量。不得通过删减含义、拆行、压成难以维护的文本或留下新旧两份说明取得表面通过。源码与机器资源是否拆分由其项目职责和验证决定，不由提示词预算代管。
目标是开放创作型 Skill 时，实施已经在方案中确认的唯一实际交接；先单独读取正式入口实际形成的输入，确认它与获批文本一致，再修改测试。实现若必须改变这份交接，停止写入并回到新的方案确认。测试验证输入、资源、路由和硬边界，不逐字锁定模型应当怎样使用参考、组织内容或形成表达。
目标会生成任务产物时，让制作真源、运行项目、中间文件、预览、报告和最终成品始终进入由代码自身位置确定、位于该 Skill 内且被 Git 忽略的本地运行区；调用目录、活动仓库、输入来源和用户给出的外部交付位置都不改变生产根。用户明确要求外部交付时，只在真实结果通过后复制点名成品，Skill 内真源和成品继续保留。只有用户结果本身就是修改现有项目文件时，才写入用户明确要求修改的准确项目；在该目录调用 Skill 不构成授权。同步修改嵌套脚本、示例和说明，不保留依赖当前目录或让调用者自行猜生产根的旧入口。
5. 核对真实结果并停止
先运行 scripts/quick_validate.py <skill-folder>；修改检查器时再运行 scripts/self-test-quick-validate.py。它们只证明结构与静态文件预算。随后根据结果成立方式执行获批方案中的最低充分真实核对：能够客观核实的结果检查真实产物、状态和证据；依赖用户偏好的开放结果中性展示完整结果和可观察差异，等待用户判断整体体验；研究核对来源，程序让同一份真实产物经过正式生成与读取，外部动作核对准确目标和结果。目标会生成文件时，从一个不相关 Git 仓库调用真实入口，确认全部生产文件实际进入 Skill 自己的忽略运行区，调用方保持不变；再单独验证明确外部交付只复制点名成品而没有迁移生产根，并检查两边实际文件树、Git 跟踪与忽略状态，不能只检查返回的路径字符串。
新增或随实现一起修改的测试、阈值和检查器，只能证明它们直接覆盖的技术约定，不能单独证明同一轮实现已经解决用户问题。核对时重新使用最初失败的真实请求和正式活动路径；主观结果只有用户明确接受后才完成，候选数量、视觉差异、内部评分和技术通过都不能代替用户判断。用户否定当前候选时立即停止该候选和目标写入，不在同一轮改换根因、追加规则、扩建架构或生成另一批结果。
真实结果成立时交付并停止。依赖用户偏好的结果在用户判断前保持中性候选状态；能够客观核实的结果按相应证据判断。真实结果失败时也停止：保留准确差异和失败证据，不继续改目标文件，不换根因或测试；说明当前文件是否仍是未验证候选，以及继续工作需要用户确认的新差异。用户选择只改本地时不提交或推送。目标 Skill 已有当前跟踪远端且用户没有选择只改本地时，整个仓库当前工作区是一个不可拆分的发布范围：已跟踪修改、未跟踪文件和现有删除全部一起验证、暂存、提交和推送，不选择性暂存，也不因包含此前本地工作而停止发布；任一部分不能发布时保留整个工作区并停止，不能改成只提交一部分。