Design the failure path
Clear errors should say what failed, what was changed and what the user can do next. Preserve the underlying diagnostic detail without making it the only explanation.
Keep automation reversible
Preview destructive changes, make outputs deterministic and support dry runs when practical. Confidence comes from being able to inspect the plan before execution.
Treat documentation as an interface
Examples, defaults and version notes are part of the product. Test the first-run path with someone who does not share the author’s local setup.