b10x | Agent Pluginsb10x in the source-owned Agent Plugins documentation.Agent Pluginsreferenceagentpluginsreferenceadopterdeveloperbuild-agent-systemstry-spec-driven-developmentreference

b10x

ReferenceAgent Plugins

ForAdopter · Developer

PreviewPublic

Source & revision

agentplugins/website/docs/plugins/b10x.md · 25dedb81f34b

Use this plugin as the marketplace front door. It sets up and upgrades the other plugins and the binaries they drive, selects the smallest specialist for a request, provides a map of public Beyond10x resources, and helps create plugins that keep their core capabilities portable across Codex and Claude Code.

It provides:

• init and upgrade skills that drive the b10x binary: it reads both hosts, the binaries on PATH and project settings, asks which products to have, lists every change and applies it after confirmation (see Install);
• a session-start hook that runs b10x check and prints one line per plugin/binary drift;
• a Claude Code PreToolUse hook on Bash that runs b10x guard bash and refuses the commands the guard is configured to refuse;
• a routing skill for selecting aep, ess, worktree or connectors, which reaches every skill of every plugin and sends upgrades to the upgrade skills;
• direct links to public product guides, command references, plugin references, and source;
• an authoring-plugins skill for creating or porting dual-harness plugins.

The b10x binary

command	does
b10x init <product>… [--method cargo|prebuilt] [--host claude|codex|all] [--json] [--out <file>]	plan the named products: plugins and CLIs installed or brought current; nothing else touched
b10x upgrade [<product>…] [--method …] [--host …] [--json] [--out <file>]	the same for installed products (all, or the named ones)
b10x setup apply --plan <file> --yes	refuse a stale plan, snapshot every file it changes, run the actions, check that the result converged
b10x setup undo [<snapshot>]	restore the files the newest (or named) snapshot holds, then refresh both hosts' marketplaces
b10x setup plan [--products …] [--host …] [--method …] [--json] [--out <file>]	the whole desired state at once: the named products installed, other catalog plugins removed
b10x skill <plugin>[:<skill>]	list an installed plugin's skills, or print one — usable before a restart
b10x setup guide	print /b10x:init, for an agent that has no plugin yet
b10x check	the session-start drift check; prints only problems, refreshes the newest releases at most daily
b10x install <cli> [--tag <tag>] [--dir <dir>] [--method cargo|prebuilt]	install one CLI (the local pin, else the repository's pin, else the newest)
b10x pin <cli> <x.y.z|x.y>	pin a CLI for this repository in b10x.toml
b10x unpin <cli>	remove that pin
b10x guard bash	the PreToolUse hook: read one event on stdin, exit 0 to allow, exit 2 to refuse with one line naming the replacement

The CLIs are aep, ess, worktree and connectors, plus the optional metaharness and b10x-harness of the aep product. They install from the release's checksummed prebuilt archive by default, and with cargo when --method cargo asks for it or the release has no archive for this machine's target (its SHA256SUMS lists the targets it has). A binary limited to some operating systems (b10x-harness: Linux) is not installed elsewhere. B10X_MARKETPLACE=<local checkout> makes b10x read and register that checkout instead of this repository, for testing an unpublished marketplace.

The guard

b10x guard bash is a Claude Code PreToolUse hook. It parses the command with the Bash grammar and checks each simple command, including those in $(…), after env, timeout or sudo, and inside bash -c '…'. A refusal is exit 2 and one stderr line naming what to do instead. Input it cannot read, a tool other than Bash, an unreadable configuration and any internal error are allowed: the hook never blocks a session by failing. It reads no file but its configuration and starts no process. The plugin runs it only when the installed b10x has the guard command, so a plugin newer than the binary allows everything.

group	refuses	on without a file
gh_writes	gh writes (pr create|comment|edit|merge|close|review|ready, issue, release, run rerun|cancel, workflow run, secret set, repo create|edit|delete|archive, label, and gh api with a method other than GET or with fields) for a repository of orgs: named by --repo or the API path, or run below a workspace_roots directory	no
tmp_writes	writing under /tmp or /dev/shm: output redirections, tee, -o/--output/--out, mktemp -p /tmp, cd /tmp, a cp/mv destination, mkdir, touch	no
read_dev_zero	read -t in a command that reads /dev/zero	yes
pgrep_loops	pkill -f, and pgrep -f in a while or until loop or a for body	yes
heredoc_stdin	a heredoc or here-string into python -, cat > file, bash -s, node -, ruby - or git commit -F -; python -c "…" with a backtick in the double-quoted code	yes
commit_message_flag	git commit -m, --message, -am	no

The configuration is $B10X_GUARD, else $XDG_CONFIG_HOME/b10x/guard.toml, else ~/.config/b10x/guard.toml. Every group is a table with enabled; gh_writes also takes orgs and workspace_roots. Without orgs, gh_writes refuses nothing.

[gh_writes]
enabled = true
orgs = ["example-org"]
workspace_roots = ["~/work"]

[tmp_writes]
enabled = true

[commit_message_flag]
enabled = true

Codex runs no hook from this plugin; the guard is Claude Code only.

How it stays current

• Every plugin lives here and carries this repository's version. catalog.json lists products, plugins, CLIs and retired names, and no versions.
• CLIs are the newest release, unless a repository pins one or a local pin in ~/.config/b10x/pins.toml does (Pin a version). agentplugins-check tools (every pull request, main push and daily) downloads the newest aep, ess, worktree, metaharness and connectors, runs every command the skills spell with --help, validates the ESS syntax example, and fails when a release is newer than verified.json, the release the skills were last verified against.
• On the machine, b10x check runs at session start, reads the newest releases from GitHub at most once a day, and says when the plugins or a CLI are older than the newest release, when a CLI does not match its repository's pin, when an earlier install is still there, or when nothing is set up.

Portable plugin creation

The creator uses skills/<name>/SKILL.md as the shared capability layer. Both hosts load that layout and its references, assets, and optional scripts. A command is a short skill the operator starts by name, or an agent starts on the operator's request: at most 20 lines, handing off to one activity skill that holds the behavior. Claude Code lists it as /<plugin>:<name>, Codex as $<name>. Any approval a command needs is a step in its body or that activity skill, so an agent that started it stops there. A skill kept operator-only sets disable-model-invocation: true for Claude Code and policy.allow_implicit_invocation: false in its agents/openai.yaml for Codex, and its description gives the reason in a sentence starting Operator-only:.

Specialist-agent behavior lives in the owning skill, as references/<role>.md. A thin Claude Code agents/ wrapper names that skill and links the file; Codex runs the same file directly or delegates through its supported orchestration. The creator never presents a Claude-only command or agent file as a portable component.

The full compatibility rules live with the plugin source and link to the current OpenAI plugin packaging guide and Claude Code plugin reference.

Routing boundaries

The front door does not copy specialist instructions. Install the plugin it selects when you need the governed workflow:

• aep for plans, artifact stores and accepted development work;
• ess for ESS specification, retrofit, validation and conformance;
• worktree for managed Git worktrees and safe cleanup;
• connectors for setting up providers and invoking governed integrations.

For the broader organization map, start at the Beyond10x documentation.