Why aic

This page stays restrained. It explains aic’s design orientation without disparaging similar tools. If you already know the built-in configuration mechanisms of Claude / Codex / Gemini / OpenCode, focus on §3.

1. Can’t I just symlink manually?

It works in the short term. But once Skills / Contexts / MCPs grow in number, you will hit these issues:

Each tool’s directory layout differs (.claude/skills/ / .codex/skills/ / .gemini/skills/ / .opencode/skills/). Hand-managing four sets of links drifts easily.
There is no separation between declaration and execution: state can only be inferred from the filesystem, with no clear answer to “which are desired, which are stale, which are broken”.
New team members must absorb the full set of linking rules verbally or via docs.
env-required Skills lack a unified check; missing variables only surface as runtime errors.

aic consolidates these manual tasks into a standardized engineering flow:

.aic/.aicrc  → desired state (declaration)
aic sync     → actual state (execution)
aic env check → integrity check

2. How does this differ from the built-in config in Claude / Codex / Gemini?

Dimension	Built-in config	aic
Multi-tool distribution	Each tool maintains its own	One `.aicrc` covers four tools
Project-level declaration	Scattered across directories	Centralized in `.aic/.aicrc`
Portability across projects	Mostly personal global config	Project-level declaration travels with git
Env validation	Each tool implements its own	Unified `aic env check`
Registry content	No built-in marketplace	aic-registry public templates
Visual operation	Config files are JSON / TOML	Unified interaction across 7 TUI panels

aic is not a replacement: the built-in config mechanisms of Claude / Codex / Gemini / OpenCode remain the authoritative substrate. aic layers “project-level, portable, visualized” on top.

3. Why TUI first instead of CLI?

This is aic’s core design orientation.

3.1 Daily operations are state transitions, not command sequences

Installing a Skill, activating a Context, checking missing env values — these are essentially “switching among a set of states”, not “executing commands in order”. A TUI’s panel + list + detail view maps directly onto the cognitive model of “state → detail → action”.

3.2 Keep configuration work inside the terminal

Developers spend most of the day in the terminal. If configuring AI tools requires switching to a browser or a separate GUI, it breaks the “do everything in the terminal” workflow. The TUI’s benefit is staying in the terminal — no extra window management, and seamless integration with the terminal flows of Claude / Codex / Gemini / OpenCode themselves.

3.3 Mouse optional, keyboard reachable

The TUI supports both mouse clicks and keyboard shortcuts (tab / i / u / s). Mouse users work as if it were a traditional GUI; keyboard users can stay on the home row.

3.4 Theme and local-first alignment

The TUI does not depend on a system WebView. Colors and layout are fully controlled by aic, which makes “restrained, beautiful, close to developer aesthetics” achievable without running extra services on the user’s machine.

3.5 CLI still exists

The CLI is fully retained, mainly for:

Scripting (aic install xxx && aic sync)
CI integration (aic env check in PR pipelines)
Remote environments (after SSH’ing into a server, use the CLI directly)

aic ... --no-tui is available on every command to force the plain-text path.

4. Where does aic fit?

Individuals: keep AI tool configuration consistent across machines / projects.
Small teams: let team conventions (Context / permission presets) travel with the project; new members git clone && aic sync to restore everything.
Heavy AI tool users: people running Claude + Codex + Gemini + OpenCode simultaneously who don’t want to maintain a separate config per tool.

5. Where does aic not fit?

Enterprise compliance / SSO / auditing: the first version has no account system, no cloud sync, no audit log.
Fully offline / intranet deployment: Registry pulls currently go over the public internet. To deploy internally, fork aic-registry to an internal GitLab and switch via AIC_DOWNLOAD_BASE or protocol = "http".
Web dashboard / cloud collaboration: not in aic’s direction. aic does not plan cloud-hosted capabilities.

6. Boundaries with similar tools

Tool	Main difference
Each AI tool’s built-in `init`	Targets itself only; not cross-tool
General dotfile managers (GNU Stow / chezmoi)	Manage dotfiles, not AI-tool-specific config
Other SKM / Skills CLI	Most cover Claude / one tool only
Codex / Gemini official tools	Each manages its own; no project-level declaration for Skill / Context
Homebrew / apt	Package-manager level; doesn’t touch project-level config distribution

aic sits at the intersection of AI coding configuration + multi-tool + project-level.

7. If you are still on the fence

Try this in your terminal:

aic install git-commit
aic context use 02-iteration-evolution
aic env check
aic

In ten seconds you’ll know whether the TUI fits your workflow. If not, the CLI is fully available.