Picking a workflow by model: when to brainstorm, when to advise, when to skip the plan step entirely

Article 12 in the AgentKit v3 onboarding series. About a 9 minute read.

Lately on Discord I have been sharing my new workflow with Opus 5.5: no more plan → clear → cook. And of course you all piled on with questions 😂 "So where does /ak-brainstorm fit?", "Do I use /ak-advise instead of brainstorm, or together?", "Do I need a worktree for every session?".

This article answers those questions in one go so I can stop repeating myself.

1/ Why does a strong model not need a separate plan step anymore?

The reason is simple: Opus 5.5 sticks to the goal really well. Hand it a clear destination and it splits the work, checks itself, and walks all the way to the end. Making it write a plan to a file, /clear the context, then re-read the plan to cook often just burns extra tokens without adding quality.

But there is a trap. A model that is good at sticking to goals sticks to a vague goal just as faithfully. Garbage in, garbage out. A fuzzy prompt gives fuzzy results, just delivered with a lot of confidence 😁

So with a strong model, the most important job is no longer writing a plan. The most important job is locking the DoD (Definition of Done): when is it done, and how do we verify it. You and the agent have to be looking at the same finish line.

2/ AI can build almost anything, which does not mean you should build everything

AI makes building dangerously easy. Think of something and you have the code in minutes. But easy to build does not mean worth building 😁

So I always open every AI session with a brainstorm, split into 4 questions, in order:

1. The idea is [...], the goal is [...]. Interview me until you understand exactly what I am thinking, then review, research, analyze and propose.

2. Is there anything I missed? Anything I have not thought of?

3. Do I actually need to build this? Are there risks or trade-offs I should know about? Is there a better approach? Where is the evidence?

4. If I still decide to build: is everything simple enough to implement and easy enough to change later? Any technical debt? When should I stop?

Do not ask all 4 at once. The answer to the previous question shapes the next one. Asking one at a time lets the AI focus completely on one thing and give its best suggestion. Question 3 is the most important, because quite often the right answer is "don't build it".

The sequence I always follow is:

problem → verify → challenge → decide → lock requirements → implement

At the "lock requirements" step, let the AI interview you a second time. The first round is to understand the idea. The second round is to make sure you are both on the same page: the AI understands exactly what you expect, and you lock the scope of work and the DoD. That is exactly the job of /ak-advise.

Only then do you implement, ideally in a brand new context, with the decision brief (the summary of the decisions and DoD you just locked) as input. A clean context means the agent does not get pulled off course by directions you already discussed and dropped.

Two more pieces of advice:

• Don't ask "which skill should I use for this". Learn to ask good questions. With a good question, any skill gives good results.

• Stay flexible. Changing a button color does not need this whole heavy process. The process serves work worth doing carefully; it is not there to slow down everything.

3/ Two workflows, chosen by model

The old workflow is still right for smaller models. Small models drift easily when the context gets long, so writing the plan to a file and then /clearing so they re-read it with a clean context is still the safest way.

The workflow for strong models, step by step

Step 1: run /ak-advise. It interviews you with a few questions, one at a time, to understand your expectations and requirements and to lock the scope of work. Answer for real, not just to get through it.

Step 2: read the advice and the DoD it prints carefully. In there is a Done means section: a list of verifiable end states, like "every endpoint uses the new client, the old client is deleted, the test suite passes". Words like "better" or "cleaner" do not count as DoD. If something does not match your intent, fix it right now, because this is the cheapest place to fix it.

Step 3: jump straight into /ak-cook. No plan, no clear. If you want to go all the way to a PR in one run, use /ak-vibe --ship instead of cook.

/ak-advise add Google login to the app, keep the existing email login as is
# answer the interview, re-read the DoD, edit if needed
/ak-cook

4/ So where does /ak-brainstorm still fit?

It still has a place. This is how I tell them apart:

• /ak-brainstorm: when you are not sure what to do. It helps explore ideas, lay out the possible directions, compare pros/cons and trade-offs.

• /ak-advise: when you already know what you want, and you want the agent to understand exactly what is in your head.

You can use both together. If the idea is still foggy, brainstorm first to pick a direction, then advise to lock the scope and DoD, then cook:

/ak-brainstorm → /ak-advise → /ak-cook   (or /ak-vibe --ship)

If the task is already clear, skip brainstorm and go straight to advise to save time.

5/ Do you need /ak-worktree for every session?

Not for every session. The rule I use:

• One session doing one job on one repo: no worktree needed, work directly on the branch.

• Multiple sessions running in parallel on the same repo: use /ak-worktree, one worktree and one branch per session. The reason is that two agents editing the same directory easily stomp on each other's files, switch each other's branches, or commit each other's changes.

One small note: if a worktree has a dev server or watcher, remember to kill the process before deleting the worktree, or your machine fills up with orphaned processes.

Wrap-up

1/ Strong model: /ak-advise → re-read the DoD → /ak-cook. The time you spend goes into locking the DoD, not into the plan.

2/ Smaller model: keep brainstorm → plan → clear → cook.

3/ Don't know what to do yet? Brainstorm. Already know? Advise.

4/ You only need worktrees when multiple sessions run in parallel on the same repo.

5/ Before building, ask "do I actually need to build this?". Ask one question at a time, then implement in a fresh context with the decision brief. For small tasks, skip the process.

Sources

• Discussion on the AgentKit Discord, 29–30/10/2026.

• Descriptions of the ak-advise, ak-brainstorm, ak-cook, ak-vibe, ak-worktree skills in the ak 3.0.0 kit.