New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Rigor Dependency Update

by rigortype in rigortype/rigor

Update Rigor's bundled gems and/or Nix Flake development environment while preserving version constraints.

MPL-2.0Auto-check passedDevelopment

Install Rigor Dependency Update

skills CLI
$ npx skills add rigortype/rigor --skill rigor-dependency-update -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rigortype/rigor rigor-dependency-update --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rigortype/rigor.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/rigor-dependency-update .claude/skills/rigor-dependency-update && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
rigor-dependency-update
GitHub stars
106
Token cost
~2k tokens
SKILL.md length
1,011 words
Files
1
Skills in repo
36
Repo updated
First seen
Licence
MPL-2.0

At a glance

Update Rigor's bundled gems and/or Nix Flake development environment while preserving version constraints.

  • Works in 2 steps: Bundled gems — Gemfile.lock. The… → Nix Flake dev environment — flake.lock.…
  • Nixpkgs updates
  • SKILL.md covers Layer 1 — bundled gems (bundle…, Layer 2 — Nix Flake dev…, The nixpkgs-bump… and Order of operations, plus 5 more sections
  • Calls bundle, nix and git

What it does

Rigor Dependency Update is an agent skill from rigortype/rigor. Update Rigor's bundled gems and/or Nix Flake development environment while preserving version constraints. Use for dependency, Gemfile.lock, flake.lock, or nixpkgs updates; not for Ruby-version bumps or references/ submodule updates.

Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Dependency management. It works with Ruby. The repository describes itself as: Inference-first static analysis for Ruby. The licence is MPL-2.0.

When your agent uses it

  • Nixpkgs updates
  • Not for Ruby-version bumps
  • References/ submodule updates

Example prompts

  • “/rigor-dependency-update”

Workflow steps

2 steps, taken from the first numbered list in SKILL.md.

  1. Bundled gems — Gemfile.lock. The runtime-affecting layer
  2. Nix Flake dev environment — flake.lock. The development

What it can do on your machine

Read from SKILL.md and the folder at commit 57a67cf. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • bundle
    • nix
    • git
    • make
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Rigor Dependency Update loads about 2k tokens when it runs. Until then it costs about 66 tokens; SKILL.md has 1,011 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~66
When it runs · the whole SKILL.md, loaded when a task matches
~2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from rigortype/rigor at commit 57a67cf, republished under its MPL-2.0 licence (© rigortype). 1,011 words, ~1,963 tokens.

Download SKILL.mdSave it as .claude/skills/rigor-dependency-update/SKILL.md (or your agent's skills folder).
name
rigor-dependency-update
description
Update Rigor's bundled gems and/or Nix Flake development environment while preserving version constraints. Use for dependency, `Gemfile.lock`, `flake.lock`, or nixpkgs updates; not for Ruby-version bumps or `references/` submodule updates.
metadata.internal
true

Update dependencies (two layers)

The project's dependencies live in two independent layers, and the first job is to keep them separate — a single "update the deps" request usually means both, but they are different kinds of change and belong in different commits so history stays legible.

  1. Bundled gems — Gemfile.lock. The runtime-affecting layer: the analyzer's own dependencies (prism, rbs, language_server-protocol) plus dev tooling (rubocop, rspec, binpacker, …). Managed with bundle update.
  2. Nix Flake dev environment — flake.lock. The development layer: the pinned nixpkgs-unstable revision that provisions the dev shell (make, git base, bundix, the Ruby build inputs). Managed with nix flake update.

Do both by default, but each layer is a self-contained commit, so doing one alone is fine. Work on a branch and open one PR carrying both commits (the public-dev workflow — grouped changes go through a PR, not a direct push to master).

Use bundle / nix commands; never hand-edit a lockfile.

Layer 1 — bundled gems (bundle update)

See what is available first, then update within the existing gemspec constraints:

sh
nix develop --command bundle outdated
nix develop --command bundle update

bundle update re-resolves every gem to the latest version the gemspec's existing ranges allow. This is a lockfile refresh only — git diff Gemfile.lock should show version bumps and nothing structural.

Two judgment calls the resolver makes for you, worth confirming:

  • A held-back major is not a blocker to chase. If bundle outdated lists a new major (e.g. diff-lcs 2.0) but bundle update keeps the old one, a transitive constraint is capping it (rspec pins diff-lcs < 2.0). That is correct — leave it. Pulling a major that the gemspec ranges forbid would require a gemspec range change, which is a deliberate decision outside this skill (edit the gemspec via bundle add, verify the new major, land it on its own).

Commit subject: Update bundled gems to their latest in-range versions. Body: list the bumps, note no range change, note any major deliberately held by a transitive cap.

Layer 2 — Nix Flake dev environment (nix flake update)

sh
nix flake update

This bumps the single nixpkgs input to the latest nixpkgs-unstable and rewrites only flake.lock. flake.nix is untouched.

The deliberate in-flake pins stay — they are hardcoded in flake.nix for a reason and each has its own change path, so a dev-environment refresh must not move them:

  • Ruby (mkRuby, currently 4.0.5) — bump via rigor-ruby-version-bump, not here.
  • git (the 2.54.0 overrideAttrs) — an explicit override; bump individually with a fresh source hash if needed.
  • waza (the pinned release binary + per-platform hashes) — bump individually (new version + four fetchurl hashes) if a newer waza release is wanted.

Commit subject: Update the Nix Flake dev environment to the latest nixpkgs. Body: note the old → new nixpkgs date, that only flake.lock moved, and that the in-flake pins were intentionally left.

The nixpkgs-bump native-extension rebuild (do this, or verify fails)

A nixpkgs bump rebuilds the Ruby derivation to a new /nix/store path even when the Ruby version is unchanged (the stdenv/build inputs moved). The gems already compiled into vendor/bundle are linked against the old libruby, so the next bundle exec dies with, e.g.:

json-2.20.0/lib/json/ext/parser.bundle:
  linked to incompatible /nix/store/<old>-ruby-4.0.5/lib/libruby-4.0.5.dylib (LoadError)

Rebuild the native extensions against the new Ruby before verifying:

sh
rm -rf vendor/bundle
nix develop --command bundle install     # recompiles native ext against the new Ruby

vendor/bundle is gitignored — this is a purely local artifact of the rebuild, so nothing about it is committed, and CI (which installs fresh each run) never hits this. It only blocks your local make verify, so clear it whenever a Flake update leaves bundle exec complaining about an incompatible libruby.

Order of operations

The rebuild dependency makes the order matter when both layers move:

  1. Layer 1: bundle update, review, commit.
  2. Layer 2: nix flake update, commit.
  3. After the Flake update, rm -rf vendor/bundle && bundle install (rebuild native ext against the freshly-rebuilt Ruby).
  4. make verify — must run after step 3, or the stale extensions fail it.
Show full SKILL.md (394 more words)Show less

Verify

sh
nix develop --command make verify
nix develop --command git diff --check

make verify (test + lint + check + check-plugins) must be green under the new toolchain and freshly-compiled gems — it is the proof both layers are healthy together. Only Gemfile.lock and flake.lock should be in git status (vendor/bundle stays untracked).

Record the perf-gate shift

A Gemfile.lock bump can move the release gate's allocation number with no engine change: the rbs gem supplies the core RBS the engine loads, and the per-PR "Engine allocations" job cannot see it, because both of its arms run on one bundle. Measure before and after the update, on the base commit and on the branch, with nix develop --command make bench-perf or by dispatching the release gate on each (gh workflow run release-gate.yml --ref <branch>). Put both allocation numbers and the delta in the PR body: a release cut attributes its rise from these records (bench/README.md, "Over a release cycle"). A Flake-only update moves the local Ruby but not CI's, so a local pair is enough for it.

Push and open the PR

sh
git push origin HEAD:refs/heads/<branch>
gh pr create --draft --base master --title "Update dependencies: bundled gems + Nix Flake dev environment" \
  --body "<the two commits, per-layer>"

The PR's ci.yml gate re-runs the full suite on a clean checkout (its own bundle install), which is the authoritative cross-environment check. The PR is created --draft and goes Ready (gh pr ready <pr>) only on the user's explicit instruction to land it, with CI green and no stop instruction standing (this skill's own landing rule, which docs/agents/contribution-flow.md § "Landing a pull request" defers to — a GitHub APPROVE cannot exist on a one-developer repository, so it is not the trigger).

Stays untouched (out of scope here)

  • The gemspec version ranges — a constraint change (admitting a new major) is a deliberate decision, done via bundle add and verified on its own, not folded into a lockfile refresh.
  • The Ruby version — rigor-ruby-version-bump.
  • references/ submodules — rigor-add-reference.
  • The in-flake git / waza pins — explicit overrides, bumped individually with fresh hashes.

Quick checklist

  • Branch cut; one PR carrying one commit per layer.
  • bundle update (not a hand-edit); git diff Gemfile.lock is version-only; no gemspec range change; held-back majors left alone.
  • nix flake update; only flake.lock moved; Ruby / git / waza in-flake pins untouched.
  • rm -rf vendor/bundle && bundle install after the Flake update.
  • make verify green under the new toolchain; git diff --check clean.
  • Perf-gate allocations before and after the update are in the PR body.
  • Two commits: Update bundled gems to their latest in-range versions and Update the Nix Flake dev environment to the latest nixpkgs.

© rigortype, MPL-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/rigor-dependency-update of rigortype/rigor.

Open the folder on GitHubat commit 57a67cf

Compare with similar skills

Rigor Dependency Update next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Rigor Dependency Update compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Rigor Dependency Update this skillrigortype/rigor106—~2kAutomated safety check: PassMPL-2.0
Dependency UpdaterAsvarox/allkaraoke2614 repos~3.5kAutomated safety check: PassMIT
Breaking Change Analysisruby-git/ruby-git1.8k—~1.7kAutomated safety check: PassMIT
Dep Auditorlaolaoshiren/claude-code-skills-zh878—~895Automated safety check: PassMIT
Gem Dependency Managementruby-git/ruby-git1.8k—~806Automated safety check: PassMIT
Dependency Update BotVarnan-Tech/opendirectory674—~3kAutomated safety check: NotesMIT

Similar skills

  • Dependency Updater

    Asvarox/allkaraoke

    Smart dependency management for any language. An agent skill from Asvarox/allkaraoke.

    261 GitHub starsUsed in 4 repos~3.5k tokens
    DevelopmentAuto-check passed

  • Breaking Change Analysis

    ruby-git/ruby-git

    Assesses what an API change would break before it is made, finds every usage, documents the impact and plans a deprecation or migration path.

    1.8k GitHub stars~1.7k tokensUpdated 7 days ago
    DevelopmentAuto-check passed

  • Dep Auditor

    laolaoshiren/claude-code-skills-zh

    审计 Node.js、Python、Go、Rust、JVM、Ruby 项目的依赖漏洞、版本健康度与许可证事实；当用户要求检查 package.json、lockfile、requirements、go.mod、Cargo.toml、pom.xml、Gemfile.lock，或生成不改依赖的中文审计报告时使用

    878 GitHub stars~895 tokensUpdated 3 days ago
    DevelopmentAuto-check passed

  • Gem Dependency Management

    ruby-git/ruby-git

    Workflow for updating gem dependencies and fixing CVEs in the ruby-git project: assess with bundle outdated and audit, edit the gemspec, test, then commit with conventional messages.

    1.8k GitHub stars~806 tokensUpdated 7 days ago
    DevelopmentAuto-check passed

  • Dependency Update Bot

    Varnan-Tech/opendirectory

    Scans your project for outdated npm, pip, Cargo, Go, or Ruby packages.

    674 GitHub stars~3k tokensUpdated 1 mo ago
    DevelopmentAuto-check: notes

  • Update Dependencies

    sesori-ai/sesori_apps_monorepo

    Weekly dependency update workflow for Sesori Apps Monorepo. An agent skill from sesori-ai/sesori_apps_monorepo.

    126 GitHub stars~7.8k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from rigortype/rigor

All 36 skills in this repo

  • Rigor Regression Sweep

    rigortype/rigor

    Measure Rigor's baseline drift across the tagged history of a real OSS Ruby project.

    106 GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed

  • Rigor Unused Adjudicate

    rigortype/rigor

    Adjudicate a rigor unused report safely before proposing dead-code removal.

    106 GitHub stars~1.1k tokensUpdated yesterday
    Auto-check passed

  • Rigor Baseline Reduce

    rigortype/rigor

    Reduce an existing .rigor-baseline.yml rule by rule by triaging sites, fixing or intentionally suppressing them, and regenerating the baseline.

    106 GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed

  • Rigor Doctor

    rigortype/rigor

    Validate that a project's Rigor configuration, plugins, paths, and baseline are actually healthy.

    106 GitHub stars~767 tokensUpdated yesterday
    Auto-check passed

  • Rigor Plugin Author

    rigortype/rigor

    Author a new Rigor plugin, choosing plugins/ for production support or examples/ for a contract walkthrough.

    106 GitHub stars~3.3k tokensUpdated yesterday
    Auto-check: notes

  • Rigor Plugin Author

    rigortype/rigor

    Author a Rigor plugin in an adopting project or standalone rigor- gem for a DSL, framework, or metaprogramming pattern.

    106 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Rigor Dependency Update

What does Rigor Dependency Update do?

Update Rigor's bundled gems and/or Nix Flake development environment while preserving version constraints. Rigor Dependency Update is an agent skill from rigortype/rigor. Update Rigor's bundled gems and/or Nix Flake development environment while preserving version constraints.

When should I use Rigor Dependency Update?

Rigor Dependency Update fits situations like: nixpkgs updates; not for Ruby-version bumps; references/ submodule updates.

How do I install Rigor Dependency Update in Claude Code?

Run `npx skills add rigortype/rigor --skill rigor-dependency-update -a claude-code`. Or copy the skill folder (.claude/skills/rigor-dependency-update in rigortype/rigor) into .claude/skills/rigor-dependency-update in your project. Claude Code loads it when a task matches its description.

How do I install Rigor Dependency Update in Codex?

Run `npx skills add rigortype/rigor --skill rigor-dependency-update -a codex`. Or copy the skill folder (.claude/skills/rigor-dependency-update in rigortype/rigor) into .agents/skills/rigor-dependency-update in your project. Codex loads it when a task matches its description.

Can I use Rigor Dependency Update in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rigortype/rigor --skill rigor-dependency-update -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/rigor-dependency-update, .gemini/skills/rigor-dependency-update, .github/skills/rigor-dependency-update and .opencode/skills/rigor-dependency-update in your project.

What does Rigor Dependency Update need to run?

Going by SKILL.md and its folder, Rigor Dependency Update needs the command-line tools its instructions call (bundle, nix, git, make and gh).

Does Rigor Dependency Update access the network?

SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Rigor Dependency Update safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Rigor Dependency Update use?

Rigor Dependency Update is published under the MPL-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Rigor Dependency Update use?

About 2k tokens (SKILL.md is roughly 7.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Rigor Dependency Update?

Skills that share tags, products or a category with Rigor Dependency Update: Dependency Updater (Asvarox/allkaraoke, 261 stars), Breaking Change Analysis (ruby-git/ruby-git, 1.8k stars), Dep Auditor (laolaoshiren/claude-code-skills-zh, 878 stars) and Gem Dependency Management (ruby-git/ruby-git, 1.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Rigor Dependency Update?

rigortype (a GitHub organization) maintains it in rigortype/rigor, which has 106 GitHub stars. The repository holds 36 skills in this directory. The repository was last updated on October 8, 2026.

Source: rigortype/rigor on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.