CLI · Packs

Packs are Kirimana’s extensibility primitive: a versioned, hash-verified bundle of contracts, patterns, locale rules, and templates that a community or organisation can author once and install anywhere. The kiri pack verbs cover the full lifecycle — scaffold, validate, install, list, publish.

kiri pack init

Scaffold a new pack from the in-repo template.

Usage: kiri pack init [OPTIONS] NAME

NAME is the new pack directory name (kebab-case). --dir chooses where to create it (default: ./packs/<name> inside the kirimana repo, otherwise ./<name>).

kiri pack init acme-retail-domain

kiri pack validate

Validate a pack’s manifest and file tree.

Usage: kiri pack validate [OPTIONS] PACK_PATH

Flag	Description	Default
--strict	Apply the official-registry bar: at least one source/silver/gold artefact plus non-empty domains and classifications	off

Run plain validate while iterating; run --strict before publishing anywhere shared.

kiri pack install

Install a pack from a local path, a git URL, or a GitHub Release.

Usage: kiri pack install [OPTIONS] SOURCE

The SOURCE prefix decides the transport:

Source shape	Behaviour
gh:owner/repo@version	Download the GitHub Release published at tag pack-v<version>
http(s)://…, git@…, ssh://…	Git clone (pin with --ref — branch, tag, or SHA; default main)
anything else	Treated as a local path

Flag	Description	Default
--install-dir	Override the install directory	~/.kirimana/packs/
--ref	Git ref when installing from a git URL	main
--force	Overwrite an existing install of the same pack	off
--token	GitHub token for gh: installs of private releases. Defaults to $GH_TOKEN, then $GITHUB_TOKEN; public releases need none.

kiri pack install gh:acme/kirimana-packs@1.2.0
kiri pack install ./packs/acme-retail-domain

kiri pack list

List installed packs.

Usage: kiri pack list [OPTIONS]

--verify re-hashes each installed pack against its recorded checksum and flags tampering — packs are content-addressed, so a modified install is detectable.

kiri pack publish

Publish a pack as a GitHub Release.

Usage: kiri pack publish --repo <owner/name> [OPTIONS] PACK_PATH

Flag	Description	Default
--repo	GitHub repository slug to publish to; the release is created at tag pack-v<version> — required
--out-dir	Where the tarball + .sha256 sidecar are written	<pack-path>/dist/
--token	GitHub token; defaults to $GH_TOKEN, then $GITHUB_TOKEN. Required unless --dry-run.
--target-commitish	Commit/branch the release tag points at	repo default branch HEAD
--force	Replace an existing release at the same tag. Releases are immutable by convention — bump the version instead unless you know what you’re doing.	off
--dry-run	Build the tarball + .sha256 locally and skip all GitHub calls — useful for verifying determinism and inspecting contents	off
--skip-validate	Skip kiri pack validate before tarballing. Discouraged — publishing a broken pack burns the version forever.	off

The publish pipeline is deterministic: the same pack tree produces the same tarball and hash, which is what kiri pack list --verify checks against after install.

kiri pack validate ./acme-retail-domain --strict
kiri pack publish ./acme-retail-domain --repo acme/kirimana-packs --dry-run
kiri pack publish ./acme-retail-domain --repo acme/kirimana-packs

Where packs plug in

Installed packs extend existing verbs rather than adding new ones — for example, locale packs feed classification (kiri inventory pre-classify --locale-pack, see the lineage page), and pack-provided contract patterns and templates become available to the scaffolding verbs. Pack contents follow the same governance rules as project-authored YAML: classifications, domains, and ownership are validated on install, and --strict publishing enforces that a pack ships them.