Wire Rigor type-checking into a project's CI pipeline: run it in its own isolated Ruby-4.0 job and surface diagnostics inline on the pull / merge request via a CI-native output format (SARIF, GitHub Actions annotations, GitLab Code Quality, Checkstyle, JUnit) or through reviewdog. Triggers: "add Rigor to CI", "run rigor in GitHub Actions / GitLab CI", "show Rigor errors on the PR", "set up reviewdog for rigor". NOT for first-time project configuration (use rigor-project-init to create `.rigor.yml` first) or reducing a baseline (use rigor-baseline-reduce).
Prepare a rigor RubyGems release by bumping the gem version, updating the changelog, and running release verification commands. Use when the user asks to prepare the next version, cut a release, refresh release metadata, or make sure versioned files are consistent before tagging.
Import Ruby built-in method types from the CRuby checkout into Rigor's runtime catalogues. Use when adding a core / stdlib class to the constant-fold dispatcher, extending per-class catalog coverage (Hash, Range, Set, Pathname, Time, Enumerable, …), regenerating the YAML catalogues, or onboarding a refinement carrier via `RBS::Extended`. Captures the nine-stage flow and its non-mechanical decision points.
Author a new Rigor plugin end-to-end: decide `plugins/` (production) vs `examples/` (tutorial), then run requirements → template → scaffold → demo → spec → verify. Triggers: "Create a Rigor plugin for X", "Extend Rigor for our DSL", "Plugin similar to rigor-units for currency". NOT for edits to existing plugins or analyser-engine work in `lib/rigor/`.
Run a multi-version baseline-drift regression sweep of Rigor against a real OSS Ruby project — baseline at one tag, then `rigor check` every later tag against that frozen baseline + frozen config, and tabulate how the surfaced-diagnostic ("error increase") count evolves. Use to validate how realistic Rigor's diagnostics and the `rigor-project-init` workflow are over a normal development flow, and to grow an empirical multi-project corpus. Triggers: "sweep Rigor across versions of X", "check error increase over a release line", "validate the baseline against real churn", "regression-sweep this project".
Add a new git submodule under references/ for vendored upstream source, and the reference for everything else about references/. Use when the user asks to "vendor X as a reference", "add a submodule under references/", or when a new ADR / feature needs a reference checkout — the three-file change (.gitmodules, Makefile's REFERENCE_SUBMODULES + init-submodules, the submodule pointer) committed together. ALSO use when asking what a given references/ tree is for, or when a submodule misbehaves: an empty checkout after cloning, `git status` failing, a parent `git reset` aborting on a submodule, a stale .git/config section after a rename, or a `submodule.c` BUG assertion.
Author a new Architecture Decision Record under docs/adr/. Use when the user asks to "write an ADR", "record this decision as an ADR", "add ADR-N for X", or when a design discussion reaches a decision worth recording. Covers the quality bar (defers to ADR-49's rubric — archetype, stakes, eight axes) and the mechanical wiring (next number, the file, the docs/adr/README.md index row in ascending order with its capped status, whether the ADR earns a CLAUDE.md premise line at all — usually not — and verification). NOT for editing the type spec or internal-spec corpus, and NOT a substitute for reading ADR-49 — this skill is the procedure; ADR-49 is the binding quality contract.
Search Rigor's own research corpus — docs/adr, docs/notes, docs/design, CHANGELOG.md + docs/CHANGELOG-0.1.x.md, handbook/manual — for prior evaluations, surveys, measurements, comparisons, and decisions, and report them with citation-grade file:line evidence. Use whenever the user asks "have we evaluated / measured / compared X before?", "過去に調査・評価した ことある?", "既存のノート/ADRから探して", "what do our docs say about X", or needs primary-source backing for a talk, blog post, ADR, or README claim — especially comparisons against other tools (Steep, Sorbet, TypeProf, rbs_rails, Tapioca, PHPStan, …). Also use before publishing any comparative claim about Rigor, to check what the corpus actually supports. NOT for a single fact in a file you already know (just rg/Read it directly).