Source-linked AI summary
Hierarchical Skill Evolution for Coding Agent
Jun Gao, Yun Peng, Changhai Zhou, Yuhan Zhu, Xiangyu Zeng, Shiyang Zhang Yuhua Zhou, Luozheng Qin, Qian Qiao, Xiaoteng Ma, Baian Chen Weiyi Shang, Zhen Ming Jack Jiang, Lizhi Liao, Xiaoxue Ren
TL;DR
Coding trajectories contain reusable experience but are entangled with task- and repository-specific context, complicating the distillation of skills that generalize. HSE hierarchically aggregates evidence to evolve transferable skills with an external writer–evaluator loop, and its frozen skill library improves results across the evaluated benchmarks, models, and harnesses.
Problem
Coding trajectories mix reusable repair procedures with task- and repository-specific context, leaving the appropriate level of evidence aggregation for generalizable skills unresolved.
Source: §1 · p. 1Method
HSE aggregates task evidence within repositories and then across repositories into procedural and recovery skills, using an external writer–evaluator loop while keeping the coding model frozen.
Source: §1 · p. 2, §4.3 · p. 5Results
The frozen HSE skill library improves over No Skills across SWE-bench Verified and DeepSWE under both evaluated harnesses and remains useful with GPT-5.5 and Opus 4.8 under Pi.
Source: §6 · p. 9Takeaways & Limitations
Ten skills evolved solely on SWE-Gym transfer across the evaluated benchmarks, coding models, and agent harnesses, while target-benchmark adaptation yields further gains.
Source: §1 · p. 2, §6 · p. 9Cross-model evaluation with GPT-5.5 and Opus 4.8 is conducted only under Pi.
Source: §6 · p. 9
Abstract
from arXiv · showhide
Skills provide agents with reusable experience to guide future decisions without modifying the underlying model. However, coding trajectories are often entangled with task- and repository-specific contexts, making it challenging to distill procedural skills that generalize across diverse coding environments. To address this challenge, we present Hierarchical Skill Evolution (HSE), which progressively distills procedural knowledge from coding trajectories through hierarchical evidence aggregation. HSE first extracts task-level evidence from individual trajectories, then aggregates recurring evidence within the same repository to form repository-specific skill candidates, and finally consolidates consistent patterns across repositories into transferable skills across repositories. The evolution is driven by an external writer-evaluator loop that generates and assesses skills while keeping the underlying coding model frozen. The loop externally updates the writer and evaluator policies to improve subsequent skill generation and assessment. This hierarchy progressively filters task-specific details while preserving procedures that generalize across diverse coding environments. Successful trajectories yield reusable guidance for future tasks, while failed trajectories reveal recurring failure modes that guide avoidance and recovery. We evaluate HSE on SWE-bench Verified and DeepSWE, using GLM-5.2 across Pi and Claude Code harnesses and GPT-5.5 and Opus 4.8 with Pi. Across both benchmarks, 10 skills evolved solely from SWE-Gym improve coding performance across all evaluated settings, demonstrating transfer across benchmarks, coding models, and agent harnesses. We further evolve the skill library from target-benchmark trajectories without verifier feedback, relying solely on the learned evaluator for candidate assessment and achieving additional gains through benchmark-tailored skills.
1 INTRODUCTION
Coding trajectories contain reusable repair experience but also task- and repository-specific details, making generalizable skill extraction difficult. HSE aggregates evidence hierarchically and evolves skills that improve performance across evaluated benchmarks, models, and harnesses.
1 INTRODUCTION
- Trajectories offer reusable repair experience, but their task- and repository-specific context makes it difficult to distill procedures that generalize.The central challenge is choosing an aggregation level that removes specific details without losing the useful procedure.Source: §1 · p. 1
- HSE aggregates task evidence into repository-level patterns and then cross-repository procedures, while evolving successful evidence into procedural skills and recurring failures into recovery skills.An external writer–evaluator loop also updates the policies governing skill generation and assessment while the coding model stays frozen.Source: §1 · pp. 2–3
- In django django-16950, the selected No Skills and SWESkillsBench traces make an incomplete repair, while the HSE trace produces a conditional fix preserving primary-key and non-primary-key behavior.The agent identifies the behavioral boundary from current code and tests, rather than simply removing the offending operation.Source: §1 · p. 2
- Ten skills evolved solely on SWE-Gym improve over No Skills and baselines across SWE-bench Verified and DeepSWE, including evaluations with multiple models and harnesses.The evaluation includes GLM-5.2 under Pi and Claude Code, plus GPT-5.5 and Opus 4.8 under Pi.Source: §1 · pp. 2–3
2 RELATED WORK
Prior work reuses agent experience and evolves skills or prompts, but HSE distinguishes itself by aggregating procedural evidence from tasks through repositories to cross-repository skills.
Learning from Agent Experience
- Agent-experience methods reuse reasoning, feedback, executable skills, extracted insights, routines, or successful and failed trajectories, while coding retrieval can return prior trajectories.These approaches motivate experience reuse, but the passage distinguishes them from HSE’s task-to-repository-to-cross-repository procedural aggregation.Source: §2 · p. 3
Skill and Prompt Evolution
- HSE’s distinguishing approach is task-to-repository-to-cross-repository aggregation of procedural evidence into a separately deployable skill library.The related-work discussion contrasts this aggregation with trajectory retrieval and other skill- or prompt-evolution approaches.Source: §2 · p. 3
- Skill and prompt evolution includes hierarchical skill-patch merging, bounded skill updates, skill extraction and curation, skill-package management, and prompt optimization.The passage contrasts HSE’s updates to writer and evaluator policies with approaches that optimize prompts or learn policies alongside skills.Source: §2 · p. 3
3 PROBLEM FORMULATION
HSE treats issue resolution as trajectory-based evidence collection without updating the coding model. It groups evidence within repositories and across repositories to produce assessed candidates and transferable skills.
3 PROBLEM FORMULATION
- An issue-resolution task combines an issue description, repository snapshot, and execution environment; the agent’s tool calls and observations form a trajectory.HSE evolves reusable skills and the rules that construct them without updating the coding model.Source: §3 · p. 3
- Task evidence records pair trace-derived execution signals with a summary of the observed outcome.The record is defined as z_i = (e_i, y_i), with e_i = ϕ(τ_i) and y_i = ψ(τ_i).Source: §3 · p. 3
- At L2, the writer and evaluator use repository-grouped task records to form a repository-conditioned candidate and assess it as accept, revise, or reject.The repository is the intermediate aggregation level between individual tasks and cross-repository skills.Source: §3 · p. 3
- At L3, accepted repository evidence and recurring failure signatures are consolidated into transferable procedural and recovery skills.The writer proposes cross-repository candidates, and the evaluator checks their support, scope, and safety before promotion.Source: §3 · pp. 3–4, Figure 2 · p. 4
4 HIERARCHICAL SKILL EVOLUTION
HSE turns frozen-agent trajectories into skills through task-, repository-, and cross-repository evidence aggregation, with an external controller updating candidate-generation and assessment rules. Validation governs transfer and further evolution.
4 HIERARCHICAL SKILL EVOLUTION
- HSE iterates through task, repository, and cross-repository evidence aggregation while updating external writer and evaluator rules, then validates the proposed state before transfer.The coding agent remains frozen during this process.Source: §4 · p. 4
4.1 L1: AGENT ROLLOUTS AND TASK EVIDENCE
- L1 labels each trajectory with repair-stage evidence and verifier outcomes; outcome transitions set evidence strength, and recurring negative evidence contributes to recovery-skill construction.Failed-to-successful and successful-to-failed transitions are strong positive and strong negative evidence, respectively; unpaired first-round outcomes are treated as weak evidence.Source: §4.1 · pp. 4–5
4.2 L2: REPOSITORY-CONDITIONED CANDIDATES
- L2 requires repeated positive evidence and a recurring repository signal, while strong negative evidence constrains promotion; the evaluator accepts, revises, or rejects structured candidates.Candidates specify a trigger, evidence gate, recommended actions, validation steps, and stop condition.Source: §4.2 · p. 5
4.3 L3: TRANSFERABLE SKILLS
- L3 converts patterns supported across repositories into transferable procedural skills and separately turns recurring unresolved failure signatures into recovery procedures.The evaluator checks cross-repository support before promotion, filtering repository-specific details while retaining supported procedures.Source: §4.3 · p. 5
4.4 WRITER AND EVALUATOR RULE UPDATES
- Writer rules shift candidate construction toward recovery and validation when unresolved evidence accumulates, while evaluator weights change from feedback and decision thresholds remain fixed.Regression associated with a promoted candidate increases penalties on contributing negative or risk signals; later positive support can increase previously undervalued signals.Source: §4.4 · pp. 5–6
4.5 HELD-OUT VALIDATION AND TRANSFER
- HSE evaluates the proposed library on held-out tasks before accepting an evolution state; accepted states transfer skills to the frozen agent and rules to the external controller.When validation rejects a proposed state, the current accepted version is retained.Source: §4.5 · p. 6
4.6 TRAINING, STATIC INFERENCE, AND TARGET-BENCHMARK ADAPTATION
- Static inference freezes the learned state and gives the coding agent only the skill library; target adaptation updates that library from target trajectories using the learned evaluator without verifier outcomes.The target-adaptation setup also excludes evaluation-time test results from candidate assessment.Source: §4.6 · p. 6
4.7 CASE: CONDITIONAL REPAIR IN THE HSE TRACE
- In the django trace, a PK-only reset fixes the reproducer but fails an initialization check; the final conditional repair preserves both primary-key and non-primary-key behavior and passes focused tests.The skill advises minimal edits, focused validation, and re-localization when a failed test contradicts the current repair direction.Source: §4.7 · p. 6
5 EVALUATION
The evaluation tests frozen transfer, target-benchmark adaptation, component contributions, and generalization across harnesses and models on SWE-bench Verified and DeepSWE. Across these settings, HSE improves over baselines, and adaptation further raises resolved rates.
5 EVALUATION
- The evaluation uses 500 SWE-bench Verified tasks and 113 DeepSWE tasks, measuring resolved rate as the percentage of tasks with a successful verifier outcome.GLM-5.2 is evaluated with Pi and Claude Code; cross-model evaluation also uses GPT-5.5 and Opus 4.8 with Pi.Source: §5 · p. 7
5.1 STATIC INFERENCE
- HSE has the highest mean resolved rate across four benchmark–harness settings, beating No Skills by 1.9–4.5 points on SWE-bench Verified and 5.6–7.7 on DeepSWE without target adaptation.It also exceeds the strongest baseline by 0.7–0.9 points on SWE-bench Verified and 2.1–3.5 on DeepSWE.Source: §5.1 · p. 7
5.2 TARGET-BENCHMARK ADAPTATION
- By Gate 8, resolved rate gains reach 14.7 and 13.3 points on SWE-bench Verified, and 23.0 and 23.3 points on DeepSWE, for Pi and CC respectively.Mean resolved rate increases at every reported gate across all four settings.Source: §5.2 · p. 7, Table 2 · p. 8
5.3 COMPONENT ANALYSIS
- Removing procedural skills costs 1.2 and 3.6 points on SWE-bench Verified, while removing recovery skills costs 5.3 and 5.6 points on DeepSWE.The authors hypothesize that harder DeepSWE tasks make recovery guidance more beneficial; removing both recovery skills leaves HSE just 0.3 and 2.1 points above No Skills on DeepSWE.Source: Table 3 · p. 8, §5.3 · p. 8
- Removing hierarchical aggregation reduces performance by 1.2–2.0 points on SWE-bench Verified and 1.8–3.8 on DeepSWE; freezing controller updates also reduces performance.The respective losses from freezing controller updates are 0.6–1.4 and 1.8–2.1 points.Source: §5.3 · p. 8, Table 4 · p. 9
5.4 GENERALIZATION ACROSS HARNESSES AND MODELS
- Across harnesses, fixed HSE packs improve over transfer-harness No Skills by 3.1–7.3 points, with changes of −2.1 to +3.8 points relative to source-harness HSE.The transferred packs remain useful across both harnesses.Source: Table 5 · p. 9, §5.4 · p. 9
- With Pi, the same HSE pack improves GPT-5.5 by 2.8 points on SWE-bench Verified and 6.3 on DeepSWE, and Opus 4.8 by 1.6 and 1.8 points, respectively.These gains support reuse beyond GLM-5.2.Source: Table 6 · p. 9, §5.4 · p. 9
6 LIMITATIONS AND CONCLUSION
The frozen HSE library transfers across both benchmarks and evaluated harnesses, with further gains from target-benchmark adaptation and contributions from multiple components. The authors note limits in cross-model and controller-ablation coverage.
6 LIMITATIONS AND CONCLUSION
- Cross-model evaluation with GPT-5.5 and Opus 4.8 is limited to Pi, while the controller ablation evaluates the writer–evaluator update mechanism as a whole.Source: §6 · p. 9
- The frozen HSE library improves over No Skills on SWE-bench Verified and DeepSWE under both evaluated harnesses and remains useful with GPT-5.5 and Opus 4.8 under Pi.Target-benchmark adaptation yields further gains as target-task experience accumulates; analyses also show contributions from procedural and recovery skills, hierarchical aggregation, and controller updates.Source: §6 · p. 9
AI USE STATEMENT
- Generative AI assisted with manuscript drafting and polishing.Source: AI USE STATEMENT · p. 9
REPRODUCIBILITY STATEMENT
- Appendices C, D, and E provide the motivating-example materials, method implementation, and experimental protocol, respectively.Source: REPRODUCIBILITY STATEMENT · p. 10
A COST OF TRANSFERABLE SKILLS
HSE reduces context word counts relative to SWESkillsBench, although it still uses more words than No Skills. The accompanying evidence rules specify how task and repository evidence is constructed and screened before candidates are promoted.
A COST OF TRANSFERABLE SKILLS
- HSE uses approximately 34% and 39% fewer total words with Pi on SWE-bench Verified and DeepSWE, respectively, versus about 6% and 3% with CC, relative to SWESkillsBench.HSE still uses more total words than No Skills in all four settings; prefilling dominates word totals, and a compact skill context can coexist with a longer interaction sequence.Source: A COST OF TRANSFERABLE SKILLS · p. 13, Table 7 · p. 13
B EVIDENCE RULES
- Task-level evidence combines trace-visible tool interactions and accessed skill resources into five repair phases, each recording a trigger, actions, evidence to collect, and stop condition.Invalid model outputs fall back to deterministic template-based construction.Source: B EVIDENCE RULES · p. 13
- Repository-conditioned candidates require at least two positive task records and a recurring observable repository signal; candidates with prohibited information are rejected by a hard-safety filter.Strong negative evidence acts as a regression constraint, and fixed evaluator thresholds determine acceptance, revision, or rejection.Source: B EVIDENCE RULES · pp. 13–14
C MOTIVATING EXAMPLE: SKILLS AND SELECTED TRAJECTORIES
- The appendix documents the Django django-16950 motivating case with skill documents, source patches, and selected consequential trace events, including failed repairs and corrections.Source: C MOTIVATING EXAMPLE: SKILLS AND… · p. 14
C.1 TASK CONTEXT AND THE STATE DISTINCTION
- The motivating task distinguishes an auto-increment primary key from a separate default-valued UUID referenced by an inline child; clearing the UUID can cause a NOT NULL save failure.The instance value and a form field’s initial value are separate state, while default-valued primary keys have a regeneration path on save.Source: §C.1 · pp. 14–15
C.2 SKILL DOCUMENTS
- The reproduced SWESkillsBench Django document includes framework examples but does not specify how BaseInlineFormSet should distinguish primary-key from non-primary-key UUID state; HSE’s skill emphasizes fresh evidence, minimal edits, focused checks, and re-localization.Source: §C.2 · p. 15
C.3 TRACE READING CONVENTION
- Trace prefixes N, S, and H identify original step ids within No Skills, SWESkillsBench, and HSE traces; they are not aligned time or compute units.Source: §C.3 · p. 15
C.4 NO SKILLS: LOCAL TESTS PASS, BUT THE PATCH REMOVES A PK INVARIANT
In the No Skills trace, a repair that preserved the reported non-primary-key UUID also preserved default-valued primary keys, removing an existing behavior. The SWESkillsBench trace retries but retains the same core executable change.
C.4 NO SKILLS: LOCAL TESTS PASS, BUT THE PATCH REMOVES A PK INVARIANT
- The No Skills trajectory’s broad test selection ran 1,583 tests, with 51 skipped, but passing local tests did not expose the primary-key behavior regression.Source: §C.4 · p. 16
- The No Skills final repair preserves the non-primary-key UUID but also preserves default-valued primary keys that the old branch reset, and visible tests do not detect this instance-level regression.The form and formset can be valid while saving fails with a NOT NULL constraint; later testing records a failure before the edit is restored.Source: §C.4 · pp. 15–16
C.5 SWESKILLSBENCH: RETRIES OCCUR, BUT THE SAME CORE EDIT REMAINS
- In the selected SWESkillsBench trace, a visible old-primary-key test passes, yet the final evaluation later fails a strengthened version of that same old-behavior test.Source: §C.5 · p. 17
- The No Skills and SWESkillsBench patches share the same core executable change, despite differences in comments and added test code.Source: §C.5 · p. 17
C.6 HSE SKILLS: LOCAL FAILURE, FURTHER INSPECTION, AND CONDITIONAL REPAIR
The HSE trace uses focused reproduction and further source inspection to refine an initially incomplete repair. Its final conditional change preserves non-primary-key instance values while resetting primary keys before field construction.
C.6 HSE SKILLS: LOCAL FAILURE, FURTHER INSPECTION, AND CONDITIONAL REPAIR
- The HSE trace’s one-test reproducer passes and retains the non-primary-key UUID before and after saving, but the existing UUID suite then fails because the inline field’s initial value is not None.Source: §C.6 · p. 18
- Inspection shows the inline field initializes from the referenced parent attribute, while the save hook generates a default for a missing primary key, supporting distinct handling of these states.Source: §C.6 · pp. 18–19
- The focused UUID tests pass with the reproducer, which prints the same non-primary-key UUID before validation and after saving; broader validation reports 1,108 tests run with 14 skipped.Source: §C.6 · p. 19
- The final patch resets default-valued primary keys before field construction, preserves non-primary-key instance values, and clears only the constructed form field’s initial value.This ordering avoids the field capturing the old primary key as its initial value.Source: §C.6 · pp. 19–20
C.7 BENCHMARK VERIFICATION AND ADDED ASSERTIONS
This section presents Django skill materials covering API and data-handling patterns, maintainability, and repository-guided editing and recovery. It also reports benchmark verification with primary-key assertions and reproduces a complete Django skill.
C.7 BENCHMARK VERIFICATION AND ADDED ASSERTIONS
- Two assertions check that the formset instance UUID and the first form instance’s parent_id are None.The UUID is the test model’s primary key, not the issue’s non-primary-key id field, Thing.Source: §C.7 · p. 21
- HSE Skills passes the added check, while No Skills and SWESkillsBench fail its first assertion because their patches retain the parent primary key.The first assertion checks that the formset instance UUID is None; the same assertions are used in all three final evaluations.Source: §C.7 · p. 21
C.8 COMPLETE SWESKILLSBENCH DJANGO SKILL
- The reproduced SWESkillsBench django-patterns skill covers Django architecture, REST APIs, ORM practices, caching, signals, middleware, and production-grade applications.The appendix presents the complete skill, including its front matter, code examples, and quick-reference table.Source: §C.8 · p. 22
- The user serializer checks that password fields match, removes the confirmation field, and saves the password through Django’s password-hashing method.The example raises a validation error when the fields differ, then calls set_password before saving the user.Source: §C.8 · pp. 27–28
- The Product ViewSet combines filtering, search, and ordering with action-specific serializers and custom product actions.The examples also show an authenticated cart endpoint that returns an error for a missing product and a success response after adding one.Source: §C.8 · pp. 28–29
- The order service creates order items from cart contents, clears the cart, and provides payment-processing and confirmation-email routines.The payment example includes a gateway-integration placeholder and calls the order confirmation email routine.Source: §C.8 · pp. 29–30
- The examples apply caching at the view, template-fragment, and low levels, with cached product and category data assigned timeouts.They show a 15-minute view cache, a sidebar fragment cache, a 15-minute featured-products cache, and a one-hour category cache.Source: §C.8 · pp. 30–31
- User signals create and save profiles, while custom middleware updates authenticated users’ activity times and logs request timing and responses.The middleware examples record request start time and log method, path, response status, and duration.Source: §C.8 · pp. 31–32
- Performance examples contrast N+1 access with select_related and prefetch patterns, and include database indexing and bulk create or update operations.The closing pattern table also lists select_related and prefetch_related as foreign-key and many-to-many optimizations, respectively.Source: §C.8 · pp. 32–33
- The Django skill reminder prioritizes maintainable structure and organization over concise code in production applications.It cautions that Django shortcuts do not replace production-oriented maintainability.Source: §C.8 · p. 33
C.9 HSE PROCEDURAL SKILL
- The success-pattern skill is training-only and draws on five repositories, 11 repository events, and 37 verifier-positive task events.It is marked as a procedural prior rather than a repository-specific patch recipe.Source: §C.9 · p. 34
- The skill is evidence-gated: inspect the repository first, ignore mismatched guidance, and stop to re-localize if the diff drifts from the symptom.It cautions against copying historical paths or patch shapes, broadening edits merely because the skill was retrieved, or treating weak validation as success.Source: §C.9 · pp. 34–35
- The HSE skill treats repeated owner paths as localization priors, then uses current task evidence to select the narrowest supported path and make a minimal edit.It starts from the smallest public symptom and checks focused behavior before broad validation.Source: §C.9 · p. 34
D IMPLEMENTATION DETAILS
HSE keeps the coding model frozen while external policies manage skill construction and assessment. Its implementation aggregates evidence hierarchically and represents candidates as structured procedures.
D IMPLEMENTATION DETAILS
- HSE maintains its skill library and writer/evaluator policies outside the frozen coding model; external policies manage skill construction and assessment.The coding agent receives the exported skills.Source: D IMPLEMENTATION DETAILS · p. 35
D.1 HIERARCHICAL STATE
- The hierarchy records task-level evidence and outcomes before aggregating repository evidence into transferable cross-repository skills.The writer and evaluator operate at L2 and L3; L1 records verifier outcomes and outcome-transition labels.Source: §D.1 · p. 35, Table 12 · p. 35
D.2 CANDIDATE REPRESENTATION
- Candidates use a shared representation of trigger, evidence, actions, validation, and stop condition.The evidence gate specifies what must be observed before acting; the stop condition indicates when to abandon or re-localize a direction. The evaluator accepts, revises, or rejects candidates based on support, scope, and safety.Source: §D.2 · p. 35
E.1 TRAINING AND VALIDATION SPLIT
- The 500 sampled SWE-Gym tasks are split into 474 training tasks from ten repositories and 26 validation tasks from bokeh/bokeh, with no repository overlap.Sampling is approximately even across repositories; the split is approximately 95%/5%.Source: §E.1 · pp. 35–36
E.2 BENCHMARKS AND EVALUATION
The evaluation covers SWE-bench Verified and DeepSWE, measuring whether transferred skills resolve benchmark tasks. It compares a frozen skill library with target-benchmark adaptation using target trajectories but no verifier feedback to the policies.
E.2 BENCHMARKS AND EVALUATION
- A task is resolved when its patch passes the benchmark verifier; resolved rates use the complete benchmark of 500 SWE-bench Verified tasks or 113 DeepSWE tasks.Tables 13 and 14 provide per-run resolved counts underlying the static-skill and target-benchmark adaptation results.Source: §E.2 · p. 36, Table 13 · p. 36, Table 14 · p. 37
- Static HSE evaluates the transferred skill library without using target-benchmark trajectories to construct or update skills.The primary experiments use GLM-5.2 with Pi and Claude Code; No Skills and SWESkillsBench serve as baselines, and static HSE uses ten SWE-Gym-evolved skills.Source: §E.2 · p. 36
- Target-benchmark adaptation updates the skill library from target trajectories while keeping the transferred writer and evaluator policies fixed and withholding verifier outcomes from them.The protocol uses eight rounds, each with a complete benchmark rollout followed by one writer–evaluator update; the resulting library is evaluated on the same complete target task set.Source: §E.2 · p. 36
- Mean@3 summarizes resolved rates across three runs, with subscripts reporting their sample standard deviation using the R − 1 denominator.The reported benchmark denominators are N = 500 for SWE-bench Verified and N = 113 for DeepSWE.Source: §E.2 · p. 36
Related papers
This paper cites
- Self-Refine: Iterative Refinement with Self-Feedback2023
- Voyager: An Open-Ended Embodied Agent with Large Language Models2023
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering2024
- OpenHands: An Open Platform for AI Software Developers as Generalist Agents2024
- Training Software Engineering Agents and Verifiers with SWE-Gym2024
- SkillOpt: Executive Strategy for Self-Evolving Agent Skills2026