asi

asi is a cross-tool packaging system for AI agent and skill catalogs. You maintain one canonical catalog of agents and skills, and asi renders it into the tool-specific formats each AI coding assistant expects:

• Claude Code — .claude/agents/*.md, .claude/skills/*/SKILL.md
• GitHub Copilot — .github/agents/*.agent.md, .github/skills/
• OpenAI Codex / modern OpenAI agents — .codex/agents/*.toml
• Gemini CLI — .gemini/agents/*.md, .gemini/skills/

Write an agent or skill body once, describe it once in the catalog registry, and asi handles the per-tool frontmatter, file naming, and directory layout differences for you.

It also does a second, related job: asi gateway points those same tools at a local LLM gateway, so the tool that reads your catalog and the endpoint it talks to are configured from one place. See Gateway wiring.

Why

Every AI coding tool has invented its own format for "here's a reusable agent persona" and "here's a reusable skill/playbook" — different frontmatter fields, different file extensions, different directory conventions. If you use more than one tool (or want to keep your team's agents/skills portable across tools), you end up hand-maintaining near-duplicate copies. asi keeps one source of truth and generates the rest.

Install

There isn't a one-line installer yet — build from source:

git clone https://github.com/corypolicht/asi.git
cd asi
go build ./cmd/asi
./asi --version

Requires Go 1.25+. Prebuilt release binaries for Linux/Windows will be published on this repo's Releases page in a future update — CI and release automation are still being wired up for the public mirror, so for now, building from source is the supported path.

Quick Start

Every asi command needs to find a catalog/ directory — either bundled next to the binary, or discovered by walking up from your current directory (handy in this repo's own dev loop), or pointed at explicitly:

# Point asi at a catalog (the parent directory of a catalog/ folder)
asi config set-catalog-dir /path/to/your/catalog/repo

# Validate the catalog's schema and cross-references
asi validate

# Render the catalog into one or more tool-specific formats
asi sync --targets claude,copilot,openai,gemini

# Install the rendered agents/skills into this project or your home directory
asi install

asi install prompts interactively for scope (local project vs. your home directory vs. both) and which tool targets to install. Pass --non-interactive --scope local --targets claude to skip the prompts in scripts/CI.

How the Catalog Works

Your catalog is a directory (named catalog/ by convention) containing:

catalog/
├── agents.json      # Agent registry: id, description, skills, tool mappings
├── skills.json      # Skill registry: id, description
├── agents/          # One markdown body per agent: {id}.md
└── skills/          # One directory per skill: {id}/SKILL.md

• agents.json / skills.json are the registries — metadata about each agent/skill (what it's called, what it does, which skills an agent can invoke, and any per-tool overrides).
• agents/{id}.md and skills/{id}/SKILL.md are the master body files — the actual instructions, shared across every rendered target. Skill directory names must match the skill's id exactly (lowercase, numbers, hyphens).

At render time, asi synthesizes the frontmatter each tool expects from the registry entry (plus any target-specific override) and pairs it with the shared body text. See public/catalog/ in this repo for a small, working sample catalog — 3 agents and 4 skills — that asi validate and asi sync both run clean against.

Pointing at Your Own Catalog

asi resolves its catalog in this order:

1. catalog.dir in ~/.asi/config.json — an explicit override. Set it with asi config set-catalog-dir <path> (the path should be the parent directory of your catalog/ folder, not the folder itself).
2. Remote sync — set catalog.source: remote (via asi config set-catalog-source remote) along with a remote URL (via asi config set-remote <git-url>) to have asi clone/pull your catalog repo automatically on every run, without rebuilding the binary.
3. The catalog/ directory shipped beside the binary — the default for a normal install.
4. An upward directory walk from your current working directory — a dev-loop convenience.

This means you can keep a private catalog (your own agents, skills, and conventions) in its own repo, and either point asi config set-catalog-dir at a local checkout of it, or configure it as a remote source so every machine stays in sync automatically:

asi config set-remote https://github.com/your-org/your-catalog.git
asi config set-branch main
asi config set-catalog-source remote
asi sync --targets claude

Run asi config show at any time to see every resolved setting.

Gateway wiring

Separately from catalog packaging, asi gateway configures where your AI coding tools send their API traffic — useful when you run a local gateway or proxy in front of Anthropic, OpenAI, or self-hosted models.

asi gateway on      --targets claude    # route one tool through the gateway
asi gateway status                      # inspect current wiring
asi gateway refresh --targets claude    # refresh the cached model list
asi gateway off     --targets claude    # revert

Targets are claude, codex, antigravity, and copilot; omit --targets to apply to all of them. Each target has its own wiring — environment variables, settings files, and for Claude Code a SessionStart hook that keeps the model picker populated — and asi knows the differences.

The default gateway URL is http://127.0.0.1:1235. Override it with --gateway-url to reach a gateway on another port or host.

OAuth tokens and provider API keys are never inspected or modified; off removes only the endpoint overrides on added.

Companion project: llm-proxy

llm-proxy is a gateway built to sit on the other end of asi gateway. It fronts Claude Code and OpenAI-compatible clients, routing each request to Anthropic, Google Gemini, or local backends (LM Studio, llama.cpp, vLLM, Ollama) through a rules engine, and translating between the OpenAI and Anthropic wire formats. Its default port is 1235 — the same one asi gateway targets by default.

The two tools are developed together but neither depends on the other: asi gateway works with any gateway that speaks these APIs, and llm-proxy documents a manual equivalent for every wiring step asi performs.

Status

This is an actively developed tool, mirrored out from a privately-developed monorepo (see CONTRIBUTING.md for what that means for contributions). The CLI surface, catalog schema, and rendering pipeline are functional and exercised daily, but expect some rough edges around release packaging and CI while that side of the project catches up.

License

MIT — Copyright (c) 2026 Cory Policht.