rigortype 0.2.1 → 0.2.3

data/skills/rigor-monkeypatch-resolve/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: rigor-monkeypatch-resolve
+description: |
+  Resolve a cluster of `call.unresolved-toplevel` / `call.undefined-method` diagnostics that are really the project's own monkey-patches (core-extension files that add methods with literal `def`) by wiring them into `pre_eval:` so Rigor pre-evaluates them and learns the added methods. Triggers: "Rigor flags methods my core-ext adds", "undefined-method on my own monkey-patch", "set up pre_eval", "lots of unresolved-toplevel from my lib/core_ext". NOT for dynamically-generated methods (define_method / method_missing / class_eval heredocs) — those need a plugin (use rigor-plugin-author) — and NOT for an external gem with no RBS (use rigor-rbs-setup).
+license: MPL-2.0
+metadata:
+  version: 0.1.0
+  homepage: https://github.com/rigortype/rigor
+---
+
+# Rigor Monkeypatch Resolve
+
+When a project adds methods to existing classes in its own files — the
+classic `lib/core_ext/*.rb` `class String; def squish; …; end` pattern —
+Rigor does not see them unless told to, so every call to the added method
+fires `call.undefined-method` (or `call.unresolved-toplevel` for a
+top-level helper). `pre_eval:` ([ADR-17](https://github.com/rigortype/rigor/blob/master/docs/adr/17-monkey-patch-pre-evaluation.md))
+fixes this: it pre-evaluates the listed project files and registers every
+method they define with a **literal** `def` / `def self.`.
+
+## When to use
+
+- `rigor triage` shows a cluster of `call.undefined-method` /
+  `call.unresolved-toplevel` whose receiver is a core class the project
+  monkey-patches (or a top-level helper the project defines).
+
+## When NOT to use
+
+- The methods are **generated dynamically** (`define_method` with a
+  computed name, `method_missing`, a `class_eval <<~RUBY … def #{name}`
+  heredoc). `pre_eval:` walks for *literal* `def`s and will not find
+  them — that residue is a `rigor-plugin-author` job.
+- The cluster is on a **third-party gem** with no RBS — that is
+  `rigor-rbs-setup`.
+
+## Procedure
+
+### Phase 1 — confirm it is a monkey-patch cluster
+
+```sh
+rigor triage --format json
+```
+
+Look at the `selectors` / `hotspots`: a cluster keyed on a core receiver
+(`String#squish`, `Integer#…`) or a top-level helper, all pointing back
+to a file in your project that defines them. Open that file and confirm
+the methods are written as literal `def` / `def self.`.
+
+### Phase 2 — wire the file(s) into `pre_eval:`
+
+Add the defining file paths to `pre_eval:` in `.rigor.dist.yml` (paths
+are resolved relative to the config file):
+
+```yaml
+pre_eval:
+  - lib/core_ext/string.rb
+  - lib/core_ext/integer.rb
+```
+
+List the **files that contain the `def`s**, not the call sites.
+
+### Phase 3 — verify the cluster cleared
+
+```sh
+rigor check
+```
+
+The `call.undefined-method` cluster on those methods should be gone. If
+some survive, those specific methods are almost certainly
+**dynamically generated** — `pre_eval:` cannot reach them, and the
+durable fix is a project plugin (hand off to `rigor-plugin-author`). A
+genuine typo (a real undefined method) correctly keeps firing — do not
+add it to `pre_eval:`.
+
+## Next step
+
+Re-run `rigor skill describe`. With the monkey-patch noise gone, the
+remaining diagnostics are a cleaner target for `rigor-baseline-reduce`
+or `rigor-protection-uplift`.

data/skills/rigor-next-steps/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: rigor-next-steps
+description: |
+  Route a project to its next Rigor step from a single entry point: resolve the `rigor` command (install it if missing), onboard the project if it has no Rigor config, then ask `rigor skill describe` what to do next and hand off to the matching skill. Triggers: "what should we do next with Rigor?", "I want to use Rigor on this project", "help me move this project forward with Rigor", "where do I start with Rigor?". NOT a replacement for the task-specific skills it routes to — it hands off to them.
+license: MPL-2.0
+metadata:
+  version: 0.1.0
+  homepage: https://github.com/rigortype/rigor
+---
+
+# Rigor Next Steps
+
+The single entry point for "what should we do next with Rigor on this
+project?" This skill is deliberately **thin**: it only does the
+bootstrap that must happen before `rigor` can speak for itself, then it
+hands the decision to the installed `rigor` binary via
+`rigor skill describe`. That keeps the advice **current to the
+installed version** — the routing intelligence lives in the gem, not
+frozen in this file (ADR-73).
+
+Work top to bottom. Stop at the first step that is not yet satisfied,
+complete it, then continue.
+
+## Step 1 — Resolve the `rigor` command
+
+```sh
+rigor --version
+```
+
+If it prints a version (`rigor 0.x.y`), `rigor` is installed — go to
+**Step 3**. If the command is not found, go to **Step 2**.
+
+## Step 2 — Install Rigor (only if Step 1 failed)
+
+Rigor is a standalone tool, **not** a project dependency — do not add it
+to the `Gemfile`. Fetch and follow the install guide, which is written
+for an AI agent and picks the right channel (mise / asdf / gem / Docker)
+for the environment:
+
+- <https://raw.githubusercontent.com/rigortype/rigor/master/docs/install.md>
+
+Follow it until `rigor --version` succeeds, then continue to Step 3.
+
+(This is the one step that cannot be driven by `rigor skill describe` —
+there is no binary to ask yet. It is the only install knowledge this
+skill carries, kept as a pointer rather than a copy so it does not go
+stale.)
+
+## Step 3 — Set the project up if it has no Rigor config
+
+Check the project root for `.rigor.yml` or `.rigor.dist.yml`. If
+**neither** exists, the project has never been onboarded — set it up
+first:
+
+```sh
+rigor skill rigor-project-init
+```
+
+Follow that skill's body top to bottom (it detects the stack, picks
+plugins, writes `.rigor.dist.yml`, and snapshots a baseline if needed),
+then come back to Step 4.
+
+## Step 4 — Ask `rigor skill describe` what to do next
+
+Once `rigor` is installed and the project is configured, let the live
+command pick the next move:
+
+```sh
+rigor skill describe
+```
+
+Its output reports the project's current state (config / baseline /
+`sig/` / CI), names a **recommended next skill** with a one-line reason,
+and lists every skill you can run next with its current description.
+
+## Step 5 — Route and act
+
+Read the `## Recommended next step` and `## For the agent` sections of
+the `describe` output, then:
+
+- **Present the recommendation to the user proactively** — e.g. "Rigor
+  is set up but not wired into CI; I suggest the `rigor-ci-setup` skill
+  to lock in the regression guard. Shall I?" — rather than only asking
+  an open question.
+- If the user has a different goal, ask which skill they want from the
+  listed catalog.
+- Then load the chosen skill and follow it:
+
+  ```sh
+  rigor skill <chosen-skill>
+  ```
+
+Re-run `rigor skill describe` any time you want the next step again — it
+always reflects the project's current state, so this skill stays useful
+across the whole adoption journey, not just the first run.
+
+## Reading the docs offline
+
+Once Rigor is installed (Step 1 succeeded), the full manual **and
+handbook** ship inside the gem — read any chapter **without the
+network**:
+
+```sh
+rigor docs                 # the offline doc index (what's available)
+rigor docs <name>          # a chapter, e.g. `rigor docs editor-integration`
+rigor docs --list          # name + absolute path for every bundled doc
+rigor docs --list handbook # just the handbook chapters
+```
+
+Prefer this over fetching the same page from the web: it is the exact
+copy that shipped with the installed `rigor`, so it always matches the
+binary's behaviour. (The web copy at <https://rigor.typedduck.fail/llms.txt>
+is for the contributor-facing corpus and for reading before install.)

data/skills/rigor-plugin-tune/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: rigor-plugin-tune
+description: |
+  Re-scan a configured project's Gemfile.lock against Rigor's bundled plugin catalogue and enable the plugins that match its current dependencies (Rails, RSpec, dry-rb, Sidekiq, Devise, …), then verify they all load. Run it after adding a gem, or when an onboarding predates a dependency the project now uses. Triggers: "enable the right Rigor plugins", "I added gem X, does Rigor have a plugin?", "which rigor plugins should this project use?", "rigor plugins for my stack". NOT for first-time onboarding (use rigor-project-init, which does the initial selection) and NOT for authoring a new plugin (use rigor-plugin-author).
+license: MPL-2.0
+metadata:
+  version: 0.1.0
+  homepage: https://github.com/rigortype/rigor
+---
+
+# Rigor Plugin Tune
+
+`rigor-project-init` selects plugins once, at onboarding. Dependencies
+drift afterward — a project adds Sidekiq, adopts dry-rb, brings in
+shoulda-matchers — and the bundled Rigor plugin that understands the new
+gem is not enabled until someone wires it. This skill is the recurring
+"re-match plugins to the current Gemfile.lock" pass.
+
+All `rigor-*` plugins ship **bundled inside the `rigortype` gem** — no
+separate install. Enabling one is just adding its id to `plugins:` in
+`.rigor.dist.yml`.
+
+## When to use
+
+- The project added (or removed) a gem since it was onboarded.
+- `rigor check` is missing framework knowledge (e.g. ActiveRecord
+  relation methods, RSpec matchers) that a bundled plugin would supply.
+
+## When NOT to use
+
+- First-time setup — `rigor-project-init` does the initial selection.
+- A gem with **no** bundled plugin and no RBS — that is
+  `rigor-rbs-setup` (community RBS) or, for your own DSL,
+  `rigor-plugin-author`.
+
+## Procedure
+
+### Phase 1 — list what is enabled vs what is installed
+
+Read the current `plugins:` in `.rigor.dist.yml`, and the project's
+dependencies in `Gemfile.lock`.
+
+### Phase 2 — match against the bundled catalogue
+
+The authoritative, current list of bundled plugins (the count drifts as
+new ones land) is the catalogue:
+
+<https://github.com/rigortype/rigor/blob/master/plugins/README.md>
+
+For each Gemfile.lock dependency, check whether a bundled `rigor-<gem>`
+plugin exists and is **not** already in `plugins:`. Common matches:
+`activerecord`/`actionpack` → the Rails plugins, `rspec` → `rigor-rspec`,
+`dry-*` → the dry-rb plugins, `devise`, `sidekiq`, `sorbet`, etc. Add the
+missing ones to `plugins:`.
+
+### Phase 3 — verify every plugin loads
+
+```sh
+rigor plugins --strict
+```
+
+`rigor plugins` reports the activation status of every configured plugin;
+`--strict` exits non-zero on any activation failure (ideal as a CI gate).
+Fix any failure it reports (a misspelled id, a missing `signature_paths:`)
+before moving on.
+
+### Phase 4 — re-check
+
+```sh
+rigor check
+```
+
+The framework calls the newly-enabled plugins understand should now
+resolve. If enabling a plugin surfaced new diagnostics, treat the diff as
+usual (baseline regenerate in acknowledge mode, or fix genuine findings).
+
+## Next step
+
+Re-run `rigor skill describe` for the next move.

data/skills/rigor-protection-uplift/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: rigor-protection-uplift
+description: |
+  Close the type-protection holes `rigor coverage --protection` surfaces: for each unprotected dispatch site, run `rigor sig-gen` first, hand-author only the minimal residual annotation, then verify with a double gate — the site becomes protected AND `rigor check` gains no new diagnostic. Triggers: "raise type protection", "add types where Rigor can't catch bugs", "act on coverage --protection / --mutation output", "make more of this code bug-catchable". NOT for Rigor's own `lib/` or the bundled plugins (use `rigor sig-gen` directly there and treat gaps as engine signal), and NOT for first-time setup (use rigor-project-init).
+license: MPL-2.0
+metadata:
+  version: 0.1.0
+  homepage: https://github.com/rigortype/rigor
+---
+
+# Rigor Protection Uplift
+
+`rigor coverage --protection` (Tier 1) and `rigor coverage --protection
+--mutation` (Tier 2) *surface* "add a type here" — they never author the
+type. This skill *acts* on that surfacing under the discipline that keeps
+Rigor false-positive-safe: protection goes up, and not one line of
+working code starts reporting a new diagnostic.
+
+## When to use
+
+- A user wants to raise how much of their code Rigor can actually catch
+  bugs in.
+- You have `coverage --protection` output (an "add a type here" list) and
+  want to close it.
+
+## When NOT to use
+
+- **Rigor's own `lib/`, or the bundled `plugins/` / `examples/`** — the
+  self-check tree. Hand-authoring types there collides with the
+  sig-gen-first ethos; run `rigor sig-gen` directly and treat residual
+  gaps as engine signal to report, not a private fix.
+- **"Make my code more precise" with no protection goal** — that is
+  `rigor coverage` (precision), not `--protection`.
+- **A project with no Rigor config yet** — onboard first with
+  `rigor-project-init`.
+
+## Load-bearing rules (read before touching a single type)
+
+1. **The signal prioritises and verifies; the contract sources the
+   type.** Never write the type the coverage/mutation signal "wants".
+   Write the type the code *actually has*, derived from the
+   implementation and its callers. A type guessed from the signal is a
+   false-confidence type — worse than no type.
+2. **sig-gen first.** A hand-written annotation is only the *residual*
+   `rigor sig-gen` cannot reach. Every residual is a sig-gen-improvement
+   to report, not just a private fix.
+3. **"Minimal" = annotation footprint, not minimal-to-kill-the-mutant.**
+   Optimising literally for mutant death games the metric. Add the
+   smallest *true* annotation that models the contract; if that also
+   kills the mutant, good.
+4. **Robustness (ADR-5).** Tighten returns, keep parameters lenient. An
+   over-tight param annotation breaks callers and breaches the
+   false-positive discipline.
+
+## Procedure
+
+### Phase 1 — surface the holes
+
+```sh
+rigor coverage --protection --format json PATHS
+```
+
+Read the ranked "add a type here" list (`count`, `method_name`,
+`examples`). Optionally confirm the highest-traffic ones actually buy
+catching power with the Tier 2 deep dive:
+
+```sh
+rigor coverage --protection --mutation --format json   # changed-files by default
+```
+
+### Phase 2 — sig-gen first
+
+```sh
+rigor sig-gen --diff PATHS      # inspect; --write to apply
+```
+
+Adopt every concrete inferred signature. Note where sig-gen emits
+`untyped` for a site on the "add a type here" list — that is the
+**residual** Phase 3 owns.
+
+### Phase 3 — author the residual (cheapest carrier per hole class)
+
+| Hole class                          | Cheapest carrier                              |
+| ----------------------------------- | --------------------------------------------- |
+| `Dynamic` method return             | annotate that method's return in `sig/…rbs`   |
+| `Dynamic[top] \| nil` ivar read     | `# @rbs @field: T` (ADR-58 territory)         |
+| untyped param feeding the receiver  | a *lenient* param annotation                  |
+
+Write the minimal true type. Prefer annotating the *upstream* source of
+the Dynamic (the method return / the ivar) over the call site itself.
+
+**Trap (carrier-additivity):** a sidecar `sig/…rbs` is NOT purely
+additive. Declaring a class there flips it from inference-mode to
+RBS-declared mode and *drops every member the RBS omits* — a lone
+`def formatted: () -> String` can make Rigor forget the inferred
+`initialize` and reject `Money.new(500)`. So either (1) adopt the full
+Phase-2 sig-gen base into the file and add the residual on top, or
+(2) use an in-place additive carrier (rbs-inline `#:` / a
+`%a{rigor:v1:…}` return-override) that annotates the method without
+re-declaring the class. "Minimal footprint" means the smallest *true*
+type, never the smallest *file*.
+
+### Phase 4 — double-gate verify (both must hold)
+
+```sh
+rigor coverage --protection PATHS   # (a) the site is now protected / ratio up
+rigor check PATHS                   # (b) no NEW diagnostic vs the post-sig-gen baseline
+```
+
+If (b) regresses, the annotation modeled the wrong contract — **revert
+it**, do not suppress the diagnostic. If (a) did not move, the carrier
+was wrong (often: you typed the call site, not the upstream Dynamic
+source). Gate (b) is a *diff* against the post-sig-gen state, not an
+absolute "zero diagnostics" — sig-gen itself can surface the
+acknowledge-mode FP envelope a project baseline absorbs; this skill owns
+only the increment it adds.
+
+### Phase 5 — feed the residual back
+
+File each Phase-3 residual as a sig-gen gap (what shape did inference
+miss?). The hand annotation is the stopgap; the durable fix is raising
+inference so the residual disappears.
+
+## Honest bounds
+
+Hand-RBS uplift is a finisher, not a path to 80% protection. The
+dominant remaining holes after this loop are intractable from
+annotation alone — external-gem Dynamic receivers, polymorphic value
+types, generic type parameters, dynamically-built classes. Those need
+parametric types / external RBS / engine folding (and are where the
+`rigor-plugin-author` escalation or a Rigor issue comes in), not another
+hand annotation. Expect a low-20s → low-30s% protection lift on a mature
+library, at zero diagnostic cost.

data/skills/rigor-rbs-setup/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: rigor-rbs-setup
+description: |
+  Install community RBS for the project's gems with `rbs collection install`, so Rigor stops typing calls into RBS-less dependencies as `Dynamic` and gains real coverage (and real bug-catching) on them. Rigor auto-detects the resulting `rbs_collection.lock.yaml` — no Rigor config change needed. Triggers: "set up rbs collection", "my gems type as Dynamic", "rigor check says N gems have no RBS available", "reduce false positives from untyped gems". NOT for first-time Rigor setup (use rigor-project-init first) and NOT for a gem that has no entry in the community collection (that needs rigor-plugin-author or a Rigor issue).
+license: MPL-2.0
+metadata:
+  version: 0.1.0
+  homepage: https://github.com/rigortype/rigor
+---
+
+# Rigor RBS Setup
+
+Most of what Rigor cannot type on a real application is the surface of
+third-party gems that ship **no RBS**: a call into such a gem returns
+`Dynamic`, so every downstream method on the result is unprotected and
+some genuine bugs go uncaught. The Ruby ecosystem's answer is the
+community RBS collection at
+[`ruby/gem_rbs_collection`](https://github.com/ruby/gem_rbs_collection);
+this skill wires it into the project.
+
+## When to use
+
+- `rigor check` ends with `info: N gem(s) in Gemfile.lock have no RBS
+  available: …` — that list is the gap this skill closes.
+- A deep call chain into a gem (an HTTP client, a parser, a service
+  object) types as `Dynamic` and you want Rigor to see through it.
+
+## When NOT to use
+
+- The project has no Rigor config yet — run `rigor-project-init` first.
+- A specific gem you need is **not in** the community collection — RBS
+  setup will not cover it. That residue is for `rigor-plugin-author` (if
+  it is your own DSL) or a Rigor issue (if it is a popular gem worth
+  built-in support).
+
+## How Rigor consumes it (so you know what "done" looks like)
+
+Rigor **auto-detects** `rbs_collection.lock.yaml` at the project root
+(`rbs_collection.auto_detect` defaults to `true`) and feeds each gem's
+downloaded RBS directory into its signature paths, skipping `stdlib`
+entries it already bundles. **No `.rigor.yml` change is required** — the
+lockfile's presence is the whole wiring. (Set `rbs_collection.lockfile:`
+only if the lockfile lives somewhere other than the project root.)
+
+## Procedure
+
+### Phase 1 — see the gap
+
+```sh
+rigor check
+```
+
+Read the closing `info` line listing the gems with no RBS. That is your
+target set.
+
+### Phase 2 — make the `rbs` CLI available
+
+`rbs collection` is part of the `rbs` gem and reads the project's
+`Gemfile.lock`. Check it is runnable:
+
+```sh
+rbs --version            # or: bundle exec rbs --version
+```
+
+If it is missing, add it to the project's development group
+(`bundle add rbs --group development`) or install it standalone
+(`gem install rbs`). Prefer `bundle exec rbs …` when `rbs` is in the
+Gemfile so it matches the project's resolved versions.
+
+### Phase 3 — initialise the collection config (first time only)
+
+```sh
+rbs collection init
+```
+
+This writes `rbs_collection.yaml` (which gems to pull, which to ignore).
+Skip if the file already exists; review it either way — the default
+pulls RBS for every gem in the lockfile that the collection knows.
+
+### Phase 4 — install
+
+```sh
+rbs collection install      # bundle exec rbs collection install when bundled
+```
+
+This resolves against `ruby/gem_rbs_collection`, writes
+`rbs_collection.lock.yaml`, and downloads the `.rbs` files into
+`.gem_rbs_collection/`.
+
+### Phase 5 — verify (re-check; watch for new diagnostics)
+
+```sh
+rigor check
+```
+
+Two things to confirm:
+
+1. **The `info` "no RBS available" list shrank** — the gems now covered
+   dropped off it.
+2. **No surprising new diagnostics.** Community RBS occasionally ships a
+   signature stricter than the gem's real runtime behaviour, which can
+   surface a false positive. Treat the diff like any other:
+   - In **acknowledge mode**, regenerate the baseline
+     (`rigor baseline regenerate`) so the new envelope is recorded.
+   - For a **genuine** new error the sharper types caught, that is a win
+     — fix it.
+   - For a clear RBS-quality false positive, `# rigor:disable <rule>` the
+     site with a reason, or pin the gem out in `rbs_collection.yaml`.
+
+### Phase 6 — commit
+
+Commit the **config + lockfile**, gitignore the **download dir**:
+
+```sh
+# .gitignore
+.gem_rbs_collection/
+```
+
+Commit `rbs_collection.yaml` and `rbs_collection.lock.yaml` so every
+contributor and CI resolves the same RBS. `.gem_rbs_collection/` is
+regenerable from the lockfile (`rbs collection install`), so it is not
+committed.
+
+## Next step
+
+Re-run `rigor skill describe` — with the gem-RBS foundation in place it
+will route you to the next move (CI wiring, baseline work, or protection
+uplift).

data/skills/rigor-upgrade/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: rigor-upgrade
+description: |
+  Adopt a new Rigor version cleanly: after upgrading the `rigortype` gem, re-run the analysis, diff the diagnostics against the committed baseline, and sort the changes into genuine new catches (sharper inference), known sig-quality false positives, and the baseline you should regenerate. Triggers: "I upgraded Rigor, what changed?", "new diagnostics after gem update rigortype", "adopt the new Rigor version", "rigor baseline drifted after upgrade". NOT for first-time setup (use rigor-project-init) or routine baseline work unrelated to an upgrade (use rigor-baseline-reduce).
+license: MPL-2.0
+metadata:
+  version: 0.1.0
+  homepage: https://github.com/rigortype/rigor
+---
+
+# Rigor Upgrade
+
+A new Rigor release sharpens inference and may add or tighten rules, so
+`rigor check` can report diagnostics it did not before — most are the new
+version catching more, a few are sig-quality false positives the new
+sharpness exposes. This skill adopts the upgrade without either blindly
+regenerating the baseline (which buries genuine new catches) or treating
+every new line as a regression.
+
+## When to use
+
+- You just ran `mise use gem:rigortype` / `gem update rigortype` and want
+  to understand what the new version changed about your project's
+  diagnostics.
+
+## Procedure
+
+### Phase 1 — confirm the new version
+
+```sh
+rigor --version
+```
+
+### Phase 2 — see the delta against the committed baseline
+
+```sh
+rigor check
+rigor diff            # compare current diagnostics to the saved baseline JSON
+```
+
+`rigor diff` shows what is **new** relative to the baseline — that set is
+what the upgrade changed.
+
+### Phase 3 — sort the new diagnostics
+
+For each newly-surfaced diagnostic:
+
+- **A genuine new catch** — the sharper inference found a real latent
+  issue. Fix it. (Check `evidence_tier` in `rigor check --format json`:
+  `high` is most likely a true positive.)
+- **A sig-quality false positive** — a known class (Struct
+  `call.wrong-arity`, an over-nilable RBS return, a regex-capture `$1`
+  read). `# rigor:disable <rule>` the site with a reason, or address the
+  RBS. Read `rigor explain <rule>` if unsure whether the rule should fire
+  here.
+- **Expected envelope growth** — broadly acceptable in acknowledge mode.
+
+### Phase 4 — regenerate the baseline (acknowledge mode)
+
+Once you have triaged and fixed the genuine catches, record the new
+envelope so the regeneration does not bury what you just fixed:
+
+```sh
+rigor baseline regenerate
+```
+
+Commit the updated `.rigor-baseline.yml` together with any fixes, so the
+team adopts the same post-upgrade baseline.
+
+## Note
+
+`rigor skill describe` cannot detect that you just upgraded — the
+baseline records only its schema version, not the Rigor version that
+generated it — so this skill is invoked on demand rather than
+recommended automatically. Run it whenever you bump the gem.
+
+## Next step
+
+Re-run `rigor skill describe` for the next move.