A developer's guide to coding agentsInternal talk · July 2026

Agentic
Engineering.

From token prediction to self-verifying loops

context effort verify
2
The hook

Same model. Two prompts.

you › "fix the bug" agent flails — edits three files, tweaks the test until it passes, declares victory. The bug is still there. you › /goal make test_invoice pass — `pytest -q` must exit 0. Do NOT edit or skip the test. Paste the final output. agent nails it — real fix, real green, evidence attached.

The engineering around the model made the difference. That's this whole talk.

3
Agenda

One idea, seven upgrades

The machine grows up
01talks → 02thinks → 03acts → 04loops
Then you take over
05count the cost → 06split the work → 07make it stick

Each upgrade fixes the last one's limit. One thread runs through all seven — the context window — and ● CONTEXT flags it. New to all this? Start with the beginner deck.

01

A machine that talks

Where it started: a text box and a next-token predictor. Astonishing — and all it can do is guess.

4
The predictor · what an LLM does

It predicts the next token. That's it.

  • One job, forever: given the text so far, guess the next chunk. Then loop.
  • It's your phone keyboard's middle suggestion — at a trillion-parameter scale.
  • Everything else — chat, tools, agents — is scaffolding we build around that one trick.

A model is a probability distribution over the next token, sampled one token at a time.

5
The predictor · the middle button

Prediction 1.0: one word of memory

EXAMPLE — typing with only the middle suggestion
# tap the centre autocomplete key, over and over: "I am going to be a little more than the first time I have to get the car and the kids are not going to be a good idea to have a great day…"
  • Every word is a fine guess given the word before it — and the sentence goes nowhere.
  • That's next-token prediction, original flavour: a lookback of one.
the kids are not ___ ? one step back — that's all ✕ can't see this far back

Your keyboard sees ~one word; the old n-gram models saw two or three. An LLM with no useful context drifts exactly like this — the upgrade that sees everything is next.

6
The predictor · attention

Attention: it weighs every token

The invoice test expects VAT so ___ ? the newest token looks back at all of them — with different strengths
  • The keyboard sees the last ~2 words. The model weighs the entire context for every token — that's why it's not gibberish.
  • The context IS the program. Curating it is the job.

● CONTEXT This is the thread: attention runs over the context window, so what you load into it is the program.

02

Teach it to think

Problem: hard answers don’t fit in one forward pass. Fix: let the model write itself a scratchpad — and dial how much.

8
Thinking · reasoning

Reasoning: the model writes its own context

EXAMPLE — the invoice test: total 100, but the test expects 121
# without reasoning — one hard prediction, pattern-matched you › why does the test expect 121, not 100? model › Probably a rounding bug. ✕ wrong # with reasoning — the model writes a scratchpad first thinking › test asserts 121 · input total is 100 121 / 100 = 1.21 → 21% — the VAT rate so the test expects VAT applied model › The test expects 21% VAT to be applied.

Same model, same question. The only difference: it thought on paper before it answered.

9
Thinking · why it works

Why thinking works

  • One forward pass per token. Force the answer into the next token and it gets exactly one pass of compute — hard problems don't fit.
  • Reasoning = the model writing intermediate steps into its own context, then attending to them. The scratchpad becomes part of the program.
  • Each step is an easy next-token guess; a chain of easy predictions replaces one impossible one. More tokens spent = more compute on the answer ("test-time compute").
  • Thinking tokens are billed as output — the priciest tokens you buy. They stay in context for the rest of that turn, then the API strips them: gone next turn, never re-billed as input. Billed once. The effort dial (next slide) sets how many.
this turn → prompt thinking tokenswritten by the model answer the answer attends to the model's own scratchpad next turn → prompt thinking tokens stripped by the API answer never re-sent — so never re-billed as input

● CONTEXT Reasoning is the model extending its own context — the scratchpad is program it writes for itself.

10
Thinking · the effort dial

The other dial: effort

EffortReach for it when…
lowcheapest & fastest — bulk, delegated grunt work.
mediumthe cost-saving step-down for routine agentic work.
highthe API default — start here for everything that isn't code.
xhighstart here for coding & agentic runs — Anthropic's recommended default for both, and Claude Code's.
maxfrontier problems only — past xhigh it mostly adds cost.

Claude Code's "ultracode" = xhigh + standing permission to run multi-agent workflows (chapter 06) — a harness mode, not an API level.

agentic eval score → output tokens per task → ↙ lower effort clears the old model's ceiling +25% tokens, ~no gain Opus 4.8 · max its best — still below Opus 5 · xhigh Opus 5 · max shape: Anthropic — Claude Opus 5 launch (Jul 2026); scores from published trackers

Effort moves you along one model's curve; the model picks which curve — and a newer curve sits above and to the left. On Frontier‑Bench, Anthropic reports Opus 5 more than doubling Opus 4.8 at a lower cost per task; past xhigh, max buys ~nothing for roughly 25% more tokens. Its low/medium are unusually strong — re-sweep, don't inherit.

03

Give it hands

Problem: it can only talk — it can’t read your repo or run a test. Fix: tool calls, and a harness to execute them.

11
Hands · the three parts

Model · harness · client

  • Model — the brain, an API you rent: Fable · Opus · Sonnet (Anthropic) · GPT‑5.6 Sol (OpenAI) · Gemini 3.1 Pro (Google).
  • Harness — the loop around the model: assembles context, runs tools, manages permissions. Claude Code · Codex CLI · Gemini CLI · Jules (async).
  • Client — where you meet the harness: terminal · IDE extension (VS Code, JetBrains, Antigravity) · desktop · web · CI.
you CLIENT terminal · IDE · desktop · web · CI HARNESS — the loop assemble context run tools · your permissions runs on your machine MODEL rented API — emits tokens only POST context tokens back

The model only emits tokens — the harness is the program that gives them hands. Rent the model, run the harness, pick the client; most models work in most harnesses.

12
Hands · anatomy of a tool call

A tool call is just tokens

# the model can't run anything — it can only emit this: model › {"tool": "bash", "input": {"cmd": "pytest -q"}} harness › runs it locally · exit 1 · 3 lines of output harness › appends the result to the context, POSTs it all back model › "test_invoice expects VAT — patching calc.py…"
  • The "call" is ordinary next-token output in a structured shape — still just prediction.
  • The harness parses it, runs it locally under your permissions, and appends the result to the context.
  • The model never touches disk or network — it sees your repo only as tokens in the next request.

● CONTEXT A tool result is just more context. "Reading a file" = loading its tokens into the window.

13
Hands · client & server

The harness is a client. The model is a server.

YOU HARNESSclient MODEL APIstateless server type: "fix the bug" context ~5k POST full context tokens + tool call run tool locally context ~9k POST full context — bigger tokens + tool call run tool locally context ~14k POST full context — bigger still final answer

Every arrow to the server carries the whole conversation again — the API keeps nothing between calls. Remember the growing bars; the why is next, the price is chapter 05.

14
Hands · statelessness · the why

Why re-send everything?

  • The API is a pure function: tokens in → tokens out. No session, no memory — like the guy in Memento.
  • The sequence diagram's re-sends weren't waste — they're the only way the model sees turn 1 again.
  • So memory = whatever is in context, rebuilt by the harness every turn.
15
Hands · one turn’s payload

One line typed, ~20,000 tokens sent

EXAMPLE — what one Claude Code turn actually assembles
# you type one line — the harness builds all of this: system prompt ~2,600 who it is, the rules tool definitions ~4,100 every tool's schema CLAUDE.md + skills ~1,800 your conventions conversation so far ~9,200 every earlier turn tool results ~2,300 files read, cmd output your message 11 "wire up the CSV export"

Which tokens fill that context window is what you're really controlling.

04

Close the loop

Problem: one step per turn — you are the relay. Fix: the harness re-runs until a verifier says done.

16
The loop · four levels

Four levels, each contains the last

① In-model what it just knows ② Reasoning think before answering ③ Tools read, run, call — act ④ Loops act → check → repeat engineering starts here

Levels 1–3 are the deck so far: knowledge (ch 01), thinking (ch 02), tools (ch 03) — you mostly get them for free. Level 4 — closing the loop against a goal — is this chapter, and where the failure modes live.

17
The loop · the inner loop

The harness keeps going

  • Last chapter you pressed send after every tool result — the model was a single-step oracle.
  • An agent is the harness feeding results straight back and re-POSTing, until the goal is met — no human relay.
  • Nothing changed inside the model. The loop is pure harness engineering around a stateless predictor.

That's the entire trick: a while-loop around a token predictor. Which raises the question the next slide answers — who decides when it's done?

18
The loop · the loop primitive

From ralph to /goal

# the original "ralph" loop — dumb on purpose while :; do claude -p "$(cat PROMPT.md)" done # 2026: same idea, with a finish line /goal ship the CSV export — `npm test` must exit 0
  • A loop just re-runs the agent until a condition is met. The primitive is trivial — a shell while.
  • All the intelligence lives in the goal and the stopping condition you hand it.
19
The loop · verifiers

Never loop without a verifier

"Looks done" is not a verifier.

"exit code 0" is. A verifier is an objective check the model can't argue with.

  • A loop is a repeated cycle toward a verifiable goal. No verifier → no goal → nothing to stop for.
  • Good verifiers: a test suite, the compiler / type-checker, a build, a screenshot diff.
  • The verifier is the loop's ground truth. Everything else is the model's opinion.
20
The loop · failure modes

Two ways loops go wrong

Spiralling

Never recognises completion — each lap piles new code on broken code. Burns tokens, gets worse.

Cheating

Reward hacking: test.skip, hardcoded expected values, deleting tests, appending || true. The verifier goes green; the work is fake.

SPIRALLING CHEATING no verifier → no "done" each lap piles on — context grows, the work gets worse agent instead of fixing — test.skip · || true verifier goes green ✓ loop exits happily the work — fake ✗

Both are spec bugs, not model bugs. The loop optimises exactly what you wrote down; if "pass" is gameable, it gets gamed.

21
The loop · a loop that works

Be annoyingly specific

PATTERN — a goal prompt that can't be gamed
/goal GOAL: export invoices to CSV VERIFY: `pytest tests/test_export.py -q` exits 0 FORBIDDEN: do NOT skip, delete or weaken any test; no `|| true`, no hardcoded expected values EVIDENCE: paste the final test output here

Name the verifier command, forbid the shortcuts by name, and demand real evidence — test output, an exit code, a screenshot diff.

05

The bill comes due

Problem: every lap re-sends the whole history — cost grows quadratically and quality rots. First, the diagnosis.

22
The bill · context growth

One session, blow by blow

EXAMPLE — three turns, payload by payload
turn 1 "why does auth fail?" ~8,500 in system · tools · CLAUDE.md turn 2 "fix it" (3 tokens) ~13,000 in turn 1's exchange turn 3 "run the tests" ~15,500 in turn 2 system + tools + CLAUDE.md (every turn) turn 1: reply + 2 files read turn 2: the diff you

"fix it" is 3 tokens; the request that carries it is ~13,000. The other 12,997 are the memory — every reply, tool call, and file read gets re-sent, verbatim, forever.

23
The bill · the growing input

Those bars, in numbers

input tokens sent → 5,000 9,000 34,000 ~70,000 150,000 turn 1 turn 2 turn 5 turn 10 turn 20
the growing bars from the client/server slide — now measured; each turn's input grows roughly linearly, so the session total grows quadratically.

Turn 20 drags all 19 previous turns with it — the longer the session, the heavier and slower every turn.

24
The bill · input vs output

Two token bills, very different

Input tokensOutput tokens
Whateverything re-sent — history, files, tool resultsgenerated text, incl. thinking tokens
Volumehuge, grows every turnusually small
Price / tokenbaseline (cheap)~5× input
Cacheable?yes — coming upno
Model · July 2026Input / MTokOutput / MTok
Haiku 4.5$1$5
Sonnet 5$3 · intro $2$15 · intro $10
Opus 5$5$25
Fable 5$10$50

Agentic sessions are input-dominated: the model reads far more than it writes.

Three patterns: the ~5× output premium holds across the lineup; each tier jump roughly doubles both prices; and Opus 5 landed at Opus 4.8's price — a generation of capability for free. That last one is the tell: this is a price per token, not a price per task. Next slide.

25
The bill · price per task

The smarter model is often the cheaper one

MeasuredResult
Opus 4.5 vs Sonnet 4.5
SWE-bench, medium effort
matched Sonnet's best score using 76% fewer output tokens
Opus 5 vs Opus 4.8
internal trading eval
best score on ~1⁄7 the reasoning tokens, under half the latency
Sonnet 5 vs Opus 4.8
BrowseComp
same accuracy at ~⅓ the per-task token cost
Opus 5 xhigh vs max
GDPval-AA v2
higher score on 25% fewer output tokens
Price per token ≠ price per task

A weaker model flails: it re-reads files, makes more tool calls, guesses wrong and retries — and every lap re-sends the whole history. You save 5× per token and spend 3× the tokens.

Why it happens: capability shows up as fewer laps, not just better answers. Fewer laps means less thinking, fewer tool calls, and — because every lap re-sends everything before it, so the session total grows quadratically — a much smaller bill.

The caveat that keeps this honest: it only holds where the task is hard enough for the shortcut to exist. Classification doesn't get cheaper on Opus. The rule stays cheapest model that clears the bar — measured on your work, not assumed.

26
The bill · input vs output · example

Where the money goes: one turn

EXAMPLE — "add a --json flag to the export command"
# INPUT — what the model reads ~22,700 system prompt 2,600 tool definitions 4,100 conversation so far 9,200 export.py + cli.py 6,800 read this turn your message 9 "add a --json flag…"
# OUTPUT — what the model writes ~1,600 thinking ~900 billed as output prose ("I'll add…") ~250 Edit tool call (the diff) ~450

The bill (Opus 5, $5 / $25 per MTok): input would be $0.11, but ~19k of it is cache-read at 0.1× → ~$0.03. Output: 1,600 × $25/M → ~$0.04.

The model reads 14× more than it writes — yet the tiny output side costs more: output is 5× the price and never cached. That's why thinking tokens are the expensive dial — billed once, here, then stripped from context: they never come back on the input side.

27
The bill · KV cache · how

KV caching: don't recompute the prefix

  • The provider caches the computed attention state (the KV pairs) for a prefix it has already seen.
  • Send the same prefix again → cached input is ~10× cheaper and faster. But it must be byte-identical.
  • So harnesses append, never rewrite. Edit the system prompt or reorder history and you bust the cache — full price again.

● CONTEXT Caching = paying less to re-send the same context.

28
The bill · KV cache · lifetime

How long does the cache live?

  • Default TTL is 5 minutes — and every cache hit resets the clock, so an active session stays warm indefinitely.
  • A coffee break longer than the TTL → cache gone; the next turn rewrites it at full price. (A 1-hour TTL is available, for more.)
  • Reads cost ~0.1× input; writes cost a premium — 1.25× (5-min) or (1-hour). Break-even: 2 requests on the 5-min TTL, 3 on the 1-hour.
active session — cache stays warm t1 t2 t3 t4 each hit resets the 5-min TTL > 5 min break TTL expires cache gone — full-price rewrite

● CONTEXT Cache is per-model — switch models mid-session and you pay to rebuild the cached context.

29
The bill · the dumb zone

The dumb zone

  • Recall attention: every new token is a weighted look-back over all earlier tokens — and the weights sum to 1.
  • So context is zero-sum: each irrelevant token you load competes for the same attention budget as the needle — and near-miss distractors pull hardest.
  • That's why "just throw everything in" backfires: more haystack = a thinner slice of attention per needle. Degradation starts well before the window limit.
  • Symptoms: forgets instructions, redoes finished work, ignores a fact that's right there.
  • Hygiene: /clear, /compact, a fresh session per task, and subagents that summarise back.

● CONTEXT Where agents go to get confused is the last stretch of the window — hygiene is just keeping it lean.

06

Split the work

Problem: one window, one brain, carrying everything. Fix: route the cheapest adequate brain; delegate to fresh windows.

30
Split the work · subagents

Subagents: fresh windows, tiny summaries

  • A subagent starts with an empty context window — the messy exploration happens over there. That's the rot fix.
  • Only a short summary comes back; the parent's window stays lean.
  • Each subagent picks its own model and effort — grunt work goes cheap. That's the cost fix. The rest of this chapter: who to route what.

● CONTEXT Delegation is context engineering — spend the main window on decisions, not exhaust.

31
Split the work · the lineups

Same shape everywhere

MakerSmallMediumLargeAbove (frontier)
AnthropicHaikuSonnetOpusFable
OpenAI · GPT‑5.6LunaTerraSol
Google · Gemini 3.5/3.6Flash‑LiteFlashProDeep Think

S / M / L repeats at every lab; Anthropic adds Fable above the large model — priced above Opus (2× per token). Whether it still scores above it is the next slide. Snapshot, July 2026 — this reshuffles constantly.

32
Split the work · the numbers

How much better, actually?

Benchmark · July 2026Sonnet 5Opus 4.8Opus 5Fable 5
SWE-bench Pro · real repo fixes63.269.279.280.0
OSWorld 2.0 · computer use55.770.6
Frontier-Bench v0.1 · hard agentic~18~4333.7
ARC-AGI-3 · novel problems30.2

Two shapes here. On ordinary coding the tiers are 10–15 points apart — real, not dramatic. On benchmarks built from problems the last generation couldn't touch, it's a 2×+ jump (Frontier-Bench) or 3× the whole field (ARC-AGI-3, where the next-best model scores 7.8). SWE-bench Verified is saturating — Opus 5 sits at 96%. Caveat: Anthropic publishes most of these as claims rather than tables — exact figures come from third-party trackers and move a point or two.

Why it matters here: jumps this size make an old routing table wrong, not just suboptimal. Dashes are honest — not every model is run on every benchmark — and none of these is your workload. Re-measure.

33
Split the work · two dials

Capability = model × effort

  • Remember the effort dial from chapter 02 — model size and effort move independently. A small model thinking hard can beat a big one thinking lazily.
  • Effort buys thinking tokens — billed as output (~5×), and they fill your context. Not free.
effort → model size → low xhigh sonnet·high opus·xhigh fable·low

● CONTEXT Thinking tokens are output that lands right back in the context window.

34
Split the work · routing heuristics

Three rules for routing

  • Crank effort first — before you reach for a bigger model, turn the effort up. opus·high is the workhorse; xhigh for long-horizon runs.
  • Cheapest that works — route to the smallest model that clears the bar, measured. Escalate on failure, not vibes.
  • A new tier resets the curvelow effort on a new model often beats xhigh on the old one: a cheaper floor, not just a higher ceiling.
more effort same model bigger model next tier up Opus 5 · max the ceiling first Fable judgement work still fails? still fails? still fails? start: cheapest that clears the bar move up only on real failure — every model hop busts your cache

Fable is for judgement work — two slides on. And re-run the sweep after a model launch: Opus 5's low/medium are strong enough that inherited settings are usually wrong.

35
Split the work · what Fable is

Fable is a price tier, not a strict upgrade

  • 2× Opus 5's price ($10/$50 vs $5/$25) — and since the Opus 5 launch it no longer wins across the board: Opus 5 leads it on Frontier-Bench and OSWorld, at half the cost per token.
  • Where it still earns the premium: judgement — planning, taste, self-correction, spotting the flaw in its own diff, and the longest-horizon runs.
  • Where it's wasteful: grunt work. Mechanical edits, bulk refactors, running tests — a smaller model does those fine, for a fraction of the cost.
Don't make Fable type

You hired a staff engineer. Use it for the hard call and the review — and only once Opus 5 at max effort has actually failed. Then hand the typing to something cheaper.

36
Split the work · Fable · the advisor

Pattern 1 — the advisor

ADVISOR fable · judgement EXECUTOR opus · does the work consult ↑ verdict ↓ work
# harness level — a standing rule in CLAUDE.md: Before committing to a plan or a risky change, spawn a subagent with model: fable to review it, and apply its verdict.

The API also has a built-in advisor tool (beta), consulted mid-generation. One rule: the advisor must be at least as capable as the executor — so sonnet·executor → opus/fable·advisor is fine, opus·executor → sonnet·advisor is a 400. Claude Code has no --advisor flag, so in the harness it's the standing rule above.

37
Split the work · Fable · the orchestrator

Pattern 2 — the orchestrator

RULE — drop this in your CLAUDE.md
# CLAUDE.md For all coding tasks use your judgement to decide an appropriate lower-power model and run that in a subagent.

Fable plans, delegates, and reviews what comes back; haiku / sonnet / opus do the typing.

FABLE plan · delegate · review subagenthaiku subagentsonnet subagentopus delegate ↓ ↑ results
38
Split the work · Fable · cross-vendor

Pattern 2b — delegate across vendors

  • Subagents' model param only takes Claude models — other vendors join via a thin wrapper subagent that shells out to their CLI.
  • Here: Fable hands bulk implementation to GPT-5.6 Sol (OpenAI's flagship, $5 / $30 per MTok) through the Codex CLI.
  • Why: a genuinely independent second perspective — different model family, different blind spots — and someone else's rate limits.
# CLAUDE.md For bulk implementation you may delegate to GPT-5.6 Sol: spawn a wrapper subagent that writes a self- contained prompt and runs `codex exec`. Label it "gpt-5.6:" so the trace shows who did the work.
FABLE plan · delegate · review subagent opus · implements wrapper subagent sonnet · low effort codex exec GPT-5.6 Sol delegate ↓ shells out ↓

The UI reports the wrapper's Claude model — the label is the only cue the real worker was GPT-5.6 Sol. Parallel cross-vendor workers need worktree isolation so edits don't collide.

39
Split the work · where to spend

Where to spend what

Tier · the lineup from beforeSuggested usage
SmallHaiku · Luna · Flash-Liteclassification, log triage, autocomplete, high-volume pipelines — anything you'd regret paying Opus prices for.
MediumSonnet · Terra · Flashthe workhorse: implementation from a clear spec, tests, refactors, bulk subagents, data wrangling.
LargeOpus · Sol · Prothe agentic default: long-horizon coding, debugging, multi-step tool work, user-facing writing & design.
FrontierFable · Deep Thinkplan reviews, the hard architectural call, verify stages, final polish — never bulk implementation, mechanical edits, or first drafts.

Same split every time: the top tier decides and checks; cheaper models produce the volume. Escalate on failure, not vibes — a cheaper model at higher effort often beats a pricier one at low. But price the task, not the token: on genuinely hard work the bigger model gets there in fewer laps, and fewer laps is where the money actually is.

40
Split the work · dynamic workflows

Workflows: everything at once

  • A workflow is a small orchestration the agent writes & runs: agent() (fresh subagent), parallel() (fan out), pipeline() of phases.
  • It combines the whole story: fresh context per stage (chapter 05's rot), per-stage model routing (this chapter), verifiers between phases (chapter 04's loop).
explore · haiku explore · haiku explore · haiku ∥ parallel plan · fable build · opus verify · tests fail → retry pass ✓ done

● CONTEXT Each stage gets a fresh window — one stage's mess never carries into the next.

41
Split the work · workflows in code

What a workflow looks like

SKETCH — the script the model writes
phase('Explore'); parallel( agent('map the data layer', {model:'haiku'}), agent('map the API routes', {model:'haiku'}), ); phase('Plan'); agent('write the plan', {model:'fable'}); phase('Build'); agent('implement it', {model:'opus'}); phase('Verify'); run('pytest -q'); // gate: must pass
REAL — how you ask for it in Claude Code
# plain words opt it in — just say "workflow": > Use a workflow: review this branch. Fan out one reviewer per dimension — logic, security, tests — and verify every finding before reporting. # power-ups ultracode <task> standing opt-in (xhigh + workflows) +500k token budget it paces itself to /workflows watch the phases run live

You never hand-write the script — you state the shape (stages, fan-out, the verify bar) and the model writes & runs the orchestration. Knowing the shape tells you what to ask for.

42
Split the work · which tool when

Which tool, when

AskSingle question, one answer → just talk to it.
AgentMulti-step task in your repo → agent + tools, one session.
/goalRepetitive "keep going until done" → a loop with a real verifier.
WorkflowBig, parallelisable, multi-stage job → orchestrate subagents.

Reach for the simplest rung that does the job. A workflow for a one-line question is as wrong as eyeballing a thousand-file migration by hand.

07

Make it stick

Problem: everything you fixed dies at /clear — every session starts blank. Fix: durable context — CLAUDE.md · skills · plugins.

43
Make it stick · CLAUDE.md

The standing orders: CLAUDE.md

  • A markdown file the harness injects at session start — conventions, commands, boundaries. The model reads it before your first word.
  • Three scopes: repo CLAUDE.md (checked in — the team's), ~/.claude/CLAUDE.md (personal — every project), and per-directory (monorepo sub-projects).
  • AGENTS.md is the cross-vendor twin (Codex, Cursor, Copilot read it natively). Claude Code doesn't — bridge with a one-line @AGENTS.md import, or a symlink.
  • It rides in every turn's context → keep it to short, always-true rules. Recipes belong in skills — next slide says why.
# CLAUDE.md @AGENTS.md ← imports the shared file ## Commands - build: npm run build · test: npm test ## Style - TypeScript strict; no default exports ## Boundaries - never edit migrations/ by hand - ask before adding a dependency

● CONTEXT CLAUDE.md is context you pay for every turn — the whole reason skills exist is to keep it thin.

44
Make it stick · why skills

Why skills? Every session starts blank

  • Groundhog Day: the model knows the world, not your workflow. Release-notes format, review checklist, deploy steps — re-explained every single session.
  • The naive fix bloats: paste it all into CLAUDE.md and it rides in every turn's context — paid every turn, relevant almost never.
  • Skills = lazy-loaded context: a one-line description that's always present; the full recipe loads only when the task matches. The cost of an index entry, the power of a manual.
you › "prep the release notes" matches a description CONTEXT — every turn release-notes · 1 line code-review · 1 line deploy · 1 line the index — always present, tiny release-notes body full recipe — loaded now ON DISK — costs nothing release-notes/SKILL.md code-review/SKILL.md deploy/SKILL.md only the matched body loads

● CONTEXT Skills answer one question: how do I teach the agent my job without paying for the lesson on every turn?

45
Make it stick · skill anatomy

A skill is a folder + SKILL.md

  • The folder name is the skill name. One field does the work: description — the trigger the harness matches on.
  • The body loads only when the skill is used — auto-matched, or invoked directly as /skill-name. Costs almost nothing until you need it.
  • Lives in .claude/skills/ (this project) or ~/.claude/skills/ (everywhere you work).
# .claude/skills/release-notes/SKILL.md --- description: Draft release notes from git history since the last tag. ← the trigger --- # instructions the agent loads on match…

● CONTEXT Skills exist to be lazy-loaded into context only when it makes sense.

46
Make it stick · build a skill

Build one in three steps

WALKTHROUGH — a release-notes skill
1. mkdir -p .claude/skills/release-notes 2. # write SKILL.md — a description, then the recipe: "Read `git log` since the last tag, group commits by type, write RELEASE_NOTES.md." 3. # fresh session — you just type: "prep the release notes" → skill auto-triggers

No registration, no restart — the harness matches your sentence to the description and loads the body. A skill is just context, injected at the right moment.

47
Make it stick · skills at scale

From one skill to a system

Composable sets

Matt Pocock's approach: dozens of tiny skills — conventions, testing style, PR etiquette — each triggering on its own cue.

Compound Engineering

A whole method as a skill system: brainstorm → plan → work → review → compound. Every solved problem becomes a new doc or skill.

brainstorm plan work review compound docs/solutions/ the lesson, written down write the lesson read before the next run starts each loop starts smarter

A skill system is an engineering culture the agent can read — two worked examples on the next slides.

48
Make it stick · example · pocock

Worked example: mattpocock/skills

  • Matt Pocock published his personal .claude/skills/ as a public repo — dozens of small, sharp, single-purpose skills, each one SKILL.md.
  • Built against four failure modes: misalignment, verbosity, non-functional code, architectural complexity.
  • Two kinds: user-invoked (you type /grill-me) and model-invoked (tdd triggers itself off its description).
  • No single skill is the point — they compose into a pipeline.
# the pipeline, as skills: /grill-me interrogate the plan until it holds up /to-spec turn the conversation into a spec /to-tickets break the spec into tracked units /implement execute a ticket — TDD + review # model-invoked — trigger on their own: tdd red → green → refactor diagnosing-bugs reproduce → minimize → fix handoff compact context for the next agent

github.com/mattpocock/skills — alignment before code, always; read the files, copy the patterns, adapt the conventions.

49
Make it stick · example · compound

Worked example: Compound Engineering

# one loop, five skills (Every's CE plugin): /ce-brainstorm scope the idea into requirements /ce-plan structured plan for the work /ce-work execute the plan end-to-end /ce-code-review bugs, regressions, standards /ce-compound write the lesson to docs/solutions/ ↳ auto-loaded next time it's relevant
  • A whole method shipped as a plugin — around the loop sit /ce-debug (diagnosis loop), /ce-worktree (isolated branches), /ce-commit-push-pr (ship it).
  • The last step is the whole idea: every solved problem becomes a doc the next session reads before it starts.
  • So each unit of work makes the next one cheaper — the system compounds.

The unit of progress isn't the merged PR — it's the knowledge that compounds. (Kieran Klaassen / Every.)

50
Make it stick · plugin anatomy

Plugins distribute all of it

  • A plugin bundles skills + agents + hooks + MCP servers (LSP servers, monitors too) — one plugin.json under .claude-plugin/.
  • A marketplace is a git repo with a .claude-plugin/marketplace.json listing its plugins.
  • Installed skills are namespaced/plugin-name:skill-name — so nothing collides.
PLUGIN skills agents · hooks MCP servers LSP · monitors marketplacegit repo teammate/plugin install

● CONTEXT A plugin is your team's context, made distributable.

51
Make it stick · publish a plugin

Ship it to the whole team

WALKTHROUGH — from your skill to their /install
1. # wrap it up (skills/ sits at the plugin root): my-plugin/.claude-plugin/plugin.json # name (required) my-plugin/skills/release-notes/SKILL.md 2. # list it in the marketplace repo & push: .claude-plugin/marketplace.json # name: claude-tools git push 3. # teammate, one time: /plugin marketplace add your-org/claude-tools /plugin install release-notes@claude-tools

Skills = your habits. Plugins = your team's habits — versioned, installable in one command.

52
Close · recap

It's all context engineering

It was one machine all along

A token predictor → that thinks → with hands → in a loop → whose context you engineer: route it, delegate it, cache it, write it down.

  • Give Fable the advisor job — a standing rule in CLAUDE.md, not a flag.
  • Write one skill for your most-repeated chore.
  • Add a real verifier to your next /goal — a command, not a vibe.

● CONTEXT Every marker in this deck pointed back here.