本文へ移動
cccskills
無料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」。

j5ik2o/okite-ai
インストール方法を見る

含まれるファイル（2）

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

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

各言語の既存リンターエコシステムを活用し、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. 理由の説明: なぜこのルールが存在するかを簡潔に記載する

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

aggregate-design

無料日本語概要

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、集約の分割、真の不変条件

j5ik2o/okite-ai802026年4月25日 更新

aggregate-transaction-boundary

無料日本語概要

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

j5ik2o/okite-ai802026年4月25日 更新

backward-compat-governance

無料日本語概要

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

j5ik2o/okite-ai802026年4月25日 更新

breach-encapsulation-naming

無料日本語概要

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

j5ik2o/okite-ai802026年4月25日 更新

clean-architecture

無料日本語概要

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

j5ik2o/okite-ai802026年4月25日 更新

cqrs-aggregate-modeling

無料日本語概要

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

j5ik2o/okite-ai802026年4月25日 更新

j5ik2o のスキルをすべて見る

このスキルの問題を報告する