The same three corrections, session after session.
An opportunistic refactor I hadn't asked for. An abstraction built for a case that doesn't exist yet. Five tests written before a single one of them had been run.
None of that is a model failure. Each correction was me finding out, again, that the conventions I care about lived nowhere except in my head.
The corrections I repeated were the ones I'd never written down
For a while I handled this with a longer prompt. Every session, I'd retype some version of my standards before setting the work in motion.
That fails two ways. I never typed the same thing twice, so behavior varied session to session for reasons that had nothing to do with the model or the task. The standards I typed were also only the ones I happened to remember while typing: the rest got rediscovered later, in review, which is the most expensive place to find them.
A prompt I retype is not a standard. It's a habit with a bad success rate.
I documented how I want work done, not what work to do
Two skills do most of the lifting for me.
The first covers design conversations. Interview me relentlessly, one question at a time, and bring a recommended answer to each one rather than an open-ended prompt. If a question can be answered by reading the codebase, go read the codebase instead of asking me. That last rule exists because being asked something the repository already answers was one of my most repeated corrections.
The second covers implementation. Read every file you intend to change, in full, before changing it. Adhere to the written plan, and wait for approval. Change only what the plan describes: no opportunistic refactors. No abstractions for hypothetical future work. Keep comments spare, because expressive code beats a comment explaining unclear code. For back-end work, run red, green, refactor one test at a time, thinnest end-to-end slice first. Stage files by name rather than everything in the working directory. Never skip the pre-commit checks.
Read that list back and there's nothing novel in it. It's the onboarding conversation. It's what a senior engineer absorbs in their first month through pull request review, gradually, and then keeps. I never codified it for the agent, something that starts every session as a new hire who read nothing.
Standards belong in a repository, not in a prompt
I manage these with the skills CLI, which installs skills into whichever coding agent I'm using. My own set lives in a repository: github.com/dpickett/ai-skills. When I catch myself making the same correction twice, I stop correcting and go edit the skill.
Two properties earned this its place. The standards are files under version control, so a convention has a history and I can see when it changed and why. They also aren't welded to one vendor's agent, which matters more than it sounds like when tooling turns over this fast.
One thing worth saying plainly: generic skill collections did almost nothing for me. Everything valuable came from conventions specific to how I work and to what a particular codebase expects. Somebody else's standards, installed wholesale, are just a longer prompt. The skills that earn their place are the ones that already sound like me.
One thing to check this week: scroll back through your last 10 agent sessions and note every correction you typed more than once. That list, close to verbatim, is your first skill.
P.S. - If the list is long, you don't have an agent problem. Those conventions were never written down for your engineering team either.