apply-code-conventions

コード規約を適用する

スタイルの信頼できる情報源: スタイルとフォーマットは、プロジェクトで設定されたリンターに従います。このスキルはスタイル以外の振る舞いとアーキテクチャのガイダンスのみを追加します。Hotwire + Tailwind の詳細については、apply-stack-conventions を参照してください。

クイックリファレンス

トピック	ルール
原則	DRY、YAGNI、役立つ場面での PORO、CoC、KISS
コメント / タグ	なぜを説明する。タグ付きメモには実行可能なコンテキストが必要
ロギング	検証済みの単一メッセージ引数（通常は JSON ハッシュ）。補間は行わない。エラー時にはマスク済みのバックトレースを含める
深いスタック	apply-stack-conventions → ドメインスキル（services、jobs、RSpec）へチェーンする

HARD-GATE

TESTS GATE IMPLEMENTATION:
When this skill guides new behavior, the tests gate still applies:
PRD → TASKS → TEST (write, run, fail) → IMPLEMENTATION → …
No implementation code before a failing test. See write-tests.

コアプロセス

Rails コードをレビューまたはリファクタリングする際は、この順序に従ってください。各ステップは、出力における必須のチェックポイントに対応します。

1. リンターを実行する — 設定（例: .rubocop.yml または .standard.yml）を検出し、適切なツールを実行し、見つからない場合はその旨を記録します。出力: リンターを検出（または不在）。スタイルはそれに従う。
2. 領域固有のルールを適用する — パスパターンを確認し、「領域別の適用」表から的を絞ったガイダンスを適用します。出力: 該当する変更ファイルごとの、パス別の具体的な推奨事項。
3. テストゲートを検証する — 新しい振る舞いの前に、失敗するテストが存在することを確認します。出力: 失敗するスペック、実行コマンド、期待される失敗、最小限の実装ステップ、再実行の成功。
4. 構造化ロギングを徹底する — すべての Rails.logger 呼び出しが、インストールされたロガーの検証済み単一メッセージインターフェースを使用していることを確認します。エラーには event: フィールドとマスク済みバックトレースを含めます。出力: 以下のサブルールの構造化ロギングルールを適用する。
5. コメント規律を徹底する — すべてのタグ（TODO:、FIXME:）に実行可能なコンテキスト（担当者、チケット）があることを確認します。出力: 以下のサブルールのコメント規律ルールを適用する。
6. 専門スキルへチェーンする — 統合表を使用して、必要に応じてより深いガイダンス（セキュリティ、ジョブ、スペック）を取り込みます。

言語: 明示的に別途指定されない限り英語。

サブルール

コメントとタグ付きメモ

何をではなくなぜをコメントします。タグ — TODO: / FIXME: / HACK: / NOTE: / OPTIMIZE: — には実行可能なコンテキスト（担当者、チケット、次のステップ）が必要です。コンテキストのないタグはレビューで不合格となります。

# BAD — naked tag, no context
# TODO: fix this

# GOOD — TODO with next step + dependency
# TODO(jsmith, JIRA-1234): replace TIER_RATES with DB-backed lookup once billing API v2 is stable.

構造化ロギング

プロジェクトにインストールされたロガーインターフェースを使用します。標準の Ruby/Rails ロガーは1つのメッセージ引数を受け入れます。2引数の構造化呼び出しには、検証済みのカスタムアダプターが必要です。復旧境界で1回だけログを記録し、機密データをマスクし、予期しない例外を保持します。

rescue Timeout::Error => e
  Rails.logger.error({ event: "order.processing_failed", error_class: e.class.name, backtrace: e.backtrace&.first(5) }.to_json)
  raise
end

領域別の適用（パスパターン）

領域	パスパターン	ガイダンス
ActiveRecord パフォーマンス	app/models/**/*.rb	ループ内では eager load する。pluck / exists? / find_each を優先する。
コントローラー	app/controllers/**/*_controller.rb	ストロングパラメータ。アクションは薄く → サービスへ。IDOR / PII → security-check。
RSpec	spec/**/*_spec.rb	FactoryBot。eager なセットアップが必要でない限り let! より let を優先する。
サービスオブジェクト	app/services/**/*.rb	単一責任。.call / 依存性の注入。
バックグラウンドジョブ	app/jobs/**/*.rb / app/workers/**/*.rb	冪等性、リトライ、キューの選択、副作用の境界 → implement-background-job。

RSpec と let_it_be（test-prof）

test-prof がすでに Gemfile.lock にある場合にのみ let_it_be を推奨します。それ以外の場合はデフォルトで let を使用し、遅延評価が例を壊す場合にのみ let! に頼ります。依頼されない限り test-prof を導入しないでください。

拡張リソース（段階的開示）

これらのファイルは、その特定の内容が必要な場合にのみ読み込んでください:

• assets/checklist.md — 詳細なコードレビューチェックリストに使用します。
• assets/snippets.md — 一般的なパターンの簡単なコードスニペットに使用します。

読み込んだアセットとその理由を出力に記載し、プロセスを検証可能にしてください。

統合

スキル	チェーンするタイミング
apply-stack-conventions	スタック固有: PostgreSQL、Hotwire、Tailwind
model-domain	ドメインの概念と不変条件に対して、より明確な Rails ファーストのモデリング選択が必要なとき
create-service-object	サービスオブジェクトの実装または改善
implement-background-job	ワーカー、キュー、リトライ、冪等性
write-tests	Spec スタイル、テストゲート（red/green/refactor）、request spec と controller spec の比較
security-check	コントローラー、パラメータ、IDOR、PII
code-review	マージ前の完全な PR チェック