Agent skill · caffeinelabs
mops-cli
Manage Motoko projects with the mops CLI — toolchain pinning, dependency management, type-checking, building, and linting. Use when working with mops.toml, mops.lock, running mops commands, adding/removing packages, pinning moc or lintoko versions, checking or building canisters, configuring moc flags, or setting up a new Motoko project.
What it needs
About 11k tokens when loaded.
What this skill does
<!-- Vendored from caffeinelabs/mops .agents/skills/mops-cli/SKILL.md. Do not edit below this comment: scripts/sync-mops-cli-skill.mjs overwrites it on every run. Send changes upstream instead. --> Mops CLI Opinionated guide for Motoko projects. Covers project config, dependency management, type-checking, building, and linting. Key Principles 1. No dfx — mops neither invokes nor supports dfx. There is no mops toolchain init, no moc-wrapper, and no mops watch --generate / --deploy. Always pin moc in [toolchain]; every command that compiles requires it. Use the newest moc version. Pin pocket-ic too if you have replica tests, benchmarks, or --check-deploy — with no pin those commands error, naming mops toolchain use pocket-ic 15.0.0. When MOPSPOCKETICURL points at an already-running PocketIC server, no pin is needed and an existing pin is ignored with a warning — do not add one to silence it; unset the variable instead. 2. No mo:base — it is deprecated. Always use mo:core (import Array "mo:core/Array"). 3. All config in mops.toml — canisters, moc flags, toolchain versions, build settings. 4. Canister-centric workflow — define all canisters in [canisters]; never pass file paths to mops check. Exception: library packages (no [canisters]) use file paths directly: mops check src//.mo. Project Setup Minimal mops.toml check-stable runs ICP's upgrade-time stable-variable compatibility check locally, so incompatible changes fail in mops check instead of being rejected when upgrading a live canister. It compares the current code against a .most from the deployed version. Bootstrap that .most: new project → mops deployed init (empty-actor baseline); already-deployed canister → build from the deployed commit, then mops deployed. After every deploy, run mops deployed to promote the just-built .most (see mops deployed below). Optional canister fields: candid (path to .did for compatibility checking), initArg (Candid-encoded init args). …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills caffeinelabs/mops-cli