Claude Code gets faster the longer a team uses it, but only up to a point. Past that point, developers on Sydney and Melbourne teams tell us the same thing: the model keeps making the same small mistake in a different session, weeks apart. A migration drops a column without a backfill. A log line quietly leaks a request body. Nothing breaks production outright, it's just the same category of slip resurfacing because nobody wrote the rule down anywhere Claude could check it. It's rarely a skill gap. It's a memory gap, and it turns out to be a fixable one.
The Correction You Keep Making
Anthropic's engineering team published a practical fix for this on 22 July 2026, built around Claude Code Skills. The idea isn't new tooling. It's turning the correction you've made three times into something Claude checks for itself, every time, before the pull request lands. Most teams already know which corrections these are. They're the ones a senior developer leaves on almost every review, phrased almost the same way each time, because the rule never made it out of that person's head and into anything Claude could read. Once it's written down, the correction stops being a recurring line item on someone's calendar.
What Claude Code Already Checks, And What It Can't
Claude Code already runs a gather context, take action, verify loop against whatever signals a codebase exposes: type checkers, linters, tests, runtime errors. That loop catches syntax problems and broken builds without anyone asking, and it's a real part of why Claude Code feels reliable on day-to-day work. What it can't infer is the stuff that only lives in a senior engineer's head, the codebase-specific rules nobody wrote down because they seemed obvious once you'd been burned by them. Two examples come up constantly in Claude Code teams:
Reject any migration that drops a column without a backfill step
Never log the request body on an error path
Neither rule is caught by a generic linter, because neither is generic. They're specific to how your codebase and your data handling actually work, which is exactly why they keep slipping through no matter how good the underlying model gets. A type checker has no opinion on backfills. A linter doesn't know what counts as sensitive in your logs, and it never will, because that judgement is local to your business.
Turning a Rule Into a Skill
The fix is mechanical rather than clever. You write the rule down once as a Skill: a short markdown file with frontmatter describing when it applies and what to check. Drop it into .claude/skills/ and Claude Code picks it up automatically from then on, without anyone needing to remember to mention it in the next session.
Write the rule down once as a short markdown file with frontmatter describing when it applies and what to check
Drop the file into .claude/skills/ so Claude Code loads it automatically
Claude checks its own work against the rule on every relevant task, not only the one where you first spotted the problem
When it finds a violation, it loops back and fixes it before handing the work to you
This sits alongside the type checkers, linters and tests Claude Code already uses, not instead of them. The verify step just gets one more source of signal, and it's the one source that used to require a human to remember.
Which Rules Are Worth Writing Down First
Not every review comment needs to become a skill. The ones worth the ten minutes it takes to write one down tend to share a pattern.
The correction you've made more than once in code review, on different pull requests, for different reasons on the surface
The mistake that's cheap to catch in a pull request but expensive once it's merged, such as a missing backfill or a skipped cache invalidation
The rule that's specific to your codebase or your data handling obligations, not something a standard linter or type checker would ever flag on its own
Start with the two or three rules your team repeats most often. A skill file that covers one real, recurring mistake is worth more than ten written speculatively for problems that haven't happened yet, and it's easier to trust a small set of skills you know are actually catching something.
What It's Worth to an Australian Dev Team
A skill file doesn't disappear when the engineer who wrote it changes teams or leaves the business. It sits in the repository as a documented, reusable standard, which matters more once a codebase has more than a couple of contributors and nobody can rely on tribal knowledge alone. Teams running Claude Code across a shared codebase typically see it pay for itself inside the first sprint. The correction that used to eat a senior developer's attention on every single review now happens automatically, before the PR lands rather than after, and the standard is visible to anyone who opens the folder rather than living in one person's head.
We build this kind of verification layer for Sydney dev teams as a fixed fee engagement, typically starting from $3,500 AUD for a first working set of skills across a single repository, scaling from there depending on how many rules and codebases are in scope. It's the same category of setup work whether the client is an Australian fintech encoding a Privacy Act data handling check or a product team just tired of reviewing the same migration mistake every fortnight. Either way, the value is the same: the check happens once, automatically, instead of every time a human happens to notice.
If your team is running Claude Code across a shared codebase and wants this set up properly, not just one skill file but a verification layer suited to how your codebase actually breaks, get in touch via our contact page and we'll walk through what a first skill set would look like for your repo.
