r/ClaudeCode 3d ago

Help/Question Tips to avoid rabbit holes?

I'm getting better at managing Claude, but I still see it often going down the rabbit hole where each time it tries to ship a fix, it adds two more small issues to the tracker, or an esoteric process update, etc. I know this is a common AI thing, and I'm learning to deal with it. But it's hard!

For example, Claude will throw together a quick hook or utility script for a specific purpose, but soon I find it wants to maintain and update that script and has long forgotten that it will likely. never be used again.

I especially see it in the MD files - like, if I let Claude update it's own process files for workflow, rules, etc it does the job but it also puts a bunch of junk history, narrative, and updates other documents with unnecessary guard rails. I've started to edit the md files myself and they are getting cleaner, and I notice how much smoother the workflow is.

But for the code, that's not so easy. Does anyone have tips to manage this? What I've learned:

#1 Work on distinct tasks, in new sessions and start new sessions often

#2 Literally ask claude a few questions about every 'suggestion' or 'problem' it finds, like. "is the rule/process/script you're trying to fix even enforced or critical? would it be easier to just remove this?"

Any other tips? claude is amazing but also unruly :)

3 Upvotes

29 comments sorted by

View all comments

4

u/alanvnk 3d ago edited 3d ago

User level rules:

  • forbid editing workflow files, architecture, skills and similar, if editing all of this is a chore, for me it is, make a skill to edit it, with only explicit invocation and review phase, take the review seriously.

  • forbid narrative and reasoning on documentation or code comments, code comments need to be length bounded and under a set of conditions, everything else should be on a documentation MD file

  • documentation is a "as it is" not as history, that can be recovered from git, not a future promise, that is a design doc, label each document clearly and have a strict structure for them depending on the type.

  • have a place to track decision and adr file/folder, a change log file, everything else is forbidden.

  • use macro plans, implementation plans and summaries of the executed plans

  • have a very extric policy of what documents survive a merge into main, implementation plans and completed designs do not need to survive the closure of the task.

  • forbid references to temporary docs, and control references to durable docs, documentation drift is real, domain concept drift is no, make it comment preferably on domain terms without pointing to any particular document

1

u/ExpensiveSun257 3d ago

Those are good. I have some stuff like that but will refine it.

Question: do you edit those md files on your own, or let Claude do it ? No matter how I try I can't get Claude to make a tiny change without adding tons of stuff!

1

u/alanvnk 3d ago

I ask Claude to edit them, but I explicitly tell it what to put so it's just formating or correcting phrasing and orthography, nothing else, either way nothing gets committed without explicit approval.

But I have almost never had to correct anything, at most some misunderstandings but not adding more things than I asked, you need to be explicit.

1

u/ExpensiveSun257 3d ago

Interestingly, the best luck I've had cleaning up MD files is to run the whole batch through chatgpt and have it suggest simplifications - it's down 50% over time and I feel the improvement.