skill-evolver

Daymade Skill Evolver

通过当前的专业 Skills，为指定的现有 Skill 编排一轮以研究为依据的改进。将原始结果、阶段输入、依赖关系和返回的证据关联在一起。如果证据支持保持不变，那么不修改 Skill 也是有效结果。

在此处负责编排；专业工作由当前负责的所有者执行。Skill Creator 负责实施并验证选定的更改，不负责决定本轮的业务目标或研究计划。 如果请求仅限于诊断，则保持只读。

确定目标和结果

将指定的 Skill 定位到其权威仓库或项目源、当前发布标识，以及相关情况下实际加载的入口。阅读其入口和受影响任务所用的资源。区分源文件、已安装副本和宿主端使用情况；不要把缓存当作所有者来编辑。

在选择改进方案之前，说明用户可见的结果、可能证伪该结果的观察、需要保留的受支持任务、获授权的交付物，以及停止条件。包括最初报告的故障。不要用研究报告、更短的提示词、分数或绿色检查结果来替代它。只询问缺失的信息，或会改变工作的、由用户决定的选项；复用已有答复和授权。

比较候选方案时，保持结果判定标准稳定。接受改进之前，应针对原始要求校正代理指标；不要把目标改成候选方案已有的输出。

收集能够影响决策的证据

从当前实现、项目决策、现有工具/Skills、提供的示例和先前验证过的工作入手。如果证据的来源和条件仍符合当前所有者的约定，就复用该证据。执行选定阶段之前，加载阶段交接说明，并遵循其中适用的所有者路径；此参考说明规定了输入和返回结果，不是另一套专业流程。

根据用户明确的请求、已接受的路径和未解决的问题选择阶段。若已有决定性证据，范围有限的修复无需开展无关研究；但工作简单并不能免除用户要求的历史记录、收藏、竞品或 Deep Research 流程。准确标记复用、已执行、不必要和受阻的工作；不要把跳过的研究说成已完成。

针对每个选定阶段，预先确认有可用且能力匹配的所有者、相关分支、权限和所需数据；随后加载并执行该阶段。对于公开工作流，优先选择可用的公开所有者。传入原始用户目标、目标源/引用、过去成功的任务、授权、整理好的证据，以及需要解决的问题。执行该工作流，并检查实际证据或结果后再继续；只有所有者列表或加载回执，并不意味着阶段已完成。将缺口与依赖该缺口的决策关联起来，而不是根据建议重新整理一份证据列表。

对于已获授权的历史记录和整理好的案例（包括成功、失败和用户修正），使用 history-reader 和 Skill Creator 交接说明。发现积极改进机会，不要求本 Skill 之前曾失败。若请求是审计整个会话并梳理其中的经验，则使用公开的 history/Creator 交接说明；仅在可用时，将 session-retrospective 作为可选的本地适配器。一般的目标改进无需单独的回顾收据。

调研目标的任务能力

将研究问题与业务结果以及目标的输入、错误、恢复和下游使用者路径关联起来。在选择外部工具或方法之前，先通过参考资料的整理交接，使用可访问的收藏搜索功能或提供的精选链接／导出内容。对于当前条目范围内有代码支持的对比，使用 competitors-analysis 的来源和综合分析路径；对于没有代码的手动／原生工作流，使用原始产品文档、提供的观察结果或任务探查。将与来源绑定的机制和反证带回本轮；不要用功能列表替代负责人的决策链。

对于请求的研究方向或尚未解决的广度／综合分析，执行 deep-research，并遵循其当前的资产、模式和来源约定。复用已接受的路径和现有原始导出；不要强行指定提供商、付费模式或报告长度。当剩余答案已无法改变选择或必需的验收结果时，停止检索。汇总返回的证据时，将来源约定中的事实、实际测试过的行为和未经测量的业务收益分开。

决定每项重要机制

在提出改进诊断之前，使用 Skill Creator 适用的常规更新或跨任务改进交接，并将每个重要候选方案与目标当前的决策路径进行比较。说明现有机制及其来源、拟议的决策变更、该发现属于机制缺失、现有行为尚未执行、证据缺失还是正向机会，以及一项不应应用此变更的条件。若没有证据支持的增量改进，则复用当前机制。

将未知或不确定的收益与“没有值得追求的价值”的证据分开。将尚未排序的线索与修复或投资建议分开；证据充分时允许停止。在比较或进一步研究能够改变决策，或满足明确要求的研究方向时，才进行相应工作。保留有限范围内的机会探索，不要求此前必须有失败；也保留已有充分依据的修复，不强制设置竞品评审关卡。让指定的辅助工具仅用于其实际适用的条目范围；若普通工具也能完成同等工作，则应将其设为可选。

对于有代码支持的竞品研究，使用 competitors-analysis 的 Landscape 交接，根据其现有处置约定，将发现的每项重要机制归类为采用、不采用或需要核实。结合原始问题和来源检查返回结果的覆盖情况，包括正向机会和现有等效机制；不要凭空制造变更。

必须选择技术方案时，结合汇总后的证据和当前授权，执行 tech-selection 适用的完整或轻量流程。将其实际选择或尚待用户决策的事项带入实施阶段。如果现有负责人已覆盖所需内容，应修复其加载或调用方式，而不是重复实现。组合兼容的改进；重大方向、新产品范围、真实偏好和不可逆／外部选择仍须遵守现有授权边界。在已授权的目标工作范围内，选择并执行必要的本地可逆实施细节。

实施并验证选定的变更

在编辑前，从不可变来源冻结完整的目标包。 保留其触发条件、支持的任务、接口、确认点、恢复路径和用户拥有的数据。如果共享检出中包含其他工作，请在隔离的源代码检出中操作。确保目标的源代码以及直接受影响的说明、示例、帮助内容和调用方路径保持一致。

替换机制前，清点受影响的运行时默认值和副作用，包括读写行为、访问权限和生成输出的位置。除非授权改进明确要求变更这些内容，且其验收检查覆盖该变更，否则予以保留。不要根据一般安全偏好推断出新要求。

按照仓库的常规工作流，为选定变更执行 Skill Creator 的制作、迁移和验证交接。传递冻结的业务标准、旧任务以及默认值／副作用，作为必须保留的要求。由目标的执行负责人针对其实际使用方和恢复检查负责；不要把判断整合后的结果是否满足请求的责任推给他人。根据变更实际的故障范围对其分类；新增能力或方法并不会自动授权配套评估、基准测试、重复试验、查看器或额外的 Agent。

通过实际使用方验证原始结果，包括受影响的故障和恢复路径。根据冻结的目标包检查重要的旧任务。将静态保留情况与任务结果证据分开。使用已知正常和失败的案例校准验收标准；当规则会检查输入时，缺少输入和空值是两种不同情况。阅读源代码、子进程退出、测试或 CI 可以作为佐证，但不能代替对所请求结果的验证。

按照目标仓库的发布和本地可用流程，完成获准的交付。如果所请求的结果涉及确切的已发布或已使用对象，则读取并核对该对象。对于尚未观察到的人为验收，保持未确认状态；但仍须完成获准的实施和检查。

使用可用执行器，且不丢失结果

通过可用的技能搜索，按能力解析所选所有者；如果没有技能搜索，则检查当前主机目录和用户声明可访问的来源。Evolver 仅随附自身套件，不包含配套 Skills。公开可用并不能证明已安装、分支已就绪或能够访问所需数据。不要要求访问我们的私有仓库、凭据或本地配置。不要自动安装或克隆某个所有者，也不要覆盖主机禁用 Skill 的策略。对于尚未安装的公开所有者，请使用公开目录和安装指南确定其实际插件包，或使用可用的同等所有者或工具；不要编造已成功调用的说法。

同一个 Agent 可以按顺序加载并执行 Skills。在授权委派或并行执行独立工作流之前，遵循当前用户／主机约定和公开所有者的委派／验证工作流。只有在可选的本地适配器 daymade-agent-discipline 已存在且可访问时，才应用它；依赖阶段应等待所需证据。 默认情况下，不要为每个 Skill 分配一个 Agent，也不要在此处复制所有者的引擎。

缺少调用工具并不意味着已解析的 Skill 不存在：读取其当前条目，并使用可用工具执行适用的工作流。

如果缺少某个专家，则使用可用工具完成相同的实质性工作：读取有界范围内提供的记录、检查固定源对象、运行所需探测、比较权衡，或编辑并验证规范源文件。不要编造专家调用，也不要声称其关卡已通过。如果所需来源、权限、运行时或使用方不可用，只暂停依赖该项的工作，说明缺少的观察结果和恢复条件，并继续执行独立且已获授权的工作。缺少可选工具并不能免除必需结果。

停止并留下增量续接信息

报告实际改进或有证据支持的未变更决定、确切的源文件／差异和结果证据，以及尚未满足的标准。明确区分源文件、发布、安装、预备任务运行和实时业务结果。

如果目标项目已有规范文档，只更新其中变更的决定和源文件锚点。可复用的修正应留在所属 Skill 中；原始历史记录应保留为历史记录。在现有任务上下文中写明下一项未完成操作及其重新开启条件，不要新建记忆或第二份状态台账。恢复时从该操作继续，不要重复已定论的研究。所需结果和交付内容验证完成后，或仅剩明确受阻的事项时，停止；不要启动自动改进循环。