The description does the triggering

Your audit-event skill is on disk and well-formed. Whether Copilot ever reaches for it comes down to a single line: the description. This is the difference between a skill and a prompt file, and it’s worth slowing down on, because it’s easy to write a perfect procedure that never runs.

How a skill gets chosen

Copilot doesn’t load every skill into every request — that would bury the model in irrelevant procedures. Instead it scans the available skills’ descriptions against the task in front of it and pulls in the ones that match. The body of the skill — your five steps — only enters the picture after the description has earned its way in. So the description isn’t documentation. It’s the matcher. It’s the part that has to say, clearly enough for the model to recognize, “this is the situation I’m for.”

That’s why the field reads best as a trigger condition, phrased as “use this when…”:

Use when recording a significant event through shared-lib’s audit helper — e.g. approval requested or granted.

Compare that to a description that merely summarizes the skill:

Helper for audit events.

Both describe the same file. Only the first tells Copilot the circumstance — a task about recording an event through the audit helper — in words it can match against a real prompt like “add an approval.granted event when the second approver signs off.” The vague version names a topic; the good version names a moment. Name the moment.

The contrast with manual invocation

This is the line that separates the two ways of giving Copilot a procedure:

A prompt file is manually invoked. You type /scaffold-endpoint. Nothing happens until you reach for it — you’re the trigger. Good when you know the right moment and want explicit control.
A skill is model-invoked. You never type its name. Copilot reads the descriptions, recognizes that the task at hand is about recording an audit event, and applies the skill on its own. Good when the agent should recognize the moment — including moments you’d forget to flag by hand.

The audit-event convention is squarely the second kind. The whole problem you started with was that you kept re-explaining the convention whenever work touched an audited event. A prompt file wouldn’t fix that — you’d still have to remember to invoke it. A skill with a sharp description fixes it for real: now, the moment any task in either repo is about recording an event, Copilot pulls the convention in itself, before you’ve said a word about it.

The test

You’ll know the description is right when you stop thinking about the skill. Ask Copilot to add the approval.granted event in orders-service without mentioning the convention, and watch whether the resulting code follows your team’s shape — dotted lowercase name, the helper, the required fields, recorded after success. If it does, the description matched and the skill fired on its own. If it doesn’t, the description was too vague to recognize the moment; sharpen it toward “use this when…” and try again.

One skill, two repos, invoked automatically. The last thing to see is how far that one file reaches — because it isn’t only Copilot that understands it. Next: write once, runs everywhere.