This works fine, of course. And Claude, our slave of steel, doesn’t mind the extra typing and isn’t concerned that it will strike the wrong key.
This is an interesting example of how Claude’s style might differ from ours. I’d love to start a long-term thread collecting examples of how (and where possible, why) Claude’s code differs from our own, and whether we should teach Claude to code like we do or whether we might learn from its example.
Yes! An interesting challenge is doing the mapping to/from designators. We humans ask for the parent as our inner abstraction of the app’s data (surfaced via the doc Outline) find it easier than remembering the name (if unique) or path of the desired object. For our slaves of steel, it is likely the opposite, where having to learn the abstraction just to get at the human’s internal model is wasteful effort.
We (humans) can, of course, surface the paths implicit in designators: for instance, in children. So, such a ‘reverse’ look-up is possible, though we have little personal value for that, as the data is longer and less memorable (for the human brain). Indeed, the result of children might be 10s or 100s of paths, yet all encapsulated by/abstracted to one short string.
Beyond being a useful shorthand the designators are also semantically different in ways that affects correctness as the document changes. When you list out all the children, that’s it — those are the notes you get. If you add or remove them, or change their names then your code breaks. Claude is creating fragile logic here.
Since you named this a megathread, I thought I would share some results of my toy project, and discussions with Claude to make my usage allocation go farther.
The Tinderbox file is the start of a collection of information on polymers, starting with notes for 11 commodity polymers, the recommended drying temperatures, and the time suggested to dry them before using for 3D printing (fused deposition modeling, FDM). I populated the notes by exploding a table I found on the internet. I had Claude parse the notes and assign the attributes Material, TemperatureC, TimeHours. Because I am cheap, I started with the free tier and lost a little modified information when my session hit the usage limit, and I restarted after paying for a month. I then spent some of my usage asking Claude about ways to make my work more efficient and use less of my allotment. I thought others might find these suggestions useful as well.
I first had Claude create a note containing the day’s transcript. It created this in its container in the TB file. It may be that I need to explicitly tell it to finalize the session, as the transcript appeared incomplete at one point.
Claude suggested creating a note with the Current State summarized, it says this reduces the tokens compared to sending the entire Tinderbox file to the server.
It also created a note clarifying for itself the limitations of the MCP compared to its assumptions.
Another suggestion was to create summary of the transcripts for its future reference, which I agreed to, and had it put in its folder.
I had it create an additional note with some estimates of session usage, though it provided information on what it cannot access-namely it can’t see what usage is reported by the app, it can only take what information is provided by the API as it interacts with the server. It still has useful general information that may guide what I use Claude for in the future.
At the end of the session, I explicitly told it this was the end of the session and asked it to update the notes we discussed which it did. I was careful to save the file.
The actual work I did on this file was trivial, though it was satisfying to have it generate a LaTeX table in a note based on all the material note attributes, and to reshape the entries to make the display better. Not the best use of high tech, but I’m calling this an exercise of capabilities, rather than laziness.
