Skip to content

One definition,
wired into every agent.

See how it works Read the docs GitHub

Agentyx resolves the packs a project chooses into Skills, MCP servers and hooks, then installs them where Codex, Claude Code, Kimi Code and Qwen Code each expect them. Local to the project, recorded in a lockfile, reversible.

project definition

.agentyx.json

{
  "packs": [
    "technical", "typescript", "angular",
    "creative-web", "ui-ux", "accessibility"
  ],
  "enable": ["playwright"],
  "targets": ["codex", "claude", "kimi", "qwen"]
}

agentyx resolve

6 packs → 27 Skills

+ 2 MCP servers

Plan first: install --dry-run previews every write.

native destinations

  • Codex

    .agents/skills

    mcp .codex/config.toml

  • Claude Code

    .claude/skills

    mcp .mcp.json

  • Kimi Code

    .agents/skills

    mcp .kimi-code/mcp.json

  • Qwen Code

    .qwen/skills

    mcp .qwen/settings.json

Every written path is recorded in .agentyx.lock.json. Anything not recorded is never overwritten or deleted. 18 packs · 73 Skills · 7 MCP servers

agentyx resolve ui-ux creative-web --explain

Different questions, one resolved set.

Packs are declared and never inherit. When two packs want the same Skill it resolves once and keeps both origins. The two design packs show it: one asks how the product behaves, the other what the site should feel like.

ui-ux

Does the product behave well?

Usability, states, interaction, design-system consistency and product copy for apps, forms, dashboards and settings.

  • ui-visual-design
  • ux-usability
  • interaction-design
  • ux-writing

creative-web

What should the site feel like?

A creative concept, composition, type, storytelling, motion and critique for marketing sites, launches and portfolios.

  • creative-direction
  • web-composition
  • typographic-art-direction
  • visual-storytelling
  • motion-art-direction
  • design-critique
  • design-reference-research

Shared Skills resolve once and keep both origins

  • design-system-practice
  • visual-verification

agentyx resolve --explain
from ui-ux, creative-web

From a project to a setup you can review.

Choices live in .agentyx.json. Sync converges the files on disk to that desired state, and doctor reports how far reality drifted.

  1. 01

    Initialize

    Detect your stack and agents, choose packs, and install the first setup interactively.

    pnpm dlx @agentyx/cli init

  2. 02

    Tune your capabilities

    Add packs or enable optional capabilities as your project changes.

    pnpm dlx @agentyx/cli configure

  3. 03

    Sync the agents

    Converge provider files on the desired project configuration.

    pnpm dlx @agentyx/cli sync

  4. 04

    Check the setup

    Review health, installed-state drift and available usage evidence.

    pnpm dlx @agentyx/cli doctor
Plan first
Preview changes with install --dry-run before any file is written.
Owned files only
The lockfile tracks managed paths. Edited or unowned destinations become conflicts.
Project local
Skills, MCP configuration and supported hooks live with the project.

Four agents, one definition.

Every provider receives byte-identical Skill content. Only the destination differs, and each one is that provider's own documented convention. See the full compatibility matrix.

Where Agentyx installs

Every path is relative to your project root. Agentyx writes nothing else, and never $HOME.

Installation destinations per provider: Skills, agents, MCP configuration and hooks.
Capability Codex Claude Code Kimi Code Qwen Code
Project Skills .agents/skills.claude/skills.agents/skills.qwen/skills
Project agents .codex/agents/<name>.toml.claude/agents/<name>.md.agents/agents/<name>.md.qwen/agents/<name>.md
MCP configuration .codex/config.toml.mcp.json.kimi-code/mcp.json.qwen/settings.json
Lifecycle hooks .codex/hooks.json.claude/settings.json user-level config only — Agentyx installs none .qwen/settings.json shared with MCP

What doctor can observe

A capability a provider cannot reliably show is unobservable, never dormant. Absence of evidence is never reported as evidence of absence.

Runtime observation signals available per provider.
Signal Codex Claude Code Kimi Code Qwen Code
Session lifecycle yes yes unobservable yes
Tool use yes yes unobservable yes
Skill use unobservable yes unobservable unobservable
MCP use yes yes unobservable yes
Context size unobservable yes unobservable unobservable

agentyx doctor

Know what your agent setup is doing.

doctor checks more than whether a tool is installed. It compares your config with the files on disk, sizes the active harness, and reports usage evidence when a provider can expose it.

Read how observation works
agentyx doctorIllustrative report
installed state
In syncConfigured files match the managed lockfile.
footprint
5 packs · 18 Skills · 2 MCP servers
observed activity
example MCP use9 / 12 sessions
75% of sessions with sufficient evidence for this capability.
skill usage
Unavailable for this targetDoctor will not treat missing visibility as zero use.
Find configuration drift
See stale, edited or conflicting managed files before they surprise another agent.
See the harness footprint
Count active packs, Skills, MCP servers, tools and hooks, including qualitative MCP context cost.
Use evidence carefully
Session rates include a numerator and denominator; unobservable activity stays unavailable, never 'unused'.

Observation is local, metadata only and baseline aware. Older sessions do not count against newly enabled capabilities. Doctor offers conservative hints; it never edits your configuration.

Packs compose. You choose the mix.

18 built-in packs carry 73 Skills, with no inheritance and no hidden dependencies. A polished product site, for example, pairs the creative-web and ui-ux design packs with the accessibility pack.

Browse the packsPack reference

.agentyx.json

{
  "packs": [
    "technical",
    "typescript",
    "angular",
    "creative-web",
    "ui-ux",
    "accessibility"
  ],
  "enable": ["playwright"]
}

→ 27 Skills, 2 MCP servers. Playwright is optional.