I recently submitted the DataTides.SixSigma package to Dax Lib. And then discovered I had managed to forget several of the conventions I’d already used in other packages.
TABLEREF, not TABLE.
The exact annotation format.
Fully qualified function names.
I got things wrong, a colleague caught them before the reviewer, and I had to go back and fix them after the PR was already open.
Which was a pretty good reminder that relying on my memory is not a particularly good validation strategy.
So I built daxlib-audit-cli.
It is a small CLI that checks a Dax Lib package folder before you open the PR.
It checks things such as:
- package structure
- required manifest fields
- function names matching their manifest IDs
TABLEREFtyping- complete documentation comments
- annotations matching the manifest
- unqualified cross-references
The idea is simple: catch the boring mistakes locally, before someone else has to point them out in a review.
It is also generic. The CLI works against whatever namespace your own manifest declares, rather than being tied to one particular library or package.
I built it alongside a companion Claude skill that formats raw DAX UDFs into the DAX Lib structure in the first place.
So the workflow is essentially:
skill = format it
CLI = check it
I’ve also included two example packages in the repo: one clean package and one with five mistakes deliberately seeded into it, so you can see exactly what the audit catches.
You can find daxlib-audit-cli on GitHub: https://github.com/Juls-BI/DaxLib-audit-cli
If you’re contributing to Dax Lib, point it at your package folder before opening your PR.
And if you haven’t contributed yet because you found the process a little difficult to navigate, I hope this brings some clarity and makes that first contribution a little easier.
