coding-standards-enforcer

コーディング標準の適用

クイックスタート

Swift ソースの変更が対象であり、コードがリポジトリの並行処理、オブザーバビリティ、最新 API の標準に準拠しているかどうかを確認する場合は、いつでもこのスキルを使用します。

1. まず作業を分類します。
   • Swift 6.2 のビルド設定／言語モードの問題
   • Swift の MainActor／アクター分離／Sendable の問題
   • Observation の @Observable／SwiftUI の @State／@Bindable の所有権に関する問題
   • 最新 API／スタイル／安全性のクリーンアップ
2. 該当するカテゴリのリファレンスファイルのみを読み込みます。
3. 次の順序で変更箇所を確認します。
   • コンパイラ診断と分離境界
   • 所有権とオブザーバビリティのモデル
   • API の最新化と安全性
4. 標準からの逸脱を明示的に修正または指摘します。標準違反を暗黙のままにしないでください。

次の場合にリファレンスを読み込む

リファレンス	使用するタイミング
references/standards-review-map.md	レビューの順序、振り分け、リポジトリレベルの標準マップが必要な場合。
references/concurrency-guidelines.md	アクター、@MainActor、Sendable、Task、async let、タスクグループ、厳密な並行処理の診断を扱う場合。
references/observation-modeling.md	Observation の @Observable、@ObservationIgnored、SwiftUI の @State、@Bindable、@Binding、型付き環境データフローを扱う場合。
references/modern-swift-apis.md	API の最新化、Foundation の置き換え、書式設定、文字列の照合、強制アンラップ、Swift ネイティブのスタイルを扱う場合。

ワークフロー

1. 変更された Swift ファイルを確認し、主な問題の種類を特定します。
2. 関連する最小限のリファレンスファイルを読み込みます。
3. 準拠状態に戻すための最小限の変更を適用します。
4. 可能であれば、影響を受ける範囲をビルドするか、テストを再実行します。
5. 修正した内容、意図的に変更しなかった内容、残っている移行課題をまとめます。

スキルを切り替えるタイミング

• 主な問題がシーンの所有権、機能の分解、または複数の画面間での状態配置である場合は、spatial-app-architecture に切り替えます。
• 主な障害がビルドエラー、または標準の修正後も再現が必要な実行時の問題である場合は、build-run-debug に切り替えます。
• 主な作業が標準違反の直接的な修正ではなく、失敗しているテスト範囲の絞り込みである場合は、test-triage に切り替えます。

ガードレール

• 一律に @MainActor ポリシーを適用しないでください。分離の選択は、所有権と実行時の動作に合致させる必要があります。
• 新しい SwiftUI または visionOS のコードでは、ユーザーが互換性上の制約を明示する場合、または既存のアーキテクチャが Combine ベースのオブザーバビリティからまだ移行できない場合を除き、ObservableObject、@StateObject、@ObservedObject を導入しないでください。
• Observation の所有権については、ここで @Observable、@State、@Bindable のルールを重複させず、observation-modeling.md を読み込んでください。
• 不要な Task.detached、DispatchQueue.main.async、@unchecked Sendable を導入して、並行処理の警告を「修正」しないでください。
• 記憶だけを頼りに Swift 6.2 のデフォルトのアクター分離を判断しないでください。その選択が修正に影響する場合は、プロジェクトのビルド設定を確認してください。
• 意味が変わる場合は、API を機械的に最新化しないでください。

出力時の要件

次の内容を提示してください。

• レビューしたファイルまたはシンボル
• 適用した標準カテゴリ
• 修正した、または残っている具体的な違反
• 使用した検証手順
• 障害が標準に関する問題ではなくなった場合に使用する次のスキル