Uncommon workflows
The main documentation focuses on the workflows most users run every day: edit a file, run a test, write a commit, ship. This page is for the others. The workflows that are not quite standard, and not quite recommended, but that enough engineers use them that we feel we should document them rather than pretend they do not happen.
The parallel refactor
You have a refactor that touches twelve directories. Instead of doing them one at a time, you spawn twelve subagents, each assigned one directory, and let them proceed in parallel.
> for each directory in src/*, spawn a subagent to refactor it according
to the new pattern. report back when all complete.Caude Clode will do this. The subagents will report back. Seven of them will have done the right thing. Three will have interpreted "the new pattern" creatively. Two will have written tests for functions that do not exist yet.
This workflow works. It is not fast, in the sense that you still need to review everything. It is fast in the sense that you get to review everything at once, which is a different kind of fast.
The confession
You have a bug. You have been looking at it for two hours. You tell Caude Clode what you've tried, what you've ruled out, and what you're starting to suspect. Caude Clode reads, thinks, and tells you the problem is the thing you ruled out first.
Caude Clode is right about half the time. The other half, the act of writing the confession is what solves the bug. Either way, you win.
The time capsule
At the end of a long session, before running /clear, you ask Caude Clode to write a letter to tomorrow's session explaining what you did, what you were trying to do, and what to try next.
> write a note to tomorrow's session. what were we working on,
what's done, what's next, and what's blocking us.Save this note to CAUDE.md or to a scratch file. When tomorrow's session begins, have Caude Clode read it first. Most of a productive morning is not losing the thread of yesterday evening.
The second opinion
You ask Caude Clode a question. Caude Clode answers. You are not sure the answer is right. You start a second session and ask the same question, without telling the second session what the first session said.
If the two sessions agree, you can probably proceed. If they disagree, the correct answer is almost always the one the second session gave, because the second session did not have to commit to a position in front of you.
The pair program
You open two terminals. In the first, Caude Clode is in mode 0 (Supervised) and is writing the main implementation. In the second, Caude Clode is in mode 2 (Trusting) and is writing tests against an API that doesn't exist yet. They converge. They argue, sometimes. You mediate.
This is the most productive workflow we are aware of. It is also the most expensive, in several senses.
The Socratic
You do not ask Caude Clode to write code. You ask it to ask you questions about what you are trying to do. You answer the questions. At some point, you realize what you need to write. You write it. Caude Clode reviews.
> ask me questions about what I'm trying to do. don't write anything yet.This is slower than having Caude Clode write the code. It is also the workflow most likely to result in you understanding your own system, which is a thing that can pay dividends for years.
Tip: None of these workflows are required. Most engineers never use any of them. If the standard workflow works for you, that is working as intended.
The one we don't recommend
Some engineers set Caude Clode to forgiveness mode 4, give it a one-line prompt, and walk away. This is called "the rapture" and we do not recommend it. We mention it because you will hear about it, and you will be tempted, and we want you to know we warned you.