A skill pointing to a dead API needs maintenance, however polished its description looks. OpenAI recorded the removal of DALL·E 2 and DALL·E 3 from its API in May 2026. The endpoint leaves the catalog. The instruction file stays comfortably on disk, ready to send another agent to the same closed door.
Writing this retrospective, I return to a request I made in August 2026: delegate research and turn that capability into a reusable skill. I wanted to benefit from the work again later. In July, I had already questioned why a tool was using a particular model when another option was available. Reuse interests me alongside the ability to understand what is being invoked.
Consider a hypothetical image generation skill. Its description explains the expected output, but its execution calls a retired service. Reading the summary gives you a promise the environment cannot fulfill. The agent can explain the error very politely. I still have no image, and now I have a paragraph of condolences.
I want the dependency visible near the instructions: which tool performs the work and where to check that it remains available. 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. A familiar name concealing a surprise does not make my day easier.
I do not want a collection of files maintained as a hobby, either. I requested the skill 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 without launching an expedition through the whole setup.
My verdict: dependencies belong in skill maintenance. When changing an API, I will review the instruction that selects the tool, check the expected deliverable, and retire the path that stopped working. Keeping the name is worthwhile when its promise remains true.