- Like normal software engineering - building small parts in isolation, verifying they work and then bringing them together to make the whole.
- Asking Claude to do things using sub-agents to keep the parent context clean. i.e. reviewing plans, research, code reviews
- If there's ever something you can have verification on - a test suite, a screenshot with pixel reading, a certain output to match. Then with `/goal` it tends to work very well with little guidance (in my experience)
- If it keeps getting things wrong, then I make it write a skill. i.e. for some reason it always had errors running playwright but would get there in the end, and it would always have trouble with auth on my NAS but with the skill it can follow the path that's worked for it in the past and not burn tokensIt's different for me from just app chat, because I have some specific custom workflows and tools I gave to the agent, and, yes, all of the nice stuff mentioned in other comments
Instead of a Claude.md file, I have all my agents look for and use a generic, agents.md, file and a create/update a humans.md file throughout projects. Regardless of whether I'm using the CLI or a harness app, I almost always create a new folder for new projects, and I'll use subfolders for subprojects.
The humans.md file is for me so I can look at it and remember which harness I was using last. If this was a Claude project, a Codex project, or an OpenClaw project, etc. It also includes some human-readable details to bring me up to speed with the project context. I found this makes it a lot easier to switch models mid-project.
I achieve this by:
Asking it to create test scenarios and documentations as it builds.
Along with the CLAUDE.md also ask it to create area specific files (example: frontend, backend, security, database, testing) all being referenced in the main CLAUDE.md where it saves the detailed rules for that area. This would help immensely when the project grows avoid hitting the CLAUDE.md file limit.
Now I am happier. Worked great!