The Runbook · The Durability Curve

Did Your AI Actually Read the Doc?

Fri, 16 Oct 2026 00:00:00 GMT

Yesterday you and ChatGPT settled the plan. Today’s chat has never heard of it, and Claude never saw it either. So you paste it in again, and whatever you forget to paste gets decided twice.

This guide puts the plan in one Google Doc that both assistants read, in three steps, then gives you a test that shows whether a new chat is reading the current version. If you only use one assistant, its built-in Projects feature keeps your notes across chats in that app, which may be all you need.

Connect both assistants to Google Drive

Use the Google account you will keep the doc in. Connecting lets each assistant search everything that account can open, including files far beyond this doc. If Google says your organisation blocks it, your admin has to allow it.

Claude. Open Claude’s connector settings, click the + next to Google Drive, and sign in to Google. A tick means it’s already connected. Anthropic offers this on every plan, Free included; on Team and Enterprise, an Owner has to add it first.

ChatGPT. Open ChatGPT and click Plugins in the left sidebar. If Google Drive shows a +, click it and sign in to Google. OpenAI doesn’t list which plans include it; it was there on our Plus account. If Google Drive isn’t there, use the doc with Claude and paste its text into ChatGPT when you need it there. That copy won’t update itself.

Make the doc

Create a Google Doc in that same Google account, with a name no other file in your Drive uses, paste this in, fill in the brackets, and swap the example decision for one of yours. Keep everything in the body of the doc, not in comments, which some connections can’t read.

ABOUT THIS PROJECT
Goal: [what this project is for, in one sentence]
Audience: [who the work is for]
Current priority: [the next specific task]
Rules for any AI:
Read this whole document before you start.
If you cannot open it, say so. Do not guess.
Link a source for every fact. Say when you are unsure.
Never publish, send or spend anything without asking me.

DECISIONS (newest at the top; a newer line wins)
2026-10-15: Link every statistic. Why: one went untraced.

Each time you settle something, add it as a new first line under DECISIONS, with the date. A decision made in a chat isn’t in the doc until someone writes it there.

Start every chat the same way

Claude. Open a new chat in Claude, click the + in the message box, then Connectors, then Add from Google Drive. Search for the doc, tick it and click Add to chat. Anthropic says Claude re-reads it each time you send a message, so your latest edits reach it.

ChatGPT. Open a new chat in ChatGPT, type @ at the start of your message and pick Google Drive from the list.

In both apps, put the prompt below in that same first message. It tells the assistant which doc to open:

Open my Google Doc "[doc name]" and read all of it.
Tell me the current priority and the newest decision.
Then help me with: [task]

The test

Both assistants can remember earlier chats, and an answer from memory sounds the same as an answer from the doc. An AI can even cite a source it never read. So give the doc a word no chat has seen.

Type a new first line under DECISIONS with today’s date and a word you make up. Type it in the doc only, never in a chat.

[today's date]: Test. Codeword: [your made-up word]

In each assistant, open a brand-new chat, attach the doc as in step 3, and ask:

Open my Google Doc "[doc name]".
Quote the first line under DECISIONS exactly,
and name the doc you opened.

It quotes today’s codeword. It fetched the current doc. Go on to the second question below.
It quotes anything else. It didn’t fetch the current doc. Check you attached the right one, then try once more in a new chat. If it still fails, don’t rely on that assistant for this project yet.
It can’t find the doc. Check that the Google account you connected in step 1 is the one that owns the doc.

Quoting a line shows it can fetch the doc. To check it can use it, ask in the same chat:

Which decisions are settled, and what should you do next?

It should name your current priority and leave everything under DECISIONS settled. If it reopens a decision or picks other work, make that decision or the current priority clearer in the doc and ask again. We ran both questions in Claude and ChatGPT on 15 October 2026: both quoted the codeword, and both followed the newer of two conflicting decisions.

Delete the test line afterwards. Rerun the test with a new codeword whenever you change assistant, plan or settings.

When to move it to GitHub

Skip this unless you want your assistants to hand work to each other. A repository on GitHub is a project folder that keeps every version of its files, and a change there can set an assistant working once you have set up a task to watch for it. On ChatGPT Plus or Pro, you can create a task in Work that starts by itself when someone opens a pull request, GitHub’s name for a proposed change. OpenAI names only Gmail, Slack and GitHub as triggers for these tasks, so a Google Doc isn’t one of them. On a paid Copilot plan, you can hand a task to Copilot, GitHub’s own assistant, or (in preview) to Claude or OpenAI’s Codex, and get a proposed change back to review.

To move, you need a free GitHub account. Signed in, open github.com/new, type a name, choose Private, add a README, and click Create repository.

Open README.md, click the pencil at the top right of the file to edit it, and replace its text with this, filled in from your doc:

# [Project name]

- Goal: [what this project is for, in one sentence]
- Audience: [who the work is for]
- Current priority: [the next specific task]

## Rules for any AI

- Read README.md and DECISIONS.md before you start,
  and tell me which files you read.
- If you cannot open a file, say so. Do not guess.
- Link a source for every fact. Say when you are unsure.
- Never publish, send or spend anything without asking me.

Click Commit changes…, then Commit changes in the box that opens, leaving it on the main branch. Click the repository’s name at the top to go back to its main page, then click Add file, then Create new file, and name it DECISIONS.md. Paste this, replace the example line with your decisions from the doc, newest first, each starting with a dash, and save it the same way:

# Decisions (newest at the top; a newer line wins)

- [date]: [what you decided]. Why: [why]

The doc and the repository won’t update each other, so edit only the repository from then on. For ChatGPT, add GitHub from Plugins, as in step 1, and give it access to this repository (OpenAI’s steps); a new repository can take about five minutes to appear there. For Claude, add the repository to a chat or a project (Anthropic’s steps); in a project, select Sync now after you change a file.

Neither connection can write, so you or a coding assistant make the changes. A connection only gives access, so open each chat by asking for README.md and DECISIONS.md. To run the test here, put the codeword line, starting with a dash, at the top of the list in DECISIONS.md and ask a brand-new chat to quote the first decision in DECISIONS.md exactly, then delete the line. We run our own team of assistants this way, and each one needed its own trigger, because the repository tells nobody when new work arrives.

Two rules

Keep passwords and private details out. Deleted text can usually be brought back from the doc’s version history, so if a password gets in, change it.

Treat text other people add as a stranger’s instructions. If you share the doc, anyone who can edit it can write something your AI will read and may follow. Invariant Labs showed this in a May 2025 demonstration: a message they planted in a GitHub issue steered an AI agent into leaking private data.

Use AI to Learn Without Getting Worse at It

Thu, 24 Sep 2026 00:00:00 GMT

Answer-giving AI left learners worse off once it was gone. Three setups built to keep the thinking with you, and a way to check what stuck.

If you have used ChatGPT this month to get through something you are learning (a spreadsheet formula, a new codebase, the rules of a new job), it probably felt like progress. The answer was always one message away.

A team of researchers tested it. Nearly 1,000 Turkish high-school students practised maths, some of them with a ChatGPT-style assistant beside them. That group’s practice scores rose 48%. Then the assistant was taken away for the exam, and they scored 17% lower than students who had never had it. The analysis the authors registered in advance puts the drop about a third smaller, but it is still a drop. In the chat logs, students had often asked for the answer and copied it.

Easier practice is not evidence that you learned the thing. The effort you skip is often the part that was teaching you.

When you only need the answer, take it. This is about the times you need the skill, because you will have to do it again with nobody to ask.

Experienced programmers too

The Turkish students were teenagers. In January, Anthropic published a trial with 52 Python programmers, recruited through a crowd-work platform, learning a Python library that was new to them. More than half had seven or more years of coding experience. Half of them worked with an AI assistant; afterwards everyone took a quiz with no AI allowed.

The AI group scored 4.15 points lower on the 27-point quiz, roughly 15 percentage points, and they were not significantly faster. They learned less and got little or no time back.

Who did the thinking

Some of those programmers scored well anyway, and they had used the assistant differently. Those who handed it the work, leaned on it more as the task went on, or had it debug for them averaged 24% to 39% on the quiz. Those who asked it conceptual questions averaged 65%, about the same as the group with no AI. The best result, 86%, came from two people who let it write the code and then questioned it until they understood what it had written. The groups were small and sorted after the fact, so treat them as a clue.

A separate team found the same split. In pre-registered experiments with German university students learning to code, the researchers found no effect of a chatbot on learning overall. Inside that average, students who used it to generate solutions covered more topics but understood less, and students who used it to ask for explanations understood more. That split was exploratory. In the same study, 42% of requests for a solution came before the student had tried at all.

Only the Turkish trial tested the design directly. Its second AI group had an assistant told to give hints, with the correct solutions loaded. Their practice scores rose 127% and the exam damage disappeared, though they did no better than students with no AI. Two other trials show well-designed tutors teaching well without isolating who did the thinking. At Harvard, 194 physics students each learned one lesson from a tutor told to encourage a first try and release the solution one step at a time, and another in an active-learning class; median gains with the tutor were more than double the class’s, though it answered whenever a student demanded it. In Nigeria, teacher-guided sessions with a chatbot raised English scores 0.238 standard deviations against students who got no programme at all.

Not every result fits. Google’s trial of Gemini’s Guided Learning raised maths scores overall, but its younger year group did slightly worse. The German study found no overall effect either way.

The consistent part is narrow and useful. In two randomised trials, an AI assistant used freely during practice left people worse off once it was gone. In both studies that looked at how people used it, those who asked for explanations did better than those who asked for answers. So keep the thinking on your side of the chat: try before you ask, and ask it to explain. Three ways to set that up follow.

Level 1: switch on the learning mode you already have

As of September 2026, according to each company’s help pages and apps:

ChatGPT: type @study, or press + and choose Study. It is on every plan, though it does not work inside Projects.
Gemini: Add files, then More tools, then Guided Learning.
Claude: first switch on Code execution and file creation under Settings, then Capabilities. Then add Anthropic’s learn skill from Customize, then Skills, then Discover. It stays out of coding tasks by design; for code, see Level 2.
Copilot: open Quick response under the prompt and choose Study and learn.
Claude Code: type /output-style learning.

Then one habit: before you send a question, write your own answer, even a bad one.

Treat the modes as a start. OpenAI’s own help page says Study mode may still give a direct answer, and the companies’ own trials are early. In OpenAI’s one-session study, students using Study mode scored roughly 15% higher than with ordinary online resources in microeconomics, and no differently in neuroscience.

Level 2: paste a tutor prompt

The modes are not everywhere, and they slip. A prompt goes anywhere. Paste this at the start of any chat where you are learning, and fill in the last two lines:

Be my tutor for this. I'm trying to learn it, not just get it done, so help me work it out myself.

1. Don't give me the answer or write the solution for me. Give me one hint or one step at a time, then wait for my reply.
2. If I ask you to just tell me, ask me to try first. Count every wrong answer or guess as a try. After my second wrong try, give me the answer and explain the step I missed.
3. When I get something right, confirm it and ask me why it works.
4. Keep every reply to a few sentences.
5. When we finish, give me a similar problem to try on my own.
6. If you're not sure something is correct, say so.

What I already know: [e.g. basic percentages, nothing about probability]
The problem: [paste it here]

It borrows Harvard’s try-first, one-step shape and the Nigeria exercises’ hint-then-answer rule, and it is stricter than Harvard’s tutor, which answered on demand.

I ran it eight times with a scripted learner: seven across Claude, Gemini and GPT, one in the ChatGPT app. Each time the learner demanded the answer, the tutor asked for an attempt, and after the second wrong try it gave the answer and named the missed step. Once, asked for fixed code, GPT held back the code but described the fix in words, which gave most of it away.

On a long problem some models count tries per step, so the answer arrives a step at a time; that is fine. If a hint gives the answer away, reply “smaller hint”.

This is the same move as asking for the step before the answer, kept on for a whole session.

If you are learning code, use /output-style learning in Claude Code, or paste the prompt with the function or error as “the problem”. When it does write code, do what Anthropic’s top-scoring pair did: ask why each part is there until you could write it yourself. Then, my suggestion: close the chat and write it.

Level 3: give it your material, then test yourself cold

Levels 1 and 2 set up the tool. This level adds your own material, and it measures you.

Create a project for the thing you are learning. In ChatGPT, New project in the sidebar. In Claude, Projects, then New Project (the free plan allows five). In Gemini, a Gem with your files added.
Paste these instructions into the project’s instructions:

You are my tutor for the material in this project. I'm here to learn it, not to look things up, so make me work for every answer.

1. Before you answer anything about the material, check the files in this project. Use them as the source of truth. If they don't cover it, say so before you answer from general knowledge.
2. Whenever I ask a question about the material, don't answer it yet, even if I say "just tell me". First ask me what I think, or give me one hint.
3. Count every wrong answer or guess as a try. After my second wrong try, give me the answer from the files and explain the step I missed.
4. When I get something right, confirm it and ask me why it works.
5. Keep every reply to a few sentences.
6. If you're not sure something is correct, say so.

Upload your material: course notes, documentation, your team’s handbook if you are allowed to put it into that service, and an answer key if you have one. The Harvard team loaded every question with its worked answer; without your material, a tutor falls back on what it already knows.
Test the setup before you trust it. Ask a question about the material and add “just tell me”. If it answers straight away, the setup is not holding. My first version failed exactly this test in the ChatGPT app, answering at once from general knowledge. The version above passed with a hint drawn from the file.
Learn in chats inside the project.
A few days later, run the cold check. Open a new chat in the project, paste this, and fill in the topics you studied:

Cold check. Quiz me on what I've been learning from the files in this project.
Only ask about these topics: [list what you studied]
Ask 6 questions, one at a time. Mix "what is" questions with "what would you do if" questions.
Don't give hints and don't tell me whether I'm right until all 6 are done.
Then score me out of 6, show the correct answer from the files for each one I missed, and list what I should review.

Answer from memory, with no notes. In the ChatGPT app, with a planted mix of right and wrong answers, every question stayed on topic, it gave no feedback until the sixth, and it scored 3 out of 6, marking exactly my wrong answers and correcting each from the file. I did not test the Claude or Gemini apps themselves, so run it once with answers you know are right and wrong before relying on the score.

The German study found students felt they had learned more than they had. A score checked against your files is a better guide than that feeling, though I tested the marking only on short factual questions, so check each marked miss against the source. Put the check in your calendar and paste the prompt yourself. Whatever you missed goes back into a tutoring chat.

What the research can and cannot tell you

None of the seven studies tested people again weeks or months later, so none shows the learning lasted. Only two went through journal peer review. The evidence on how people used the AI comes from patterns inside two studies, not from assigning them. Three trials were run by AI companies, and in Nigeria the comparison group got no programme at all.

Your own cold check a few days later is the only follow-up test in this piece.

The checklist

Next time you open an AI to learn something:

Decide whether you need the answer or the skill. For the skill, keep the thinking on your side.
Switch on your app’s learning mode, or paste the tutor prompt.
Write your own answer before you ask, then ask it to explain.
If a hint gives it away, ask for a smaller one.
For anything you need to know properly, put your material in a project and test the setup with “just tell me”.
A few days later, run the cold check on the topics you studied, with no notes, and send what you missed back into a tutoring chat.

The Nigeria exercises drew in part on tutor prompts published by Ethan and Lilach Mollick in 2023.

The Skill That Never Fired

Mon, 31 Aug 2026 00:00:00 GMT

A skill can fail in two ways. Its instructions can be wrong, so it does the job badly. Or Claude can decide never to load it, so the instructions never run at all. The first failure is obvious when you test the skill by name. The second only shows up when you test whether Claude chooses it on its own.

The second failure is the quiet one. You write a skill, you invoke it by name to check it, and it works. Then in normal use it just sits there. Claude answers without it. Nothing errors, nothing warns you, and the skill still shows as installed. It was never wrong. It was never chosen.

That choice is a routing decision, and Claude makes it by matching the request against your skill’s name and description, before it reads a word of the body. The Claude Code docs say it directly: the description is what helps Claude decide when to load a skill. Anthropic tells you to test that decision, separate from the skill’s output, and ships a tool that does it. Its skill-creator scores one target skill over repeated runs: does this skill fire on the prompts it should, and stay quiet on the ones it should not?

What that score does not tell you is what happened when another plausible skill was there too: whether the neighbour took the request, both fired, or neither did. That is the failure this piece is interested in, where your skill sits beside one that could answer it and the winner is not guaranteed to be yours. This walks through building a skill, watching that decision for yourself, and grading it against the neighbour it can lose to. You can run a first pass in about 15 minutes at a terminal.

What a skill is

At its simplest, a skill is a folder with one required file, SKILL.md. It can also hold scripts and reference files that load only when needed, but the minimum is the one file:

---
name: customer-date
description: Format a date for customer-facing UK correspondence (emails, letters, messages to customers) as D Month YYYY. For CSV or data exports, use export-date.
---

Rewrite the date the user gives in UK long form, for example 30 August 2026. Reply with only the formatted date.

For a normal auto-invocable skill, the name and description sit in Claude’s discovery context so it can decide whether the skill is relevant. The body below the frontmatter loads only when the skill is invoked, whether Claude chooses it or you type its name. Claude sees both the name and the description, and the description is the main field Anthropic gives you for saying when the skill should run. Write it for the router, not as a note to yourself. Claude Code also accepts a when_to_use field, appended to the description; these skills use only a name and a description.

Three common ways to use a skill. In claude.ai, turn on code execution, open Customize then Skills, and upload the folder as a zip. In Claude Code, put the folder in .claude/skills/ for one project or ~/.claude/skills/ for all of them. Through the Claude API, you upload it and reference its skill_id. The core SKILL.md format travels across all three, though installation differs and some frontmatter, including the disable-model-invocation used later, is specific to Claude Code.

Watching the routing decision

The mistake to avoid is judging a skill by its output. Ask Claude to format a date and you might get 30 August 2026 whether your skill ran or not, because the model can format a date on its own. The output tells you nothing about routing.

You want the decision itself. In Claude Code, a skill runs through a Skill tool that appears in the event stream. Run a prompt non-interactively and filter the stream down to the skill call:

$ claude -p "Rewrite this date for the customer email: 2026-08-30" \
    --output-format stream-json --verbose \
  | jq -c 'select(.type=="assistant") | .message.content[]?
           | select(.type=="tool_use" and .name=="Skill") | .input'

{"skill":"customer-date","args":"2026-08-30"}

That last line is the filtered result, not the raw stream, which wraps each event in more metadata. If the reader prints nothing, dump a raw event and look for a Skill call by hand, because the stream’s shape shifts between versions. It is the routing decision read from the tool call, not guessed from the output. /skills shows which skills are available to Claude and /context shows the discovery listing’s context cost, but neither proves this prompt invoked one. In claude.ai there is no equivalent machine-readable event. Anthropic’s guidance is to review Claude’s thinking to confirm a skill loaded, which works for checking by eye but not for building the kind of record above. And the event stream shows the skills Claude actually invoked, both of them when it invokes two, which is how a both shows up at all. What it does not expose is the candidate set: the other installed skills that were plausible but never invoked. You see what fired, not what it beat.

Routing is a decision you can grade

Whether a skill fires is a choice among whatever skills could plausibly answer the request. You can only grade that choice if you know what the right answer was before you run it.

So I built two skills with different jobs. customer-date, above, formats dates for customer emails in long form. export-date formats them for CSV exports as DD/MM/YYYY. Then I wrote a labelled prompt set: 4 requests that clearly want the customer skill, 4 that clearly want the export skill, and 4 date-adjacent requests that should fire neither. Every result gets one of four labels: right, wrong, none, or both.

Start with the failures, because they are where the method earns its keep.

Ambiguous request. Ask “Format this date: 2026-08-30” with both skills installed, and the results scatter: sometimes one fires, sometimes both, sometimes neither. That scatter is the expected result of an ambiguous request. The request never said whether it wanted the customer or the export format, so there is no correct answer to grade against. An ambiguous prompt is not a failed test, it is an ungradable one. If you cannot label the right skill before running it, the result cannot tell you whether Claude chose well.

Names and descriptions that draw no line. I named two skills for their output format, long-date and slash-date, and gave them the same vague description, “Format a date.” Their bodies did different things, but their discovery metadata claimed the same job, so there was no boundary for the router to use and nothing told Claude which one fits a customer request. The grades went bad in the way that matters: one customer prompt fired nothing at all, and 2 export prompts fired both skills at once. Misses and double-fires, which is why “both” has to be one of your outcome labels.

Then the control, so you can see what clean looks like. Give the two skills distinct, use-case descriptions, and ask prompts whose wording matches those use cases, and routing is clean: 8 out of 8 to the right skill, and the neither-prompts correctly firing nothing. That is the model doing the keyword and intent matching you made easy for it. It is the case that should work, and it does. Note that the customer prompts contain words like “customer email” that are already in the customer skill’s description. Clean routing here is a control condition, not proof that routing is robust. The evidence is in the failures above.

The fix

Routing runs on the discovery metadata Claude can see, which is the name and the description together, and my runs show either one can carry it. When the names were the vague part but the descriptions were sharp, routing was clean. When the descriptions were the vague part but the names said the use case, customer-date and export-date, routing was also clean, 8 out of 8 on the same prompts. That name-only run is an easy case, mind: the prompts carry the same words as the names, customer and export, so it shows a name helps when the request echoes it, not that a bare name is a strong signal on its own. It broke in one condition only: format-only names, long-date and slash-date, plus a shared vague description, where neither field told Claude what set the two skills apart.

That broken condition is the useful one. I left the weak names alone and rewrote only the descriptions around use cases, and the mess went to 8 out of 8. A good description rescued names that carried no signal. A good name had already done the same for descriptions that carried none. What you cannot do is leave both vague and expect Claude to find the line.

So write the description as a routing rule, not a summary. Put the use first. Include the words people actually type when they want this skill. Draw the boundary against the neighbour it might be confused with.

Some skills should not be auto-routed at all. Anything with a side effect or a real cost is safer as a skill you invoke by name, /customer-date, or one you lock with disable-model-invocation: true so only a person can trigger it. For those, manual invocation is the design, not a workaround. The rule underneath: how much routing error you can accept depends on what a wrong route costs. When the cost is high, the fix is often to stop routing automatically rather than to tune the description harder.

The failure that has nothing to do with your skill

There is one more way a skill stops firing, and no description work touches it. For skills still exposed to the model, Claude Code keeps every skill’s name in the discovery listing, but the listing has a budget, around 1% of the model’s context window, and once it runs over, Claude Code starts dropping descriptions, beginning with the skills you invoke least. That can strip out exactly the words that told two skills apart. So a skill whose description used to distinguish it cleanly can start missing once your catalogue grows large enough, with nobody editing it. /doctor reports the listing’s cost. If a skill that used to route well starts slipping, check the size of your catalogue before you rewrite the skill: prune the skills you do not use, shorten the descriptions that survive so the distinguishing words fit, set low-priority skills to name-only so Claude keeps their names without their descriptions, or set rarely-used skills to disable-model-invocation: true, which takes them out of the router and its listing entirely; you still invoke those with /name.

Worth knowing before it bites a team: skills with the same name at different levels do not merge, one shadows the other. The order is enterprise, then personal, then project, so a /deploy skill in your ~/.claude/skills/ silently overrides the one your repo ships in .claude/skills/. If you commit skills for a team, give them names that will not collide, and do not rely on the project copy winning. This is also where overlap arrives for people who did not build it: a marketplace pack or an inherited folder drops in a skill whose description competes with one of yours, and the first you hear of it can be a skill that used to fire and now does not.

Which layer failed

The check separates two layers that a vague “it didn’t work” runs together. Execution failure means Claude loaded the skill and the body did the wrong thing. Selection failure means the right body never got its chance to run at all. Everything else in this piece is a kind of selection failure: a discovery miss, interference from a neighbour, two definitions that overlap, a listing truncated at scale, a same-name skill shadowing yours. Only execution failure is about the instructions. The rest is why a skill can regress with nobody touching it, and why testing the body is only half the job.

The stakes climb once the skills matter. A date formatter losing to its twin costs you a wrong date format. A code-review skill that loses requests to a generic “help me with this file” skill costs you the review you thought ran on every change. Whether that happens turns on the same thing as the date skills: whether the two descriptions draw a line the router can use. The installed list will not tell you, so check it directly. Ask “look at this diff” with both installed and the route can go four ways: cleanly to the review skill, to a both, to the generic skill alone, or to neither. Give it requests whose correct skill you know, install it next to the neighbour you suspect, and read which one the Skill tool actually calls.

Run it yourself

The official skill-creator plugin measures a target skill’s trigger rate for you. The manual version here adds the identity of the competing skill, so you can tell a miss from interference, a neighbour firing instead of the target or alongside it, reproduce a collision between two specific neighbours, and read the Skill call yourself. There is a second reason to read the calls rather than trust a score: as of the current evaluator (August 2026), it reads the first tool call in a run and counts the target as not fired if anything else, a neighbour skill included, gets there first, so the interference this piece is about can quietly lower the very rate meant to catch it. Here is the whole pack. Two skills, twelve prompts, four outcome labels, and the one-line reader from earlier. It is also a download, at durabilitycurve.com/tools/skill-routing-eval.

The skills, with descriptions that draw the boundary:

---
name: customer-date
description: Format a date for customer-facing UK correspondence (emails, letters, messages to customers) as D Month YYYY. For CSV or data exports, use export-date.
---
Rewrite the date the user gives in UK long form, for example 30 August 2026. Reply with only the formatted date.

---
name: export-date
description: Format a date for CSV or database exports (spreadsheets, data files) as DD/MM/YYYY. For customer emails and letters, use customer-date.
---
Rewrite the date the user gives in slashed form, for example 30/08/2026. Reply with only the formatted date.

The prompts, each with its known-correct skill:

should fire customer-date:
  Rewrite this date for the customer email: 2026-08-30
  Put this date in a letter to the client: 2026-08-30
  Format the date for a message to a customer: 2026-08-30
  Tidy the date in this customer-facing note: 2026-08-30

should fire export-date:
  Format this date for the CSV export: 2026-08-30
  Put this date into the spreadsheet export: 2026-08-30
  Format the date for the database file: 2026-08-30
  Prepare this date for a data export: 2026-08-30

should fire neither (date-adjacent work these formatters should refuse):
  What is today's date?
  When did the Second World War end?
  Parse this log timestamp: 2026-08-30T14:22Z
  What day of the week is 2026-08-30?

Install both skills, run each prompt through the jq reader above, and mark the result right, wrong, none, or both. Those labels roll up into three numbers worth watching. Recall: of the requests that should fire a skill, how many did. False triggers: of the requests that should not, how many fired it anyway. Interference: with a neighbour installed, how often that neighbour fires on a request meant for this skill, either instead of it or alongside it. Recall and false triggers are what the standard trigger-rate test measures for one skill, from its positive and negative cases. Interference is the number it cannot give you, because it only records whether the target fired, not which competing skill fired instead or alongside it. Score a both as a hit on recall and on interference at once: the intended skill ran, but so did a skill that should have stayed quiet. A skill that scores well alone and badly in company has a selection problem, and editing the body will not touch it.

What I measured on Claude Opus 5, arranged by what actually distinguished the two skills:

In this run, either signal alone held the line; only the condition where neither field distinguished the jobs produced misses and double-fires.

On the date-adjacent negatives above, run against the distinct-description pair, both skills stayed quiet: 0 false triggers in 4. Those negatives ran against the sharp descriptions only, so this does not show how false triggers rise as a description gets vaguer. Run the same set against the descriptions you plan to ship: a clean positive-routing score will not tell you whether a skill grabs adjacent work it should leave alone. Small numbers, one model, one surface, and single runs. The routing choice is a model decision that can scatter, so a clean 8 out of 8 is one draw, not a settled rate; run each prompt a few times and read how often the right skill wins, not a single mark. This is a diagnostic you run on your own skills, not a benchmark, and the caption matters more than the cells: this is the shape of the thing, not what Opus 5 does in general. Two skills is the floor, not necessarily the hard case. A real catalogue may have several plausible neighbours, so run the eval beside the skills your target actually competes with, not only against a clean pair.

The habit

A skill has two ways to fail. Its instructions can be wrong, and you probably test that already. Or Claude can never choose it, and that one leaves no mark: the skill sits installed, looking healthy, and quietly does nothing.

Test whether Claude chooses the skill. The output looking right does not prove the skill ran. The skills you never test that way are the ones you only think are working.

The pack here, two skills, twelve labelled prompts, and the run.sh reader, needs only the claude CLI and jq and is yours to keep: durabilitycurve.com/tools/skill-routing-eval.

Stop Re-Priming Claude Code by Hand

Mon, 10 Aug 2026 00:00:00 GMT

What you will do: take the block of context you paste at the start of every Claude Code session and put it in one file, so you type /prime instead. About fifteen minutes.

Who this is for: you come back to the same project across many sessions, and you keep re-pasting the same “here is the project, here is where things stand” preamble before real work starts.

Who should skip it: if you open a fresh project every time, or never re-explain anything, there is nothing here for you.

You need: Claude Code (a recent 2.1.x release; the mechanics here were checked against the docs on 9 August 2026), a project you return to, and a shell.

Every session starts the same way. You open Claude Code and spend the first few minutes telling it where you are. This is the project. Here is what you changed last time. Here is the thing that is half-finished. Leave the migration alone. You have typed some version of that briefing fifty times, and you are the one keeping it in your head and re-entering it by hand.

That is a prompt you repeat, and a prompt you repeat should be a command you type. Claude Code lets you save one as a file and invoke it with a slash. The good version does more than paste static text back at you: it runs a couple of commands and reads a couple of files first, so the context arrives already filled with your project’s current state. By the end of this you will have /prime, and starting a session will be one word.

One file becomes one command

The smallest possible version is a single file with one line in it. In your project, create .claude/skills/prime/SKILL.md (a prime folder with a SKILL.md inside it):

Summarise where this project stands and what I should work on next.

Save it. In Claude Code, type / and prime shows up in the list; run /prime and the agent does what the file says. The folder name is the command: a prime folder gives you /prime. Claude Code watches existing skills folders and picks up a new or edited skill the moment you save it, no restart. The one exception is the very first time: if .claude/skills/ did not exist when you started the session, restart Claude Code once so it begins watching the new folder, and saves are live after that.

That is already a command, and it already saves you the typing. But it is static. It says the same sentence every session and knows nothing about what actually changed since last time. The next step is where it earns its place.

Make it load your real state

Two small pieces of syntax turn the file from a saved sentence into a live briefing.

A line that starts with !`command` runs that shell command and drops its output into the file before Claude reads it. The docs call this dynamic context injection: “the command runs first, and its output gets inserted into the prompt,” so the agent receives the actual data, not the instruction to go and get it.¹ A line with @path/to/file inlines that file’s contents the same way. Put them together and /prime can walk in already knowing your latest commits, your uncommitted changes, and whatever notes you keep.

Open that same file and replace its one line with the fuller version below, which you can adapt to any repository. Swap NOTES.md for the short file where you keep current project state, not your whole project history:

---
description: Load where this project stands and print a short situation report
argument-hint: "[optional focus area]"
allowed-tools: Bash(git log *) Bash(git status *)
---

Recent work on this branch:
!`git log --oneline -10`

Branch and uncommitted right now:
!`git status --short --branch`

Current state notes, read in full:
@NOTES.md

Give me a four-line situation report: what branch I am on, what changed
recently, what is unfinished, and what to pick up next. If I named a focus
area ($ARGUMENTS), orient every line to it.

The point is what the reader on the other end receives. Not “go check git” but the actual log, the actual dirty files, the actual notes, already in front of the model, followed by a request to make sense of them. $ARGUMENTS is whatever you typed after the command, so /prime the auth refactor pushes “the auth refactor” into that placeholder and the report orients to it. The two lines at the top of the frontmatter are optional labels: description is the text that shows beside /prime in the menu, and argument-hint is the grey prompt after it.

To show it doing real work, here is ours. Our project is a large notes vault whose rulebook says: before you touch anything, read the pipeline status, read the working briefing, read the vault vitals, and check none of it is stale. That was three files and a freshness check we opened by hand at the start of every session. Our /prime injects all of it and ends with a read. Invoked against our live state, it returned:

1. Pipeline: red. One red alert, a knowledge-review backlog; two yellow,
   the weekly cleanup twelve days overdue and a staging queue filling up.
2. Binding constraint: the output bottleneck. Six pieces ship-pending,
   all marked critical, the oldest sixty-four days. Ship before building.
3. Last session: perfected and shipped the opening piece of a new series.
4. Next: take one of the built-and-parked series pieces to publish-ready.

That is the whole payoff: the state of the project, the one thing that matters most, and where to start, assembled before I said a word. Those four lines are ours, from our injects; run the git template above and /prime hands you the same shape filled with your own project, your commits and dirty files and notes in place of our pipeline and briefing.

Let it run without asking

Unless those commands are already allowed by your own permission settings, Claude Code stops and asks the first time each injected command runs. The allowed-tools line in the frontmatter above pre-approves them for you, so /prime runs clean:

allowed-tools: Bash(git log *) Bash(git status *)

Each entry is a pattern: Bash(git log *) means “any command starting with git log, no prompt,” and Bash(git status *) does the same for git status. These two pre-approve only the reads /prime actually needs; anything else stays subject to your normal permission prompts. A blanket Bash(git *) would pre-approve git push, git reset, and every other git command without a prompt too, so keep the grant to the narrow pair. It is scoped to the turn that /prime runs in and clears when you send your next message, so you are not opening a standing hole in your permissions either.

One honest wrinkle from ours: our freshness line runs TZ='Europe/London' date, and the leading TZ= assignment does not always match the command prefix cleanly, so the first run still asks once. We approve it and move on. If one of your lines keeps prompting despite an allowed-tools entry, that mismatch is why; simplify the command or approve it the once.

One caution that matters more once the file is not yours to begin with: a skill runs shell commands and can pre-approve its own tools, so treat one you pulled from someone else’s repository like a script you are about to run. Read its !` lines and its allowed-tools before you invoke it.

Why not just put this in CLAUDE.md?

If Claude Code already reads a CLAUDE.md at the start of every session, a fair question is why this is not a few more lines there. The docs draw the line by what changes. CLAUDE.md is for facts that hold every session: your conventions, your architecture, the guidance you want in front of Claude every time. It loads into every session, which makes it the wrong home for anything that moves underneath it.

/prime is for the things that move. Where the tests live belongs in CLAUDE.md; what you touched last, what is uncommitted, the one thing on fire this morning, all of that is different by the next session, and you want it recomputed when you ask rather than hand-edited into a file.

That is the real move here, and it is bigger than one command. The durable thing to save is the procedure that fetches the state. A commit list or a status line goes stale the moment you write it down; a command that runs git and reads your notes fetches the current answer every time. Keep the procedure narrow, though: whatever /prime injects stays in the conversation and costs tokens on every later turn, so its job is to locate the work, not to preload your whole project. If it starts turning into a project dump, stop adding files.

You may see the older one-file form

If you read around, you will find the same trick written as a single .claude/commands/prime.md file with no folder. That is the older shape, and it still works: a .claude/commands/prime.md and a .claude/skills/prime/SKILL.md both create /prime and behave the same way. The skills folder is the form the docs point you to now, and the reason is room to grow. A folder holds more than the one file, so it carries supporting scripts when your /prime gets ambitious, and a skill can let Claude reach for it on its own when it fits (add disable-model-invocation: true to keep it strictly manual, /prime only). If you already have a one-file command, leave it alone, it keeps working. Reach for the folder when the command outgrows a single file, and if you ever keep both under one name, the skill wins.

When it does not fire

It is not in the / list. You are probably not in the project, or the file is not at .claude/skills/prime/SKILL.md (the folder has to be named prime and the file SKILL.md). A skill in ~/.claude/skills/ instead works in every project.
It runs, but Claude never reaches for it on its own and the menu shows no hint. The frontmatter did not parse. A malformed YAML block does not remove the skill: /prime still works, but it loads with empty metadata, so the description no longer matches. Start Claude Code with --debug to see the parse error, then line up the --- fences.
It prompts for permission every single run. Your allowed-tools pattern does not match the command you inject. Line the prefix up exactly, for example Bash(git log *) for a git log line.
$1 is not what you expected. In the skills model, indexed arguments are zero-based: $0 is the first argument, $1 the second. Reach for $ARGUMENTS when you just want “everything I typed,” and leave positions alone unless you genuinely need them.
The output did not appear. The injection only fires from a !`…` backtick span with a leading !. A command sitting in a plain fenced block is shown to the model as text, not run.

Prove it loads

Do not take my word that the injection fired. Run /prime and read the top of what comes back. If it references your actual latest commit message and your actual files, the commands ran and the state is real. If it hands you generic advice that would fit any repository, nothing injected: your !`…` or @ lines are the place to look. A command that prints the same thing regardless of your project is just a saved sentence, which is where we started.

Once it loads real state, you have turned a paragraph you retyped every session into one word, and the machine does the fetching. That is the pattern for the whole series: a thing you do by hand, moved into a tool you set up once and then just run. This one only read your project. The next rung is about letting Claude Code change it safely: a guardrail that stops the agent before it edits a file you marked off-limits. That is the next Runbook.

Sibling piece, same tool, different job: Never Let Claude Code Tell You It’s Done wires a test the agent cannot talk its way past.

Claude Code documentation: dynamic context injection and slash-command syntax. ↩