Skill Adaptation (a Meta-Skill): Rewriting Agent Instructions to Match the Executor Model's Capabilities

MODE A — one edit, no logs (a strong model edits the skill for a weak one)
INPUT:  task + original skill + executor's tool list
STEP 1: Tools → separate callable tools from documents,
        add an environment check and actions for typical errors
STEP 2: Context → open with the task, the edit boundaries, and the delivery path;
        separate the task from examples; paste the needed material right into the skill
STEP 3: Requirements → each gets: action + object + done condition
STEP 4: Verification → finish with an independent check:
        reread, recompute another way, compare against a threshold,
        repeat until it passes
OUTPUT: the rewritten skill (or the original, if there's nothing to fix)

MODE B — self-improvement loop (5 rounds, requires logs and a verifier result)
RUN → logs + verifier verdict → edit the skill using the same 4 rules,
earliest failure first → next run

Mode A is a single request. Mode B is a separate request for each round.

Task: You run marketing at an online store. The skill “build the weekly ad report from a Google Ads export in Excel” was written for a top model. Now the routine has been handed to a cheap model so you don't pay premium rates for every run. It keeps “calling the xlsx tool,” delivering the report without recomputing ROI, or saving the file in the wrong place.

Prompt:

You are rewriting an agent's skill so that a weaker model can carry it out.

<Task>
Every Monday the agent takes the Google Ads export (file ads_week.xlsx in the /input folder),
calculates spend in dollars, clicks, CPC, and ROI for each campaign,
and saves the result to /output/report.xlsx.
</Task>

<ExecutorTools>
read_file, write_file, run_python (pandas and openpyxl are installed).
There is no "xlsx" tool: xlsx is a file format, you open it via run_python.
</ExecutorTools>

<OriginalSkill>
[paste the text of the original SKILL.md]
</OriginalSkill>

<RewriteRules>
1. TOOLS: clearly separate callable tools from documents and formats.
   Add an environment check at the start and what to do on typical errors.
2. CONTEXT: open the skill with the task, the boundaries of allowed edits, and the delivery path.
   Separate the current task from examples and reference material.
   If the task needs reference material, paste it right into the skill.
3. REQUIREMENTS: phrase each requirement as action + object + done condition.
4. VERIFICATION: end the skill with an independent check — reread the result,
   recompute it another way, compare against an explicit threshold,
   repeat until the check passes.
</RewriteRules>

Don't put a ready-made answer into the skill. If there's nothing to fix, return the original skill unchanged.
Return only the text of the new skill.

Result: The model will return a rewritten SKILL.md. It'll open with the task and the /output/report.xlsx path. Excel will be described as a file you open via run_python, not as a tool. Each requirement will be phrased like “calculate X in column Y; done when…”. At the end there'll be a step: reread the final file, recompute ROI a second way, and check the discrepancy against a threshold. Then you run the cheap model on the new skill. If it still slips up, move on to Mode B.

The weakness. A weak model takes in a skill as one long text and executes it partially. It picks up some of the requirements, gets lost between the working task and the reference material, and doesn't check the result. A skill written “for a smart reader” doesn't help these models: everything they need is in there, but in a form they don't act on.

The strength. A model is good at rephrasing text against a clear checklist. It doesn't have to guess where the weak model will trip: the four failure types are already named, and each one is turned into a concrete editing rule. That's why the meta-skill clearly beats a generic “rewrite it so it works for everyone.”

How the method gets around the weakness. It removes everything the executor would otherwise have to infer: the delivery path, whether something is a tool or a document, what “done” means, how to verify. When it's all explicit, with nothing left “between the lines,” it's easier to execute.

Control levers: - The executor's tool list → the more precise it is, the better rule 1 works. Without it, the rewriter won't see what exactly trips up the weak model. - Logs and verifier verdict → Mode B. With them, even a weak model improves its own skill. Without them, self-rewriting makes results worse. - The threshold in the check → replace it with your own criterion (“discrepancy no more than 1%”, “all 12 columns filled”). - Number of rounds → 5 in the study. The curves aren't monotonic: measure the gain on a held-out check, not by the last round. - “Earliest failure first” → don't let the rewriter fix everything at once. An early failure often breaks everything after it.

The authors put the full text of the meta-skill in Appendices B and C. It isn't in the provided excerpt. Below is a template assembled from the description of the rules in section 3.2. It's a reconstruction, not the verbatim original.

Mode A — editing without logs:

You are rewriting an agent's skill so that a weaker model can carry it out.

<Task>
{task}
</Task>

<ExecutorTools>
{executor_tool_list}
</ExecutorTools>

<OriginalSkill>
{original_skill_text}
</OriginalSkill>

<RewriteRules>
1. TOOLS: separate callable tools from documents and file formats.
   Add an environment check and actions for likely errors.
2. CONTEXT: open the skill with the user's task, the boundaries of allowed edits, and the delivery path.
   Clearly separate the current task from examples and reference material.
   Paste the material the task needs right into the skill.
3. REQUIREMENTS: every important requirement = action + object + done condition.
4. VERIFICATION: end the skill with an independent check:
   reread the result, recompute it another way,
   compare against an explicit threshold {threshold}, repeat until the check passes.
</RewriteRules>

Don't put a ready-made answer to the task into the skill.
If there's nothing to fix, return the original skill unchanged.
Return only the text of the new skill.

Mode B — a self-improvement round (add logs):

<Task>{task}</Task>
<ExecutorTools>{tool_list}</ExecutorTools>
<CurrentSkill>{previous_round_skill}</CurrentSkill>
<Trajectory>{agent_action_log_from_last_run}</Trajectory>
<VerifierOutput>{verifier_result_or_your_note_on_what_went_wrong}</VerifierOutput>

Find the FIRST failure in the log and fix it in the skill first.
Then apply the rewrite rules:
{same_4_rules_as_above}
Return only the text of the new skill.

What to fill in: - {task} — one specific task with input and output. - {executor_tool_list} — the real names that the weak model actually sees. - {threshold} — a measurable “done” condition. - {agent_action_log_from_last_run} — an export of the agent's actions. Most agent environments provide one.

🚀 Quick start — paste into the chat:

Here's a template for rewriting a skill for a weaker model (Skill Adaptation). Adapt it to my task: {describe what routine the agent does and on which model}.
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask about the task, the delivery path, the executor's tools, and the “done” criterion. Without them, rules 1, 2, and 4 won't work: you need to know what the weak model can actually call, where to deliver, and how to verify. It'll take the pattern from the template and assemble a ready-to-use prompt.

⚠️ A skill doesn't replace model capability: after the edit, the executor's own failures remain. The model fixes a script but doesn't rerun it. It repeats a failed call. It stops before writing the file. Out of several constraints, it follows whichever one the skill emphasizes and loses the rest.

⚠️ A weak model shouldn't rewrite its skill “blind”: in single edits without logs, weak models that edited their own skills made results worse on average compared with the original. Self-improvement only works when there's evidence of failure (a log plus a verifier verdict).

⚠️ The effect is modest and uneven: in the self-improvement loop the gain is small (a few points), and the curves move in waves. The weakest model stays below baseline in some rounds. The authors themselves don't lean on the exact figures, only on the fact that the sign of the effect matched for all executors.

⚠️ Strong models probably don't need this: the method was tested on weak and mid-tier executors. If you only run top models, the main value is the four rules as a checklist when writing skills.

⚠️ The tests are agent tasks with verifiable outcomes: documents, spreadsheets, STEM problems. The method wasn't tested on subjective tasks (writing, creative work).

The researchers took three independent benchmarks of agent tasks with human-written skills, for a total of 607 tasks. Seven models were split into three tiers based on their results without a skill: weak, mid-tier, and top. Across all tasks, the skill gave a small gain with no clear pattern. But on 103 selected “task — skill” pairs where it genuinely helped top models, the picture changed: strong models gained ~27 points, weak ones stayed flat, and the weakest one even dropped. So the authors read the weak models' failure logs and grouped them into four failure types. They found that in 86% of failures the requirements were already in the skill but weren't followed. From these four types they built the meta-skill, and strong models (Kimi-K3, GLM-5.3, and others) used it to rewrite skills. To separate the protocol's contribution from that of a strong rewriter, they compared it with a one-line “rewrite it so it works for everyone” request: the protocol added 5.1–6.0 points. The surprise: in the self-loop without logs, weak models edited their skills into something worse than the original, but with logs and a verifier verdict they got better. Hence the practical takeaway: rewrite based on evidence of failure, not at random.

🔧 Technique: audit your own CLAUDE.md / AGENTS.md → find the items a weak model will drop

This is an extrapolation: the authors tested the method on skills, not on project instruction files. But the same four failures work as a checklist. Give the model your instructions file and ask:

Copy

Check my instructions file against four questions.
1) Does it contain “tools” that are actually formats or documents?
2) Does it open with the task and the delivery path, or with generic statements and examples?
3) Does every requirement have an action, an object, and a done condition?
4) Is there an independent check with a threshold at the end?
For each item, show quotes where it's violated and suggest an edit.

🔧 Technique: move examples to the end and label them → protection against context failure

If your skill has examples, label them: “EXAMPLE. This is not the current task.” In the study, weak models mistook reference examples for their own work.

• Paper title: Evolving to Match Capabilities: Improving Harness Self-Evolution via Skill Adaptation.
• Benchmarks used in the study: SkillsBench (Li et al., 2026), DocOps (Jiang et al., 2026a), Tessl (Shaposhnikov et al., 2026).
• Related approaches mentioned in the paper: Meta-Harness (Lee et al., 2026a), Self-Harness (Zhang et al., 2026a).
• The full meta-skill and rewriting protocol are in Appendices B and C of the paper (not included in the provided excerpt).
• The authors' names and affiliations aren't given in the provided excerpt.