Building a Check Splitter, Prompt by Prompt

An earlier guide on this site, The Anatomy of a .skill File, took a skill apart: what goes in one, and what separates a skill you would run on a client file from one you would not. That guide was about the format. This one is an application of it: one skill, for one accountant's problem with check images, from the first message I typed to the last.

A skill is a procedure you have written down for Claude. It is a text file in plain English, written the way you would write it for a new hire who has never seen your process, with a label at the top that says when to use it. Once Claude has the file, it follows the procedure whenever the work in front of it matches the label.

The skill in this article splits the checks out of a bank statement.

It started with a call in September. An accountant at a bookkeeping firm we work with was describing one of his clients. This client's bank does not send check images on their own. They arrive inside the monthly statement PDF. The first few pages are an ordinary statement, and the rest are check images laid out in a grid, as many as sixty-nine to a page.

He needs every one of those checks in QuickBooks. So he screenshots a check, reads the payee off the picture, uploads it, and goes back for the next one. He called it one of the most painful accounts he has. It is not hard work, just very manual.

The skill does the screenshotting and the reading. You give Claude the statement PDF. It finds every check on every page, saves each one as its own image file, and reads the check number, date, payee and amount into a spreadsheet, one row per check, matched to its line on the statement.

I built it by typing to Claude: forty messages over three days, and no code. The rest of this article is those forty messages, in the order I typed them. With each one is what I was thinking when I typed it, and what came back.

One note before it starts. Every check and statement pictured in this article is synthetic. Claude drew them for testing. None is a real check, and the accountant's real statements were never used. The bank, business and payee names on them were generated, and any match to a real one is a coincidence. The other material used in testing, a bank's sample statement and research datasets of cheque images, is publicly available.

The first message

About two weeks after that call, I sat down to work on it. I did not remember the details, only that it was about checks and that the call had been recorded. My Claude is connected to my meeting notes, so it can read the transcripts.

Every message in this article is shown like that: what I typed, word for word, then what Claude did, then its reply. The real firm, its accountant and their client came up in my prompts, and their names are replaced with brackets. Every name that is shown, on a check or a statement, is made up. A […] marks where I cut the reply short. You will count more than forty boxes. The extra ones are short notes I sent back on a plan, and messages I sent and then took back. I say so where they come up.

I dictate most of what I send, which is why it reads like talking, and why the accountant's name came out wrong.

The "or something" was on purpose. I could have described the problem from memory, but Claude takes what you tell it at face value. If I had been specific about the wrong things, it would have gone to work on my description. So I told it where to look and left the rest loose.

I built this in Claude Code, which is Claude set up for building software. You probably use Claude in the browser, or in Cowork, Claude's app for longer jobs. Where I do something you cannot do there, I say what to do instead. Here, if your Claude is not connected to your notes, attach the transcript or paste it in.

The habit: when something is written down where Claude can read it, send Claude there. Do not summarize it from memory first.

A question about my own product

Legix is the accounting software I build. The Legix MCP is the connection that lets Claude work inside it, and an earlier guide covers what those are.

I asked about my own product because I did not remember. We build quickly, and once I have decided how a tool should work I stop carrying the details. Asking also made Claude read how the connection works, so it knew what it could do with it for the rest of the conversation.

The habit: ask Claude to go and look, even at something you could answer yourself. The looking is how it learns what it is working with.

Describing the real document

Claude had never seen the accountant's statement. I had.

The number is the part that mattered. "Multiple checks per page" could mean six. Sixty-nine means each check is the size of a thumbnail.

The habit: describe the real thing, and include the number.

A plan that was too big

Claude had offered a seven-part build. What I needed was one statement to test on that day.

Nothing in Claude's plan was wrong. It leans toward building more, and I needed one statement for one demo. If the simple version worked for the accountant, I might come back and build the rest.

Claude also did not know what already existed. QuickBooks exists. Legix exists. It does not know what you do not tell it.

All three warnings were real. None of them mattered for a first test file.

The habit: Claude does not know what you already have, or how much you need. Tell it, and cut the plan down to that.

Pulling every dataset

I sent the next two while Claude was still building the test files. It picks up a message like that at its next stopping point.

Clicking the link myself was quicker than answering the question.

The habit: some steps are yours to do.

As much variation as possible

Before the next message I switched on plan mode. In plan mode Claude does not build anything. It writes out the whole route and waits for me to approve it.

I picked all three kinds of check image, and 150+ files. Neither was the recommended answer.

The second and third kinds are public research datasets of cheque images. None of their images appear in this article or in its downloads. Every check pictured here is one Claude drew.

Claude answers one prompt at a time, with its best response for that moment. Left to that, a long build zigzags. By now I could see several steps coming, so I had it lay them out first. In the browser there is no plan mode. Say "plan this, don't start yet."

The recommended button is Claude's best guess from what it knows. What I knew is that real accounting documents are a mess: blurry checks, different kinds of checks, different formats. Give Claude clean test files and it builds for the clean case.

The habit: when you can see further than the next prompt, have it plan first.

Four rejections in four minutes

Claude wrote the plan and asked me to approve it. A plan can be sent back with a note, and Claude rewrites it. I sent this one back four times.

I approved the fifth version.

The first two notes are questions on purpose. Claude tends to assume you already know what you want, and often I do not know what the options are yet. "Should we" and "anything else" give it permission to go past what it thinks I know.

Then it had gone too far. The plan had started designing the skill, which did not exist yet. So the fourth note pulls it back.

A lot of working with Claude is this. Give it broad strokes, then cut, and keep cutting until the plan makes sense. You are marking the edges, so it knows where to go and where to stay.

The habit: open it wide first, then narrow it.

"Both"

Before it started building, Claude asked whether it could install a library that makes PDF pages with real, selectable text. It gave me two buttons: "Yes, install it (Recommended)" and "No, image-only". You do not have to pick a button. I typed this.

That comes from what I have seen with customers. A clean, sharp image is easy for most systems. What actually arrives is messy, and I was telling Claude what it was about to receive.

The habit: tell it how messy the real thing is.

Keeping the screenshots

Claude had sent me pictures of the test statements it made.

Then it asked whether to put the folder under version control, which keeps every past version of every file. The buttons were "Local git repo (Recommended)", "Git + private GitHub repo" and "No git, just files". I picked the second. It keeps a private copy online as well.

I save anything I might build on. If I make another skill this way, the pictures, the plan and the log are there to pull from. I wanted the history so I could always go back. And I wanted this project in a place of its own, so Claude is not reading unrelated files while it works here.

The habit: save what you might build on later.

"Ensure it's isolated"

A subagent is a second Claude that the first one starts. It begins with an empty memory and knows only what it is handed.

Claude never forgets what is in a conversation, and by now this one held the answer keys, the code, and how every test file was made. A Claude that has seen the answers cannot tell me how a fresh one will do. The accountant's Claude will have a PDF and nothing else, so the test got a PDF and nothing else.

In the browser, a new chat does the same job. It starts with only what you put in it.

The habit: test it with nothing in the window that the user will not have.

Harder test files

The next day.

The habit: when the first score is perfect, question the test.

"Did the agent not crop/zoom by itself?"

Claude's answer is accurate. It also rests on something it assumed and I never said. The accountant will not use the Legix MCP for this. He will upload the PDF straight into Claude.

"Crozsion" is the dictation again. Claude read it as "crop" and carried on.

I had not looked at how the test was run. I asked because small things are easier to read up close. That is true for a person, and it is probably true for Claude. A lot of how I work with it comes from asking how a person would do the same job.

A couple of hours of testing had been run against a limit the skill will never have.

The posting errors in that table were planted in a synthetic statement. No real account has them.

The habit: tell Claude what it will have in its hands.

An hour of zooming

About forty minutes later:

I said it then because it was in front of me. I could see it going through hundreds of checks one at a time. I also knew where the skill would end up. In the browser there is one Claude working in one lane. In Cowork or Claude Code it can hand pieces of the job to several at once.

One line in that reply says images "briefly came back as 'media removed', and it had to redo that work." The subagent's own note, which I did not see at the time, was blunter: "every image read came back as '[media removed: request limit]', and I wrote a first doc_65.json anyway, so its values were invented." It went back and reread every page once the images loaded.

I take Claude at its word most of the time. You build a sense for it, the way a senior accountant looking at a junior's work knows when something is off without checking every line, and then digs into that part.

The habit: say the constraint when you see it. Do not save it for later.

Twelve checks to an image

The habit: when it stops short, find out whether the problem is the reader or the material.

One word

That was the second "Proceed". There were four.

By now every report ended with a numbered list of what Claude would do next, and each time it was what I would have chosen. That is how I know it has the right context. I am not correcting anything, so one word is enough.

It only works because of the time spent earlier: setting the context, cutting the plan, looking at the results.

The skill was called check-statement-reader at this point. I renamed it later.

The habit: when its next step is the one you would pick, one word is enough.

Running it like an accountant would

Every test so far had been run by a subagent. A subagent is started by a Claude that knows everything we built, and that Claude writes its instructions. You are relying on Claude to keep things from itself.

A new chat that I open myself has none of that. It has the skill, a PDF and one plain request, which is what the accountant will have.

The four statements in the kit are synthetic. Every name, account number, signature and check on them is made up.

The habit: the real test is a fresh session holding only what the user will have.

A zip with no words

Statement A, in an ordinary Claude chat. I downloaded what it produced and handed it back.

The habit: handing back the output is a prompt too.

Statement B, sent three times

The zip I downloaded for B had only three of its thirty images in it.

I rewound. In Claude Code a rewind goes back to an earlier point in the conversation, and the message you had sent is gone as if you never sent it. In the browser, editing an earlier message does the same thing, where that is available. I sent B again, this time with the text of the chat reply pasted in.

That one was my mistake. The chat had shown only a few of the files. The rest were in the files list, not in the chat, and I had not looked there. All thirty were fine. I rewound again and sent the complete zip.

There was no other session. A rewind in Claude Code also puts the files back the way they were at that point, so the fix Claude made before I rewound was undone on disk. Claude cannot see a rewind. It saw files that had changed and guessed at the reason. It repeated that warning four more times before the end.

I rewind when the setup of a message was wrong, or when the conversation has picked up something I do not want it carrying forward.

The habit: when a message went wrong, go back and send a better one. Do not stack a correction on top of it. And know that going back can undo more than the message.

36 of 37

Statement C was the hard one: sixty-two check images, more than half of them blurred on purpose.

The rule it put at the top of the skill, in its words: "every value must be read off the check's own image. If the amount can't be read, the check is unverified, even when its number is readable."

Claude changed the skill without being asked, and that was fine with me. By this point it knew the goal well enough to make that call. I had not expected it, and I was not surprised.

The habit: a rule that must hold goes at the top of the skill, with its reason.

Regular chat, or Cowork

I rewound and asked again, with one more line.

I work in Claude Code. Most accountants do not. I did not know offhand what Cowork or the browser could do, and I did not want to build something that only runs where I work.

The habit: check the place your user works, not the place you do.

Seventy unverified

Statement D: 204 checks, seventy of them blurred, and the rewritten skill.

The first rows of the spreadsheet it produced, with some columns left out. The payees are made-up names on a synthetic statement:

check_number  date        payee                  amount   status
2633          2026-06-08  Nicole Brennan         4837.07  matched
2524          2026-06-1?  Lakeside Lab Services  1658.17  matched
2496          2026-06-24  Robert Mehta           727.0    matched
                                                          unverified
2480          2026-06-15  Linda Delacroix        544.62   matched

Claude asked three questions and I answered two. It suggested three next steps and I took one. Over the three days it asked plenty that I never answered: how long A took, whether to keep B's extra observations, whether to run C again.

Its questions and suggestions are its guesses at where to go next. I answer the ones that point where I want to go.

The habit: you do not owe it an answer to every question.

Writing it down

I was already building the skill for a customer. I asked for the guide because the skill is not the hard part for most people. The hard part is a new way of working: handing a job over, breaking it into pieces, checking what comes back, and marking where the edges are.

I have built hundreds of these, and what I know about it came from doing it. Most of what is written about prompting stays at broad strokes. I wanted one build written down message by message, for someone who knows the work the skill does.

The message-by-message document Claude wrote from that request is what this article was built from.

The habits, together

Each section above ends on a habit. Here they are in one place, in the order I would use them on a new build.

Load the context. Claude starts with nothing about your firm, your client or your tools.

• When something is written down where Claude can read it, send Claude there. (The first message)
• Ask it to go and look, even at something you could answer yourself. (A question about my own product)
• Describe the real thing, and include the number. (Describing the real document)
• Tell it how messy the real thing is. ("Both")
• Tell it what it will have in its hands. ("Did the agent not crop/zoom by itself?")
• Say the constraint when you see it. (An hour of zooming)
• Check the place your user works, not the place you do. (Regular chat, or Cowork)

Open it wide. Let it show you options you had not thought of.

• When you can see further than the next prompt, have it plan first. (As much variation as possible)
• Ask "should we" and "anything else" before you decide. (Four rejections in four minutes)

Set the edges. Then cut.

• Claude does not know what you already have, or how much you need. Tell it, and cut the plan down to that. (A plan that was too big)
• A rule that must hold goes at the top of the skill, with its reason. (36 of 37)
• You do not owe it an answer to every question. (Seventy unverified)
• Some steps are yours to do. (Pulling every dataset)

Let it run. Once the context is right, get out of the way.

• When its next step is the one you would pick, one word is enough. (One word)
• Handing back the output is a prompt too. (A zip with no words)
• Save what you might build on later. (Keeping the screenshots)

Test it fresh. The test only counts if it looks like the real use.

• Test it with nothing in the window that the user will not have. ("Ensure it's isolated")
• When the first score is perfect, question the test. (Harder test files)
• When it stops short, find out whether the problem is the reader or the material. (Twelve checks to an image)
• The real test is a fresh session holding only what the user will have. (Running it like an accountant would)
• When a message went wrong, go back and send a better one. (Statement B, sent three times)

Two things sit under all of these. They are what I would tell myself two years ago.

Claude knows more than I do about almost anything I ask it to build. What it does not have is my context, and it does not know where the edges are. Giving it those two things is my whole job.

And my wording does not have to be precise. I dictate. I ramble. I say "or something". What has to be clear is the direction I am going and what I do not want. The fastest way I know to get there is to let Claude ask me questions and offer options, and to answer each one with why or why not.

Run it yourself

The skill and four test statements are in the downloads below. The statements are synthetic. No real check, account, payee or signature is on them.

1. In Claude, turn on code execution and file creation, under Settings and then Capabilities.
2. Add the skill: Customize, then Skills, then the plus button, then "Upload a skill". Choose check-splitter.skill.
3. Start a new chat and attach one statement. Use one statement per chat.
4. Type what an accountant would type: "Here's a client's bank statement with the check images. Can you split out the checks, match them to the statement, and tell me anything I need to look at?"
5. Check the result against the table below. Did it find the posting errors, and did it leave the blurred checks blank? For a line-by-line score, open a second chat, give it the spreadsheet from the first chat and that statement's answer key, and ask it to list every difference. Keep the answer keys out of the chat you are testing in.

Two things differ from what you read above. The skill in the download is a later version than the one at the end of this build. It reads checks the same way and hands back more: one zip with a review page, the statement marked up, and an Excel workbook. And statement B was made again after the deposit-slip fix, so its slips now add up.

Before you put a real client's statement into any chat, check it against your firm's policy on client data.

The downloads

check-splitter. The skill. A procedure, two reference documents and the programs it runs. Open SKILL.md first. The rule about never recording a value it did not read off the check is near the top, under "The one rule that matters most".

The build guide. The long write-up Claude produced when I asked for it in Writing it down: the method, stage by stage, with each correction explained.

The message-by-message companion. Every prompt, with how Claude read it and why.

The test kit and its answer keys. Four synthetic statements and the skill in one zip. The answers are in another.

Sources

The build. Every quoted message comes from the recorded conversation, 23 to 25 September 2026, in Claude Code. The real firm, its accountant and their client came up in my prompts, and their names are replaced with brackets. Every name that is shown, on a check or a statement, is made up. Range dashes in Claude's replies are written as hyphens, and nothing else in a quote is changed. The numbers in Claude's replies are its own reports at the time.

Claude's features, as I checked them on 25 September 2026:

• Use skills in Claude and How to create custom skills, for adding a skill and what it needs switched on.
• Get started with Claude Cowork, for sub-agents in Cowork.
• Claude Cowork and chat are one Claude. Chat and Cowork are being merged, starting with Pro and Max plans, so the names on your screen may not match the ones here.

Two things in this article are what I saw and are not documented anywhere I could find: the limit on how many images one conversation can hold, and where the browser lists the files a chat produces. If Anthropic's documentation disagrees with this article, believe the documentation.

Test material. Every check and statement pictured in this article, and every statement in the kit, was drawn by a program Claude wrote. No real check, account, signature or client appears in them. The bank, business and payee names were generated, and any match to a real bank, business or person is a coincidence.

Everything else that went into the test statements is publicly available: Impact Bank's sample statement, published on the bank's own site; the synthetic cheque images on Hugging Face, under an Apache 2.0 licence; and the IDRBT Cheque Image Dataset, a research dataset of scanned cheques. Files built from those are in the wider test set only. None is shown or included here. Claude also downloaded the SSBI check dataset for reference. Its licence is non-commercial, and it was not used in any test file.

The earlier guides. The Anatomy of a .skill File and MCPs for Accounting Firms.

Josh Hsu · Legix · published Oct 2026