A few things that have worked well for me:

  - 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 tokens

Real-time web data access capability.

I don't know if it's just my perception, but I think the "channels" feature is massively underestimated. I get that it's basically their response to openclaw, and people kind of had enough of that stuff, but having my agent in my favourite messenger is a game-changer for me.

It'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

When you run into a bug/problem, asking it to find the source instead of asking it to fix it

I think one of my favorite workflow hacks is to instruct the various harnesses to use the same format for writing handoffs, instructions, and context for me and for the next agent.

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.

Cancellation of the subscription.

Now I am happier. Worked great!

I use chaptgpt to give me the claude prompts so they cover everything I need and it works so well!

I can do thing that are good

It may not qualify as a hack, but I use Soonpatch to paste a slack link and get the bug/improvement solved in the proper repo right away, no matter in which directory I call it

Firstly the obvious ,start with a clear plan and write them down in a md file that you work together with it. Execute things in chuck and always updating the docs as it goes and taking note of any deviations or changes from initially set rules and assumptions.

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.

Be careful about which model you use with Claude;

https://news.ycombinator.com/item?id=48586039

drop horizontal layers architectures and focus on vertical-slices. This alone reduces the needed context window per feature by an order of magnitude.