A separate group are commands tied to a particular surface: working with trees, comparing several candidates, moving a task to the cloud, shepherding changes. They are not required to appear in the static command-line reference and are not required to exist everywhere at all. That is not a shortcoming but a consequence of surfaces being different: some procedures only make sense where the corresponding interface exists. Comparing options is needed where they can be shown side by side, and working with trees where there is something to switch to.

That is exactly why such things are spoken about with a date and a caveat. The security check and review are available in certain versions and on certain surfaces, while support in the command line may be announced as coming. Passing an editor skill off as a terminal command is a typical mistake that breaks automation on someone else's machine where that surface simply does not exist. And it does not break at once: on the author's machine everything works, so the cause is looked for in the colleague's environment rather than in the procedure itself.

It is worth picturing in advance how that looks. A team writes a review step before merging into its documentation and names a specific command. For people working in the application the step passes. In an automated run on a server that has only the command line the step is missing: the command is unknown, the call ends in nothing. The sign by which this is caught is an unpleasant one - not an error but silence: the check does not complain because it never ran. Hence a rule: a procedure a merge decision depends on must fail when it cannot run rather than be skipped.

The practical technique here is simple: before building a process on a command, check that it exists in your environment and record that in the process description. One line of the form requires version at least such-and-such and this surface saves a colleague an hour of investigation. It is the same reproducibility discipline as with the tool's version: a process must name its prerequisites. And they are better checked at the start of a run than at the moment the relevant step comes up.

The boundary between a built-in procedure and your own is drawn by knowledge of the repository. The built-in one knows the general shape of the task and knows nothing about your check commands, your directories and your boundaries. Your own knows that, but it has to be written and maintained. A sensible order is to start with the built-in one, see where it misses, and write your own only where the miss repeats. Copying a built-in procedure wholesale for the sake of one edit is not worth it: the copy stops receiving updates, and a few versions later you are maintaining it instead of using what ships.

The engineering conclusion: built-in skills are useful as a quick start and as a sample. Even if you eventually write your own procedure, it is worth looking at the built-in one - it shows the expected structure and the typical steps. And for repeatable work specific to your repository you still need your own skill: the built-in one does not know your check commands and your boundaries. A healthy ratio looks like this: the built-in ones cover the general, your own cover what makes your project different from any other.

The typical failures are predictable. Treating the command list as permanent and copying it into team instructions. Passing a skill of one surface off as a command of another. Building automation on a command whose availability has not been checked and not noticing the skipped step. Copying a built-in procedure wholesale for the sake of one edit. And ignoring the built-in procedures, explaining to the agent every time what has already been written down.