Super Elixir

One skill, many specialities. Call it once. It picks the speciality from the job, loads only that guide, and for reviews it can run several passes and return one report.

The guides are kept whole. Each is a full, separate skill that was merged in; the router decides which to open.

Step 0: detect the job

Do this first and do not announce it. Signals and precedence are in references/auto-detect.md. For project facts (Elixir version, Phoenix, Ecto, Oban, which linters exist), run node scripts/elixir-scan.mjs detect <dir>.

Order of precedence: a safety finding, then the user's explicit words, then the detected job. A security finding, a data-loss risk or an irreversible action is always stated in full sentences.

Review pipeline: several passes, one report

Use this for "review everything", "full review" or any request naming more than one concern. A single named concern runs only its own pass.

1. Facts. Run node scripts/elixir-scan.mjs detect <dir>. It tells you which passes apply (no Ecto, no GenServers, no Phoenix) and which gates the project really has.
2. Candidates. Run node scripts/elixir-scan.mjs scan <dir>. The output is a list of places to look, not findings. Never report a candidate without reading the code around it.
3. Passes, in this order. Open each guide and its references, apply its checklist, its Valid Patterns (Do NOT Flag) and its Context-Sensitive Rules.
   1. code-review: style, pattern matching, OTP basics, docs.
   2. security-review: injection, atoms, secrets, process exposure.
   3. performance-review: GenServer bottlenecks, memory, concurrency, database.
   4. antipatterns: the known-bad catalog, only for what the earlier passes did not already cover.
4. Verify every finding with references/verification-protocol.md. A finding that fails a gate is dropped or downgraded to a question.
5. Report once. Fill templates/review-report.md. De-duplicate across passes, order by severity, give each finding a path:line, the evidence, and a fix.

Review only. Do not edit code during a review pass unless the user asked for fixes.

Build pipeline: one feature, in order

1. Think. thinking: does this need a process at all? What is the data, what are the functions?
2. Shape. New app or large feature: architect. Otherwise skip.
3. Test first. tdd: a failing test, then the smallest change.
4. Write. idioms, pattern-matching, plus otp or ecto as the code needs.
5. Document. docs for public modules and functions.
6. Gate. mix format, mix compile --warnings-as-errors, mix test, then only the linters in mix.exs (Credo, Sobelow, Dialyzer). Use templates/feature-checklist.md to track it.

The short list of iron laws

Every guide keeps its own full list. These recur across the sources and rarely conflict:

1. No process without a runtime reason. State, concurrency or fault isolation. Otherwise plain functions.
2. Supervise every long-lived process. No bare start_link in production.
3. Tagged tuples for expected failure. Raise for bugs. rescue only around external code.
4. In with, every failable step uses <-. A = swallows the error.
5. Guards use and, or, not. Never &&, ||, !.
6. No atoms from external input. String.to_atom/1 on user data leaks the atom table.
7. Messages are copied. Keep them small.
8. Changesets for external data. cast/4 for input, change/2 for internal changes.
9. No code without a failing test first.
10. Verify before you report. Evidence, not impression.

Where two guides disagree, the stricter rule wins, and the project's own AGENTS.md and rules (see rules/elixir/) win over both.

Overlaps: which copy to read

These topics exist in more than one guide. All are kept. Pick by the job.

Layout

Old skill names

Text inside the guides may name the skill it came from. Resolve it here.

Related skills

• tdd: drive a change test-first.
• safe-refactor: clean up Elixir without changing behavior.
• super-protobuf: the service exposes protobuf, gRPC or Connect.
• verify: prove tests and gates pass before you claim done.
• handoff: pause a long review or change.

Done when

• The right speciality (or the pipeline) ran, and only the needed guides were opened.
• Code compiles and tests pass, or the review report is complete with evidence for every finding.
• No finding was reported that failed the verification protocol.