# The build, message by message

_Companion to `BUILD-GUIDE.md`. Every prompt Josh wrote during the build, quoted exactly (typos
included), followed by what Claude understood it to mean, why it read it that way, and what it
did. Stage numbers refer to Part 3 of the main guide._

_Corrected against the session transcript on the evening of 2026-09-25: two quotes fixed (#12, #22),
placeholders made consistent, #31 and #33 rewritten (the "other session" was a rewind of this same
conversation), #32's count, #38's third question, and prompts 41 and 42 added._

_Prompts 43–53 (output polish and the workbook, skill v0.6–v0.7, Stages 16–17) added 2026-09-26._

Why this document exists: the main guide explains the reasoning after the fact. This one shows
the reasoning as it happened, in the actual exchange. Most of the prompts are short. What made
them work was the context each one landed in, and that's the thing worth learning: a two-word
prompt like "Proceed" carries a whole plan when the previous turn laid one out and ended with a
concrete proposal. Where Claude read a prompt more broadly or narrowly than intended, that's
noted too, because the corrections are half the lesson.

Conventions: **Prompt** is verbatim, except that client and customer names are replaced with
bracketed placeholders like [the customer]. **Prompt** is otherwise untouched, typos included. **Read as** is the interpretation. **Why** is the signal in
the words or context that produced that reading. **Did** is what followed. **Note** is a lesson or
a misread.

---

## Day 1: from a remark on a call to a corpus

### 1

> Okay, Check the latest call from [the customer's accountant] we had over a transcript. I think he was talking about a check splitter or something. He was having a problem with one of his clients where he had to take a bunch of information and be able to split the check or something like that.

**Read as.** Find the most recent meeting transcript with the person named (the name came
through garbled), locate the part about splitting checks, and summarize what the problem actually was.

**Why.** "Check the latest call … over a transcript" points at the meeting-notes tool.
The garbled word was almost certainly a person's name, and the prompt was vague ("or something",
"something like that") twice, so the job was to recover the facts, not to confirm a guess. "Split the check"
could mean splitting a bill or splitting an image; the summary had to settle which.

**Did.** Searched meeting notes, found the 2026-09-10 sync with the customer's accountant, pulled the
transcript, and reported the actual problem: bank statements with check images embedded, up to
69 per page, screenshotted one at a time. Also surfaced the customer's privacy concern and the
open promise to test on his client. (Stage 1.)

**Note.** The first useful act was disambiguation: "check splitter" turned out to be a
check-_image_ splitter. Everything after depended on getting that right.

### 2

> Do we have an example we could test this on? Either through the legix mcp to get documents or find an online one one as a sample?
>
> Also, remind me again, can the legix mcp read/upload documents?

**Read as.** Two questions. Find a test file, from inside the product's data or from the web.
And a factual check on the product's connector: read only, or upload too?

**Why.** "Either … or" gave two search channels explicitly. "Remind me again" signalled a factual
question with a definite answer, to be looked up, not reasoned about.

**Did.** Read the connector's source to answer precisely (it can list and read documents, one
page at a time, at a fixed size; it cannot upload). Started a subagent to scan every client's
documents, and searched the web in parallel. (Stage 2.)

**Note.** Reading the source rather than recalling was right: the exact answer (≤1568px pages,
no upload) became load-bearing two days later.

### 3

> Yeah, could you give me the URLs for the web pages those links are on, not the actual download links themselves?

**Read as.** Replace the direct-download links with the pages that host them.

**Why.** Explicit. The implied reason: a person wants to see licensing and context before
downloading anything, and a bare file link hides both.

**Did.** Found and gave the hosting pages (the bank's e-statement disclosure page, the dataset
pages, the arXiv pages).

### 4

> The problem with the Impact Bank electronic disclosure page: the sample statement is just a bank statement. What I need is a bank statement, the first few pages, but then the rest of the pages are all these multiple checks per page. Could be 69 checks on a single page. Does that make sense?

**Read as.** A precise specification of the target document: statement pages first, then pages
that are grids of many small check images. The sample found doesn't have the second part.

**Why.** "What I need is …" followed by a concrete description. "69 checks on a single page"
repeated the number from the call, so density was a requirement, not a detail. "Does that make
sense?" invited confirmation of understanding, not a design.

**Did.** Confirmed, did two more targeted searches (nothing public matches; such pages carry
signatures and account numbers), and laid out three realistic routes: real data from the
product, a real file from the customer, or build a synthetic one. Recommended building now and
asking the customer in parallel. (Stage 2 → 3.)

### 5

> 3. three is an interesting idea. How would you approach this?

**Read as.** Explain the synthetic-file approach in enough detail to judge it. Not "do it".

**Why.** "How would you approach this?" asks for a method. Nothing said "go".

**Did.** Proposed a seven-part approach: generate a ledger first so the answer key is free,
render statement pages, draw US checks rather than reuse the Indian ones, lay out grid pages at
several densities, write the answer key alongside, define difficulty levels, and score against
the key.

**Note.** This proposal was bigger than what Josh wanted next (see 6). Proposing the full shape
was still useful: most of it came back a day later, once the small version had shown its limits.

### 6

> Yeah, I don't necessarily need a whole ledger system. I'm wondering if we can just take that PDF that was given to us (that Impact Bank sample statement), and then maybe we pull some of those random synthetic check images. We put 9 of them on each page, and we add 4 additional pages of it. Does that make sense? And then we could have various variations:
>
> - Easy: 1 statement, 6 checks per page
> - Medium: 20 per page
> - Hard: 69 per page
>
> And then have multiple variants or variations for this. Thoughts?

**Read as.** Scale the plan down to the smallest useful thing: existing sample statement plus
appended grid pages of existing check images, three densities, several seeds each. Keep the
answer key, because it's cheap when the script places the images.

**Why.** "I don't necessarily need a whole ledger system" rejected the heavy part by name. The
rest was a concrete recipe. "Thoughts?" left room to flag consequences.

**Did.** Agreed, and flagged three consequences before building: the appended checks wouldn't
match the statement (so only splitting could be tested), the images are Indian cheques (fine for
finding, misleading for reading), and the "9 per page" versus the 6/20/69 levels. Asked to
confirm the dataset download. (Stage 3.)

**Note.** The right response to "keep it small" is to keep it small _and say what the small
version can't measure_. That sentence is what made Stage 4 necessary rather than surprising.

### 7

> 1. That's fine. We can change things up/make it match. Not the most important thing.
> 2. Also fine
> 3. THat's fine
>
> And maybe we create directory called building-accounting-skills/
>
> And create a new folder for this

**Read as.** All three caveats accepted; matching can come later. Create a new top-level
directory with that name, and a project folder inside it for this work.

**Why.** Numbered replies to the three numbered caveats. The directory name was given exactly.

**Did.** Created `building-accounting-skills/check-statement-fixtures/`, downloaded the check
images, wrote the first generator, produced nine files with answer keys, and looked at pages of
each level before reporting.

### 8 (sent while the previous work was running)

> What's in the full dataset?

**Read as.** Describe the Hugging Face dataset's full contents: splits, counts, banks, license.

**Why.** "Full" contrasted with the 60 images just downloaded from the two smaller splits.

**Did.** Read the dataset's README and reported its structure (295 images, four banks, the
cut-paste method, Apache 2.0).

### 9 (sent while work was running; the earlier links list was pasted back)

> I'm leaning towards actually pulling everything just as future reference. I don't know, we might be able to use this and inventory all of it.

**Read as.** Download every dataset in the list, not just the ones in use, and write an
inventory with sizes and licenses.

**Why.** "Pulling everything" plus "inventory all of it". The pasted list defined "everything".
"Future reference" meant keep, not necessarily use.

**Did.** Checked each source's size and hosting first, then downloaded the ones that allowed it
in the background, and wrote `INVENTORY.md` with license notes, including that one set is
non-commercial and one blocked scripted downloads. (Stage 2.)

### 10

> Did you get the "IDRBT" one?

**Read as.** A status check on the one dataset the report said couldn't be fetched by script.

**Did.** Answered no, explained the 403, described what a browser download would involve, and
asked whether to do it that way.

### 11

> I just downloaded it in the downloads folder

**Read as.** The user did the browser download; file it.

**Did.** Found it still downloading (a `.crdownload` file), waited for it to finish, moved it into
the datasets folder, checked the contents (112 TIFFs), updated the inventory.

**Note.** Checking that the download had _finished_ before moving it is the small kind of care
that avoids a corrupt archive nobody notices for a week.

### 12

> Okay, now that we have these things, maybe we should create 3-5 individual PDF variants of these bank statements. What are my options? How do we approach this?

**Read as.** Design question, again not "go": what could vary between 3–5 test statements, and
what's the recommended combination.

**Why.** "What are my options" asks for choices; "how do we approach this" asks for a
recommendation among them.

**Did.** Laid out four choices (statement pages, check-image source, page layout, whether checks
match the statement), five layouts each testing something different, a recommendation, and a
cheaper alternative. Ended with a question about 3 versus 5.

### 13

> I think we should have as much variation as possible, right, because we'll be using these to build out the skill itself. We want to make sure we have enough variety here. Any suggestions?

**Read as.** Optimize for variety, not for a small hand-picked set, because the files will be
the development set for a skill. This is now a real build; plan it properly.

**Why.** "As much variation as possible" and the stated reason ("build out the skill itself")
changed the goal from a demo set to a corpus. That justified switching to planning mode and
asking the two questions that would set the scope (image sources; corpus size).

**Did.** Entered plan mode. Asked two questions with recommended defaults; the answers were:

> Drawn US checks (Recommended), HF synthetic Indian cheques, IDRBT real scans

> ~150+ files

Wrote the plan: variation axes, drawn US checks with a small per-file transaction list so
checks match statements, the answer-key schema, named scenarios plus random combinations, a
held-out split, a validator, contact sheets, a light scorer. (Stage 4.)

### 14 (four replies during plan review)

> Should we also precreate an answer key as well?

**Read as.** Beyond the generator's internal record, produce an answer key in the exact shape a
future skill's output should take, and a scorer that compares the two.

**Did.** Added `expected.json` in the skill's output format and `score.py` with named metrics
and a self-test to the plan.

> anything else we should consider as part of this setup?

**Read as.** Look for gaps before committing.

**Did.** Added eight items: the connector's ≤1568px page limit as the biggest risk, a
real-world test set from the product's own PDFs, what the skill's output _is_, other input types
(TIFF, JPG, encrypted PDF), scale tests, pinning the held-out set with hashes, which bank layouts
to model, and backup.

> Why is [the customer's accountant] being mentioned?

**Read as.** The plan document shouldn't name the customer or his client. Keep it general.

**Why.** A one-line question about a name is almost always "remove it".

**Did.** Replaced every reference to the customer, the client and the scenario name that carried
it with neutral wording.

**Note.** A plan file outlives the conversation and gets shared. Names that were fine in chat
aren't fine in the artifact.

> Remember we're not creating the skill at all yet. We're just creating the initial materials and a very light way to evaluate this

**Read as.** The plan had grown toward skill design (output contract, MCP changes, scale
tests). Cut back to: files, answer keys, a light scorer.

**Why.** "Remember" flags a drift from an earlier boundary. "Very light way to evaluate" set the
scorer's ambition explicitly.

**Did.** Rewrote the plan to that scope; moved the skill-design items to a "notes for later"
section. Plan approved. (End of Stage 4.)

**Note.** This is the most important correction of day one. Claude's instinct was to design the
whole system; the owner's was to build the measuring instrument first. The second was right, and
the guide's method is built on it.

### 15 (during the build)

> Both. statements might have selectable text, but the checks are _usually_ image files scanned in

**Read as.** Install the PDF library so statement pages can carry a real text layer, _and_
render check pages as images, because that's how real statements arrive.

**Why.** "Both" answered the yes/no; the second sentence was a domain fact about real documents,
stated to shape the design.

**Did.** Built two rendering paths: reportlab for digital statement pages, Pillow for anything
scanned; check pages are always images. (Stage 5.) This one sentence is why the corpus has the
"digital vs. scanned" axis at all.

### 16

> Those screenshots are great. Let's save those somewhere to just keep. A lot of the stuff we're creating I'd like to save so we can track these

**Read as.** Two things: keep the contact-sheet images in the project, not in scratch; and more
generally, start tracking artifacts over time.

**Why.** "Save those somewhere to just keep" is specific; "a lot of the stuff … track these"
generalizes it to a habit.

**Did.** Saved the sheets into a dated `docs/contact-sheets/` folder, wrote a script to regenerate
them, saved the plan, started `docs/LOG.md`, then asked whether to put the whole folder under
version control. The answers:

> Git + private GitHub repo

> legix-ai/building-accounting-skills

Created the repo, committed code, keys and docs, ignored the regenerable 2.5 GB, pushed.

**Note.** The log started here, on request. It's the reason the main guide could be written.

### 17

> Okay now what's next?

**Read as.** Recommend the next step, in order, with reasons.

**Did.** Proposed: a no-skill baseline first (because it would tell us where things break before
any design), then decide how a skill gets a closer look at checks, then a real-world test set,
then close the loop with the customer, then design. Recommended starting with the baseline.

### 18

> 1. Could you do this isolated with a subagent? Ensure it's isolated?

**Read as.** Run the baseline in a subagent that cannot see the answers, the generator, or even
the file names, and prove the isolation.

**Why.** "Isolated" twice, with "ensure": the emphasis was on the test being clean, not merely
delegated.

**Did.** Designed the blind protocol: renamed files in scratch sandboxes, the mapping kept
elsewhere, boxes as page fractions, a prompt restricting tools, and a transcript audit afterwards.
Ran three subagents; audited; scored. (Stages 7–8.)

**Note.** "Ensure it's isolated" produced the audit script. Without that phrase there might
have been a sandbox and no proof.

### 19

> Okay, let's proceed with the next test then

**Read as.** Run the test proposed at the end of the previous report: add scenarios that remove
the shortcuts, then rerun the same blind baseline.

**Why.** "The next test" referred to the specific next step the previous message had
recommended. Short approvals inherit their content from the last proposal.

**Did.** Added six hard scenarios, made generation byte-reproducible (which the regeneration
check demanded), reran the blind baseline on seven files. (Stage 9.)

### 20

> Can you link to or open up one of those really, really hard ones, the 69 per page?

**Read as.** Show the actual dense file, and say what's hidden in it.

**Did.** Opened the PDF in the side panel and listed its seven planted traps (four posting
errors, three checks not on the statement) with pages and amounts.

### 21

> Did the agent not crop/zoom by itself?

**Read as.** A question about the subagent's behaviour on the dense file, and implicitly about
whether the test was fair.

**Why.** "By itself" asks whether it had the option and didn't take it.

**Did.** Explained that it had no crop tool (by design of the blind setup), and that cropping the
first-glance image wouldn't have helped anyway because the detail wasn't in it; the detail was in
the PDF. Proposed the next test: give it the full PDF plus a crop tool.

**Note.** This question is the hinge of the project. It led directly to 22.

### 22

> A few things to note here:
>
> 1. Yes, we definitely should note to increase the MCP's capabilities for Legix at some point, so Crozsion tool may help down the road. Second thing is that, to start, the thing that we're going to be building later, not now, is that we won't actually leverage the Legix MCP per se because we don't have a get document tool. These types of statements don't actually show up in the Legix MCP. It usually shows up in an external system that one of the accountants actually just uploads manually to Claude. Claude, using this particular skill, let's say, would have access to the full document itself. There would need to be instructions to Claude, or a Python something, or anything that allows Claude to be bundled with the skill to kind of zoom in if it chooses to or needs to. Does that make sense? This is separate from the Legix MCP and its limitations.

**Read as.** A correction of the environment assumption. The skill runs on a PDF an accountant
uploads directly to Claude, so it has the whole file and can bundle its own zoom script. The
connector's limits don't apply. Noting a connector improvement for later is a separate item.

**Why.** "We won't actually leverage the Legix MCP" and "would have access to the full document
itself" are unambiguous. "A Python something … bundled with the skill" named the mechanism.
"Crozsion" was read as a transcription of "cross-section"/"crop", i.e. a crop tool for the
connector.

**Did.** Recorded the decision and its consequences in the log (the page-image baselines measured
a floor, not the ceiling), logged the connector item separately, and proposed the zoom test with
the full PDF. (Stage 10.)

**Note.** Two baselines, a couple of hours of work, had been measured against the wrong
ceiling. The lesson went into the
method as step 2: settle the environment before the first measurement.

### 23

> Proceed

**Read as.** Build the zoom script and run the blind zoom test as proposed.

**Did.** Wrote `zoom.py` (info, text, crop, tiles), verified it on the dense file, ran three
blind subagents with the full PDFs and the tool. (Stage 11.)

### 24

> Still running?

**Read as.** Status check on the last subagent, which had been going far longer than the others.

**Did.** Checked its output folder and crop count, confirmed it was alive and on the dense file,
noted the time already spent, and flagged that the time itself was a finding.

### 25

> ok let me know when it's done
>
> one note for later, for the sake of speed, we'll probably want to think about how the skill can parallelize this process so it can go faster because one someone first runs the skill it won't be through a sub agent but the main claude

**Read as.** Two things: report when the run finishes; and a design constraint to record now,
act on later: the skill will first run in the main session, not a subagent, so it can't fan out.
Speed has to come from somewhere else.

**Why.** "One note for later" marks it as a constraint to log, not a task. The reasoning
("won't be through a sub agent but the main claude") was the constraint itself.

**Did.** Logged it with four options (batch the zoom, triage first, parallel calls in one turn,
subagents only where available). Reported the run when it ended: zoom solved reading, but
one-at-a-time took 63 minutes and hit the image limit. The constraint had just been demonstrated.

**Note.** All four options ended up in the skill. Constraints stated early, even "for later",
tend to become the design.

### 26

> Proceed

**Read as.** Do the proposed next step: batched sheets plus a triage workflow, rerun the dense
file.

**Did.** Built `detect` and `sheet`, wrote the triage prompt, ran one blind subagent. Nine minutes,
all four posting errors, no false alarms. (Stage 12.)

### 27

> Proceed

**Read as.** Do the three proposed steps in order: legibility flag, detector fixes, run the
workflow across the hard files plus some originals.

**Did.** Added the legibility field and calibrated it, reworked the detector, wrote workflow v0
and ran it blind on 13 files. (Stage 13.)

### 28

> Proceed

**Read as.** The three proposed steps: workflow v1, the held-out run, package as a skill.

**Did.** Wrote v1, ran five blind subagents on 18 held-out files, built the skill package with
`export`, and updated it from the held-out findings (image budget, fax warning). (Stage 14.)

**Note.** Four consecutive "Proceed"s worked because each preceding report ended with a numbered,
concrete proposal and its expected outcome. That's the pattern: make the next step explicit
enough that a one-word answer is unambiguous.

### 29

> show me the held-out results
>
> "Run it once in the main Claude session" -> Could you give me a few sample PDFs I'll open up a new claude session, upload the skill/files and run it.

**Read as.** Two things: a per-file view of the held-out scores; and a test kit for a manual run
by the owner in a fresh session, where the skill will be used the way an accountant would use it.

**Why.** The quoted phrase was Claude's own suggestion, taken up. "A few sample PDFs" plus "upload
the skill/files" defined the kit.

**Did.** Printed the per-file table. Built a kit of four held-out statements renamed `A`–`D` so the
names gave nothing away, with a README (kept out of the test session) saying what each contains
and what good looks like, and the packaged skill. (Stage 15.)

### 30

> @"~/Downloads/files_statement_A_output.zip" this was the output

**Read as.** Score this against A's answer key.

**Did.** Unpacked, scored every field, opened a few exported images to confirm they matched
their names. Perfect. Asked for the two things the zip couldn't contain: run time and the chat
reply's wording.

### 31

> @"~/Downloads/files_statement_B_output.zip"
> this was the output

**Read as.** Same, for B.

**Did.** The repo already held two commits: one scoring B from the first, partial download (3 of
30 images), and one fixing a generator bug (deposit slips itemizing exactly 80% of their total)
found from B's chat reply. Both came from earlier branches of this same conversation: Josh had
rewound it twice, once after the partial zip and once after pasting the chat reply along with the
question "Did it split it properly? Part of the main goal of the skill was to split it into
individual things". Claude couldn't see the rewinds. It read the two commits as another session's
work, and read the working tree, where the rewind had restored the pre-fix `checks.py`, as
"uncommitted edits that undo the fix", which it flagged and left alone. This zip was complete:
every referenced image was present and every back matched its front.

**Note.** Two lessons. "Check that everything the output references is present" entered the
heuristics here. And a rewind in Claude Code restores the files as well as the conversation: the
fix stayed in git but vanished from the working tree, and the surviving branch blamed a colleague
who didn't exist. The file stayed reverted until the article work found it, three hours later.

### 32

> @"~/Downloads/files_statement_C_output.zip"
> This was the file output

**Read as.** Same, for C, the hard mix.

**Did.** Scored it: legible checks perfect, but 36 of the 37 blurred checks had been filled in with
guessed data (one was marked unverified), two payees invented. Opened one export to confirm it was unreadable blur. Wrote the
finding, then changed the skill before the next run (v0.3: the one rule at the top, a self-check,
unverified export naming). (Stage 15.)

**Note.** The biggest single finding of the project came from a routine "score this" prompt.
The scoring habit is what caught it; the prompt didn't have to ask for anything special.

### 33

> I'm curious, if run in regular claude web, it can't spin sub agents to parallelize, right?
>
> Versus cowork? Can cowork spin up sub agents?

**Read as.** A factual question about environments, with an implied design question: should the
skill use subagents where they exist?

**Did.** The first version of this prompt, without the Cowork line, got an answer from memory
("as far as I know"). Josh rewound and re-sent it with the second question; that time Claude
checked current documentation rather than answering from memory (plain chat: no; Cowork: yes,
at Claude's discretion). Proposed an optional delegation path with the two design choices
it would need.

### 34

> yes, add the delegation path

**Did.** Added the delegation section, the worker brief, and `zoom.py merge`; tested merge on
sample data. v0.4.

### 35

> @"~/Downloads/files_statement_D_output.zip"

**Read as.** Score D. No words needed; the pattern was established.

**Did.** Scored it: 70 blurred checks all marked unverified, none filled in; legible checks
essentially perfect; the remaining misses were small-print date and payee misreads. Opened one
to confirm. Asked which environment and how long.

### 36

> Regular chat. And about ~10min

**Did.** Recorded both. Ten minutes in plain chat meant the delegation path was no longer
urgent. Suggested a small report caveat for small check images.

### 37

> do the v0.5 wording change

**Did.** Added the caveat to the report step and template; uncertain digits written as `?`.
Rebuilt and pushed.

---

## Writing this guide

### 38

> Okay, now, what I want you to do. I want you to map every single step that we possibly took through this entire process. Section by section. Why we did one thing, corrected another. I'm trying to write up an extremely comprehensive build guide such that if I were to hand over to someone, they could recreate this skill almost exactly. Does that make sense?
>
> Before you write it, any questions? What do you we should cover and how should we cover it?

**Read as.** A request to plan a guide, not write it yet. Four things mattered: completeness
("every single step"), causality ("why … corrected another"), a handoff reader, and an explicit
invitation to ask before writing.

**Did.** Proposed a structure with the method as spine and asked four questions: recreate this
skill or teach the method; does the reader have the repo; where does it live; how much of the mess to keep.

### 39

> 1. Lean more to the method. I want this to be centered around this skill. But it's suppose to teach someone the thinking process behind the process, approach, and decisions as well. Note this is suppose to be somewhat self-contained, because I'm assuming future builds will have it's own unique process to building it's own skill, not necessarily following this guide exactly.
> 2. No, they do not. I would just hand them this guide and that's it and they would have access to their own Claude. Most likely Claude Cowork for example. Does that make sense?
> 3. I just want a markdown document to start
> 4. Minor things like typos we can remove. But only if that was truly a mistake. But corrections from validation resulted in a fix, I want an explanation of what happened. Even typos can be important especially if it resulted in an undesirable behavior. The reader wouldn't be as familiar with Claude, Agents, Skills, etc. So the guide is suppose to help them train their heuristics and understand the process. Does that make sense?
>
> Yes, I'm completely expecting it to be long and comprehensive, but not necessarily verbose.

**Read as.** Method-centred with this skill as the worked example; self-contained because the
reader has only the guide and their own Claude; a primer for a reader new to these tools; keep
every correction that carries a lesson, including typos that caused real effects; markdown;
long but tight.

**Did.** Reconstructed the history from the repo's log, reports and git history rather than from
memory (some work happened in other sessions), then wrote `BUILD-GUIDE.md`: primer, method,
fifteen stages with corrections and "ask your Claude" briefs, the skill as it stands, thirty-one
heuristics, open items, and appendices carrying the schema, prompts, ledger and full `SKILL.md`.

### 40

> I kind of also want to include the exact prompt, every one of them quoted, that I wrote then what you interpreted my prompt to mean and why. Like a message by message build guide.

**Read as.** This document.

**Why.** The main guide shows the reasoning in retrospect; a reader learning to work with Claude
also needs to see what the prompts actually were, how short most of them could be, and what made
the short ones sufficient.

### 41

> Small tweaks, we shouldn't mention anything PII, like [the customer], that's an actual client. So no client names.

**Read as.** Remove the customer's and the accountant's names from both guides, and set a
convention for placeholders.

**Did.** Replaced them with bracketed placeholders and added the conventions line at the top of
this document.

### 42

> scrub the names from the log and reports too

**Read as.** The same sweep across the rest of the repo: log, plan, README, inventory.

**Did.** Four more files edited. Noted that the names remain in this repo's git history and in
the LGX root `CLAUDE.md`.

**Note.** These two came after this document was first written; they're here because the rule
they set applies to everything above.

## Output polish and the workbook (v0.6–v0.7)

### 43

> Okay I just forked this conversation/session. We're going to leave this build here. The next, separate thing is I'm wondering how we might be able to show this off as demo video of how this works?

**Read as.** A new, separate topic, in a forked copy of the session so the build stays untouched.

**Did.** Proposed a shot list and what to record. Nothing was built; the next message changed
direction.

### 44

> Actually, back to this Skill, is there any polishing of the output that would improve the UX and the 'aha' moment for the accountant using it? Any suggestions/ideas?

**Read as.** Not "is it right?" (that was measured) but "what does the accountant see first?"
An open question, so answer with options and a recommendation, not a build.

**Did.** Proposed a review page with the tie-out first and evidence cards (the check beside the
statement line), then quick wins (memo, front and back in one image, a request-originals list
with an email draft, a payee roll-up, a heads-up with an estimate, bundle naming), then two
bigger ideas: an annotated copy of their own statement, and pushing to QuickBooks. Recommended
the review page, memo and stacked images first, and asked whether the page should lead with the
tie-out or the evidence.

**Why.** Demo-video thinking and output thinking are the same question: what makes someone say
"oh"? The answer had to be judged from the accountant's chair, and it's cheap to propose.

### 45

> Yes, plan it out. All the above. Include "An annotated copy of their own statement PDF'..." great idea. Exclude 'Pushing' for now
>
> Once you plan this, we'll compact and then build it

**Read as.** Everything proposed except QuickBooks, including the "later" idea. Plan first, in
enough detail to survive the conversation being compacted (summarized to free up context).

**Did.** Wrote a plan file: deliverables, page layout (tie-out first, as recommended), the new
fields in the results file, a new `deliver.py`, the test support (line positions in the answer
keys, and a script that turns an answer key into perfect results), and the checks to run.

**Why the plan had to stand alone.** After compaction, Claude keeps a summary, not the
conversation. A plan written to a file, with file paths and acceptance checks, is what carries
the design across.

### 46

> Okay, I'll compact

**Read as.** Stop here; the next message will be after compaction.

### 47

> Where did we leave off?

**Read as.** A status question after compaction, not a go-ahead. Summarize the approved plan and
wait.

### 48

> Build it.

**Read as.** Go, per the plan file, to the end: build, check, document, commit.

**Did.** Stage 16 of the main guide. Three layout problems turned up only by looking at the
output in a browser; none would have failed a test.

### 49

> Show me D's review.html too
>
> Can you open the kit in finder?

**Did.** Sent the page; revealed the kit zip in Finder.

### 50

> So here's what I'm looking for additionally. I'd like the output to be a zip file, but I'd like to also put the individual check images bucketed into folders. Does that make sense? Ask me questions

**Read as.** Sort the images into subfolders inside the zip. "Ask me questions" means the
bucketing rule is the owner's call.

**Did.** Asked four: bucket by what (status), each check once or also in a flat folder (once),
naming (numbered by priority), and who uses the folders (QuickBooks and forwarding, both).
Built it.

### 51

> We don't need to test these on all statements again. Just focus on Statement A

**Read as.** Sent mid-build: test changes on one statement, not six. Scope for verification,
applied to everything after it.

### 52

> Great. Now that I'm looking at this. There's a few outputs, right? CSVs, HTMLs. Excluding the folder buckets, can we design a format that can put everything into an excel file? I know that excel can store a lot of different things together and we can integrate the default xlxs skill into this one right?

**Read as.** One workbook holding everything the loose files hold, built with the xlsx skill's
know-how. A design question first, in plan mode.

**Did.** Asked what it replaces, how pictures appear, formulas or values, and which sheets.

### 53

> "xlsx skill's license" -> what do you mean? We've integrated the excel skill before into skills in the past? And generated an excel file from it. We can keep the HTML PDF, but I still want the excel file to standalone. i.e. even if the PDF/HTML wasn't present, the excel file can standalone. Can't annotations, in a form, be in the excel as well? i.e. you can add images to cells, right?

**Read as.** A correction and a requirement. The correction: the owner's own `lgx-docx` already
copies Anthropic's docx toolchain with its license, so "can't copy it" was wrong. The
requirement: the workbook must stand alone, pictures and annotations included.

**Did.** Checked the precedent and followed it (copied `recalc.py` and its license). Asked two
more questions (a marked-up sheet per page: yes; keep `checks.csv` only: yes), planned and built
v0.7 (Stage 17).

**Note.** The owner answered a multiple-choice question with a paragraph that questioned the
premise of the options. Those answers are worth more than any of the choices offered.

---

## What the prompts have in common

Reading them in sequence, a few patterns stand out. They're worth more than any single prompt.

- **Most prompts were questions, not instructions.** "How would you approach this?", "What are my
  options?", "Any suggestions?", "Did the agent not crop/zoom by itself?" Each pulled a proposal
  out of Claude, which Josh then accepted, trimmed or redirected. The design emerged from that
  exchange, not from a specification.
- **Approvals were short because proposals were concrete.** Four consecutive "Proceed"s each
  carried a numbered plan with expected outcomes from the previous report. A one-word approval is
  unambiguous only when the previous turn made the next step explicit.
- **Corrections were about scope and environment, not about code.** "We're not creating the
  skill yet." "We won't actually leverage the Legix MCP." "Why is [the customer's accountant] being mentioned?"
  None of these touched a line of code, and each changed the direction more than any code
  review would have.
- **Domain facts arrived as asides.** "Checks are _usually_ image files scanned in." "It won't be
  through a sub agent but the main claude." "Could be 69 checks on a single page." Each became a
  design axis or a constraint. When you know something about how the work is really done, say
  it, even in passing.
- **Handing back outputs is a prompt.** Four zip files with no instructions produced four scored
  runs, one generator bug fix and two skill versions, because the scoring habit was already in
  place.
- **Twice the owner asked for something Claude wouldn't have prioritized:** saving the
  screenshots and tracking artifacts (which produced the log), and isolating the subagent (which
  produced the audit). Both turned out to be structural.