Create and edit a pack

A pack's source lives in one of two places, depending on who owns it: a git repo you maintain, or an org's internal pack builder. Either way, you never edit the copy baselane vendored into a consuming repo. You edit the source and publish a new version.

Where edits happen

Say your org shares a security-review pack across every repo it owns. Its source is a normal git repo: a pack.json at the root plus its skill folders. To change it (for example, to tighten a review checklist or add a new hook), edit those files directly, commit, and tag the release:

git commit -am "security-review: flag hardcoded AWS keys"
git tag v1.1.0
git push --tags

Then publish that tag under the pack's name (see publish a pack):

baselane publish @acme/security-review --source github:acme/security-review-pack --ref v1.1.0

If the pack instead started life inside an org's portal, built with the pack builder and not hand-written, its source is the builder form, not a git repo you clone. Open it from the org's packs list, edit the same fields (agents, commands, hooks, skills), and publishing a new version happens from there directly, no separate baselane publish step.

Example

The full loop for a git-sourced pack, edit to publish:

git commit -am "security-review: flag hardcoded AWS keys"
git tag v1.1.0
git push --tags
baselane publish @acme/security-review --source github:acme/security-review-pack --ref v1.1.0

Every repo that still has 1.0.0 as its exact recorded version (its pin) now shows as behind.

The versioning loop

A published version is immutable the moment it's published: @acme/security-review@1.0.0 will always resolve to exactly the bytes published under that name. There's no in-place edit. Editing means publishing 1.1.0 and leaving 1.0.0 alone. Every repo that installed 1.0.0 keeps running it, unchanged, until it's explicitly moved forward.

That's what makes drift and fleet tracking work: once 1.1.0 is published, every repo still pinned to 1.0.0 shows up as behind on the fleet board, with a one-click PR to bump it. Nothing is force-upgraded. A repo stays on its pinned version until that PR lands, or until someone runs baselane update by hand.

What you never edit

The copy of a pack's skills sitting inside .claude/ in a repo that installed it is a vendored, generated artifact, not the source.

Hand-editing it directly does nothing for the next repo that installs the pack, and it shows up as drift the next time anyone runs baselane drift, because the vendored copy no longer matches what the pinned version would produce. Fix it in the pack's source instead, and publish a new version. The vendored copy updates itself the next time the repo bumps.