The Personal Librarian

In Claude, create a new Project and give it a name. The important field is the custom instructions box — this text is prepended to every conversation inside the project, forever. Write the job, not the format.

This is the step people skip, and it's the one that does the work. A model guessing at your taste from a conversation is a party trick; a model with sixteen years of timestamped purchase history can tell you which book you bought and abandoned in 2023.

This guide assumes Kindle, because Amazon will hand you your entire digital purchase history as CSV — it's just buried in the privacy tools rather than anywhere near your library.

1. Go to Amazon's Privacy Central → Request Your Information (from Account, look for "Request Your Data" or "Your Data Requests").
2. Choose a category. For books, the two that matter are Digital content ordering — every Kindle purchase, with title, ASIN and order date — and Digital borrowing / Kindle Unlimited, which includes a Loan Status column. You can also request everything and pick out the two files later.
3. Confirm via the email Amazon sends. Nothing happens until you click that link.
4. Wait. It usually arrives within a few hours; Amazon reserves the right to take up to 30 days, and a full-account request often does.
5. The download is a zip. The files you want are Digital Content Orders.csv and Digital Borrowed Items.csv.

Upload both to the project, not to a chat. Files attached to a project are visible to every future conversation in it; files dropped into a single chat vanish with that chat.

The columns that actually matter

Purchase history tells you what you bought. That's a different library from the one you've read, and the gap is usually enormous. Read state is what makes "show me unread books I already own" an answer rather than a guess.

Kindle already knows. Whispersync has to track your place in every book to keep devices aligned, so if you have Kindle for Mac installed, the answer is sitting in a database on your own machine — no logging habit required. Two files under ~/Library/Containers/com.amazon.Lassen/Data/Library/: Protected/BookData.sqlite for titles and series, and Application Support/Whispersync/WSyncDefault.sqlite for read state and your collections.

Point an assistant at that folder and ask it to pull read state for every book. It's a short script, not a project. Three things to tell it, because each one fails silently:

Quit the Kindle app first — it flushes on quit. And drop the built-in dictionaries before you count anything; there are around forty of them, they're tagged DICT, and they'll show up as unread forever.

No Kindle app? You can still infer it. When someone loves a book they buy the next one within days, so book one owned with no book two is a decent unread marker. It's a guess, though, and a fallible one — on a real library it got about four calls wrong out of the handful anyone bothered to check, in both directions.

Now the first real session. The output is a document, not an answer — this is the step that turns a chat into a system.

Signals worth asking for

• Binge windows — six books by one author in three weeks says more than any rating.
• Acquisition pace by year — where the peaks are, and what was happening in those years.
• Returned or expired loans — a borrow you let lapse is a soft "not for me".
• Lanes that are already full — knowing where you own forty books means recommendations there should be recent releases, not new authors.

With the profile written and the CSVs attached, natural-language search just works — the profile supplies the taste model and the CSVs supply the inventory. What makes it feel like a librarian rather than a search box is insisting on the two-list answer.

• "Something lighthearted, under 350 pages, that I already own."
• "Books like the one I just finished — tell me why each one matches."
• "What did I buy in 2024 and never continue?"
• "I want to be scared but not grossed out."
• "What's the longest-running author relationship in my library, and have I missed anything of theirs?"

That last one is worth running once a year. A completist check against a favourite author's actual bibliography turns up gaps you'd never notice yourself.

Ask for recommendations in a fixed shape and they get dramatically more useful: one row per lane of your taste, with a column for something you already own and a column for something new. The owned column is free — it costs nothing and you can start tonight.

Then keep a second doc — maybe-list.md — and ask for anything interesting to be appended to it. Split it into ready to start right now (already yours) and to get. It becomes the thing you open in a bookshop.

Everything so far lives in text. The last piece is a page you can look at — one self-contained HTML file, published so it keeps a URL and survives the conversation that made it.

Shelves that earn a tab

The one feature worth insisting on is a reading log: read / reading / did-not-finish, plus a rating, stored in the page itself with an export button. It's the only thing here a chat genuinely cannot do — and next session, you feed those marks back into the profile doc, which is how the system learns something the purchase data never knew.

The CSV export is a one-time snapshot; your library isn't. Two ways to refresh it, and they answer different questions.

From the Kindle app on your computer

This is the fast path and the one you'll use most: the same two databases from step 3, re-read. It gives you the current catalogue and current read state with no browser and no login — which means it also answers "what did I finish since last time?", the one question the purchase export can never answer.

Save each run as a snapshot file and diff against the previous one. Three lines come out of that diff: what's new, what moved to read, and what's still sitting there. That's the whole maintenance loop.

From the browser, when you need authors or covers

Slower, because it needs a logged-in Chrome session driven by browser automation — so save it for when you're rebuilding the dashboard. Everything else the local databases already have. Part II has the mechanics.

Put it on a schedule

Once the refresh is a skill, it can run without you. A scheduled task attached to the project — monthly is about right — runs the sync, diffs against the last snapshot, and reports back in three lines. The unread list stops drifting, and you stop being the thing that remembers to update it.

Keep the cadence modest. Reading changes on the scale of weeks; a daily job just generates noise you'll learn to ignore.

Write it down as a skill

Save the refresh as a reusable skill rather than rediscovering it every few months. The valuable content is not the happy path — it's the trap list. A skill that opens with "here are the three fields that look like read state and aren't" saves an hour every time.

Worth including: where each piece of data lives, the traps, a fast path and a full path, what files it writes, and a sanity check against a known baseline count so a bad run announces itself. Then add the two steps a script can't do — put the fresh unread list back into your project, and fold what changed into the profile doc.