Pairs where one command is an alias of another deserve a separate note. They exist for historical reasons: the name changed and the old one was kept for compatibility. In scripts and instructions the primary name is better - an alias may disappear one day, and that will be a silent breakage in the most inconvenient place. Silent, because an unknown command usually does not crash the session; it simply fails to do what was expected of it, and the person notices only later.

A practical habit that saves time: type a slash and look at the hint instead of trying to remember. The live menu reflects your version, your plugins and your account's capabilities - that is, what is actually available. Memory reflects an article read six months ago, and an article written for a different surface. The gap between those two lists is the source of most questions of the form why do I not have this.

The dynamic list has a flip side: it can be long. So it helps to pick a dozen commands you use daily once and turn them into reflexes. Usually that is checking the state, switching the mode, viewing changes, compacting the history, starting a review and quitting. The rest is looked up as needed - and that is exactly why knowing the groups matters: search by meaning works in an unfamiliar version too.

Session commands are worth telling apart by price rather than by name. Starting a new session means losing all the context accumulated: a cheap operation when the previous task is closed, an expensive one when you are merely tired of a long exchange. Forking keeps the original session untouched and therefore suits an attempt you are unsure about. Jumping back to an earlier message rewinds the conversation. Compacting the history reduces the context, but it reduces the detail along with it: what the agent remembered verbatim survives compaction as a retelling. Hence the practical rule: compact earlier than it becomes a forced measure.

The diagnostics group is needed exactly once, but then it is needed immediately. When behavior looks wrong, the first thing done is taking the debug log path, the request identifier and the conversation identifier. Those three things turn a message saying it broke into a report that can be answered. To them is added the output about the version, the system and the account: the answer to one and the same question depends on the build, and without a version a conversation with support starts with clarifications. All of it is worth collecting before a restart rather than after - a restart is often exactly what erases the interesting part of the log.

The engineering conclusion is simple: a command reference is a map of capabilities rather than a list to memorize. Knowing the groups is more useful than remembering names: knowing the group, you find what you need in seconds even in a new version where some names have changed. And knowing a command's price is more useful than knowing its syntax.

The typical failures are predictable. Using an alias in team instructions and getting a silent breakage one day. Looking for an editor command in the terminal. Memorizing the list instead of using the hint. Starting a new session where forking would have been enough. And building a process on a command whose availability in your version has not been checked.