Your experience is a runtime dependency

I was talking to Jack Pettit about why people get different results from the same AI agents. The comparison that helped was onboarding a capable new developer: they may know the tools well, but they still need the team's conventions, project history, and expectations for the work.

I think of that context as a runtime dependency. Skills and repo instructions are how I make my working practices available to an agent, so I don't have to explain them again in every session.

#Give the agent the context it needs for the task

An agent doesn't automatically know which test command covers the important path, which generated files to leave alone, or what a reviewer expects to see in a PR description. Those details can determine whether otherwise reasonable work is usable in a particular repo.

Some come from experience: a command that reported success without running the relevant tests, an edge case found in production, or a requirement that usually goes missing from a ticket. Writing them down gives the agent something concrete to act on.

The useful instruction explains the constraint and how to check it. "Be careful with tests" leaves most of the decision unresolved. Naming the command, what it covers, and what a successful result looks like is more useful.

#Put instructions where they apply

I use three places for this context.

Global instructions hold preferences that apply across projects, such as how I want review findings reported, when to search instead of guessing, and how much autonomy I expect before the agent asks me a question.

Repo instructions cover the local workflow: test commands, generated files, issue templates, deployment scripts, and the checks needed before a change is ready. These belong with the code so someone working in that repo can find them.

Skills describe repeatable tasks that need more than a short rule. Reviewing a pull request, refining backlog items, applying brand guidelines, and writing in my voice each have their own inputs, tools, examples, and checks.

The distinction helps keep the context relevant. I don't want every session to load a detailed PR review procedure when I'm only editing a sentence.

#Turn repeated corrections into reusable guidance

When I keep correcting the same mistake, I look for a missing instruction. If an agent repeatedly checks GitHub review status without reading unresolved inline threads, the review skill should explain how to retrieve both. If it keeps editing generated output, the repo instructions should name the source file and the generation command.

Formatting preferences deserve examples too. A short example of the PR description I want is often clearer than a list of adjectives such as "concise" or "technical".

Not every correction needs a permanent rule. Sometimes my request was vague, the mistake was specific to that task, or the existing instruction was simply missed. I want to fix the recurring cause without adding a new paragraph for every bad response.

I've also gone too far in the other direction. Loading too many rules makes sessions slower and harder to follow. A skill should provide the constraints and checks for a task, with enough room for the agent to choose how to complete it.

#Keep the guidance useful as models change

A model upgrade doesn't make my repo conventions or review preferences obvious to it. Those instructions can still help, even when the model needs less guidance with the implementation itself.

I expect some instructions to become unnecessary as the tools improve. Others describe decisions that remain specific to my work. Keeping the reason for a rule beside it makes that easier to judge later.

For me, the useful work is making an implicit expectation explicit: what matters, where the evidence is, and how to check the result. When the same correction keeps coming back, I put it in the repo instructions or the relevant skill, then check whether the next task actually benefits from it.