Questions

Should this go in a skill or in the project instructions?

Project instructions are read on every task in that project. A skill is read only when a task matches its description. Put the things that are always true in the project instructions, and the things that are true for one kind of work in a skill.

Always on against on demand

Project instructions occupy context whether or not the current task needs them, which is the right trade for facts like the package manager, the test command and the branch convention. A procedure for one job, such as how to cut a release or how to write a migration, costs the same context on every unrelated task if you put it there.

Length is the practical signal

When a section of project instructions grows past a screen and describes a procedure rather than a fact, it has become a skill that has not been extracted yet. Pulling it out shortens what every task pays for and gives the procedure a description, which is also the point at which you find out whether it was ever specific enough to be followed.

They are not rivals

The healthy arrangement is short project instructions that state the standing facts, plus a small set of skills that carry the procedures. If you find yourself repeating the same paragraph across several skills, that paragraph is a standing fact and belongs upstream in the project instructions instead.