Skip to main content
Now that Packmind contains coding standards, commands, and skills, let’s distribute them to your Git Repositories. The distribution will commit instructions files that will be used by AI Agents (Claude Code, Cursor, etc.).

​
Supported AI Agents

Packmind supports multiple AI coding assistants. Organization administrators can choose which agents to enable in Settings → Distribution → Rendering. See Manage AI Agent Rendering for details. For a detailed breakdown of where standards, commands, and skills appear for each AI assistant, see Understanding Where Your Artifacts Appear.
Default skills included — All distributions automatically include Packmind’s default skills (such as packmind-update-playbook for creating and updating playbook artifacts with AI assistance). These are added alongside your package contents regardless of which distribution method you use.
Need support for a new AI agent? You can create an issue in our repository to request support for additional AI coding assistants.

​
How to Distribute

There are two ways to distribute packages to your repositories:
  1. Using the Packmind app - Distribute packages through the web interface with full control over targets and repositories
  2. Using the Packmind CLI - Install packages directly from your terminal, useful for CI/CD pipelines and local development

​
Distribution Methods Overview

​
Distribute via the App

To distribute standards, commands, and skills, you need to add them to a package. A package is a curated collection of commands, standards, and skills grouped together (e.g., “Frontend React Standards”, “Backend API Guidelines”). When you distribute a package:
  • All commands, standards, and skills in the package are distributed together
  • The latest version of each item is used
  • A single commit contains all the package content
  • You can distribute multiple packages at once to the same target
To distribute packages:
  1. Navigate to the Packages section
  2. Select the package(s) you want to distribute
  3. Click Distribute and choose your target repositories
  4. Confirm the Distribution
This approach is useful when you want to:
  • Distribute related guidelines together
  • Maintain consistent sets of standards across projects
  • Organize guidelines by technology, team, or project structure
For more information on creating and managing packages, see Packages Management.

​
Distribute via the Packmind CLI

You can also distribute packages directly from your terminal using the packmind command:
For example:
When your organization uses multiple Spaces, prefix package slugs with the space slug using @space/package notation.
This will:
  1. Fetch the specified packages from Packmind
  2. Generate the instruction files for all enabled AI agents
  3. Write the files to your local repository
  4. Notify Packmind that a distribution occurred

​
CLI Distribution Considerations

When you distribute packages using the CLI, Packmind automatically creates a Git provider entry to track the distribution. However, these CLI-created providers have some limitations:
Limited Provider Management — Git providers created through CLI distributions are not authenticated. This means you cannot trigger new distributions from the app for these repositories, you cannot add new targets to these providers from the app, and the provider appears in your organization’s Git settings but with limited functionality. To enable full management from the app, connect a Git provider in Settings → Git Providers — using the GitHub App (recommended) or a personal access token. See Git Repository Connection for the full setup.
Connecting a provider later does not lose what the CLI recorded. Once a connection exists for the same host — github.com, gitlab.com or your self-managed instance — the CLI records new repositories under it, and adding a repository the CLI already recorded moves it there with its targets and distribution history. The CLI-created entry disappears from your Git settings once it holds no repository.

​
When to Use CLI Distribution

The CLI approach is ideal for:
  • CI/CD pipelines - Automate distribution as part of your deployment process
  • Local development - Quickly install packages without leaving your terminal
  • Monorepos - Use packmind install to install packages for all packmind.json files in the repository
  • Repositories without a connection - Distribute to repositories that aren’t connected to the app

​
Distribution History and the Tracked Branch

Every package, standard, command, and skill has a Distribution History listing when it was distributed and where it landed. When your organization tracks a repository and branch (see Git Track), Packmind shows the branch you currently track. Distributions made on other branches of the same repository are hidden, so the view stays focused on the branch your team works from today. This applies to both places branches surface:
  • Distribution History — entries recorded on another branch of a tracked repository are not listed.
  • The Deployments overview — the repositories list only shows the tracked branch, so a repository never appears twice under two branches.
Repositories you have never tracked are unaffected — every branch keeps showing in both views.

​
When the Tracked Branch Is Deleted

A branch usually disappears the day its pull request is merged. Tracking survives it, and since distributions are only recorded on the tracked branch, nothing is recorded from then on — with no error anywhere to say so. Packmind checks the tracked branch against your Git provider and flags it when it is gone:
  • Settings → Targets — the repository card carries a Branch deleted marker.
  • The Git connection panel — the tracked branch is marked in the repositories list, where an admin manages tracking.
  • packmind git info — reports that the branch is not in the repository and offers to move tracking.
Needs a Git connection — checking a branch means asking your Git provider, so the two web app markers only appear for repositories reached through a connection. A repository Packmind knows only from packmind install carries no credentials to ask with, and packmind git info is the signal there.
To start recording again, an organization admin moves tracking to a branch that exists:
Nothing recorded on the deleted branch is lost — its history is kept, exactly as when tracking moves for any other reason.

​
Moving the Tracked Branch Is Reversible

Moving tracking to another branch never deletes anything:
  • Distributions recorded on the branch you leave are kept, just no longer displayed.
  • Move tracking back and the earlier history reappears, with new distributions added to it.
So a team that tracks main, moves to dev for a while, then returns to main finds their original main history intact and continuing where it left off.
Only one branch at a time — Packmind shows the tracked branch’s history rather than several branches side by side. To see another branch’s history, ask an organization admin to move tracking to it, either with change branch in the Git connection panel (see Changing a Repository’s Branch) or with packmind git track --update.

​
Removing Tracking

An organization admin can take a repository out of the governance views entirely by running packmind git untrack from a clone of it (see Git Untrack). The repository disappears from Distribution History and the Deployments overview. Nothing is deleted. Every distribution recorded before the removal is kept, and tracking the same branch again brings the whole history back, with new distributions appended to it. Tracking a different branch instead starts that branch’s history fresh, while the original branch’s history stays retained and returns whenever you track it again. While a repository is untracked, packmind install behaves exactly as it does for a repository that was never tracked: it completes locally and tells you the distribution was not recorded.

​
Keep the Distribution State in Sync with Your Repository

What a target runs is whatever its packmind-lock.json says. Each lock lists the version of every package distributed to that folder:
Both packmind install and distributions from the app write this file, and removing a package from a target in the app removes it from the lock too.

​
When Packmind Reads the Lock Files

Packmind refreshes the distribution state from the lock files on the tracked branch on its own when:
  • A repository is tracked — the lock files already in the repository are read when it is connected.
  • The tracked branch changes — the new branch’s lock files are read. Distributions of the previous branch are kept as history but no longer shown.
  • A target is added — the lock at the target’s path is read. If there is none, the target shows no distribution.
  • A target’s path is renamed — the lock at the new path is read. Earlier distributions stay with the target.

​
Sync from the App

When a lock file changed outside Packmind — for example someone edited it by hand — refresh the state yourself:
  1. Open the Distribution page and select the repository.
  2. In the repository’s detail pane, click Sync from repository.
Packmind reads every packmind-lock.json on the tracked branch and updates the targets that changed:
  • A lock in a folder no target declares creates that target.
  • A package missing from a lock is kept while the packmind.json next to it still lists it; otherwise it is recorded as removed.
  • A lock that already matches what Packmind shows records nothing.
If some lock files could not be used, a Some lock files weren’t fully recorded banner lists them, grouped by target:
  • A package unknown to your organization — that package is not recorded.
  • A lock written by an older CLI — the lock records no package versions, so it is ignored. Distribute to that target again to refresh it.
Needs a working Git connection — Syncing reads the repository through your Git provider. When the connection is missing or broken (for example an expired token), Sync from repository is disabled and its tooltip asks you to fix the Git connection first. See Git Repository Connection.

​
Record from Your Terminal

You can also send your local lock files to Packmind with the CLI. From the tracked branch, run:
Run from the repository root, it records every target; run from a sub-folder, only the targets at or below it. It finds the lock files through Git, so folders your .gitignore excludes are skipped. It works even when your lock edits are not pushed yet — but the next Sync from repository reads the locks on the remote branch and shows that state again, so push your changes. See Distribution Record.

​
Removing Packages

When you no longer need a package in your repository, you can remove it using either the app or the CLI.

​
Remove via the App

In the Packmind app, you can remove packages one-by-one from your distributions:
  1. Navigate to the Packages section
  2. Open the package you want to remove
  3. Click Remove from target and confirm the removal

​
Remove via the CLI

There are two ways to remove packages using the CLI: Option 1: Use the remove command
For example:
Option 2: Edit packmind.json and reinstall
  1. Open your packmind.json file
  2. Remove the package slug from the packages list
  3. Run the install command to update your repository:
This approach is useful when you want to make multiple changes to your package configuration at once.

​
Publishing to a Marketplace

Besides committing instruction files into your repositories, you can publish a package as a managed plugin to a marketplace so your team can install it directly in Claude Code or GitHub Copilot. See Publish to a marketplace for how to link a marketplace, publish packages, and monitor adoption.

​
Retiring a Published Plugin

If a package was published to a marketplace as a managed plugin, you can retire it through a dedicated flow that opens a deletion pull request in the marketplace repository. See Retire a plugin from a marketplace for the step-by-step process.