claude: Add "memory" files like CLAUDE.md, and settings#2128
Merged
gnprice merged 12 commits intozulip:mainfrom Feb 11, 2026
Merged
claude: Add "memory" files like CLAUDE.md, and settings#2128gnprice merged 12 commits intozulip:mainfrom
gnprice merged 12 commits intozulip:mainfrom
Conversation
Collaborator
|
Neat! LGTM, and stress-tested with some of my own experiments with Claude atop this branch. Please merge at will. |
Written with Opus 4.6, with the following prompt: Read README and lib/api/ and understand how we write bindings for the server API My only manual edit was s/build/watch/ in the `build_runner` command.
From Opus 4.6, with just the `/init` command in Claude Code. This is the raw generated version, before any review or editing from me.
For the moment I'm deferring to the tool on what overall structure to use here. Just gave it a read-through and tweaked things that seemed like they'd go in a wrong direction. Most of these were reasonable inferences for Claude to make from our docs, just better suited for the docs' original audience (humans) than for it. The one outright error is the `--fix` needed on `tools/check drift`.
The text is adapted from this comment of mine: zulip#1397 (comment) On the assumption that Claude Code's developers know better than I do how to best express that for Claude Code to use, I gave it the following prompt: ❯ Please edit .claude/api.md to add the following information: Question: Should I detect based on server version or just check if the field exists in the response? Answer: In general, when interpreting data from the server, we very rarely use explicit version checks. Instead, we interpret the data based directly on what we see. So for example if some field isn't present which new servers always send, then that means the server is too old to have that field, and we interpret the data accordingly. and this is what it did.
This was generated by Claude Code at Opus 4.6 with the
following prompt. (I haven't yet reviewed and revised myself;
that comes next, but I wanted to record the raw output.)
Explore very thoroughly the code for this app's internal data store
to understand its architecture and key patterns.
Please investigate:
1. lib/model/store.dart, especially PerAccountStore
2. Other files in lib/model/
3. The relationship between PerAccountStore, PerAccountStoreBase,
and subclasses of PerAccountStoreBase
4. Files in lib/api/model/
5. How data flows from InitialSnapshot to the store, and how data
on the store is updated by events
6. Files in test/model/
7. test/example_data.dart
8. The existing CLAUDE.md
9. lib/widgets/store.dart
Be very thorough - look at multiple files to understand the big
picture. Report back with detailed findings.
The prompt is based on the internal one that the `/init` command
generated for a subagent in order to produce CLAUDE.md.
Turns out that when this prompt caused a subagent to be spawned,
it was given a still more detailed prompt:
Explore very thoroughly the code for this Flutter/Dart app's
internal data store architecture. I need detailed findings on all
of the following areas:
1. lib/model/store.dart — especially PerAccountStore, GlobalStore,
and any base classes. Understand the full class hierarchy, key
fields, methods, and how ChangeNotifier is used.
2. Other files in lib/model/ — scan all files in this
directory. Understand what each one does and how they relate to
the store.
3. The relationship between PerAccountStore, PerAccountStoreBase,
and any subclasses — trace the inheritance hierarchy. Where is
PerAccountStoreBase defined? What does it provide? What
subclasses exist?
4. Files in lib/api/model/ — scan these to understand the API data
types, how they use json_serializable, and how they relate to
the store.
5. How data flows from InitialSnapshot to the store, and how store
data is updated by events — find InitialSnapshot, understand
how it populates the store, and trace how events update the
store state.
6. Files in test/model/ — scan these to understand testing
patterns for the store.
7. test/example_data.dart — understand the test fixture patterns.
8. CLAUDE.md — read for additional architecture context.
9. lib/widgets/store.dart — understand how widgets access the
store.
Be very thorough - read the actual file contents, not just file
names. Look at multiple files to understand the big
picture. Report back with detailed, organized findings covering
all 9 areas.
So in retrospect I probably could have made my prompt terser.
Again keeping the structure unchanged, but fixing small errors and small misleading bits.
Suggested by the `/insights` command.
Amazing. Got the following error the next time I tried
starting `claude`:
/home/greg/z/flutterz.claude1/.claude/settings.json
└ hooks
└ postEdit: Invalid key in record
Files with errors are skipped entirely, not just the invalid settings.
And indeed, there is no such thing as a "postEdit" hook.
That's not even the naming convention: they're in PascalCase.
Here's the docs:
https://code.claude.com/docs/en/hooks-guide
Looks like there is a way to get a similar effect:
https://code.claude.com/docs/en/hooks-guide#auto-format-code-after-edits
but I'll skip it for now.
Member
Author
|
Thanks! Merging. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is what I developed along the way in my initial Claude Code experiments the other day that produced #2123, plus some small cleanups today. Upstream docs here:
https://code.claude.com/docs/en/memory
https://code.claude.com/docs/en/settings
https://code.claude.com/docs/en/permissions#permission-rule-syntax
As the commit messages explain, the bulk of the text here was generated by Claude itself, all with the Opus 4.6 model. I've read all of it and corrected things that were wrong or I thought might be misleading. OTOH I've largely left intact the tool's choice of how to cover the material and how to structure the files — I figure the tool's developers have a better idea than I do of how that's best done, and that they've tried to get the tool to reflect that knowledge.
I've left intact in the branch more detail about the process of producing these than I typically would, including a couple of commits that have raw Claude output followed by separate commits for my fixes. I figure the process is interesting information to share as we're doing this initial experiment, and the raw output here under .claude/ doesn't break anything the way that changes in the actual code can.