AndyNemmity

If I fork out a version for others that is public, then I have to maintain that variation as well.

Is anyone in a similar situation? I think most of the ones I see released are not particularly complex compraed to my system, but at the same time I don't know how to convey how to use my system as someone who just uses it alone.

it feels like I don't want anyone to run my system, I just want people to point their ai system to mine and ask it what there is valuable to potentially add to their own system.

I don't want to maintain one for people. I don't want to market it as some magic cure. Just show patterns that others can use.

Which is why I use a skill that is a command, that routes requests to agents and skills.

Writing about AI so far, but who knows. Just started it.

https://gist.github.com/notque/e57cb975a3df7780824ce4085a59a...

There was someone a while ago who made a funny post about the type of Hacker News commenters. So I have 5 of them that will review things, and ended up being way more effective than I ever imagined they'd be.

│ contrarian-provocateur-roaster │ Challenge premises, explore alternatives │ "Have you considered..."

│ enthusiastic-newcomer-roaster │ Accessibility, onboarding friction │ "Wait, how do I even..."

│ pragmatic-builder-roaster │ Operational reality, production concerns │ "This won't survive 3AM pages" │

│ skeptical-senior-roaster │ Long-term maintenance, sustainability │ "Who maintains this in 2 years?" │

│ well-actually-pedant-roaster │ Terminology precision, verifiability │ "Technically, that's not..." │

Someone tells me it "forgets" their instructions. Or it hallucinates fixes. Or it ignores the rules they put in CLAUDE.md. And when I ask what their setup looks like, it's always the same thing: a massive system prompt with every rule for every language, stuffed into context.

So I wrote up how I solve this.

This has been found in all sorts of variations, and is accepted. It's not just my word, it's the standard understanding. But also, it's true in my experience.

You also limit the session work when you are offloading to agents, which are calling skills. So it does do that as well.

But that's what we're talking about, having agents do things in smaller chunks. Maybe I didn't explain that clearly enough?

It's just a complex topic. It's hard to cover everything. But yet, that's part of the idea. We're making context very specific to the task, and cutting things up into smaller chunks with dedicated context windows only for that task.

I almost completely ignore Claude.md - there are very few rules I want every subtask to know about.

the main system is for cordination, of the many agents with their own dedicated Claude.mds which call their own skills with their own dedicated instructions.

It's like Russian dolls. Now, I do use much, much MUCH larger Agent mds than anyone else. I've been doing this for 10 months, and I believe it's the correct way to do it.

I intend to write a blog post on it, it's a topic in it's own part.

Even your small Claude.md - I would have in several files. The Typescript agent is the only one that needs to know about the Typescript details. This is the kind of thing I mean.

That uses less tokens. The LLM is just calling the script, and getting the response, and then using that to continue to reason.

So I'm not exactly following.

But for sure, there are places it makes sense, and there are places it doesn't. I'm arguing to maximully use it for places that make sense.

People are not doing this. They are leaving the LLM to everything. I am arguing it is better to move everything possible into tools that you can, and have the LLM focus only on the bits that a program doesn't make sense for.

Also, the pick up or not pick up, or discover or may not discover is solved as well. It's handled by my router, which I wrote about here - https://vexjoy.com/posts/the-do-router/

So these are solved problems to me. There are many more problems which are not solved, which are the interesting space to continue with.

I'm just also working on real projects as well, so a lot of my priority is focused on new skills building, and not worrying about managing the current ones I have as github repos.

So in my nano banana image generation skill, it contains a python script that does all the actual work. The skill just knows how to call the python script.

We're attaching tools to the md files. This is at the granular level of how to hammer a nail, how to use a screw driver, etc. And then the agent, the handyman, has his tool box of skills to call depending on what he needs.

You're packaging the tool with the skill, or multiple tools to do a single thing.

It will just as easily get around it by running it as a bash command or any number of ways.

I think of this stuff as trivial to understand from my point of view. I am trying to share that.

I have nothing to sell, I don’t want anyone to use my exact setup.

I just want to communicate the value as I see it, and be understood.

The vast majority of it all is complete bullshit, so of course I am not offended that I may sound like 1000 other people trying to get you to download my awesome Claude Code Plugins repo.

Except I’m not actually providing one lol

The real issue is I don’t know the issues ahead of time. So each experience is an iteration stopping things I didn’t know would happen.

Thankfully, I’m not trying to sell anyone anything. I don’t even want people to use what I use. I only want people to understand the why of what I do, and how it adds me value.

I think it’s important to understand this thing we use as best we can.

The personal value you can get, is entirely up to your tolerance for it.

I just enjoy the process

But the things I am doing might not be the things you are doing.

If you want proof, I intend to release a game to the App Store and steam soon. At that point you can judge if it built a thing adequately.

another is one claude code ships with, using rip grep.

Those are actual features. It's adding deterministic programs that the llm calls when it needs something.

All of these systems are for managing context.

You can generally tell which ones are actually doing something if they are using skills, with programs in them.

Because then, you're actually attaching some sort of feature to the system.

Otherwise, you're just feeding in different prompts and steps, which can add some value, but okay, it doesn't take much to do that.

Like adding image generation to claude code with google nano banana, a python script that does it.

That's actually adding something claude code doesn't have, instead of just saying "You are an expert in blah"

Agents are an md file with instructions.

Skills are an md file with instructions.

Commands are.. you get the point.

We're just dealing with instructions. Claude.md is handled by Claude Code. It is forgotten almost entirely often when the context fills.

Okay, what is an agent? An agent is basically a Claude.md file, but you make it extremely granular. So it only has instructions of let's say, Typescript.

We're all just doing context management here. We're trying to make sure our instructions that matter stay.

To do that, we have to remove all other instructions from the picture.

When you're doing typescript, you only know type script things.

Okay, what's a skill? A skill is doing a single thing with type script. Why? So that the context is even smaller.

Instead of the agent having every single instruction you need about typescript, you put them in skills so they only get put into context when that thing is needed.

But skills are also where you connect deterministic programs. For example, I have a skill for creating images in nano banana.

So when the Typescript Agent needs to create an image, it calls the skill, that calls the python script, to create images in nano banana.

We're managing all the context to only be available when it's needed, keeping all other instructions out.

Does that help?

It's also deeply interesting because it's essentially unsolved space. It's the same excitement as the beginning of the internet.

None of us know what the answers will be.

So a Skill is just a smaller granulatrity level of that concept. It's just one of the individual things an MCP can do.

This is about context management at some level. When you need to do a single thing within that full list of potential things, you don't need the instructions about a ton of other unrelated things in the context.

So it's just not that deep. It would be having a python script or whatever that the skill calls that returns the runtime dependencies and gives them back to the LLM so they can refactor without blindly greping.

Does that make sense?

I am not sure where exactly we are headed through all this, but I feel like overall having data be a shared commons has been beneficial.

I am working alone. So I am instead having plans automatically update. Same conception, but without a human in the mix.

But I am utilizing skills heavily here. I also have a python script which manages how the LLM calls the plans so it's all deterministic. It happens the same way every time.

That's my big push right now. Every single thing I do, I try to make as much of it as deterministic as possible.