installable-tools

installable-tools — validate before you promote

A thing Pulp can install is not "done" when the code compiles or when it works in your repo checkout. It is done when a user who installed Pulp can install it, use it, and uninstall it — from their own project directory, not the Pulp source tree. Ship the README only after that is proven.

Why this skill exists

pulp tool install trace-processor shipped as a first-class tool (with a whole showcase README promoting it) but worked only inside a Pulp git checkout: the registry is resolved by walking up from cwd for tools/packages/tool-registry.json, which installed users don't have, so it errored Tool registry not found. It got that far because every validation ran from inside the repo. Uninstall had a second latent problem — it never validated the tool id, so uninstall ../../x could delete outside the managed tree.

Both are the kind of gap that only a from-the-user's-seat, full-lifecycle test catches. This skill is that checklist.

The bar (all four, every time)

1. Install from OUTSIDE any checkout. cd to a scratch dir whose parents contain no tools/packages/tool-registry.json, point PULP_HOME at a throwaway dir, and run the install with the user-facing pulp (the installed binary or a fresh ./build/pulp), not a raw in-repo build invocation.
2. Use it. Confirm the installed artifact actually runs / is found by the command that consumes it (pulp trace query, etc.).
3. Uninstall from OUTSIDE any checkout. It must remove exactly what it installed, name the path it deleted, and leave a clear message when nothing matched.
4. Prove uninstall is safe. A hostile id (.., ../x, a/b, absolute path, empty) must be refused before any deletion, with a plant-a-victim test asserting nothing outside the managed tree was touched.

Only after 1–4 pass do you write or update the README/docs that tell users to run the command.

Registry resolution (why standalone works)