AI工具包

2. Or install something in one command

npx toolkit-ai source add vercel-labs/agent-skills npx toolkit-ai skill brainstorming

3. Check what's installed and what needs updating

npx toolkit-ai list npx toolkit-ai check ```

---

Install

```bash

Recommended — install once, get the short `toolkit` command,

One-off use (never installs anything globally)

npx toolkit-ai ```

Install

toolkit skill <name> # Install a skill toolkit agent <name> # Install an agent toolkit mcp <name> # Register an MCP server toolkit bundle <name> # Install a bundle (all items at once) toolkit plugin <name> # Install a plugin (decomposed across every detected provider)

Add a source and install a skill from it

toolkit source add vercel-labs/agent-skills toolkit skill brainstorming

Install an entire bundle

toolkit bundle fullstack-starter

Scan before installing something you don't trust

toolkit scan skill suspicious-skill

Install in CI — fail the pipeline if the scanner finds anything risky

toolkit skill suspicious-skill --strict

Make symlink installs the default for future TUI and CLI installs

toolkit settings install-mode link ```

---

Quick Start

```bash

Guidelines

- Use plural nouns for resource names (/users, not /user) - Return 201 for successful creation, 204 for deletion - Include pagination for list endpoints ```

Installs to detected targets: ~/.claude/skills/, ~/.copilot/skills/, ~/.agents/skills/ (Codex), ~/.config/amp/skills/

Settings

toolkit settings install-mode copy # Install skills/agents as file copies toolkit settings install-mode link # Install skills/agents as symlinks toolkit settings cache 24h # Refresh stale source cache after 24h toolkit settings cache 0 # Always check sources on launch/refresh toolkit settings concurrency 4 # Fetch up to 4 sources in parallel

Settings

The TUI includes a Settings tab for install mode, source cache duration, parallel source refreshes, detected providers, and the config/cache paths. The same values are stored in ~/.toolkit/config.json and used by headless CLI commands.

• installMode: "link" (default) symlinks skills/agents to the source cache, so refreshes and local source edits propagate without reinstalling.
• installMode: "copy" installs stable snapshots of skills/agents instead — useful when you want installed content frozen at install time, independent of source-cache refreshes.
• cacheTTL controls how long source clones are considered fresh before the next launch or refresh fetches updates.
• cacheTTL: 0 always checks remote sources.
• sourceConcurrency controls how many source repos fetch in parallel.

Directories named node_modules, .git, dist, build, .next, and coverage are automatically skipped.

Use when creating or reviewing API endpoints.

API Design

CLI Commands

```bash

Plugins

Plugins are bundled packages of skills, agents, commands, and MCP servers, discovered as a first-class resource type and installed across every detected provider — Claude Code, Codex, GitHub Copilot, Cursor, VS Code, and Amp.

Discovery — manifest formats accepted:

- .claude-plugin/plugin.json — Claude Code's official plugin layout - .codex-plugin/plugin.json — Codex's native plugin layout - plugin.json at the plugin root — generic / cross-tool plugin packages - Plugins already installed by Claude Code's /plugin install — read from ~/.claude/plugins/installed_plugins.json and surfaced under the synthetic claude source. No source configuration needed; they appear automatically in toolkit list and the TUI catalog. Run toolkit plugin <name> on one to mirror it across every other detected provider, using native plugin installs where available and decomposed copies only for fallback providers. Toolkit never writes to Claude's plugin state — remove plugin only removes the toolkit-managed copies. - Plugins already installed by Codex — read from ~/.codex/config.toml [plugins."<name>@<marketplace>"] entries plus ~/.codex/plugins/cache/<marketplace>/<name>/<version>/, then surfaced under the synthetic codex source. Run toolkit plugin <name> to mirror it across the other detected providers. - Plugins already installed by GitHub Copilot CLI's copilot plugin install — discovered by walking ~/.copilot/installed-plugins/_direct/ (the per-plugin install root the Copilot CLI populates) and surfaced under the synthetic copilot source. Same flow as the Claude case: appear automatically in toolkit list, run toolkit plugin <name> to mirror it across every other detected provider. Toolkit never writes back to Copilot's installed- plugins tree — remove plugin only removes the toolkit-managed copies.

Manifest path overrides — for plugins that don't fit Claude's layout:

Most Claude plugins put skills directly under skills/<name>/SKILL.md and agents directly under agents/<name>.md. Cross-tool plugin packages (AMS, Radware bundles, anything with per-tool adapters) often nest these — e.g. skills/universal/foo/SKILL.md, skills/stack-specific/backend-java/foo/SKILL.md, agents/adapters/copilot/reviewer.agent.md.

The plugin.json manifest may declare explicit content roots so the toolkit walks the right places:

{
  "name": "radware-ams",
  "skills": [
    "skills/universal/",
    "skills/stack-specific/backend-java/",
    "skills/stack-specific/frontend-react/"
  ],
  "agents": "agents/adapters/copilot/",
  "commands": "commands/",
  "mcps": "mcps/"
}

Each field accepts a string or an array of strings, all relative to the plugin root. The toolkit walks each declared root recursively for SKILL.md / *.agent.md / *.md / *.prompt.md / *.mcp.json, then installs or mirrors across every detected provider exactly as it does for Claude-shaped plugins. When fields are absent, the conventional dirs (skills/, agents/, commands/, root .mcp.json) are scanned instead.

Install — what happens to each component:

Installing a plugin uses each provider's native plugin system when one is available, and decomposes only for providers that do not have a plugin registry:

• Claude Code → ~/.claude/plugins/cache/toolkit-ai/<name>/<version>/
• Codex → ~/.codex/plugins/cache/toolkit-ai/<name>/<version>/
• GitHub Copilot CLI → ~/.copilot/installed-plugins/toolkit-ai/<name>/
• Cursor / VS Code / Amp → decomposed skills, agents, commands, and MCP config in the native per-user locations those tools already read
• commands/<name>.md → transformed *.prompt.md for VS Code / Insiders
• .mcp.json → registered as MCP servers in every detected MCP-aware config (.claude/settings.json, .cursor/mcp.json, .vscode/mcp.json, .codex/config.toml, .config/amp/settings.json, etc.)

The result is that the same plugin works in every assistant the user has installed, in each one's own native shape — no provider-specific plugin machinery required on the consumer side. Native plugin installs deliberately do not also copy the same skills/agents into Claude/Copilot/Codex user dirs, because that duplicates agents in provider UIs.

For Codex native plugin installs, command files are copied into the plugin's commands/ directory with only Codex-safe frontmatter (description and argument-hint). Claude-only metadata such as name, phase, persona, or model is stripped from the Codex copy so slash commands can be discovered.

Native Copilot plugin registration: when GitHub Copilot CLI is detected, plugin install also writes a real entry to Copilot's plugin manager — copies the plugin tree to ~/.copilot/installed-plugins/toolkit-ai/<name>/, adds to ~/.copilot/config.json installedPlugins[], enables it in ~/.copilot/settings.json. This makes the plugin show up in Copilot's "Plugins" UI panel, not just as decomposed skills/agents on disk. toolkit remove plugin mirrors this — drops the registry entry, disables in settings, removes the cache dir.

Native Codex plugin registration: when Codex is detected, plugin install also writes a real Codex plugin install — copies the scoped plugin tree to ~/.codex/plugins/cache/toolkit-ai/<name>/<version>/, registers a local toolkit-ai marketplace in ~/.codex/config.toml, and enables [plugins."<name>@toolkit-ai"]. Codex then loads the plugin from its own plugin system instead of only seeing decomposed standalone skills/agents. toolkit remove plugin removes the config entry and cache tree.

Hooks (hooks/hooks.json). Toolkit refuses to merge a plugin's hooks into the user's ~/.claude/settings.json (those commands run on every tool call across every repo and the security scanner doesn't cover them yet), but a plugin-tree hooks file is a different story: each tool's plugin manager loads hooks/hooks.json from inside the plugin's own install dir and scopes the hooks to that plugin's lifecycle. The toolkit copies the hooks/ directory verbatim along with the rest of the plugin tree, so any hooks/hooks.json the plugin ships rides along to Claude / Copilot / Codex plugin installs.

Per-tool hooks.json swap. Claude, Copilot, and Codex disagree on hook schema — Claude uses PascalCase events and ${CLAUDE_PLUGIN_ROOT}, Copilot uses camelCase events with no documented plugin-root env var, Codex's hook spec is not public. A plugin can ship multiple hook configs and let the installer pick the right one per tool. The canonical hooks/hooks.json is treated as the Claude flavor; if the plugin also ships hooks/configs/copilot.hooks.json or hooks/configs/codex.hooks.json, the installer for that tool reads the matching template, substitutes the literal string __AMS_PLUGIN_ROOT__ with the install destination directory, and writes the result over hooks/hooks.json inside that tool's install. Claude's install is never swapped — it keeps the canonical file. During the substitution, toolkit normalizes backslashes to forward slashes so Git Bash on Windows receives paths it can execute safely.

plugin/
├─ hooks/
│  ├─ hooks.json                    ← canonical (Claude flavor)
│  └─ configs/
│     ├─ copilot.hooks.json         ← swapped in for Copilot install
│     └─ codex.hooks.json           ← swapped in for Codex install

This sidesteps the missing plugin-root env var problem on Copilot and Codex: since the templates carry absolute paths after substitution, the hook commands resolve correctly without any runtime variable expansion.