Not Every Improvement Needs a New Skill
Before adding another Skill, determine whether the request needs a patch, a checklist, a reusable capability, or a genuinely separate boundary.
Dated writing on operations, products, software, and decisions. Browse by category or tag.
Matching: 146 / 146 · Newest first
Before adding another Skill, determine whether the request needs a patch, a checklist, a reusable capability, or a genuinely separate boundary.
Long-running work needs a durable checkpoint, a decision trail, and one safe next action that survives the chat window.
A useful AI team separates the roles of routing, doing, reviewing, and authorizing rather than pretending every agent has final authority.
When the same Skill exists across personal and shared workspaces, creating another copy can hide the real version problem.
Naming an AI capability is easy. Knowing its owner, boundaries, lifecycle and shutdown path takes more thought.
Three simple outcomes can help separate verified work, conditional progress, and genuine blockers—without hiding uncertainty.
Version names, current-source identity, and actual release evidence are different things—and confusing them multiplies uncertainty.
A passing static check isn't the same evidence as a working application, a browser test, or a verified production release.
When files, specialists, and decisions multiply, a workspace needs a map of relationships rather than just a bigger folder tree.
A package can carry manifests, file hashes, and provenance—but those are not the same as proving its software works.
As AI specialists multiply, choosing the right owner becomes as important as the quality of any individual expert.
The urge to create a new AI expert for every problem—and the discipline of improving the system before expanding it.