Rigor Plugin Review

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 (removed in 0.3.0; renamed to 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:

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:

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 — 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 — producer / #cache_for / #producer_value / #producer_error, ADR-60 WD3 record-and-validate.
• 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.