can’t throw a rock without hitting someone’s bespoke cc workflow so here’s mine. it’s gonna be kinda here and there but that’s pretty much how I use it

claude three ways

I basically have three modes that I use cc in; simple/defined tasks where I’m paying attention to the output/outcome, big chunks of medium-specified work, and focused refinement of the former.

the first is the easiest to understand and maybe the “default” way I see other people using cc. you ask for a specific thing (“why does this error happen”, “how can I set up tmux locally, can you do it”, “what does this program do”), and you pay active attention to the agent while it does its thing. in this case I’m usually paying a lot of attention to the tools it’s calling or what it’s writing/editing and I often ask for explanations of why. it’s slow, but I’m trying to understand stuff in this mode. i also do this when I’m having claude work on technical documentation or doing PR review with me.

the second is a bit more interesting and flies in the face of a lot of “best practices” but if I’m building a feature or some larger piece of code where I know what I want to do, I’ll usually do some prompting/planning to have the agent explore an existing codebase and see how we do things already, and sketch out a design. I try to work in chunks that make sense to me - often I’ll discover new things as I build it that I want to tweak or change, and I’ll just keep churning along.

this produces a lot of pretty bad code to be sure, but I find it more valuable to get something working that I can touch and think about. sometimes I’ll realize the best thing to do is something else, and I’ll revert the branch and start from scratch with better prompting to focus the design more.

a note - in this mode, I’m skipping permissions and just letting claude do its thing.

once I’ve got something that works, I’ll usually skip into the refinement phase. here I tend to be a lot more methodical and use various skills (like ed3d’s superpowers variant) after having claude do a lot of review and documentation on anti patterns, dead/duplicate code, etc. this phase can take a while depending on how far/much work I did in the earlier phase.

I don’t think this is, like, the one true way to do this stuff but it works for me.

the thing that I find most helpful in all of these cases is that I have some way for the agent to automatically get feedback on what it’s doing. either I’m sending telemetry into honeycomb and letting cc read it back out, or having a lot of tests, or having the agent run things in tmux and reading the buffer — there’s always some sort of feedback loop. I also like to build a docs folder with links to external doc sources (or just include markdown docs for stuff) that it’s working on. for oss libraries I like to check out the lib from github and add it to my working session and tell the agent it can look at the underlying code for a framework if it has any questions, stuff like that. it helps! the key to being effective with this stuff is mostly giving the agent the ability to understand how/why it’s failing and let it self-correct.