Writing an AI Skill Definition for Go Backend API Engineers

In a previous post, I argued that centralised agent skill definitions are the key to scaling AI across an engineering org. In the follow-up, I walked through how to build a context layer that connects your knowledge base to AI tooling. This post is the next step: what does an actual skill definition look like, why is it opinionated, and how do you enforce it across your entire engineering org? Why a skill definition matters Give an AI coding assistant a Go codebase with no context and ask it to add a new endpoint. You'll get something that compiles. It might even work. But it won't match your architecture. It won't follow your error handling patterns. It won't use your shared libraries. It won't write the tests the way your team expects. The AI doesn't know: That your transport layer is deliberately dumb — just request mapping, no business logic That you use ULIDs, not UUIDs That all dependencies must be passed explicitly — no globals, no init() That new libraries need approval before