A coding agent will follow your house conventions perfectly well once you have described them. That is not the problem. The problem is that you describe them again on the next task, and the next, and the description drifts a little each time — so the tests written on Monday and the tests written on Thursday do not look like they came from the same codebase.
What a skill actually is
A skill is a set of instructions with a description precise enough that the agent reaches for it unprompted. That second half is the part that is easy to get wrong. A skill nobody loads is a skill that does nothing, and a description written as an abstract summary of a problem domain will not load, because at the moment the skill is needed nobody is thinking in those terms — they are looking at a specific file with a specific problem in it.
So the descriptions on our skills name artefacts. Function names. File shapes. The question as somebody would actually type it.
Narrow beats comprehensive
The temptation with a skill that works is to grow it, and that instinct is exactly backwards. A skill covering testing, deployment and review has a description matching everything, gets loaded for everything, and stops carrying information: its presence no longer tells the agent anything about the task in front of it.
When a skill starts needing “and also”, that is a second skill.
Where to start
Everything we publish is Apache-2.0 and readable in one sitting. If one is nearly right for your team but not quite, forking it and changing the parts that do not fit is the intended use rather than a workaround.