Yes, from 200k to 1M come yesterday. Claude, I mean.
Your skills library sounds like it needs to be thoroughly researched. Links?
dimitarvp
Vidar
That should really help. But why does it still keep compacting on me? Might be setting somewhere.
Not sure all are shareable as I didn’t really consider what information Claude picked up on the way. I would have to check for any internal proprietary or copyrighted parts. Any particular topics of interest?
0
dimitarvp
I am on Max. Forgot the details. Here’s the announcement: 1M context is now generally available for Opus 4.6 and Sonnet 4.6 | Claude by Anthropic
1
dimitarvp
Anything and everything that helps Claude not stumble and keep retrying the same stupid crap 1-2 times a day that swallows extra 10 minutes really. To sharpen it. So, language skills, tool skills, best practices, that kind of stuff. Anything that gives it actionable info right away and helps it progress smoother.
1
Rich_Morin
I’m using a largish tree of small(er), cross-linked files, organized in an ontological fashion. So, for example, there are subtrees for different sorts of things. Within each subtree, there are documented and (mostly :-) enforced naming conventions and patterns of file and dir usage. Many of these are seen in multiple subtrees. For example:
- “date bucket” (
YYYY-MM-DD) and_spex/directories _index.md,_readme.md, and_rules.fe.md/files- Overview files for the overall tree and each subtree
- Spec files for all conventions, projects, scripts, etc.
- YAML headers for all MD files
Using all of this as an “interface” to the file tree provides a form of progressive disclosure that allows both humans and LLMs to find things as they are needed:
“In the design of interfaces one must also consider carefully how one selectively informs a user about a particular system, providing well-chosen bits and pieces that can constitute a general understanding of a system.” - Kristina Hooper Woolsey
My latest foray into this space involves the creation of a YAML file that details patterns in the purpose, scope, and usage of various file tree conventions. The choice of YAML is very intentional: it can be “read” by LLMs, humans, and scripts. So, for example, I can use it in maintenance sweeps to find and repair unintentional divergence from the prevailing pattern(s).
All of this will probably feel like massive overkill to some, but bear in mind that:
- File storage is reliable and essentially free.
- Git can provide a really useful safety net.
- Organized hierarchies (can) scale very gracefully.
Finally, remember that LLMs and scripts are doing the Real Work™ of constructing, maintaining, and using the tree. For example, I absolutely loathe Git’s UI, but CC has no trouble with it at all. So, no problem…
0
Rich_Morin
Vidar
I’ll see what I can come up with. The Rust-NIF skill (Rustler) is fairly small and easy. It shows some of the structure anyway. (It would occasionally return a wrong double ok tuple to Elixir, but that should be fixed now).
1
Vidar
I wouldn’t say overkill as the long term memory issue and focus drift is real. But while I can aspire to that I don’t think I stand a chance to keep that organized over time. I trust your mileage varies a lot. (Wife gives me max 5 minutes, but I would set money on at least 10. She hasn’t taken into account that I can just keep my hands off).
After every 20 to 50 or so compactions I get a confused Claude which is sadly also very action oriented. That one can create more havoc in a few minutes than me and other Claudes can correct in hours. Thus being aware and killing off any utterly confused Claude at birth is a priority. I mention that because messing up file names, references and git repos seems be confused Claude’s speciality. Once even found messing up another repo altogether. Keeping the file_locations.md seem to help some.
1
sbuttgereit
This is a generic reply to a few of the comments here related to context and similar issues.
I watched this talk a few days ago and thought it might be relevant, if perhaps a little tangential:
Enjoyed it and very much liked this guy’s approach. Specifically he’s thinking about the constraints of the tool as a tool and how best to work within those constraints. This isn’t any different than we might do with any other technology, though I think it’s easier to forget about this with LLMs since the cost of entry is simply starting a discussion to get some result… but they’re still just tools that will work better if used correctly and will likely fail you if not.
3
Vidar
Some things Claude stumble at on a daily basis isn’t really language specific, but here it the current version of my rather ambitious Elixir skill for Claude. It is a balancing act of content vs focus and context, and what to prioritize and keep in the core skill vs referenced files (which Claude use less frequently). I’m sure the current balance is off but hopefully it will evolve for the better over time. There are also rough patches and sharp edges I’m sure, but this is what I currently use.
I have tried to sanitize it, but if there are still remnants of private repos, computer names, or worse, then please let me know. Examples and reference bits are dominantly lifted right from production code to ensure they work, and credits should be given where due. Hopefully somewhat useful as is, for inspiration or for scaring and scarring innocent code souls.
1