| name | custom-linter-creator |
| description | 各プログラミング言語の既存リンターエコシステムを活用してカスタムlintルールを作成するスキル。 人間向けではなくAIエージェント向けのリンターであり、エラーメッセージはAIに対する修正指示プロンプトとして機能する。 Rust(dylint)、TypeScript/JavaScript(ESLint)、Python(pylint)、Go(golangci-lint)等、 言語ごとの標準的な方法でカスタムルールを `lints/` ディレクトリに作成する。 以下の場合に使用する: (1) プロジェクト固有のコーディングルールをAIに強制させたいとき、 (2) 違反時にAIが読める修正指示を出力するlintルールを作りたいとき、 (3) 命名規則・構造パターン・一貫性ルールをAI駆動のリンティングで強制したいとき。 トリガー: 「リンタールールを作成」「lintルールを追加」「このパターンを強制」 「AIリンター」「カスタムlint」「コードルール」「命名ルール」「構造ルール」 「create a linter rule」「add a lint rule」「enforce this pattern」「AI linter」。 |
カスタムリンタークリエイター
各言語の既存リンターエコシステムを活用し、lints/ ディレクトリにカスタムlintルールを作成する。
エラーメッセージはAIエージェントへの修正指示プロンプトとして設計する。
基本概念
- 既存エコシステム活用: フルスクラッチではなく、各言語の標準リンターにカスタムルールを追加する
- AI向けエラーメッセージ: lint違反メッセージをAIが理解・実行できる修正指示として記述する
lints/ ディレクトリ: プロジェクトルートの lints/ にカスタムルールを配置する
言語別ガイド（クイックリンク）
詳細な実装手順は references/language-ecosystems.md を参照。
ワークフロー
1. 対象言語の特定
プロジェクトの言語を確認し、上記テーブルから適切なリンターを選択する。
確認項目:
2. lints/ ディレクトリの初期化
言語別ガイドに従い、lints/ ディレクトリを初期化する。
確認項目:
検証: ls -la lints/ でファイル構造を確認する。
3. カスタムルールの実装
AI向けエラーメッセージテンプレートに従い、ルールを実装する。
確認項目:
検証: ルールファイルの構文エラーがないことを確認する。
4. リンター設定への統合
プロジェクトのリンター設定にカスタムルールを追加する。
確認項目:
検証: リンターの設定読み込みエラーがないことを確認する。
5. 動作確認
実行→検証→修正ループ:
- 実行: 意図的に違反コードを書き、リンターを実行する
- 検証: AI向けエラーメッセージが正しく出力されるか確認する
- 修正: メッセージが不明瞭なら修正し、再度実行する
言語別実行コマンド:
| 言語 | 実行コマンド | 期待される出力 |
|---|
| Rust | cargo dylint --all | 違反箇所のファイルパス・行番号とAI向けメッセージ |
| TypeScript/JS | npx eslint . | 違反箇所とmessageIdに対応するメッセージ |
| Python | pylint --load-plugins=lints.checkers.xxx src/ | メッセージコード(C9001等)と詳細メッセージ |
| Go | ./bin/linter ./... または golangci-lint run | 違反箇所の位置情報とメッセージ |
確認項目:
AI向けエラーメッセージテンプレート
すべてのカスタムルールは以下のテンプレートに従ってエラーメッセージを記述する。
テンプレート構造
[違反内容]: 何が違反しているかを1文で説明
修正手順:
1. [具体的なアクション1]
2. [具体的なアクション2]
3. [具体的なアクション3]
コンテキスト: {file_path}:{line_number} の {identifier}
スコープ: 修正対象以外のコードは変更しないこと
理由: このルールが存在する理由を簡潔に記載
注意: {identifier} はルールに応じた識別子名（モジュール名、クラス名、関数名等）に置き換える。
具体例
Rust (mod.rs禁止ルール):
このファイルは mod.rs を使用しているが、プロジェクト規約で禁止されている。
修正手順:
1. このファイルの内容を親ディレクトリ名.rs にコピーする
2. 例: src/actors/mod.rs → src/actors.rs に移動する
3. mod.rs ファイルを削除する
4. 他ファイルの use/mod 宣言に変更は不要（パスは同じ）
コンテキスト: {file_path}:{line_number} の {module_name}
スコープ: 対象ファイルとその移動先のみ変更すること
理由: Rust 2018 エディションのモジュールスタイルに統一するため
ESLint (曖昧サフィックス禁止ルール):
クラス '{class_name}' は曖昧なサフィックス '{suffix}' を使用している。
修正手順:
1. このクラスの責務を特定する（データアクセス？認証？調整？）
2. 責務を具体的に表す名前に変更する
例: UserManager → UserRepository / UserAuthenticator / UserCoordinator
3. このクラスへの全参照を新しい名前に更新する
コンテキスト: {file_path}:{line_number} の {class_name}
スコープ: クラス定義とその参照のみ変更すること
理由: Managerは責務が曖昧で、コードの意図が伝わりにくいため
設計指針
- 具体的な修正手順: 「修正してください」ではなく「snake_caseに変換し、全参照を更新する」
- ステップ番号付き: 複数手順がある場合は番号で順序を示す
- コンテキスト情報: 違反箇所のファイルパス・シンボル名・行番号を含める
- スコープ制限: 「修正対象以外のコードは変更しない」旨を明記する
- 理由の説明: なぜこのルールが存在するかを簡潔に記載する
