Plenty of Australian teams have started building Claude Skills. Far fewer have worked out what a Skill is actually for. The common first attempt looks sensible: paste a few thousand words of style examples into a Skill and expect Claude to hold a consistent voice across every output. What usually happens instead is that the quality of thinking drops. Every Skill you load takes up part of the model's working context, and the more you preload, the less room Claude has to reason about the task in front of it.
Anthropic's own write-up, Lessons from Building Claude Code: How We Use Skills, makes the point plainly. A Skill is not a longer prompt. It is a structured system for deciding what information should be available, when it should appear, and how Claude reaches it. That is context engineering, and it is a far more useful frame than prompt engineering for anyone setting up their first Skills.
Why more context makes Claude worse, not better
A model has a finite attention budget. When you fill a Skill with background, examples, and edge cases that may never apply to the current request, you spend that budget before Claude has read the actual task. Teams notice this as vaguer answers, missed instructions, and a model that seems to forget what it was asked halfway through. The fix is not a better prompt. It is deciding what Claude should see and holding everything else back until it is needed.
Progressive disclosure: SKILL.md is a map, not a manual
Anthropic organises each Skill as a small collection of resources rather than one long document. The SKILL.md file sits at the top as a navigation layer. Claude starts there and only loads more when the task calls for it. The structure usually looks like this:
SKILL.md: a short map of what the Skill does and where to find the rest. It is not a knowledge base.
references/: detailed material such as API parameters, loaded only when Claude needs the specifics.
scripts/: executable code for repetitive, deterministic steps.
examples/: worked examples Claude can pull in when a pattern is unclear.
assets/: templates, files, and other supporting material.
The point of this layout is restraint. Claude reads the map first and reaches for a reference or an example only at the moment it becomes relevant. Progressive disclosure keeps the working context clear so the model can think, rather than wading through everything you might ever want it to know.
Instructions capture judgement, scripts capture execution
A useful split runs through every good Skill. Instructions hold judgement; scripts hold execution. Knowing that a Stripe 200 response does not always mean a payment succeeded is judgement. A function that checks the payment events to confirm the outcome is execution. Write the judgement down as instructions, and move the repeatable, deterministic work into scripts Claude can run.
Instructions: the reasoning a careful colleague would apply, including when a result is misleading or a step has a catch.
Scripts: the deterministic actions that should run the same way every time, such as validating an input or calling an internal endpoint.
Document the gotchas, not the obvious
The most valuable part of a Skill is not information that already exists in public documentation. It is experience. The hard-won lessons your team has collected, the ones that are not in the model's training data, are what make a Skill worth keeping. These are the details that save hours of confused debugging later.
A particular table cannot be sorted by created_at, so a different field has to be used.
A staging environment returning 200 does not guarantee the operation actually completed.
Two identifiers that look different, such as request_id and trace_id, are in fact the same thing.
Write descriptions as routing rules
Skill discovery is often misunderstood. Claude is not searching a catalogue of features. It is deciding when to load a Skill at all. That means the description should read as a routing rule, not a feature list. Write it to answer one question: in what situation should this Skill be pulled in? A description such as 'use when reconciling a customer refund against payment provider records' tells Claude exactly when to reach for it. A list of everything the Skill can do does not.
What this means for Australian teams
For teams in Sydney and beyond, the practical payoff is consistency under load. An Australian financial services firm working under APRA and Privacy Act obligations cannot afford a model that behaves differently every time a compliance check runs. Turning that check into a well-structured Skill, with the judgement written as instructions and the repeatable verification moved into scripts, makes the behaviour predictable and easier to audit. One mid-sized firm we worked with replaced an ad hoc review process with a single Skill and freed roughly $45,000 of analyst time a year, while making the output far easier to trust.
If your team is standing up its first Claude Skills and wants them structured as context engineering from the start, we can help. Book a brainstorm and we will map your first few Skills together.
