>> skills belong in the repository
A coding agent arrives with broad ability and almost no local judgment. It can read a language, propose a change, and run a command. It does not automatically know which file owns a contract, which checks matter, or what this project has already decided not to do. Intelligence without context creates plausible work. Not necessarily correct work.
My starting point for skills is simple: the working method should live beside the work. A skill is a small, versioned instruction set for a recurring task. It tells the agent what to inspect, where the boundaries are, how to make the change, and what evidence is required before the task can be called complete.
GitHub gives that method a durable home. The skill can be reviewed with the code, changed when the architecture changes, and shared by everyone who opens the repository. It is no longer a private prompt remembered by one person. It becomes part of the project's visible operating surface.
This matters inside Visual Studio and VS Code because that is where intent meets the actual files. The agent can move from a request to the repository's own instructions without leaving the editor or rebuilding the context by hand. The distance between asking and doing becomes shorter, while the rules remain inspectable.
A good skill does not try to contain the whole project. It narrows one kind of work: create a post, diagnose CI, prepare a release, review a command surface. Its value comes from specificity. The agent still reasons, but it reasons inside a path that the repository can explain and the team can verify.
The deeper idea is not automation. It is continuity. The same repository carries the code, the history, and the method used to change it. The editor becomes a doorway into that system. The agent becomes useful because it enters through the same door as everyone else.