Skip to content
cccskills
FreePublished on GitHub

custom-linter-creator

各プログラミング言語の既存リンターエコシステムを活用してカスタム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」。

The English summary is being prepared. Showing the original description.

Run score Not tested

See how to install

Files included (2)

  • SKILL.md7.7 KB
  • references/language-ecosystems.md17.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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

各言語の既存リンターエコシステムを活用し、lints/ ディレクトリにカスタムlintルールを作成する。 エラーメッセージはAIエージェントへの修正指示プロンプトとして設計する。

基本概念

  • 既存エコシステム活用: フルスクラッチではなく、各言語の標準リンターにカスタムルールを追加する
  • AI向けエラーメッセージ: lint違反メッセージをAIが理解・実行できる修正指示として記述する
  • lints/ ディレクトリ: プロジェクトルートの lints/ にカスタムルールを配置する

言語別ガイド(クイックリンク)

詳細な実装手順は references/language-ecosystems.md を参照。

言語リンターツール詳細リンク
RustdylintRust (dylint)
TypeScript/JavaScriptESLintESLint
PythonpylintPython (pylint)
Gogolangci-lintGo (golangci-lint)

ワークフロー

1. 対象言語の特定

プロジェクトの言語を確認し、上記テーブルから適切なリンターを選択する。

確認項目:

  • プロジェクトのメイン言語を特定した
  • 対応するリンターツールがインストール可能か確認した

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

言語別ガイドに従い、lints/ ディレクトリを初期化する。

確認項目:

  • lints/ ディレクトリを作成した
  • 言語固有の設定ファイル(Cargo.toml / package.json 等)を配置した
  • エントリポイントファイルを作成した

検証: ls -la lints/ でファイル構造を確認する。

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

AI向けエラーメッセージテンプレートに従い、ルールを実装する。

確認項目:

  • ルールファイルを作成した
  • エラーメッセージをAI向け修正指示として記述した
  • テンプレートの5要素(違反内容・修正手順・コンテキスト・スコープ制限・理由)を含めた

検証: ルールファイルの構文エラーがないことを確認する。

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

プロジェクトのリンター設定にカスタムルールを追加する。

確認項目:

  • プロジェクトの設定ファイルにカスタムルールを登録した
  • ルールの重大度(error/warning)を設定した

検証: リンターの設定読み込みエラーがないことを確認する。

5. 動作確認

実行→検証→修正ループ:

  1. 実行: 意図的に違反コードを書き、リンターを実行する
  2. 検証: AI向けエラーメッセージが正しく出力されるか確認する
  3. 修正: メッセージが不明瞭なら修正し、再度実行する

言語別実行コマンド:

言語実行コマンド期待される出力
Rustcargo dylint --all違反箇所のファイルパス・行番号とAI向けメッセージ
TypeScript/JSnpx eslint .違反箇所とmessageIdに対応するメッセージ
Pythonpylint --load-plugins=lints.checkers.xxx src/メッセージコード(C9001等)と詳細メッセージ
Go./bin/linter ./... または golangci-lint run違反箇所の位置情報とメッセージ

確認項目:

  • 違反コードでエラーが検出された
  • エラーメッセージに5要素(違反内容・修正手順・コンテキスト・スコープ・理由)が含まれている
  • 修正後、エラーが解消された

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は責務が曖昧で、コードの意図が伝わりにくいため

設計指針

  1. 具体的な修正手順: 「修正してください」ではなく「snake_caseに変換し、全参照を更新する」
  2. ステップ番号付き: 複数手順がある場合は番号で順序を示す
  3. コンテキスト情報: 違反箇所のファイルパス・シンボル名・行番号を含める
  4. スコープ制限: 「修正対象以外のコードは変更しない」旨を明記する
  5. 理由の説明: なぜこのルールが存在するかを簡潔に記載する

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、 不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。 以下のいずれかに該当する場合は必ずこのスキルを使用すること: - 集約(Aggregate)の新規設計・実装・リファクタリング(どの言語でも) - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定(「AとBは同じ集約にすべきか?」「この集約は大きすぎるか?」) - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断(ドメインイベント、結果整合性、Sagaパターン) - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正 キーワード例:集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、 エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存(Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて)。 トリガー:「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル(deprecation cycle)の 制度化、互換層の局所化(Adapter/Strangler Fig)、契約テスト(CDC)による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存(Java, TypeScript, Go, Python, Rust等すべて)。 トリガー:「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合(永続化、JSON変換など)に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー:「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造(ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層)に基づく。特にインフラ層は 横断的関心事(ロギング、設定管理)のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー:「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

See all skills by j5ik2o

Report a problem with this skill