A skill is a folder of instructions and scripts that an AI assistant loads when the task matches. Ours encode the architectures on this site and the conventions we use every day — so the assistant arrives already knowing how the work is supposed to be done.
Most of the gap between a useful AI assistant and a frustrating one is context. A model that does not know your layer conventions will cheerfully put business logic in Bronze; one that does not know your deployment rules will write a pipeline that cannot be backfilled. Skills close that gap once, in a form the whole team shares.
They are plain folders — a SKILL.md with instructions, plus any reference files or scripts it needs. The format is open and the content is text, so a skill travels between assistants, lives in your repository, and reviews like code. Nothing to run as a service, nothing to keep patched.
The reference architectures on this site, turned into something that builds them. Opinionated by design — they make the choices we would make.
Scaffolds a batch lakehouse on Databricks that follows the medallion reference architecture — including the parts people skip.
Structured Streaming done the way the streaming reference architecture describes, with the failure modes handled up front.
Designs and reviews events for an event-driven integration platform, holding the line on what is allowed on the bus.
Reads a data platform you already have and reports where it diverges from the reference architecture — with the cost of each divergence, not just the name of it.
A skill follows every reference architecture we publish. If you want the pattern before the skill exists, the architecture page has the full checklist — and we are happy to walk it with you.
The small ones that pay for themselves daily. Free, and a reasonable way to see how we write skills before buying one.
Writes the commit message from what the diff actually changed, runs the checks that matter first, and refuses to push to the default branch.
Takes a 300-line SQL query nobody owns any more and states its grain, its joins, the filters that change the result, and what it would look like refactored.
Turns raw meeting notes into decisions, owners and open questions — and marks the things that sounded agreed but were not.
After a change lands, updates only the documentation that the change actually invalidated — and leaves the rest alone.
We package a skill whenever we catch ourselves explaining the same thing twice. If there is something your team explains twice a week, tell us.
The architecture skills are opinionated because opinions are the point. If your conventions differ — and they will — we build the skill around yours, and your team gets an assistant that already works the way you do.
Talk to us