Splunk app packaging

Skill cmwema/splunk-expert/skills/splunk-app-packaging

Package a Splunk app or TA into a clean, installable .tar.gz for Splunkbase or manual distribution. Trigger for: packaging a Splunk app, building an installable tarball, app release / version bump before shipping, fixing a bloated or invalid package (accidentally includes .git, node_modules, or a nested self-included copy), deciding what to exclude from a shipped package (dev-only docs, build artifacts, local/), verifying package contents before Splunkbase submission or manual install. Default: Splunk Enterprise 9.x.From its SKILL.md

Install

npx -y skills add cmwema/splunk-expert --skill splunk-app-packaging

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.1 KB, as published. Nobody here has run it

Splunk App Packaging

Router only. Read references/packaging.md for all packaging tasks.

Routing

Task	Action
Build an installable .tar.gz, decide what to exclude	Read `references/packaging.md`
Fix a bloated/invalid package (nested copy, `.git` included)	Read `references/packaging.md`
Version bump + changelog as part of a release	Read `references/packaging.md`
TA scaffolding, CIM mapping, REST handlers, AppInspect itself	Defer to `splunk-ta`

Shared conventions

The tarball's top-level directory must exactly match [package] id in app.conf.
Always exclude: .git/, local/, __pycache__/, *.pyc, .DS_Store, any existing package archive already sitting in the app root.
Never build the archive from inside the app directory with the output written into that same tree — build to a scratch path first, then move it into place, to avoid nesting the archive inside itself.
Bump [launcher] version in app.conf (and any changelog the project keeps) as part of the same release, before packaging — check the project's own git history for its established version/changelog convention rather than assuming one.
Verify the built tarball's contents (tar -tzf) before shipping: exactly one top-level directory, no VCS metadata, no dev-only docs, size in a plausible range for the app's actual content.

Output format

Fenced bash for build/verification commands, ini for app.conf version edits. ⚠️ callouts when a step is easy to get destructively wrong (building in-place, deleting instead of excluding).