A skill pointing to a dead API needs maintenance, however polished its description looks. On May 12, 2026, OpenAI removed DALL·E 2 and DALL·E 3 from its API. The endpoint leaves the catalog. The instruction file stays comfortably on disk, ready to send another agent to the same closed door.
Take an image generation skill whose script still calls `dall-e-3`. The description promises an image in a given format, and the execution hits a model that no longer exists. The agent can explain the error very politely, and I still have no image.
I want the dependency visible near the instructions: which tool performs the work and how to check that it remains available. In practice, that is a `requires:` field at the top of the skill naming the model or endpoint, plus a smoke test that sends the smallest possible request and fails when the model is gone. That also helps when the service exists but the current session lacks access. Those are different problems. Replacing the implementation because a tool is absent from one session starts a renovation before checking for the key.
Updating a skill requires deciding whether the deliverable stays the same. When only the means of producing that result changes, preserving the familiar entry point makes sense. When the new service changes behavior, that difference needs to reach the person requesting the work.
I do not want a collection of files maintained as a hobby, either. A skill exists to avoid repeating research and preparation. If every use requires investigating everything from scratch, reuse exists only in the title. I need to find the execution requirements and an update path in the skill itself.
Dependencies are part of maintaining a skill. When changing an API, I will review the instruction that selects the tool, update the `requires:` line, check the expected deliverable, and retire the path that stopped working.