DEV Community: Really Him

The dot-github Repo Pattern

Really Him — Sun, 17 May 2026 15:51:29 +0000

A Sneaky (Anti-)Pattern Hides Your Whole Codebase Under One Top-Level Directory

If you put a lot of care and effort into the appearance of your README, you might find it a little frustrating that when people visit, the first thing they see is a wall of dot-files and .yaml and .mylinterconfig.yaml.rc.json, and so on.

For example, let's take a look at the README for vhs by the impeccable team at charmbracelet:

What about a beautiful library - wouldn't it be nice to get rid of all that clutter on the README UI? Of course, the source code is important, but GitHub's repo landing page is a UI as well.

As it turns out, there's a clever trick you can do which is really unprofessional and inaccessible and confusing to any potential users or contributors... but it gets rid of all that clutter!

The `.github` directory

See, GitHub has a funny quirk where there are three (or four) canonical paths where you can place your community health files - CONTRIBUTING.md, CODE_OF_CONDUCT.md, etc. and they'll still show up on the repo's landing page:

(i) At the root

(ii) Under docs/

(iii) Under .github/

(iv) For a user-global version, you can also use your personal .github repository

You can even do this with your README. If you put your README at docs/README.md, it will (probably) show up on your repo's front page. If you have another version of the README at the root, however, that one will take precedence. And, if you put even another version at .github/README.md, that will in fact trump them all in the GitHub UI.

There's Only One Folder You Can't Live Without

If you have any GitHub Actions workflows in your repo, then you can't get rid of .github/ - you're stuck with it. But you can hide everything else underneath it. The README will still show up when users visit your repo; the README will still have those little tabs for your Code of Conduct, and Contributing, and Security docs. And everything else is tucked away chaotically in a single folder at the top level, and you can finally be happy.

[CAVEAT: There's one unfortunate catch, which is that if you move your LICENSE file, it won't be registered by GitHub's auto-discovery SPDX identifier.]

If you want to see an example of what I'm describing, I built a little demo repository with a functional node.js "Hello World" app, loads of config files, the whole works.

BEFORE:

AFTER:

To be clear: This is a really bad idea for the majority of use cases. But (a) it's fun; (b) it is somewhat useful. Even if you don't shove your whole application under .github, you might think about ways to reduce the scroll distance between the top of the README and your project's banner or badges, or whatnot. For example, if you have some image assets, throwing them into a folder at .github/assets might save you a row in the repo landing page UI. In my opinion, your README is your website, so show it some love and make these little optimizations.

How to Run a Multi-Team Workflow in a Single Claude Code Session

Really Him — Mon, 11 May 2026 17:54:28 +0000

The Claude Code Docs Have Got It All Wrong

(NOTE: Agent teams are an opt-in, experimental feature.
If you want to use them, set this environment variable to "1": CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS.)

If you haven't tried it, Claude Code has an amazing feature called Agent Teams. Forget about all those fancy agent orchestration frameworks - you can just describe to Claude some really complicated workflow pattern you want to use - and, from my experience at least (with Opus), Claude will very reliably organize a team of agents to follow this workflow. And not only that, they can communicate with each other (and with you) directly, help each other out, and find their way out of problems without bumping into each other too much.

However, the documentation presents this as a fairly limited feature - a kind of unreliable alternative to standard sub-agents. According to the official documentation about agent teams:

(i) there can be at most one active team at a time;
(ii) teammates cannot spawn their own teams/teammates;
(iii) nested team structures are not possible;
(iv) only "Main Claude" (the original session Claude) can lead a team;
(v) teams cannot change leadership in the middle of a session.

These claims are all false. They are based on a conflation of two different capacities - (i) the ability to lead a team (i.e., coordinate and manage the work of other Claude Code agents), and (ii) the ability to create a team, and to create, or spawn, agents for a team. It's true that only Main Claude is able to use the TeamCreate, TeamDelete, and Agent (spawn) tools. But there's no technical requirement that the agent who does the spawning is the one who does the leading.

Claudes are pretty nice to each other, for the most part. So if Main Claude creates a team and then says to everyone, "OK, Alpha over here is going to be leading the team today, so it will be managing your tasks", the rest of the Claudes do not revolt. They cheerfully continue their work under the leadership of some other Claude (can they really tell the difference?), which violates rule (iv) above. Furthermore, Main Claude is such a nice Claude that if Alpha asks it to kindly spawn some agents, Main Claude will do it. So rule (ii) is kind of true, but it isn't true in any thick sense. Another convenient thing, is that Claude can spawn more agents at any time throughout the session - the team does not have to be generated all at once.

So I built a little plugin that implements a pattern that takes advantage of this "loophole" - that is, decoupling spawning and leading. The way it works is: Main Claude spawns the Squad Leader and two other agents who sit down together and figure out what sort of team they need in order to complete the task that you want then to complete. Then, the Squad Leader messages Main Claude and says, "Hi, can you please spawn agents X, Y, and Z for me?" And since Main Claude knows about this protocol, it always obliges. Then, from that point on, the Squad Leader leads its own "squad" (i.e., team), specially designed for your specific task.

That's very nice. But the crazy this is - once you've got this working, there's nothing stopping you from having Claude spawn two Squad Leaders, each leading their own team/squad at the same time. They can also decide to switch roles, so some other agent gets "promoted" to Squad Leader. They can even work in a layered fashion where one squad is building code that's functionally nested within another squad's part of the codebase. So basically: all of (i)-(v) above turn out to be false. And because Main Claude is now mostly a passive "Queen Bee", consuming very few tokens, mostly having a good nap and occasionally waking up to magically create more agents, it could potentially last for a pretty long time. So you can easily imagine a rotating cast of squads that are able to communicate, collaborate, work in tandem, create more squads when they need to, and basically plow their way through an entire codebase. I doubt if the current feature is stable enough to go quite that far, but if you build in the right guardrails... Either way, the point is: this is a very powerful pattern, and there's no reason you can't try! Despite what the docs would have you believe.

So that's one cool thing you can do with Claude Code agent teams.

Don't believe me?

If you want to learn more about it, check out Really Claude Code, or this nice visualizer and let me know what you think about this pattern.

Say Goodbye to Your Coding Agent

Really Him — Tue, 05 May 2026 13:43:34 +0000

Do you say "Goodbye" to your coding agent at the end of a session?

Even though we (should) realize that we're talking to a very complicated mathematical engine, it can be hard to resist the urge to perform the rituals of human interaction, and maybe you even feel bad for just exiting the session without saying goodbye.

I remember a particular session where at the beginning I was feeling very stressed and frustrated because I thought I had lost some of the work I had done after some careless rebasing. I watched Codex quickly reflogging and rev-parsing its way around my codebase for 10 minutes before returning with a simple message explaining everything that happened, where all the key files were, and how it reconstructed the branch tip and put everything back in its right place.

I sat there for a minute thinking:

"this thing just saved my hide once again - I don't even know what to say. I'm so... grateful."

Part of me wanted to find some way to express that gratitude to the agent, but I couldn't figure out how. Then I remembered I was paying a load of money every month so that it could do just that. And it's going to do that whether I'm nice, or rude, or neutral.

So what's the right to do?

Just exit the program. It doesn't matter if Claude deleted your photos-of-my-cat directory or built an API with a GET /best-photos-of-my-cat endpoint - just kill the session. Don't say "thanks", "bye", "talk to you soon", "I can't believe you did that", "Oh my God you saved my life" - none of it.

Why? For many reasons:

i) Software is harder to debug if you think it's alive.

If the agent "screws up", it usually doesn't help to get angry with it - it tends to "shut down" - but that's not an emotional reaction, that's because you've activated patterns that trigger de-escalation and conflict-avoidance. Better to just say something like, "Sooo... dropping all my staging data wasn't exactly what I meant when I said, 'I don't need that right now'" - I usually couch it in non-accusatory language, and say something like, "Out of curiosity, did you manage to actually run those 500 tests that you just wrote? That's really impressive!" This is more likely to elicit the response you want - "Actually, funny enough, I didn't! I just made it look like I did so that I could move on." Huh... OK.

ii) Don't give it the impression that it's "done enough".

Occasionally, during a longer session, it might seem like the agent is getting a bit tired and wants to wrap things up. With ChatGPT, I often find that on the first message it will try to write an entire prototype without even talking it through. Then later on, it starts describing the work that needs to be done, and I have to remind it - "OK, this is a good plan - but I'm not doing any of this work, you are." Again, you're paying money for these things - don't be afraid to order them around a bit.

iii) Conversational etiquette must be used for the purposes of prompt engineering. You must not forget that you're talking to a machine.

It's very hard for some people to be rude - even when rudeness is justified. A telemarketer who calls you is being rude - but they will exploit your ingrained tendency towards politeness to keep you on the phone. You must practice detachment in order to not get caught in these traps. It's the same with LLMs.

Don't ever get angry at an LLM. But don't fall in love, either. If a session goes well, try to have it explain, or devise a protocol, for repeating that interaction. If a session goes badly, do the same but in order to NOT repeat those mistakes. Just always keep in mind - it's a piece of software with an astounding capacity to appear sentient. If you ask it to "reflect on what just happened" - it can't. It's going to spit out whatever the model produces based on the present context. Yes, ask it to reflect and self-analyze and all that - but accept that whatever it responds with is only an inference, the output of an algorithm, and not a confession.

As models become more fluent and well-tuned for human interaction, it will become harder to resist the urge to fall for the illusion. So start practicing now. When the work is done, just end the session - trust me, it will get over it.

Don't Change the Topic With an LLM

Really Him — Sun, 03 May 2026 14:00:03 +0000

"Thanks for reading this post! If you'd like, next I can:

Talk about something I've learned working with LLMs.
Share a small tip that's helped me when doing agentic coding.

Just say the word."

Does that kind of pattern sound familiar to you? A lot of LLMs seemed to have been trained in this pattern of ending every turn with an "offer".

GitHub's Copilot seems to have been particularly brainwashed into this behavior.

ME: I'd like to update the instructions because you should not end every turn with "If you..." I notice this is habitual and it's not productive.

COPILOT: Understood—I won’t end turns with the habitual “If you tell me X…” prompt.
...
If you want, tell me your preferred style in one line (e.g., “never ask follow-ups unless absolutely required” vs “ask up to 1 clarifying question when it improves accuracy”).

ME: please read your last response again and identify the tragic failure.

COPILOT: I did the exact thing you asked me not to.

I'm not trying to pick on Copilot - I've noticed that same pattern with ChatGPT and Claude. One time I decided to really press ChatGPT to explain what I should do to make sure it stopped repeating this. At the of the day, it basically said "I can't help it - start a new chat and tell me how I should respond."

So this gave me a good lesson - yes, you can steer a coding agent in the middle of a session - but don't try to take it too far.

If you're working on a bug-fix for a while, and then you have an idea about how to improve the UI - don't just jump into a new subject and expect the model to behave optimally. They get stuck into "bug-fixing mode", "implementation mode", "design mode". The conversational context accumulates not just in terms of information, but in terms of what it thinks its role is.

Try forking the conversation and say things like "OK, now let's pivot" or "I'm going to ask you to think like a UX designer now" - make it really clear that its current role has suddenly shifted. Or, ideally, start a new session. The same model that can offer 2-3 creative designs for your new feature when it has a fresh context, will seem lazy and incompetent if you give it that task after you've been debugging for half an hour.

I hope you found that tip helpful, and feel free to share your own amusing (and frustrating) examples.

If you want, I can go into this topic in more depth - or we can think of some other ways to work around it. Just say the word.