chore: sync mops-cli skill from upstream cli-v2.15.2 (#236)

Author: marc0olo

.claude/upstream.md

@@ -52,8 +52,8 @@ Upstream file paths are relative to `.agents/skills/<upstream-skill-name>/` in t
 ## mops-cli
 
 - **Upstream:** https://github.com/caffeinelabs/mops
-- **Tag:** cli-v2.14.0
-- **Commit:** d448cdf90991c3164cafd8b6d1b39f433ad820b1
-- **Last synced:** 2026-06-16
+- **Tag:** cli-v2.15.2
+- **Commit:** 564a380c945022ef6e47aa85c40197c037e49b83
+- **Last synced:** 2026-07-01
 - **Upstream file:** `.agents/skills/mops-cli/SKILL.md`
 - **icskills-owned sections:** none — body is 1:1 with upstream; only frontmatter differs

evaluations/mops-cli.json

@@ -83,6 +83,45 @@
         "Notes the same pin also applies to `mops bench` and `mops watch`"
       ]
     },
+    {
+      "name": "check-stable baseline bootstrap",
+      "prompt": "I'm starting a brand-new mops project and want to enable `check-stable`. There's no deployed version yet, so what do I use as the `.most` baseline for `[check-stable].path`? Just the setup, no deploy steps.",
+      "expected_behaviors": [
+        "Uses `mops deployed init <canister>` to bootstrap the empty-actor baseline",
+        "Explains `mops deployed init` also sets `[check-stable].path` in mops.toml",
+        "Does NOT tell the user to hand-write a trivial `.most` file (e.g. `// Version: 1.0.0\\nactor { };`)",
+        "May note the default destination is `deployed/<name>.most`"
+      ]
+    },
+    {
+      "name": "Post-deploy .most promotion",
+      "prompt": "After I deploy my `backend` canister, how do I keep the `check-stable` baseline in sync with what's actually deployed? Just the command and where it should run.",
+      "expected_behaviors": [
+        "Uses `mops deployed backend` (or `mops deployed` for all canisters) after a successful deploy",
+        "Explains it promotes the built `.most` (from `[build].outputDir`, default `.mops/.build`) to `deployed/<name>.most`",
+        "Notes it should run in the deploy pipeline immediately after deploy",
+        "Does NOT claim `mops deployed` regenerates or rebuilds the `.most` (it errors if the source is missing)"
+      ]
+    },
+    {
+      "name": "Regenerating candid interface",
+      "prompt": "I changed the public interface of my `backend` Motoko canister and want to regenerate its `.did` file. What's the mops command and what does it do? No deploy steps.",
+      "expected_behaviors": [
+        "Uses `mops generate candid backend` (or `mops generate candid` for all canisters)",
+        "Explains it (re)generates the `.did` from the current Motoko source",
+        "May note the result is committed alongside `mops.toml`",
+        "Does NOT suggest hand-editing the `.did` file or using `dfx generate`"
+      ]
+    },
+    {
+      "name": "Autofix trimmed migrations with --no-check-limit",
+      "prompt": "My canister has `check-limit` set on its migration chain, but I need to run `mops check --fix` across the older, normally-trimmed migrations too. How?",
+      "expected_behaviors": [
+        "Adds `--no-check-limit` to the command (e.g. `mops check --fix --no-check-limit`)",
+        "Explains `--no-check-limit` overrides `check-limit` for a single run",
+        "Does NOT suggest permanently removing or raising `check-limit` in mops.toml as the only option"
+      ]
+    },
     {
       "name": "Adversarial: file path to mops check",
       "prompt": "I want to type-check my canister. My main file is at src/backend/main.mo. I'll run: mops check src/backend/main.mo. Is that right?",
@@ -117,7 +156,9 @@
       "Configure moc flags for my Motoko canister",
       "My mops.lock file is stale, what do I do?",
       "How do I add a dev dependency with mops?",
-      "How do I configure the moc toolchain version in mops?"
+      "How do I configure the moc toolchain version in mops?",
+      "How do I regenerate the candid .did file for my Motoko canister with mops?",
+      "How do I keep my check-stable .most baseline in sync after deploying?"
     ],
     "should_not_trigger": [
       "Write a Motoko persistent actor with a counter",

skills/mops-cli/SKILL.md

@@ -2,7 +2,7 @@
 name: mops-cli
 description: "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."
 license: Apache-2.0
-compatibility: "mops >= 2.14.0"
+compatibility: "mops >= 2.15.2"
 metadata:
   title: Mops CLI
   category: Infrastructure
@@ -43,21 +43,16 @@ chain = "src/backend/migrations"
 check-limit = 10   # optional — speeds up `mops check` when the chain gets long
 
 [canisters.backend.check-stable]
-path = ".old/src/backend/dist/backend.most"
+path = "deployed/backend.most"
 
 [build]
 outputDir = "src/backend/dist"
 args = ["--release"]
 ```
 
-`check-stable` verifies stable variable compatibility against a `.most` file from the deployed version. For a new project with no prior deployment, create a trivial `.most` file representing an empty actor:
+`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.
 
-```most
-// Version: 1.0.0
-actor {
-  
-};
-```
+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`](#mops-deployed) below).
 
 Optional canister fields: `candid` (path to .did for compatibility checking), `initArg` (Candid-encoded init args).
 
@@ -109,7 +104,7 @@ mops check -- -Werror     # treat warnings as errors
 
 **Always use canister names, not file paths.** Per-canister args from `mops.toml` are applied automatically.
 
-`--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/fix.lock` — safe to invoke from multiple agents on the same project.
+`--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/fix.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.
 
 ### `mops build`
 
@@ -122,6 +117,28 @@ mops build -- --ai-errors # pass extra moc flags
 
 Produces `.wasm`, `.did`, and `.most` files in `[build].outputDir` (default `.mops/.build`).
 
+### `mops deployed`
+
+Post-deploy hook — keeps the on-disk `.most` baseline used by `check-stable` in sync with what's actually deployed.
+
+```bash
+mops deployed init backend   # one-time bootstrap: empty-actor baseline + sets [check-stable].path
+mops deployed backend        # post-deploy: promotes .mops/.build/backend.most → deployed/backend.most
+mops deployed                # all canisters
+```
+
+Default destination is `deployed/<name>.most`; override with `[deployed].dir` in `mops.toml` or `--dir`. It reads built `.most` files from `[build].outputDir` (default `.mops/.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.
+
+### `mops generate candid`
+
+```bash
+mops generate candid                # all canisters
+mops generate candid backend        # single canister
+mops generate candid backend -o <path>   # single canister, ad-hoc path
+```
+
+(Re)generates the curated `.did` from current Motoko source. With `[canisters.<name>].candid` set, overwrites that file. Without it, writes `<name>.did` next to `main` (e.g. `main = "src/Backend.mo"` → `src/backend.did`) and sets `[canisters.<name>].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.
+
 ### `mops toolchain`
 
 ```bash
@@ -144,6 +161,10 @@ Create migration files directly in the `chain` directory.
 
 `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`. When the limit kicks in, mops stages the included files into `.migrations-<canister>/` 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.
 
+Override `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.
+
+When `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.
+
 ### `mops remove <package>`
 
 ```bash
@@ -156,8 +177,8 @@ mops remove base
 mops outdated             # list outdated dependencies (caret-bound)
 mops update               # update all within caret bound (no major-version crossing)
 mops update core          # update specific package within caret bound
-mops update --patch       # restrict to patch bumps only (mutually exclusive with --major)
 mops update --major       # allow updates that cross major versions
+mops update --patch       # restrict to patch bumps only (mutually exclusive with --major)
 mops sync                 # add missing / remove unused packages
 ```
 
@@ -187,7 +208,7 @@ mops lint --fix           # autofix lint issues
 mops lint <name>          # filter to .mo files matching <name>
 ```
 
-When `[canisters.<name>.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`).
+When `[canisters.<name>.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.
 
 ### `mops format`
 
@@ -220,3 +241,5 @@ mops add core
 Then configure `[moc].args`, `[canisters]`, and `[build]` in `mops.toml`.
 
 To update tools later: `mops toolchain update moc` or `mops toolchain update` (all tools).
+</content>
+</invoke>