--- name: skill-evolver description: >- Researches and improves a specified existing Skill using successful/failed work and competitor evidence. Use for 优化这个Skill, 从成功和失败经验改进Skill, or 研究竞品后优化指定技能. Routine creation and editing use skill-creator. argument-hint: " [desired result or evidence]" --- # Daymade Skill Evolver Run a research-driven improvement round for a named existing Skill: identify what would improve its actual task results, evaluate relevant mechanisms, implement within authorization, and verify the resulting consumer behavior. An unchanged Skill is a valid outcome when the evidence supports keeping it. Keep optimization decisions here. Use Skill Creator for making and validating selected changes; it does not choose this round's business goal or research plan. When the request is diagnosis-only, remain read-only. ## Resolve the target and result Resolve the named Skill to its authoritative repository or project source, current release identity, and actual loaded entry when relevant. Read its entry and the resources used by the affected jobs. Distinguish source, installed copies and host consumption; do not edit a cache as if it were the owner. State the user-visible result, the observation that could disprove it, supported jobs to preserve, authorized deliverables, and stopping condition before selecting improvements. Include the original reported failure. Do not replace it with a research report, a shorter prompt, a score, or green checks. Ask only for missing information or a user-owned choice that changes the work; reuse existing answers and authorization. Keep the outcome criterion stable while comparing candidates. Correct a proxy against the original requirement before accepting an improvement; do not move the goal to whichever output the candidate already produces. ## Gather evidence that can change a decision Start with current implementation, project decisions, existing tools/Skills, provided examples, and previously verified work. Reuse evidence whose source and conditions still apply. Load [evidence to change](references/evidence-to-change.md) before interpreting historical cases or positive opportunities. For authorized history, use the owning index and exact reader. Bound the sessions, time window or candidate set before reading content. Distinguish user instructions, observed outputs and an author's later report. Omit hidden reasoning and prepare redacted, source-anchored inputs before delegation. Missing index coverage is a specific evidence gap; do not replace it with an unbounded raw-history scan. Include successful work and user corrections as well as errors. A positive opportunity does not require an earlier failure in our Skill. Use the reference's matched-case route for a diagnosed deviation and its opportunity route for a successful or external mechanism. ## Research the target's task capabilities Choose sources by the business result and the target's actual task surface, including important input, error, recovery and downstream-consumer paths. Search existing assets and supplied/configured favorites before external tool or method selection. Discover relevant competitors by capability, not only by the current Skill name. Include a candidate that could disprove the preferred approach. Bind repository-backed comparisons to an immutable source ref and the relevant edition or shipped artifact. Trace the real execution entry through normal, failure, recovery and consumer paths before borrowing a mechanism. Cite the source location and distinguish source-contract facts from exercised behavior and unmeasured business benefits. Use current first-party material for external contracts. Use Deep Research when unresolved breadth or synthesis needs it; do not force a provider, paid mode or report length. Keep the research questions and discovered mechanisms before constructing the final comparison. Stop retrieval when remaining answers cannot change selection or required acceptance. A narrow repair decided by an existing contract and reproducible probe does not need unrelated research lanes. ## Decide every important mechanism Give each important discovered mechanism an explicit disposition: adopt, do not adopt, or needs verification. Attach its evidence, fit conditions, expected increment over the current owner, cost, falsifier and reopening condition. Read counterevidence before treating repeated endorsements as causal proof. Preserve useful existing mechanisms; do not manufacture changes to fill a comparison. Use the reference to distinguish a missing mechanism, a correct mechanism not loaded or bypassed, a wrong acceptance criterion, an implementation defect, and a stale constraint. Fix the smallest maintenance point that changes the next execution. If an existing owner already covers the need, repair its loading or invocation instead of duplicating it. Combine compatible improvements; leave major direction, new product scope, real preferences and irreversible/external choices at their existing authorization boundary. Choose and execute necessary local reversible implementation details within the authorized target work. ## Implement and verify the selected changes Freeze the complete target bundle from an immutable source before editing. Preserve its triggers, supported jobs, interfaces, confirmation points, recovery paths and user-owned data. Work in an isolated source checkout when the shared checkout carries other work. Keep the target's source and directly affected instructions, examples, help and caller routes aligned. Inventory affected runtime defaults and side effects before replacing a mechanism, including read/write behavior, access permissions and generated-output locations. Preserve them unless the authorized improvement explicitly changes them and its acceptance checks cover that change. Do not infer a new requirement from a general security preference. Use the repository's normal change workflow and the available Skill Creator making/verification tools. Classify changes by their actual failure surface; new capability or methodology does not automatically authorize paired evaluation, benchmarking, repeated trials, a viewer, or extra agents. Verify the original result through its real consumer, including the affected failure and recovery path. Check important old jobs against the frozen bundle. Separate static preservation from task-result evidence. Calibrate acceptance with known healthy and failing cases; missing inputs and empty values are distinct when the rule examines them. Source reading, a subprocess exit, tests or CI may support a claim but cannot substitute for the result being requested. Complete authorized delivery through the target repository's release and local availability procedures. Read back the exact published or consumed object when that is part of the requested result. Keep human acceptance unconfirmed when it has not been observed; still finish the authorized implementation and checks. ## Use available executors without losing the result Discover installed specialist Skills by capability when useful: history readers, favorites-search, competitors-analysis, deep-research, tech-selection and skill-creator. Resolve their installed identity and load their current contract; do not copy their engines or assume a sibling file ships in this standalone plugin. Delegate only under current authorization and host capabilities. If a specialist is absent, use available tools for the same substantive work: read bounded supplied records, inspect fixed source objects, run the needed probe, compare trade-offs, or edit and validate the canonical source. Do not invent a specialist invocation or claim its gate passed. If a required source, permission, runtime or consumer is unavailable, pause only that dependent item, name the missing observation and resume condition, and continue independent authorized work. Missing optional tooling does not waive a required outcome. ## Stop and leave an incremental continuation Report the actual improvement or evidence-backed no-change decision, the exact source/diff and result evidence, and the remaining unmet criteria. Keep source, publication, installation, prepared-task runs and live business results distinct. Update only changed decisions and source anchors in the target project's existing canonical document when one exists. Keep reusable corrections in their owning Skill; preserve raw historical records as history. Leave the next unmet action and its reopening condition in the existing task context rather than creating memory or a second state ledger. Resume from that action instead of repeating settled research. Stop when required results and delivery are verified, or when only explicitly blocked items remain; do not start an automatic improvement loop.