AI coding tool は、もはや code だけを読む存在ではありません。AGENTS.md、CLAUDE.md、SKILL.md、.cursor/rules、MCP settings、hooks、Copilot instructions のような「agent への説明書」も読みます。問題は、これらの configuration が壊れていても、TypeScript の type error のようにすぐ赤くならないことです。多くの場合、agent が silently ignore したり、一つの tool では動くのに別の tool では効かなかったりします。

今日紹介する agent-sh/agnix は、まさにこの隙間を埋める tool です。AI agent configuration file 向けの linter で、Rust で実装されています。npm、Cargo、Homebrew、editor extension、GitHub Action、online playground を提供します。GitHub search result では現在およそ 263 stars、23 forks。主な言語は Rust、license は MIT OR Apache-2.0 です。npm package agnix と crates.io package agnix-cli の latest version は、どちらも 0.29.0 です。

プロジェクト概要

項目内容
リポジトリagent-sh/agnix
npm packageagnix
Cargo packageagnix-cli
Stars約 263
Forks23
主な言語Rust
ライセンスMIT OR Apache-2.0
現在の versionv0.29.0

解いているのは「正しそうに見えるが効いていない」問題

従来の developer tool configuration には、明確な schema があることが多いです。package.json、tsconfig.json、ESLint config が間違っていれば、editor、CLI、CI がすぐ教えてくれます。一方で AI agent configuration はまだ緩い状態です。同じ markdown や JSON でも、tool ごとに期待する場所、field、format が違います。

その結果、かなり見えにくい問題が起きます。Configuration file は存在し、agent も起動する。しかし重要な rule が load されていない。たとえば skill name の format、frontmatter field、hook path、MCP JSON、Copilot instructions の置き場所などです。Developer は agent の挙動がおかしいと感じてから、ようやく configuration を疑うことになります。

agnix は、この種の configuration issue を早めに見つけるための tool です。README では現在 421 rules を掲げており、official specs、research、real-world breakage pattern から rules を作っていると説明しています。Business code を lint するのではなく、agent が project をどう読み、tool をどう呼び、skill をどう trigger し、hook をどう実行するかを決める meta configuration を lint します。

対応範囲が広い

agnix の面白いところは、一つの agent だけに閉じていない点です。README の support table では、次のような入口を扱っています。

  • Agent Skills：SKILL.md を検証する。
  • Claude Code：CLAUDE.md、hooks、agents、plugins を検証する。
  • GitHub Copilot：.github/copilot-instructions.md と instructions files を検証する。
  • Cursor：.cursor/rules/*.mdc、.cursorrules、hooks、agents、environment settings を検証する。
  • Kiro：steering、skills、agents、hooks、MCP settings、powers を検証する。
  • MCP：*.mcp.json を検証する。
  • AGENTS.md：AGENTS.md、AGENTS.local.md、override files を検証する。
  • Cline と Gemini CLI：それぞれの rules、settings、extension config を検証する。

これは現在の実務にかなり近いです。一つの repository に AGENTS.md、Claude Code skill、Cursor rule、Copilot instructions、MCP server config が同時にあることは珍しくありません。Unified checker がなければ、team はそれらが各 tool の最新の約束に合っているかを manual review に頼ることになります。

agnix は、それらを一つの CLI で扱います。価値は official docs の代替ではありません。見落としやすい format、name、location、compatibility issue を runnable check に変えることです。

CLI は素直に使える

最も簡単な使い方は npm です。

npm install -g agnix
agnix .

Homebrew や Cargo でも install できます。

brew tap agent-sh/agnix && brew install agnix
cargo install agnix-cli

README にある主な commands は次の通りです。

agnix .
agnix --fix .
agnix --fix-safe .
agnix --dry-run --show-fixes .
agnix --strict .
agnix --target claude-code .

Command の段階がわかりやすいです。普段は agnix . で diagnostics を見る。まとめて直す前に --dry-run --show-fixes で差分を確認する。Auto-fix に慎重な場合は --fix-safe だけ使う。CI では --strict を使い、warning も failure として扱えます。

Auto-fix は狭く使いたい

agnix は auto-fix を提供します。ただし、最初から大きな repository で何でも自動修正するより、まずは補助的に使うのがよいと思います。理由は単純で、agent configuration file には team semantics が含まれることが多いからです。Format rule だけでなく、team convention に触れる場合もあります。

現実的には、次の流れが安全です。

  • Local で agnix . を実行し、まず diagnostics だけ読む。
  • agnix --dry-run --show-fixes . で修正予定を見る。
  • 明らかな format issue には --fix-safe を使う。
  • --fix や --fix-unsafe は、人間が確認した batch fix に限定する。

これなら linter の速度を得つつ、team convention を自動 tool に任せすぎずに済みます。特に SKILL.md や AGENTS.md は Codex や Claude Code の振る舞い全体に影響するので、少し conservative でよいです。

Editor と CI integration で基盤になる

agnix は単体 CLI だけではありません。README には VS Code、JetBrains、Neovim、Zed extension、そして GitHub Action が載っています。Playground もあり、browser に agent config を貼り付けて diagnostics を見られます。

これは「たまに一回だけ check する」よりも、agent configuration を daily development feedback loop に入れる方向です。

  • SKILL.md を書いているとき、editor が field や naming issue を出す。
  • PR で GitHub Action が agent configuration の破壊を検出する。
  • Claude Code、Cursor、Gemini CLI などを upgrade したとき、一つの CLI で repository を再確認する。
  • Team が MCP config や hooks を追加するとき、CI で structure を検証する。

AI coding agent を本番の workflow に入れている team では、これは ESLint、markdownlint、actionlint に近い基礎 check になりそうです。Agent が必ず正しい判断をする保証にはなりませんが、少なくとも説明書が壊れている状態は早く見つけられます。

再利用しやすい rule engine の構成

README の architecture を見ると、agnix は単なる command script ではなく Rust workspace です。主な crate は次の通りです。

  • agnix-rules：rules JSON から rule metadata を生成する。
  • agnix-core：shared validation engine。
  • agnix-cli：command-line interface。
  • agnix-lsp：language server。
  • agnix-mcp：MCP server。
  • agnix-wasm：browser や runtime integration 向けの WebAssembly bindings。

この分割は妥当です。Agent configuration format はまだ速く変化しています。Rules が CLI の内部だけに閉じていると、editor、web playground、MCP server へ展開しにくくなります。Rule metadata と core validation engine を分けておけば、新しい tool や file type への対応もしやすくなります。

agnix-mcp も注目点です。理論上、agent は自分自身の configuration や project instruction を変更する前に checker を呼べます。壊れた configuration を書きながら、その configuration が効いていると信じて作業を続ける、という失敗を減らせるかもしれません。この種の agent self-governance tool は、今後増えていくはずです。

向いている場面

agnix は次のような project に先に入れたい tool です。

  • Repository に AGENTS.md、CLAUDE.md、SKILL.md、Cursor rules がある。
  • Team が複数の AI coding tools を併用している。
  • Codex skills、Claude Code commands、MCP server、hooks を保守している。
  • PR review で agent instruction の format issue を手で指摘することが多い。
  • Agent configuration を CI に入れたい。
  • AI coding workflow の template repository や starter kit を作っている。

個人 project で一、二行の agent instruction だけを書くなら、agnix は少し重く感じるかもしれません。ただし configuration が team で reuse され、automation、CI、deployment、code review に影響し始めるなら、専用 linter の価値はかなりあります。

注意したい境界

agnix が検証できるのは「configuration file が rules に合っているか」です。「agent があなたの意図を本当に理解したか」ではありません。Skill metadata、hook config、generic instruction などを指摘できますが、engineering instruction そのものが妥当かどうかは人間が判断する必要があります。

また、rule が多いほど noise も管理が必要です。初回導入では warning が多く出るかもしれません。まず error を消し、その後でどの warning を CI gate に入れるかを決めるのがよいです。既存の大きな repository では、最初から strict にするより段階的に締めるほうが導入しやすいです。

Version change にも注意が必要です。AI coding tool ecosystem はまだ速く動いており、official convention、file path、field name が変わる可能性があります。agnix の価値はそれらの変化に追従する点ですが、team 側も version を固定し、評価なしで CI に新しい rules を入れないほうが安全です。

まとめ

agent-sh/agnix は、AI agent configuration にも lint が必要だという問題をはっきり扱っています。Project に AGENTS.md、skills、MCP configs、hooks、editor-specific rules が増えるほど、それらが正しく load されるかを手作業で確認するのは難しくなります。

agnix の方向は実務的です。一つの Rust core で複数の agent configuration を検証し、CLI、editor extension、GitHub Action、MCP、WASM から使えるようにする。Agent を魔法のように賢くする tool ではありませんが、configuration file のミスで最初から誤った方向へ進むリスクを減らせます。

Team がすでに AI coding agent を実際の development workflow に入れているなら、agnix は toolbelt に加える価値があります。まずは agnix . と --dry-run から始め、agent configuration を一度書いて忘れる prompt file ではなく、継続的に保守する engineering asset として扱うのがよさそうです。

リポジトリ：https://github.com/agent-sh/agnix