rigortype 0.2.6 → 0.2.7

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

@@ -27,6 +27,22 @@ environment.
 > covers the in-repo layout, `plugin_helpers.rb`, and `make verify`.
 > This skill is for plugins that live in *your* project.
 
+## First: load the version-current copy
+
+The plugin contract is pre-1.0 and moving (see the next section), so this
+skill's step detail — in its `references/` files — is exactly the kind that
+drifts between releases. Follow the copy that ships with the **installed**
+Rigor rather than any vendored or frozen copy of this file. Get the complete
+current procedure (body + all references, inline) in one call:
+
+```sh
+rigor skill --full rigor-plugin-author
+```
+
+If you already loaded this skill *via* `rigor skill` you have the current
+copy — just proceed. If the `rigor` command is not available, run
+**`rigor-next-steps`** to install Rigor first, then come back.
+
 ## Important — the plugin contract is a preview (pre-1.0)
 
 Rigor's plugin contract (ADR-2) is **not yet frozen**. It stabilises

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

@@ -0,0 +1,174 @@
+---
+name: rigor-plugin-review
+description: |
+  Review an existing Rigor plugin's source against the current authoring contract and produce a prioritized upgrade path — the modernization counterpart to rigor-plugin-author. Audits config-default declaration (ADR-40), the AST-walk model (node_rule vs a hand-rolled traversal), return-type / narrowing hooks (dynamic_return / narrowing_facts, not the removed flow_contribution_for or deprecated type_specifier), the ADR-60 WD4 authoring helpers (diagnostic / diagnostics_for / suggest / producer_value / read_fact), engine-collaboration vs reimplementation, cache-producer soundness, manifest-field hygiene, and doc freshness. Triggers: "review this Rigor plugin", "does my plugin follow best practices", "upgrade our rigor-prefixed plugin to the latest contract", "modernize this plugin", "is this plugin using the current API". NOT for authoring a new plugin (use rigor-plugin-author), enabling bundled plugins on a project (use rigor-plugin-tune), or tuning plugin config.
+license: MPL-2.0
+metadata:
+  version: 0.1.0
+  homepage: https://github.com/rigortype/rigor
+---
+
+# Rigor Plugin Review
+
+Audit an **existing** Rigor plugin — a bundled one in the rigor
+monorepo (`plugins/` or `examples/`), or your own `rigor-<id>` gem —
+against the current `Rigor::Plugin::Base` authoring contract, and hand
+back a **prioritized upgrade path**. This is the review / upgrade
+counterpart to `rigor-plugin-author` (which creates new plugins).
+
+Plugins written before a contract addition keep working — the gate is
+compatibility, not currency — but they drift from the idiom other
+authors copy. The commonest drift, in rough order of how often it
+appears:
+
+1. **Config defaults** declared with a `DEFAULT_*` constant +
+   `config.fetch(k, DEFAULT)` instead of `config_schema {kind:,
+   default:}` (ADR-40).
+2. **Hand-rolled boilerplate** the ADR-60 WD4 authoring helpers now
+   own — a Levenshtein "did you mean", a `@table`/`@load_error` memo +
+   rescue, a `Diagnostic.new` where a node exists.
+3. **A hand-rolled AST walk** where the engine-owned `node_rule` now
+   fits (ADR-37 / ADR-52).
+4. **Removed / renamed hooks** still named — `flow_contribution_for`
+   (deleted, ADR-52 WD3) or `type_specifier` (deprecated alias for
+   `narrowing_facts`, ADR-80).
+5. **Stale docs** — archaeology about deleted hooks, pinned version
+   references that no longer mean anything.
+
+## First: load the version-current copy
+
+This skill audits against a contract that moves release to release (hook
+renames, new helpers, deprecations), so its checklist — in its
+`references/` files — is only as good as the Rigor it ships with. Follow
+the copy that ships with the **installed** Rigor rather than any vendored
+or frozen copy of this file. Get the complete current procedure (body + all
+references, inline) in one call:
+
+```sh
+rigor skill --full rigor-plugin-review
+```
+
+If you already loaded this skill *via* `rigor skill` you have the current
+copy — just proceed. If `rigor` is not on `PATH`, this task needs it: run
+**`rigor-next-steps`** to install Rigor first, then come back.
+
+## When to use / not use
+
+**Use it** when someone asks to review a plugin's quality, check it
+against best practices, or upgrade it to the current contract — whether
+it lives in the rigor monorepo or in an external repo.
+
+**Do not use it** for:
+
+- **Authoring a new plugin** → `rigor-plugin-author`.
+- **Choosing / enabling bundled plugins on a project** →
+  `rigor-plugin-tune`.
+- **A behavioural bug in a plugin** — that is ordinary debugging, not a
+  contract-conformance pass.
+
+## Read the plugin — and read the contract
+
+Rigor is installed on disk, so both the plugin under review and the
+worked-example plugins are readable source:
+
+```sh
+rigor plugin list                 # every bundled + example plugin, with paths
+rigor plugin print rigor-<id>     # a plugin's main source, inline
+rigor plugin path  rigor-<id>     # its directory, to browse
+```
+
+The **authoritative** authoring surface — the one this review scores
+against — is the internal spec, not this file:
+
+- [`docs/internal-spec/plugin.md`](https://github.com/rigortype/rigor/blob/master/docs/internal-spec/plugin.md)
+  — manifest, `node_rule` / `node_file_context`, `dynamic_return` /
+  `narrowing_facts`, the `#diagnostic` / `#diagnostics_for` / `.suggest`
+  / `#read_fact` author helpers, `config_schema` `{kind:, default:}`.
+- [`docs/internal-spec/plugin-cache-producers.md`](https://github.com/rigortype/rigor/blob/master/docs/internal-spec/plugin-cache-producers.md)
+  — `producer` / `#cache_for` / `#producer_value` / `#producer_error`,
+  ADR-60 WD3 record-and-validate.
+- [`docs/internal-spec/plugin-trust.md`](https://github.com/rigortype/rigor/blob/master/docs/internal-spec/plugin-trust.md)
+  — `TrustPolicy` / `IoBoundary`.
+
+When the checklist below and the spec disagree, **the spec binds** —
+it tracks the installed `rigor` version; this skill is a snapshot.
+
+## Procedure
+
+### Phase 1 — Inventory
+
+Read the plugin's `lib/**/*.rb`, its `README.md`, and its integration /
+unit spec. Note: the `manifest(...)` block, every `config.fetch` /
+`DEFAULT_*` constant, every `Rigor::Analysis::Diagnostic.new`, any
+hand-rolled `levenshtein` / `each_child` walk / cross-plugin `@*_resolved`
+flag, and every mention of `flow_contribution_for` / `type_specifier`.
+
+### Phase 2 — Score against the checklist
+
+Walk [`references/01-best-practices-checklist.md`](references/01-best-practices-checklist.md)
+concern by concern. For each finding, record: the smell, the modern
+replacement, the authoritative citation, and — critically — whether the
+change is **mechanical** (byte-identical diagnostics expected) or
+**design-level** (needs judgment / may change behaviour).
+
+### Phase 3 — Establish the oracle BEFORE changing anything
+
+The plugin's integration spec is the contract you must preserve. Run it
+green first, so you can prove each later step is a faithful refactor:
+
+```sh
+# external gem:
+bundle exec rspec spec/
+# in the rigor monorepo:
+nix … develop --command bundle exec rspec spec/integration/<plugins|examples>/<id>_plugin_spec.rb
+```
+
+If there is no spec, **write one first** (per `rigor-plugin-author`
+Phase 3) — a modernization with no oracle is a guess.
+
+### Phase 4 — Apply the upgrade path, mechanical first
+
+Order the work low-risk → high-risk, and **re-run the spec after every
+step**:
+
+1. **Mechanical (expect byte-identical diagnostics):** ADR-40 config
+   defaults · helper swaps (`suggest` / `producer_value` / `diagnostic`
+   / `diagnostics_for` / `read_fact`) · manifest-field renames (ADR-60
+   WD1/WD2) · doc freshness. A spec that changes here means the swap was
+   not faithful — fix it, do not re-baseline.
+2. **Design-level (may change behaviour — validate empirically):** an
+   AST-walk migration onto `node_rule`; an engine-collaboration refactor
+   that reads `Scope#type_of` instead of a hand-rolled binding map.
+   **Do not delete hand-rolled state before proving the engine gives you
+   the same information** — see the `rigor-units` trap in the checklist
+   (the diagnostics-side `Scope` is a *seed entry scope* without
+   flow-accumulated local bindings, so a cross-statement binding map can
+   be necessary, not redundant).
+
+### Phase 5 — Verify
+
+```sh
+rigor check <plugin>/lib        # ADR-43 contract self-check — MUST be clean
+rigor plugins --strict          # the plugin still loads
+rigor plugins --capabilities    # node-rule types / dynamic_return receivers look right
+bundle exec rspec …             # the oracle spec, still green
+```
+
+In the **rigor monorepo**, the gate is `make check-plugins` (runs
+`rigor check` over every `plugins/*/lib` + `examples/*/lib`) plus
+`make verify`; land the change as its own commit(s) with the spec as
+the byte-identical gate.
+
+## Output
+
+Hand the user a table — smell → replacement → authority → mechanical /
+design — ranked so the mechanical, oracle-gated wins land first, and
+call out any finding (like the units binding-map case) where the
+"obvious" modernization is actually wrong. If nothing is stale, say so
+plainly: a plugin that already tracks the current contract is a pass,
+not an occasion to invent churn.
+
+## Next step
+
+Re-run `rigor skill describe` for the next move, or `rigor-plugin-author`
+if the review surfaced a *new* capability the plugin should grow.

data/skills/rigor-plugin-review/references/01-best-practices-checklist.md

@@ -0,0 +1,214 @@
+# Plugin best-practices checklist
+
+Score a plugin concern by concern. Each row is **smell → modern
+replacement → authority**. The authority column names the binding
+surface (`docs/internal-spec/*` or the ADR); when it disagrees with
+this file, it wins.
+
+`M` = mechanical (byte-identical diagnostics expected; oracle-gated).
+`D` = design-level (may change behaviour; validate empirically).
+
+---
+
+## 1. Manifest & config defaults (ADR-40) — `M`
+
+**Smell:**
+
+```ruby
+DEFAULT_ROUTES_FILE = "config/routes.yml"
+config_schema: { "routes_file" => :string }
+# …
+@routes_file = config.fetch("routes_file", DEFAULT_ROUTES_FILE)
+```
+
+**Modern:**
+
+```ruby
+config_schema: { "routes_file" => { kind: :string, default: "config/routes.yml" } }
+# …
+@routes_file = config["routes_file"]   # default merged under user config
+```
+
+`Base#config` merges `manifest.config_defaults` beneath the user config,
+so the plugin reads the key directly and the `DEFAULT_*` constant goes
+away. Keep a constant only where a value needs *validation the merged
+default cannot express* (e.g. an allow-listed `severity` that must fall
+back when a user supplies a bad value).
+
+**Authority:** `docs/internal-spec/plugin.md` § "Declared config
+defaults — `config_schema` `{ kind:, default: }`".
+
+---
+
+## 2. AST-walk ownership (ADR-37 / ADR-52) — `D`
+
+**Smell:** a hand-rolled traversal for per-node checks —
+`root.compact_child_nodes.each { … }`, a bespoke `Walker` that recurses
+the tree, or a `#diagnostics_for_file` that re-walks to find call sites.
+
+**Modern:** declare `node_rule(Prism::CallNode) { |node, scope, path| … }`
+and let the engine own the single per-file walk. For a two-pass
+(collect-then-validate) plugin, add `node_file_context { |root, scope| … }`
+— it runs once before the node rules and threads a file-local value in
+as the rule block's fourth argument.
+
+**Keep `#diagnostics_for_file`** only for genuinely whole-file
+diagnostics a per-node walk cannot express — see concern 5 for the case
+where a stateful whole-file walk is *required*, not lazy.
+
+**"Genuinely whole-file" is a sharp line — apply it, don't defer to
+precedent.** A per-*class* or per-*def* contract check (does this class
+define `#get`? does its body return the contracted type?) IS
+node-expressible — migrate it to `node_rule(Prism::ClassNode)` /
+`node_rule(Prism::DefNode)`, even if a shipped production plugin still
+uses `#diagnostics_for_file` + a hand-rolled `class_nodes` walk for the
+same job (`rigor-hanami`'s ADR-28 check half does — an equivalent,
+older shape, not a reason to keep a new copy hand-rolled). The genuine
+whole-file case is a diagnostic whose *identity or count is not tied to
+any one node* — e.g. `rigor-routes`'s "routes file failed to load"
+warning, which must fire exactly once per file (or run) even on a file
+with zero matching nodes. That cannot be a node rule; a per-class check
+can.
+
+**Authority:** `docs/internal-spec/plugin.md` §§ "Node-scoped rules —
+`node_rule`", "`node_file_context`".
+
+---
+
+## 3. Return-type & narrowing hooks (ADR-37 / ADR-52 / ADR-80) — `M`/`D`
+
+**Smell:** `flow_contribution_for` (deleted in ADR-52 WD3 — *defining it
+now raises `ArgumentError`*), or `type_specifier` (the pre-ADR-80 name).
+
+**Modern:** `dynamic_return(receivers:/methods:/file_methods:)` to
+*supply* a return type, `narrowing_facts(methods:)` to supply
+post-return narrowing facts. `type_specifier` survives as a
+deprecating alias removed in 0.3.0 — rename to `narrowing_facts`.
+
+The gate resolves after `#init` when passed a callable
+(`methods: -> { [@method_name] }`), so config-derived method names work.
+
+**Authority:** `docs/internal-spec/plugin.md` § "Return-type and
+narrowing contributions". `M` for the pure rename; `D` if you are adding
+a contribution the plugin did not have.
+
+---
+
+## 4. Authoring helpers (ADR-37 / ADR-60 WD4) — `M`
+
+The single richest source of drift. Each helper replaces a hand-rolled
+shape and is expected to be diagnostics-preserving.
+
+| Smell | Modern | Authority |
+| --- | --- | --- |
+| `Rigor::Analysis::Diagnostic.new(line:, column: loc.start_column + 1, …)` where a node exists | `#diagnostic(node, path:, message:, severity:, rule:)` (or `location: node.message_loc` for a sub-span) | plugin.md § "Positioning a diagnostic — `#diagnostic`" |
+| `violations.map { |v| diagnostic(node, message: v.message, …) }` | `#diagnostics_for(violations, path:, node:)` — duck-types `#message` / `#node` / `#severity` / `#rule` / `#location` | plugin.md § author helpers (ADR-60 WD4) |
+| A hand-rolled `levenshtein` / `closest_*` "did you mean" | `Rigor::Plugin::Base.suggest(name, candidates)` (`DidYouMean::SpellChecker`) — a **class** method, callable from an `Analyzer` too | plugin.md § "`Base.suggest`" |
+| `@table ||= cache_for(id).call` + a multi-`rescue` ladder + an `@load_error` ivar | `#producer_value(id, params:)` (memoised incl. nil) + `#producer_error(id)` (the rescued exception, for a tailored message) | plugin-cache-producers.md § "Invalidation contract" |
+| `@x_resolved` flag guarding `services.fact_store.read` | `#read_fact(plugin_id:, name:)` — nil-inclusive memo, retires the flag | plugin.md § author helpers (ADR-60 WD4) |
+| Hand-parsing a `Prism::SymbolNode#value` / string literal | `Rigor::Source::Literals` | plugin.md § "Extracting argument literals" |
+| A private reimplementation of a target library (own inflector, own pure helper) | Call the library's safe methods directly — `Plugin::Inflector` over real `ActiveSupport::Inflector` (ADR-39) | plugin.md § "Target-library invocation" |
+
+**Note on tailored load-error messages:** `#producer_value` rescues
+every `StandardError` into `#producer_error`, so a plugin that wants
+class-specific messages ("not found" vs "failed to parse" vs
+access-denied) switches on `producer_error(id)`'s class when building
+the load-error diagnostic — cleaner than an inline rescue ladder and
+still message-preserving. A *file-level* load-error (line 1, no node)
+legitimately keeps a direct `Diagnostic.new` — `#diagnostic` needs a
+node to position at.
+
+---
+
+## 5. Engine collaboration vs reimplementation — `D` (read the trap)
+
+**Principle (rigor-pattern):** do not re-implement a fact the engine
+already computes. If you need "is this a literal string?" / "what type
+did inference give this expression?", read `Scope#type_of(node)` rather
+than tracking it yourself. `rigor-pattern` reads the engine's
+`LiteralStringFolding` result back instead of propagating strings by
+hand.
+
+**The trap (rigor-units) — when a hand-rolled binding map is NOT
+redundant:** the `Scope` handed to the **diagnostics** side
+(`#diagnostics_for_file` / a `node_rule`) is the **seed entry scope**.
+`Scope#type_of` re-evaluates a *self-contained* expression on demand
+(`scope.type_of(100.kilometers)` folds through the plugin's own
+`dynamic_return`), but it carries **no flow-accumulated local
+bindings**: for `speed = distance / time`, `scope.type_of(distance)` is
+`untyped`, because the entry scope never bound the earlier assignment.
+Only the **flow scope** handed to a `dynamic_return` block resolves such
+locals. So a diagnostics-side check that must follow a dimension /
+type across statements legitimately keeps its own single-pass binding
+map — deleting it and reaching for `scope.type_of` collapses
+cross-statement propagation.
+
+**How to tell which case you are in:** if the value you need lives *at
+the call site you are inspecting* (a literal argument, a self-contained
+sub-expression) → read `Scope#type_of`. If it lives *in an earlier
+statement's local binding* and you are on the diagnostics side → the
+engine will not hand it to you; keep the binding map, and document why.
+**Validate empirically before deleting state:** run the integration
+spec after the change; a wave of failures on multi-statement fixtures is
+this trap.
+
+**Authority:** the reasoning is recorded in
+`docs/notes/20260704-examples-plugin-modernization-survey.md` (the
+`rigor-units` section) and the `rigor-units` class comment itself.
+
+---
+
+## 6. Cache producers (ADR-60 WD3) — `M`/`D`
+
+**Smell:** a "prime the read before `cache_for` so the digest is
+captured" comment, or a producer that globs a directory but does not
+declare `watch:`.
+
+**Modern:** record-and-validate — the `io_boundary.read_file` inside the
+`producer` block is captured into the dependency descriptor *after* the
+block runs, so there is nothing to prime. A producer that reads a *set*
+of files by glob declares `watch:` so file *additions* invalidate too.
+
+**Authority:** `docs/internal-spec/plugin-cache-producers.md` §§
+"Invalidation contract", "`producer(... watch:)`".
+
+---
+
+## 7. Manifest-field hygiene (ADR-60 WD1 / WD2) — `M`
+
+**Smell:** `external_files:` (never wired — removed in ADR-60 WD1);
+`BlockAsMethod verbs:` (renamed → `method_names:`); `NestedClassTemplate
+name_arg_position:` (renamed → `symbol_arg_position:`).
+
+**Modern:** drop `external_files:`; use the renamed keys.
+
+**Authority:** `docs/internal-spec/plugin.md` § "`Rigor::Plugin::Manifest`"
+and `macro-substrate.md`.
+
+---
+
+## 8. Documentation freshness — `M`
+
+**Smell:** "the former `flow_contribution_for` hook was removed"
+archaeology in a README / class comment (a reader who never knew the
+deleted hook does not need it named); pinned version references that no
+longer carry meaning ("introduced in v0.0.9").
+
+**Modern:** describe the *current* mechanism directly. Keep a historical
+note only where a reader migrating an old plugin genuinely needs it —
+and put that in a CHANGELOG / migration note, not the class docstring.
+
+---
+
+## 9. Verification (ADR-43) — always
+
+- `rigor check <plugin>/lib` — the ADR-43 contract self-check resolves
+  the plugin's inherited `Plugin::Base` calls and warns on contract
+  misuse. MUST be clean; fix the cause, never disable the rule.
+- `rigor plugins --strict` — the plugin still activates.
+- `rigor plugins --capabilities` — `node_rule_types` /
+  `dynamic_return_receivers` / `type_specifier_methods` reflect the
+  declarations.
+- The integration / unit spec — green, and byte-identical across every
+  mechanical step.
+- In the monorepo: `make check-plugins` + `make verify`.

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

@@ -20,6 +20,21 @@ 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`.
 
+## First: load the version-current copy
+
+This skill's exact commands, flags, and config keys drift between Rigor
+releases, so follow the copy that ships with the **installed** Rigor rather
+than any vendored or frozen copy of this file. Get the complete current
+procedure in one call:
+
+```sh
+rigor skill --full rigor-plugin-tune
+```
+
+If you already loaded this skill *via* `rigor skill` you have the current
+copy — just proceed. If `rigor` is not on `PATH`, this task needs it: run
+**`rigor-next-steps`** to install Rigor first, then come back.
+
 ## When to use
 
 - The project added (or removed) a gem since it was onboarded.
@@ -43,9 +58,13 @@ 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:
+new ones land) comes from the **installed** Rigor itself — read it there,
+not from a web page that may describe a different version:
 
-<https://github.com/rigortype/rigor/blob/master/plugins/README.md>
+```sh
+rigor docs manual/plugins/README   # the catalogue of every bundled plugin, offline
+rigor plugins                      # what is enabled in THIS project right now
+```
 
 For each Gemfile.lock dependency, check whether a bundled `rigor-<gem>`
 plugin exists and is **not** already in `plugins:`. Common matches:

data/skills/rigor-project-init/SKILL.md

@@ -23,6 +23,22 @@ chapter for the install channels (`mise` recommended). This skill
 references only public CLI flags and config keys — the same surface
 `rigor --help` documents.
 
+## First: load the version-current copy
+
+This skill's step detail lives in its `references/` files, and its exact
+commands, flags, and config keys drift between Rigor releases — so follow
+the copy that ships with the **installed** Rigor rather than any vendored
+or frozen copy of this file. Get the complete current procedure (body + all
+references, inline) in one call:
+
+```sh
+rigor skill --full rigor-project-init
+```
+
+If you already loaded this skill *via* `rigor skill` you have the current
+copy — just proceed. If `rigor` is not on `PATH`, this task needs it: run
+**`rigor-next-steps`** to install Rigor first, then come back.
+
 ## Phase 0 — When to use this skill
 
 Trigger when the user says "set up Rigor here", "configure rigor for

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

@@ -16,6 +16,21 @@ 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.
 
+## First: load the version-current copy
+
+This skill's exact commands, flags, carrier syntax, and rule ids drift
+between Rigor releases, so follow the copy that ships with the **installed**
+Rigor rather than any vendored or frozen copy of this file. Get the
+complete current procedure in one call:
+
+```sh
+rigor skill --full rigor-protection-uplift
+```
+
+If you already loaded this skill *via* `rigor skill` you have the current
+copy — just proceed. If `rigor` is not on `PATH`, this task needs it: run
+**`rigor-next-steps`** to install Rigor first, then come back.
+
 ## When to use
 
 - A user wants to raise how much of their code Rigor can actually catch

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

@@ -18,6 +18,21 @@ community RBS collection at
 [`ruby/gem_rbs_collection`](https://github.com/ruby/gem_rbs_collection);
 this skill wires it into the project.
 
+## First: load the version-current copy
+
+This skill's exact commands, flags, and config keys drift between Rigor
+releases, so follow the copy that ships with the **installed** Rigor rather
+than any vendored or frozen copy of this file. Get the complete current
+procedure in one call:
+
+```sh
+rigor skill --full rigor-rbs-setup
+```
+
+If you already loaded this skill *via* `rigor skill` you have the current
+copy — just proceed. If `rigor` is not on `PATH`, this task needs it: run
+**`rigor-next-steps`** to install Rigor first, then come back.
+
 ## When to use
 
 - `rigor check` ends with `info: N gem(s) in Gemfile.lock have no RBS

data/skills/rigor-upgrade/SKILL.md

@@ -17,6 +17,22 @@ 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.
 
+## First: load the version-current copy
+
+This skill's exact commands, flags, and config keys drift between Rigor
+releases, so follow the copy that ships with the **installed** Rigor rather
+than any vendored or frozen copy of this file — doubly so here, since you
+just changed the version this skill is meant to track. Get the complete
+current procedure in one call:
+
+```sh
+rigor skill --full rigor-upgrade
+```
+
+If you already loaded this skill *via* `rigor skill` you have the current
+copy — just proceed. If `rigor` is not on `PATH`, this task needs it: run
+**`rigor-next-steps`** to install Rigor first, then come back.
+
 ## When to use
 
 - You just ran `mise use gem:rigortype` / `gem update rigortype` and want

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification
 name: rigortype
 version: !ruby/object:Gem::Version
-  version: 0.2.6
+  version: 0.2.7
 platform: ruby
 authors:
 - Rigor contributors
 bindir: exe
 cert_chain: []
-date: 1980-01-02 00:00:00.000000000 Z
+date: 1980-01-01 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: language_server-protocol
@@ -886,6 +886,7 @@ files:
 - skills/rigor-baseline-reduce/references/02-fix-or-suppress.md
 - skills/rigor-ci-setup/SKILL.md
 - skills/rigor-doctor/SKILL.md
+- skills/rigor-doctor/references/01-checks.md
 - skills/rigor-editor-setup/SKILL.md
 - skills/rigor-mcp-setup/SKILL.md
 - skills/rigor-monkeypatch-resolve/SKILL.md
@@ -894,6 +895,8 @@ files:
 - skills/rigor-plugin-author/references/01-plan-and-scaffold.md
 - skills/rigor-plugin-author/references/02-walker-and-types.md
 - skills/rigor-plugin-author/references/03-test-and-ship.md
+- skills/rigor-plugin-review/SKILL.md
+- skills/rigor-plugin-review/references/01-best-practices-checklist.md
 - skills/rigor-plugin-tune/SKILL.md
 - skills/rigor-project-init/SKILL.md
 - skills/rigor-project-init/references/01-detect.md
@@ -909,7 +912,7 @@ licenses:
 metadata:
   bug_tracker_uri: https://github.com/rigortype/rigor/issues
   source_code_uri: https://github.com/rigortype/rigor
-  documentation_uri: https://github.com/rigortype/rigor/tree/main/docs
+  documentation_uri: https://github.com/rigortype/rigor/tree/master/docs
   rubygems_mfa_required: 'true'
 rdoc_options: []
 require_paths:
@@ -958,7 +961,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 4.0.10
+rubygems_version: 3.7.2
 specification_version: 4
 summary: Inference-first static analysis for Ruby.
 test_files: []