[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GPW95ND0TREPVNZM09522B":3,"skill-same:01M6GPW95ND0TREPVNZM09522B":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":16,"sourceHtmlUrl":17,"categories":18,"keywords":19,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6GPW95ND0TREPVNZM09522B","mops-cli",null,"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\u002Fremoving packages, pinning moc or lintoko versions, checking or building canisters, configuring moc flags, or setting up a new Motoko project.","jiayaoqijia\u002Fcryptoskill","jiayaoqijia","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1453879?v=4","01M6GMYTX7Q7S504VC6E756ENR","YQ","01M6GMYV1QKJ1CC75MTTGT9PR0",81,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fdfinity-official-mops-cli\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fdfinity-official-mops-cli\u002FSKILL.md",[],[20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"mops cli","cli","commands","new","running","when","type-checking","lock","with","toolchain","linting","type","toml","project","flags","manage","up","dependency","use","dependency management","management","projects","packages","infrastructure","2026-11-10 10:12:30",false,"---\nname: mops-cli\ndescription: \"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\u002Fremoving packages, pinning moc or lintoko versions, checking or building canisters, configuring moc flags, or setting up a new Motoko project.\"\nlicense: Apache-2.0\ncompatibility: \"mops >= 3.3.0\"\nmetadata:\n  title: Mops CLI\n  category: Infrastructure\n---\n\n# Mops CLI\n\nOpinionated guide for Motoko projects. Covers project config, dependency management, type-checking, building, and linting.\n\n## Key Principles\n\n1. **No dfx** — mops neither invokes nor supports `dfx`. There is no `mops toolchain init`, no `moc-wrapper`, and no `mops watch --generate` \u002F `--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 `MOPS_POCKET_IC_URL` 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.\n2. **No `mo:base`** — it is deprecated. Always use `mo:core` (`import Array \"mo:core\u002FArray\"`).\n3. **All config in `mops.toml`** — canisters, moc flags, toolchain versions, build settings.\n4. **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\u002F**\u002F*.mo`.\n\n## Project Setup\n\n### Minimal `mops.toml`\n\n```toml\n[toolchain]\nmoc = \"1.15.1\"\nlintoko = \"0.11.0\"\npocket-ic = \"15.0.0\"  # required for replica tests \u002F benchmarks \u002F --check-deploy\n\n[dependencies]\ncore = \"2.6.1\"\n\n[moc]\nargs = [\"--default-persistent-actors\", \"-W=M0223,M0236,M0237\"]\n\n[canisters.backend]\nmain = \"src\u002Fbackend\u002Fmain.mo\"\n\n[canisters.backend.migrations]\nchain = \"src\u002Fbackend\u002Fmigrations\"\n# check-limit = 10   # optional — speeds up `mops check` when the chain gets long\n\n[canisters.backend.check-stable]\npath = \"deployed\u002Fbackend.most\"\n\n[build]\noutputDir = \"src\u002Fbackend\u002Fdist\"\nargs = [\"--release\"]\n# check-wasm = true    # optional: analyze final Wasm complexity\n# check-deploy = true  # optional: verify fresh PocketIC installation after build\n\n# Opt-in Wasm optimization (Binaryen wasm-opt) for build + bench\n[optimize]\n# level = \"O3\"       # default\n# keep-names = true  # default\n# wasm-opt pin: [toolchain] wasm-opt = \"131\" (required when [optimize] is set)\n```\n\n`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.\n\nBootstrap 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`](#mops-deployed) below).\n\nOptional canister fields: `candid` (path to .did for compatibility checking), `initArg` (Candid-encoded init args).\n\n### Warning Flags\n\n`-W=M0223,M0236,M0237` — redundant type instantiation (M0223), suggest contextual dot notation (M0236), suggest redundant explicit arguments (M0237). These are allowed (disabled) by default; `-W=` enables them as warnings.\n\n### Moc Args Layering\n\nFlags are applied in this order (later overrides earlier):\n\n1. `[moc].args` — global, all commands (check, build, test, bench, etc.)\n2. `[build].args` — build only (e.g. `--release`)\n3. `[canisters.\u003Cname>.migrations]` — auto-injected `--enhanced-migration` (managed by mops)\n4. `[canisters.\u003Cname>].args` — per-canister\n5. CLI `-- \u003Cflags>` — one-off overrides; supported by `mops check`, `mops build`, `mops check-stable`, `mops generate`, `mops migrate`, `mops test`, and `mops bench`\n\n## Core Commands\n\n### `mops install`\n\n```bash\nmops install            # dev flow: keeps mops.lock in sync, self-heals a broken one\nmops install --locked   # CI flow: fail if mops.lock is missing or would change\n```\n\nRun after cloning or after manual `mops.toml` edits. `mops.lock` is always maintained — there is no flag to opt out, and no `--lock` flag (removed in v3). A missing, unparseable, legacy-format or `mops.toml`-inconsistent lock is regenerated by a plain `mops install`, including locks that still carry absolute local paths from older CLIs, and locks that lost a transitive dependency (a locked package declares a dependency that `deps` no longer lists — typically a botched merge).\n\n`--locked` requires an up-to-date lock and never writes it. It is also available on every implicitly-installing command (`mops build`, `mops check`, `mops check-stable`, `mops check-candid`, `mops test`, `mops bench`, `mops generate candid`), so CI can run `mops test --locked` with no prior install. `mops sources` has no `--locked` (a packtool caller parses its stdout mid-build) — put `mops install --locked` earlier in the pipeline instead.\n\nThe `CI` env var no longer affects lockfile behavior (removed in v3). Commit `mops.lock` — for applications and libraries alike.\n\nA lock also goes stale when a local `path` dependency's own `mops.toml` changes — including one nested further down the chain. `mops install` regenerates it; `--locked` fails until the regenerated lock is committed. Note the first `mops install` after upgrading regenerates the lock of any project that has a `path` dependency, so commit it before running `--locked` in CI. Projects without `path` dependencies keep their existing lock.\n\n`{MOPS_ENV}` in a `path` dependency expands to `$MOPS_ENV` (default `local`), which makes the lock environment-specific. Switching `MOPS_ENV` makes it stale: `mops install` regenerates it, and `--locked` fails with a message naming `MOPS_ENV`. Keep one lock per environment, or drop `--locked` — a lock generated under one `MOPS_ENV` will not satisfy `--locked` under another.\n\nIntegrity is verified at download time, so `mops install` no longer re-hashes `.mops\u002F`: editing a dependency in place will not fail the next install. Use `mops verify` for the on-demand on-disk audit.\n\nDownloaded files are always checked before anything enters the cache — against `mops.lock` when it already records the package, otherwise against the registry. A committed lock therefore makes verification free, which is why a clean checkout installs without asking the registry about hashes.\n\nTwo consequences worth knowing: a corrupt or hand-edited `mops.lock` now fails a _download_ (the error names `mops.lock` as a possible culprit — restore it from version control; already-cached packages are unaffected), and a package the registry publishes no hashes for still installs, unverified, with a warning.\n\nPackages download in parallel through a bounded pool. `mops install --concurrency \u003Cn>` or the `MOPS_CONCURRENCY` env var (works on every installing command) caps simultaneous registry requests; the default derives from the CPU count and the file-descriptor soft limit (4–16). Transient network errors (`fetch failed`, `ECONNRESET`, `EMFILE`) retry automatically with the concurrency halved, up to twice. Set `MOPS_CONCURRENCY=1` only if installs still fail after the retries (an egress proxy capping connections, for example).\n\n### `mops verify`\n\n```bash\nmops verify   # re-hash .mops\u002F against mops.lock, and mops.lock against the registry\n```\n\nCovers GitHub dependencies as well as registry ones.\n\nExits 1 with the offending files and a recovery hint. This is the replacement for anyone who relied on `mops install` failing when `.mops\u002F` had been modified.\n\n### `mops add \u003Cpackage>`\n\n```bash\nmops add core             # latest version\nmops add core@2.5.0       # specific version\nmops add --dev test       # dev dependency\nmops add org\u002Frepo         # GitHub shorthand (also accepts a full github.com url)\nmops add .\u002Fpkg            # local package directory\n```\n\nUpdates `mops.toml` and `mops.lock`.\n\nAdding a package that is already declared in the other section **moves** it rather than declaring it twice. `\u003Cpkg>@\u003Cversion>` replaces the declared version and reports what it replaced; it leaves pinned aliases like `\"core@1.0.0\" = \"1.0.0\"` alone, and there is no flag to create one — write it by hand.\n\n### `mops check`\n\nPrimary correctness command — runs moc check, then check-stable (if configured), then lint (if lintoko is in toolchain).\n\nOn moc 1.15.0+, canisters with `[migrations]` get stricter upgrade diagnostics: a field the initial actor requires that no migration produces fails as an `M0267` error instead of only warning (`M0254`), and compat errors carry a source location. Older moc pins and canisters without `[migrations]` are unaffected either way.\n\nThe `check-stable` baseline is always a `.most` file — as `[canisters.\u003Cname>.check-stable].path` or as the `mops check-stable \u003Cbaseline.most>` argument. A `.mo` source is rejected. See [`mops deployed`](#mops-deployed) for where the baseline comes from — that differs between a fresh project and an already-deployed canister.\n\n```bash\nmops check                # all canisters\nmops check backend        # single canister\nmops check --fix          # autofix + check + stable + lint\nmops check --no-lint      # skip the lint step for one run\nmops check --verbose      # show moc invocations\nmops check -- -Werror     # treat warnings as errors\n```\n\n**Always use canister names, not file paths.** Per-canister args from `mops.toml` are applied automatically.\n\n`--fix` applies machine-applicable fixes from both moc and lintoko in one pass. Concurrent `--fix` runs (across processes) serialize automatically via an advisory lock at `.mops\u002Ffix.lock` — safe to invoke from multiple agents on the same project. Read-only files (e.g. frozen migrations) are skipped with a warning, not fixed.\n\n### `mops build`\n\n```bash\nmops build                # all canisters\nmops build backend        # single canister\nmops build --verbose      # show compiler commands\nmops build --check-wasm   # analyze final Wasm complexity without PocketIC\nmops build --no-check-wasm # skip configured [build].check-wasm once\nmops build --check-deploy  # verify fresh installation on PocketIC\nmops build --no-check-deploy # skip configured [build].check-deploy once\nmops build -- --ai-errors # pass extra moc flags\n```\n\nProduces `.wasm`, `.did`, and `.most` files in `[build].outputDir` (default `.mops\u002F.build`).\n\nWith `[optimize]` in `mops.toml`, runs `wasm-opt` after candid metadata (default `-O3 -g`). Requires a Binaryen pin: `mops toolchain use wasm-opt 131`. Build commands never write the pin themselves, and a `wasm-opt` failure fails the build. Pass `--no-optimize` (on `build` or `bench`) to skip the pass for a single run without editing `mops.toml`.\n\nWhen `--check-wasm` or `[build].check-wasm = true` is enabled, Mops runs fast Walrus analysis on the final Wasm without starting PocketIC. Per-function IC0505 complexity below 750,000 is quiet, 750,000 through 899,999 emits an early warning, and 900,000 or more emits a critical warning. `MOPS-WASM-COMPLEXITY` output includes actionable function metrics, the three largest complexity contributors, and Motoko correction guidance. The estimate never fails the build. Use `--no-check-wasm` to skip configured analysis once.\n\n### `mops deployed`\n\nPost-deploy hook — keeps the on-disk `.most` baseline used by `check-stable` in sync with what's actually deployed.\n\n```bash\nmops deployed init backend   # one-time bootstrap: empty-actor baseline + sets [check-stable].path\nmops deployed backend        # post-deploy: promotes .mops\u002F.build\u002Fbackend.most → deployed\u002Fbackend.most\nmops deployed                # all canisters\n```\n\nDefault destination is `deployed\u002F\u003Cname>.most`; override with `[deployed].dir` in `mops.toml` or `--dir`. It reads built `.most` files from `[build].outputDir` (default `.mops\u002F.build`); override with `--build-dir`. `mops deployed` errors if the source `.most` is missing — it never regenerates. Run it from your deploy pipeline immediately after a successful deploy.\n\n### `mops generate candid`\n\n```bash\nmops generate candid                # all canisters\nmops generate candid backend        # single canister\nmops generate candid backend -o \u003Cpath>   # single canister, ad-hoc path\n```\n\n(Re)generates the curated `.did` from current Motoko source. With `[canisters.\u003Cname>].candid` set, overwrites that file. Without it, writes `\u003Cname>.did` next to `main` (e.g. `main = \"src\u002FBackend.mo\"` → `src\u002Fbackend.did`) and sets `[canisters.\u003Cname>].candid` in `mops.toml`. Run after every interface change; commit `.did` + `mops.toml` together. Same moc invocation as `mops build`, so the result always passes `mops build`'s subtype check.\n\n### `mops toolchain`\n\n```bash\nmops toolchain use moc 1.15.1        # pin specific version\nmops toolchain use moc latest        # pin latest version (non-interactive)\nmops toolchain use lintoko 0.11.0    # pin specific version\nmops toolchain use pocket-ic 15.0.0  # pin for replica tests \u002F benchmarks \u002F --check-deploy\nmops toolchain use wasm-opt 131      # Binaryen for [optimize] (or `latest`)\nmops toolchain update moc            # update to latest (requires existing [toolchain] entry)\nmops toolchain update                # update all tools to latest\nmops toolchain info \u003Ctool>           # show release info (latest, pinned, history)\nmops toolchain info \u003Ctool> --versions # list recent releases, newest first\nmops toolchain info \u003Ctool> --versions --all # full release history (cache warming)\nmops toolchain info \u003Ctool> --versions --prerelease # include prereleases\nmops toolchain bin moc               # print path to binary\n```\n\n**`pocket-ic` versions**: pin anything from `9.0.0` up, `latest` included — mops keeps no list of blessed versions. Pins below `9.0.0` error with a migration message (they ran on the legacy client that mops 3.0.0 removed). With no pin, replica tests \u002F `mops bench` \u002F `--check-deploy` \u002F `mops toolchain bin pocket-ic` error naming `mops toolchain use pocket-ic 15.0.0`. That version is a hint, not a fallback.\n\n**Agent note**: `toolchain use \u003Ctool>` without a version opens an interactive picker — do not use in scripts or agents. Always pass a version or `latest`. The picker, `latest`, and `--versions` all default to stable releases; pass `--prerelease` to include prereleases. `toolchain update` only works when the tool already has a `[toolchain]` entry. `toolchain info \u003Ctool> --versions` works without `mops.toml` (first GitHub page by default; pass `--all` for full history).\n\n### Enhanced migrations\n\nWhen `[canisters.\u003Cname>.migrations]` is configured, `mops check`, `mops build`, and `mops check-stable` automatically inject `--enhanced-migration`. Do not add `--enhanced-migration` to `[canisters.\u003Cname>].args` — mops will error.\n\nCreate migration files directly in the `chain` directory.\n\nAfter `mops check --fix` (or `mops check \u003Ccanister>`) confirms the chain compiles, run `mops build` to produce the wasm artifact.\n\nUse `mops build --check-deploy`, or set `[build].check-deploy = true` for every build, to install each built Wasm on a fresh PocketIC canister and catch module validation, initialization, and installation failures. Requires `[toolchain] pocket-ic` (a version from `9.0.0` up, or a local binary path) — or set `MOPS_POCKET_IC_URL` to an already-running PocketIC server (the pin is then ignored). Unpinned with no URL, the build errors naming `mops toolchain use pocket-ic 15.0.0`. Use `--no-check-deploy` to skip configured validation once. The command uses each canister's `initArg`, or `()` when omitted. Set `wasmMemoryLimit` to a positive integer byte limit on a canister to check deployment under that limit. PocketIC errors are reported as provided by the client, and installation failures are collected across canisters. Before installation, Mops runs `moc --stable-compatible` from a temporary empty-actor `.most` to each generated `.most`. If moc reports incompatibility, Mops emits `MOPS-CHECK-DEPLOY-SKIPPED` with the compiler diagnostic and does not check that canister on fresh PocketIC. Eligible siblings are still checked; validate the skipped upgrade against representative baseline state.\n\n`check-limit` (optional) caps how many recent chain files `mops check` and `mops lint` consider — useful when the chain grows long and re-checking every old migration slows feedback down. `mops build` is unaffected by `check-limit`; it compiles the full chain, and when `[canisters.\u003Cname>.check-stable].path` is set it also folds the deployed baseline via `--stable-baseline`, so an applied migration edited, deleted, or backdated since deploy fails the build with `M0268` — the backstop for when `check-limit` trims that migration out of the folded `mops check`. When the limit kicks in, mops stages the included files into `.migrations-\u003Ccanister>\u002F` next to the `chain` directory (auto-`.gitignore`d). `moc` diagnostics may then print paths there — the real file lives in the `chain` directory with the same name.\n\nOverride `check-limit` for a single run with `--no-check-limit` (`mops check`, `mops check-stable`, `mops lint`) — e.g. `mops check --fix --no-check-limit` to autofix older, normally-trimmed migrations. On `mops check` and `mops check-stable`, `--no-check-limit` also suppresses the pending-migration warning.\n\nWhen `check-limit` is set, `mops check-stable` (and the stable check inside `mops check`) reports if more migrations are pending than the limit allows — as an error if compat failed (replacing the misleading `moc` message), otherwise a warning.\n\n### `mops remove \u003Cpackage>`\n\n```bash\nmops remove core\n```\n\nRemoves from whichever section declares the package; `--dev` limits it to `[dev-dependencies]`. A package declared in both sections is removed from both.\n\n### Dependency Management\n\n```bash\nmops outdated             # list outdated deps (caret-bound); exit 1 if any, 2 if the check failed\nmops outdated core        # check a single package\nmops update               # rewrite mops.toml versions within caret bound (no major-version crossing)\nmops update core          # update specific package within caret bound\nmops update --major       # allow updates that cross major versions\nmops update --patch       # restrict to patch bumps only (mutually exclusive with --major)\nmops update --verbose     # verbose output\nmops sync                 # add missing \u002F remove unused packages\nmops sync --dry-run       # print what would change, write nothing\n```\n\n`mops update` rewrites `mops.toml` in place (like `cargo upgrade`, not `cargo update`) and re-pins GitHub dependencies to their branch head. Like `mops outdated`, it exits `2` when it cannot run or complete — no `mops.toml`, a package that is not declared, or a dependency that failed to update (the other dependencies are still updated).\n\n`mops sync` needs a pinned `[toolchain] moc` — it reads imports with `moc --print-deps`. Packages imported only from `test`\u002F`tests`\u002F`bench`\u002F`benchmark` directories are added to `[dev-dependencies]`; already-declared packages are never moved between sections.\n\n## Other Commands\n\n### `mops self update`\n\nUpdates a global install (npm\u002Fpnpm `-g`) only, and fails if the `mops` on PATH did not end up on the new version. For `ic-mops` as a project dependency, run `npm i -D ic-mops@\u003Cversion>` instead.\n\n### `mops publish`\n\n```bash\nmops publish              # publish to the registry (runs tests\u002Fdocs\u002Fbench by default)\nmops publish --dry-run    # same local steps as publish; no registry contact \u002F identity\nmops publish --dry-run --no-test --no-docs --no-bench   # packaging checks only\nmops publish --no-test --no-docs --no-bench\n```\n\n`--dry-run` runs the same local publish pipeline (packaging checks, docs, changelog, tests, benchmarks) and prints the final file list, then stops before identity\u002Fupload. `--no-*` flags work as usual. It does **not** run canister config validation (SPDX\u002Fsemver\u002Fname rules) or prove registry acceptance (already published, permissions, missing deps).\n\n### `mops test`\n\nTests live in `test\u002F*.test.mo`:\n\n```bash\nmops test                         # run all tests\nmops test my-test                 # filter by name\nmops test --mode wasi             # use wasmtime (for to_candid\u002Ffrom_candid)\nmops test --reporter files        # one line per file (default is verbose)\nmops test --watch                 # re-run on file changes\nmops test -- -Werror              # pass extra moc flags\n```\n\nReplica tests (actor files or `\u002F\u002F @testmode replica`) run on PocketIC — the `pocket-ic` version from `[toolchain]`, or an already-running server when `MOPS_POCKET_IC_URL` is set (no pin needed; canister log output is not streamed in attached mode). Unpinned with no URL, they error naming `mops toolchain use pocket-ic 15.0.0`. Same for `mops bench` and `mops watch --test`. There is no `--replica` flag and no dfx replica.\n\n### `mops bench`\n\nBenchmarks live in `bench\u002F*.bench.mo`:\n\n```bash\nmops bench                        # run all benchmarks\nmops bench my-bench               # filter by name\nmops bench --gc incremental       # select GC\nmops bench --save                 # save results to .bench\u002F\u003Cname>.json\nmops bench --compare              # compare with saved results\nmops bench -- -Werror             # pass extra moc flags\n```\n\n### `mops lint`\n\nRuns lintoko (also runs automatically as part of `mops check` when lintoko is in toolchain):\n\n```bash\nmops lint                 # lint all .mo files\nmops lint --fix           # autofix lint issues\nmops lint \u003Cname>          # filter to .mo files matching \u003Cname>\n```\n\nWhen `[canisters.\u003Cname>.migrations].check-limit` is set, `mops lint` skips the trimmed chain migrations to match what `moc` sees during `mops check`. To lint a trimmed migration on demand, pass an explicit filter (e.g. `mops lint OldMigrationName`) or `--no-check-limit` to lint the full chain.\n\n### `mops format`\n\n```bash\nmops format               # format all .mo files\nmops format --check       # check formatting without modifying\n```\n\n### `mops watch`\n\n```bash\nmops watch                # errors + warnings + format (the default set)\nmops watch --warning      # errors + warnings only\nmops watch -t             # errors + tests\n```\n\nError checking is always on. Passing any flag selects only the named tasks, so add `-w` \u002F `-f` when you want them alongside `-t`. Those four are the whole set — there is no `--generate` or `--deploy`.\n\n## Common Patterns\n\n### Warning suppression for a canister\n\nUse per-canister `args` (not global) for suppressions:\n\n```toml\n[canisters.backend]\nmain = \"src\u002Fbackend\u002Fmain.mo\"\nargs = [\"-A=M0198\"]\n```\n\n### New project\n\n```bash\nmops init -y\nmops toolchain use moc latest        # pin latest moc (non-interactive)\nmops toolchain use lintoko latest    # pin latest lintoko\nmops add core\n```\n\nThen configure `[moc].args`, `[canisters]`, and `[build]` in `mops.toml`.\n\nTo update tools later: `mops toolchain update moc` or `mops toolchain update` (all tools).\n","# Mops CLI\n\nOpinionated guide for Motoko projects. Covers project config, dependency management, type-checking, building, and linting.\n\n## Key Principles\n\n1. **No dfx** — mops neither invokes nor supports `dfx`. There is no `mops toolchain init`, no `moc-wrapper`, and no `mops watch --generate` \u002F `--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 `MOPS_POCKET_IC_URL` 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.\n2. **No `mo:base`** — it is deprecated. Always use `mo:core` (`import Array \"mo:core\u002FArray\"`).\n3. **All config in `mops.toml`** — canisters, moc flags, toolchain versions, build settings.\n4. **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\u002F**\u002F*.mo`.\n\n## Project Setup\n\n### Minimal `mops.toml`\n\n```toml\n[toolchain]\nmoc = \"1.15.1\"\nlintoko = \"0.11.0\"\npocket-ic = \"15.0.0\"  # required for replica tests \u002F benchmarks \u002F --check-deploy\n\n[dependencies]\ncore = \"2.6.1\"\n\n[moc]\nargs = [\"--default-persistent-actors\", \"-W=M0223,M0236,M0237\"]\n\n[canisters.backend]\nmain = \"src\u002Fbackend\u002Fmain.mo\"\n\n[canisters.backend.migrations]\nchain = \"src\u002Fbackend\u002Fmigrations\"\n# check-limit = 10   # optional — speeds up `mops check` when the chain gets long\n\n[canisters.backend.check-stable]\npath = \"deployed\u002Fbackend.most\"\n\n[build]\noutputDir = \"src\u002Fbackend\u002Fdist\"\nargs = [\"--release\"]\n# check-wasm = true    # optional: analyze final Wasm complexity\n# check-deploy = true  # optional: verify fresh PocketIC installation after build\n\n# Opt-in Wasm optimization (Binaryen wasm-opt) for build + bench\n[optimize]\n# level = \"O3\"       # default\n# keep-names = true  # default\n# wasm-opt pin: [toolchain] wasm-opt = \"131\" (required when [optimize] is set)\n```\n\n`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.\n\nBootstrap 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`](#mops-deployed) below).\n\nOptional canister fields: `candid` (path to .did for compatibility checking), `initArg` (Candid-encoded init args).\n\n### Warning Flags\n\n`-W=M0223,M0236,M0237` — redundant type instantiation (M0223), suggest contextual dot notation (M0236), suggest redundant explicit arguments (M0237). These are allowed (disabled) by default; `-W=` enables them as warnings.\n\n### Moc Args Layering\n\nFlags are applied in this order (later overrides earlier):\n\n1. `[moc].args` — global, all commands (check, build, test, bench, etc.)\n2. `[build].args` — build only (e.g. `--release`)\n3. `[canisters.\u003Cname>.migrations]` — auto-injected `--enhanced-migration` (managed by mops)\n4. `[canisters.\u003Cname>].args` — per-canister\n5. CLI `-- \u003Cflags>` — one-off overrides; supported by `mops check`, `mops build`, `mops check-stable`, `mops generate`, `mops migrate`, `mops test`, and `mops bench`\n\n## Core Commands\n\n### `mops install`\n\n```bash\nmops install            # dev flow: keeps mops.lock in sync, self-heals a broken one\nmops install --locked   # CI flow: fail if mops.lock is missing or would change\n```\n\nRun after cloning or after manual `mops.toml` edits. `mops.lock` is always maintained — there is no flag to opt out, and no `--lock` flag (removed in v3). A missing, unparseable, legacy-format or `mops.toml`-inconsistent lock is regenerated by a plain `mops install`, including locks that still carry absolute local paths from older CLIs, and locks that lost a transitive dependency (a locked package declares a dependency that `deps` no longer lists — typically a botched merge).\n\n`--locked` requires an up-to-date lock and never writes it. It is also available on every implicitly-installing command (`mops build`, `mops check`, `mops check-stable`, `mops check-candid`, `mops test`, `mops bench`, `mops generate candid`), so CI can run `mops test --locked` with no prior install. `mops sources` has no `--locked` (a packtool caller parses its stdout mid-build) — put `mops install --locked` earlier in the pipeline instead.\n\nThe `CI` env var no longer affects lockfile behavior (removed in v3). Commit `mops.lock` — for applications and libraries alike.\n\nA lock also goes stale when a local `path` dependency's own `mops.toml` changes — including one nested further down the chain. `mops install` regenerates it; `--locked` fails until the regenerated lock is committed. Note the first `mops install` after upgrading regenerates the lock of any project that has a `path` dependency, so commit it before running `--locked` in CI. Projects without `path` dependencies keep their existing lock.\n\n`{MOPS_ENV}` in a `path` dependency expands to `$MOPS_ENV` (default `local`), which makes the lock environment-specific. Switching `MOPS_ENV` makes it stale: `mops install` regenerates it, and `--locked` fails with a message naming `MOPS_ENV`. Keep one lock per environment, or drop `--locked` — a lock generated under one `MOPS_ENV` will not satisfy `--locked` under another.\n\nIntegrity is verified at download time, so `mops install` no longer re-hashes `.mops\u002F`: editing a dependency in place will not fail the next install. Use `mops verify` for the on-demand on-disk audit.\n\nDownloaded files are always checked before anything enters the cache — against `mops.lock` when it already records the package, otherwise against the registry. A committed lock therefore makes verification free, which is why a clean checkout installs without asking the registry about hashes.\n\nTwo consequences worth knowing: a corrupt or hand-edited `mops.lock` now fails a _download_ (the error names `mops.lock` as a possible culprit — restore it from version control; already-cached packages are unaffected), and a package the registry publishes no hashes for still installs, unverified, with a warning.\n\nPackages download in parallel through a bounded pool. `mops install --concurrency \u003Cn>` or the `MOPS_CONCURRENCY` env var (works on every installing command) caps simultaneous registry requests; the default derives from the CPU count and the file-descriptor soft limit (4–16). Transient network errors (`fetch failed`, `ECONNRESET`, `EMFILE`) retry automatically with the concurrency halved, up to twice. Set `MOPS_CONCURRENCY=1` only if installs still fail after the retries (an egress proxy capping connections, for example).\n\n### `mops verify`\n\n```bash\nmops verify   # re-hash .mops\u002F against mops.lock, and mops.lock against the registry\n```\n\nCovers GitHub dependencies as well as registry ones.\n\nExits 1 with the offending files and a recovery hint. This is the replacement for anyone who relied on `mops install` failing when `.mops\u002F` had been modified.\n\n### `mops add \u003Cpackage>`\n\n```bash\nmops add core             # latest version\nmops add core@2.5.0       # specific version\nmops add --dev test       # dev dependency\nmops add org\u002Frepo         # GitHub shorthand (also accepts a full github.com url)\nmops add .\u002Fpkg            # local package directory\n```\n\nUpdates `mops.toml` and `mops.lock`.\n\nAdding a package that is already declared in the other section **moves** it rather than declaring it twice. `\u003Cpkg>@\u003Cversion>` replaces the declared version and reports what it replaced; it leaves pinned aliases like `\"core@1.0.0\" = \"1.0.0\"` alone, and there is no flag to create one — write it by hand.\n\n### `mops check`\n\nPrimary correctness command — runs moc check, then check-stable (if configured), then lint (if lintoko is in toolchain).\n\nOn moc 1.15.0+, canisters with `[migrations]` get stricter upgrade diagnostics: a field the initial actor requires that no migration produces fails as an `M0267` error instead of only warning (`M0254`), and compat errors carry a source location. Older moc pins and canisters without `[migrations]` are unaffected either way.\n\nThe `check-stable` baseline is always a `.most` file — as `[canisters.\u003Cname>.check-stable].path` or as the `mops check-stable \u003Cbaseline.most>` argument. A `.mo` source is rejected. See [`mops deployed`](#mops-deployed) for where the baseline comes from — that differs between a fresh project and an already-deployed canister.\n\n```bash\nmops check                # all canisters\nmops check backend        # single canister\nmops check --fix          # autofix + check + stable + lint\nmops check --no-lint      # skip the lint step for one run\nmops check --verbose      # show moc invocations\nmops check -- -Werror     # treat warnings as errors\n```\n\n**Always use canister names, not file paths.** Per-canister args from `mops.toml` are applied automatically.\n\n`--fix` applies machine-applicable fixes from both moc and lintoko in one pass. Concurrent `--fix` runs (across processes) serialize automatically via an advisory lock at `.mops\u002Ffix.lock` — safe to invoke from multiple agents on the same project. Read-only files (e.g. frozen migrations) are skipped with a warning, not fixed.\n\n### `mops build`\n\n```bash\nmops build                # all canisters\nmops build backend        # single canister\nmops build --verbose      # show compiler commands\nmops build --check-wasm   # analyze final Wasm complexity without PocketIC\nmops build --no-check-wasm # skip configured [build].check-wasm once\nmops build --check-deploy  # verify fresh installation on PocketIC\nmops build --no-check-deploy # skip configured [build].check-deploy once\nmops build -- --ai-errors # pass extra moc flags\n```\n\nProduces `.wasm`, `.did`, and `.most` files in `[build].outputDir` (default `.mops\u002F.build`).\n\nWith `[optimize]` in `mops.toml`, runs `wasm-opt` after candid metadata (default `-O3 -g`). Requires a Binaryen pin: `mops toolchain use wasm-opt 131`. Build commands never write the pin themselves, and a `wasm-opt` failure fails the build. Pass `--no-optimize` (on `build` or `bench`) to skip the pass for a single run without editing `mops.toml`.\n\nWhen `--check-wasm` or `[build].check-wasm = true` is enabled, Mops runs fast Walrus analysis on the final Wasm without starting PocketIC. Per-function IC0505 complexity below 750,000 is quiet, 750,000 through 899,999 emits an early warning, and 900,000 or more emits a critical warning. `MOPS-WASM-COMPLEXITY` output includes actionable function metrics, the three largest complexity contributors, and Motoko correction guidance. The estimate never fails the build. Use `--no-check-wasm` to skip configured analysis once.\n\n### `mops deployed`\n\nPost-deploy hook — keeps the on-disk `.most` baseline used by `check-stable` in sync with what's actually deployed.\n\n```bash\nmops deployed init backend   # one-time bootstrap: empty-actor baseline + sets [check-stable].path\nmops deployed backend        # post-deploy: promotes .mops\u002F.build\u002Fbackend.most → deployed\u002Fbackend.most\nmops deployed                # all canisters\n```\n\nDefault destination is `deployed\u002F\u003Cname>.most`; override with `[deployed].dir` in `mops.toml` or `--dir`. It reads built `.most` files from `[build].outputDir` (default `.mops\u002F.build`); override with `--build-dir`. `mops deployed` errors if the source `.most` is missing — it never regenerates. Run it from your deploy pipeline immediately after a successful deploy.\n\n### `mops generate candid`\n\n```bash\nmops generate candid                # all canisters\nmops generate candid backend        # single canister\nmops generate candid backend -o \u003Cpath>   # single canister, ad-hoc path\n```\n\n(Re)generates the curated `.did` from current Motoko source. With `[canisters.\u003Cname>].candid` set, overwrites that file. Without it, writes `\u003Cname>.did` next to `main` (e.g. `main = \"src\u002FBackend.mo\"` → `src\u002Fbackend.did`) and sets `[canisters.\u003Cname>].candid` in `mops.toml`. Run after every interface change; commit `.did` + `mops.toml` together. Same moc invocation as `mops build`, so the result always passes `mops build`'s subtype check.\n\n### `mops toolchain`\n\n```bash\nmops toolchain use moc 1.15.1        # pin specific version\nmops toolchain use moc latest        # pin latest version (non-interactive)\nmops toolchain use lintoko 0.11.0    # pin specific version\nmops toolchain use pocket-ic 15.0.0  # pin for replica tests \u002F benchmarks \u002F --check-deploy\nmops toolchain use wasm-opt 131      # Binaryen for [optimize] (or `latest`)\nmops toolchain update moc            # update to latest (requires existing [toolchain] entry)\nmops toolchain update                # update all tools to latest\nmops toolchain info \u003Ctool>           # show release info (latest, pinned, history)\nmops toolchain info \u003Ctool> --versions # list recent releases, newest first\nmops toolchain info \u003Ctool> --versions --all # full release history (cache warming)\nmops toolchain info \u003Ctool> --versions --prerelease # include prereleases\nmops toolchain bin moc               # print path to binary\n```\n\n**`pocket-ic` versions**: pin anything from `9.0.0` up, `latest` included — mops keeps no list of blessed versions. Pins below `9.0.0` error with a migration message (they ran on the legacy client that mops 3.0.0 removed). With no pin, replica tests \u002F `mops bench` \u002F `--check-deploy` \u002F `mops toolchain bin pocket-ic` error naming `mops toolchain use pocket-ic 15.0.0`. That version is a hint, not a fallback.\n\n**Agent note**: `toolchain use \u003Ctool>` without a version opens an interactive picker — do not use in scripts or agents. Always pass a version or `latest`. The picker, `latest`, and `--versions` all default to stable releases; pass `--prerelease` to include prereleases. `toolchain update` only works when the tool already has a `[toolchain]` entry. `toolchain info \u003Ctool> --versions` works without `mops.toml` (first GitHub page by default; pass `--all` for full history).\n\n### Enhanced migrations\n\nWhen `[canisters.\u003Cname>.migrations]` is configured, `mops check`, `mops build`, and `mops check-stable` automatically inject `--enhanced-migration`. Do not add `--enhanced-migration` to `[canisters.\u003Cname>].args` — mops will error.\n\nCreate migration files directly in the `chain` directory.\n\nAfter `mops check --fix` (or `mops check \u003Ccanister>`) confirms the chain compiles, run `mops build` to produce the wasm artifact.\n\nUse `mops build --check-deploy`, or set `[build].check-deploy = true` for every build, to install each built Wasm on a fresh PocketIC canister and catch module validation, initialization, and installation failures. Requires `[toolchain] pocket-ic` (a version from `9.0.0` up, or a local binary path) — or set `MOPS_POCKET_IC_URL` to an already-running PocketIC server (the pin is then ignored). Unpinned with no URL, the build errors naming `mops toolchain use pocket-ic 15.0.0`. Use `--no-check-deploy` to skip configured validation once. The command uses each canister's `initArg`, or `()` when omitted. Set `wasmMemoryLimit` to a positive integer byte limit on a canister to check deployment under that limit. PocketIC errors are reported as provided by the client, and installation failures are collected across canisters. Before installation, Mops runs `moc --stable-compatible` from a temporary empty-actor `.most` to each generated `.most`. If moc reports incompatibility, Mops emits `MOPS-CHECK-DEPLOY-SKIPPED` with the compiler diagnostic and does not check that canister on fresh PocketIC. Eligible siblings are still checked; validate the skipped upgrade against representative baseline state.\n\n`check-limit` (optional) caps how many recent chain files `mops check` and `mops lint` consider — useful when the chain grows long and re-checking every old migration slows feedback down. `mops build` is unaffected by `check-limit`; it compiles the full chain, and when `[canisters.\u003Cname>.check-stable].path` is set it also folds the deployed baseline via `--stable-baseline`, so an applied migration edited, deleted, or backdated since deploy fails the build with `M0268` — the backstop for when `check-limit` trims that migration out of the folded `mops check`. When the limit kicks in, mops stages the included files into `.migrations-\u003Ccanister>\u002F` next to the `chain` directory (auto-`.gitignore`d). `moc` diagnostics may then print paths there — the real file lives in the `chain` directory with the same name.\n\nOverride `check-limit` for a single run with `--no-check-limit` (`mops check`, `mops check-stable`, `mops lint`) — e.g. `mops check --fix --no-check-limit` to autofix older, normally-trimmed migrations. On `mops check` and `mops check-stable`, `--no-check-limit` also suppresses the pending-migration warning.\n\nWhen `check-limit` is set, `mops check-stable` (and the stable check inside `mops check`) reports if more migrations are pending than the limit allows — as an error if compat failed (replacing the misleading `moc` message), otherwise a warning.\n\n### `mops remove \u003Cpackage>`\n\n```bash\nmops remove core\n```\n\nRemoves from whichever section declares the package; `--dev` limits it to `[dev-dependencies]`. A package declared in both sections is removed from both.\n\n### Dependency Management\n\n```bash\nmops outdated             # list outdated deps (caret-bound); exit 1 if any, 2 if the check failed\nmops outdated core        # check a single package\nmops update               # rewrite mops.toml versions within caret bound (no major-version crossing)\nmops update core          # update specific package within caret bound\nmops update --major       # allow updates that cross major versions\nmops update --patch       # restrict to patch bumps only (mutually exclusive with --major)\nmops update --verbose     # verbose output\nmops sync                 # add missing \u002F remove unused packages\nmops sync --dry-run       # print what would change, write nothing\n```\n\n`mops update` rewrites `mops.toml` in place (like `cargo upgrade`, not `cargo update`) and re-pins GitHub dependencies to their branch head. Like `mops outdated`, it exits `2` when it cannot run or complete — no `mops.toml`, a package that is not declared, or a dependency that failed to update (the other dependencies are still updated).\n\n`mops sync` needs a pinned `[toolchain] moc` — it reads imports with `moc --print-deps`. Packages imported only from `test`\u002F`tests`\u002F`bench`\u002F`benchmark` directories are added to `[dev-dependencies]`; already-declared packages are never moved between sections.\n\n## Other Commands\n\n### `mops self update`\n\nUpdates a global install (npm\u002Fpnpm `-g`) only, and fails if the `mops` on PATH did not end up on the new version. For `ic-mops` as a project dependency, run `npm i -D ic-mops@\u003Cversion>` instead.\n\n### `mops publish`\n\n```bash\nmops publish              # publish to the registry (runs tests\u002Fdocs\u002Fbench by default)\nmops publish --dry-run    # same local steps as publish; no registry contact \u002F identity\nmops publish --dry-run --no-test --no-docs --no-bench   # packaging checks only\nmops publish --no-test --no-docs --no-bench\n```\n\n`--dry-run` runs the same local publish pipeline (packaging checks, docs, changelog, tests, benchmarks) and prints the final file list, then stops before identity\u002Fupload. `--no-*` flags work as usual. It does **not** run canister config validation (SPDX\u002Fsemver\u002Fname rules) or prove registry acceptance (already published, permissions, missing deps).\n\n### `mops test`\n\nTests live in `test\u002F*.test.mo`:\n\n```bash\nmops test                         # run all tests\nmops test my-test                 # filter by name\nmops test --mode wasi             # use wasmtime (for to_candid\u002Ffrom_candid)\nmops test --reporter files        # one line per file (default is verbose)\nmops test --watch                 # re-run on file changes\nmops test -- -Werror              # pass extra moc flags\n```\n\nReplica tests (actor files or `\u002F\u002F @testmode replica`) run on PocketIC — the `pocket-ic` version from `[toolchain]`, or an already-running server when `MOPS_POCKET_IC_URL` is set (no pin needed; canister log output is not streamed in attached mode). Unpinned with no URL, they error naming `mops toolchain use pocket-ic 15.0.0`. Same for `mops bench` and `mops watch --test`. There is no `--replica` flag and no dfx replica.\n\n### `mops bench`\n\nBenchmarks live in `bench\u002F*.bench.mo`:\n\n```bash\nmops bench                        # run all benchmarks\nmops bench my-bench               # filter by name\nmops bench --gc incremental       # select GC\nmops bench --save                 # save results to .bench\u002F\u003Cname>.json\nmops bench --compare              # compare with saved results\nmops bench -- -Werror             # pass extra moc flags\n```\n\n### `mops lint`\n\nRuns lintoko (also runs automatically as part of `mops check` when lintoko is in toolchain):\n\n```bash\nmops lint                 # lint all .mo files\nmops lint --fix           # autofix lint issues\nmops lint \u003Cname>          # filter to .mo files matching \u003Cname>\n```\n\nWhen `[canisters.\u003Cname>.migrations].check-limit` is set, `mops lint` skips the trimmed chain migrations to match what `moc` sees during `mops check`. To lint a trimmed migration on demand, pass an explicit filter (e.g. `mops lint OldMigrationName`) or `--no-check-limit` to lint the full chain.\n\n### `mops format`\n\n```bash\nmops format               # format all .mo files\nmops format --check       # check formatting without modifying\n```\n\n### `mops watch`\n\n```bash\nmops watch                # errors + warnings + format (the default set)\nmops watch --warning      # errors + warnings only\nmops watch -t             # errors + tests\n```\n\nError checking is always on. Passing any flag selects only the named tasks, so add `-w` \u002F `-f` when you want them alongside `-t`. Those four are the whole set — there is no `--generate` or `--deploy`.\n\n## Common Patterns\n\n### Warning suppression for a canister\n\nUse per-canister `args` (not global) for suppressions:\n\n```toml\n[canisters.backend]\nmain = \"src\u002Fbackend\u002Fmain.mo\"\nargs = [\"-A=M0198\"]\n```\n\n### New project\n\n```bash\nmops init -y\nmops toolchain use moc latest        # pin latest moc (non-interactive)\nmops toolchain use lintoko latest    # pin latest lintoko\nmops add core\n```\n\nThen configure `[moc].args`, `[canisters]`, and `[build]` in `mops.toml`.\n\nTo update tools later: `mops toolchain update moc` or `mops toolchain update` (all tools).\n",{"name":5,"license":15,"metadata":49,"description":7,"compatibility":52},{"title":50,"category":51},"Mops CLI","Infrastructure","mops >= 3.3.0","main","3df1d0d67b30ff15236561f8c0f9f06d33f42dfd","skills\u002Fchains\u002Fdfinity-official-mops-cli",17,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia","https:\u002F\u002Feth2030.com","Hardcore infra. Building @alt-research and applied cryptography.","2026-11-12 02:28:42",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add jiayaoqijia\u002Fcryptoskill --skill mops-cli",{"tool":68,"command":69},"bunx","bunx skills add jiayaoqijia\u002Fcryptoskill --skill mops-cli",{"tool":71,"command":72},"pnpm","pnpm dlx skills add jiayaoqijia\u002Fcryptoskill --skill mops-cli","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fdfinity-official-mops-cli\u002FSKILL.md",true,[76,80,86],{"path":77,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":16},"LICENSE","许可证",10770,{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"SOURCE.md","REFERENCE","参考文档",326,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fdfinity-official-mops-cli\u002FSOURCE.md",{"path":87,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":88,"sourceHtmlUrl":89},"TRUST.auto.yaml",2197,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fdfinity-official-mops-cli\u002FTRUST.auto.yaml",[91,120,142,160,173,183],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":95,"licenseFileUrl":96,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":44},"01M712C436EQYE43342Q4E7GG1","recipe-performance","Diagnose a specific MetaMask user flow's real-app performance and Sentry critical-user-flow telemetry with deterministic mm-harness recipes. Use for CUF boundaries, cold\u002Fwarm\u002Fbackground-resume behavior, latency regressions, lifecycle tags, duplicate or blocking network requests, long tasks, layout\u002Fpaint cost, screen redraws, React rerenders, or browser trace analysis where tests alone cannot prove the real app.","MIT","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FSKILL.md",[],[100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119],"performance","recipe performance","recipe","mm","sentry","harness","app","deterministic","recipes","flow","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":124,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":44},"01M70XT2F8A5CQZ81JBP98KSW3","mexc-spot-websocket","MEXC Spot WebSocket workflows for public streams, protobuf handling, depth maintenance, listen keys, and private streams without exposing API keys.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FSKILL.md",[],[128,129,130,131,132,133,134,135,136,137,138,139,140,141],"mexc spot websocket","spot","websocket","api","workflows","public","listen","streams","depth","keys","for","api keys","maintenance","protobuf",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":146,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":44},"01M70XT0MBXN3WZY1BKN0CPNKR","mexc-spot-rest","MEXC Spot REST workflows for public data, signed account requests, orders, wallet\u002Fadmin actions, and secure signing without exposing API keys.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FSKILL.md",[],[150,129,151,152,153,154,155,139,138,137,156,157,158,133,159,132,131],"mexc spot rest","REST","admin","signing","Wallet","requests","actions","secure","data","orders",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":164,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":44},"01M70XSYSVZ2N0N91XCAR2CAK0","mexc-futures-websocket","MEXC Futures WebSocket workflows for public streams, private account\u002Forder\u002Fposition streams, ping\u002Fpong, subscriptions, and depth maintenance.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FSKILL.md",[],[168,169,130,170,171,140,138,172,136,135,133,132],"mexc futures websocket","futures","position","ping","subscriptions",{"skillNo":174,"name":175,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":95,"licenseFileUrl":176,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":44},"01M6H0ZWHVE5W04WG2DKQE2SQC","0xklen-version-and-refresh-sanctions-lists","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FSKILL.md",[],[180,181,182],"refresh","0xklen version and refresh sanctions lists","version",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":95,"licenseFileUrl":187,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":44},"01M6H0Z28Q3R8J0S799GJQWXM3","verify-tests-cover-changed-lines","Use when a PR adds code that the existing suite may not exercise. Measures patch coverage — the share of newly changed lines hit by tests — before approving.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FSKILL.md",[],[191,192,193,194,195,196,197,38,198,199,200],"tests","cover","verify tests cover changed lines","verify","coverage","pr","exercise","patch","code","share"]