Back to Details

custom-linter-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

カスタムリンタークリエイター

Custom Linter Creator

各言語の既存リンターエコシステムを活用し、
lints/
ディレクトリにカスタムlintルールを作成する。 エラーメッセージはAIエージェントへの修正指示プロンプトとして設計する。
Leverage the existing linter ecosystems of each language to create custom lint rules in the 
lints/
directory. Error messages are designed as correction instruction prompts for AI Agents.

基本概念

Core Concepts

  • 既存エコシステム活用: フルスクラッチではなく、各言語の標準リンターにカスタムルールを追加する
  • AI向けエラーメッセージ: lint違反メッセージをAIが理解・実行できる修正指示として記述する
  • lints/
    ディレクトリ    : プロジェクトルートの 
    lints/
    にカスタムルールを配置する
  • Leverage existing ecosystems: Add custom rules to the standard linter of each language instead of building a linter from scratch
  • AI-oriented error messages: Write lint violation messages as correction instructions that AI can understand and execute
  • lints/
    directory    : Place custom rules in the 
    lints/
    directory at the project root

言語別ガイド（クイックリンク）

Language-specific Guides (Quick Links)

詳細な実装手順は references/language-ecosystems.md を参照。
言語リンターツール詳細リンク
RustdylintRust (dylint)
TypeScript/JavaScriptESLintESLint
PythonpylintPython (pylint)
Gogolangci-lintGo (golangci-lint)
Refer to references/language-ecosystems.md for detailed implementation steps.
LanguageLinter ToolDetails Link
RustdylintRust (dylint)
TypeScript/JavaScriptESLintESLint
PythonpylintPython (pylint)
Gogolangci-lintGo (golangci-lint)

ワークフロー

Workflow

1. 対象言語の特定

1. Identify the target language

プロジェクトの言語を確認し、上記テーブルから適切なリンターを選択する。
確認項目:
  • プロジェクトのメイン言語を特定した
  • 対応するリンターツールがインストール可能か確認した
Confirm the language of the project, and select the appropriate linter from the table above.
Check items:
  • Identified the main language of the project
  • Confirmed that the corresponding linter tool can be installed

2. 
lints/
ディレクトリの初期化

2. Initialize the 
lints/
directory

言語別ガイドに従い、
lints/
ディレクトリを初期化する。
確認項目:
  • lints/
    ディレクトリを作成した
  • 言語固有の設定ファイル（Cargo.toml / package.json 等）を配置した
  • エントリポイントファイルを作成した
検証: 
ls -la lints/
でファイル構造を確認する。
Initialize the 
lints/
directory according to the language-specific guide.
Check items:
  • Created the 
    lints/
    directory
  • Placed language-specific configuration files (such as Cargo.toml / package.json)
  • Created the entry point file
Verification: Check the file structure with 
ls -la lints/
.

3. カスタムルールの実装

3. Implement custom rules

AI向けエラーメッセージテンプレートに従い、ルールを実装する。
確認項目:
  • ルールファイルを作成した
  • エラーメッセージをAI向け修正指示として記述した
  • テンプレートの5要素（違反内容・修正手順・コンテキスト・スコープ制限・理由）を含めた
検証: ルールファイルの構文エラーがないことを確認する。
Implement the rules according to the AI-oriented error message template.
Check items:
  • Created the rule file
  • Wrote the error message as a correction instruction for AI
  • Included the 5 elements of the template (violation content, correction steps, context, scope restriction, reason)
Verification: Confirm that there are no syntax errors in the rule file.

4. リンター設定への統合

4. Integrate into linter configuration

プロジェクトのリンター設定にカスタムルールを追加する。
確認項目:
  • プロジェクトの設定ファイルにカスタムルールを登録した
  • ルールの重大度（error/warning）を設定した
検証: リンターの設定読み込みエラーがないことを確認する。
Add custom rules to the project's linter configuration.
Check items:
  • Registered custom rules in the project's configuration file
  • Set the severity level (error/warning) of the rules
Verification: Confirm that there are no errors when the linter loads the configuration.

5. 動作確認

5. Verify functionality

実行→検証→修正ループ:
  1. 実行: 意図的に違反コードを書き、リンターを実行する
  2. 検証: AI向けエラーメッセージが正しく出力されるか確認する
  3. 修正: メッセージが不明瞭なら修正し、再度実行する
言語別実行コマンド:
言語実行コマンド期待される出力
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
違反箇所の位置情報とメッセージ
確認項目:
  • 違反コードでエラーが検出された
  • エラーメッセージに5要素（違反内容・修正手順・コンテキスト・スコープ・理由）が含まれている
  • 修正後、エラーが解消された
Execution → Verification → Correction Loop:
  1. Execution: Write code that intentionally violates the rule, then run the linter
  2. Verification: Confirm that the AI-oriented error message is output correctly
  3. Correction: If the message is unclear, modify it and run the linter again
Language-specific execution commands:
LanguageExecution CommandExpected Output
Rust
cargo dylint --all
File path, line number of the violation, and AI-oriented message
TypeScript/JS
npx eslint .
Violation location and message corresponding to the messageId
Python
pylint --load-plugins=lints.checkers.xxx src/
Message code (such as C9001) and detailed message
Go
./bin/linter ./...
or 
golangci-lint run
Location information of the violation and message
Check items:
  • The error is detected in the intentionally violating code
  • The error message contains the 5 elements (violation content, correction steps, context, scope, reason)
  • The error is resolved after correction

AI向けエラーメッセージテンプレート

AI-oriented Error Message Template

すべてのカスタムルールは以下のテンプレートに従ってエラーメッセージを記述する。
All custom rules shall write error messages according to the following template.

テンプレート構造

Template Structure

[違反内容]: 何が違反しているかを1文で説明
修正手順:
1. [具体的なアクション1]
2. [具体的なアクション2]
3. [具体的なアクション3]
コンテキスト: {file_path}:{line_number} の {identifier}
スコープ: 修正対象以外のコードは変更しないこと
理由: このルールが存在する理由を簡潔に記載
注意: 
{identifier}
はルールに応じた識別子名（モジュール名、クラス名、関数名等）に置き換える。
[違反内容]: 何が違反しているかを1文で説明
修正手順:
1. [具体的なアクション1]
2. [具体的なアクション2]
3. [具体的なアクション3]
コンテキスト: {file_path}:{line_number} の {identifier}
スコープ: 修正対象以外のコードは変更しないこと
理由: このルールが存在する理由を簡潔に記載
Note: Replace 
{identifier}
with the identifier name corresponding to the rule (module name, class name, function name, etc.).

具体例

Specific Examples

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は責務が曖昧で、コードの意図が伝わりにくいため
Rust (mod.rs prohibition rule):
このファイルは 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 (ambiguous suffix prohibition rule):
クラス '{class_name}' は曖昧なサフィックス '{suffix}' を使用している。
修正手順:
1. このクラスの責務を特定する（データアクセス？認証？調整？）
2. 責務を具体的に表す名前に変更する
   例: UserManager → UserRepository / UserAuthenticator / UserCoordinator
3. このクラスへの全参照を新しい名前に更新する
コンテキスト: {file_path}:{line_number} の {class_name}
スコープ: クラス定義とその参照のみ変更すること
理由: Managerは責務が曖昧で、コードの意図が伝わりにくいため

設計指針

Design Guidelines

  1. 具体的な修正手順: 「修正してください」ではなく「snake_caseに変換し、全参照を更新する」
  2. ステップ番号付き: 複数手順がある場合は番号で順序を示す
  3. コンテキスト情報: 違反箇所のファイルパス・シンボル名・行番号を含める
  4. スコープ制限: 「修正対象以外のコードは変更しない」旨を明記する
  5. 理由の説明: なぜこのルールが存在するかを簡潔に記載する
  1. Specific correction steps: Do not use vague descriptions like "Please fix it", use specific instructions such as "Convert to snake_case and update all references"
  2. Numbered steps: Use numbers to indicate the order when there are multiple steps
  3. Context information: Include the file path, symbol name, and line number of the violation location
  4. Scope restriction: Clearly state that "code other than the correction target shall not be modified"
  5. Explanation of reason: Briefly describe why this rule exists