@Allyn Martinez A couple of these I think I've already solved for. for your #7. My structure includes three levels of rules (Claude.md files) the global one, a base folder one, and one by project. The global and base folder ones cannot be edited by sessions launched anywhere outside the base folder. This is enforced both in prose and through hooks. Each folders also cannot edit outside their own folder, they can send requests through briefs which are placed in the other folders and only actioned in a session that has the full context of those folders. They are treated as suggestions to review given the full context. for your #10 I created a credit maximizer project that does a ton of things for me, it keeps a running tab of where I am in my 7 day window usage. I simplify this and color code it. Green is +/- 10%, Orange is 10%+ under budget, Red is 10%+ over budget. Then my job scheduler when it's about to launch a job checks the color and will only run jobs authorized in that color. I also have a real time measure of my context, 5h window and 7d window embeded in my vscode terminal that runs constantly so that I can also see where I am in terms of usage. As you can see from the attached snippet I'm dead in the water at the moment and have no 5h window, because same.

This is a really interesting question and I'm also quite curious. I think you would need to have very rigid structures in places to make sure that things don't totally go off the rails. Either that or you work in black boxes. Would be interested to know what people have actually implemented though.

I do my brainstorming directly in VScode with Claude Opus 5.5. I've detailed how I set it up and my process here: https://www.skool.com/cliefnotes/how-are-you-maximizing-your-usage-claude-code-edition?p=3d8874f2

You are talking my language. I have created an ICM for running solo adventures in the new Dungeon Crawler Carl TTRPG and am now working on making it into a multi-player system. It is a text adventure but with add ons, like choosing a spotify list based on location, images for all characters and locations, sounds, etc. I've already played for a jaw dropping over 52 hours and have likely spent just as much in developing the system and trying to tweak it. It is almost solely responsible for me bumping up against my usage max. I've attached screenshots of different parts of the HUD as well as what a play session looks like for one turn. I would be happy to do a show and tell if you are interested.

Honestly almost all my use of ICM is creative work. Some more creative than others. I've setup a system around decision making and project building that's quite robust but might be more than you need to put in place. Maybe it would be useful to you. https://www.skool.com/cliefnotes/how-are-you-maximizing-your-usage-claude-code-edition?p=3d8874f2

@Clare Martinez Absolutely. All my files are versioned and have histories, especially those in the project structure process. I have yet to have an update that I don't push accross all projects, but I envision it might happen at some point. They all carry the version that they were created from as well as the version they have been modified to locally within their own folders. Having consistent versions also makes shared tools easier to use. The todo (a list based of items to work on based on specific goals) and worklog (a list of what has been worked on, when and what was done or where it ended, sometimes including justifications) that I have in all folders both grow quite large so they are archived regularly. This gives me a full view of what is currently being worked on, and also what has been done in the past. The worklog archive for my largest project is 256 entries deep at the moment (funny that it's that number when I checked). I also have a regularly scheduled job that checks for new capabilities in each project and raise them as candidates for other projects. Nothing can modify my base claude.md or the global claude.md except projects from the base directory. I enforce this both through instruction but also through hooks and rules that will prevent it. I also don't let any projects modify each other except through the delivery of briefs that are treated as suggestions and evaluated on their own merit when I am running that specific project and it therefore has all the local context. It can get a bit irritating to have to swap back and forth between terminal sessions but also I think is both good security and a prevention of over-reach. I like the idea of exploration and some of the projects have definitely become iterative.