Before I figured out how to use macros to enable SwiftMCP, I experimented a lot with SwiftSyntax and built a project that I called SAAE – Swift AST Abstractor & Editor. Such it lay forgotten on a public GitHub repo. So I figured, it would deserve a new coat of paint and a better name.
The CLI of the project has four main functions at this time:
- analyze – Makes you are cut down interface description for any number of files. This way you can hand the public interface for a framework to your LLM without it having to read lots of superfluous text.
- check – Does a super-fast local syntax check within the scope of one file. This way you can catch “obvious” syntax error in generated code before you waste time on a long build.
- reindent – Generated code usually doesn’t care about how you like your code reindented. This function essentially what CMD+I does in Xcode.
- distribute – Generated code tends to want to put all new code into a single file resulting an tons of declarations in huge files. This function splits all declarations into separate files. If protocol extensions it puts them parallel to the declaration file with +Protocol added to the name.
This is all some kind of housekeeping work, so at first I wanted to go with maid. But my AI convinced me that this is a bad name for many reasons, including the fact that the term “maid” is supposedly sexist. So I let myself be convinced that butler is way better. So we went with that.
SAAE becomes SwiftButler
So for version 1, I polished up the CLI a bit, gave it a --version command, and renamed it to butler. I added a SKILL.md file to aid with it being used as an OpenClaw skill and also added it to my homebrew tap so that you can easily install it.
brew install cocoanetics/tap/swiftbutler
Then to use it just do something like:
butler analyze Sources/MyModule --visibility public
The complete documentation for the CLI can be found on GitHub. Or just install it from ClawHub.
Granted, you could also ask your coding agent to do this kind of refactoring. But coding agents would do that by generating all the extracted code from scratch and also to generated the code to be deleted as well. With this tool it’s essentially free.
This was the main realization why I felt that butler would be quite useful in any Swift developer’s tool belt.
And while watching my coding agents at work I keep seeing that they still have occasional trouble with syntax or even get tripped up by their own file editing tools. Cursor (and by extension VS Code) has an advantage over Codex and Claude by having access to a Swift Linter which tells the LLM right then and there that there’s some syntax problem.
I have yet to try it in practice, but I think the butler check function should be able to act as a first line of defence linter for Codex or Claude Code. This emits all the kinds of syntax errors you’d get from the syntax checker of the Swift compiler. It won’t be able to tell you if you are calling a non-existing function from another file, but there are many syntax problems it CAN tell you about. To a degree there are even fix its provided.
Conclusion
LLMs might be getting better and better at writing correct code from the start, but even if they write perfect code there remain some refactoring operations that you’d be better off doing deterministically by employing tools that can help you verify and modify the abstract syntax tree of your source code.
When building SwiftButler I had a few more ideas for what it could/should do:
- make sure all public functions have DocC comments
- make sure all file headers adhere to a certain standard
- more ambitious: have some sort of lookup function that allows finding declarations or functions by name or semantically
- most ambitious: emulate cross-file syntax checking by verifying that declarations or functions exist in the local project
What do you think? What should be add next?
Categories: Updates
