Every Monday morning, a risk analyst at a Melbourne financial services firm opens Claude and pastes in the same 1,800-word context block. Their firm's vendor classification framework. APRA CPS 234 requirements. The internal risk thresholds that took a decade of regulatory engagement to develop. The output template compliance requires.
Eight weeks in, the output is good. But the analyst is essentially re-briefing Claude from scratch at the start of every session, and work that should feel like an integrated system feels like a sophisticated copy-paste operation. The tool is capable. The workflow is not.
What a Skill actually does
A Skill is a packaged bundle of instructions, tools, and context that Claude loads when the work calls for it. Anthropic ships first-party Skills for common tasks like API integration and code review. The more interesting move for Australian teams is building custom Skills for domain-specific work: the exact compliance procedure your team follows, the internal taxonomy your operations team uses to classify incidents, the way your agency structures a client brief before work begins.
The pattern: document the procedure once, in a form Claude can follow. Stop re-explaining it every session. Claude loads the Skill when relevant and works from the embedded knowledge, rather than from whatever context the user manages to paste in before the conversation gets going. The output becomes consistent across team members, not just for the person who remembers all the relevant context.
Why Australian teams have more to gain than most
The institutional knowledge argument is obvious but understated. Your team's procedure for handling an AUSTRAC suspicious matter report, or the way your firm structures an APRA notification, exists nowhere else. It is not in Claude's training data. It is not in any open-source repository. It lives in the heads of your most senior people, in Notion pages that nobody reads, and in the email chain someone forwards to new starters as a quick reference.
The firms that encode that knowledge into Skills are not deploying generic Claude. They are deploying Claude-shaped-to-their-institution. That produces visibly better outputs. Over time, it creates an implementation that is harder to replicate than any prompt engineering an outsider could attempt in an afternoon.
There is also a direct cost argument. An analyst spending three minutes reconstructing context at the start of eight sessions per day loses 2 hours per week to setup friction. Across 10 analysts at $100/hr fully loaded, that is roughly $104,000 in annual opportunity cost. A well-built Skill eliminates most of that overhead.
How to build your first Skill in three steps
The core artifact is a markdown file. No engineering team required, no deployment pipeline, no infrastructure to maintain. Here is the process that consistently gets teams their first Skill into production inside a fortnight.
1. Pick a task that runs at least weekly
'Generate a CPS 234 compliance summary for a new vendor' is a strong first Skill candidate. It runs frequently in Australian financial services, has a defined output structure, requires deep regulatory knowledge, and currently depends on someone remembering to include the right context before starting. That last point matters. If the task produces noticeably worse output when the subject-matter expert is on leave, that is a Skill candidate. High frequency and defined output justify the documentation investment.
2. Write the procedure, not the description
Document how your best subject-matter expert does the task. Not what the task is. How they actually do it. What inputs they pull first. Which regulatory sources they check. What edge cases they flag before the draft goes to review, and why. The Skill encodes that tacit procedure so Claude follows it consistently, not by coincidence. A thorough SKILL.md for a CPS 234 assessment typically runs 800 to 1,200 words.
3. Add tools and two worked examples
Wire in any tools the Skill needs: MCP server access to your vendor database, the internal API that returns current policy versions, whatever data source your expert checks manually today. Then include two worked examples of good output alongside the instructions. Claude calibrates to your quality standard much faster with examples than with instructions alone. The difference between a Skill with examples and one without shows up in the first output it generates.
When Skills are the wrong move
Not every process should become a Skill. The most common mistake is building Skills for work that does not actually have a repeatable procedure underneath it. A few situations where the documentation investment is not worth it:
The task runs less than monthly. Documentation and maintenance cost exceeds time savings. The ROI is not there.
The process changes every quarter. A Skill with stale instructions generates confidently wrong output. Fast-changing procedures need a different approach.
Experts on your team disagree on the right approach. A Skill locks in one procedure. Surface that disagreement first before encoding either version.
The work is genuinely exploratory. Skills work best for defined, repeatable procedures. If the task is figuring out what to do about a novel situation, a Skill is not the right container.
The honest version of this test: if you would not document the process for a new hire, do not build a Skill for it. Skills are formal procedures. They work best when someone has already done the hard work of making the process legible.
Where Australian teams typically start
Australian financial services. Draft an APRA notification. Summarise CPS 230 operational risk implications of a vendor change.
Australian government. Format a ministerial brief to departmental standards. Cross-reference policy against current legislation.
Australian healthcare. Apply privacy redaction per the Australian Privacy Principles before a document goes external.
Professional services firms. Generate a client status update in the firm's standard format from a call summary.
The pattern across these sectors is consistent. The best first Skills are the ones where the gap between a senior practitioner and a junior one is most visible on the same task. That gap is process knowledge. It is tacit, it is specific to your institution, and it is exactly what a Skill is designed to encode.
Pick one process your team runs at least weekly that currently depends on someone remembering to include the right context. Document how your best person does it. Build the Skill. The businesses that pull ahead over the next few years will not be the ones that adopted Claude first. They will be the ones that stopped treating every conversation as a blank slate.