Agent Tool Packager

Current Version: v0.2.3

Agent Tools Inspiration

If you have ever watched a James Bond film, you know the pattern: before the Aston Martin leaves the garage, someone has already fitted the ejector seat. If you prefer Jason Bourne, you know the other pattern: in a strange city, a cash stash and a clean passport can matter as much as muscle memory. Different franchises, same truth—the mission goes better when the right gear is already in place.

… read the full story

Agent Tool Packager (ATP) is a command-line tool (atp) that standardises how you build small packages of agent-facing material—rules, prompts, skills, hooks, MCP servers, commands, and related payloads—and install them into git projects for the coding agent you use.

If you are new here, you are in the right place: one workflow lets you author, validate, catalog, and install agent tools without repeating vendor-specific copy steps by hand.

What problem does ATP solve?

Modern AI coding assistants (Cursor, Claude Code, Gemini CLI, Codex CLI, Kiro, and others) each expect files in different places—project rules, skills directories, MCP JSON, hook configs, and so on. ATP gives you:

A single package format (atp-package.yaml plus staged payloads) that describes what you ship.
A local Station—your machine’s catalog and configuration hub—where published packages live.
A per-project Safehouse (.atp_safehouse) that records what is installed in each repository and which agent that project uses.
Installer logic per agent so the same catalog package lands in the right paths for Cursor, Gemini, Codex, Claude, etc.

In short: define packages once, publish them to your Station, then install into each repo’s Safehouse for the agent you nominate.

The journey in steps

Step	What you do	Link
1	Learn the vocabulary	Manual: Terminology
2	Get going	Manual: Getting started
3	Author a package	Manual: Authoring packages
4	Agent to the field…	Manual: Safehouse & agent
5	Package management	Manual: Install & manage
6	Example package authoring	Manual: Example Skills Pack
7	Configuration details	Manual: Configuration details

End-to-end narrative index: Manual home.

Key features at a glance

Multi-type packages

Modern packages use root type: Multi with a parts array. Each part has its own type (Rule, Prompt, Skill, Hook, Mcp, Command, Experimental), usage lines, and optional components (files) and bundles (executable trees). Legacy single-type packages remain supported. Multi-part staging uses paths like part_{index}_{Type}/ inside stage.tar so parts do not overwrite each other.

Validation at author time and install time

atp validate package checks your working tree: manifest, non-empty stage.tar, Multi vs legacy rules, duplicate basenames across parts, and consistency with staged files.
atp catalog add package refuses to publish until validation passes.
atp install runs validation against the catalog extract before changing the project—same intent as atp validate catalog-package on a Station package directory.

Install scopes

Control where material lands:

--project / --station — prompt-like files (rules, skills, etc.) toward project agent dirs vs user/Station-wide layout per agent-paths.
--user-bin / --project-bin — bundle executables in shared user layout vs project Safehouse bin layout.

Default behaviour is typically project scope for prompt matter and user-bin for executables—see the install manual for details.

MCP and hooks merges

Packages with Mcp or Hook parts may merge into agent-specific JSON or settings (for example Cursor .cursor/mcp.json and .cursor/hooks.json, Gemini .gemini/settings.json, Codex .codex/config.toml and .codex/hooks.json). If an existing server or hook identity conflicts with different content, install fails until you choose --force-config (take the package version) or --skip-config (skip those merges for this run). --verbose or DEBUG containing atp can add diagnostic detail.

Multiple agents, one catalog

The Station’s agent-paths in atp-config.yaml maps each supported agent id (cursor, claude, gemini, codex, kiro, …) to home and project paths and subfolders for rules, prompts, skills, hooks, commands, etc. atp agent handover to <name> switches the project’s agent and re-applies installs where supported—verify files after switching.

Install the CLI

npm install -g @wazzamo-agent-tools/packager
atp --version

Use a current Node.js (the upstream project pins a version; Node 24+ is typical). Primary use is on UNIX-like systems (Linux, macOS, BSD).

Minimal command sequence

atp station init
cd /path/to/your/package-dir
atp create package skeleton
# … edit metadata and parts (see authoring manual) …
atp validate package
atp catalog add package

cd /path/to/your/git-project
atp safehouse init
atp agent cursor
atp install your-package-name

Example package authoring

Example skills pack

This example is in the Agent-Tools/Packager Github repo but here it is again, with some explanation.

The upstream repository includes example-skills-pack/ with a pack.sh script that builds demo packages. Running it from that directory publishes to your user catalog—pair it with atp catalog list and a test project with Safehouse + agent + atp install to see skills appear under the agent’s skills directory (for example .gemini/skills/ for Gemini CLI).

See this page for a break-down of the Example skills pack that you can copy and use as a template.

Reference documentation

Resource	Description
Manual index	Full manual table of contents
Releases	Summaries of each CLI release (links to full notes on GitHub)
Configuration overview	Station layout, catalog, Safehouse manifest, naming
Upstream project	Source repository and issue tracker

Agent Tool Packager is published as @wazzamo-agent-tools/packager. Documentation on this site summarises the Agent-Tools / Packager manuals and configuration reference for newcomers and day-to-day use.