The Anatomy of a .skill File

"That's a developer thing, right?"

That is the response I get from most accountants when this comes up. And I understand it. It has a file extension. It lives in a folder. Somebody said "repo" once and the room went quiet.

So here is the entire minimum viable version of one:

---
name: month-end-close
description: Runs the monthly close for a client. Categorization review,
  reconciliation, recurring entries, and variance flagging over 10%. Use
  when asked to close a month, run month-end, or prepare the monthly package.
---

# Month-End Close

1. Pull the bank and credit card transactions for the period.
2. Review anything uncategorized against the client's chart of accounts.
3. Never invent an account. If nothing fits, flag it.
...

That is a working skill. One text file. Some labels at the top, and the procedure written the way you would write it for a competent new hire who has never seen your process.

I have 187 of these files on my computer right now. Eighty-four of them, 45%, are exactly that. One file, nothing else in the folder. The median one is 136 lines long. You have written longer emails.

There are two arguments for not bothering to learn this. One of them is bad. The other one is good, and still wrong.

The bad argument: it's code, so it's not my job

It is not code. It is a procedure written in plain English, in a text file, with a label on top saying when to use it.

The format was published as an open standard in December 2025 precisely because it is trivial. That is the whole design thesis. Within twelve weeks there were compatible implementations in forty-odd other products, which does not happen to complicated things. It happened to this one because there is almost nothing to implement.

And the person doing the best work teaching this to accountants is not an engineer. Lovely McInerney is ex-Big-4 audit. Her account of building her first one is an accountant's account: she wrote instructions that were too vague, got inconsistent output, and fixed it by being more specific. Her words, and they are the best sentence anyone has written about this format:

"The fix wasn't more AI capability. It was more specificity from me."

That is not a programming problem. That is the thing you are already good at.

The good argument: Cowork already does this

This one deserves a real answer, because it is correct as far as it goes.

Cowork builds skills for you. You point it at a folder, describe what you want, and it writes the files. For a lot of workflows you can skip everything in this guide and go straight there. The people teaching that route are teaching the right thing, and they are teaching it well. Getting a firm from zero to actually using this stuff is the hard part and it is most of the value. If you have not done that yet, go do that first.

McInerney raises this objection against her own article, which is the honest way to do it, and her answer is the one I would give:

"Cowork builds skills under the hood. When you tell Cowork to automate a workflow, it's creating the same SKILL.md files, the same folder structures, the same reference documents I described above. Understanding how skills work means you can inspect what Cowork creates, refine it, and fix it when something goes wrong. You're not dependent on magic you don't understand."

And the second half, which matters more:

"Cowork can scaffold a depreciation skill in minutes. But it doesn't know your organization uses straight-line only. It doesn't know you prorate partial periods by days in service. It doesn't know which GL accounts map to which asset categories. The specificity that makes a skill reliable? That comes from you."

The tool writes the container. You are still the only one who can put your firm inside it.

So here is the honest filter for whether to keep reading. If you are content to never look inside the thing that produces your client's numbers, close this tab. That is a real position and some people hold it.

But you are an accountant. You have never once in your career accepted a number because it was printed nicely. You tie things out. You look at the support. The idea that you would run a procedure on client books for six months without ever opening it up is not a thing that is going to happen, and when you do open it up, this is what you will be looking at.

What is actually at stake

Three numbers.

98% and 21%. In Karbon's State of AI in Accounting 2026 survey, roughly 600 firms across six continents, 98% report using AI. Twenty-one percent have a policy or strategy for it. That gap is not a technology problem. It is a documentation problem, and this format is the only place in the stack where a firm's policy can actually live in a form the AI obeys.

40%. When you look at what accountants are actually doing with AI in the wild rather than what they say in surveys, roughly 60% is using it to do a job. The other 40% is building something: a tool, a template, a repeatable process. That 40% is already authoring. Most of them just do not know the format has a name.

Zero. I went through about sixty items of accountant-facing skill content and code, everything I could find that puts this format in front of our profession. Not one published accounting skill is written for a firm with more than one client. Every single one assumes one entity, one folder, one filer. And essentially none of them query a ledger. They read exports, with a pile of brittle parsing code in between.

The version of this built for how your practice actually works does not exist yet. You are the one who knows what belongs in it.

What I am going to give you

I build these. Three of them are shipped, running against real client books right now, and everything structural in this guide comes out of those or out of reading everyone else's. I read 187 skill files to write this, including all eight of Anthropic's own finance skills, line by line.

First, how to think about a skill. There is exactly one concept in this format that matters, and it is not the folder diagram everyone leads with. Get this part and the rest follows.

Next, the build program. Author it, partition it, verify it, ship it. Every template inline, nothing held back, plus a working skill whose only job is to check your other skills before you hand them to anyone.

Finally, the playbooks. Thirteen skills a firm should actually build, each with a starter spec, grouped by whether you need them on day one or when you get serious. The last one gets built end to end, in front of you, and then you can download it.

All of those are free and unlocked. There is no email box anywhere in this guide. If you build something from it, I would like to see it, and that is the only thing I am going to ask you for.

So what is a skill, actually?

Three different things get called "a skill" and they are worth separating before we go further, because the confusion between them is where most of the bad writing about this format comes from.

The concept. A procedure you have handed to the AI, that it reaches for on its own when the work matches. This is the sense people mean in conversation.

The directory. The actual artifact. A folder whose only required member is a file named SKILL.md. Capital letters, exactly like that, because it is case-sensitive and skill.md will not be found. The folder's name has to match the name written inside the file.

The .skill archive. That directory, zipped, with the extension changed. It exists so you can upload one to claude.ai. It is a distribution wrapper and nothing more.

That last one is worth a second, because it is the thing in the title of this guide and it is the least important of the three. It is not in the published specification at all. The spec describes a directory. The zip container is tooling that grew up around it. When you read someone's "anatomy of a .skill file," they are almost always describing the directory.

The one-line version: a skill is a folder with a procedure written in markdown, and everything else is optional packaging around that.

The diagram everyone leads with, and why it is the wrong frame

Open any write-up on this format and you will get this within the first screen:

skill-name/
├── SKILL.md          # the instructions
├── scripts/          # code
├── references/       # documents
└── assets/           # files

It is accurate. Those are the conventional folder names. It is also close to useless, and if it is the mental model you carry away from this guide you will build the wrong thing.

Two problems with it.

First, those names are convention, not rules. The specification recommends them. It does not require them. You can put anything in a skill folder and call it anything. Nearly half of all skills have none of these subfolders at all.

Second, and this is the real issue, it sorts by what kind of thing is in the folder. Code here, documents there, files over there. That is how you would organize a filing cabinet, and it tells you nothing about the only question that actually determines whether your skill works: when does each piece get loaded, and what does it cost when it does?

Those three folders do differ from each other in a way that matters enormously. But the difference is not "code versus documents." We will get to what it actually is shortly, and it will reorganize how you think about the whole format.

The specification itself is refreshingly short about all of this. A directory, one required file, two required labels, three suggested folder names. It is silent on the archive, silent on versioning, silent on signing, silent on registries. That silence is deliberate and we will come back to what it costs you in Part 3.

How to think about a skill

Here is the one concept. Everything else in this guide is downstream of it.

A skill does not load all at once. It loads in three stages, and each stage costs you something different.

The Loading Contract

That table is the format. If you understand those three rows you can stop reading this section, though I would rather you did not, because the consequences are not obvious.

Level 1: Metadata, the part that pays rent

Every skill you have installed puts its name and description into the AI's context at the start of every single session. Not the instructions. Not the reference files. Just those two labels, about a hundred tokens.

This is the only part of your skill that is always loaded, and it is the only part that costs you something whether or not the skill is ever used. Across those 187 files, the median description runs 378 characters. Install a hundred skills and you are carrying a standing tax before anyone has said anything.

Put real numbers on it. Say your firm builds out properly: a policy skill, a close runner, a cleanup diagnostic, a client question answerer, a 1099 prep, plus a handful of client-specific ones. Call it twenty. At the median description length that is roughly 2,000 tokens loaded into every session, forever, whether you use any of them or not.

That is not a large number and I am not telling you to be precious about it. I am telling you because it inverts the instinct people arrive with. The instinct is that a long skill is expensive. It is not. A long skill is free until it fires. A sloppy description is expensive every single day. Almost everyone optimizes the wrong one.

It is also, and this is the part people miss, the only information available when the AI decides whether to use your skill at all. More on that in Part 1 of the build program, because it is where most skills fail.

Level 2: Instructions, loaded whole or not at all

When your request matches a description, the AI reads that skill's body. The entire thing, at once, into context.

There is no partial load here, which is why the size guidance exists. Keep it under 500 lines. Most people do without trying: median 136 lines, and only 10% of the files I looked at exceed 500.

Level 3: Resources, free until you touch them

Everything bundled in the folder costs nothing until something actually reads or runs it.

Not "a little." Nothing. A 400-line Python script sitting in scripts/ is invisible to the context window until the moment it executes. Anthropic's own phrasing for how much you can bundle into a skill is "effectively unbounded."

This is the row that changes how you build, and it leads directly to the reframe.

Using the Loading Contract: Runs, Reads, Uses

Now back to those three folders. They are not sorted by content type. They are sorted by what the agent does with them, and therefore by what they cost.

Runs: scripts/

The agent executes these. It never reads the source.

Only the output enters context. The code itself is free, permanently, no matter how long it is. This is the single most underused fact about the format. Pre-writing a script is not just more reliable than having the model work out the same logic every time, it is also cheaper, because the logic costs nothing and only the answer costs anything.

Reads: references/

The agent reads these into context, whole, the same way it reads the body.

So these are not free when used. A 12KB methodology document costs 12KB of methodology document. But it costs it only on the tasks that need it, which is the entire point, and which is why a skill can carry a methodology far larger than any single conversation could hold.

Uses: assets/

The agent copies these into its output, or compares against them. Templates, sample documents, logos, fonts.

They never enter context at all. Not when used, not ever. This is how you show a skill what good looks like without paying for the demonstration.

The decision rule, for when you are staring at a piece of your procedure and cannot tell where it belongs:

That last row is a real diagnostic and it works in reverse too. If you notice a reference file being pulled in on every single run, it is in the wrong place. Move it into the body. If you notice one never being pulled in at all, either it is badly signposted or you did not need it.

Always on: the frontmatter

And back to where we started. Your name and description are the only part of the whole construction that is loaded on every session regardless. Everything else is conditional. That asymmetry is why the next section of this guide spends more time on the two labels at the top of the file than on anything else.

The consequence: partition, do not compress

Put the three levels together and you get the working principle for the rest of this guide.

Because unread files cost nothing, there is effectively no ceiling on what a skill can contain. You could ship your entire methodology, every policy memo, ten years of worked examples. The constraint was never total size.

The constraint is what any single task drags into context.

Which means the design question is never "how do I make this shorter." It is "what does this particular task actually need to pull in." Those are different questions and they have different answers. The first one leads you to delete things you need. The second one leads you to put them somewhere the AI only goes when it has a reason to.

Everything in Part 2 of the build program is that idea, applied.

The Build Program

Everything up to here was how to think about the format. The rest of this guide is how to build one.

Three parts, in order, and the order matters because each one assumes the last.

Part 1: Author. Pick the right procedure, write the two lines that decide whether anyone ever uses it, and write the body. At the end of this part you have a working skill. Most people stop here and that is a completely defensible place to stop.

Part 2: Partition and Verify. Split the knowledge so a single task only pulls in what it needs, decide which work the model should not be doing at all, and build the thing that checks the output before a human sees it. This part is what separates a skill you would run on a client file from one you would not.

Part 3: Ship. Where skills live, what does not sync, what to know before client data goes anywhere near one, and how to read a skill somebody sends you.

On effort, honestly: the first one takes an afternoon, and most of that afternoon is not typing. It is you working out what your procedure actually is, which turns out to be harder than writing it down. The second one takes about an hour. By the fourth you are doing it in twenty minutes and wondering why you waited.

If you would rather see what to build before learning how, skip to the playbooks. You will build the wrong thing first, and you will build it in a format that mostly works anyway, and you will come back here when you want to know why the output keeps drifting. That is a reasonable trade and I am not going to pretend otherwise.

Otherwise, start here.

Part 1: Author

Every accounting firm already has a skills library.

It is called the procedures binder. Or the shared drive folder called SOPs that somebody built in 2019 and three people have opened since. Or, most often, it is the senior who knows how the Henderson file works, and the fact that nobody wants them to take vacation in March.

The knowledge exists. It is just stored in a format that requires a human to execute it, which means it does not scale past the number of humans who have read it, and it degrades every time one of them leaves.

What is new is not that you can write procedures down. You have always been able to write procedures down. What is new is that writing one down now produces something that runs.

So let us write one.

Step A: Pick the procedure

The instinct is to pick the hardest thing you do. Resist it. The hardest thing you do is hard because it requires judgment, and judgment is the part you are keeping.

The test is two words, and both have to be true.

Recurring. You do it at least monthly. Ideally you do it for every client, every period, and you are slightly tired of it.

Identical. You do it the same way every time. Not "roughly the same." The same. If two people at your firm would produce meaningfully different output from the same inputs, you do not have a procedure yet, you have a habit, and you need to settle the disagreement before you encode it.

That second one is the filter that matters, and it does something useful even before you write any code. Sitting down to encode a procedure forces you to discover that your firm does not actually have one. This is the most common thing that happens to people on their first attempt, and it is not a failure. It is the audit finding.

Good first candidates look boring. A monthly close package. A cleanup diagnostic for a new client. A 1099 prep run. The thing you explain to every new hire in their first week and then re-explain in their third.

Bad first candidates: anything where the answer depends on a conversation with the client, anything you do twice a year, anything you have strong feelings about. Save those. You will be much better at this in a month.

Picked one? Good. Now the part that decides whether anyone ever uses it.

Step B: Write the description

This is the most important section in this guide.

Recall the Loading Contract. Your name and description are the only part of the skill that is always in context. They are also, and this is the consequence people miss, the only information available when the AI decides whether to use your skill at all.

Not the body. The body has not been read yet. Not the reference files. Certainly not the scripts. Roughly a hundred tokens of description, weighed against every other skill installed, and either yours gets picked or it does not.

You can write a magnificent procedure and have it never once fire. That is the most common failure mode in this format, and it is entirely upstream of the quality of the work.

So. The two labels at the top of the file:

---
name: month-end-close
description: Runs the monthly close for a client. Categorization review,
  reconciliation against bank and credit card statements, recurring journal
  entries, and variance flagging over 10% month over month. Use when asked
  to close a month, run month-end, prepare the monthly package, or when a
  client's books need their period-end review.
---

Both halves, always

A description has two jobs and most bad ones only do the first.

Half one: what it produces. Specifically. Not "helps with month-end." The actual outputs, named. Somebody reading only this sentence should know what lands on their desk.

Half two: when to use it. This is the half people skip, and it is the half that makes the thing fire. Write the phrases a person would actually say out loud. Not the formal name of the procedure. The way somebody asks for it at 4pm on a Tuesday.

Anthropic's financial-statements skill is the best specimen I have found of half two done properly:

"Use when preparing a monthly or quarterly P&L, closing the books and need to flag material variances, comparing actuals to budget, building a financial summary for leadership review, or looking up GAAP presentation requirements and period-end adjustments."

Five distinct entry points, all in natural language, none of them requiring the person to know what the skill is called. That is the model.

Third person. Always.

This one looks like a style nit and is not.

The description gets injected into the system prompt. It is read as a statement about a capability that exists, not as a message from you to the reader. So:

• ❌ "I can help you close the month."
• ❌ "You can use this to run a monthly close."
• ✅ "Runs the monthly close for a client."

Both of the wrong versions cause the AI to misidentify what it is looking at. The first sounds like an assistant introducing itself. The second sounds like documentation aimed at a human. Neither reads as "here is a tool that does X," which is the only reading you want.

Name it with a gerund, and avoid the mush words

Naming convention: prefer the -ing form. processing-pdfs, analyzing-spreadsheets, reconciling-bank-statements. It reads as an activity, which is what a skill is.

Two words are forbidden outright in a skill name on Anthropic's hosted surfaces: anthropic and claude. A skill called claude-close-runner works perfectly on your computer and is refused the moment you try to upload it. Neither may name or description contain an XML tag, which is the narrower cousin of the no-angle-brackets rule below.

Then the words to avoid by judgment rather than by rule: helper, utils, tools, documents, data. They are the naming equivalent of an account called Miscellaneous. They tell the AI nothing about when to reach for the thing, and if you find yourself wanting one, it is usually a sign the skill is trying to do more than one job.

Which is the next rule.

No angle brackets. Anywhere in the frontmatter.

Not in the description, not in any other field.

The reason is not cosmetic. Frontmatter goes into the system prompt, and angle brackets can be read as structural markup rather than as text, which means content inside them can be interpreted as instruction rather than description. The spec warns about it explicitly and the validator will hard-fail a description that contains them.

This one is worth flagging because five of Anthropic's own eight finance skills break it. They use an argument-hint field with values like "<account> [period]". Those skills work fine in the environment they were written for. They would not survive a strict validation, which is a good early illustration of a theme you will meet properly in Part 2: what the tooling accepts and what the specification says have quietly drifted apart.

Length is not your constraint. Attention is.

The cap is 1,024 characters. Across all 187 skill files I looked at, not one exceeds it. The longest is 863. The median is 378.

So stop optimizing for length. Nobody is near the ceiling. What you are actually competing for is a decision made against every other description installed, which means the win condition is distinctiveness, not brevity. A 400-character description that names five real trigger phrases beats a 120-character one that is merely accurate.

The mistake almost everybody makes

Somewhere in the body of the file, people write a heading like this:

## When To Use This Skill

Use this skill when you need to close a client's month...

That text is dead weight. Read the Loading Contract again if it is not obvious why. The body does not load until after the skill has already been selected. By the time anything can read your "when to use" section, the decision it was written to inform has already been made, correctly or otherwise, on the strength of the description alone.

Every piece of triggering information has to live in the description or it may as well not exist. If you find that section in your file, do not delete the content. Move it up.

The advanced move: negative triggers

Almost nobody teaches this one, and it becomes essential the moment your firm has more than two or three skills. (Anthropic's xlsx skill demonstrates it about as forcefully as it can be done, with five named exclusions. We tear that one down in Playbook Zero.)

When two of your skills are adjacent, the description has to disambiguate, not just describe. It needs to say what it is not for.

Here is a real one, from a close-binder skill that lives alongside two sibling deliverables:

"…Use when asked to run or build the month-end close workbook, close binder, monthly close workpapers, or 'tie out the balance sheet' for a client. Not for forward cash projections (cairn-money-map) or narrative financial-review reports (foreyes-financial-review)."

That last sentence is doing real work. Without it, "build me the monthly package for Henderson" is ambiguous across three skills and you get whichever one happened to match marginally better.

And here is what happens when nobody writes it. Anthropic ships two skills in the same plugin:

• journal-entry-prep: "Use when booking accruals, prepaid amortization, fixed asset depreciation, payroll entries, revenue recognition, or any manual journal entry."
• journal-entry: "Use when booking month-end accruals (AP, payroll, prepaid), recording depreciation or amortization, posting revenue recognition or deferred revenue adjustments…"

Same job. Overlapping triggers. Neither says which to prefer, and "book an accrual" matches both. This is not a criticism of skills that are otherwise well written, it is the clearest available demonstration that the problem is real and that first-party code is not immune to it.

Rule of thumb: the moment you write your second skill in a domain, go back and add a negative clause to the first one.

Step C: Write the body

The description got you selected. The body is what actually happens next.

Good news: this part is much more forgiving, and you already know how to do it.

Write it for a competent new hire

That is the register. Somebody who knows accounting, does not know your firm, and is not stupid. You do not explain what a reconciliation is. You do explain that this client's merchant deposits land net of fees and have to be grossed up.

Anthropic's own framing for this is "the context window is a public good," and the working default is that the model is already smart, so you only add what it does not have. Do not write a paragraph explaining double-entry. Write the paragraph explaining that you book revenue on accrual for the SaaS clients and cash for the trades.

Length: keep it under 500 lines. As we saw, the median in the wild is 136 and only a tenth of files exceed 500, so this is a ceiling you will have to work at to hit.

Front-load the non-negotiables

This rule is McInerney's, it is not in the official documentation anywhere, and it matches what I have seen:

"Claude pays more attention to content near the top of your SKILL.md. Put non-negotiable rules, like 'always ask for the report period end date before running any script,' in the first few paragraphs, not buried at the bottom."

So the shape of a good body is: the handful of rules that must never be broken, then the procedure in order, then the edge cases. Not chronological throughout. Rules first.

Match the specificity to the fragility

This is the most useful single idea in Anthropic's authoring guidance, and it has a good analogy attached: a narrow bridge with cliffs on both sides needs guardrails. An open field just needs a direction.

The mistake in both directions is real. Over-specify a judgment call and you get a worse answer than the model would have produced on its own. Under-specify a fragile sequence and you get a different answer every month.

For most accounting procedures the answer is: high freedom on the narrative and the analysis, low freedom on anything touching a number or a file format. Which is a preview of Part 2.

Three workflow patterns worth stealing

These come out of Anthropic's guidance and all three translate cleanly to accounting work.

Checklists. For anything multi-step, give the AI a checklist it copies into its response and ticks off as it goes. This sounds trivial and is not: it makes the work visible and interruptible, and it makes a half-finished run obvious instead of silent. It works for prose tasks as well as scripted ones.

Validation loops. Run a validator, fix what it reports, run it again, and only proceed when it passes. The validator does not have to be a script. It can be a style guide the AI reads and compares its own output against.

Plan, validate, execute. For anything batch or destructive, have the AI write a structured plan file first, validate that file, and only then execute. You get a machine-checkable intermediate state and you catch errors before anything lands. If you have ever wanted a preparer's workpaper before the entries post, this is that.

The Four Skill Shapes

You now have a working skill. Before Part 2, it is worth knowing what it can grow into, because the four shapes are a real progression and knowing which one you are aiming at saves you from building infrastructure you do not need.

Bare

SKILL.md and nothing else. Forty-five percent of everything in the wild.

Right for anything a very good memo could accomplish. Your firm's categorization policy. The rules for how you handle a particular client. A procedure with no computation in it. Do not be embarrassed by this shape; it is the most common one for a reason, and a well-written bare skill beats a badly-partitioned complicated one every time.

Guided

Add references/. The body becomes a short procedure plus a routing table pointing at the heavy material.

Right when your methodology outgrows the body, which happens around the point where a single reference document would be longer than the procedure that calls it. Part 2 is mostly about this transition.

Tooled

Add scripts/. Now some of the work is code.

Right the moment a number has to be identical on every run, or a file has to come out in exactly the same shape. This is the step where a skill stops being a very good memo and starts being a deliverable.

Full

All three folders, plus verification, plus samples in assets/ showing what good output looks like.

Right for anything that goes to a client under your firm's name.

For calibration, here are three real deliverables of mine, all built independently against different client work, ordered by how far they went:

Three things fell out of that comparison that I did not plan and only noticed when I lined them up.

Every one has a references/methodology.md and at least one verification script. Nobody mandated that. It is what the work converges on.

Two of the three split format.md out of methodology.md. What to compute got separated from how it should look, in different files, on different projects, without anyone deciding it centrally. That split turns out to be the same distinction Part 2 is built around.

Verification grew faster than generation. In the largest one, the two verification scripts together are 36 KB against a 62 KB generator. In the smallest and earliest, verification was 2 KB against 12 KB. As these things mature, proportionally more of them becomes checking rather than producing.

That is not a coincidence and it is the whole subject of Part 2.

Part 2: Partition and Verify

You have watched a junior hand you a workbook that was beautifully formatted and wrong.

Nobody in this profession trusts a number because it is printed nicely. We tie out. We look at support. We have an entire vocabulary for the difference between something that looks finished and something that is finished, and a professional apparatus built on the assumption that those two things come apart routinely.

That instinct is the most valuable thing you bring to this format, and it is almost entirely absent from the literature about it.

Part 1 got you a skill that works. Part 2 is the difference between a skill that works and a skill you would let near a client file.

Compute, Compose, Render

Here is the framework. One decision, applied to every step of your procedure.

Because the model can do almost anything, there is a strong pull toward letting it do everything. Resist that. Every piece of work belongs in exactly one of three buckets, and you should be able to say which without hesitating.

Compute: it has to be exact

Numbers. Balances. Dates. Totals. Anything with a right answer.

These come from a query or a script. Not from reading, not from estimating, not from remembering something seen earlier in the conversation. The test is simple: if a figure could come out differently on two runs against the same data, it is in the wrong bucket.

This is the bucket people get wrong most often, and they get it wrong in a specific way. They let the model read a number out of a document and carry it forward. It usually works. The failure mode is not that it is wrong often, it is that it is wrong rarely and silently, which is worse.

Compose: it genuinely needs judgment

The narrative. The explanation of why a variance happened. Which three actions matter most for this client this quarter. The sentence that says the liquidity position is deteriorating rather than that the current ratio moved.

This is what you actually want a model doing, and it is the only bucket where variation between runs is fine, because it is a different client in a different month and the answer should be different.

If you find yourself writing rigid rules here, stop. You are over-specifying a judgment call and you will get worse output than the model would have produced on its own.

Render: it has to look the same every time

Formatting. Document structure. Tab order. Which cells are bold. The header block.

Script it. A model that formats freehand produces something slightly different every month, and your client will notice the drift before you do. What they will conclude is that somebody new is doing their work.

Running the exercise

Do this on paper before you write anything.

List every step of your procedure. Write C, Co, or R next to each. Two things will happen.

First, you will find steps you cannot classify. That is the useful part: a step you cannot classify is almost always two steps glued together. "Pull the receivables and explain what is going on with them" is a Compute and a Compose wearing one label. Split it and both halves get easier.

Second, you will find Compute steps you had been letting the model do. That is the moment the framework pays for itself.

For calibration, a report skill of mine splits like this: figures pulled deterministically from the ledger by query, narrative written fresh per client, formatting handled by a Python file. Three buckets, three mechanisms, and that split is most of the reason the output can carry a firm's name.

Partition, do not compress

Back to the Loading Contract, because now it becomes an instruction.

Bundled files cost nothing until read. So the question is never "how do I make this shorter." It is "what does this particular task need to pull in."

When the body gets crowded, do not delete. Move, and leave a signpost:

## Where to look

| If you need                       | Read                      |
| --------------------------------- | ------------------------- |
| The categorization policy itself  | references/policy.md      |
| How to handle a prior-period item | references/adjustments.md |
| What the deliverable looks like   | references/format.md      |
| Client-specific quirks            | references/clients.md     |

The body stays short and always loads. The heavy material loads only on the tasks that reach for it.

There is a second benefit with nothing to do with context windows. Whoever owns your categorization policy now edits one file. Nobody edits a shared forty-page document, nobody steps on anybody, and when something changes, what changed is easy to see. If you have ever tried to get four people to maintain one SOP, you already know why that matters more than the token argument.

Four rules on references, all of which the checker at the end of this part enforces.

One level deep. SKILL.md points at a reference. That reference does not point at another one. When references chain, the agent starts previewing files with head -100 instead of reading them whole, and you get partial information with no signal that anything was missed. Silent failure, which is what earns it a rule.

A table of contents on anything over 100 lines. Same reason. If a long file does get partially read, the top of it should still reveal the full scope.

Never duplicate. A fact lives in the body or in a reference, never both. Two copies drift and the model cannot know which is current.

No clutter. No README.md, no changelog, no installation guide. A skill contains what the agent needs to do the job. It is not a repository and it does not need to explain itself to a human browsing GitHub.

Scripts: solve, do not defer

Two rules and one law.

Solve, do not defer. Handle the missing file and the permission error inside the script. Do not let it fail and hope the model improvises something sensible, because improvisation is precisely what you are removing. A script that dies with a clear message beats one that dies vaguely and gets worked around.

Say which mode you mean. "Run verify.py to check the output" and "See verify.py for the checking logic" are different instructions and produce different behavior. The agent does exactly what you wrote.

And no voodoo constants. If your script contains TIMEOUT = 30, or a materiality threshold of 5000, or a fuzzy-match cutoff of 0.8, document why. Ousterhout's formulation is aimed squarely at this format:

If you don't know the right value, how will Claude determine it?

Accountants should find this one easy. It is the same instinct as a workpaper that shows its basis. An unexplained threshold in a script is an unsupported number in a binder.

The Check

Now the part almost nobody builds, and the reason I think this profession has an unfair advantage at this format.

I went into this expecting quality to track popularity. It does not. Quality tracks tests. The best-built accounting skill I found has a single star on GitHub and ships fifty-nine tests against an answer key somebody computed by hand. One of the most-starred ships forty-four skills in five commits.

Stars measure whether people liked the idea. Tests measure whether the author tried to break their own work. Only one of those predicts whether the thing survives a real client file.

So if you build one thing nobody else is building, build the check: a script whose only job is to verify the output before a human sees it.

McInerney's version is the clearest case I know of an accountant arriving at this independently. Her skills produce spreadsheets where every cell that should be a formula is a formula, because, in her words, "Auditors don't want hardcoded numbers, they want to see the calculation." And then:

"I also built a validation step. After generating any XLSX, Claude runs a recalculation script using LibreOffice headless mode to verify all formulas resolve without errors (#REF!, #DIV/0!). No file gets delivered until it passes."

That is a preparer and a reviewer in one folder. Nobody taught her that, because it is how this profession already works.

Yours might tie totals back to the trial balance, confirm every required field is populated, check that no account appears that is not on the client's chart, or verify that three variants of a report carry identical numbers. The specific check matters less than the fact that one exists and that it can actually fail.

And know what your check does not prove. Anthropic's xlsx skill is unusually honest about this and the sentence is worth carrying: "A green recalc proves your formulas evaluate, not that they are right. An off-by-one range or a reference to the wrong row yields a clean, error-free file with wrong numbers."

A passing check means the machinery ran. Your reconciliation can tie against the wrong account. Your report can foot perfectly and cover the wrong period. So verify the logic by hand at small scale before trusting the AI at large scale, which is what you already do with an unfamiliar workbook. The check catches mechanical failure, not misunderstanding.

Build the evaluation before you write the skill

Anthropic's prescribed loop, which inverts what most people do:

1. Run the model on a representative task without your skill.
2. Write down the specific ways it fell short. Not "it was bad." The actual failures.
3. Build three scenarios testing those gaps.
4. Baseline them.
5. Write the minimum content that makes them pass.
6. Iterate.

The reason for the order is stated well in the source: it ensures "you're solving actual problems rather than anticipating requirements that may never materialize." Most people write a skill full of instructions guarding against things the model was never going to get wrong, which costs context on every run and buys nothing.

The Claude A / Claude B loop is the cheap version. Author the skill in one session. Test it in a fresh one that has the skill loaded and none of your context. Bring the failures back. The fresh instance does not know what you meant, which is the whole point, and it is the closest thing available to handing your SOP to a new hire and watching where they stumble.

Watch how it navigates

Three diagnostics, genuinely useful once your skill has bundled files:

• A file read in an order you did not expect means your structure is not as intuitive as you think.
• A file never read at all is either unnecessary or badly signposted. Find out which before deleting it.
• A file read on every single run belongs in SKILL.md. You partitioned it out and should not have.

That last one is the diagnostic for the partitioning question above.

The frontmatter reality

One more thing before shipping, and it is the messiest part of the format.

Three schemas claim your frontmatter and they do not agree.

The open specification permits name, description, license, compatibility, metadata, and an experimental allowed-tools. Claude Code honors roughly fifteen more. The packager allows {name, description, license, allowed-tools, metadata}.

Read those carefully and you will notice the packager rejects compatibility, which the specification explicitly permits. A skill can be entirely spec-legal and still fail to build.

The practical consequence: fields that work in Claude Code can block you from ever packaging the skill for upload. If it will only ever run locally, use whatever you like. If you intend to hand it to someone, stay inside the packager's list.

Then the borrowed field. Twenty-eight of the 187 files, 15%, set a top-level version. No schema defines it. It exists in plugin.json, a different file for a different purpose, and it has been copied across by people reasonably assuming it means something. The sanctioned place is inside metadata, and exactly one file out of 187 does that.

Run the check on something real

All of the above is a checklist, and a checklist you have to remember is a checklist you will not run. So it is a skill.

skill-preflight is free and linked at the end of this guide. Guided shape: a short body, a reference file holding every rule with its reasoning, and one script. The script is standard library only, with no dependencies, no network access and no install step. That last part is deliberate: a tool that checks whether you assumed packages were installed should not assume packages are installed.

It checks what this guide argues for. Folder name against declared name. Third-person description carrying real triggers. Angle brackets. Body length. Orphaned references, nested reference chains, missing tables of contents. Non-spec fields, and separately, fields that will block packaging. It reports passes as well as failures, because you need to see what was actually checked.

Here is what it says about itself:

  ok   FILE         SKILL.md present.
  ok   NAME-DIR     `name` matches the folder (skill-preflight).
  ok   DESC-LEN     `description` is 564 chars (cap 1024, median in the wild 378).
  ok   DESC-PERSON  `description` reads as third person.
  ok   FM-ANGLE     No angle brackets in frontmatter.
  ok   BODY-LEN     Body is 56 lines (guidance under 500, median 136).
  ok   BUNDLE       1 reference file(s), 1 script(s).

0 error(s), 0 warning(s).

Passing your own check is the minimum bar, and it is worth saying I had to fix things to get there.

What it finds in the wild

I ran it across all eight of Anthropic's finance skills and three of my own shipped deliverables. The results were more interesting than I expected.

All eight of Anthropic's carry warnings and five carry errors. Every one uses a Claude Code field that would block .skill packaging. The five using argument-hint put angle brackets in frontmatter, against the specification's own guidance. To be completely clear what this does and does not mean: those skills work correctly where they are meant to run, and their descriptions are the best-written ones in this article. The finding is not that Anthropic is careless. The finding is that the gap between the specification and the tooling is wide enough that first-party code sits inside it, which should lower your confidence that care alone will keep you out of it.

And all three of mine fail the folder-name rule. Every one has a source folder literally named skill/ while its frontmatter declares something else. Two happened to be packaged from a renamed copy, so their shipped archives are correct. The third was packaged directly and shipped an archive whose every member contradicted its declared name.

Nothing warned me. The first-party validator returns Skill is valid! for exactly that folder. I only found it by writing a tool that checks a rule the official tooling does not.

It also found a script in one of them that the instructions never mention, so nothing says whether to run it or read it, which is the execution-intent rule from two sections ago, shipped without being followed.

And one finding it reported at first turned out to be my checker's mistake, not the skill's: it flagged a reference file for pointing at a script and a fonts folder, which is not a reference chain at all. A reference that names a script to run causes no partial read of anything. I had written the rule wider than the reason behind it, and the tool faithfully enforced my error until I read the finding closely enough to doubt it. That is worth including because it is the other half of the argument: a check is only as good as the rule it encodes, and you still have to read what it says.

That is the honest argument for this entire section. I know these rules. I wrote them down. I still broke the folder-name rule on all three deliverables and the intent rule on one, silently, and only caught it by building something that checks mechanically. Your professional judgment is not the failure point. Your attention is. Which is precisely why this profession invented review as a separate step performed by a different person, and why the skill you build should contain one.

Part 3: Ship

Three things to know before a skill leaves your laptop, and one before you let somebody else's onto it.

Skills do not sync

This surprises everyone, so it goes first.

A skill you upload to claude.ai is not on the API. Neither of those is the one on your desktop. There is no sync, no account-level library, no "my skills" that follows you around. Each surface is a separate place you put a copy.

The row that matters for a firm is the fourth. A claude.ai upload is individual-user only. No organization distribution, no admin management, no way to push an update to your staff. If you build a close procedure and want six people running it identically, uploading it to claude.ai six times is the plan, and every fix means doing that again.

The project folder row is the one people miss and it is usually the answer. Put the skill in a shared repository, and everyone who has that folder has that skill, updates included, with a history of what changed.

If your firm runs managed settings, that row is the real enterprise answer, and it is the only path that pushes a skill to staff without each of them doing something. Most small firms will not have this. The shared-folder route works and costs nothing.

One naming trap while we are here: a Claude Code skill folder may not be named synced, in any capitalization. It is reserved.

Runtime differs by surface

A skill that works on your laptop can fail silently elsewhere, and the differences are not obvious.

The API sandbox has no network access and cannot install packages. Pre-configured dependencies only. A script that pulls a library at runtime works on your computer and dies there.

claude.ai varies by admin setting. Network access may or may not exist depending on how your workspace is configured, which means the same skill behaves differently for you and for the person you sent it to.

Claude Code has your full network access, which is the most permissive and the least representative. Building only against it is how you end up with a skill nobody else can run.

The practical rule: test where it will actually run, and prefer standard library over anything you have to install. Every dependency is a place the skill can fail on somebody else's computer, in a way they will report to you as "it didn't work."

Packaging

To hand a skill to someone outside your project folder, you package it: .skill is a zip with the extension changed.

python3 package_skill.py path/to/my-skill ./dist

Two things it does that matter. It validates before writing, so a broken skill does not silently become a broken archive. And it takes the member prefix from the folder name, which is the trap from Part 2. Package from a folder named exactly what your frontmatter declares, or you ship an archive contradicting itself.

Run the pre-flight check first. Then package.

Installing somebody else's skill

Now the part that should make you uncomfortable, because it is the part the format is weakest on.

There is no signing. No registry. No version pinning. No mandatory review. Nothing verifies who wrote a skill, nothing pins its contents, and nothing checks it before it runs. The specification is deliberately silent on all of it, and trust is explicitly delegated to you and your firm.

Anthropic's own guidance is to treat installing a skill like installing software, and that is the right frame. So:

Read every bundled file, not just SKILL.md. The instructions are the part that looks like the skill. The scripts are the part that runs.

Be especially careful with anything that fetches a URL. Fetched content can carry instructions, and the thing at the other end can change after you reviewed it. A skill that was fine in March is not necessarily fine in June, and nothing will tell you.

Check that the scripts do what the description says. A mismatch between stated purpose and actual behavior is the whole attack surface.

And two facts specific to firms handling client data:

Enterprise content scanning covers claude.ai and Cowork uploads only. Not the Skills API. Not the Console. If your compliance posture assumes scanning, know exactly where it applies.

Agent Skills are not covered by zero-data-retention arrangements. If a vendor tells you their skill offering is ZDR-covered, ask them to show you where, because the documentation says otherwise.

None of this means do not install other people's skills. It means the diligence is yours, it is not automated, and it is the same diligence you would apply to any other vendor artifact touching client books. You already know how to do this. Nobody has told you that you need to.

The Playbooks

Everything to here was how. This is what.

Thirteen skills, grouped by when you need them, each with the trigger, the mechanism, the failure mode, and a starter spec. Then the last one gets built in front of you and handed over.

A word on how to use this section. Do not build thirteen skills. Build one, use it for a month, and let it teach you which of the others you actually want. The list is a menu, not a program.

Playbook Zero: tear four down before you build one

Before you write anything, read somebody else's.

Anthropic publishes eight finance skills in an open repository, Apache licensed. They are the largest body of accounting-specific skills anybody has published, they are first-party, and as far as I can tell the accounting press has never mentioned them once. Together they run 1,906 lines.

Read four skills before you build anything. Three from that plugin and one from outside it. It takes half an hour, and each teaches a different decision you are about to face.

Here is the first thing you notice when you have all eight open:

Every single one is a bare skill. No scripts/. No references/. No assets/. Eight skills, nineteen hundred lines, not one bundled file between them. I checked this by listing the directories rather than inferring it from the text, because a skill can perfectly well have a folder it never mentions. Every one of the eight contains exactly one file.

Mark any of them up with Compute, Compose, Render and you get the same answer: it is all Compose. Nothing computes, nothing renders, nothing verifies.

That is not a criticism, and understanding why not is the point of reading them. But it does mean the finance plugin can only teach you one of the four shapes. So the fourth skill in this teardown comes from somewhere else, and it is the one that will change how you build.

reconciliation: the method skill, and where it stops

175 lines. Three reconciliation types, three categories of reconciling item, aging buckets, escalation thresholds, eight best practices. It is a good, tight statement of how reconciliation works.

Then look at the thresholds. Ten thousand dollars for supervisor review, fifty thousand for controller, a hundred thousand in aggregate. Followed by a footnote:

"Set thresholds based on your organization's materiality level and risk appetite. The examples above are illustrative."

That footnote is the method-versus-policy line, drawn explicitly by the author. Anthropic can tell you the shape of a reconciliation. It cannot tell you what is material to your firm, so it declines to, and says why.

Two more things worth seeing. It describes segregation of duties as a best practice, the person reconciling should not be the person processing transactions in that account, and it has no mechanism whatsoever to enforce that. It is written down, not enforced. And it assumes one entity throughout, "your organization's materiality," which is the assumption every published accounting skill makes.

close-management: the checklist skill, and a field worth stealing

221 lines, and structurally the most interesting of the eight.

It is a five-day close, T+1 through T+5, written as literal markdown checkboxes:

### Close Day 1 (T+1: First Business Day After Month-End)

- [ ] Confirm all sub-ledger modules have completed period-end processing
- [ ] Run AP accruals for goods/services received but not invoiced
- [ ] Post payroll entries and payroll accrual
- [ ] Complete bank reconciliation with final bank statement
- [ ] Run fixed asset depreciation

That is the checklist pattern from Part 1, in first-party code. Not described. Implemented, as checkboxes the model copies and ticks.

But the thing to steal is in its frontmatter:

name: close-management
description: Manage the month-end close process with task sequencing,
  dependencies, and status tracking...
user-invocable: false

user-invocable: false. Nobody can call this skill directly. It exists purely as background knowledge that informs other work, loaded when the model recognizes it is relevant and never as a command somebody types.

That is a design decision most people do not know is available, and it is exactly right for a certain kind of skill. Your firm policy skill is probably one. You do not want anybody running /firm-policy. You want it consulted, silently, whenever anybody does anything.

(It is a Claude Code field, not a spec field, which means it will block .skill packaging. That trade is Part 2's frontmatter problem in miniature.)

audit-support: where the numbers are real, and why

374 lines, the largest of the eight, and it contains this:

Fully specified. No footnote calling it illustrative, no instruction to substitute your own.

Which contradicts what I said two skills ago, and the contradiction is the lesson. Three of the eight carry the illustrative disclaimer. The other five give you hard numbers. The line between them is not carelessness, it is a distinction worth internalizing:

Where the number comes from a professional standard, they give it to you. Sample sizes for control testing are a methodology question with an established answer. Anthropic can supply that, and does.

Where the number comes from your firm's own risk appetite, they leave it blank. Materiality, escalation thresholds, what counts as a variance worth explaining. Nobody outside your firm can set those, and pretending otherwise would be worse than leaving a bracket.

So when you are filling in your own skill and you hit a number, ask which kind it is. If it comes from a standard, go and get the standard. If it comes from your firm's judgment, you are the only available source and the bracket is waiting for you.

xlsx: the one to actually copy

Now leave the finance plugin, because the most useful skill Anthropic has written for an accountant is not in it.

xlsx is their spreadsheet skill. It is what runs whenever a workbook is the deliverable, which for most of us is most of the time. And it is Tooled shape: SKILL.md plus a scripts/ folder containing recalc.py, about ten and a half kilobytes of it.

Four things in it are worth stealing outright.

It ships a verification script, and forbids delivery without it.

"Zero formula errors. Never ship while recalc.py reports errors_found."

recalc.py opens the workbook in LibreOffice headless, computes every formula, and reports what broke. That is the same technique Lovely McInerney describes arriving at as an accountant, independently, for the same reason. First-party engineering and a practitioner converged on identical machinery, which is about as strong a signal as this field offers that the check is not optional.

It bans hardcoded values outright.

"Use formulas, never hardcoded results. Write sheet['B10'] = '=SUM(B2:B9)', not the Python-computed total. The sheet must recalculate when its inputs change."

That is Playbook 11's rule, in first-party code, and it is the difference between a workbook a reviewer can follow and one they have to take on faith.

Its description carries a negative trigger, and I owe a correction here. Earlier in this guide I said nobody teaches the negative trigger. Anthropic's does not teach it, but it demonstrates it, and more aggressively than my own example:

"Do NOT trigger when the primary deliverable is a Word document, HTML report, standalone Python script, database pipeline, or Google Sheets API integration, even if tabular data is involved."

Five named exclusions. If you were unconvinced that a description should say what it is not for, that is what conviction looks like.

And it states the limit of its own check, which nothing else in the corpus does and which is the single most important sentence I found in any of these files:

"A green recalc proves your formulas evaluate, not that they are right. An off-by-one range or a reference to the wrong row yields a clean, error-free file with wrong numbers."

Sit with that, because this guide has spent a lot of words telling you to add a check, and that sentence is the honest boundary on the advice. A passing check means the machinery ran. It does not mean the answer is correct. Your reconciliation can tie against the wrong account. Your report can foot perfectly and describe the wrong period.

The instruction it pairs with that is the right one: write two or three formulas first, confirm they pull the values you actually expect, and only then build out the grid. Verify the logic by hand at small scale before you trust the AI at large scale. Every accountant already does this with a new workbook. Do it with a new skill.

There is a companion trap in the same file worth knowing, because it is the kind of thing that bites silently:

"errors_found exits 0, so never treat a clean exit as a clean workbook."

A script that exits zero has not necessarily passed. If you write a check, decide deliberately what its exit code means, and say so where the next person will read it.

What the three of them teach, together

None of this is a knock. A method skill is a legitimate shape, these are well-built examples of it, and the descriptions on them are the best-written ones in this article. You should read all eight.

But line them up against Compute, Compose, Render and the gap is precise and identical every time:

That table is the specification for the skill you should build. Anthropic wrote the textbook chapter, and wrote it well. Your firm's policy, your clients, your numbers, and your check are the parts that are missing, and they are precisely the parts nobody else can write for you.

Compute, Compose, Render, and add the check. That is the whole method, and every playbook below is an application of it.

Group A: Foundational

Four skills every firm should have. Mostly Bare or Guided shape, buildable in an afternoon each, and the first one is genuinely the first one.

Playbook 1: The Firm Policy Skill

Build this first. Not because it is the most impressive, but because everything else assumes it exists.

Your firm has conventions. Accrual for the SaaS clients, cash for the trades. Never invent a GL account, use the client's chart. Anything over five thousand gets flagged rather than categorized. The Stripe deposits land net of fees and have to be grossed up. Right now those live in three seniors' heads and a Slack thread from 2024.

The mechanism: this is the only artifact in the whole stack where firm policy can live in a form the AI actually obeys. Not a PDF nobody opens. Not a training week. A file that gets read before the work happens, every time.

The failure mode is writing it too long. People sit down to write their firm policy and produce twenty pages, and a twenty-page policy gets ignored by the AI and by your staff for the same reason. Aim for one page. The test: could a competent new hire follow this on their first day without asking a question? If yes, ship it and add to it when somebody asks a question anyway.

Shape: Bare. One SKILL.md, no subfolders. This is the 45% case and it is correct here.

Starter spec:

firm-policy/
└── SKILL.md          # ~80 lines

Description triggers on: "what's our policy on", "how do we handle", "categorize this", and, importantly, it should be written so the model reaches for it unprompted when doing any categorization work.

Body sections: close procedure in order · categorization conventions · the never-do list · client-specific gotchas · escalation thresholds with your numbers, not illustrative ones.

That last line is Playbook Zero's lesson, applied. Anthropic gave you the shape. This is where you fill it in.

What it looks like. The core of it is a handful of tables and one list. Here is the shape, with the values a firm actually has to decide left in brackets:

## Non-negotiables

- Never invent a general ledger account. Use the client's existing chart.
  If nothing fits, flag it and stop.
- Never auto-post anything over [$5,000]. Prepare it, flag it, leave it.
- Never modify a closed period.

## Basis of accounting

| Client type              | Basis     | Note                                     |
| ------------------------ | --------- | ---------------------------------------- |
| [SaaS and agency]        | [Accrual] | [Recognized on delivery, not receipt]    |
| [Trades and contractors] | [Cash]    | [Except retainage, tracked separately]   |
| [Everything else]        | [Ask]     | [Do not infer from the prior bookkeeper] |

## Escalation thresholds

| Condition                            | Action                             |
| ------------------------------------ | ---------------------------------- |
| Single transaction over [$5,000]     | Flag for review, do not categorize |
| Uncategorized older than [60 days]   | Escalate to the engagement lead    |
| Variance over [10%] month over month | Explain in the close notes         |

Those brackets are the entire point, and they are Playbook Zero's lesson made concrete. Anthropic's reconciliation skill footnotes its own thresholds as illustrative, because a vendor cannot know your materiality. The brackets are the part only your firm can fill in, and filling them in is most of what makes a skill yours.

The complete template is one of the downloads at the end. It is a bare skill: one file, seventy-eight lines, nothing else in the folder.

## When to stop and ask

Ask rather than decide when: the transaction is novel for this client, the answer
changes the financial statements materially, two conventions in this file conflict,
or the right answer depends on something only the client knows.

**When you get an answer, write it into this file.**

Compute, Compose, Render, and add the check. Here there is almost no Compute and no Render, so there is nothing to script and no check to write. That is fine. Not every skill needs all three.

Playbook 2: The New-Client Cleanup Diagnostic

Trigger: you have just taken on a client and nobody knows how bad the books are yet.

Every firm does this and almost nobody does it the same way twice. You poke around, form an impression, quote a cleanup fee, and find out in week three whether the impression was right.

The mechanism: a diagnostic that runs the same checks in the same order every time turns an impression into a number. Uncategorized volume and how far back it goes. Duplicate vendors. Sign errors. Suspense account balance. Accounts with one transaction ever. Months where the bank never reconciled. Personal expenses in the business accounts.

The failure mode: scope creep into fixing. The temptation is to have it clean things up while it is in there. Do not. A diagnostic that also modifies is a diagnostic you cannot run twice and cannot trust the second time. It reports. You decide.

Real example: this shape shows up repeatedly in what firms actually do with AI. "Dump 12 months of bank statements, get an expense spreadsheet." "Find mismatches between the ledger and the bank statement." Those are the same job, done ad hoc. The skill is what happens when you stop redoing it.

Shape: Guided, growing to Tooled. Start with the checks written out. Move to scripts once you have run it on five clients and know which checks actually matter.

Starter spec:

cleanup-diagnostic/
├── SKILL.md                    # the check sequence, in order
├── references/
│   └── thresholds.md           # what counts as bad, in your judgment
└── scripts/
    └── summarize.py            # counts and totals, deterministically

What it produces. A page, not a report. Illustrative output:

CLEANUP DIAGNOSTIC          Northgate Dental        books through 2026-06-30

SCALE
  uncategorized             418 transactions        $   287,410
  oldest uncategorized      2024-11-02              (20 months)
  months never reconciled   9 of 20
  suspense balance          $ 41,880                 as of period end

STRUCTURE
  duplicate vendors         14 probable pairs       (AMEX / American Express, etc.)
  accounts, 1 txn ever      31
  accounts, never used      88 of 214
  sign anomalies            6 income accounts with net debit balances

RISK
  personal in business      23 transactions         $  18,240   probable
  round-number entries      11 over $1,000          manual entry likely
  prior-period edits        4 after their close date

Then two or three sentences of Compose on top: what shape the engagement is, and which of those lines is the one that will actually cost time. Usually it is the nine unreconciled months, not the four hundred uncategorized transactions, and the number that looks worst is rarely the number that matters.

Compute, Compose, Render, and add the check. The counts are Compute and belong in the script. The verdict on whether this is a two-week or a two-month cleanup is Compose. The check: totals in the narrative must match totals in the script output.

Playbook 3: The Month-End Close Runner

Trigger: it is the fourth business day and you are closing eleven clients.

The mechanism: the checklist pattern from Part 1, made real. The AI copies your close checklist into its response and ticks items off as it completes them, which does two things. The work becomes visible while it happens, and a half-finished run is obvious instead of silent.

The failure mode is building this before Playbook 1. A close runner without a firm policy skill underneath it will make categorization decisions on general principles rather than yours, and you will spend more time correcting it than you saved. Build the policy first. This one reads it.

Shape: Guided. The body is the sequence. References hold per-client quirks and the escalation rules.

Starter spec:

month-end-close/
├── SKILL.md
└── references/
    ├── sequence.md          # the close steps, in dependency order
    └── clients.md           # per-client exceptions, one section each

The clients.md file is the one that grows and it is the one that earns its keep. Every quirk you would otherwise explain to a new hire goes in it, once.

What it looks like running. The checklist pattern means the work is visible while it happens, not summarized after:

CLOSE · Northgate Dental · June 2026

  [x] 1. Import bank and card activity            412 transactions
  [x] 2. Categorize against the client chart      401 auto, 11 flagged
  [x] 3. Reconcile all accounts                   3 of 3 tied
  [x] 4. Recurring entries                        depreciation, prepaid insurance
  [>] 5. Variance review                          2 over the 10% threshold
  [ ] 6. Statements

  FLAGGED FOR YOU (11)
    4 over the $5,000 threshold, prepared not posted
    5 first-time vendors, need a category decision
    2 could map to either 6200 or 6240, precedent conflicts

The [>] is the current step. The value of that is not neatness. It is that if the run stops at step 3 because an account will not reconcile, you can see exactly where it stopped, rather than getting a confident summary of a close that did not happen.

Compute, Compose, Render, and add the check. The check here is the most valuable in Group A: nothing gets marked complete without the reconciliation tying. That is the reconcile-before-writing discipline from Part 2, and it is the difference between a close runner and a close pretender.

Playbook 4: The Client Question Answerer

Trigger: a client emails asking why their numbers moved, and answering properly means opening four things.

The mechanism: most client questions are answerable from material you already have, the engagement letter, prior period reports, last quarter's notes, the current ledger. The work is not the thinking, it is the gathering. A skill that knows where to look and in what order turns twenty minutes into two.

The failure mode is letting it send. This one produces a draft. A human reads it and sends it. Write that into the skill explicitly, in the body, near the top, as a non-negotiable. The front-load rule from Part 1 exists for exactly this kind of instruction.

Shape: Guided.

Starter spec: body carries the answering procedure and the tone; references hold the engagement scope, so it knows what is in and out of scope to answer, and the standing explanations for the questions you get every quarter.

What it produces. A draft, plus the trace of where every number came from, so you can check it in ten seconds instead of re-deriving it:

DRAFT REPLY · Northgate Dental · re: "why is June so much worse?"

  Hi Sarah,

  June net income came in at $18,240 against $31,900 in May. Two things
  account for nearly all of the difference:

  Equipment. The new chair was placed in service in June, which brought
  $4,100 of depreciation into the month for the first time.

  Payroll timing. June had three pay dates rather than two, which is a
  calendar artifact and reverses next month. That is roughly $8,900.

  Underlying operations were close to flat. Revenue was up 2%.

  [rest of reply]

SOURCES
  net income Jun / May     P&L, Jun-2026 and May-2026        pulled 14:22
  depreciation             GL 6800, Jun-2026                 pulled 14:22
  payroll dates            GL 6100 detail, Jun-2026          pulled 14:22
  revenue change           P&L comparative                   pulled 14:22

NOT SENT. Review and send from your own mail client.

Two things are doing work there. Every figure carries where it came from, so review is verification rather than recomputation. And the last line is in the output because it is in the skill's non-negotiables, near the top of the body, where the front-load rule says it belongs.

Compute, Compose, Render, and add the check. Any figure quoted in a reply must be pulled fresh, never recalled from earlier in the conversation. Derive, never recall. A wrong number in a client email is a different category of problem from a wrong number in a draft.

Group B: Multi-client

This is the group nobody has built.

I went through everything published, and every accounting skill in the wild assumes one entity, one folder, one filer. Tax dominates the individual publishing because the person filing is the person building. Nobody has written for the shape your practice actually is: thirty clients, one team, the same procedure run thirty times with thirty sets of exceptions.

That is not a small gap. It is the difference between a skill that helps you and a skill that changes your capacity.

The unifying mechanism across this group: the client roster becomes an input. Once a skill takes a list of clients rather than assuming one, the same procedure becomes a portfolio operation, and the interesting questions change from "what is the answer for this client" to "which of my clients need me this week."

Playbook 5: Portfolio Status

Trigger: it is Tuesday and you want to know where all thirty clients stand without opening thirty files.

The mechanism: one roster in, one status table out. Per client: last reconciled date, uncategorized count, open items, whether the close is done for the period. No analysis, no narrative. A dashboard you can build in an afternoon and will look at every day.

The failure mode is making it clever. The temptation is to have it prioritize, recommend, explain. Resist that for version one. A boring accurate table gets used daily. A clever one gets distrusted the first time its ranking disagrees with your judgment, and then it gets abandoned.

Shape: Tooled. Almost all Compute. There is barely a Compose bucket here and that is the point.

Starter spec:

portfolio-status/
├── SKILL.md
├── references/
│   └── roster.md            # your clients, and what "current" means for each
└── scripts/
    └── status.py            # one row per client, deterministic

The roster.md file is doing more work than it looks. "Current" is not the same for a monthly-close client and a quarterly one, and encoding that difference once is what stops the table crying wolf.

What it produces. One table, no commentary:

PORTFOLIO · as of 2026-07-08                    period: June 2026

CLIENT              RECONCILED   UNCAT   OPEN   CLOSE    STATUS
Northgate Dental    2026-06-30       11      2   done     current
Acme Fabrication    2026-06-30        0      0   done     current
Bly Co Services     2026-06-30        4      1   done     current
Crest Builders      2026-05-31       38      6   open     BEHIND 1 period
Harlow Group        2026-06-30        2      0   open     in progress
Pine & Associates   2026-04-30      210     14   open     BEHIND 2 periods
...
Vance Logistics     2026-06-30        0      0   n/a      quarterly, not due

28 clients · 24 current · 2 behind · 1 in progress · 1 not due

Note the last row and the last line. Vance is on a quarterly cycle, so "not reconciled since June" is correct rather than alarming, and the roster file is what knows that. Encoding what current means per client is the difference between a dashboard you check daily and one that cries wolf until you stop looking.

That is also why this is the first Group B skill to build. It is almost trivial, and it is the one that makes the shape of your portfolio visible for the first time.

Compute, Compose, Render, and add the check. Nearly pure Compute. The check: every client on the roster appears in the output, exactly once. A silently dropped client is the failure that matters, and it is the one you will not notice.

Playbook 6: Multi-Client Bank Rec

Trigger: the same reconciliation, across every client, every month.

The mechanism: this is Anthropic's reconciliation skill with the single-entity assumption removed. Same method, three reconciliation types, same categorization of reconciling items, but the unit of work is the portfolio rather than the account. Feed it a roster, get back which clients tied, which did not, and by how much.

The failure mode: one client's mess halting the batch. If client eleven has a broken export, clients twelve through thirty still need to run. Write the skill to continue and collect failures, not to stop. This sounds obvious and is the single most common reason batch skills get abandoned after two uses.

Real example: the most-repeated bookkeeping use of AI in this profession is exactly this job done manually. Finding mismatches between the ledger and the bank statement. Comparing AR in an operational system against the ledger. Comparing AP against vendor portals. Firms are already doing this one client at a time and calling it a game changer. The portfolio version does not exist.

Shape: Full. This is the one I build end to end in Playbook 13, and the one you can download.

Starter spec:

multi-client-bank-rec/
├── SKILL.md
├── references/
│   ├── methodology.md       # matching rules, tolerances, item categories
│   └── format.md            # what the output looks like
├── scripts/
│   ├── reconcile.py         # the matching, deterministic
│   └── verify.py            # must report zero before delivery
└── assets/
    └── sample/              # a synthetic client that ties, and one that does not

Compute, Compose, Render, and add the check. Matching is Compute and belongs entirely in the script. Explaining an unexplained variance is Compose. The check is non-negotiable: the reconciliation has to tie or the run reports a failure, and there is no path where a narrative gets written over numbers that do not balance.

This is the one built end to end in Playbook 13, including the two ways I got it wrong. Skip ahead if you want the build rather than the spec.

Playbook 7: Cross-Client Anomaly Sweep

Trigger: you want to know if anything is wrong anywhere, before a client tells you.

The mechanism: the same handful of checks, run across every client, surfacing only the exceptions. Negative balances that should not be. A vendor appearing in one client's books that has never appeared before. Month-over-month swings past a threshold. Accounts with activity that were dormant for a year. Duplicate payments.

The failure mode is alert fatigue, and it kills these faster than anything. A sweep that surfaces forty items a week gets ignored by week three. Tune thresholds until it surfaces three to five, and accept that you are missing things. A sweep that surfaces three real items and gets read beats a comprehensive one that does not.

Shape: Tooled.

Starter spec: the checks live in a script because they are pure Compute. The thresholds live in a reference file because they are firm policy and will change. Keeping those separate is what lets you tune without touching code.

What a good week looks like. Four items, not forty:

SWEEP · week ending 2026-07-08 · 28 clients · 9 checks

  Pine & Associates    vendor first seen        $ 14,200   "MERIDIAN CAPITAL"
                       largest first-time payment in 14 months

  Crest Builders       duplicate payment        $  3,180   same vendor, same
                       amount, 2026-06-14 and 2026-06-17

  Harlow Group         dormant account active   $  9,650   2140 Notes Payable,
                       no activity since 2025-03

  Northgate Dental     swing over threshold      -34%      6400 Marketing,
                       vs trailing 3-month average

  24 clients quiet.

That last line matters more than it looks. A sweep that reports only exceptions is indistinguishable from a sweep that failed to run. Always state how many were checked and found clean, or you will eventually spend a quiet week wondering.

Compute, Compose, Render, and add the check. The check on this one is unusual and worth stating: run it against a client you know is clean and confirm it stays quiet. A sweep that never produces a false positive is more suspicious than one that occasionally does, but a sweep that lights up on a clean file is worthless.

Playbook 8: The Per-Client Memory File

Trigger: the third time you explain to somebody that this client's deposits land net of fees.

This one is not really a skill. It is a reference file that every other skill reads, and it may be the highest-leverage thing in this entire guide.

The mechanism: one file per client, holding what is weird about them. The stuff that lives in a senior's head. Which accounts they misuse. What their owner draws look like and where they run. The vendor whose name changed. The month they switched systems and why the comparatives break there.

The failure mode is letting it become a CRM. This is not contact details, engagement scope, or billing. It is operational exceptions only. The test for whether something belongs: would you say it to a new hire in the first ten minutes of handing them this client's file?

And the thing that makes it compound: write into it. When a skill asks you a question and you answer, the answer goes in this file. That is the ask-do-not-guess discipline from Part 2, and it is what turns a static reference into something that gets better every month somebody uses it. A skill that asks the same question twice is a skill nobody finished building.

Shape: it is a references/ folder shared across skills.

firm-knowledge/
└── references/
    └── clients/
        ├── acme.md
        ├── bly-co.md
        └── ...

McInerney hit the same problem from the software side and solved it the same way. Her fixed assets and investments skills both needed the chart of accounts, so she pulled it into a shared library outside both skills. Her line about it is the one to remember: "This is standard software architecture, which means it was completely new to me coming from a world where every Excel workbook was its own island."

Your client knowledge is currently an island per person. This is the bridge.

What one looks like. Short, operational, and written the way you would brief somebody:

# Northgate Dental

## Basis and structure

- Accrual. S-corp. Fiscal year ends 12/31.
- Owner takes W-2 plus quarterly distributions. Draws run through
  operating checking, NOT payroll. Do not reclassify them.

## Quirks

- Merchant deposits land NET of processor fees. Gross up against 4010,
  fee to 6150.01. The deposit in the bank never matches the invoice.
- Two entities share a building. Occupancy is split 60/40 by a monthly
  allocation entry. Do not categorize rent directly.
- Switched practice-management systems 2025-03. Comparatives before that
  date are not reliable and should be footnoted, not explained away.

## Rulings (append, do not edit)

- 2026-04-12 · Lab fees to COGS, not supplies. Confirmed with Sarah.
- 2026-06-03 · New chair is 7-year property, in service June.
- 2026-06-28 · "MERIDIAN CAPITAL" is the equipment lender, to 2140.

That last section is the whole idea. It is append-only and dated, every entry is a question somebody already asked and answered, and every skill your firm runs reads this file before it does anything.

Three months in, it is the most valuable file in your practice, and it was assembled entirely out of questions that were going to be asked anyway.

Playbook 9: The Year-End Prep Runner

Trigger: January.

The mechanism: 1099 determination, W-9 gaps, vendor totals against thresholds, missing taxpayer IDs, entity classification. It is the same procedure across every client, it is highly rule-driven, and it is almost entirely Compute, which makes it an unusually good fit.

The failure mode is treating a judgment call as a rule. Whether a particular payment is reportable is sometimes genuinely ambiguous. Have the skill flag ambiguity rather than resolve it, and record your ruling in the client memory file so next year it does not ask again.

Shape: Tooled.

What it produces. The exception list is the deliverable. Everything that is fine does not need a line:

1099 PREP · 2026 · Northgate Dental          142 vendors examined

REPORTABLE, MISSING INFORMATION (4)
  Meridian Capital          $ 41,200   no W-9 on file
  J. Alvarez Contracting    $ 14,880   no TIN
  Coastal Property Mgmt     $ 28,400   no W-9, likely rent, box 1
  Sandra Vinh               $  3,100   TIN present, name mismatch vs IRS format

REPORTABLE, COMPLETE (11)                     ready to file

AMBIGUOUS, NEEDS A RULING (2)
  Pacific Dental Supply     $  9,420   goods vs services split unclear
  Harbor Legal Group        $  7,650   attorney payments, box 10 vs box 1

BELOW THRESHOLD (125)

  totals tie to GL: yes ($312,880 across 142 vendors)

The ambiguous section is the one that matters. Those two are genuine judgment calls, the skill does not resolve them, and once you rule on them the ruling goes into that client's memory file so next January it does not ask again.

That is the pattern this entire group is built on. Ask once, record the answer, never ask again.

Compute, Compose, Render, and add the check. The check: totals per vendor reconcile to the ledger, and every vendor over the threshold either has a taxpayer ID or appears on an exception list. No exceptions silently dropped.

Group C: Full-shape deliverables

Three skills that produce something a client sees, with your firm's name on it.

Everything changes at this boundary. Internal tools can be a bit wrong and you catch it. A deliverable that is a bit wrong goes out. So these are all Full shape, all have verification that can actually fail, and none of them should be your first skill.

The general architecture is the same across all three, and it is the one that emerged independently across three deliverables of mine:

<deliverable>/
├── SKILL.md                  # the procedure, short
├── references/
│   ├── methodology.md        # what to compute, and how. The big one.
│   └── format.md             # what it should look like. Separate on purpose.
├── scripts/
│   ├── generate.py           # renders the artifact
│   └── verify.py             # checks the artifact, must report zero
└── assets/
    └── sample/               # what good output looks like

The methodology and format split is Compute and Render expressed as files, and I did not plan it. It showed up in two of three deliverables independently before I noticed it was a pattern.

Playbook 10: The Client Financial Review

Trigger: the annual or quarterly conversation where you tell a client what their numbers mean.

The mechanism: figures pulled deterministically, narrative written fresh, formatting scripted. Executive summary, what went well, what is at risk, and the two or three things to actually do about it.

The failure mode is the narrative drifting from the numbers. It happens when the model writes the story and then the figures get regenerated, or when a variant of the report is produced separately. The fix is structural: one computed payload, every variant rendered from it. Numbers cannot drift between the client copy and the file copy if there is only one set.

Shape: Full. And this is where the citation discipline earns its place. If a figure appears in the narrative, there should be a path from it back to the query that produced it. You are an accountant. You already know why.

Compute, Compose, Render, and add the check. The check is that the recomputed totals match the stated totals, and the categories sum. Run it before anything renders.

Playbook 11: The Close Binder

Trigger: you need balance sheet substantiation that somebody else could pick up.

The mechanism: a workbook with a tab per account, supporting detail behind each, and live tie-out formulas rather than hardcoded values. The point is not the numbers, it is that a reviewer can follow them.

The failure mode is hardcoding. A model asked to produce a spreadsheet will happily write values where formulas belong, and the result looks perfect and is unauditable.

The rule to adopt is one that an accountant and Anthropic's engineers arrived at separately. McInerney's version: every cell that should be a formula is a formula, blue for inputs, black for calculations, nothing delivered until a recalculation confirms no formula resolves to an error. Anthropic's xlsx skill states it as a requirement of every output: "Use formulas, never hardcoded results. The sheet must recalculate when its inputs change." Both ship a LibreOffice recalculation script to enforce it.

When a practitioner and a platform team independently build the same guardrail, that is the one to copy first.

Shape: Full, and this is the one where the verification script is the most important file in the folder. A broken formula in a spreadsheet is invisible until it opens on somebody else's screen.

Playbook 12: The Cash Projection

Trigger: the client asks whether they can make payroll in six weeks.

The mechanism: forward projection from actual behavior, not from a budget. Recurring inflows and outflows derived from history, known commitments layered on, and a weekly curve against whatever the client treats as their floor.

The failure mode is false precision. A weekly cash number twelve weeks out is not a forecast, it is a shape. Write the skill to say so. The value is in whether the curve crosses the floor and roughly when, not in the third significant figure, and a skill that presents it as certainty is worse than no skill.

Shape: Full.

Compute, Compose, Render, and add the check. The check here is a sanity band rather than a tie-out: does the projection start from the actual current balance, do the recurring items reconcile to trailing actuals, and does the total of the projected period fall within a plausible range of history. A projection that starts from the wrong number is wrong everywhere.

Playbook 13: Build it in front of you

The other twelve are specs. This one is a build, start to finish, and at the end you can download what comes out of it.

We are building Playbook 6, the multi-client bank reconciliation, because it is the one that does not exist. It runs from CSV exports with no accounting-system connection, so you can use it whatever you are on.

Step 1: Write the evaluation first

Before writing a line of the skill, I ran the task without one. Gave a model two CSVs and asked it to reconcile them.

It did a reasonable job and made exactly the mistake you would expect. It read amounts out of the files and did arithmetic in prose, and on the third client it quietly matched a check for 5,940 against a bank line of 5,490 and called the reconciliation complete. It was not being careless. Two numbers that similar, on nearby dates, look like the same transaction, and describing them as matched is the locally sensible thing to do.

That failure is the whole specification. The skill exists to make that particular mistake impossible.

Three scenarios, from the failures:

1. A client whose books tie, with ordinary timing items. Does it correctly leave them alone?
2. A client with an unrecorded bank charge. Does it identify the adjustment rather than forcing a balance?
3. A client with a transposition. Does it refuse to tie?

Step 2: Mark the procedure C, Co, R

Almost all Compute, which is correct for reconciliation and is precisely why doing it in prose fails. There are exactly two Compose steps, and both are about explanation rather than calculation.

Step 3: Write the description

name: multi-client-bank-rec
description: Reconciles bank statements against the ledger for every client on a
  roster in one run, matching transactions, categorizing reconciling items as timing
  differences, required adjustments, or amount mismatches to investigate, and
  verifying the arithmetic before anything is delivered. Works from CSV exports, no
  accounting-system connection required. Use when asked to run bank reconciliations
  across clients, reconcile the portfolio, check which clients tie for a period, or
  find where the books and the bank disagree. Not for a single-entity reconciliation
  where opening the file directly is faster.

598 characters. Both halves. Third person. Four natural triggers, and a negative clause on the end so it does not fire on a job better done by hand.

Step 4: Partition

multi-client-bank-rec/
├── SKILL.md                    # 77 lines: non-negotiables, then the workflow
├── references/
│   ├── methodology.md          # matching, constants, categories, known limits
│   └── format.md               # output shape and how to present it
├── scripts/
│   ├── reconcile.py            # all the Compute
│   └── verify.py               # the check
└── assets/
    └── sample/                 # three synthetic clients

Methodology and format split, which is Compute and Render as files. The body carries the four non-negotiables at the top, per the front-load rule, then the five workflow steps.

Step 5: The part where it went wrong twice

Here is what actually happened, because it is more instructive than a clean build.

First version: everything tied. Every client, every time. Which felt great for about ninety seconds. The bug was structural: every unmatched row got categorized as a reconciling item, and both sides got adjusted, so the reconciliation always balanced by construction. A transposition would have produced two tidy reconciling items and a perfect tie. The exact failure the skill existed to prevent, rebuilt in code.

The fix was a fourth category. Two unmatched rows on the same side of zero, within the date window, close enough in amount to be the same transaction, get paired and flagged to investigate, and they adjust nothing. The client does not tie until a human resolves it.

Second version: a false positive. Acme now failed, pairing a legitimate outstanding check of 1,875 against a bank service charge of 42.50, purely because both were negative and five days apart. Two unrelated transactions declared a transcription error.

The fix was a relative tolerance. A transposition produces a similar magnitude: 5,940 against 5,490 is a 7.6% spread. An outstanding check against a service charge is 97.7%. A quarter separates them cleanly.

And that constant then needed the no-voodoo rule applied to it, so it is documented in the file with its reasoning and an explicit instruction not to tune it to make a client tie. If you do not know why a threshold holds its value, neither will anyone running your skill in eight months.

Step 6: The check

3 reconciliation(s) verified, 0 client(s) could not be processed.
0 failures.

verify.py checks five things: every roster client appears exactly once, the arithmetic recomputes from its own inputs, anything marked tied has a difference of zero, the reconciling items sum to the adjustments claimed, and nothing was silently dropped.

That last one matters most and is the least obvious. A client missing from the output is worse than a client that did not tie, because a difference is visible and an absence is not.

Step 7: Run it

CLIENT                             LEDGER         BANK       DIFF  STATUS
Acme Fabrication                55,232.50    55,232.50       0.00  TIED
Bly Co Services                 25,431.25    25,431.25       0.00  TIED
Crest Builders                  44,130.00    44,580.00     450.00  OUT OF BALANCE  (1 to investigate)

2 of 3 tied. 0 could not be processed.

--- Crest Builders ---
  matched 3 of 4 ledger rows (3 exact, 0 within 5 days)
  [investigate         ] 2026-06-12       450.00  Check 3310 - Materials recorded -5,940.00, bank shows -5,490.00

Scenario three passes. It refuses to tie, and it says why.

One more test, because the failure mode for batch skills is one client breaking the run. Feed it a corrupted export and a roster row pointing at files that do not exist:

Acme Fabrication                55,232.50    55,232.50       0.00  TIED
Crest Builders                  44,130.00    44,580.00     450.00  OUT OF BALANCE  (1 to investigate)
Bly Co Services                                                    FAILED: ValueError: could not convert string to float: 'NOT_A_NUMBER'
Ghost Client                                                       FAILED: FileNotFoundError: [Errno 2] No such file or directory: 'missing-ledger.csv'

1 of 2 tied. 2 could not be processed.

Two clients broken, two still reconciled, both failures named. That is the behavior you want at 4pm on the fourth business day.

Step 8: Pre-flight and package

  ok   NAME-DIR     `name` matches the folder (multi-client-bank-rec).
  ok   DESC-PERSON  `description` reads as third person.
  ok   FM-ANGLE     No angle brackets in frontmatter.
  ok   BODY-LEN     Body is 77 lines (guidance under 500, median 136).
  ok   BUNDLE       2 reference file(s), 2 script(s).

0 error(s), 0 warning(s).

Then package, from a folder named exactly what the frontmatter declares. Twelve files, 24 KB.

It is yours. All three skills are linked at the end. No email box, no gate. The sample data is synthetic, the scripts are standard library only, and you can read every line before you run it, which after Part 3 you know to do anyway.

Compute, Compose, Render, and add the check. Twice I wrote something that produced a confident wrong answer, and both times the check is what surfaced it. That is the argument for this whole guide, and I would rather show you the two failures than a clean build that teaches nothing.

Reading a skill somebody sends you

Skills get traded now. Somebody in your network will send you one this year, and the format gives you nothing to lean on: no signing, no registry, no review gate, no way to know whether the thing at the end of a URL is what it was last month.

So the diligence is yours. How much depends on where it came from.

Read everything: if it came from the internet

A repository, a directory listing, a link in a newsletter. You have no relationship with the author and no recourse.

Read every bundled file, not just SKILL.md. The instructions are the part that looks like the skill; the scripts are the part that runs. Check that what the scripts do matches what the description claims, because a mismatch between stated purpose and actual behavior is the entire attack surface. Be hardest on anything that fetches a URL, since fetched content can carry instructions and can change after you approved it.

Then run it against data you do not care about before you run it against a client.

Read the scripts: if it came from a vendor

Your software provider ships a skill for their product. Reputational risk gives you some protection, and it is not nothing.

Read the scripts and the permissions. Establish what it writes and where. And ask the compliance question directly, because two facts are easy to get wrong: enterprise content scanning covers claude.ai and Cowork uploads only, not the API or Console, and Agent Skills are not covered by zero-data-retention arrangements. If a vendor tells you otherwise, ask them to show you where.

Read the description: if it came from a peer you trust

Another firm, somebody whose work you know. This is where skills will actually spread, and where the guard drops.

Read the description and the non-negotiables at the top of the body. You are looking for one thing: does this encode their firm's policy or yours? A close procedure from a firm that books revenue on cash will quietly apply cash conventions to your accrual clients. It is not malicious and it is not broken. It is just not yours, and it will be wrong in a way that looks entirely plausible.

Then run your pre-flight check on it anyway. Trust is not a reason to skip the thirty seconds.

The through line across all three: the format assumes you will do this, because it has decided not to do it for you. That is a real cost of the trade that made it spread so fast. You already have the instincts. Nobody has told you that you need them here.

The three skills

All free, all unlocked, no email box.

skill-preflight checks a skill directory against the specification and the authoring rules the first-party validator does not enforce. Guided shape, three files, and the script is standard library only with no network access. Run it before you hand anything to anybody, and before you install anything anybody hands you.

multi-client-bank-rec reconciles a whole client roster in one run from CSV exports, categorizes the reconciling items, refuses to tie when it finds a transposition, and verifies its own arithmetic before reporting. Twelve files. Three synthetic clients included, one of which does not balance on purpose.

firm-policy is the Playbook 1 template: a bare skill, one file, seventy-eight lines, with every value your firm has to decide left in brackets. Fill it in and delete what does not apply. It is the one to build first and the fastest thing here to make yours.

All three pass their own pre-flight. Read every line before you run them, which by now you know to do anyway.

Sources

Everything factual in this guide traces to one of these. Where I have given a number from my own survey rather than from a document, I have said so in the text.

The specification and official guidance

• Agent Skills specification, agentskills.io/specification. Open standard, published 2025-12-18, stewarded through the Agentic AI Foundation. Development at github.com/agentskills/agentskills.
• Anthropic, Agent Skills overview.
• Anthropic, Skill authoring best practices. Degrees of freedom, the workflow patterns, the anti-patterns, evaluation-driven development.
• Anthropic, Use Skills in Claude Code. Where skills live, per-surface behavior.
• Anthropic Engineering, Equipping agents for the real world with Agent Skills. Source of "effectively unbounded."
• Reference validator, skills-ref.

Skills read for this guide

• github.com/anthropics/skills and the finance plugin in knowledge-work-plugins. Eight finance skills, Apache licensed. reconciliation and close-management are the two worth reading first.
• Lovely McInerney, Building Claude Skills as an Accountant: A Professional Skeptic's Guide, and her Financial-Reporting-Skills repository. Every McInerney quote in this guide comes from these, and as far as I can establish she is the only accountant publishing on skill authoring.

Other material cited

• Simon Willison on Agent Skills, October 2025, for the comparison with MCP and the observation that Claude's own document-handling is implemented as skills.
• Karbon, State of AI in Accounting 2026, for the 98% / 21% adoption-versus-policy gap. Roughly 600 firms, six continents.
• Jason Staats, 127 ways accounting firms are using AI, a crowdsourced list of real practitioner use. Source of the twenty candidate procedures and of the trigger phrasing throughout.

My own numbers

The survey figures, 187 SKILL.md files, 45% bare, median body 136 lines, median description 378 characters, 28 files with an undefined top-level version, are from a census of every skill file on my computer in September 2026. That is a working sample, not a scientific one: it over-represents what I have installed and what I have built. Treat the medians as calibration, not as population statistics.

The comparison of three shipped deliverables, and the finding that all three carried a folder-name mismatch, is from my own work.

A note on what will go stale

This format is nine months old as an open standard and it is moving.

The parts I expect to hold: the loading contract, the description carrying the triggering burden, the run-read-use distinction, and the argument for verification. Those are structural.

The parts I expect to move: the exact frontmatter fields, the packager's allow-list, which surfaces sync with which, and the security posture. The governance gap in particular is unpriced right now and it will get priced the first time a widely-installed skill is compromised.

If you are reading this a year out and something contradicts the current documentation, believe the documentation. And tell me, because I would like to fix it.

Write it down once

Your firm's procedures are trapped.

They are in a senior's head, in a binder nobody opens, in the way a particular file has always been handled. Every hire is a re-explanation. Every departure is a loss. Every March somebody hopes the one person who knows the Henderson file does not take vacation.

That has always been the deal, because a written procedure still needed a person to execute it. What changed is not that you can write things down. It is that written down now runs.

McInerney put it better than I will: the knowledge was never rare, it was just undocumented.

So pick the boring one. The thing you do every month, the same way, that you have explained out loud more times than you can count. Give it an afternoon. Compute, Compose, Render, and add the check.

Then send it to somebody.

Josh Hsu · Legix · revised Sep 2026