ワンクリックで
flox
Manage Flox packages in the chezmoi dotfiles repository. Use when adding, removing, upgrading, or troubleshooting Flox packages.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Manage Flox packages in the chezmoi dotfiles repository. Use when adding, removing, upgrading, or troubleshooting Flox packages.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Write a terse, decision-oriented design proposal in a project's docs/proposals/ directory. Target 200-350 lines, decisions in tables, status block at top, no over-engineered meta-sections. Use when the user asks to "write a proposal", "propose X", "draft a design doc", "design proposal", or creates a file under any docs/proposals/ folder.
Guide for setting up and managing the release process for Obsidian plugins. Use when adding a release workflow to a new plugin, debugging release issues, or understanding the standardized Makefile/version-bump/GitHub Actions pattern used across ssoriche's Obsidian plugin repos.
| name | flox |
| description | Manage Flox packages in the chezmoi dotfiles repository. Use when adding, removing, upgrading, or troubleshooting Flox packages. |
| argument-hint | <action> [package] |
| disable-model-invocation | true |
The Flox manifest and lockfile live in the chezmoi source directory:
Source: ~/.local/share/chezmoi/dot_flox/env/manifest.toml
~/.local/share/chezmoi/dot_flox/env/private_manifest.lock
Deploy: ~/.flox/env/manifest.toml
~/.flox/env/manifest.lock
Always edit the chezmoi source manifest, then apply. Never edit ~/.flox/env/manifest.toml directly — chezmoi will overwrite it.
The lockfile is tracked in chezmoi so that exact resolved versions are preserved across machines. After any flox upgrade, copy the updated lockfile back into chezmoi:
chezmoi add ~/.flox/env/manifest.lock
Packages are organized into pkg-groups so they can resolve against independent nixpkgs revisions. This prevents slow-moving or large packages from blocking upgrades of fast-moving ones.
| Group | Contents | When to use |
|---|---|---|
toplevel (default) | Stable CLI tools (ripgrep, fd, bat, jq, etc.) | No pkg-group needed — this is the implicit default |
vcs | git, gh, tig, delta, difftastic, git-absorb, git-credential-manager, jujutsu, gitu, gh-dash | Git ecosystem tools that should share a revision |
editors | neovim, lua-language-server, tree-sitter | Editor + language server ABI compatibility |
golang | go, golangci-lint | Linter must match Go version |
node | nodejs, bun | JS runtimes |
lua | luarocks, lua | Lua ecosystem |
python | uv | Standalone; updates frequently |
linters | typos, dotenv-linter | Standalone linters |
cloud | awscli2 | Large package, independent update cadence |
pinned | granted | Version-pinned packages |
claude | claude-code (flox/claude-code) | Fast-moving, unfree; sourced from the flox catalog (see Catalogs below) |
opencode | opencode | Fast-moving AI tooling; needs independent upgrades |
gui | aerospace, wezterm, obsidian, halloy | GUI apps — keep separate from CLI tools |
Create a new group when:
Flox resolves packages from catalogs. Which one a package comes from is determined by its pkg-path:
pkg-path like "claude-code" or "ripgrep" resolves from nixpkgs.flox/ (e.g. "flox/claude-code") resolves from the flox catalog, curated by Flox. It often tracks fast-moving upstream tools ahead of nixpkgs.flox search <pkg> lists both variants when they exist:
$ flox search claude-code
claude-code Agentic coding tool that lives in your terminal... # nixpkgs
flox/claude-code Agentic coding tool from Anthropic # flox catalog
Compare their latest versions before choosing a source:
flox show claude-code # Catalog: nixpkgs → Latest: 2.1.193
flox show flox/claude-code # Catalog: flox → Latest: 2.1.196
To switch a package's source, change only its pkg-path (the install id / attribute name stays the same), then apply and re-lock:
claude-code = { pkg-path = "flox/claude-code", pkg-group = "claude" }
chezmoi apply ~/.flox/env/manifest.toml
flox activate -- claude --version # fresh activation re-locks; confirm the new version
chezmoi add ~/.flox/env/manifest.lock
claude-code is sourced from the flox catalog for exactly this reason — it stays current faster than nixpkgs.
The manifest uses a hybrid style:
# toplevel — dot notation
ripgrep.pkg-path = "ripgrep"
# grouped — inline table
git = { pkg-path = "git", pkg-group = "vcs" }
go = { pkg-path = "go", version = "1.25", pkg-group = "golang" }
# Toplevel (no group needed) — dot notation
mypackage.pkg-path = "mypackage"
# Grouped — inline table
mypackage = { pkg-path = "mypackage", pkg-group = "appropriate-group" }
Then apply and install:
chezmoi apply ~/.flox/env/manifest.toml
flox install mypackage # or just let flox resolve on next activation
dot_flox/env/manifest.tomlchezmoi apply ~/.flox/env/manifest.tomlflox uninstall mypackageAlways dry-run first — flox may propose downgrades if a group resolves to an older nixpkgs revision:
flox upgrade --dry-run # check ALL groups for downgrades
flox upgrade --dry-run git # check a specific group
If the dry-run looks good, apply:
flox upgrade git # upgrade a specific group
flox upgrade claude-code # single package (only if not grouped with others)
After upgrading, always sync the lockfile back to chezmoi:
chezmoi add ~/.flox/env/manifest.lock
Avoid flox upgrade with no arguments unless you've verified the dry-run shows no downgrades. Prefer upgrading groups individually.
mypackage = { pkg-path = "mypackage", version = "1.2.3", pkg-group = "pinned" }
flox search <query>
flox show <package> # detailed info including available versions
flox list # all installed packages with versions
flox list -c # show config (groups, options)
~/.local/share/chezmoi/dot_flox/env/manifest.tomlchezmoi apply ~/.flox/env/manifest.tomlflox listchezmoi add ~/.flox/env/manifest.lockFlox uses a single lockfile for all packages. When making multiple changes (e.g., adding a package AND upgrading a group), perform each operation as a separate cycle:
flox upgrade editors)This keeps each commit's lockfile diff attributable to that commit's manifest or upgrade change. Batching multiple operations before syncing the lockfile produces a single diff that conflates unrelated changes.
flox upgrade proposes downgradesThis happens when a group (especially toplevel) resolves to a different nixpkgs revision than what's in the lockfile. Splitting packages into groups changes which revision each group lands on — fewer constraints means flox has more freedom to pick a revision, and it may pick an older one.
Prevention: Always flox upgrade --dry-run first. The lockfile preserves the current good versions.
Fix if it happens: Restore the lockfile from chezmoi:
chezmoi apply ~/.flox/env/manifest.lock
flox upgrade doesn't pick up a new versionThis usually means the package shares a nixpkgs revision with other packages (the toplevel group) and that revision doesn't have the newer version yet.
Fix: Move the package to its own pkg-group so it resolves independently:
mypackage = { pkg-path = "mypackage", pkg-group = "mypackage" } # isolate into own group
Then: chezmoi apply ~/.flox/env/manifest.toml && flox upgrade mypackage
A group may fail to resolve if packages within it have conflicting version requirements.
Fix: Split the conflicting package into its own group, or relax version constraints.
flox search <name> # verify exact package name
flox show <name> # check if it exists in the catalog
Some packages use different names in nixpkgs (e.g., _1password-cli not 1password-cli).
Packages pinned to specific git commits or repos use flake instead of pkg-path:
mypackage.flake = "github:owner/repo/ref#output"
These bypass pkg-groups entirely — each flake resolves independently.