A Clawx package is a Markdown file with YAML metadata. The Markdown body becomes the system prompt for an agent CLI such as Claude Code, Codex, OpenCode, Gemini, or Antigravity. Clawx fetches the package from a registry, verifies its SHA-256 hash, shows what it is requesting permission to do, asks for approval, runs it, and records the execution.
The idea came from repeatedly writing the same operational prompts: configure CI, inspect a repository, install and verify a tool, scaffold project conventions, or apply a multi-step migration. Shell scripts are deterministic but often brittle across projects. Raw prompts are adaptable but easy to lose, change silently, or execute without much structure. I wanted to explore a point between those two.
Packages can declare parameters, dependencies, required environment variables, and allowed tools. Registries can be Git repositories or small HTTP servers. There is also an offline workspace scanner that looks at manifests and infrastructure files and recommends relevant packages.
One important limitation: tool restrictions are enforced by Clawx at the subprocess boundary when using Claude Code. For the other providers, the declared tools are currently shown during approval, but enforcement depends on that provider’s own sandbox and permission model. I do not want to imply a stronger security boundary than the implementation provides.
You can install it on macOS or Linux with:
``` curl -fsSL https://raw.githubusercontent.com/debarshibasak/clawx/master... | sh ```
Then, assuming one of the supported agent CLIs is installed:
``` clawx list clawx info gitignore-gen clawx run gitignore-gen clawx history ```
The project is written in Go and is still early. I’m particularly interested in feedback on whether agent tasks are useful as “packages,” what the trust model should look like, and where this abstraction breaks down compared with scripts, configuration management, or provider-specific skills.