skill-evolver git:20261011.b7cf350A

Immutable. This exact content never changes and is served at /api/v1/blob/4c1774c5aaa00835.

---
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: "<target Skill> [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.