A procedure a new engineer cannot get wrong

The problem is rarely that nobody knows how to do the job. It is that the person who knows is on another site, the procedure lives in a wiki page that is two firmware versions out of date, and the person in front of the device is being careful with commands they have not run before.

What it looks like here

The engineer who knows builds the procedure as a button, with the prompts, the waits and the gates already in it. Everyone else presses it. The commands are still visible — this is not a black box — but nobody is retyping them from a wiki at eleven at night.

Export the set and hand it over. Site-specific values come out first: replace the jump host and the syslog collector with global variables and the same set works for every customer, with each engineer's own values on their own machine and none of them in the file.

The parts that matter across a team

• Read before you run. Every set on the exchange shows its full script — every step, every command, nested branches included — before the download button. Anything that reboots, erases or writes config is flagged. You can apply the same standard internally.
• A record of who did what. The audit log records the button, the connection, the time and the result, and exports to CSV or JSON. That is the answer when a customer asks what was changed on their kit and when.
• Nothing to install on the customer's estate. It is a terminal on the engineer's machine. No agent, no collector, no account required to download it.
• Credentials stay put. Passwords and passphrases go into the operating system's vault — DPAPI, Keychain or libsecret — never a config file, and never in an export you share.

Where to start

Pick the procedure your team gets called about most, build it once, and share it as a set. If it is generic enough to be useful to strangers, publish it — and if it is not, keep it internal; the format is a file, and nothing obliges you to upload anything.