Skip to content

Releases: PackmindHub/packmind

Release v1.19.0

Choose a tag to compare

@github-actions github-actions released this 08 Oct 14:33

Changes

Added

  • A package can be released under a version: an immutable snapshot of the exact standard, command and skill versions it holds, with its name and description
  • The bar above the package's tabs shows its current version or Not released yet, cuts the next release, and lists past ones to read what each pinned
  • A package's Distribution now sends the version the page is read at: the release named in the bar above the tabs, or the package as it stands
  • Distributing a release sends the components it froze, deleted ones included, and writes that version into the repository's packmind.json instead of the wildcard
  • Reading the package as it stands still sends what it holds now, under *, which is what every distribution did before
  • Update N distributions is absent while a release is on screen: drift measures distance from the live package, not from the release being read
  • Update on a destination pinned to a version now moves it to the newest release instead of pushing the live package over its pin
  • A destination tracking * is left tracking it, so one Update can move a pinned repository and refresh a wildcard one in the same click
  • A repository with several destinations now receives all of them in its one commit; only the first one's files were ever committed, while every destination was reported as distributed
  • That same commit now marks every destination of the repository as distributed: only the first left Distributing now, and the others waited for ever on a job that had already run
  • Packages can be picked in the Context rail and deleted together, from the band under the list: the standards, commands and skills they held stay in the space

Changed

  • Add components moved from the package header onto the tab strip beside Components and Distribution: it has always served that tab alone, and now sits on the row it answers

Fixed

  • A clone URL embedding a token (https://oauth2:<token>@host) no longer leaks it into server logs or the Git connections page
  • Remotes stored with such a token are cleaned by a migration
  • On a self-managed GitLab, packmind install, init and track now use the connection configured for the instance instead of a CLI-managed one
  • That connection is matched by host, so a remote cloned over HTTPS or SSH reaches it alike
  • Adding a repository the CLI already recorded on that instance moves it under the connection with its targets and history, instead of refusing it as a duplicate
  • A CLI-managed connection is no longer listed once it holds no repository
  • A repository cloned over ssh:// or with a user in its URL no longer gets a CLI-managed connection of its own
  • A self-managed GitLab installed under a path such as /gitlab matches its connection: the path is no longer read as part of the group
  • Opening a component from All components keeps the rows already picked, and closing it goes back to that list rather than to the package carrying the component
  • Rule removals and edits submitted by a client that cannot know rule ids, such as the CLI reading standards from Markdown, are now matched by content instead of being dropped in silence
  • A rule removal or edit that matches no rule the standard holds now reports a conflict the client can resolve, instead of being accepted and applied to nothing
  • A GitLab repository in a subgroup keeps its full path (group/subgroup/repo) when tracked from the CLI, so a token or app connection links it instead of duplicating it
  • Git connection panel: a repository now shows one branch. change branch replaces it, refuses a branch that doesn't exist, and switching back brings that branch's history back (#902)
  • Applying a change that conflicts with the current content now says so instead of failing with a server error

Docker Images

The following Docker images have been built and pushed to Docker Hub:

  • packmind/api:1.19.0
  • packmind/frontend:1.19.0

All images are also available with the latest tag.

CLI 0.37.0

Choose a tag to compare

@github-actions github-actions released this 08 Oct 12:41

Packmind CLI 0.37.0

Installation

npm/npx

npm install -g @packmind/cli@0.37.0

Standalone Executables

Download the appropriate executable for your platform:

  • Linux x64: packmind-cli-linux-x64-0.37.0
  • Linux arm64: packmind-cli-linux-arm64-0.37.0
  • macOS arm64: packmind-cli-macos-arm64-0.37.0
  • Windows x64: packmind-cli-windows-x64-0.37.0.exe
  • Windows arm64: packmind-cli-windows-arm64-0.37.0.exe

Make the executable runnable (Linux/macOS):

chmod +x packmind-cli-*-0.37.0

Changes

Added

  • packmind install @space/my-package now installs a released version of a package rather than whatever the package currently holds, and writes that version into packmind.json. With no version after the slug it installs the latest release; @space/my-package:0.1.0 installs exactly that one; @space/my-package:* follows the package as it changes, which is what every repo did before. A version that was never released refuses the install and lists the ones that were, newest first — whether it was typed on the command line or written in packmind.json. A package that has never been released still installs as it stands, under *
  • A packmind.json written before this keeps saying * and keeps behaving exactly as it did: only a package named for the first time, or named with a version, is pinned. Each packmind.json in a repository carries its own versions, so two folders can be on two different releases of the same package
  • packmind install --upgrade moves every package packmind.json pins to a version onto that package's latest release, and writes the version it landed on. A package tracking * keeps tracking it, and is installed the way any install installs it, so its files do not go stale
  • packmind install --check-upgrades shows what --upgrade would change without writing or recording anything. It exits 1 when upgrades are available or a package could not be checked

Changed

  • packmind track and packmind init no longer send a provider vendor guessed from the remote URL: the server works it out from the remote, which is what lets a self-managed GitLab use its connection

Fixed

  • The CLI drops any token embedded in the repository's remote URL before sending it to Packmind

CLI 0.36.1

Choose a tag to compare

@github-actions github-actions released this 29 Sep 06:54

Packmind CLI 0.36.1

Installation

npm/npx

npm install -g @packmind/cli@0.36.1

Standalone Executables

Download the appropriate executable for your platform:

  • Linux x64: packmind-cli-linux-x64-0.36.1
  • Linux arm64: packmind-cli-linux-arm64-0.36.1
  • macOS arm64: packmind-cli-macos-arm64-0.36.1
  • Windows x64: packmind-cli-windows-x64-0.36.1.exe
  • Windows arm64: packmind-cli-windows-arm64-0.36.1.exe

Make the executable runnable (Linux/macOS):

chmod +x packmind-cli-*-0.36.1

Changes

Added

  • Errors are now recorded with their stack in ~/.packmind/error.log, and network failures with the request and cause behind them

Release v1.18.1

Choose a tag to compare

@github-actions github-actions released this 25 Sep 14:43

Changes

Hotfix release.

Added

  • Components can be deleted again, one by one or in bulk: in a package's Content list or the space inventory, tick rows and pick Delete from the selection bar's … menu, or use a row's own … menu
  • A git connection whose stored token can no longer be decrypted now shows a "re-authenticate" status instead of breaking the page

Changed

  • Skill files and package descriptions (new-package page, package edit form, Context drawers) now offer the WYSIWYG and Raw tabs that standards and commands already had
  • A rule's code examples list its languages side by side, each with its example count, instead of behind a select
  • A rule with no examples no longer opens on JavaScript: the language is taken from the rule itself, then from its standard, and otherwise left unchosen
  • A package's "up to date" destinations now say how old that claim is

Fixed

  • Security: creating or updating a git connection, or completing a GitHub App install, no longer sends the decrypted git token back to the browser
  • Git connections, GitHub Apps and AI providers whose stored secrets cannot be decrypted (for example after an encryption key change) now load, list and can be renamed instead of failing
  • A secret containing colons, such as a token ending with :, was stored in clear and then failed to decrypt on every read. It is now encrypted
  • Code examples being written are no longer lost when switching language or moving to the Linter tab, and Save stays disabled until an example has content
  • Errors caused by the request (not found, refused, already exists) in standards, commands, spaces, LLM, coding-agent and marketplaces now answer with their proper status instead of a 500
  • Marketplaces: a GitHub Copilot marketplace hosted outside GitHub, such as GitLab, no longer rejects every plugin
  • Marketplaces: when no marketplace descriptor is found, the error now names every path that was checked, not only the Claude Code one
  • Distribution no longer claims nobody checked a marketplace lately when it had been checked

Docker Images

The following Docker images have been built and pushed to Docker Hub:

  • packmind/api:1.18.1
  • packmind/frontend:1.18.1

All images are also available with the latest tag.

CLI 0.36.0

Choose a tag to compare

@github-actions github-actions released this 24 Sep 07:50

Packmind CLI 0.36.0

Installation

npm/npx

npm install -g @packmind/cli@0.36.0

Standalone Executables

Download the appropriate executable for your platform:

  • Linux x64: packmind-cli-linux-x64-0.36.0
  • Linux arm64: packmind-cli-linux-arm64-0.36.0
  • macOS arm64: packmind-cli-macos-arm64-0.36.0
  • Windows x64: packmind-cli-windows-x64-0.36.0.exe
  • Windows arm64: packmind-cli-windows-arm64-0.36.0.exe

Make the executable runnable (Linux/macOS):

chmod +x packmind-cli-*-0.36.0

Changes

Added

  • packmind packages move --<type> <slug> --to @space/package moves an artefact into one package and out of every other
  • packmind packages remove --<type> <slug> --from @space/package takes an artefact out of a package without adding it anywhere

Changed

  • Breaking: an artefact now belongs to one package. packmind packages add refuses one held elsewhere and points at packages move

Release v1.18.0

Choose a tag to compare

@github-actions github-actions released this 22 Sep 13:33

Changes

Added

  • The new navigation is now what a space opens on. Its sidebar carries three entries instead of one per kind of object: Context, where everything a coding agent reads is curated package by package; Distribution, the same graph read by destination rather than by package; and Review changes. The switch is on your profile page, under Navigation, and it now starts on. Turning it off restores exactly what was there, on every space at once, and the choice is held by the browser you make it in. Adding ?nav=today to any address opens that address in the previous navigation without touching the switch, and ?nav=plugin-first does the same the other way, which is enough to hand someone a link that lands them in either one.
  • The Distribution page of a space is now indexed by destination rather than by three tabs. A rail lists every repository this space's packages land in, each row carrying the branch, the packages that land there and a mark when something is behind or when the last distribution failed; selecting one opens it beside the rail. The search reaches a destination by its name, its branch or the name of a package that lands there, and under the field a pill per state counts what is not aligned and shows only those when clicked. Selecting several destinations turns them into one distribution rather than one per row, and the receipt that follows now names auto-update, which makes the same commit on a schedule. The page runs full width, as Context does: the surface is a rail beside a pane, and the heading it used to carry named what the sidebar already has highlighted

Changed

  • The bar that appears when rows are ticked now offers Unselect all beside the count rather than Clear at the far end. Both controls that change what is picked are together on the left, where the picking happened: Select all 10 and Unselect all read as one gesture and its opposite. Clear sat past the action button in the group a reader scans for what can be done with a selection, a viewport away from the count it undid, and was reported as missing by someone looking for it where they had made the selection. It also said nothing about what it cleared, which on a package's Distribution tab put it next to a second button of that exact name emptying the search field. Select all still disappears once everything shown is picked; Unselect all does not, since the bar is drawn only while something is picked. The change reaches the four lists that share the bar: a package's components, its destinations, the space inventory and a repository's install list
  • The drawer that adds components to a package can now be narrowed to one kind of component. It offers a chip per type the package is missing something of, the same control the package's own component list carries, counting what the filters below it left rather than the size of the space. A space whose loose components run into the hundreds arrived here as a single list of standards, commands and skills, and reaching the skills meant typing a word they happen to share. Ticking a row under one chip survives moving to another, so a package can be filled type by type in one pass, and the chips sit above the In no package filter rather than beside it, since the two ask different questions about the same list. The row holds still while that filter is flipped: a type whose candidates are all in a package already reads zero in place, and clicking it says so. That matters on the very first screen, since the drawer opens on the components in no package, and a space whose loose components happen to be all of one kind used to open on no type filter at all
  • Opening a repository from the Distribution page no longer puts a button strip along the bottom of the window. The repository pane used to end in one, pinned there, and on the full-bleed Distribution page that edge is the bottom of the page, beside the rail's own action bar: two rows of buttons under a surface that is otherwise all content. Most of the time the strip was not even offering anything, since it held the sentence "Select packages to distribute." next to a disabled button. Selecting rows now takes over the action slot the pane already has at its top right: it reads the number picked, offers Distribute selected for exactly those, and Clear selection beside it gives the slot back to Distribute repository. Nothing in the list moves when you tick a box
  • The rows of a repository's package list are now the height of the destination rows on a package's Distribution tab, 44 pixels against the 72 they were. The package description is gone from them: it took the row's second line, and it repeated itself once per target the package landed on, so a repository with five targets carried the same sentence five times down the list. The package's own screen still has it. Where a distribution stands and when it last moved are now side by side instead of stacked, and the per-row distribute button is the size the Context component list gives its own actions, which is what was setting the row height on its own
  • The Context rail now says which packages are not where they were sent. A package row carries a dot and a count when one of its destinations needs a hand: a repository whose copy is behind, or one whose last distribution failed. Hovering names those two separately, since a redistribution does not put right a push that broke. The dot is red when a distribution failed and orange when something is merely late, and packages that are up to date carry no mark at all. Under the search field, beside it because it narrows the same list, a toggle counts the drifted packages and shows only those when clicked; the package you have open stays listed and says why. The count is the one the package's Distribution tab shows once it is open, since both read the same selector
  • Filling a package in the Context navigation is now one control instead of two. Add components and Create sat side by side and asked you to know, before clicking, whether what you wanted already existed in the space, which is only answerable by opening the picker. They are now one split button: the wide half opens the picker, the chevron beside it holds the four ways of creating something new, under a heading that names them. When the space has nothing left to offer this package, the wide half has nothing to open and the control becomes Create a component on its own. The control also stays quiet on an empty package, where the panel below already invites you to fill it and now carries the only loud button on the screen. And an empty package in a space that owns nothing yet says so and offers creation, instead of telling you to pick from a space with nothing in it and sending you to a picker that pointed back at the same screen
  • "Add components" on a Context package now opens on the components no package carries yet, rather than on everything the space owns. Those are the ones being distributed for the first time, and the ones the picker is usually opened for: a component created a moment ago and not yet placed. They are listed newest first, the order the space component list uses under the same filter. A component that already ships from another package is a different proposition, since adding it means the same content ships from two packages that will drift apart, and it was one mis-tick away in a flat list that said nothing about where anything already was. The rest is one chip away, "In no package", the same chip the space component list filters by, and with it off every row names the packages already carrying it or says "No package", so shipping a component from two packages stays possible and stops being accidental. The search field now appears once the list on screen is long enough to need it rather than counting rows a filter is hiding
  • The Create menu on a Context package is now organised by who writes the artifact rather than by which kind it is. Seven entries under three headings become five: your agent, samples, a blank standard form, a blank command form, and an import from your machine. Three of the old entries were the same instruction sheet repeated once per type, since "install the CLI and run a slash command" does not vary by type; they are now one entry whose dialog lists the command for each. The menu no longer asks which kind of artifact you want before asking how you want to write it, which is the one part a reader arriving without a decision cannot answer. It also stops growing as Packmind gains artifact types: what each entry covers is read from a single registry, so a new type lengthens a description instead of adding a heading and two rows, and the manual entry folds its types behind one row once there are more than two of them
  • Packmind can now verify the SMTP server's TLS certificate, which it previously skipped on every connection: set SMTP_TLS_REJECT_UNAUTHORIZED=true to turn it on, off being the default so nothing breaks on upgrade. Rotate SMTP_PASSWORD either way, since it was being written to the logs in clear text on every send

Fixed

  • A git operation that fails for a reason you can do something about now says so, instead of answering "Internal server error". A connection or repository that is not there, a display name already taken, a connection with no token configured, a repository already tracked on another branch: every one of these reached the browser as a blank 500, with a stack written to our logs as though Packmind had broken, because the failure carried nothing saying what kind of failure it was. They now answer with the status they always meant — not found, refused, already exists — and carry their own sentence, so the page can tell you what happened rather than showing a generic error

  • GitHub's rate limit and GitHub's refusals are no longer reported as the same thing. Both arrive as a 403, and Packmind told them apart by looking for "403" inside the text of the error, which cannot separate ...

Read more

CLI 0.35.1

Choose a tag to compare

@github-actions github-actions released this 10 Sep 16:49

Packmind CLI 0.35.1

Installation

npm/npx

npm install -g @packmind/cli@0.35.1

Standalone Executables

Download the appropriate executable for your platform:

  • Linux x64: packmind-cli-linux-x64-0.35.1
  • Linux arm64: packmind-cli-linux-arm64-0.35.1
  • macOS arm64: packmind-cli-macos-arm64-0.35.1
  • Windows x64: packmind-cli-windows-x64-0.35.1.exe
  • Windows arm64: packmind-cli-windows-arm64-0.35.1.exe

Make the executable runnable (Linux/macOS):

chmod +x packmind-cli-*-0.35.1

Changes

Fixed

  • Commands gated by edition no longer claim a feature is missing from the Packmind Community Edition when the 404 they received meant something else. On an Enterprise deployment a deleted or mistyped organization, space or resource answers that same status, so playbook submit and the other gated commands announced the feature did not exist to users who were paying for it. The edition now comes from the server itself, so the Community Edition message only appears when the server states it, and a server too old to state its edition yields an error naming both possible causes instead of picking one
  • git track and git untrack no longer report that repository tracking "is not available for your account". No account setting gates those routes — a 404 there means a server that predates repository tracking — so the message now points at the server and at the person who can update it

Release v1.17.0

Choose a tag to compare

@github-actions github-actions released this 02 Sep 12:03

Changes

Added

  • A standard submitted from the CLI can now carry its scope. A ## Scope section in a .packmind/standards/*.md file is read as the standard's glob patterns, so the coding agents that filter on file patterns get that filtering from a CLI publish instead of only from the web app. Patterns can be written comma-separated on one line or one per bullet. Standards distributed to .packmind/standards/ now render their scope in that same section, so editing the file and submitting it back keeps the scope instead of dropping it. Previously the heading and its patterns silently became part of the description
  • packmind git track no longer sets the tracked branch to HEAD when no branch is checked out — a rebase in flight, a commit checked out directly, or a CI job on a pull request merge ref. It reports that no branch is checked out and names --branch <name> as the way to track one from there; git info and install describe the same state instead of claiming you are on a branch called HEAD (#758)
  • Packmind now tells you when the branch it tracks has been deleted — the state a merged pull request leaves behind, in which nothing is recorded any more and nothing says so. The tracked branch is checked against the Git provider and flagged as "Branch deleted" on the repository cards under Settings → Targets and on the tracked-branch list of the Git connection panel, with the consequence spelled out and the recovery being to move tracking to a branch that exists. packmind git info reports the same state from the CLI, and packmind install no longer tells you to switch to a branch that is not there. Both web app markers need a Git connection to ask the provider with, so a repository Packmind knows only from packmind-cli install is covered by the CLI messages alone (#758)
  • Check what Packmind tracks for the repository you are in with the new packmind git info command: it names the tracked branch, warns when the branch you are on is not the tracked one — distributions from there are not recorded — and tells you how to start tracking when the repository is not tracked at all. Reading the state needs no admin rights
  • A marketplace with no Packmind plugin yet now carries the publish action instead of describing it, in one of three variants read from your data: the packages that can become plugins are listed with their space and their commands and skills, and each can be published from there with this marketplace already selected in the dialog; when none of your packages can become a plugin, the page states that a plugin needs at least one skill or command and links to each package so one can be added; when there is no package at all, it links to package creation in the default space. All three name the repository and branch behind the marketplace, so a marketplace linked to the wrong repository shows up immediately. When the marketplace descriptor already lists plugins Packmind does not manage, the page scopes its message to Packmind and counts those plugins instead of claiming the marketplace is empty.
  • The marketplace page now checks the Git connection behind the marketplace when you open it, and leads with an alert whenever that connection is what blocks you: it names the connection, states the failure and the recovery in the same words as the Git page, and offers the repair before the re-check. When the credentials work again but the marketplace still carries the recorded authentication failure, the alert offers to reconcile it instead. A check that gets no answer stays silent rather than blaming the connection for a failure Packmind could not attribute.
  • Packmind now renders into Kiro, which joins the other coding agents under Settings → Distribution → Rendering and is unchecked by default. Standards become one steering file each under .kiro/steering/, carrying their scope as a fileMatch inclusion so the Kiro IDE applies a scoped standard only to the files it covers — the Kiro CLI loads every steering file regardless of inclusion mode, so scoping is not narrowed there. Skills become one directory each under .kiro/skills/, and commands are not rendered since Kiro has no command directory — they stay reachable as @.packmind/commands/{slug}.md. Nothing lands outside .kiro/, and a removal or a cleanup only ever deletes the packmind-standard-* files Packmind named, never the steering files you wrote yourself. packmind config agents lists Kiro and detects it from a .kiro/ directory, and standards rendered into .kiro/steering/ parse back with their scope, so playbook diff and playbook add round-trip them like the Claude- and Cursor-rendered ones

Changed

  • Breaking (CLI): packmind track and packmind untrack moved under the git command and are now packmind git track and packmind git untrack, joining packmind git info. Both flag spellings moved with them (git track --branch <name>, git track --update, and the two combined). The old names still parse but exit with an error naming their replacement, so scripts and CI jobs calling them must be updated
  • The marketplace list now names the Git connection behind each marketplace ("via Acme GitHub") and states its health in words, replacing an 8px dot only readable on hover. Severity follows who has to act: a credential that stopped working or a transient failure is a warning an admin can clear from Packmind, while a repository that is gone or a descriptor that does not parse is an error nobody clears from here. The tooltip names the connection at fault and the recovery instead of restating the state.
  • A disabled Sync button now names its cause: authentication when the connection's credentials stopped working, the repository when it can no longer be reached, the descriptor when it does not parse. It previously offered "Marketplace is unreachable or its descriptor is invalid" in every case, and never mentioned the one an admin can clear themselves. "Nothing to sync" still wins when no plugin has drifted.
  • The Overview tab of a marketplace plugin now separates what the plugin ships from what it does not. Commands and skills are listed under "In this plugin"; the package's standards move to a "Not shipped" section stating that standards are distributed to repositories, not to marketplaces, with a tooltip explaining that the Claude Code plugin format has no slot for instruction files and pointing to repository distribution instead. Previously all three were listed together under "Bundled artifacts", which suggested standards were published to the marketplace when they never are.
  • The "Publish to a marketplace" dialog now states what a publish will actually put on the marketplace — "Publishes 2 commands and 1 skill. 3 standards stay in the package: plugins don't carry standards." Previously it mentioned standards only when it refused a standards-only package, so a mixed package was published minus its standards without warning.
  • On a marketplace with no plugin published yet, a publishable package now reads "2 skills, 3 commands · 4 standards not shipped" instead of listing the three counts together, so the standards are not presented as part of what the Publish button would send.
  • The Packmind CLI is now packmind everywhere. The installer and packmind update maintain one real executable under that name and turn the older packmind-cli into a symlink to it, so packmind-cli keeps working and keeps receiving updates while printing a deprecation warning — it goes away in a later release. CLI messages now name the executable you actually invoked rather than hardcoding one, and the web app's setup, distribution and auto-update screens, the GitHub Actions workflow they generate, the documentation and the default packmind-onboard and packmind-update-playbook skills all say packmind. Repositories still on a CLI older than 0.34.0 keep receiving the skill wording that matches the executable they have (#772)

Fixed

  • packmind git track --branch <name> no longer accepts a branch that does not exist. The name is checked against the branches of your repository — local ones and those already fetched from the remote — and a name Packmind cannot find is refused with the spelling and git fetch as the two things to check. A typo used to be tracked silently and only surfaced later, as distributions that were never recorded (#758).
  • A connection created through the GitHub App now keeps the name you typed. The name travels with the install and is applied when the connection is created, including on-prem where the app is registered first and the name has to survive two round trips to GitHub. Previously it was dropped the moment you left for GitHub and every App connection came back as "Unnamed GitHub connection". If the name was taken by another connection while you were on GitHub, the connection is still created — unnamed, ready to be renamed — rather than the install failing (#743).
  • A Git connection whose credentials no longer work can no longer be picked in the "Link a marketplace" drawer. Every connection is checked when the drawer opens, and one that cannot authenticate stays listed and named but is disabled, with the failure and a link to repair it under the field; it is no longer auto-selected either when it is the organization's only connection. Previously it passed the drawer's filter on having stored credentials and dead-ended on a repository list that failed to load (#751).
  • packmind plugins render on a package that holds only standards now states why it cannot render, instead of failing with an opaque server error. The reason — a plugin needs at least one skill or command — was already carried by the error but never reached the CLI, which reported "Internal server error" and left nothing to act on. The marketplace publish path already explained itself; the CLI is the one route with no gate in front of it (#799)
  • Editing a standard no longer marks the plugins published from its packa...
Read more

CLI 0.35.0

Choose a tag to compare

@github-actions github-actions released this 02 Sep 12:40

Packmind CLI 0.35.0

Installation

npm/npx

npm install -g @packmind/cli@0.35.0

Standalone Executables

Download the appropriate executable for your platform:

  • Linux x64: packmind-cli-linux-x64-0.35.0
  • Linux arm64: packmind-cli-linux-arm64-0.35.0
  • macOS arm64: packmind-cli-macos-arm64-0.35.0
  • Windows x64: packmind-cli-windows-x64-0.35.0.exe
  • Windows arm64: packmind-cli-windows-arm64-0.35.0.exe

Make the executable runnable (Linux/macOS):

chmod +x packmind-cli-*-0.35.0

Changes

Added

  • Kiro is now a selectable coding agent. packmind config agents offers it, a repository holding a .kiro directory is detected as a Kiro workspace, and install renders standards as steering files under .kiro/steering/ and skills under .kiro/skills/. Commands are not rendered — Kiro has no command directory — and cleanup only ever removes the packmind-standard-* files Packmind created

Changed

  • The command is now packmind. The installer and packmind update maintain a single real executable under that name, and the older packmind-cli becomes a symlink to it — the two swapped roles, so packmind-cli keeps working and keeps receiving updates instead of silently freezing at the version it was installed at. Running it now prints a deprecation warning: it will be removed in a later release, so scripts and CI jobs calling packmind-cli should be moved over
  • Messages now name the executable you actually invoked instead of hardcoding packmind-cli. The log prefix, --help usage output, --version and every suggested command follow the name you typed, so a suggestion can always be copied and run as-is. Previously the CLI could greet you as packmind-cli and then tell you to run packmind init
  • The default skills ship a 0.35.0 instruction set using the packmind command. Rendered skills name the executable the target installation actually has, so an install older than 0.24.0 keeps being told to run packmind-cli

Fixed

  • A failed packmind update on Windows no longer suggests sudo packmind update. The Windows shells have no sudo, and the usual cause there is not permissions at all — the running executable cannot be replaced, which elevation does not fix. Windows now gets its own advice: close any other running packmind process, then re-run from an Administrator terminal. The underlying error is now kept in the message on every platform, and the sudo suggestion is unchanged on macOS and Linux
  • A scope holding a brace group (**/*.{ts,tsx}) is no longer split in two. playbook add and playbook diff read it as **/*.{ts plus tsx} whenever the agent rendered the scope as a YAML array, and reported a scope change that was not one
  • plugins render no longer calls every plugin a Claude one. A render from .claude-plugin/plugin.json now tells Packmind which vendor to target, the success line names the manifest it actually updated, and the skipped-standards notice and --help stop assuming Claude

CLI 0.34.1

Choose a tag to compare

@github-actions github-actions released this 25 Aug 11:37

Packmind CLI 0.34.1

Installation

npm/npx

npm install -g @packmind/cli@0.34.1

Standalone Executables

Download the appropriate executable for your platform:

  • Linux x64: packmind-cli-linux-x64-0.34.1
  • Linux arm64: packmind-cli-linux-arm64-0.34.1
  • macOS arm64: packmind-cli-macos-arm64-0.34.1
  • Windows x64: packmind-cli-windows-x64-0.34.1.exe
  • Windows arm64: packmind-cli-windows-arm64-0.34.1.exe

Make the executable runnable (Linux/macOS):

chmod +x packmind-cli-*-0.34.1

Changes

Added

  • playbook add and playbook submit now read the ## Scope section of a .packmind/standards/*.md file as the standard's glob scope. Patterns go comma-separated on one line or one per -/* bullet, and both forms are stored as a comma-separated list. Rules are still found with or without a ## Rules heading, including when they follow the Scope section. playbook diff reports scope changes for these files like it already did for .claude/.cursor standards. The section used to be swallowed into the description
  • New git info command reports whether Packmind tracks the current repository and on which branch. When the tracked branch is not the one checked out, it warns that distributions from here are not recorded and points to git track --update. When the repository is not tracked, it proposes git track to track the current branch. Available to every member, not only organization admins.
  • plugins render now recognizes a local .github/plugin/marketplace.json file, in addition to the existing .claude-plugin/marketplace.json, and renders a GitHub Copilot plugin into it instead of a Claude Code one. Which file is present determines the target — a workspace can only be one or the other, never both, and if both exist .claude-plugin/marketplace.json wins.

Changed

  • Change track command to git track command
  • Change untrack command to git untrack command
  • --help now lists the old track and untrack as [Removed] Use "git track" instead, matching what running them says. They used to be listed as [Deprecated] while answering "has been removed".
  • git track --help no longer describes --update as moving tracking to the current branch, which stopped being true when --branch shipped. Both entries now say the two options combine.

Fixed

  • git track no longer tracks a branch called HEAD when no branch is checked out. A detached HEAD — mid-rebase, on a commit, or in a CI job on a pull request merge ref — is reported as such, with --branch <name> named as the way to track a branch from there anyway. git info and install stop claiming you are "on" a branch in that state too, and git info on an untracked repository offers git track --branch <name> instead of offering to track HEAD. git untrack is unaffected: it takes no branch.
  • git info and install no longer describe a deleted tracked branch as if it were still there. git info reports that the branch is not in the repository — deleted after a merge, or never fetched here — and states that nothing is recorded anywhere until tracking moves, instead of only saying distributions "from here" are not recorded. install stops telling you to switch to a branch that does not exist and names git track --update instead.
  • git track --branch <name> now refuses a branch that does not exist in the repository instead of tracking it silently. A typo used to be accepted and only showed up later as distributions that were never recorded. Local and fetched remote branches both count, and the error points at git fetch for a branch that only exists on the remote.
  • git track --branch <name> no longer refuses a branch that does exist. The check read git branch -a, whose decorations were taken for part of the branch name: a branch checked out in a linked worktree is listed as + feature, and color.ui = always or column.ui = always colorize and columnize the listing even through a pipe. Any of the three made every --branch fail with "does not exist", pointing at a spelling mistake and git fetch that would not have helped. Branches are now read from git's ref list instead of its human-facing listing, which also fixes git info and install claiming a tracked branch was deleted in those repositories.
  • Messages left pointing at the removed track command now name its replacement: install on an untracked repository, the "nothing is tracked yet" error and the server-side equivalent all say packmind git track.
  • git track --branch <name> on a repository tracked elsewhere now suggests git track --update --branch <name>. It used to suggest a bare git track --update, which moves tracking to the checked-out branch instead of the requested one.
  • track --remove gets the same migration message as track, naming git untrack, instead of failing with a raw "unknown arguments" parser error.
  • Running a command outside a git repository no longer claims lint must be run in a Git repository — git info, git track and install share those git helpers — and no longer prints git's own fatal: not a git repository line after the explanation.
  • plugins render no longer crashes on a marketplace or plugin manifest file saved with a UTF-8 byte-order mark (common from Windows editors) — the BOM is stripped before parsing instead of surfacing as a raw SyntaxError.
  • plugins render reports a clearer error when no supported manifest is found, naming all three checked paths (.claude-plugin/marketplace.json, .github/plugin/marketplace.json, .claude-plugin/plugin.json), and now also reports a clean error — instead of crashing — when the manifest it does find is not valid JSON.

Removed