TL;DR
D-Skill is a way to turn the difference in behavior between two models into a text instruction. A strong model and a weak model are run on the same tasks, and their action logs are saved. Then a third model, the analyst, compares pairs of logs using a fixed scheme and writes out rules: "the weak one did this, the strong one did that, do it like the strong one." The rules are merged into a single SKILL.md file that goes into the cheap model's context. The weights are untouched; the teacher is a "black box."
The key finding: advice "from the outside" works noticeably worse than comparing pairs. If the analyst looks only at the weak model's logs, it sees the failures but doesn't know what the right move is. If it looks only at the strong model's logs, it gets generic good habits but doesn't know where exactly the weak model breaks. In the spreadsheet test, the first option closed 38–45% of the gap between the models, the second 55–71%. Comparing pairs closed 85–89%.
The method has three steps: run both models on the same tasks, collect lessons from pairs of logs (up to three per pair, of two types — "divergence" and "agreement"), merge the lessons into one skill file. The result: the cheap model with the file closes 75–95% of the gap with the expensive one and costs 5–8 times less per task.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1: Run the strong and the weak model on the same tasks (~50–100)
→ logs of actions and environment responses (no reasoning and no teacher instructions)
STEP 2: The analyst (a strong model) reads a PAIR of logs using the dimension scheme
→ up to 3 lessons per pair: divergence / agreement
→ each lesson: evidence from the logs + a general rule
STEP 3: Consolidator: shuffle the lessons → split into batches → for each batch:
map (lesson → patch) → reduce (merge, remove duplicates, generalize) → apply (to SKILL.md)
→ final SKILL.md
STEP 4: SKILL.md goes into the weak model's context
Steps 2 and 3 are separate model requests. Step 2 is repeated for each pair of logs.
Example in Action
Task: The owner of an Amazon store has an agent building summary spreadsheets from sales, inventory and returns exports. The strong model handles it, but it's expensive: thousands of runs pile up every month. The cheap one mixes up columns, doesn't check totals and, after a formula error, carries on as if nothing happened. The goal is to transfer the strong model's habits to the cheap one.
What we do: take 50 real requests ("build a returns report for October," "consolidate inventory across the Dallas and Atlanta warehouses"). Run both models. Save the logs: which files they opened, which commands they ran, what the environment returned. Don't put the teacher's reasoning or its system prompt in the logs. Then give the analyst each pair of logs with this prompt:
Prompt (analyst, per pair):
<Role>
You are a difference analyst. You compare two runs of the same spreadsheet agent
on the same task: a strong one (TEACHER) and a weak one (STUDENT).
You have no reference answers. Only the logs of actions and environment responses.
</Role>
<Task>
The user's task: "Build a summary table of Amazon returns for October
by category and calculate the return rate as a share of sales."
</Task>
<Dimensions>
Compare the runs on each dimension:
1. What the agent learned about the files before starting work (sheets, columns, date formats)
2. How it chose and executed actions (formulas, order of operations)
3. How it reacted to errors and odd intermediate results
4. How it checked the final result before answering
</Dimensions>
<Rules>
- Don't nitpick names, wording or reasoning style.
- Every lesson must point to a specific place in the logs.
- Phrase each lesson as a general rule for all future spreadsheets, not as a fix for this task.
- At most 3 lessons. Rank them by expected usefulness for new tasks.
</Rules>
<Output>
For each lesson:
type: divergence | agreement
evidence: a quote or a reference to a step in the logs
student: what the weak one did (divergence only)
teacher: what the strong one did (divergence only)
rule: a general rule that can be written into the skill
</Output>
<TEACHER_LOG>{strong_model_log}</TEACHER_LOG>
<STUDENT_LOG>{weak_model_log}</STUDENT_LOG>
Result: for each pair the analyst returns up to three structured lessons. For example: a rule about checking headers and date formats before writing formulas, or about reconciling totals with the source. Then the consolidator assembles ~100–150 lessons into a single SKILL.md with no duplicates or contradictions. You plug that file into the cheap model. Expect it to behave noticeably closer to the expensive one, but not to match it fully.
Why It Works
The weakness. The cheap model doesn't know where exactly it goes wrong. Generic advice like "be more careful, check your result" gives it almost nothing. A human has just as hard a time writing a skill "blind": they can't see how the strong model differs from the weak one on specific tasks.
The strength. LLMs are good at comparing two long texts and turning the differences into a rule. An instructions file is something the weak model reads and follows without fine-tuning.
How the method exploits this. It boils the comparison down to one point: "in this situation you did X, the strong model did Y." The dimension scheme forces a look at the process (what it learned, how it acted, how it reacted to errors, how it checked), not at trivia like style. The "general rule, not a task-specific fix" requirement keeps the file from turning into a pile of special cases. Agreement lessons preserve what the weak model already does right.
Control knobs: - Analyst strength — the most sensitive knob. With Qwen as the analyst (the same weak model), only 39–48% of the gap closed. Don't skimp on the analyst. - Consolidator — you can go cheaper. You lose about 5 points, but the method holds up. A weak consolidator model makes the document longer and compresses lessons worse. - Lessons per pair (at most 3 in the paper) — fewer for simple tasks, more for varied ones. - Dimension scheme — replace the four items with what matters in your domain: for example, "how it asked clarifying questions" for support. - Number of tasks — 57–100 in the paper. For narrow routine work fewer will probably do, but that's for you to verify. - Log source — you can use old saved runs; re-running the models isn't required.
Prompt Template
The method consists of two prompts. The first runs on each pair of logs, the second on each batch of lessons.
The authors' verbatim prompts are in the appendices (the analyst is in Appendix B); they're not in the text provided. The templates below are built from the method description in sections 3.3 and 3.4.
Prompt 1. Difference analyst (per pair of logs):
<Role>
You are a difference analyst. You compare two runs of the same agent on the same task:
a strong one (TEACHER) and a weak one (STUDENT). There are no reference answers.
You only have the logs of actions and environment responses.
</Role>
<Task>{task_description}</Task>
<Dimensions>
Compare the runs on each dimension:
1. What information the agent gathered before acting
2. How it chose and executed actions
3. How it reacted to errors and useless intermediate results
4. How it checked the final result
{your_dimensions}
</Dimensions>
<Rules>
- Don't nitpick names, wording or reasoning style.
- Every lesson must quote a specific place in the logs.
- The rule is general for future tasks of this type, not a fix for the current one.
- At most 3 lessons, in descending order of expected usefulness.
</Rules>
<Lesson_Types>
divergence — the weak one behaves differently from the strong one:
student: what the weak one did
teacher: what the strong one did
rule: an instruction that closes the gap
agreement — both do the same thing, and it's worth keeping:
behavior: what exactly
rule: what to write into the skill
</Lesson_Types>
<TEACHER_LOG>{strong_model_log}</TEACHER_LOG>
<STUDENT_LOG>{weak_model_log}</STUDENT_LOG>
Prompt 2. Consolidator (per batch of lessons, updates the skill):
<Role>
You maintain the SKILL.md skill file for a weak model.
You are given a batch of lessons from the analysis of log pairs.
</Role>
<Current_Skill>{current_SKILL.md}</Current_Skill>
<Lessons>{lesson_batch}</Lessons>
<Procedure>
MAP: turn each lesson into a candidate patch to the skill:
append to an existing section | replace text | create a new section.
REDUCE: merge the patches — remove duplicates, resolve contradictions,
generalize similar rules into one.
APPLY: output the full updated SKILL.md.
</Procedure>
<Rules>
- Keep rules short and actionable.
- Don't bloat the document: merge rules, don't stack them.
- Don't delete rules confirmed by agreement lessons.
</Rules>
What to fill in:
- {task_description} — the wording of the user's task.
- {strong_model_log}, {weak_model_log} — logs of actions and environment responses. Cut out the model's reasoning and the teacher's system instructions, as in the paper.
- {your_dimensions} — extra scheme items for your domain.
- {lesson_batch} — a slice of the overall lesson pool. In the paper the pool is shuffled and cut into k batches that are processed in sequence.
🚀 Quick start — paste into a chat:
Here is the D-Skill template. Adapt it to my task: {what my agent does and which model is the expensive one, which is the cheap one}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what tasks the agent performs, what its logs consist of and what counts as good work for you. It needs this to pick comparison dimensions for your domain. It will take the pattern from the template and assemble prompts for your data.
Limitations
⚠️ You need a strong analyst: if a weak model does the analysis, the gain drops almost by half. It finds fewer confirmed lessons and explains the cause of the gap worse. You can save on merging, but not on analysis.
⚠️ You need paired logs on the same tasks: both models must go through the same tasks with the same set of actions. Without pre-collected logs you'll have to run the expensive model too, and that costs money. The method pays off when there are many tasks and they repeat often.
⚠️ It's a pipeline, not a single request: in practice you need automation — runs on dozens of tasks, a loop over pairs, merging in batches. Doing it by hand in a chat gets you only a toy version. The authors' code is open, but you'll have to run it yourself.
⚠️ The gap doesn't close completely: the student is still a student. Results also vary between independent attempts: the resulting skill files differ, and the spread is noticeable for some model pairs.
⚠️ Tested on benchmarks: spreadsheets, a text-based household game and chess puzzles. The paper didn't test live product scenarios with complex business logic. A successful skill needs a separate run on your own tasks.
⚠️ The teacher was boosted with an existing skill: to create a gap between models, the teachers were equipped with existing skills. For the method that's equivalent to "a stronger teacher," but a real model pair needs to be tested separately.
⚠️ Some details are missing from the text: the version of the paper provided doesn't show the final prompts or examples of the resulting skills (appendices B and D). A comparison with fine-tuning and a variant with a different skill-update backend are mentioned, but the details are cut off.
How They Tested It
Researchers from Berkeley took three different environments: spreadsheet editing (SpreadsheetBench-Verified, 400 tasks), a text game about cleaning a house (ALFWorld) and chess puzzles from Lichess. In each they set up a "strong model — weak model" pair with a real gap. For spreadsheets and ALFWorld the strong teachers were boosted with an existing skill so the gap would be noticeable. The analyst never saw those skills: the teacher's logs were stripped of reasoning and all instructions.
Building a skill took just 57–100 unlabeled tasks and one run of each model. The analyst and consolidator were DeepSeek-V4-Pro (Sonnet 5 for chess). Each experiment was repeated with three independently built skills, and each skill was evaluated twice. So the numbers don't rest on one lucky attempt.
The headline: the weak model with the skill closes 83–95% of the gap on spreadsheets and ALFWorld and 75–88% on chess. On spreadsheets it looks like this: the Qwen student rose from 28 to ~72, Luna from 25 to ~73, with the teacher at ~79. The cost per task fell 8.3 times on spreadsheets and 5.7 times on ALFWorld.
Ablations showed that what matters is specifically comparing pairs. Student logs alone closed 38–45% of the gap, teacher logs alone 55–71%, both together 85–89%. This isn't obvious: you might think the strong model's logs would be enough, but they only yield generic habits that aren't tied to the student's weak spots. Another surprise: swapping in a weak model as the analyst cost many times more than swapping the consolidator. Practical takeaway: use the strong model where you need to understand the cause of the differences, and hand the merging to a cheap one.
Adaptations and Extrapolations
These are my variations. The authors' method is described above.
💡 Adaptation for an agent instructions file (CLAUDE.md / AGENTS.md): the final document doesn't have to be called SKILL.md. If you work in Cursor or Claude Code, put the lessons into the project rules file. Then the cheap model you run routine work on gets the expensive model's learned habits. To do this, change the role in the consolidator prompt:
You maintain the project rules file AGENTS.md for an agent in Cursor.
Phrase the rules as short imperatives. Group them into sections:
"Before starting," "If there's an error," "Before answering."
🔧 Technique: your own dimensions → lessons tailored to your domain. The paper's four dimensions are geared toward spreadsheets and action-based environments. For a support agent, replace them with, for example: "how it clarified the details with the customer," "how it responded to frustration," "when it escalated," "how it confirmed the issue was resolved." The lessons will get more specific to your task.
Resources
- Paper: D-Skill: Distilling Teacher Knowledge through Agent Skills. Shuo Yuan, Dacheng Li, Joseph E. Gonzalez, University of California, Berkeley.
- Code: https://github.com/shuo-yuan/D-Skill
- Related work the method builds on: Trace2Skill (Ni et al., 2026) — the base mechanism for merging lessons; SkillOpt (Yang et al., 2026) — another way to update a skill, compatible with D-Skill; SkillGen (Ma et al., 2026); Reflexion (Shinn et al., 2023).