> ## Documentation Index > Fetch the complete documentation index at: https://docs.packmind.com/llms.txt > Use this file to discover all available pages before exploring further. # CLI: Command-Line Interface ## Overview **The command is `packmind`** — The older `packmind-cli` name still works, but it is deprecated and will be removed in a future release. Update any scripts, aliases, or CI jobs that still call `packmind-cli`. The Packmind CLI provides the following commands: * **`init`** - Initialize Packmind in your project (configure agents + install skills) * **`git track`** - Set the repository and branch Packmind tracks for your project (`--branch` to name it explicitly) * **`git untrack`** - Remove Packmind's tracking of the current repository * **`git info`** - Show whether Packmind tracks the current repository, and on which branch * **`config agents setup`** - Configure which AI coding agents to generate artifacts for (interactive) * **`config agents list`** - List configured agents across `packmind.json` files * **`config agents add`** - Add coding agents to `packmind.json` files * **`config agents rm`** - Remove coding agents from `packmind.json` files * **`login`** - Authenticate with your Packmind instance * **`logout`** - Clear stored credentials * **`whoami`** - Show current authentication status * **`install`** - Download packages locally * **`uninstall`** - Remove packages from your project * **`distribution record`** - Send your local `packmind-lock.json` files to Packmind as what each target runs * **`lint`** - Run detection programs (Enterprise only) * **`playbook diff`** - Show differences between local files and Packmind artefacts * **`playbook add`** - Stage a change between local files and Packmind artefacts * **`playbook submit`** - Submit local changes to Packmind * **`skills init`** - Install default Packmind skills locally * **`skills list`** - List all skills in your organization * **`standards list`** - List all standards in your organization * **`commands list`** - List all commands in your organization * **`spaces list`** - List all spaces in your organization * **`packages create`** - Create a new package * **`packages add`** - Add standards, commands, or skills to a package * **`packages move`** - Move standards, commands, or skills into a package, removing them from every other one * **`packages remove`** - Remove standards, commands, or skills from a package * **`packages list`** - List all packages in your organization * **`plugins render`** - Render a Packmind package as a Claude Code or GitHub Copilot plugin * **`plugins delete`** - Delete a rendered Claude Code or GitHub Copilot plugin from this workspace * **`update`** - Update the CLI to the latest version ## Installation ### One-click install (Recommended) The easiest way to install and configure the Packmind CLI is using the one-click install available in the Packmind web interface. **Where to find it:** * During your first onboarding after creating an account * Anytime in your **Account Settings** page **What it does:** 1. Downloads and installs the Packmind CLI binary for your platform 2. Authenticates you automatically with your Packmind account 3. Sets up your PATH environment variable Simply copy the provided command and paste it into your terminal. The script handles everything automatically. **Why this is recommended** — The one-click install eliminates manual steps by combining installation and authentication in a single command. ### Alternative: npm Package **Node.js 22 or higher required**. **Global Installation**: ```bash theme={null} npm install -g @packmind/cli ``` After installation, the `packmind` command will be available globally. **npx** (no installation required): ```bash theme={null} npx @packmind/cli login ``` This runs the CLI directly without installing it, always using the latest version. ### Alternative: Homebrew Available on macOS and Linux. ```bash theme={null} brew tap PackmindHub/cli brew install packmind-cli ``` The Homebrew formula is still named `packmind-cli`, and it installs the executable under that name. If `packmind` is not found after a Homebrew install, use `packmind-cli`. ### Alternative: Standalone Executables Download the appropriate pre-built executable for your platform from the [GitHub Releases page](https://github.com/PackmindHub/packmind/releases?q=CLI\&expanded=true). **Available platforms:** * **Linux x64**: `packmind-cli-linux-x64-{version}` * **Linux arm64**: `packmind-cli-linux-arm64-{version}` * **macOS arm64**: `packmind-cli-macos-arm64-{version}` (signed and notarized) * **Windows x64**: `packmind-cli-windows-x64-{version}.exe` **For Linux/macOS**, make the executable runnable: ```bash theme={null} chmod +x packmind-cli-*-{version} ``` **Optional**: Move to a directory in your PATH for easy access: ```bash theme={null} # Linux/macOS sudo mv packmind-cli-*-{version} /usr/local/bin/packmind # Windows: Move to a directory in your PATH or run directly ``` **Choosing an Installation Method** — Use **one-click install** for the simplest experience with automatic authentication. Use **npm global** if you want `packmind` always available system-wide. Use **npx** for project-specific usage or testing without installation. Use **Homebrew** if you prefer managing packages through your system package manager (macOS/Linux). Use **standalone executables** if you don't have Node.js installed or need a specific binary for your environment. ## Authentication The CLI requires authentication to communicate with your Packmind instance. ### Login Command (Recommended) The easiest way to authenticate is using the `login` command: ```bash theme={null} packmind login ``` This will: 1. Open your browser to the Packmind login page 2. After you authenticate, automatically receive credentials 3. Store credentials securely in `~/.packmind/credentials.json` **For self-hosted instances**, specify your host: ```bash theme={null} packmind login --host https://your-packmind-instance.com ``` **Manual code entry** (if browser flow doesn't work): You can also enter a login code manually from the web interface: ```bash theme={null} packmind login --code YOUR_CODE_HERE ``` ### Logout Command To clear stored credentials: ```bash theme={null} packmind logout ``` This removes the credentials file. If you also have `PACKMIND_API_KEY` set as an environment variable, you'll need to unset it separately: ```bash theme={null} unset PACKMIND_API_KEY ``` ### Whoami Command Check your current authentication status: ```bash theme={null} packmind whoami ``` This displays: * Connected host * Organization name * User name * Credential expiration status * Where your credentials come from (environment variable or credentials file) ### API Key Authentication (PACKMIND\_API\_KEY) You can authenticate using the `PACKMIND_API_KEY` environment variable instead of the interactive login flow. This is the recommended approach for: * **CI/CD pipelines** — Automated environments where interactive login isn't possible * **Docker containers** — Pass the API key as an environment variable * **Scripted workflows** — When you need non-interactive authentication #### Getting Your API Key 1. Log in to your Packmind instance (Cloud or self-hosted) 2. Navigate to **Settings** (click your profile icon in the top right) 3. Scroll to the **CLI Authentication** section 4. Go to the **Environment Variable** tab 5. Click **Generate New Key** to create an API key (valid for 90 days) 6. Copy the generated key #### Setting the Environment Variable Set the `PACKMIND_API_KEY` environment variable with your API key: ```bash theme={null} export PACKMIND_API_KEY="your-api-key-here" ``` To make this permanent, add it to your shell configuration file (`~/.bashrc`, `~/.zshrc`, etc.): ```bash theme={null} echo 'export PACKMIND_API_KEY="your-api-key-here"' >> ~/.zshrc source ~/.zshrc ``` #### CI/CD Example (GitHub Actions) ```yaml theme={null} - name: Install Packmind packages env: PACKMIND_API_KEY: ${{ secrets.PACKMIND_API_KEY }} run: packmind install ``` **Credential Priority** — When both a credentials file and the `PACKMIND_API_KEY` environment variable exist, the environment variable takes precedence. ## Init Command Initialize Packmind in your project. This is the recommended first command to run when setting up Packmind in a new project. ### What Init Does The init command performs these main actions: 1. **Configures AI agents** - Interactively select which AI coding agents to generate artifacts for 2. **Installs default skills** - The `packmind-onboard` and `packmind-update-playbook` skills 3. **Offers to track this repository** - Prompts you to set the current repository and branch as the one Packmind tracks (you can confirm or skip) ### Basic Usage ```bash theme={null} packmind init ``` This will: 1. Present an interactive prompt to select which AI agents you use (Claude Code, Cursor, GitHub Copilot, etc.) 2. Save your agent configuration to `packmind.json` 3. Install Packmind's default skills to the appropriate locations for your selected agents 4. Ask whether to track the current repository and branch (you can confirm or skip) 5. Display a success message with next steps **Example output:** ``` Select coding agents to generate artifacts for: 1. [*] Claude Code 2. [ ] Cursor 3. [ ] GitHub Copilot ... Enter numbers separated by commas (default: 1,2,3): 1,2 Configuration saved. Artifacts will be generated for: Claude Code, Cursor Installing default skills... Default skills installed successfully! Files created: 5 Packmind initialized successfully! Next step: Run /packmind-onboard in your AI agent to onboard the project ``` **First-time setup** — Run `packmind init` after installing the CLI and logging in. It's the quickest way to get Packmind configured for your project. After initialization, use the `/packmind-onboard` skill in your AI agent to scan your project and generate project-specific standards and commands. ## Git Command Manage which repository and branch Packmind tracks for your project. The tracked branch is the anchor Packmind uses to attribute governance and adoption activity, so declaring it tells Packmind where to follow your team's work. Only installs that run on the tracked repository and branch are recorded — see [Distribution Recording](#distribution-recording-tracked-repository-and-branch). The command has three subcommands: `git track` to set or move the tracked branch, `git untrack` to remove tracking, and `git info` to see the current state. **Organization admins only** — Only organization admins can set, move or remove the tracked branch. If you are not an admin, the command reports that you cannot change the tracked branch. `git info` only reads, so anyone can run it. **Renamed** — These used to be the top-level `packmind track` and `packmind untrack` commands. The old names now exit with an error naming their replacement. ### Git Track Set which repository and branch Packmind tracks for your project. #### Track the Current Branch Run the command from inside your project to track the current repository and branch: ```bash theme={null} packmind git track ``` Packmind derives the repository and branch from your local git remote and current branch, then asks you to confirm before setting it: ``` Track my-org/my-repo on branch dev? (y/N) Packmind now tracks my-org/my-repo on branch dev. ``` If the branch you are on is already the tracked branch, the command reports that it is already tracked and makes no change. If a **different** branch is already tracked, the command stops and tells you to use `--update` to move it: ``` Repository my-org/my-repo is already tracked on branch main. Run `packmind git track --update` to move it to dev. ``` #### Track a Specific Branch Use `--branch` to name the branch explicitly instead of tracking whichever one you have checked out: ```bash theme={null} packmind git track --branch main ``` This is useful when you are working on a feature branch but want governance anchored to your default branch — you no longer have to `git checkout main` first. The branch does not need to be checked out locally. ``` Track my-org/my-repo on branch main? (y/N) Packmind now tracks my-org/my-repo on branch main. ``` `--branch` works with `--update` too, to move tracking to a branch you are not currently on. The branch has to exist, though. A name Packmind cannot find in your repository is refused instead of being tracked, so a typo cannot leave you waiting for distributions that are never recorded: ``` Branch mian does not exist in my-org/my-repo. Check the spelling, or run `git fetch` first if the branch only exists on the remote. ``` Both local branches and branches you have fetched from the remote count. A branch created on the remote since your last fetch is unknown locally — run `git fetch` and try again. #### When No Branch Is Checked Out Mid-rebase, after `git checkout `, or in a CI job that checked out a pull request merge ref, your repository has no current branch — Git calls this a detached `HEAD`. There is nothing to track in that state, so the command stops instead of tracking a branch called `HEAD`: ``` No branch is checked out for my-org/my-repo — HEAD is detached. Check a branch out, or name one with `packmind git track --branch `. ``` Naming the branch with `--branch` works as usual, so tracking can still be set from a detached checkout. #### Move the Tracked Branch Use the `--update` flag to move tracking to your current branch when a different branch is already tracked. Packmind asks you to confirm the change before applying it: ```bash theme={null} packmind git track --update ``` ``` Change the tracked branch for my-org/my-repo from main to dev? (y/N) Tracked branch for my-org/my-repo changed from main to dev. ``` Add `--branch` to move tracking to a branch other than the one you have checked out: ```bash theme={null} packmind git track --update --branch main ``` If you cancel the prompt, the tracked branch is left unchanged. Moving the tracked branch is **reversible**: the distributions recorded on the branch you leave are kept, they simply stop being displayed, and they reappear if you move tracking back. See [Distribution History and the Tracked Branch](/governance/distribution#distribution-history-and-the-tracked-branch). If nothing is tracked yet, `--update` has nothing to move and points you to the commands that start tracking: ``` Nothing is tracked yet — run `packmind init` or `packmind git track` to start tracking. ``` **During onboarding** — `packmind init` also offers to track the current repository and branch, so you can set the anchor as part of your first-time setup. Use `packmind git track` later to set or move it. ### Git Untrack Take a repository out of Packmind's governance views. Tracking applies to the repository, so `git untrack` takes no branch — it removes whichever branch is currently tracked. **Organization admins only** — Only organization admins can remove tracking. Run it from a clone of the repository. Packmind asks you to confirm first, and names the tracked branch so you can see what you are about to remove: ```bash theme={null} packmind git untrack ``` ``` Stop tracking my-org/my-repo? Packmind currently tracks branch main. (y/N) Packmind no longer tracks my-org/my-repo. Distributions recorded on branch main are kept and reappear if you track it again. ``` The repository disappears from Distribution History and the Deployments overview. **Nothing is deleted** — run `packmind git track` on the same branch again and the whole history comes back, with new distributions appended. See [Removing Tracking](/governance/distribution#removing-tracking). While the repository is untracked, `packmind install` behaves as it does for a repository that was never tracked: it completes locally and tells you the distribution was not recorded. Running `git untrack` on a repository that is not tracked changes nothing and reports it, exiting successfully so the command is safe to repeat: ``` Repository is not tracked in 'my-organization' organization ``` ### Git Info Check what Packmind tracks for the repository you are in, without changing anything: ```bash theme={null} packmind git info ``` When the repository is tracked and you are on the tracked branch: ``` Packmind tracks my-org/my-repo on branch 'main'. ``` When the repository is tracked but you are on **another** branch, the command adds a warning, because installs you run from here are not recorded: ``` Packmind tracks my-org/my-repo on branch 'main'. You are on 'dev', so distributions from here are not recorded. Run `packmind git track --update` to move tracking to 'dev'. ``` When the repository is not tracked at all: ``` my-org/my-repo is not tracked in Packmind. Run `packmind git track` to track branch 'main'. ``` All three are answers rather than failures, so the command succeeds in each case. It only fails when it cannot answer — outside a git repository, with no git remote, or when you are not signed in. ### Troubleshooting * **Problem**: `Repository tracking is not available for your account.` * **Solution**: The feature is not enabled for your organization yet. Contact your Packmind administrator. * **Problem**: The command reports you are not logged in. * **Solution**: Run `packmind login` first, then retry. * **Problem**: The command cannot determine the repository or branch. * **Solution**: Run it from inside a git repository that has a configured remote and a checked-out branch. * **Problem**: `Command "packmind track" has been removed.` * **Solution**: Use `packmind git track` (or `packmind git untrack` in place of `packmind track --remove`). ## Config Command Configure Packmind settings. ### Config Agents Manage AI coding agents configured in your `packmind.json` files. The `config agents` command provides subcommands for interactive setup, listing, adding, and removing agents. #### Config Agents Setup Configure which AI coding agents to generate artifacts for via an interactive prompt: ```bash theme={null} packmind config agents setup ``` This presents an interactive prompt where you can select from supported AI coding agents: * **Claude Code** - Artifacts in `.claude/` directory * **Cursor** - Artifacts in `.cursor/rules/` directory * **GitHub Copilot** - Artifacts in `.github/copilot-instructions.md` * **Continue.dev** - Artifacts in `.continue/` directory * **Junie** - Artifacts in `.junie/` directory * **AGENTS.md** - Single `AGENTS.md` file at project root * **GitLab Duo** - Artifacts in `.gitlab/duo/` directory * **OpenCode** - Artifacts in `.opencode/` directory * **Codex** - Artifacts in `.agents/` directory * **Kiro** - Artifacts in `.kiro/` directory The command auto-detects existing agent configurations in your project and pre-selects them. Your selection is saved to `packmind.json`. **Auto-detection** — If you already have agent configuration files (like `.cursor/` or `.claude/`), they will be automatically pre-selected when you run this command. #### Config Agents List Display all configured coding agents across `packmind.json` files in a matrix view: ```bash theme={null} packmind config agents list ``` The output shows a matrix with file paths as rows and agent names as columns, using checkmarks (✓) and dashes (-) to indicate which agents are configured in each file. Each file also shows its source — whether agents are configured locally (via the `agents` property in `packmind.json`) or inherited from organization settings. Use `--path` to scope the listing to a specific directory: ```bash theme={null} packmind config agents list --path ./apps/api ``` #### Config Agents Add Add one or more coding agents to all `packmind.json` files: ```bash theme={null} packmind config agents add claude cursor ``` Use `--path` to target a specific directory: ```bash theme={null} packmind config agents add --path ./packages/core claude ``` If the targeted files currently inherit agent configuration from organization settings, a confirmation prompt warns that adding local agents will override the organization-level defaults. #### Config Agents Remove Remove one or more coding agents from all `packmind.json` files: ```bash theme={null} packmind config agents rm cursor copilot ``` Use `--path` to target a specific directory: ```bash theme={null} packmind config agents rm --path ./apps/frontend claude ``` When all agents are removed from a file, the `agents` property is deleted entirely and the file reverts to organization-level defaults. #### Supported Agents | Identifier | Agent | | - | - | | `claude` | Claude Code | | `cursor` | Cursor | | `copilot` | GitHub Copilot | | `continue` | Continue.dev | | `junie` | Junie | | `agents_md` | AGENTS.md | | `gitlab_duo` | GitLab Duo | | `opencode` | OpenCode | | `codex` | Codex | | `kiro` | Kiro | After adding or removing agents, run `packmind install` to deploy or clean up the corresponding agent artifact files in your repository. ## Install Command Download commands, standards, and skills from packages to your local machine. ### List Available Packages ```bash theme={null} packmind packages list ``` ### View Package Details ```bash theme={null} packmind packages show ``` ### View Workspace Status See an overview of all `packmind.json` files and their installed packages across your workspace: ```bash theme={null} packmind install --status ``` **Example output:** ``` Workspace packages status packmind.json Packages ----------------------------------------------------------------- ./packmind.json generic ./apps/api/packmind.json nestjs ./apps/frontend/packmind.json frontend 3 unique packages currently installed. ``` This is useful for: * Understanding what packages are installed across a monorepo * Identifying empty or misconfigured `packmind.json` files (shown as ``) * Getting a quick summary of unique packages in your workspace ### Install Packages ```bash theme={null} packmind install [additional-package-slugs...] ``` **Example:** ```bash theme={null} packmind install backend frontend ``` This downloads all commands, standards, and skills from the specified packages and creates the appropriate files for your AI coding assistant. **Default skills included** — When you install packages, Packmind's default skills (including the `packmind-update-playbook` skill) are automatically installed alongside your package contents. ### Package Versions Each package listed in `packmind.json` records which version of that package the folder receives. Add the version after the slug to choose it: ```bash theme={null} packmind install @my-space/ops:0.1.0 ``` | What you type | What you get | What `packmind.json` records | | - | - | - | | `@my-space/ops` | The latest release | that release, for example `0.1.0` | | `@my-space/ops:0.1.0` | Exactly that release | `0.1.0` | | `@my-space/ops:*` | The package as it stands, including changes made since the last release | `*` | A package pinned to a version stays on it. Cutting a new release in Packmind does not move a folder that pinned an older one, and neither does running `packmind install` again — your playbook only changes when you decide it does. Asking for a version that was never released stops the install and lists the versions that do exist, newest first. A package that has never been released installs as it stands, recorded as `*`. Each `packmind.json` carries its own versions, so two folders in the same repository can sit on two different releases of the same package. ### Check Upgrades Before Installing See what `packmind install --upgrade` would change before running it: ```bash theme={null} packmind install --check-upgrades ``` **Example output:** ``` @my-space/ops 0.1.0 → 0.2.0 ~ standard Backend conventions v3 → v4 + skill Release notes (new) - command Old deploy (removed) @my-space/frontend * · 2 components to update ~ standard React components v5 → v6 ~ skill Storybook v1 → v2 Run packmind install --upgrade to apply these changes. ``` For each package in `packmind.json`, you see: * **Pinned packages** — the version the package would move from and to (here `0.1.0 → 0.2.0`) * **Packages tracking `*`** — how many of their commands, standards, and skills have changed since your last install * **What changes underneath** — every command, standard, and skill that would be added (`+`), updated (`~`, with its version move), or removed (`-`) A few other changes show up too: * **Coding agents changed in `packmind.json`** — a `Coding agents: claude → claude, cursor` line comes first, and the commands, standards, and skills that would be written to different files are marked `(files change)` * **No packages left in `packmind.json`** — every installed command, standard, and skill is listed as removed, since installing would delete their files When there is nothing to upgrade, the command prints `Already up to date`. If you don't have access to some packages, the command lists them (`Could not check 2 packages you don't have access to: …`) and exits with code `1`, so an incomplete check never passes as up to date. Nothing in your repository changes: `packmind.json`, your lock file, and your installed files stay exactly as they were, and the check is not recorded as an install in Packmind. Run `packmind install --upgrade` when you are ready to apply the changes. The command exits with code `1` when upgrades are available, and code `0` when everything is up to date — handy for flagging an outdated playbook in CI: ```bash theme={null} if ! packmind install --check-upgrades; then echo "Packmind packages have new releases. Run 'packmind install --upgrade'." fi ``` In a monorepo, the check covers the same `packmind.json` files as `packmind install`. Use `--path` to scope it to a specific directory: ```bash theme={null} packmind install --check-upgrades --path apps/api ``` `--check-upgrades` checks the packages already listed in `packmind.json`. It cannot be combined with `--upgrade`, `--status`, or package names. ### Upgrade to the Latest Releases Move every pinned package to its latest release: ```bash theme={null} packmind install --upgrade ``` This rewrites `packmind.json` with the version each package landed on, so you can see exactly what moved in your diff before committing it. To preview what would move first, without changing anything, run `packmind install --check-upgrades` (see [Check Upgrades Before Installing](#check-upgrades-before-installing)). Packages tracking `*` keep tracking it — their line in `packmind.json` is left alone — and their files are refreshed like any install. To move a single package instead, name it with the version you want: ```bash theme={null} packmind install @my-space/ops:0.2.0 ``` ### Lock File (`packmind-lock.json`) When you install or uninstall packages, the CLI generates a `packmind-lock.json` file alongside your `packmind.json`. This file records the exact versions of all installed artifacts, and under `packages` the version of each package the folder receives: ```json theme={null} { "packages": { "@my-space/ops": "1.2.3" } } ``` Packmind treats this file as the source of truth for what each target runs. See [Keep the Distribution State in Sync with Your Repository](/governance/distribution#keep-the-distribution-state-in-sync-with-your-repository). ### Recursive Install (Monorepos) By default, `packmind install` (with no package slugs) finds all `packmind.json` files in your git repository and installs their configured packages. After installation, a summary shows how many distributions were notified to Packmind. ```bash theme={null} packmind install ``` To scope the recursive install to a specific directory, use the `--path` option: ```bash theme={null} packmind install --path apps/frontend ``` **AI Agent Rendering** — The files created by the install command depend on which AI agents are enabled in your organization settings. The CLI respects your organization's configured agents and creates instruction files accordingly (e.g., `AGENTS.md`, `.cursor/rules/`, `.github/copilot-instructions.md`). The `.packmind/` directory is always created regardless of your configuration. To configure which agents are enabled, see [Manage AI Agent Rendering](/administration/manage-ai-agents). ### Distribution Recording (Tracked Repository and Branch) When you install packages inside a git repository, Packmind records the deployment as a **distribution** so it shows up in your governance and adoption views. To keep those views meaningful, a distribution is recorded **only when you install on the repository and branch your organization tracks** (see [Git Track](#git-track)). If you install anywhere else, the install still completes locally, but nothing is sent to Packmind and the CLI tells you why: * **The repository is not tracked** — no repository is tracked for this project yet: ``` Distribution not recorded — my-org/my-repo is not tracked in Packmind. Ask an admin to run `packmind git track` to start tracking it. ``` * **You are on a different branch** — the repository is tracked, but on another branch: ``` Distribution not recorded — you're on 'dev', but the tracked branch is 'main'. Switch to 'main' to record this distribution. ``` * **The folder is not a tracked git repository** — you are outside a git repository, there is no git remote, or you are not signed in: ``` This folder is not tracked — distribution not recorded in Packmind. ``` **Anyone can install** — Recording a distribution is not restricted to admins. Only *setting* the tracked repository and branch requires an organization admin (see [Git Track](#git-track)). **Not seeing your activity in Packmind?** — Confirm you are on the tracked repository and branch. An organization admin can set or move the tracked branch with `packmind git track`. If the branch was tracked before and is not anymore, its distributions are still kept — they reappear when tracking moves back. See [Distribution History and the Tracked Branch](/governance/distribution#distribution-history-and-the-tracked-branch). ### Install Globally for Claude Code (`~/.claude`) When you run `packmind install` from inside your `~/.claude` directory, the CLI switches into **home-install mode** — a streamlined flow optimized for sharing Packmind artifacts across every project you open in Claude Code, rather than tying them to a single repository. ```bash theme={null} cd ~/.claude packmind install ``` **Why install here:** * **Global availability across projects** — Skills, rules, and commands land directly under `~/.claude/skills/`, `~/.claude/rules/`, and `~/.claude/commands/`, so Claude Code picks them up in any repository you open, not just one you have initialized with Packmind. * **Single-agent rendering** — Only Claude Code artifacts are generated. Any `agents` entries in `packmind.json` and your organization's render modes are ignored, since `~/.claude` is by definition Claude-specific. * **Zero-prompt setup** — If no `packmind.json` exists in `~/.claude`, the CLI auto-creates one with `{"agents": ["claude"]}` and skips the interactive agent prompt entirely. * **Clean file layout** — The `.claude/` path prefix is stripped from rendered files, so artifacts do not nest under a redundant `~/.claude/.claude/` subfolder. * **No `.packmind/` mirror** — The server-side `.packmind/` directory (whose internal links assume a repository layout) is skipped, keeping your home directory uncluttered. * **No distribution notifications** — Even if `~/.claude` happens to live inside a git repository, the CLI does not notify Packmind that a distribution occurred — these artifacts are personal to your machine, not a team deployment. **When to use this mode** — Reach for `~/.claude` installs when you want a package available to Claude Code everywhere: personal coding preferences, cross-project organizational defaults, or experimental skills you want to try without modifying any repository. Per-repo `packmind install` remains the right choice for project-specific standards that should be shared with teammates and committed to source control. ## Distribution Command ### Distribution Record Tell Packmind what the `packmind-lock.json` files in your working copy say each target runs — useful after editing a lock by hand: ```bash theme={null} packmind distribution record ``` * **From the repository root** — every target in the repository is recorded. * **From a sub-folder** — only the targets at or below that folder are recorded. The lock files are found through Git: folders your `.gitignore` excludes are skipped, and lock files you have not committed yet are included. Only the targets that changed are listed in the output. Run it on the tracked branch (see [Git Track](#git-track)). Your lock edits do not need to be pushed, but a later **Sync from repository** in the app reads the locks on the remote branch and shows that state again — push your changes to keep them. See [Keep the Distribution State in Sync with Your Repository](/governance/distribution#keep-the-distribution-state-in-sync-with-your-repository). #### Troubleshooting * **Problem**: `The current directory is not managed by Packmind: no packmind-lock.json here or below records package versions.` * **Solution**: Run `packmind install` to create the lock files, or move to a folder that contains them. * **Problem**: `Nothing recorded: the tracked branch is 'main', and you are on 'dev'.` * **Solution**: Switch to the tracked branch and run the command again. * **Problem**: `Nothing recorded: the current directory is not in a Git repository.` * **Solution**: Run the command from inside the repository's working copy. * **Problem**: A package is reported as not a package of your organization. * **Solution**: That package is not recorded. Check its slug in the lock file, or remove it with `packmind uninstall`. ## Lint Command **Enterprise Feature** — The lint command is only available in the **Enterprise** edition. Run detection programs against your codebase from the command line. This is useful for testing draft detection programs, verifying active programs, and integrating linting into your development workflow or CI/CD pipelines. ### How Lint Works The CLI supports two linting modes: **Local Mode** (recommended): When you have `packmind.json` files in your project, the CLI uses them to determine which standards to check against. The CLI automatically searches for all `packmind.json` files in your project tree: * **Ancestor configs**: Searches parent directories up to the Git repository root * **Descendant configs**: Searches subdirectories from your current location All standards from packages defined in these `packmind.json` files are included in the analysis scope. This allows different parts of your codebase to have different standards while inheriting common standards from parent directories. To set up local linting, install packages using the `install` command. See [Distribute Standards and Commands](/getting-started/gs-distribute) for details. **Deployment Mode**: If no `packmind.json` files are found, the CLI falls back to using standards that have been deployed to your Git repository through the web interface. See [Deployment](/governance/distribution) to learn about this approach. **Priority** — When both local `packmind.json` files and deployments exist, the local configuration takes priority. ### Basic Usage ```bash theme={null} packmind lint . ``` This command: * Searches for `packmind.json` files in your project tree * Loads detection programs from the standards defined in your packages * Scans all files in the current directory (excluding `node_modules`, `dist`, and other common build folders) * Runs all active detection programs * Reports any violations found ### Specify a Path Lint a specific directory: ```bash theme={null} packmind lint src/ ``` ```bash theme={null} packmind lint /path/to/your/project ``` Lint a single file: ```bash theme={null} packmind lint src/components/Button.tsx ``` When a single file is passed: * The CLI verifies the file exists and exits with an error if not * `.packmindignore` patterns are checked — if the file matches, it is skipped and the command exits with code 0 * If the file is not in scope for the requested rule or standard (i.e. its extension doesn't match the rule's configured languages), an informational message is logged and no violations are reported ### Limiting Scope with `--changed-files` and `--changed-lines` When working on large codebases, you can focus the lint check on only the files or lines you've modified using the `--changed-files` and `--changed-lines` flags. **Git Repository Required** — The `--changed-files` and `--changed-lines` flags require your project to be in a Git repository. **Check modified lines only:** ```bash theme={null} packmind lint . --changed-lines ``` This analyzes only the specific lines you've changed, making it ideal for pre-commit hooks or reviewing your work before pushing. **Check modified files only:** ```bash theme={null} packmind lint . --changed-files ``` This analyzes all content in files you've modified, useful when you want full context but don't want to scan the entire codebase. **Example workflow:** ```bash theme={null} # Make some changes to your code git add . # Check only what you changed packmind lint . --changed-lines # If clean, commit git commit -m "Your changes" ``` ### Output Formats Choose between human-readable and IDE-friendly output: ```bash theme={null} packmind lint . --logger=ide ``` **Human-readable format** (default) shows: * File paths with violations * Line and character positions * Rule identifiers * Summary of total violations found **IDE format** provides structured output that can be parsed by editors and CI/CD tools. ### Filtering by Severity Use the `--level` flag to filter which violations are displayed based on their severity: ```bash theme={null} # Show only errors (suppress warnings) packmind lint . --level error # Show warnings and errors (everything) packmind lint . --level warning ``` | Value | What is displayed | | - | - | | `error` | Only error-level violations | | `warning` | All violations (warnings and errors) | Without the `--level` flag, all violations are displayed regardless of severity. **CI/CD usage** — Use `--level error` in your CI pipeline to focus on blocking violations only, while still running `--level warning` (or no flag) during local development to see all feedback. See [Rule Severity](/linter/linter#rule-severity) for details on how severity affects exit codes. ## Skills Command Manage skills in your Packmind organization. Skills are reusable knowledge packages that AI coding assistants can discover and use. ### Initialize Default Skills ```bash theme={null} packmind skills init ``` This command installs Packmind's default skills locally, including: * **packmind-onboard** — A skill for initializing Packmind in projects * **packmind-update-playbook** - A skill to manage your playbook: create skills, commands and standards or update the existing ones. **Automatic installation** — Default skills are also installed automatically when you run `packmind init`, install a package with `packmind install`, or when packages are distributed to your repository via the web app. ### List Skills ```bash theme={null} packmind skills list ``` This command displays all skills in your Packmind organization, showing: * **Slug** — The skill identifier * **Name** — The display name * **URL** — Direct link to view the skill in the web app * **Description** — What the skill does **Example output:** ``` Available skills: - my-custom-skill Name: My Custom Skill URL: https://app.packmind.ai/org/my-org/space/global/skills/my-custom-skill/files Description: Custom skill for my project... ``` ### Add a Skill ```bash theme={null} packmind playbook add packmind playbook submit --no-review ``` **Arguments:** * `` - Path to the skill directory containing skill files **Example:** ```bash theme={null} packmind playbook add ./my-skill packmind playbook submit --no-review ``` Use `--no-review` to trigger a [direct update](/playbook-maintenance/updating-your-playbook#direct-updates). Omit `--no-review` to use the [change proposals](/playbook-maintenance/change-proposals) system and get validation of your changes. This uploads the skill to your Packmind organization, making it available for distribution to repositories. When uploading a skill that already exists, Packmind automatically compares the content: * If changes are detected, a new version is created * If the content is identical, no new version is created See [Skills Management](/concepts/skills-management) for details on versioning. ## Standards Command Create and manage coding standards from the command line. ### List Standards ```bash theme={null} packmind standards list ``` This command displays all standards in your Packmind organization, showing: * **Slug** — The standard identifier * **Name** — The display name * **URL** — Direct link to view the standard in the web app * **Description** — What the standard covers **Example output:** ``` Available standards: - error-handling Name: Error Handling URL: https://app.packmind.ai/org/my-org/space/global/standards/abc123/summary Description: Ensure errors are handled predictably... - typescript-conventions Name: TypeScript Conventions URL: https://app.packmind.ai/org/my-org/space/global/standards/def456/summary Description: TypeScript coding conventions... ``` ### Create a Standard See [create a standard from the CLI](/getting-started/gs-create-standard#create-a-standard-from-the-cli) to discover how you can create standards using the CLI. ## Commands Command Create and manage reusable, multi-step workflow commands from the command line. ### List Commands ```bash theme={null} packmind commands list ``` This command displays all commands in your Packmind organization, showing: * **Slug** — The command identifier * **Name** — The display name * **URL** — Direct link to view the command in the web app **Example output:** ``` Available commands: - add-a-new-rest-endpoint Name: Add a New REST Endpoint URL: https://app.packmind.ai/org/my-org/space/global/commands/abc123 - setup-database-migration Name: Setup Database Migration URL: https://app.packmind.ai/org/my-org/space/global/commands/def456 ``` ### Create a Command ```bash theme={null} packmind playbook add path/to-command.md packmind playbook submit ``` The markdown file content will be used as the command's prompt. The name of the command will be deduced from the file path. The command markdown should be located in a directory where commands are available. Such directories include:
  • `.packmind/commands`
  • `.cursor/commands`
  • `.github/prompts`
 ## Spaces Command List the spaces available in your Packmind organization. [Spaces](/concepts/spaces) organize standards, commands, skills, and packages within an organization. ### List Spaces ```bash theme={null} packmind spaces list ``` This command displays all spaces in your Packmind organization, showing: * **Slug** — The space identifier (prefixed with `@`) * **Name** — The display name **Example output:** ``` Available spaces: - @global Name: Global - @security Name: Security ``` ## Packages Command Create and manage packages from the command line. ### List Packages ```bash theme={null} packmind packages list ``` This command displays all packages in your Packmind organization, showing: * **Slug** — The package identifier * **Name** — The display name ### Create a Package ```bash theme={null} packmind packages create ``` **Arguments:** * `` - Name of the package to create **Options:** | Flag | Short | Description | | - | - | - | | `--description` | `-d` | Description of the package | **Example:** ```bash theme={null} packmind packages create "Backend Standards" ``` With a description: ```bash theme={null} packmind packages create "Backend Standards" -d "Standards and commands for backend development" ``` This creates a new empty package in your Packmind organization. After creation, you can add commands, standards, and skills to the package through the web interface or by using the `packages add` command. ### Package Identification When you create a package, Packmind automatically generates a **slug** from the package name: * **Name** (provided by you): `"Backend Standards"` * **Slug** (auto-generated): `"backend-standards"` The slug is used for: * Package installation: `packmind install backend-standards` * Package identification and distribution If a package with the same slug already exists in your [space](/concepts/spaces), Packmind appends a counter (e.g., `backend-standards-1`) to ensure uniqueness. ### Add Items to a Package ```bash theme={null} packmind packages add --to --standard packmind packages add --to --command packmind packages add --to --skill ``` **Options:** | Flag | Description | | - | - | | `--to` | Target package slug (required) | | `--standard` | Slug of the standard to add to the package | | `--command` | Slug of the command to add to the package | | `--skill` | Slug of the skill to add to the package | **Examples:** Add a standard to a package: ```bash theme={null} packmind packages add --to backend --standard error-handling ``` Add a command to a package: ```bash theme={null} packmind packages add --to backend --command create-api-endpoint ``` Add a skill to a package: ```bash theme={null} packmind packages add --to backend --skill debugging-workflow ``` **Workflow tip** — Use this command after creating standards, commands, or skills via CLI to organize them into packages. This is particularly useful when automating package management in scripts or CI/CD pipelines. **One item, one package** — An item belongs to a single package. If the item already belongs to another one, `packages add` changes nothing and prints the `packages move` command that would relocate it: ``` $ packmind packages add --to backend --command create-api-endpoint Command "Create API endpoint" already belongs to package "@my-space/api" Run `packmind packages move --command create-api-endpoint --to @my-space/backend` to move the command. ``` ### Move Items Between Packages ```bash theme={null} packmind packages move --to --standard packmind packages move --to --command packmind packages move --to --skill ``` Adds the item to the target package and removes it from **every** other package it belonged to. An item already in the target package and nowhere else is left untouched. **Options:** | Flag | Description | | - | - | | `--to` | Target package slug (required) | | `--standard` | Slug of the standard to move into the package | | `--command` | Slug of the command to move into the package | | `--skill` | Slug of the skill to move into the package | **Example:** ``` $ packmind packages move --command create-api-endpoint --to @my-space/backend Command "Create API endpoint" has been added to package "@my-space/backend" It has been removed from "@my-space/api" ``` When the item came from several packages, they are listed: ``` $ packmind packages move --command create-api-endpoint --to @my-space/backend Command "Create API endpoint" has been added to package "@my-space/backend" It has been removed from the following packages: - @my-space/api - @my-space/legacy ``` ### Remove Items From a Package ```bash theme={null} packmind packages remove --from --standard packmind packages remove --from --command packmind packages remove --from --skill ``` **Options:** | Flag | Description | | - | - | | `--from` | Slug of the package to remove from (required) | | `--standard` | Slug of the standard to remove from the package | | `--command` | Slug of the command to remove from the package | | `--skill` | Slug of the skill to remove from the package | **Example:** ``` $ packmind packages remove --command create-api-endpoint --from @my-space/backend Command "Create API endpoint" has been removed from package "@my-space/backend" It does not belong to any package anymore ``` An item that belongs to no package is no longer installed or distributed anywhere. The command always states what the item still belongs to, so you can tell the two outcomes apart. ## Plugins Command Publish a Packmind package as a [Claude Code plugin](https://docs.claude.com/en/docs/claude-code/plugins) or a GitHub Copilot plugin, so its commands and skills can be installed directly into your coding agent — either from your own [marketplace](https://docs.claude.com/en/docs/claude-code/plugin-marketplaces) or, for Claude Code, as a standalone plugin repository. A rendered plugin contains the package's commands and skills — as slash commands and skills for Claude Code, as prompt files and skills for GitHub Copilot. Standards are not rendered because plugins do not support them, for either vendor — when a package contains standards, the CLI reports how many were skipped. **GitHub Copilot marketplaces are supported too** — a repository containing `.github/plugin/marketplace.json` instead of `.claude-plugin/marketplace.json` is a GitHub Copilot marketplace, and `plugins render` writes a Copilot-formatted plugin into it instead of a Claude Code one, in the same `plugins//` layout. A repository can only be one or the other, never both, the same way [marketplaces linked from the web app](/governance/marketplaces) work. ### Choose Your Workspace Mode The `plugins` commands detect what kind of workspace you are in by looking for a marketplace or plugin manifest: | File present | Mode | Use case | | - | - | - | | `.claude-plugin/marketplace.json` | **Marketplace (Claude Code)** | A repository that hosts multiple plugins, each under `plugins//` | | `.github/plugin/marketplace.json` | **Marketplace (GitHub Copilot)** | Same as above, rendered as GitHub Copilot plugins instead | | `.claude-plugin/plugin.json` | **Standalone** | A repository that contains a single plugin at its root (Claude Code only) | | None of the above | *Not supported* | The CLI exits with an error asking you to create one of the manifests first | **Setting up a marketplace** — Create a `.claude-plugin/marketplace.json` file at the root of a Git repository with the shape `{ "name": "", "owner": { "name": "" }, "plugins": [] }`. The CLI fills in the `plugins` array for you as you render packages. See Anthropic's [marketplace documentation](https://docs.claude.com/en/docs/claude-code/plugin-marketplaces) for the full schema. **Setting up a standalone plugin** — Create a `.claude-plugin/plugin.json` file at the root of a Git repository with at least `{ "name": "" }`. The plugin name must match the package slug you intend to render. ### Plugins Render Render a Packmind package as a Claude Code or GitHub Copilot plugin in the current workspace. ```bash theme={null} packmind plugins render ``` **Arguments:** * `` — Slug of the package to render (for example, `security` or `@my-space/security`) #### Marketplace Workflow Run the command from the root of your marketplace repository (the directory that contains `.claude-plugin/marketplace.json`): ```bash theme={null} packmind plugins render security ``` The CLI will: 1. Download the package's commands and skills from your Packmind organization 2. Write them under `plugins/security/` (commands in `plugins/security/commands/`, skills in `plugins/security/skills/`), along with the plugin manifest at `plugins/security/.claude-plugin/plugin.json` 3. Add or update the plugin entry inside `.claude-plugin/marketplace.json`, pointing `source` to `./plugins/security` **GitHub Copilot marketplaces** — The CLI picks the plugin format from the descriptor it finds. A repository holding `.github/plugin/marketplace.json` instead is rendered in the Copilot format: commands land in `plugins/security/.github/prompts/` as `.prompt.md` files, and the manifest is written at `plugins/security/.github/plugin/plugin.json` — the path Copilot probes — instead of `plugins/security/.claude-plugin/plugin.json`. Skills are rendered under `plugins/security/skills/` for both vendors. **Example output:** ``` Rendered 12 files into ./plugins/security/ Skipped 3 standards (not supported in plugins). Updated .claude-plugin/marketplace.json ``` When the same plugin is rendered again, the CLI asks for confirmation before overwriting: ``` Plugin "security" already exists at "./plugins/security". Overwrite? [y/N] ``` #### Standalone Workflow Run the command from the root of your standalone plugin repository (the directory that contains `.claude-plugin/plugin.json`): ```bash theme={null} packmind plugins render security ``` The CLI will: 1. Verify that the package slug matches the `name` field declared in `plugin.json` 2. Download the package's commands and skills 3. Write them directly at the repository root (`commands/` and `skills/`) Because a standalone repository already represents the plugin, the CLI always asks for confirmation before overwriting existing files: ``` Plugin "security" already exists in this workspace. Overwrite? [y/N] ``` **Git remote detected automatically** — When the workspace is a Git repository with a remote, the CLI captures the remote URL and current branch and sends them to Packmind so the distribution is tracked alongside your other deployments. ### Plugins Delete Remove a rendered plugin from the current workspace and notify Packmind that the distribution has been deleted. Like `render`, it works in whichever workspace mode it detects — a Claude Code or a GitHub Copilot marketplace, or a standalone Claude Code plugin. ```bash theme={null} packmind plugins delete ``` **Arguments:** * `` — Slug of the plugin to delete (matches the package slug used during `render`) #### Marketplace Workflow Run the command from the root of your marketplace repository: ```bash theme={null} packmind plugins delete security ``` The CLI will: 1. Locate the plugin entry in the marketplace descriptor it found — `.claude-plugin/marketplace.json` for Claude Code, `.github/plugin/marketplace.json` for GitHub Copilot 2. Ask for confirmation: ``` Remove ./plugins/security and update marketplace.json for plugin "security"? [y/N] ``` 3. Delete the plugin directory (for example, `./plugins/security`) and remove its entry from that descriptor If the plugin is not declared in the descriptor, the command exits without changes: ``` Plugin "security" is not declared in marketplace.json. Nothing to delete. ``` **Both vendors are covered** — Deleting removes the whole `plugins//` directory, so a Copilot plugin's `.github/prompts/`, `skills/` and `.github/plugin/plugin.json` go with it, exactly as a Claude Code plugin's `commands/`, `skills/` and `.claude-plugin/plugin.json` do. #### Standalone Workflow Run the command from the root of your standalone plugin repository: ```bash theme={null} packmind plugins delete security ``` After confirmation, the CLI removes the rendered `commands/` and `skills/` directories. The `.claude-plugin/plugin.json` manifest is left untouched so you can re-render the plugin later. Standalone mode is Claude Code only — there is no GitHub Copilot equivalent of a single-plugin-at-the-root repository, so Copilot plugins are always managed through the marketplace workflow above. ### Troubleshooting * **Problem**: `No .claude-plugin/marketplace.json, .github/plugin/marketplace.json, or .claude-plugin/plugin.json found in this directory.` * **Solution**: Run the command from the root of a workspace that contains one of these manifests. Create the appropriate manifest first if the workspace is brand new. * **Problem**: ` is not valid JSON. Fix the file and try again.` * **Solution**: The marketplace manifest Packmind found has a syntax error. Fix the JSON in that file and run the command again. * **Problem**: `The plugin '' is not handled in this repo.` (standalone mode) * **Solution**: The package slug you passed does not match the `name` declared in `.claude-plugin/plugin.json`. Update the manifest or pass the matching slug. * **Problem**: `Plugin "" has a remote source. Run this command in the workspace of the remote plugin.` * **Solution**: The marketplace entry points to a remote source (for example, a GitHub repository) rather than a local folder. Switch to the workspace that owns the remote plugin and run the command there. * **Problem**: Some content from the package is missing in the rendered plugin. * **Solution**: Standards are intentionally skipped because plugins do not support them, for either vendor. Check the `Skipped N standards` line in the command output to see how many were excluded. ## Playbook Command Manage local artifact changes and propose them to your team using a git-like staging workflow. The `playbook` command groups six subcommands: `diff`, `status`, `add`, `rm`, `unstage`, and `submit`. ### View Differences ```bash theme={null} packmind playbook diff ``` Compares your local artifact files (standards, commands, skills) against the versions published in Packmind. No changes are submitted. **Example output:** ``` Standard: Error Handling Rule (update) - Validate inputs at system boundaries and fail fast + Validate inputs at system boundaries, fail fast, and log the context Rule (add) + Preserve context when rethrowing errors Rule (delete) - Avoid swallowing exceptions silently ``` For each standard, the diff shows: * **Rule (update)** — a rule that was modified (Packmind detects this automatically using similarity matching) * **Rule (add)** — a new rule added locally * **Rule (delete)** — a rule removed locally **Options:** | Flag | Short | Description | | - | - | - | | `--include-submitted` | | Include already-submitted changes in the output | | `--path ` | `-p` | Limit analysis to a specific path | ### Check Status ```bash theme={null} packmind playbook status ``` Shows staged changes ready for submission and untracked local modifications. **Example output:** ``` Changes to be submitted: - Standard "Error Handling" (updated) .claude/rules/error-handling.md Changes not tracked: - Command "Deploy" (modified) .claude/commands/deploy.md Use `packmind playbook add ` to track them ``` ### Stage Changes ```bash theme={null} packmind playbook add ``` Stages a local artifact change for submission. The change type (created or updated) is detected automatically by comparing with the deployed version. ### Stage Removal ```bash theme={null} packmind playbook rm ``` Stages an artifact for removal from the playbook. The artifact must have been distributed by Packmind. Alias: `remove`. ### Unstage Changes ```bash theme={null} packmind playbook unstage ``` Removes a previously staged change from the playbook without submitting it. ### Submit Proposals ```bash theme={null} packmind playbook submit -m "Improve error handling rules for better observability" ``` Submits all staged changes as change proposals for team review in the Packmind web app. | Flag | Short | Description | | - | - | - | | `--message ` | `-m` | Message describing the intent behind the changes (max 1024 chars) | If you omit `-m`, Packmind opens your default editor so you can write the message interactively. ### How Rule Updates Are Detected When you modify a rule in a standard file, Packmind automatically determines whether the change is a rule update (the same rule was edited) or a separate deletion and addition (two unrelated rules). This keeps your change proposals clean and meaningful, showing reviewers exactly what was changed rather than an unrelated delete + add pair. **Requires a git repository** — The `playbook` command requires your project to be in a git repository with a configured remote. Make sure you have run `packmind install` to set up your `packmind.json` before using `playbook`. ## Update Command Update the Packmind CLI to the latest version. ```bash theme={null} packmind update ``` This checks for a newer version and updates the CLI in place: * **Standalone executable** — Downloads the latest binary from GitHub and replaces the current executable automatically. * **npm global install** — Runs `npm install -g @packmind/cli@latest` to update through npm. **Example output:** ``` Current version: 1.2.0 (standalone executable) New version available: 1.2.0 -> 1.3.0 Downloading packmind-cli-macos-arm64... Downloaded successfully (12.4 MB) Updated to v1.3.0 Binary location: /usr/local/bin/packmind ``` If you are already on the latest version: ``` Already up to date (v1.3.0) ``` **Permission error on Linux/macOS** — If you see a permission denied error, run the command with `sudo`: ```bash theme={null} sudo packmind update ``` ### Check for Updates Without Installing Use the `--check` flag to see if a newer version is available without performing the update: ```bash theme={null} packmind update --check ``` This is useful in CI/CD pipelines or scripts where you want to detect outdated CLI versions without automatically upgrading. The command exits with code `1` if a newer version is available, and code `0` if already up to date. **Example:** ```bash theme={null} if ! packmind update --check; then echo "A new version of packmind is available. Run 'packmind update' to upgrade." fi ``` The `update` command is available for standalone executables and npm global installs only. If you manage the CLI through a local `package.json`, update it with `npm update @packmind/cli` instead. ## Related Documentation * [Create your first command](/getting-started/gs-create-command): Learn how to create commands with AI assistance * [Packages Management](/concepts/packages-management): Learn about organizing commands, standards, and skills into packages * [Linter: Automated Detection](/linter/linter): Learn about how detection programs work * [Standards Management](/concepts/standards-management): Create rules and add code examples * [Skills Management](/concepts/skills-management): Create and manage reusable skills This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.