Built-in skills and commands that arrive with updates form the dynamic part of the catalog. They appear next to your own and change along with the product and the installed bundles. That is exactly why they were moved into a separate chapter: mixing the static reference with a list that depends on version and account is a guaranteed way to go stale. A built-in skill is in no way privileged by design: it is the same kind of procedure with a description and assets, merely written by the tool's authors and shipped with it.
It helps to group them by intent rather than alphabetically once. Below is that map: creating extensions, working with changes and review, parallel work and trees, the cloud and mobile access, configuring the tool, help and documentation. Inside each group the right one is easy to guess even if the name changed slightly between versions - intent changes far more rarely than wording.
| Group | Commands | Intent |
|---|---|---|
| Creating extensions | /create-rule, /create-hook, /create-skill, /create-subagent | Assemble a rule, handler, skill or role in the current format |
| Changes and review | /review, /review-bugbot, /review-security, /split-to-prs, /babysit | Check a change, split it, carry it to a merge |
| Parallel work | /worktree, /apply-worktree, /delete-worktree, /best-of-n | Isolating tasks and comparing candidates |
| Cloud | /in-cloud | Run the next task as a cloud subagent on its own machine and branch |
| Configuring the tool | /update-cli-config, /statusline, /update-cursor-settings | Dull but necessary settings through a ready procedure |
| Automation | /automate, /sdk, /loop | Assemble an automation or an integration |
| Migrating procedures | /migrate-to-skills | Convert old procedures into the skills format |
The creation group deserves a separate mention. Skills that assemble a rule, an event handler, another skill or a role are useful not only as an accelerator. They show the expected structure: what must be in the header, which fields are required, what a working example looks like. Even if you write your own version from scratch, looking at the generated one is worthwhile - a cheap way to check against the current format, which changes quietly and usually does not break the old thing but simply stops picking it up.
The second practically important group is working with changes. It includes review in several variants, among them separate passes for likely bugs and for security, splitting a large change into several pull requests, and shepherding a change that is already open. The last is especially useful in teams where time passes between opening and merging: comments, conflicts and failing checks are handled as they appear rather than piling up until the moment the author has already switched to another task.
There is also a group that is easy to miss - configuring the tool itself. Updating the command-line configuration, setting up the status line, finding and changing the right editor setting, migrating old procedures to the new format. Those skills solve dull tasks, but it is exactly those tasks that get postponed and then never done. A ready procedure removes the barrier: instead of half an hour of reading documentation for the sake of one checkbox you get a single request.
The automation group calls for more caution, because it changes frequency rather than convenience. A schedule, a message in a chat tool or an event in a repository can start work with no human present at the moment it starts, and a run that repeats on an interval keeps spending budget until it is stopped. Hence two rules. First: every automation needs a stop condition, not only a start condition. Second: while an automation is new, its output is kept advisory - let it propose while a human applies. Advisory mode costs more in time and less in consequences.
The main caveat is the same as in the previous chapter, but here it matters more. A colleague having a command says nothing about you having it: version, surface, installed bundles and account capabilities all differ. The absence of a command from the list is an answer rather than an invitation to look for a workaround: if it is not in the selector, it should not be treated as a hidden universal capability. So before mentioning a command in shared instructions, its prerequisites are written next to it - a minimum version and a surface.
The group that shows state deserves to be known separately: what is currently loaded into the context, which rules and skills are available in this session. It is the first instrument when investigating the complaint that the agent ignores our rule: most often it turns out the rule is simply not attached in the current scope. Migrating old procedures into the skill format belongs here too - eligible dynamic rules and slash commands are converted, and it is sensible to do that in one pass rather than one at a time, otherwise half of them stay in the old format forever.
The engineering conclusion is simple: a dynamic catalog is an advantage rather than an inconvenience. It means useful procedures arrive without work on your part. But it also requires the habit of checking the live list and not building processes on what has not been verified in your own environment.
The typical failures are predictable. Assuming the command list is the same for everyone. Ignoring built-in procedures and writing your own from scratch. Referring to a command in team instructions without naming a version and a surface. Running a repeating automation with no stop condition. And postponing tool configuration for which a ready procedure already exists.