I hope self-promotion isn't frowned upon, but I've been spending the past months figuring out a workflow [1] that helps tackle the "more complicated problems" and ensure long-term maintainability of projects when done purely through Claude Code.

Effectively, I try to:

- Do not allow the LLM to make any implicit decisions, but instead confirm with the user.

- Ensure code is written in such a way that it's easy to understand for LLMs;

- Capture all "invisible knowledge" around decisions and architecture that's difficult to infer from code alone.

It's based entirely on Claude Code sub-agents + skills. The skills almost all invoke a Python script that guides the agents through workflows.

It's not a fast workflow: it frequently takes more than 1 hour just for the planning phase. Execution is significantly faster, as (typically) most issues have been discovered during the planning phase already (otherwise it would be considered a bug and I'd improve the workflow based on that).

I'm under the impression that the creator of Claude Code's post is also intended to raise awareness of certain features of Claude Code, such as hand-offs to the cloud and back. Their workflow only works for small features. It reads a bit like someone took a “best practices” guide and turned it into a twitter post. Nice, but not nearly detailed enough for an actual workflow.

[1] https://github.com/solatis/claude-config/

> Ensure code is written in such a way that it's easy to understand for LLMs;

> Capture all "invisible knowledge" around decisions and architecture that's difficult to infer from code alone.

I work on projects where people love to create all sorts of complex abstractions but also hate writing ADRs (so they don’t) or often any sorts of comments and when they do they’re not very well written. Like the expectation is that you should call and ask the person who wrote something or have a multi-hour meeting where you make decisions and write nothing down.

That sort of environment is only conductive to manual work, dear reader, avoid those. Heed the advice above about documenting stuff.

> Ensure code is written in such a way that it's easy to understand for LLMs

Over the summer last year, I had the AI (Gemini Pro 2.5) write base libraries from scratch that area easy for itself to write code against. Now GPro3 can one-shot (with, at most, a single debug loop at the REPL) 100% of the normal code I need developed (back office/business-type code).

Huge productivity booster, there are a few things that are very easy for humans to do that AI struggles with. By removing them, the AI has been just fantastic to work with.

Thanks for sharing and taking the time to document your repo. I’m also sometimes unsure of “self-promotion” — especially when you don’t have anything to sell, including yourself.

I sometimes don’t share links, due to this and then sometimes overshare or miss the mark on relevance.

But sometimes when I do share people are excited about it, so I’ve leaned more to sharing. Worst is you get some downvotes or negative comments, so why not if there is some lurker who might get benefit.

When you don’t blog or influence, how else but in related HN comment threads are like-minded people gonna know about some random GitHub repo?

My second level hope is that it gets picked up by AI crawlers and get aligned somewhere in the latent space to help prompters find it.

ETA: “The [Prompt Engineer] skill was optimized using itself.” That is a whole other self-promotional writeup possibility right there.