S
So I just published two Claude Code plsql-formatter and sql-formatter skills. The first one handles packages, procedures, functions, and triggers. The second handles the SQL side: standalone queries, any SQL embedded inside PL/SQL and views. Together they cover everything that lands in a real project.
I split them into two skills because that is how Claude routes, by intent. Two skills, two trigger sets, no token waste on rules that don't apply.
The Problem
SQL Developer's built-in formatter is configurable, but every developer has a slightly different preferences and not everything can be customized there as you want. The result on a shared repo is a diff full of whitespace noise, columns realigned three different ways, WHERE clauses re-indented on every commit. So you spend time in code review fixing formatting instead of logic. Eventually you settle with a style which you don't really like.
A skill fixes this differently. Instead of running a tool that rewrites the file (and sometimes breaks it on edge cases), you describe the rules in plain text and let the model apply them while it's already editing. Same model that's writing your code is reading your style guide. There's nothing to install on the build server, nothing to keep in sync with editor configs. The rules are versioned in your repo, your AI assistant follows them (if you know what you are doing), and a we humans gets a readable file.
Build your own
If you want to build something similar for your own codebase, the recipe is simple. Pick a representative slice of code you wrote yourself, I picked a whole repo. Hand it to Claude and ask it to extract the formatting rules: case conventions, indentation, blank-line patterns, alignment columns, comment style. You will get a draft skill in one shot. It won't be perfect. The first pass usually misses few opinionated patterns and over-states things that are accidental rather than intentional.
The second pass is the important one. Read the draft, strike out anything that's not actually a rule (just one-off code), and tighten the description so the right rule activates at the right time. Add a Quick Reference Checklist at the bottom – a flat numbered list of every rule. That checklist is what the model uses to verify its own output before sending it to you. Without it, long rule files quietly get partial coverage on every run. With it, the model loops back over the list and self-corrects.
Don't try to write the perfect Oracle style guide on day one. Test in on code which is not yours, watch where it makes mistakes, edit the rule that caused the mistake. After a while you have a guide that matches your rules better than you.
Bonus tip
It probably belongs to the QA skill, but my formatting skill also add comments above each block of code. Imagine this: I get any package, with the worst formatting ever, without comments, or with misleading comments. It goes and without cursing reformat it in a minute and comment the code better than I would have after few hours of work.
I am not going to format my code like a muggle anymore. Also, before I even open someone else’s package, I reformat it first. It saves me from a trip to a mental institution and keeps my sanity intact.
Happy formatting!
Comments
Post a Comment