How to share Claude skills across a finance team

Bottom line: a Claude skill shares two ways — download it as a markdown file and hand it over, or publish it to your whole organisation on an eligible plan. There is no cross-organisation sharing, so anything you get from outside arrives as a file. The harder problem is not distribution: it is stopping your team space filling up with skills nobody maintains.

Distribution is a five-minute problem. Governance is the one that decides whether shared skills are an asset in six months or a liability.

How do you share a Claude skill?

Two mechanisms, and one gap.

As a file. Any skill can be downloaded as a markdown file and sent to someone. To install one, go to Customize, then Skills, then Add, and either upload the file or paste the instructions directly. That is also how skills published on GitHub or a vendor's site reach you.

Organisation-wide. On eligible plans a skill can be published to everyone in your organisation, which behaves much like sharing a document internally — one version, centrally visible.

The gap: there is currently no way to share a skill directly with someone outside your organisation. Cross-company sharing means exporting the file. Anthropic's agent skills documentation is the reference for how skills are structured and loaded.

The bloat problem, and the two-week rule

Sharing is easy enough that teams over-share, and that is the failure mode. A skill nobody uses is a skill nobody maintains, and an unmaintained skill does not sit there harmlessly — its steps go stale while still looking authoritative. Six months on, someone runs it and gets a confidently wrong answer.

The rule we use internally at Aleph is a deliberate cooling-off period: nothing gets promoted to the team space until an individual has used it themselves for a couple of weeks. If you are as excited about it in two weeks as you were the weekend you built it, it goes in. Most things do not survive that wait, which is the point.

Albert described this on our Claude Skills for Finance webinar, alongside a live walkthrough of building and sharing one.

Use skill analytics to prune

On Claude Enterprise you can pull analytics on skill usage — how many times a given skill has been called over a period. That turns pruning from an argument into a lookup: a skill in the team space with no calls in six weeks is a deletion candidate, and removing it is a maintenance saving rather than a loss.

It is worth treating this as a standing habit rather than a cleanup project. A quarterly pass over usage, deleting what nobody calls, keeps the shared library small enough that people trust what is in it. Some teams pipe that usage data into their reporting stack alongside model cost, so skill adoption and spend sit on the same dashboard.

Vetting a skill you did not write

A skill is instructions an agent will follow against your data, so treat an unfamiliar one the way you would treat an unfamiliar macro.

• Read it before you install it. Skills are plain markdown; there is no excuse for not looking.
• Prefer known sources. A vendor you already work with, or a widely used public repository with visible adoption, over a link from a newsletter.
• Check what it reaches for. A skill that expects broad access to systems it does not need is a flag.
• Ask your security team when unsure. This is a short conversation, and the right one to have before a skill is running against the ledger.

What a shareable skill actually contains

Skills that travel well look similar regardless of which tool they run in: a name, a description of when to use it, the instructions themselves, and ideally the checks. The description does more work than people expect, because it is how the agent decides to reach for the skill without being told to.

Four things separate a skill someone else can actually use from one that only works for its author:

• No implicit context. If it assumes a file path, a workbook name or a connection only you have, it breaks silently for everyone else. State what it expects.
• An explicit trigger. "Use this when asked for monthly ARR movement" beats a bare title, because it tells the agent when to apply it.
• Its own checks. Row counts, period status, a tie-out. The same instinct as a check tab in a model.
• A note on what it deliberately does not do. This is what stops the next person using it for something it was never validated against.

Versioning something your team depends on

Once more than one person relies on a skill, it needs the same treatment as a shared model.

Name one owner. Not a committee — one person who is responsible for the steps still being correct. Unowned shared skills are the ones that rot, because everybody assumes somebody else is checking.

Record what changed and when, in the skill itself. A short change note at the bottom costs nothing and answers the question that always comes up: has this been updated since the chart of accounts changed?

Re-validate on a trigger, not a timetable. The events that invalidate a finance skill are specific: a chart-of-accounts change, a new entity, a reporting-line restructure, a change of CFO with different preferences. Tie the review to those rather than to a quarterly reminder nobody honours.

Using skills to onboard

The most underrated use of a shared skill library is onboarding, and it reframes what the library is for. A new analyst's first month is largely spent learning undocumented conventions: which date field the team reports on, which accounts roll into which reporting line, how much detail the CFO wants in commentary, what gets flagged and what gets absorbed.

Those conventions are exactly what a well-written skill encodes. A team with ten good skills has written down a meaningful part of its own operating manual as a side effect — and unlike a wiki page, it gets used, so it stays true.

That is also the argument for keeping the library small and curated rather than exhaustive. Ten skills people trust teach a new joiner more than fifty nobody has validated. For the broader picture of where agent workflows fit a finance team, see AI agents in finance and FP&A.

Why a folder of markdown files stops working

Keeping shared instructions in a folder of markdown files is a genuinely good way to get started, and it fails in a familiar way. Someone downloads a file, improves it, and does not upload it back. Now there are two versions, then five, and you are looking at ARR-pull-v1 through ARR-pull-v15 with no way to tell which one is right.

It is the shared-spreadsheet problem wearing different clothes, and it arrives at the same size of team. The fix is the same too: one governed version that everyone reads from, rather than copies that drift. See automating FP&A workflows for where that boundary usually sits.

Start from skills that already work

If you would rather not start from a blank file, the Claude skills for finance guide includes six ready-made .skill files you can install and edit — a reasonable way to see how a well-structured skill is written before you author your own. The webinar recording walks through building one from scratch and connecting it to live finance data.

For skills that run against your own actuals with per-user permissions, see the Aleph agent.