Contributing

Skill Blaizzy/mlx-vlm/skills/skills/contributing

Use this skill when the user wants to contribute to MLX-VLM — opening a PR, where model code/config/tests go, backward-compatible config args, running the test suite, code formatting and the pre-commit hooks (black, clang-format), and PR expectations (tests, review, perf evidence). Use it to set up a change so it passes review.From its SKILL.md

Install

npx -y skills add Blaizzy/mlx-vlm --skill contributing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

3.3 KB, as published. Nobody here has run it

Contributing to MLX-VLM

Use this workflow to shape a contribution so it lands cleanly. It reflects the current mlx_vlm/ layout (note: CONTRIBUTING.md still points at an older src/ layout — the real paths are below).

Setup

git clone https://github.com/<you>/mlx-vlm && cd mlx-vlm
uv pip install -e .            # editable install (or: pip install -e .)

Where things go

Model code: mlx_vlm/models/<model_type>/, and the file name matches the config.json model_type (e.g. llava). A new kernel or helper goes in its own file in that model directory, not bolted into language.py. To add a whole new model, use Skill("mlx-vlm-skills:add-new-model").
Config args: add to the model's ModelConfig (in <model>/config.py) with an inline # comment, and keep them backward-compatible — a default of None/0/False must reproduce the original behavior so existing checkpoints and configs are unaffected. Gate new features so they are opt-in.
Tests: add to mlx_vlm/tests/test_models.py as a class per feature (e.g. TestMyFeature). Do not create a standalone test_<feature>.py — repo convention keeps model tests in test_models.py. Prefer cheap synthetic/random-weight tests (tiny configs) and check exactness against the original path in the degenerate limit (feature disabled == baseline).

Run the tests

cd mlx_vlm && uv run --with pytest python -m pytest tests/test_models.py -q -k "<ClassName>"

Formatting — install and run pre-commit

Before opening a PR, install the pre-commit hooks once and run them. The repo uses pre-commit (black for Python, clang-format for C++); PRs are expected to be hook-clean.

pip install pre-commit
pre-commit install                 # install the git hooks (run once per clone)

# run on the files you changed
pre-commit run --files <file1.py> <file2.py>
# or check everything
pre-commit run --all-files

You can also format a single file directly:

black <file>.py
# clang-format -i <file>.cpp   # for C++

Reminder: run pre-commit run --all-files (or at least on your changed files) as the last step before pushing — an unformatted diff will fail CI/review.

PR expectations

Fork and open the PR against main.
New code that should be tested comes with tests (see above).
Every PR needs passing tests and at least one review.
Include perf evidence for anything performance-sensitive — a self-contained, reproducible benchmark. Use Skill("mlx-vlm-skills:benchmarking") for the fork-vs-main table format.
Keep the change scoped and opt-in; don't regress existing checkpoints.

Routing

Adding a model → Skill("mlx-vlm-skills:add-new-model").
Converting/quantizing weights → Skill("mlx-vlm-skills:convert-quantize").
Perf numbers for the PR → Skill("mlx-vlm-skills:benchmarking").
Filing a bug found while contributing → Skill("mlx-vlm-skills:reproducible-github-issues").