alint: repository の構造・内容・agent 制約をまとめて lint する

多くの team はすでに code lint を持っています。

JavaScript なら ESLint;
Rust なら Clippy;
security / semantic check なら Semgrep;
その上で format や test や policy check も CI に載せている。

それでも repository には、意外と誰も系統的に見ていない領域があります。

ある file は必ず存在してほしい;
ある directory 名は規約に沿っていてほしい;
package.json、Cargo.toml、GitHub Actions workflow の値は team の基準を満たしてほしい;
すべての package に README が必要;
Markdown link は実在する target を指していてほしい;
AI agent に渡す AGENTS.md と repository の実際の制約はズレてほしくない。

今日メモしておきたい asamarts/alint は、まさにその層を狙った tool です。これは別の language lint を作っているのではなく、**「repository 全体はどういう形であるべきか」**を declarative に書き、それを Rust 製 CLI で検査する project です。

GitHub repository page、release page、project site を 2026-06-22 時点で見ると、この repository は 43 stars、1 fork、主要言語は Rust。作成日は 2026-04-18、公開上の最新更新日は 2026-06-22 です。license は Apache-2.0 / MIT の dual license。最新 release は v0.13.0 で、公開日は 2026-06-17 です。

Project overview

項目	内容
Repository	asamarts/alint
位置づけ	repository 構造・file 内容・cross-file relation 向けの汎用 linter
Stars	43
Forks	1
主要言語	Rust
作成日	2026-04-18
最終更新日	2026-06-22
License	Apache-2.0 / MIT
Current version	v0.13.0
Version date	2026-06-17

見ているのは「code が正しいか」だけではなく「repo の形が正しいか」

alint の入り口はかなり明快です。対象は repository shape です。

README と公式 site が繰り返し強調しているのは AST レベルの rule ではなく、むしろ次のような repository 層の問題です。

file が存在するか;
file 名や path が naming rule に沿っているか;
JSON / YAML / TOML / XML の値が条件を満たしているか;
複数 file の間に必要な関係があるか;
ある fact が存在するときだけ rule を有効にするか;
出力を CI、PR annotation、あるいは agent が直接読める形にするか。

この位置取りが面白いです。なぜなら、多くの重要な rule は厳密にはどの language にも属していないからです。

例えば、

「各 package に README が必要」は TypeScript rule でも Rust rule でもない;
「GitHub Actions は commit SHA に pin する」は YAML syntax check では足りない;
「すべての Cargo.toml は edition = 2024 を持つべき」は Rust code lint とは少し違う;
「新しい directory には対応する doc entry が必要」は repository governance に近い。

こうした constraint は普段、wiki、review 習慣、暗黙知のどこかに散らばっています。alint はそれを「人が覚えること」から「repository 自身が検査すること」に寄せています。

1 つの `.alint.yml` で、構造・内容・関係をまとめて表現する

この project で使いやすそうだと感じたのは、設定の入口を 1 つに寄せていることです。

README と公式 site の例を見ると、1 つの .alint.yml で同時にかなり多くのことを書けます。

どの bundled ruleset を継承するか;
どの path が必須か;
どの config file の値が固定値や regex に合うべきか;
どの directory が naming rule を満たすべきか;
どの file 同士が pair / unique relation を持つべきか;
has_rust や has_node のような fact が成り立つときだけ、どの rule を動かすか。

ばらばらの shell script を積み上げるより、長期的にはかなり保守しやすい constraint layer に見えます。

project site が出している surface area も小さくありません。89 の rule kind、13 の family、22 の bundled ruleset、12 の fix operation、10 の subcommand、8 の output format。数字そのものが価値ではありませんが、少なくともこれは「README の有無だけを見る小さな script」ではなく、repository lint として独自の設計を持ち始めている tool です。

特に実用的なのは、cross-file relation を一級機能として扱っていること

alint が普通の lint と少し違って見えるのは、cross-file relation をかなり中心に置いている点です。

code lint は単一 file や単一 language には強いですが、repository governance の典型的な問題は、実際には file をまたいでいます。

各 workflow に対応する doc があるか;
各 package に README があるか;
各 Markdown link が存在する target を指しているか;
各 directory に必要な metadata file があるか;
同じ kind の identifier が一意か。

これを shell pipeline で全部やろうとすると、たいてい脆くて読みにくい CI script になります。alint はそこを declarative rule に落としていて、可読性と再利用性がかなり上がりそうです。

multi-language repository や monorepo でこの方向がしっくり来るのは当然で、repository shape そのものが language 横断の問題だからです。

AI assisted development に対しては、構造 guardrail の層を足している

alint でもう 1 つ目を引いたのは、AI-touched repos をかなり意識していることです。

README と site では次の 2 点が明確に書かれています。

--format agent で、LLM が読みやすい JSON を出せる;
export-agents-md で、active rule set から AGENTS.md を出力できる。

それぞれ単独では大きな発明ではありませんが、今の workflow ではかなり役に立ちます。

agent に repository を直接触らせる場面が増えると、問題は「code が書けるか」ではなく「構造上の制約を知らずに同じ事故を繰り返すか」になりがちです。

新しい directory を作ったのに関連 doc を追加しない;
workflow を触って team rule を壊す;
file 名が naming convention から外れる;
config file の構造を壊す;
AGENTS.md が repository の現実から少しずつズレる。

machine-readable な constraint を 1 つの output にまとめられる tool は、CI 用であるだけでなく、agent に対して **「先にルールを読んでから作業する」**ための guardrail にもなります。

この意味で alint は、repo hygiene と policy-as-code と agent guardrail をかなり近い場所に集めようとしているように見えます。

既存 lint / policy tool と競合するというより、間の層を埋めている

公式 site の説明で良かったのは、ESLint や Clippy は code、Semgrep は semantic、alint は code と policy の間で repository filesystem shape を扱うという整理です。

これはかなり正確だと思います。

つまり alint の価値は既存 lint を置き換えることではなく、別の層を追加することです。

business logic を解析するわけではない;
ある language の意味論を全部理解するわけでもない;
単一 language lint の場所を奪うわけでもない;
repository constraint を宣言し、実行することに集中している。

だからこそ README、license、workflow、lockfile、JSONPath、directory structure、doc link、Unicode hygiene のような、一見ばらばらな対象が同じ tool に入ってくるわけです。これらは最初から 1 つの AST に住んでいないので、この層専用の tool が必要になるのは自然です。

公開情報の密度を見ると、単なるコンセプト実験ではなさそう

README から分かる範囲でも、alint はかなり情報密度があります。

GitHub page 上では 55 release が見える;
最新 release v0.13.0 は数日前に出たばかり;
README には 30 OSS repo config の例がある;
development section には 450+ tests と e2e scenario 構成が書かれている;
公式 site には benchmark、rules、cookbook、compare、roadmap への導線がそろっている。

これだけで「全面採用してよい成熟度」とまでは言えませんが、少なくとも作者が継続的な tool surface と docs を意識して育てていることは伝わります。

repository governance 系の tool は、機能そのもの以上に「どこから始めるか」「何を任せるべきか」を説明できることが重要です。alint はその点で比較的丁寧です。

もちろん万能ではない

この手の tool で気を付けたいのは、管理したいものを全部 lint に押し込まないことです。

公開情報を見る限り、alint 自体は比較的境界を保っていますが、使う側にはいくつか注意点があります。

rule を増やしすぎると governance system が複雑化する;
組織運用の問題まで何でも lint 化するのは逆効果になりうる;
過剰な rule は CI noise を増やす;
repository shape を守れても、設計判断そのものは代替できない。

なので実用的な始め方は、「何でもかんでも」ではなく、安定していて、繰り返し発生して、監査しやすく、language 横断な rule から tool に移すことだと思います。

例えば、

必須 file;
doc と directory の対応;
workflow 権限や書き方の下限;
config file の固定構造;
agent が何度も踏みがちな repository constraint。

こうした部分は、最初に自動化する価値が高いです。

まとめ

asamarts/alint の面白さは、新しい code lint を足すことではなく、多くの team が長く口頭で維持してきた repository の形の rule を、宣言可能・実行可能・agent 可読な constraint layer にまとめていることです。

ESLint、Clippy、Semgrep の代わりではなく、その外側にある repository hygiene を受け持つ。multi-language repo や monorepo、そして AI agent が直接 repository に触る workflow では、かなり実用的な方向だと思います。

もし「大事なのに誰も体系的に検査していない repository rule」が自分の team に多いなら、alint はその穴を埋める候補になりそうです。