Buck Workflow

Talk it through before you know exactly what you want to build. /b-brainstorm is for the stage where the idea is still loose and you want a real back-and-forth with the agent to help flesh it out. Sometimes that means clarifying what you already have in mind; sometimes it means discovering a better shape for the idea while you're talking.

It is not locked to the start of the workflow. You can begin with a brainstorm, move into a plan, then brainstorm again once you see the plan more clearly. Or you can do one brainstorm and go straight into /b-build. The point is not to follow a ritual. The point is to have a place where thinking stays loose until you're ready to make it concrete.

When I reach for it. When I do not know exactly what I want yet and I want the agent to think with me instead of prematurely turning the idea into a plan. How often I use it depends on how much detail and control I want. There are no rules.

Figure out what the local codebase actually does before you touch it. /b-explore is the internal investigation step. It is not for web research; it is for tracing unfamiliar local code, mapping architecture, following data flow, and figuring out what a project is doing before you try to plan against it.

This is the one I reach for when I need to refresh my memory on a project or when I do not know enough about the local code to trust my assumptions yet. It stays read-only, writes findings into .context/, and is especially useful in a sub-agent because it keeps the exploration work from bloating the main session context.

When I reach for it. When I do not know how a project works, what a subsystem does, or where something lives yet. It is the local file and architecture pass I do before planning, or anytime I need to re-orient myself without changing code.

Go gather what you do not know yet. I tend to use /b-research after a brainstorm or a plan, when I know the shape of the question but I do not know enough to make the decision yet. It pulls from my Obsidian notes, the web, and places I already trust to look for real opinions and implementation detail.

This is the step for closing knowledge gaps. Which library should I use? Which tool fits this problem better? What does the API actually look like in practice? /b-research is there for the moments where moving forward without more context would just mean guessing with confidence.

When I reach for it. Usually after /b-brainstorm or /b-plan, but it can come first too. Like the rest of the tools, it is not limited to one place in the process. I use it whenever the next decision depends on information I do not have yet.

Stress-test the idea before you hand it off. /b-grill came out of Matt Pocock's grill-me idea, but with some limits added because a full grilling session can get exhausting fast. This version usually aims for around 20 questions. It can go over, but that threshold is where it starts thinking about whether the work is big enough to phase.

You can use it anywhere: hand it a plan, a brainstorm, a file, or just raw context and let it start pushing on the edges. When you use it inside Buck Workflow, it keeps updating the same subject files, memory, and surrounding artifacts rather than spinning off into a separate track. Its job is to really flesh something out before you move into /b-plan or /b-build. It is incredibly useful, but also tedious if you use it for everything, which is why it is tuned to stop short of becoming the whole workflow.

When I reach for it. When I want pressure on an idea before I commit to it. Sometimes that means the full session; sometimes it means telling it to stop at five questions, then reevaluating. Like the rest of the tools, it is available anywhere in the process — the question is how much stress-testing the idea actually needs.

Putting pen to paper without picking up a hammer. I use /b-plan when I have a pretty good idea of what I want to build and I need something durable to review and ask questions against — before any code changes. The plan goes to disk inside .context/, not into the codebase. Nothing is built yet, so nothing has to be undone yet.

What it gives me is a thing to argue with. I draft the plan, the agent helps me tighten it without padding it with extras, and I iterate on the same file until the shape feels right. Once it's on paper, the next move is locked — and that's the point. Writing the plan first is what shuts the agent up about starting to build. /b-build can then stay about the build, not about deciding what to build.

It also hands off cleanly. A future session — mine, days later, when the chat is gone — opens .context/<subject>/plan-*.md and picks up the version of the idea that already survived review. The agent that runs /b-build isn't re-deriving the work; it's executing a plan that was already pinned down.

When I reach for it. When the picture is clear enough to write down, but the work is big enough that writing it down earns its keep — multi-step, multi-file, or anything I'd want to resume. For a one-line tweak, the loop stays /b-build → /b-save; planning would be ceremony.

Break a plan down when the plan is too big to carry whole. During planning, the workflow looks at how large the plan actually is. If it is too large, it will suggest phasing it. That is where /b-phase comes in: its job is to take a set of work and organize it into phases that belong together instead of trying to force everything through one oversized session.

The point is to keep the context slim for each piece of work. Each phase becomes a smaller, more atomic set of changes that can be executed, reviewed, and resumed without dragging the rest of the project into the same context window. It is not just about making a long plan prettier; it is about making the work practical to do.

When I reach for it. When /b-plan shows me the work is too broad to carry as one unit. If a task naturally breaks into pieces that should travel together, /b-phase is how I group them so each phase stays coherent and atomic.

The build step — with or without a plan ahead of it. /b-build works two ways. If there's already a plan — or any durable artifact from /b-plan, /b-research, /b-explore, or /b-brainstorm — it picks those up and runs against them. If there isn't, it generates a quick plan of its own before it writes a line of code. Either way, it leaves a trail: the plan, the todos, the progress, all as durable artifacts sitting in .context/.

That trail is what makes the build resumable. Stop mid-feature, close the laptop, open it tomorrow on a different machine or in the cloud — the next /b-build sees where the last one left off. The work survives context loss, chat compaction, and the gap between sessions.

/b-build works ad‑hoc or as part of the entire buck workflow. The durable artifacts are what make either path usable: when you start, you pick up where the last session left off; when you stop, the next session starts from the same place.

When I reach for it. Every time I'm about to write code — whether I'm opening a fresh session on a small change or continuing a plan I already have. Ad hoc, or as part of the full loop. The durable trail is what makes the difference between work that survives a closed chat and work that doesn't.