CLIs and Skills

A skill might tell an agent to find configuration files, rename a field, preserve its value, and validate the result. We have already decided what should happen. Yet every run asks the model to reconstruct that procedure from prose and carry it out again. When the agent misses a file, we may try to fix it by adding another sentence to the skill.

For work whose rules we can specify exactly, I would rather give the agent a CLI. Put the transformation in code, test it against fixtures, and make unsupported cases fail explicitly. The model still chooses when to run it and supplies the arguments. The command owns the steps we have already settled. When the transformation is wrong, we have an implementation to fix and a regression test to keep.

A skill earns its place where the answer depends on context. During that migration, it can guide the agent through understanding why the old configuration exists, whether an unusual value is a mistake or a workaround the project still needs, and which behavior needs investigation before making the change.

The agent can follow the skill, call the CLI, and reason about its report. The command lists the files it changed and the cases it refused; the agent investigates what those exceptions mean for this project. A script bundled with a skill follows the same division. Packaging matters less than which parts we ask the model to interpret on every run.

I would start with the skill I keep correcting. If the correction is always the same and I can specify the rule, I would move that step into the command and test it. Then shorten the skill to explain when to run it and how to assess the result.