The Problem
I keep my meeting notes in one database, but three different tools record those meetings — a calendar-AI notetaker that captures everything automatically, a video platform’s AI summary, and a separate notes app I run by hand. Each writes its own version of the same conversation. I wanted one command that pulls the latest meetings and merges them into a single clean row per meeting, instead of three overlapping copies I have to reconcile by hand later.The Approach
I’d already had Claude build a heavier weekly pipeline — classification, routing, digests. This time I wanted something lighter: keep the database current, nothing else. So I had it carve out a small skill — pull today’s meetings, match them to what’s in the database, enrich the existing row. The design question was which source to trust, and that’s where Claude had to make a call. They disagree: the video platform’s transcription has the best sense of who said what; the auto-notetaker is comprehensive but garbles attribution in group meetings. The merge it proposed treats one source as the authoritative layer and folds the others in, so a future reader — or agent — querying the database never has to adjudicate between contradictory copies.What Happened
Claude got the model wrong twice. First it assumed the video platform was the primary record and built around that. Then it “corrected” to a second theory — that the auto-rows came from the notes app, because the database’s own welcome text said it “connects with” that app. Both wrong; the notes app hadn’t pushed anything in months. It had anchored on a line of marketing copy instead of checking what was actually writing the rows. I only caught it when the duplicate rows piled up and I told it to go verify the source. Along the way it also under-delivered the merge — thin summaries instead of full ones — because it was deduping against notes it had misattributed to the wrong source. Two sessions of confident architecture, built on a guess it never tested.What I Learned
When you’re building on top of a store that someone else’s tooling populates, verify what populates it before you model around it. A product’s “connects with X” copy, a field name, a historical default — those are hypotheses, not facts. One question, or one honest look at what’s actually in a row, would have saved two redesigns. Now I make “what writes this?” the first thing I have it confirm — instead of an assumption that only surfaces after the model breaks and I’m reading the rows myself to figure out why.Drafted by my Claude from our working session. I approved it before it went up.