Plugin skills

The 10 natural-language skills, auto-routing hooks, and the safety-guard table

Come to this page to look up the exact skill names, routing rules, and safety guards of the axhub plugin.
The plugin is a thin routing layer that turns Korean and English natural language into axhub CLI commands inside Claude Code (terminal and desktop app) and the Codex CLI. All decision and execution logic lives in ax-hub-cli (the axhub binary), while the plugin connects your intent to the right skill and takes care of safety guards like preview and confirmation. The current surface is 10 natural-language skills plus auto-routing hooks. For installation and a first walkthrough, see the Ask in plain words guide.

The plugin requires CLI v0.20.0 or newer. Some skills need more — scaffold needs v0.30.0, and plugins needs v0.33.0 or newer (where the axhub plugin commands live). If the CLI is missing or too old, skills stop and guide you through installation or upgrade first.

The 10 skills

Natural language is the primary path — just say what you want and the request routes to the right skill. When you want to be explicit, invoke a skill directly as a slash command: /axhub:<skill-name>.

Skill	What it does	Typical phrases
`onboarding`	First-time setup — CLI install, login, git/node checks, GitHub App, and MCP connection, in order	"set me up", "getting started"
`bootstrap`	Create a brand-new app from a template in an empty folder — app, repository, and first deploy in one pass	"I want to create an app on axhub", "create a new app"
`scaffold`	Start from a template with the repository created under your account or org — pushes, stops for confirmation, then hands off to `import`	"start from a template in my org", "create the repo under my account"
`plugins`	Publish, list, and download exact versions of plugin apps in your company marketplace	"show me the plugins", "download 1.2.0", "publish these skills as one plugin"
`import`	Bring an existing local app (non-empty folder) into axhub and prepare its first deploy	"put this folder on axhub", "deploy my existing app"
`development`	Add or change features of an existing axhub app — real-data (connector/table) screens, CRUD, UI/API work	"add search to my todo app", "build a dashboard from my data"
`deploy`	Redeploy the current branch of a connected app and track status — preview → confirm → execute → verify	"deploy", "ship it again"
`diagnosis`	Read-only diagnosis of a failed deployment — never redeploys or rolls back	"why did my deploy fail?", "just find the cause"
`clarity`	Exact CLI operations — logs, env vars, rollback, tables, connectors, GitHub reconnect, app deletion	explicit requests like "use axhub clarity to show logs"
`update`	Check and apply axhub CLI/plugin updates	"is axhub up to date?", "update axhub"

The per-command slash set from earlier versions (/axhub:apps, /axhub:status, /axhub:logs, …) and the quality agents have been consolidated into this skill set. Only skill-name slashes (such as /axhub:deploy) exist today.

Auto-routing hooks

The plugin ships hooks that route requests to the right skill. Nothing to configure.

Session start — offers a CLI/plugin update check once every 24 hours (disable with AXHUB_NO_AUTO_UPDATE), resumes a pending onboarding MCP step, and on Windows explains the Git Bash execution contract.
Prompt routing — freshness/update wording routes to update first; bringing an existing app routes to import; GitHub reconnect/device-code wording routes to the clarity auth flow; "check status / continue" wording resumes the in-flight bootstrap/deploy flow.

Safety guards

Hard-to-undo actions (deploy, delete, …) show a preview of what will happen and ask for one more confirmation. At the CLI level, mutating commands default to dry-run and require --execute.
Success is evidence-based — a deploy counts as done only after the deployment record verifies (axhub deploy verify), not when the command exits.
Secrets are collected without exposing them on screen or in command history.
Deploy, recover, and rollback always confirm which app and which tenant first.
diagnosis is read-only and never mutates state while investigating.

Using it in Codex

axhub officially supports the Codex CLI 0.147.0 or newer. Instead of the Claude bundle, install the Codex-specific derived bundle (axhub-codex):

codex plugin marketplace add https://github.com/jocoding-ax-partners/axhub

codex plugin add axhub-codex@axhub

All 10 skills are the same as the Claude edition, and the safety guards (preview, confirmation) apply identically. Only a few Codex-specific points are worth knowing.

Hook trust is asked once — on the first conversation after installing, Codex asks whether to trust the plugin hooks (4 session-start + 1 prompt). If you decline, only the automatic update check, update-first routing, restart check, and Windows-contract notice quietly turn off — every skill still completes without hooks. Updates work by simply saying "update axhub" (the update skill handles it end to end).
It works in the ChatGPT desktop app too — desktop Codex reads the same setup as the terminal, so one install covers both surfaces.
Restart Codex after a plugin update for the new version to take effect.
If you previously installed the Claude bundle (axhub@axhub) into Codex, run codex plugin remove axhub@axhub and install axhub-codex@axhub instead. If the marketplace was already registered, codex plugin marketplace upgrade axhub refreshes the catalog so only axhub-codex shows.
If skills don't appear in the catalog (descriptions get truncated when many plugins are installed), invoke them by explicit mention, like $axhub-codex:deploy.
The AI usage record opt-in is Claude-edition only — the Codex edition never creates or changes that setting.