Custom Linter Creator

lints/

Core Concepts

• 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)

Workflow

1. Identify the target language

• Identified the main language of the project
• Confirmed that the corresponding linter tool can be installed

2. Initialize the

lints/

directory

lints/

• Created the

  lints/

  directory
• Placed language-specific configuration files (such as Cargo.toml / package.json)
• Created the entry point file

ls -la lints/

3. Implement custom rules

• 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)

4. Integrate into linter configuration

• Registered custom rules in the project's configuration file
• Set the severity level (error/warning) of the rules

5. Verify functionality

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

cargo dylint --all

npx eslint .

pylint --load-plugins=lints.checkers.xxx src/

./bin/linter ./...

golangci-lint run

• 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-oriented Error Message Template

Template Structure

[違反内容]: 何が違反しているかを1文で説明
修正手順:
1. [具体的なアクション1]
2. [具体的なアクション2]
3. [具体的なアクション3]
コンテキスト: {file_path}:{line_number} の {identifier}
スコープ: 修正対象以外のコードは変更しないこと
理由: このルールが存在する理由を簡潔に記載

{identifier}

Specific Examples

このファイルは 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 エディションのモジュールスタイルに統一するため

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

Design Guidelines

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