Elixir documentation

Inspect mix.exs, locked Elixir/ExDoc versions, public API boundaries, documentation configuration, tests, and project instructions. Use supported options from those versions; do not add a coverage tool or upgrade a dependency just to follow this skill.

1. Inspect the implementation, types, callbacks, and tests behind each changed claim. Reconcile contradictions with the implementation owner; a prose task must not silently alter the contract.
2. Give public modules a useful opening summary and explain when a consumer should use them. Document relevant inputs, outputs, options, errors, effects, and process/resource ownership in proportion to complexity.
3. Use full module names, function arities, t: type references, c: callback references, and sections starting at ##. Put a function's documentation before its first clause. Record since or deprecation information only from real history. See Elixir's documentation guidance.
4. Preserve intentionally internal APIs. Respect @moduledoc false, @doc false, and the default hidden documentation for callback implementations marked @impl true. Private functions use source comments when explanation is useful. See Module attributes.
5. Use truthful examples that exercise the public entry point. Read validation for doctests, ExDoc output, and release-specific checks.

No universal section template, minimum length, or coverage percentage establishes quality. Keep accurate short docs short. Use the available technical-writing and unslop skills for substantial organization and editing; keep technical verification in this skill.