pkg⋅mgr²
Install Packs
A pack is a useful set of packages, installable from one link and still managed by the package managers you already use.
Installing a developer machine is usually a pile of tribal knowledge: a gist, a dotfiles script, a README, a copied terminal transcript. Install Packs turn that into a link.
A pack is not a new package manager. It is just a shortlist of package identifiers. pkg⋅mgr² opens the link, matches the packages it knows about, shows a confirmation, and asks the native managers to install the missing pieces.
26 media, runtime, search, build, OCR, metadata, and document-conversion tools for agent workflows.
10 terminal-native agent CLIs, coding assistants, model routers, and usage inspection tools.
23 modern shell tools for search, previewing, navigation, process monitoring, data work, HTTP, and DNS.
One click
The app accepts repeated package query parameters, so a pack can live in any blog post, README, docs page, or internal setup guide.
To make your own pack, build a URL that starts with pkgmgrmgr://install and add one URL-encoded package value per package:
pkgmgrmgr://install?package=brew%3Aripgrep&package=brew%3Afd&package=brew%3Abat
Package identifiers use the same prefixes pkg⋅mgr² stores internally: brew:bat, brew:cask:codex, npm:typescript, npx:create-vite, cargo:ripgrep, uv:tool:ruff, and uvx:ruff. Colons must be URL-encoded as %3A inside query values.
For a single package, link directly to its manager path instead: pkgmgrmgr://brew/bat, pkgmgrmgr://brew/cask/codex, pkgmgrmgr://npm/typescript, or pkgmgrmgr://cargo/ripgrep.
Public pack posts are listed from blog/index.json with category pack. Each entry needs a slug, title, subtitle, SF Symbol name, published date, and URL. The package list still lives in the pkgmgrmgr://install link inside the post.