So in case others find them useful here are 3 of the skills I use. They work pretty well together. Avoid Claude starting agents to plan and implement as the agents will typically not use the skills, and well, that is not optimal. They are substantial but only core Skill is loaded into context until it needs any specialized part.
This is a rather ambitious project to make Claude do idiomatic Elixir both in architecture and code. The skill has a hub structure with a core skill aiming to cover the most crucial and daily bits, and with referenced supporting files covering more specialized topics. Only the core skill is loaded into the context when the skill is invoked.
So far I’ve only sanitized this and the rust-nif skill. Other related skills might follow time and motivation permitting.
Rust NIFs with Rustler for Elixir — safe native code, BEAM/OTP integration, error handling, scheduler management, and process communication. ALWAYS use when writing Rust NIFs or Rustler code. ALWAYS use when integrating native Rust code with Elixir/BEAM. ALWAYS use when debugging NIF performance, crashes, or type conversion issues.
A comprehensive Claude Code skill for idiomatic Rust development. Covers ownership, traits, generics, async/await, error handling, serde, tracing, macros, design patterns, and production best practices. Current for Rust 2024 edition.
Comprehensive Phoenix Liveview skill for Claude. There is likely a bit more than normal focus on use with SVGs as I use that for dashboards, gauges, slider controls and charts. Apart from some overdue clean up it was also validated against 10 production code bases.
Thank you! I try to test these with what I make, and validate or challenge them with other production code too, but I assume there are still issues like this that slip by. But each fix is an improvement.
Credo, Dialyzer, and Sobelow are great but they don’t cover all the various other ways I and Claude can mess up an innocent project which deserves better. So I figured I might as well use Claude to detect and fix typical Claude issues using a combination of a code analyzer and the Elixir skill.
It is basically a two stage tool where the code analyzer identifies potential issues, and where Claude use the skill to evaluate if the flagged issues are real or done on purpose for some reason.
This is a work in progress, but it does catch and help fix many issues overlooked by the tools mentioned before.
Just a heads up: The above Elixir skill is good for reviewing, but there is randomness to what degree Claude use it for planning and implementing. Hence I expect to replace it fairly soon by a new iteration which has a different architecture and setup. The reasons are less about the content of the skill and more about making Claude actually use it without having to constantly check and push it.
The skill use, or not, is annoyingly non-deterministic and really a Claude issue. One can increase the odds by forcing use, where that is possible, and then getting the style and prioritizations right for Claude to actively use it. The new skill version need a few more app builds to confirm find that right priority balance though.
In the meantime the above Archdo is now at about 200 rules and finding quite a lot of issues otherwise missed. If you wonder which libraries use AI somewhat sloppily then the slop detection is quite revealing!
The easiest way to use it is just pointing Claude to the directory where it is. Then ask to use Archdo to check some project and to use the Elixir skill above for evaluation (and suggest fixes). The skill helps evaluate which are critical, real issues or intentional ways of doing things differently, which ones are tolerable or just taste, or false positives in that project setting.
(If the project is compiled too that helps as some rules will only work on compiled projects).
So these skills have been through another iteration and some major reorganizing. The goal has been to get Claude to:
Invoke the relevant skills before planning or implementing.
Actively use the skills while working.
Option for semi-forced TDD (which still allows refactoring without issue).
Use milestone plans, and force Claude to actively use the skills before implementing each milestone.
Hooks to catch some slop so it can be replaced while still implementing and context is fresh.
When making key code decisions, and there are relevant rules/ guidance/ decisions in the skills, Claude should add a §§ code in the comments about which skill guidance were followed. (Easily removed later with a script when done). This helps make Claude stop and consider decisions using the skills.
With this setup using hooks there are additive edits to existing files and many new files. Thus for convenience there is an install and uninstall file. It is purely additive, and it is namespaced bb, so it should not collide with anything else.
The Elixir pack and the Rust pack can be used alone or together. The install script will ask to install the common third repo with the hooks they share. The idea is that more languages can easily follow the same pattern later and be added or removed without messing up the existing configuration of other languages.
So now the Elixir and Rust skills have repos including these skills (with subskills):
These are big skills so they do spend tokens loading. But to the degree they improve the Claude output closer to directly usable code I’m ok with that. Might be an issue for 200k contexts (haven’t tried), but works fine with 1M.
There is a user_guide included, but the most important things are two keywords:
[use-skills] which forces invoking of relevant skills, and activates more hooks to encourage actual skill use.
[TDD] which forces tests to be written before the implementation. Apart from getting the test workflow it also makes it harder for Claude to get lazy or skip work. Once the test is in place the implementation has to be done. And it forces Claude to think about the code two times instead of just one, which is likely good.
Mentioning milestone plan will make a milestone plan, and with [use-skills] active Claude then have to actively check the relevant skills before implementing each step.
Links:
Older Elixir and Rust skills marked as having been superceded.
I am about to try ArchDoandElixir_skill. One thing that immediately jumped out: zero attack vectors on updating the repo. It’s quite OK, I maintain per-machine update_all scripts and can just shove both in there but – have you considered this?
EDIT: Oh, I see Elixir_skill seems to be superseded by elixir-phase-skills?
Yes, it turned out that optimizing the skill for the different phases of planning, implementing and reviewing took different kinds of constructs. So splitting them was part of the new iteration. They are also better organized according to Claude. (I asked, so well, that how it likes it).
The hooks package aim to make sure the skills and TDD is used. Just mention [use-skills][TDD] and “make a milestone plan” along with Elixir (or Rust), and it should take it from there.
Still doing quite active updating on these, so there will be some more updates once I’ve done the initial tests on the latest add-ons.
Edit: For the updates I’ve so far just replaced them with the newer version. As they grow, or I add more of the skills to the public repo, I should probably think of something better organized.
Do you honestly find planning mode useful? I found it super tiring to get 4 screens worth of output, correct Claude on two minor points and get presented with that 4-screen again, left to review the diff on my own. After literally the 5th time I just disabled it.
I find it very useful. First for the architecture part of it, and secondly as it splits up large projects into smaller bits which doesn’t cause Claude to stress, panic and do crazy work skipping stuff. And if you do get a compact in the middle of a plan the next session knows better where to continue.
Oh, and I avoid than planning agent like the plaque. Tell Claude no agent for planning or implementing.
[use-skills][TDD] Make a milestone plan to implement this and that in Elixir…. Use no agents for planning or implementation.
That is how I start all Elixir or Elixir/ Rust projects these days. (The agent thing I have in huge letters in the Claude and memory files so I don’t have to actually say that).
Edit: If you ask it to explain in detail the reasoning behind say architectural choices for the plan it might read it more detailed. Force proof of work and all that.
No, I don’t actually enter planning mode as that will start the agent. But I do ask for the milestone plan as that is also connected to planning architecture, hook and skill use.
Well I was just about to ask whether we talk the same thing. The actual plan mode of Claude I find infuriating; I found multiple different ways to do it and for now settled on a memory file + a Markdown RFC file. The latter usually grows too big though, still working very hard on making sure stuff is compressed and substantive (I have the feeling whoever devises a mix of a human language + math + symbolic logic might actually come at a hair distance of inventing Skynet).
You might give this ClaudePlans a try. It watches and renders plans, memories, and extra folders you add using MDex with syntax highlighting, Mermaid charts, etc. Keyboard navigation, supports the PLUG_EDITOR conventions so you can open in editor of choice, inline annotations, etc. Makes plan mode much more pleasant.
Yes, I gave up on the planned mode too as it messed with the skill use and hooks. It works ok for me for other projects though.
The long term idea here for Elixir is to have skills and Archdo reflecting each other. So when a plan has been made and implemented, and Archdo analyses it and Claude interpret using the reviewing skill, then the Archdo rules are referring to specific skill sections. Thus Claude knows where too look for information and fixes.
By adding, distilling and iterating over time and projects the coordination should be ever improved. For overall quality check I run both against many different repos of varying maturity and sizes for validating, challenging or calibrating rules and skill guidance. For the moment I’m still just adding in functionality, so this will be the next iteration of both skills and Archdo I think.
