claude: Add "memory" files like CLAUDE.md, and settings, take 2#2131
Merged
gnprice merged 12 commits intozulip:mainfrom Feb 12, 2026
Merged
claude: Add "memory" files like CLAUDE.md, and settings, take 2#2131gnprice merged 12 commits intozulip:mainfrom
gnprice merged 12 commits intozulip:mainfrom
Conversation
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 adjusting the `build_runner` command, which Claude had taken verbatim from the README.
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. I did move the file, though. Claude put it by default in the root, but the docs say it should have the same effect here under .claude/ : https://code.claude.com/docs/en/memory
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
prompt below. (I haven't yet reviewed and revised myself;
that comes next, but I wanted to record the raw output.)
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 (also below).
So in retrospect I probably could have made my prompt terser.
My prompt:
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 that Claude generated for the subagent:
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.
Again keeping the structure unchanged, but fixing small errors and small misleading bits.
These reflect fixes I made in reviewing Claude's output for what became the PR zulip#2123 (for issue zulip#1942).
See docs: https://code.claude.com/docs/en/memory#modular-rules-with-claude/rules/ I also tested manually that Claude still has this file handy in context: I asked a question which this file answers, and it successfully regurgitated this file's answer without any tool use (in particular without going and reading any files).
Really one should probably keep any LLM tools in a worktree that doesn't have these secrets in the first place. But for defense in depth, let's deny access to them in case they are present.
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
1 participant
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.
When I merged #2128, I accidentally used a draft version from before sending the PR. Here's the intended version again.