IMPORTANT: Consult these usage rules early and often when working with the packages listed below. Before attempting to use any of these packages or to discover if you should use them, review their usage rules to understand the correct patterns, conventions, and best practices.
_A dev tool for Elixir projects to gather LLM usage rules from dependencies _
Many packages have usage rules, which you should thoroughly consult before taking any action. These usage rules contain guidelines and rules directly from the package authors. They are your best source of knowledge for making decisions.
When looking for docs for modules & functions that are dependencies of the current project,
or for Elixir itself, use mix usage_rules.docs
# Search a whole module
mix usage_rules.docs Enum
# Search a specific function
mix usage_rules.docs Enum.zip
# Search a specific function & arity
mix usage_rules.docs Enum.zip/1
You should also consult the documentation of any tools you are using, early and often. The best
way to accomplish this is to use the usage_rules.search_docs
mix task. Once you have
found what you are looking for, use the links in the search results to get more detail. For example:
# Search docs for all packages in the current application, including Elixir
mix usage_rules.search_docs Enum.zip
# Search docs for specific packages
mix usage_rules.search_docs Req.get -p req
# Search docs for multi-word queries
mix usage_rules.search_docs "making requests" -p req
# Search only in titles (useful for finding specific functions/modules)
mix usage_rules.search_docs "Enum.zip" --query-by title
- Use pattern matching over conditional logic when possible
- Prefer to match on function heads instead of using
if
/else
orcase
in function bodies
- Use
{:ok, result}
and{:error, reason}
tuples for operations that can fail - Avoid raising exceptions for control flow
- Use
with
for chaining operations that return{:ok, _}
or{:error, _}
- Elixir has no
return
statement, nor early returns. The last expression in a block is always returned. - Don't use
Enum
functions on large collections whenStream
is more appropriate - Avoid nested
case
statements - refactor to a singlecase
,with
or separate functions - Don't use
String.to_atom/1
on user input (memory leak risk) - Lists and enumerables cannot be indexed with brackets. Use pattern matching or
Enum
functions - Prefer
Enum
functions likeEnum.reduce
over recursion - When recursion is necessary, prefer to use pattern matching in function heads for base case detection
- Using the process dictionary is typically a sign of unidiomatic code
- Only use macros if explicitly requested
- There are many useful standard library functions, prefer to use them where possible
- Use guard clauses:
when is_binary(name) and byte_size(name) > 0
- Prefer multiple function clauses over complex conditional logic
- Name functions descriptively:
calculate_total_price/2
notcalc/2
- Predicate function names should not start with
is
and should end in a question mark. - Names like
is_thing
should be reserved for guards
- Use structs over maps when the shape is known:
defstruct [:name, :age]
- Prefer keyword lists for options:
[timeout: 5000, retries: 3]
- Use maps for dynamic key-value data
- Prefer to prepend to lists
[new | list]
notlist ++ [new]
- Use
mix help
to list available mix tasks - Use
mix help task_name
to get docs for an individual task - Read the docs and options fully before using tasks
- Run tests in a specific file with
mix test test/my_test.exs
and a specific test with the line numbermix test path/to/test.exs:123
- Limit the number of failed tests with
mix test --max-failures n
- Use
@tag
to tag specific tests, andmix test --only tag
to run only those tests - Use
assert_raise
for testing expected exceptions:assert_raise ArgumentError, fn -> invalid_function() end
- Keep state simple and serializable
- Handle all expected messages explicitly
- Use
handle_continue/2
for post-init work - Implement proper cleanup in
terminate/2
when necessary
- Use
GenServer.call/3
for synchronous requests expecting replies - Use
GenServer.cast/2
for fire-and-forget messages. - When in doubt, us
call
overcast
, to ensure back-pressure - Set appropriate timeouts for
call/3
operations
- Set up processes such that they can handle crashing and being restarted by supervisors
- Use
:max_restarts
and:max_seconds
to prevent restart loops
- Use
Task.Supervisor
for better fault tolerance - Handle task failures with
Task.yield/2
orTask.shutdown/2
- Set appropriate task timeouts
- Use
Task.async_stream/3
for concurrent enumeration with back-pressure
_A code generation and project patching framework _