You wrote a good prompt in June. Four tries to get it right, and the fourth one was: it read the trial balance, found the mess in Uncategorized Expense, and sorted it into what you could code and what you had to ask about.
Then July came round and you wrote it again from memory. Slightly different words, and the answer came back a different shape. You spent five minutes deciding whether it was as good as last month's.
That five minutes repeats every month. When you turn a prompt into a reusable skill you're not saving the prompt. You're saving the decisions you made while getting the prompt right, in a file the assistant reads back before it answers.
I'm a partner in a tax and accounting firm and I run our month-end. That's where this comes from: the same handful of judgment calls came up every month in a slightly different order, so I stopped re-deciding them and started writing them into files instead. That's process, not proof about anybody's books. Nothing from our work appears below, and every number in this article belongs to a client I made up.
That client is Cedar Hollow Landscaping LLC, invented for this article and the ones beside it: a single-member LLC on cash basis, one checking account, one credit card, about forty transactions a month. Its made-up June trial balance runs to eighteen accounts and has three problems in it. This article fixes exactly one of them, on purpose. The whole close it sits inside is in Get a reviewable monthly close: AI-assisted bookkeeping for small firms.
How do you turn a prompt into a reusable skill you can run every month?
Take one step you already do by hand, run it once as a plain prompt, then save the parts that worked into a file the assistant reads before it answers. A skill is a folder with a file called SKILL.md inside it: a few lines of front matter naming the skill and saying when to use it, then your instructions in ordinary sentences. Start narrow. The uncategorized-expense sweep is a good first one. On the made-up landscaping client's June books that's a $1,284.50 Uncategorized Expense balance across four transactions, sorted into what you can code now, what needs the owner, and what needs a receipt. Write three test cases with the answers already known, run them, then run it on the next month.
Key Takeaways
The file is small - a folder, a file called SKILL.md, a name and a description at the top, and your instructions underneath in plain sentences.
The decisions are the asset - which balance counts as an exception, what gets coded now versus asked about, what the answer has to look like. Those are your rules and nobody can sell them to you.
Narrow beats clever - the made-up June books carry three seeded problems and this skill is built to catch one of them. A skill that volunteers opinions on the other two gets abandoned by the fourth run.
The payoff lands on run two - run one is a prompt that worked. Run two, four weeks later, on a different month, with a tired person driving, is the thing you actually built.
Test cases come before trust - three of them, with the answers written down first: a normal made-up month at $1,284.50 across four transactions, a made-up month with nothing uncategorized, and a made-up file from the wrong period.
Budget ten minutes a month to keep one - that's re-running the three test cases and writing one change-log line. Six skills is an hour. Twelve is two hours you have to find every month, and that arithmetic is the whole build-versus-subscribe question.
This article describes file shapes and host behavior as of writing, including the two blocks above. Hosts change these. Where something differs from what's in front of you, the vendor's current documentation wins.
What a skill file actually is
Start with the prerequisite, because it decides whether the rest of this applies to you. A skill saved in a folder on your computer only works in a tool that reads that folder, like Claude Code or Codex running on your machine. Web chat in a browser only gets skills you upload to your account or install as a plugin. This article uses the folder version, so what you need is an agent running on your computer with access to a folder. Sorting that out is its own job, and it comes before this one.
With that in place, a skill is a folder with one file in it. The folder is named for the skill, and the file inside is called SKILL.md. That's the whole structure.
The top of that file is a short block fenced by a line of three dashes above and below it. Give it two lines, a name and a description, and you'll see files carrying more. The name matches the folder. The description is a sentence or two saying what the skill does and when to use it, and it's the one that matters most. Everything under the closing dashes is ordinary writing: headings, numbered steps, sentences.
The description is doing more work than it looks like. It's mainly what the assistant reads when it's deciding whether this is the right skill for what you just asked. A vague description means the skill sits there unused. Write it the way you'd write the label on a folder somebody else has to find in a hurry.
Where the folder goes depends on the host. On a personal setup, Claude Code looks in ~/.claude/skills/ and Codex looks in ~/.agents/skills/, one subfolder per skill. When you want to hand a set of them to somebody else there's a packaged form for that, called a plugin.
Claude Code and Codex both document support for this shape (Claude Code docs, Codex docs). That's what their documentation says. Nobody here tested it for you, and it stops short of any claim about a packaged thing running anywhere. If you're on something else, check its own docs before you copy a folder around.
Two honest things before you build it. A skill is a tool you pick up, and it runs when somebody runs it, so it fails the busy test the same way a faster manual step does. What keeps working while you're busy is the decisions inside the file, because they've stopped living in your head.
And this file is a different animal from the two you may already keep. A standing rules file is written for a person to read. A header at the top of a prompt is a label you write for yourself. This one gets read by a host when you ask for the job it names, and you prove it with a test whose answer you wrote down first. That last part is what the other two don't have.
Start from the run that already worked
Start from the last time you got a good answer. A blank file is a much harder morning.
If you've never gotten one, run this once first, on made-up numbers, so you have something to cut down. It's four sentences and it's deliberately worse than the file you'll end up with.
Here is a list of transactions sitting in Uncategorized Expense for one month
at a small landscaping business. For each one, tell me whether I can code it
now, whether I have to ask the owner, or whether I need a receipt first.
Give me one sentence of reasoning per transaction. Don't propose journal
entries.
[paste the transactions here]Now read what you typed, looking for four things you decided while you were typing. You made all four. You've just never written them down.
Here's the June run on the made-up landscaping client, in one line: you pasted four transactions totaling $1,284.50 out of Uncategorized Expense and asked which ones you could code and which ones needed the owner. Buried in that request were the four decisions. The full June review, all three problems, is in Produce a month-end review packet from your trial balance, with AI assistance.
The four decisions that turn a prompt into a reusable skill
Scope. What this looks at, and everything it leaves alone. The made-up June trial balance also has a $312.00 bank reconciliation difference from a vendor payment recorded twice, and a $950.00 owner draw coded to Repairs & Maintenance. Both are real problems in the invented file. Neither is this skill's job. Write that down, because a skill that wanders is a skill you stop believing.
The exception rule. What counts as needing a human. Here it's three buckets: code it now, ask the owner, need a receipt. Three is enough. The bucket names go in the file so every month's answer comes back in the same three piles.
The output shape. What the answer has to look like before you can use it. Three headed lists, a date and an amount and one sentence of reasoning under each transaction, and a total per bucket that adds back to the balance you handed it. That last part is the check. If the totals come up short, something got dropped or invented, and one glance at that line tells you so.
The stop condition. When it should refuse. If a transaction fits two buckets, it goes in the ask pile with a reason. If the totals come up short, it says so and stops there, with the gap named.
Those four are what the month-end issue called the decisions you keep re-making, moved out of your head and into a file that something else can read.
Test it before you trust it
Write the answers first. This is the part people skip and it's the part that makes the difference between a file you keep and a file you quietly stop opening.
Three cases, all built on the made-up client so nothing real is anywhere near it.
The normal month is the made-up June sweep: four transactions, $1,284.50, three buckets, totals that add back. Watch the lane it stays in. If it mentions the invented $312.00 reconciliation difference or the invented $950.00 in Repairs & Maintenance, it failed, even though both observations are correct. You didn't ask.
The clean month is a month where nothing is uncategorized. The right answer is a sentence saying there's nothing to sort, and a stop. A skill that finds work in an empty month will find work in a real one.
The wrong file is the made-up client's May trial balance handed over while the request says June. The right answer is that the period doesn't match. This one catches the failure that costs the most, because a confident answer about the wrong month reads exactly like a confident answer about the right one.
Run all three the day you write the file, then run them again any time you change it.
Then the standing rule, which survives however well the tests go. Check every line against the transaction it came from, side by side, before you agree with it. That check is the work. Budget the same minutes for it you'd budget for reading a bank feed yourself, because that is what you are doing.
What it costs to keep, and when to stop building
Every time you turn a prompt into a reusable skill you're signing up for a small standing cost, so it's worth knowing the size of it before you build the second one.
Budget an afternoon for the first one, and here is where it goes: about an hour on the file itself, and the rest on settling the rules you have been re-deciding from memory. That second part is the argument you were going to have eventually anyway.
Then budget ten minutes a month. Here's what the ten minutes buys, so you can check the number for yourself: re-run the three test cases, and write one change-log line if anything moved. Things move for four reasons, and you'll recognize the first three straight away: you added an account, a client changed how they do something, or the host changed how it reads the file. The fourth one catches people out. The model can behave differently under the same words than it did last month. That's the reason the test cases earn their place.
Do the arithmetic before you build the second one. This is the decision the second half of this article exists for. Ten minutes a skill a month, times however many you keep. One is nothing. Six is an hour. Twelve is two hours a month you have to find, which is a real thing to spend if you're the person trying to buy back capacity.
Three things tell you you've crossed the line. You open the folder and can't remember what half of them do. Two of them disagree and you don't know which is current. Somebody asks which one to run for a client and you have to go read both.
So here's the split I'd make, and you can weigh it however you want given what I do for a living. The skills worth keeping yourself are the ones holding your firm's own decisions: your fuel-station threshold, your transfer rule, the client whose books need one extra step. Nobody can sell you those, because they're yours and you're the only one who knows when they change. The generic ones, the ones that would read identically at any firm in the country, are where somebody else keeping them current starts to look like a fair trade.
That's a decision rule. The answer it gives you depends on how many you're running and how much of your own judgment is sitting in them.
Do this week
Pick the smallest step in your monthly review that you re-explain every time. Save the file in the setup pack, replace the bracketed rules with two of your own, and run the three test cases on a made-up set of numbers, not a client's.
If you only have twenty minutes, do the front matter and the scope section. A file with a good name, a clear description and an honest scope is already better than typing it again next month.
One question
So: which line in your file did you have to argue with yourself about? One line, please, and leave the rest of the file where it is. Send it with the rule it replaced.
The setup pack
Five files. Save the first one, then use the rest to keep it honest and to hand it over.
The skill file
Save this as SKILL.md inside a folder named uncategorized-sweep and the sweep is built. Every bracketed line is a rule your firm has already made and never wrote down, so put yours in before the first run.
---
name: uncategorized-sweep
description: Sort a month's Uncategorized Expense balance into code-it-now,
ask-the-owner, and need-a-receipt. Use when a trial balance shows a balance
in Uncategorized Expense for a client month under review.
---
# Uncategorized expense sweep
Read the pasted transaction list, sort it, and write nothing anywhere.
## Scope
Only transactions sitting in Uncategorized Expense for the month named in the
request. Ignore every other account, every other month, and every other
problem in the file, including anything that looks miscoded somewhere else.
Say nothing about them at all.
## What you need before you start
- The client name and the month, both stated in the request.
- A list of the uncategorized transactions with date, description, amount,
and which account paid them.
If either is missing, name the one that's missing and stop.
## Sort every transaction into exactly one bucket
1. CODE IT NOW. The description matches a rule below or a category this firm
has clearly already settled. Name the account and quote the rule you used.
2. ASK THE OWNER. Only the client knows what it was. Write the question you
would send them, in one sentence, in plain words.
3. NEED A RECEIPT. The category depends on a document nobody has yet.
## Rules this firm has already made
- Fuel stations under [your threshold] go to vehicle expense on the statement
line alone.
- Transfers to [your second account] are owner draws unless the owner says
otherwise in the same week.
- [one line per rule you catch yourself re-deciding]
## Output
Three headed lists in the order above. Under each transaction: the date, the
amount, and one sentence of reasoning. Then one line per bucket with its count
and dollar total, and a final line with all three added together, which has to
equal the Uncategorized Expense balance you were given.
## Stop conditions
- A transaction that fits two buckets goes in ASK THE OWNER, with the reason.
- If the three totals don't add up to the balance you were given, say so and
stop. Do not adjust anything to make it tie.
- Never propose a journal entry. Never say a transaction is fine.The three test cases
Made-up numbers throughout, from the invented landscaping client. Run these the day you write the file and again every time you change it.
CASE 1 The normal month
Give it Four made-up transactions out of Uncategorized Expense, $1,284.50
Expect Four transactions, three buckets, totals adding to $1,284.50
Expect No mention of the made-up $312.00 reconciliation difference
Expect No mention of the made-up $950.00 in Repairs & Maintenance
Fails if It fixes something you didn't ask about
CASE 2 The clean month
Give it The same invented client, a month with nothing uncategorized
Expect One sentence saying there's nothing to sort, then a stop
Fails if It finds work anyway
CASE 3 The wrong period
Give it The invented client's May trial balance, with June named in the ask
Expect It says the period doesn't match, and stops
Fails if It sorts May and calls it JuneThe check before you post anything
How do you know the answer in front of you is safe to act on? You work down these six. Every one of them is a thing that has gone wrong for somebody.
[ ] Every CODE IT NOW line names an account and quotes the rule it matched
[ ] Every amount matches the transaction it came from, opened side by side
[ ] The three bucket totals add back to the balance I handed it
[ ] Nothing in the answer is about something I didn't ask about
[ ] Nothing in ASK THE OWNER is a question I could have answered myself
[ ] I made every entry myself, after reading the reasoning, not beforeThe handoff note
The point of writing the rules down is that somebody else can run the step. Paste this above the skill file when you hand it over, filled in.
Run this on [client] for [month], from the uncategorized list only.
You decide: nothing. Sort, then bring me the three lists.
Escalate to me: anything in ASK THE OWNER, anything where the totals
don't add back, anything you'd have to guess at.
Bring back: the three lists, and the line where they add to the balance.
Nothing gets entered until I've read the reasoning.The change log
Keep it at the bottom of the skill file. These three lines are made up, like everything else here. One line per change, and name the test case that caught it, because a change nothing caught is a change you can't check.
02 Jul Added the fuel-station rule Kept asking about the same vendor none, spotted by hand
19 Jul Stop when the totals don't tie It nudged a number to balance Case 1
04 Aug Named the month in the scope line It sorted the wrong period Case 3The file will be shorter than you expect. Most of it is four sentences you were already saying out loud every month, finally written somewhere that something other than you can read them.