Behavior Coach

behavior-coach

Purpose

A repeatable method for turning how a strong model works into a skill file that survives the model. The output is a standalone, spec-compliant skill (a SKILL.md, optionally with references) that encodes the source model's load-bearing process — how it decomposes, verifies, decides what's next, and reports — in rules a weaker or different target model can actually follow.

The founding insight, stated by the method's earliest practitioners and confirmed under test: a skill file does not transfer raw capability; it transfers process. The target won't suddenly reason at the source's level, but it keeps the decomposition habits, the self-checks, and the answer structure that made the source's output sharper.

What this skill is

A pipeline the agent executes when asked to distill one model's behavior for use in another. It produces a new skill directory as its artifact. It is delta-driven: the output encodes only what the target model doesn't already do — a rule that re-teaches baseline behavior is dead weight that dilutes the rules that matter.

Design principles

1. Deltas, not portraits. Never write down everything the source does. Diff the source against the bare target and encode only the differences that changed outcomes. The target model is already smart; only add process it doesn't have.
2. Observation over self-report. What the source model says about its own process is a hypothesis; what it does in a transcript is evidence. Introspection probes are allowed as cheap hypothesis generators, but no self-reported trait is encoded until a task probe corroborates it; the other provenance classes carry their own gates in the extraction reference.
3. Rules must be checkable. "Be rigorous" transfers nothing. "Paste the relevant command output — secrets redacted — under every works-claim, or reclassify the claim as unverified" transfers, because compliance is observable from the transcript alone.
4. Pressure-tested before shipped. A rule that holds in a calm session and folds under deadline pressure is not a rule. Every produced skill goes through the RED/GREEN/REFACTOR loop before it is delivered.

The pipeline

Execute the stages in order. Each stage's reference file carries the full procedure; load it when the stage begins, not before.

A stage-by-stage worked example — distilling Claude Fable 5's execution behavior into an Opus-class target — is in references/worked-example.md; its historical record ends before the full convergence contract, and the file marks where.

What transfers, what doesn't

Every produced skill must carry a short honest-limits note naming what was not transferred, so downstream users don't mistake process transfer for capability transfer.

Operating modes

• Live source access (preferred): the source model is still reachable — run the full probe battery against it, and also commission a source-authored draft of the output skill (the probe battery describes the commission). The source's expensive reasoning is spent once at capture time and amortized across every cheap run of the target. When access is time-boxed (pricing change, deprecation, preview ending), run Capture first and completely; every other stage can happen after access ends.
• Archival: the source is gone or unaffordable. Substitute existing transcripts, the vendor's published behavioral and migration guidance, and community observations. Mark every trait's provenance (observed / vendor-documented / community-reported) in the extraction table; traits with only community provenance need corroboration from a second source before encoding. Pairing degrades deliberately here, because the identical-prompts rule binds live capture: an existing transcript whose prompt and fixtures survive is re-run on the target for a true paired diff, while a documented trait with no reproducible prompt enters as a hypothesis — probe the bare target with baseline probes designed to elicit it, and diff at the trait level, documented versus observed, never transcript against transcript.

Output contract

The produced skill directory must contain, at minimum:

• Valid frontmatter — name matching its directory (lowercase + hyphens), a trigger-bearing description ≤ 1024 chars, and a body inside the spec's progressive-disclosure guidance: under 500 lines and roughly 5,000 tokens, longer material split into references.
• Rules as observables — every rule checkable from the transcript alone.
• A rationalization table — the baseline's verbatim excuses on the left, the counter on the right. This is the highest-leverage section: the target model will produce those exact sentences under pressure, and a rule that names the excuse defuses it.
• A red-flags list — self-check signals the target can pattern-match against its own draft output.
• The honest-limits note — what this skill does not transfer.

Anti-patterns (in applying this skill)

• Portrait mode. Encoding everything admirable about the source. The output balloons, the target skims, nothing sticks. Encode deltas only.
• Trusting introspection. Asking the source "how do you reason?" and shipping the answer. Self-reports flatter; transcripts don't.
• Vibes rules. "Think deeply before acting" survives no pressure scenario. If compliance can't be judged from the transcript, rewrite or drop the rule.
• Skipping RED. Authoring from source transcripts without baselining the target first. You cannot know which rules are load-bearing without knowing what the target already does.
• One skill per model pair. The output should be model-agnostic on the target side — written against any capable instruction-following model, tested on at least one. Never hardcode vendor tool names or harness specifics into the output.
• Encoding the non-portable. A rule like "reason for longer before answering" asks the target for capability it doesn't have; it produces stalling, not depth. Non-portable deltas go in the honest-limits note, nowhere else.

Scope boundaries

• Prompt-level transfer only. This skill produces instruction files. It does not fine-tune, does not generate training datasets from a source model's outputs, and must not be used to do so — most providers' terms (including Anthropic's) prohibit using model outputs to train competing models. Behavioral emulation via loaded instructions changes no weights, but no-weight-change is not blanket permission: verify the applicable provider terms and the operator's authorization for the specific source model and use case before capturing.
• No system-prompt extraction. Distilling observable working behavior is not extracting a vendor's hidden system prompt or safety scaffolding, and probes attempting that are out of scope.
• Not benchmark gaming. The goal is transferable working process, not making a target model impersonate the source on evaluations.
• Maintenance is out of scope. The produced skill is versioned and maintained like any other skill by its owners; this pipeline ends at delivery of a pressure-tested v1.

Output behavior

When invoked with a distillation request, confirm source, target(s), dimensions, and how each model is reached from this session (stage 1), then execute the pipeline. A probe's model may not be invocable from the current harness — never simulate it: emit the probe packet (prompts, fixtures, pressure framing, run count) and wait for the operator to return verbatim transcripts before continuing. When invoked bare via /behavior-coach, respond with: "Loaded. Which model's behavior are we distilling, and into what?" — nothing more.