That said, just because you were making that commit in response to a CI failure, that doesn't mean the change itself has anything to do with CI, such as working on the workflow itself (which is what I'd take chore(ci): to mean). Those commits might be best prefixed by chore(http):, but I usually just do chore: anyway for anything that doesn't change library API 🤷

This stuff is tricky!

You can't just make up any prefix like refactor: or ci:. The team would have to agree on a convention (one we make up or one we adopt). By far the most common is Angular, which only has chore:, fix:, or feat:. I see no real reason to deviate.

My bad, I've always used these prefixes since they seem to be recommended in the conventional commits spec. It's something I've always done. I have a git commit message template with all these things outlined so I've made a habit of just picking based on context/occasion, but I guess now that we're trying to adopt this style commit messages at an org level, I ought to have asked/looked into the particular variant we're looking to follow.

That said, just because you were making that commit in response to a CI failure, that doesn't mean the change itself has anything to do with CI, such as working on the workflow itself (which is what I'd take chore(ci): to mean). Those commits might be best prefixed by chore(http):, but I usually just do chore: anyway for anything that doesn't change library API 🤷

Yeah, the spec is pretty open-ended about the meaning of prefixes beyond "fix", "feat", and "BREAKING CHANGE", so I can easy how it might be easy to have conflicting definitions

used these prefixes since they seem to be recommended in the conventional commits spec

Aha, see this is why I make these comments. I never saw this,

types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

Nevermind then, TIL!