okite-ai

Pull Request をグリーンにするスキル。CI チェックの失敗解消と、PR に紐づく Issue の 修正・クローズを一括で実行する。GitHub Actions の CI ログ分析、ローカル CI （`./scripts/ci-check.sh`）の実行、エラーの根本原因特定と修正、PR コメントや リンクされた Issue の解消を含む。解消した Issue は確認後にクローズする。 ループモード（`/loop 5 /pr-green`）にも対応し、自律的に CI 監視・修正・プッシュを繰り返す。 トリガー：「PR をグリーンにして」「CI を通して」「CI エラーを直して」 「PR の issue を解消して」「PR を修正して」「CI が落ちている」「テストが失敗している」 「PR のレビュー指摘を直して」「PR を mergeable にして」 といった PR 修正・CI 解消関連リクエストで起動。PR 番号が指定されなくても、 現在のブランチから自動検出して対応する。

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

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

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

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

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

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

CQRSの実装においてイベントソーシングが必然的に必要となる理由を論理的に説明する。 C側からQ側へのデータ同期問題（計算された値の同期不可、トリガーの限界、ポーリングの スケーラビリティ問題、ダブルコミット問題）を段階的に分析し、イベントを真のデータソースに する設計への到達過程を示す。CQRS導入検討、アーキテクチャ設計時に使用。 対象言語: 言語非依存。 トリガー：「CQRSにイベントソーシングは必要か」「C側とQ側の同期方法」 「CQRSでモデルを分ける必要はないのか」「リードモデルの更新方法」 「なぜイベントソーシングが必要か」「ダブルコミット問題」「CQRSの同期問題」 「CQRSはESなしでも動くか」といったCQRS/ES必然性関連リクエストで起動。

CQRS（Command Query Responsibility Segregation）における一貫性・可用性・スケーラビリティの トレードオフ分析と設計判断を支援する。CAP定理に基づくCQRSの評価軸、イベントソーシングとの 組み合わせによる影響、読み書きモデルの分離戦略を提供する。アーキテクチャ設計、技術選定、 既存システムのCQRS導入検討時に使用。 対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。 トリガー：「CQRSを採用すべきか」「読み書き分離の設計」「結果整合性の判断」 「イベントソーシングを組み合わせるべきか」「CQRSのトレードオフ」「CQRSの可用性」 「CQRSのスケーラビリティ」「書き込みモデルと読み込みモデルの分離」 といったCQRS設計判断関連リクエストで起動。

集約間の制約チェック（「集約Aのユースケースで集約Bの状態を確認したい」）に対する 設計判断を支援する。Sagaの誤用検出、ビジネス要件の問い直し、CQRS/ESにおける 技術的制約の理解、不整合データの許容判断を含む。 コードレビュー、アーキテクチャ設計、要件分析時に集約間の制約問題に直面した場合に使用。 対象言語: 言語非依存。 トリガー：「集約間の制約チェック」「他の集約の状態を確認したい」「Sagaで制約チェック」 「ブランドに商品が紐づいているか確認」「集約間のバリデーション」 「イベントソーシングで逆引き」「集約をまたぐビジネスルール」「CQRS/ESの制約」 「コマンド側からリードモデルを参照していい？」「ユースケースで他の集約を参照」 といった集約間制約関連リクエストで起動。

DDDのモジュールパターンに基づくドメイン層パッケージングガイド。技術駆動パッケージング （entities/, value-objects/, services/, repositories/等）を検出し、ドメイン用語ベースの パッケージングへの修正を促す。ドメイン層においてモジュール名がユビキタス言語の一部となるよう導く。 トリガー：「ドメイン層のパッケージ構造」「DDDのモジュール設計」「技術駆動パッケージングを直したい」 「entities/フォルダをやめたい」「ドメインパッケージのレビュー」等のドメインモジュール関連リクエストで起動。

DDDのビルディングブロック（値オブジェクト、エンティティ、集約、ドメインサービス）の設計ガイド。 ドメインモデリング、エンティティ設計、集約境界の決定、値オブジェクトの実装時に使用。 トリガー：「値オブジェクトを作りたい」「集約の設計」「ドメインサービスの書き方」 「エンティティと値オブジェクトの違い」「DDDで実装したい」等のドメインモデリング関連リクエストで起動。

既存コード（DDDを前提としていない）を分析し、ドメインモデル（集約、ローカルエンティティ、 値オブジェクト、ドメインサービス）を擬似コード付きで提案するスキル。プロパティ・メソッド・ 不変条件・集約境界を含む設計を提案する。対象言語: 言語非依存。 トリガー：「既存コードからドメインモデルを抽出して」「このコードをDDDで再設計したい」 「ドメインモデルを提案して」「集約を見つけたい」「DDDに移行したい」 「既存コードを分析してドメインモデルを作って」「レガシーコードをDDDに」 といった既存コード分析・ドメインモデル抽出リクエストで起動。

ドメインモデル中心の開発手順ガイド。テストファーストでドメインモデルを設計・実装し、 インメモリリポジトリ→ユースケース→インフラの順で開発を進める手法を解説。 トリガー：「ドメインモデルから始めたい」「TDDでDDD」「インメモリリポジトリの作り方」 「ユースケースのテスト方法」「DDD開発の進め方」等の開発プロセス関連リクエストで起動。

Domain PrimitivesとAlways-Valid Domain Modelの設計原則に基づき、ドメインモデルの型安全性と不変条件を 保証する設計・実装を支援する。プリミティブ型の濫用を防ぎ、構築時検証・不変性・自己完結性を備えた ドメイン固有の型を設計する。コードレビュー、新規実装、リファクタリング時に使用。 対象言語: Rust, TypeScript, Java。他の言語（Kotlin, Scala, Go, Python等）にも応用可能。 トリガー：「ドメインプリミティブを作りたい」「Always-Validなモデルを設計」「プリミティブ型をラップしたい」 「構築時に検証したい」「無効な状態を型で防ぎたい」「Smart Constructorパターン」等のリクエストで起動。

ソフトウェアにおける非正常状態（Error, Defect, Fault, Failure）の分類と定義を提供する。 JIS規格・JSTQB・Bertrand Meyer等の複数の標準に基づき、各概念の違いを明確化し、 適切なエラー設計・障害対策の判断を支援する。エラー設計、障害分析、コードレビュー、 テスト設計時に用語の混乱を防ぎ、正確な分類に基づく対処戦略の選択に使用。 対象言語: 言語非依存。 トリガー：「ErrorとFaultの違い」「DefectとBugの関係」「障害と故障の区別」 「エラーの分類」「Failureとは何か」「非正常状態の設計」「エラー用語の定義」 「エラーと欠陥の違い」「faultとfailureの違い」 といったエラー分類・用語定義関連リクエストで起動。

エラーハンドリングのベストプラクティスを適用するスキル。回復可能性を基準にしたエラー設計、 Either/Result型の使用、ドメインエラーとシステムエラーの適切な分類を支援する。コードレビュー、 新規実装、リファクタリング時にエラー処理パターンの改善が必要な場合に使用。対象言語: Go, Rust, Scala, Java, TypeScript, JavaScript, Python。トリガー：「エラー処理を改善して」 「Result型を使いたい」「例外設計をレビューして」「回復可能なエラーの設計」といった エラーハンドリング関連リクエストで起動。

ファーストクラスコレクションパターンの設計・実装を支援。コレクションをラップする専用クラスの 設計、ドメインロジックの集約、不変性の確保をガイド。コードレビュー、新規実装、リファクタリング 時にコレクション操作ロジックが散在している場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust。 トリガー：「コレクションをラップしたい」「リストのロジックを集約」「ファーストクラスコレクション」 「コレクション操作が散在」「List<Order>をOrdersクラスに」といったコレクション設計関連リクエストで起動。

字面の同一性ではなく意図（目的）の同一性に基づいてコードの共通化を判断するスキル。 DRY原則の誤適用（字面が同じだが意図が異なるコードの共通化）を検出し、正しい共通化判定を 支援する。コードレビュー、リファクタリング、新規実装時に重複コードの扱いを判断する場合に使用。 対象言語: 言語非依存（Rust, Java, TypeScript, Go, Python, Kotlin, Scala等すべて）。 トリガー：「重複コードを共通化したい」「DRYに従いたい」「似たコードがある」 「この2つの関数をまとめたい」「コードの重複を減らしたい」「共通化すべきか」 「リファクタリングで共通関数にしたい」といった重複コード・共通化関連リクエストで起動。

デメテルの法則（最小知識の原則）に基づくコードレビューと設計支援。オブジェクトの連鎖呼び出し （Train Wreck）を検出し、直接の友人とのみ会話する設計へ変換する。結合度の低減と 変更容易性の向上を促進する。コードレビュー、新規実装、リファクタリング時に オブジェクト間の結合が深い場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust。 トリガー：「デメテルの法則」「連鎖呼び出しを減らしたい」「Train Wreckを直して」 「結合度を下げたい」「ドット連鎖が多い」「最小知識の原則」「Law of Demeter」 といったオブジェクト間結合関連リクエストで起動。

乱雑なコードベースを、明確なパッケージ/モジュール構造に再設計するための指針。 対象は (1) 乱雑なコードの再整理、(2) 単一巨大モジュールの分割、 (3) パッケージ境界のレビュー、(4) 新規プロジェクトのモジュール階層設計。 トリガー：「パッケージ構造を見直したい」「モジュールの依存関係が複雑」 「ファイル配置を整理したい」「循環依存を解消したい」といった構造改善リクエストで起動。

「Parse, don't validate」原則に基づくコードレビューと設計支援。validateパターン（チェックして結果を捨てる） をparseパターン（チェック結果を型で保持）に変換し、型システムで不変式を強制する設計を促進する。 コードレビュー、新規実装、リファクタリング時にvalidation関数の改善が必要な場合に使用。 対象言語: Rust, Haskell, TypeScript, Scala, Java, Go, Python。 トリガー：「バリデーションを改善して」「型で保証したい」「shotgun parsingを直して」 「不正な状態を型で防ぎたい」「Maybeを減らしたい」といった型安全性関連リクエストで起動。

Apache Pekko + Scala 3によるCQRS/Event Sourcing実装ガイド。 PersistenceEffectorを用いた集約アクター、ドメインモデルとアクターの分離、 状態遷移の型安全な表現、イベント設計、Protocol Buffersシリアライズ、 ZIOベースのユースケース層、リードモデルアップデータの実装パターンを提供する。 対象言語: Scala 3限定。CQRS/Event Sourcingアーキテクチャが前提の場合のみ使用。 トリガー条件: 「Scala」かつ「CQRS」または「Event Sourcing」または「Pekko」が リクエストに含まれる場合のみ起動。Scala以外の言語やCQRS/ES以外のアーキテクチャでは このスキルを使用してはならない。 トリガー：「PekkoでCQRS/ESを実装したい」「Scalaで集約アクターを書きたい」 「PersistenceEffectorの使い方」「Pekkoのイベントソーシング」 「ScalaでCQRSのコマンド側を実装」「Pekkoで状態遷移を管理」 といったPekko + Scala + CQRS/ES実装リクエストで起動。 非トリガー：「CQRSのトレードオフ」「イベントソーシングとは」「JavaでCQRS」 「GoでEvent Sourcing」「CQRSの概念を教えて」など、Scala/Pekko以外や概念的な質問では 起動してはならない。

既存コードベースのパッケージ/モジュール構造を分析し、リファクタリングを実行する。 循環依存の検出・解消、神モジュールの分割、責務分離の実施、移行計画の作成と実行を行う。 トリガー：「この依存関係を整理して」「循環依存を解消して」「このモジュールを分割して」 「リファクタリングして」といった既存コードの構造改善実行リクエストで起動。 設計指針が必要な場合は package-design スキルを参照。

DDDにおけるリポジトリの設計ルールとアンチパターンを提供する。集約単位の命名規則、 CQS（Command Query Separation）に基づくメソッド設計、入出力の型制約をチェックする。 コードレビュー、新規実装、リファクタリング時にリポジトリ設計の問題を検出する場合に使用。 対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。 トリガー：「リポジトリの設計をレビュー」「Repository名がおかしい」「findByIdの戻り値」 「リポジトリがDTOを返している」「テーブル名でリポジトリを作ってしまった」 「集約単位のリポジトリ」「リポジトリのアンチパターン」「リポジトリのCQS」 といったリポジトリ設計関連リクエストで起動。

リポジトリインターフェースの配置場所に関するガイド。クリーンアーキテクチャにおいて リポジトリインターフェースをドメイン層ではなくユースケース層に配置すべき理由を解説。 ドメインモデルとリポジトリの結合防止、構造による設計意図の強制を主眼とする。 トリガー：「リポジトリをどこに置く」「リポジトリインターフェースの配置」「ドメイン層にリポジトリ」 「クリーンアーキテクチャでリポジトリ」等のリポジトリ配置関連リクエストで起動。

「Tell, Don't Ask」原則に基づくコードレビューと設計支援。オブジェクトの状態を問い合わせて 外部で判断するパターンを、オブジェクトに直接命じるパターンに変換する。カプセル化を強化し、 責任をデータを持つオブジェクトに集約する設計を促進する。コードレビュー、新規実装、 リファクタリング時にgetterの乱用やFeature Envyの改善が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust。 トリガー：「getterを減らしたい」「カプセル化を改善して」「Feature Envyを直して」 「オブジェクトに責任を持たせたい」「デメテルの法則」といったOOP設計関連リクエストで起動。

プリミティブ型をドメイン固有型でラップすべきか否かの判断を支援する。 Primitive Obsession（プリミティブ型の過剰使用）と Value Object Obsession（過剰なラップ）の 両極端を避け、投資対効果に基づく合理的な判断基準を提供する。 Value Objectの定義が文脈（PofEAA/DDD/一般）で異なることによる用語混乱の防止も含む。 コードレビュー、新規実装、設計議論時にプリミティブ型のラップ判断が必要な場合に使用。 対象言語: 言語非依存（Rust, TypeScript, Java, Kotlin, Scala, Go, Python等すべて）。 トリガー：「この値をラップすべきか」「プリミティブ型のままでいいか」 「Value Objectにすべきか」「型を作りすぎでは」「Primitive Obsession」 「ラップしすぎ」「型が多すぎる」「Stringのままでいいか」 といったプリミティブ型ラップ判断関連リクエストで起動。

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Codex's capabilities with specialized knowledge, workflows, or tool integrations.

Install Codex skills into $CODEX_HOME/skills from a curated list or a GitHub repo path. Use when a user asks to list installable skills, install a curated skill, or install a skill from another repo (including private repos).

Creates Claude Code rules (.claude/rules/*.md) with YAML frontmatter and path-specific scoping. Use when creating project rules, coding standards, or conditional guidelines for specific file types.

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

GitHub OSS向け README.md の作成・改善・レビューを支援する。What/Why/How to start/Help/Maintainers の軸で情報を整理し、最短で動かせる Quickstart と docs への導線を構成する。 READMEの新規作成、既存READMEの再構成、READMEレビュー、ドキュメント分割の判断時に使用する。 トリガー：「READMEを作って」「READMEを改善して」「Quickstartを追加して」 「GitHub向けREADMEテンプレ」「READMEをレビューして」などのREADME関連リクエスト。

スキルディレクトリを `.claude/skills/{name}` から `.agents/skills/{name}` へ移動し、 `.claude/skills/{name}` と `.codex/skills/{name}` の両方からシンボリックリンクを作成するマイグレーションスキル。 スキルの実体を `.agents/skills/` に一元化し、Claude Code と Codex CLI の両方から 参照可能にするディレクトリ構成を実現する。引数としてスキル名が必須。 トリガー：「スキルを .agents に移動」「スキルをマイグレート」「シンボリックリンクを作成」 「migrate skill」「スキルの配置を統一」といったスキル配置変更リクエストで起動。

Claude Codeスキルを公式ベストプラクティスに基づいてレビューする。SKILL.mdファイルのレビュー、 スキル品質のチェック、スキル構造の検証、改善提案が必要な場合に使用。 トリガー：「このスキルをレビューして」「スキル品質をチェック」「SKILL.mdを検証」 「このスキルを改善」などのスキルレビューリクエストで起動。