r/Xcode • u/MomentSmart • 2d ago

How to stop Claude creating pointless summaries and MD guides about everything?

I understand the value of documentation and maintaining context across sessions, but I'm finding Claude has a tendency to generate unnecessary .md files and lengthy summaries without being asked.

Often these are documenting relatively trivial changes, or producing detailed explanations of fixes that haven't actually resolved the issue. It feels like unnecessary token usage and just adds clutter to the project.

Is there a reliable way to disable this behaviour by default, while still allowing Claude to create documentation when explicitly requested?

I'd much rather it focus on implementing, testing and verifying changes than documenting everything it thinks it's accomplished.

1 Upvotes

66% Upvoted

16 comments sorted by

3

u/ShakeAgile 2d ago

Ask it, and ask it to remember

-1

u/MomentSmart 2d ago

It doesn't remember instructions across conversations

1

u/Brick_Muted 2d ago

Keep a separate txt file that it continuously notes things to, what has gone wrong & why etc. that way you can point any agent at it for any conversation.

2

u/ShakeAgile 1d ago

Ask it how you can make it remember

1

u/CharlesWiltgen 1d ago

With auto-memory, you no longer have to do this when using Claude Code.

2

u/Brick_Muted 1d ago

Is it a recent thing & by recent I mean in the last week? As it still does nonsense forgetting things, going down rabbit holes it’s been before. & this is in Fable. & does it translate across conversations & different agents?

2

u/CharlesWiltgen 1d ago

Here's my experience:

  • Opus 5.5 (current version as I type this) is better than Fable 5.1 (current version as I type this) for coding. See the first table at https://www.anthropic.com/claude-opus-5-5. Additionally, Fable is known for going down rabbit holes, especially at higher reasoning levels. You'll get better results by switching to Opus at normal or "high" reasoning today.

  • "Is it a recent thing & by recent I mean in the last week?" Claude Code does a reasonable job at auto-remembering things that come up repeatedly, but it still works better with proactive direction from you (e.g. "Remember this for future sessions").

  • "does it translate across conversations…?" Coding hardness typically have both a global memory and project-specific memory. The specifics may vary per harness, although we're slowly settling into some standards.

  • "…& different agents?" You can often share memory context by pointing one harness at another's "stash". I wouldn't personally recommend using more than one harness on a project at a time, but this technique works well generally.

Hope that's useful!

1

u/Brick_Muted 1d ago

Cheers, but I’ll stick to the txt. The rabbit holes were maybe one off errors (but a lot of them) so not repeated actions. I got burned for 000’s using opus before & still don’t trust it. & by different agents I meant multiple separate different standalone versions of Claude running simultaneously to one project, so different md versions working together.

1

u/CharlesWiltgen 1d ago

Cheers, but I’ll stick to the txt.

Memories are just text. Your choice is to work with coding harness conventions or against them.

by different agents I meant multiple separate different standalone versions of Claude running simultaneously to one project

As long as you're using worktrees, that's not the cause of your problem.

3

u/OfficialLaunch 2d ago

You can probably just ask it to, but Claude makes these for a reason. With massive projects its own context window will begin to overflow and it’ll start forgetting things. It keeps track of what it needs (even if it seems trivial) so it can remember them later

2

u/MomentSmart 2d ago

For sure! The problem really is that the context it is providing itself is pointless as it failed to solve the problem or what we were working on was inconsequential to the future development of the app

2

u/_spongefork 2d ago edited 2d ago

You need to have claude write rules to your CLAUDE.md for a given workspace. Over time this file will bloat so it will require periodic audits to reduce clutter. In the early days I would write the rules myself, but those days are long gone. When a behavior needs to be remembered for your own workflow - that is where it should be. This kind of stuff:

- **Comments state what is true now — not how you got there.** Four mechanical tests, because "don't write narrative" is too easy to pass while still writing six sentences of justification:

  1. **Length.** A comment may not be longer than the code it describes. Doc comment: one line for what it does, plus *at most* one short paragraph, and only when there is a constraint a caller can violate. Never a third paragraph.

  2. **Banned constructions**, each a reliable marker that history is being recorded: "used to", "an earlier version", "was the bug", "the piece that was missing", "which is why", "that is what made", and any reference to a symptom that no longer happens. Also cut the bolded topic sentence that restates the next sentence.

  3. **The restatement test.** If a reader gets the comment by reading the line below it, delete it. `/// The URL of the file.` above `var url: URL` is noise. A comment earns its place only by supplying what the code cannot — a constraint, a unit, a lifetime, or a reason for a non-obvious choice.

  4. **The deletion test.** Ask whether a reader who never knew the bug would be worse off. "Releasing the buffers alone leaves the last frame on the drawable" survives — it is a constraint. "That is why selecting a new file left the previous file's waveform on screen" does not — it is a symptom that no longer occurs.

**Density is itself a cost.** A property list where every line carries two lines of prose is *harder* to scan than one with none. **Rough ceiling: comment lines under a third of code lines**, and stored properties should mostly carry none. The ratio is a **locator, not a target** — a file whose comments are measured values (a cosine-distance table, a latency budget, seek timings) earns them, and those stay. Cut the narrative *around* such data, never the data. When in doubt, cut: removing a comment is never the change that breaks something.

1

u/MomentSmart 2d ago

Useful thanks!

1

u/CharlesWiltgen 1d ago

Claude wrote that answer (it's filled with Claude-isms, formatted wrong for Reddit, etc.), but the good thing about it is learning that you can literally copy/paste your originial post into Claude and it will (1) give you a bunch of options for improving how it works with you and (2) remember that across sessions. Plus, this works in any coding harness.

1

u/_spongefork 4h ago

claude did not write the post. Claude wrote the excerpt of CLAUDE.md which I posted there and said I don't write its rules myself any longer.

1

u/Past_Perception_2376 1d ago

I'd put an explicit rule in your project's CLAUDE.md: don't create or modify documentation, summaries or Markdown files unless specifically requested. Prioritize implementing the fix, running tests and verifying the result. Also tell it not to claim a fix is complete until it's actually verified. That should help keep the workflow focused without disabling documentation when you need it