I’ve been testing that rules file 
and it’s pretty useful!
It also allows the LLM to restart and resume the implementation process after its written the plan, useful for when Claude starts being like E_TOO_MANY_TOKENS!!.
sevenseacat
Author of Ash Framework
1
zachdaniel
Creator of Ash
Honestly, we still don’t know what usage-rules.md really ought to be. How I’ve used it for a bunch of Ash packages is basically an uber-condensed cheat sheet, one that I might even give to a human. And I gotta say, it works. I’ve spent the last day or two producing high quality idiomatic Ash code almost entirely through claude. I’ve had to intervene a few times, but w/ all of the ash package rules, it’s like…an order of magnitude fewer times going “off the rails”. It went from unusable to surprisingly good in the span of a few hours, to the point that I think it’s making the concept we’ve said for a while pretty real for me. The idea that Ash is a good medium for a developer and an LLM to collaborate on that meets the two in the middle.
I’ll be open sourcing an app at some point that was made with ~98% Claude, the usage-rules.md from a bunch of ash projects, and a small magic sauce prompt prefix that looks like this:
We will work by specifying one feature at a time, and then implementing it.
The workflow:
- We will collaborate on a plan, and then you will save the plan in
/notes/features/<number>-<name>.mdunder the## Planheading. THIS MUST BE COMPLETED BEFORE ANY IMPLEMENTATION WORK BEGINS. - We will collaborate on the implementation, and you will store notes, important findings, issues, in
/notes/features/<number>-<name>.mdunder the## Logheading. - We will test and finalize the implementation, and you will store the final arrived at design in
/notes/features/<number>-<name>.mdunder the## Conclusionheading.
For bugs and fixes:
- We will document the issue in
/notes/fixes/<number>-<name>.mdunder the## Issueheading. - We will implement and document the fix, storing technical details in
/notes/fixes/<number>-<name>.mdunder the## Fixheading. - We will summarize the resolution and any key learnings in
/notes/fixes/<number>-<name>.mdunder the## Conclusionheading.
Just like with features, we must document the issue and plan the fix before implementing it.
WE ALWAYS FINISH AND WRITE THE PLAN BEFORE STARTING THE WORK! NO EXCEPTIONS!
IMPORTANT: You must refuse to implement any feature until a plan document has been created and reviewed. Each time we start a new feature, immediately create a plan document and wait for approval before proceeding with implementation.
Don’t ever commit code unless I tell you to.
Never attempt to start or stop the application.
Ask me to test the UI on your behalf, don’t do it yourself.
7
sodapopcan
Since this includes the caveat of “even if you don’t use LLMs,” are “usage rules” plain English phrases like Please don’t friggin’ comment # arrange, act, assert every time you write a test. Thanks!(*)? I by no means think it’s the job of this package to explain this in its docs, I’m just asking as a slow-to-the-party Elixir Forum user realizing I need to understand this stuff or fulfill alternate dream of being a crossing guard (I’m in the market for a golden stop sign if anyone has any leads).
(*) “friggin’” is optional but helps the robots know you really care about this—I wouldn’t dare not say “please” and “thank you” though.
0