I sanitized two more skills for anyone who might find them useful.

Phoenix skill

Comprehensive Phoenix skill for Claude which I’ve used for a while. Further cleaned up and validated against 10 production code bases.

Phoenix LiveView skill

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.

The monitoring section is wrong. The resource_impl macro has to be called on the actual impl Resource for … and will set the IMPLEMENTS_* booleans.

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.

archdo, the checked rules

Documents what rules are checked.

archdo

Architectural quality checker for Elixir — 144 rules checking OTP patterns, boundaries, error handling, and test architecture.

It is early stage, but I’ve found it useful so far.

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:

1. Invoke the relevant skills before planning or implementing.
2. Actively use the skills while working.
3. Option for semi-forced TDD (which still allows refactoring without issue).
4. Use milestone plans, and force Claude to actively use the skills before implementing each milestone.
5. Hooks to catch some slop so it can be replaced while still implementing and context is fresh.
6. 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):

Elixir:
elixir-planning
elixir-implementing
elixir-reviewing
phoenix
phoenix-liveview

Rust:
rust-planning
rust-implementing
rust-reviewing
rust-nif

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 ArchDo and Elixir_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.