Skill.md検索

codex CLI を使用し、git diff ベースのコードレビュー（review モード）と特定ファイル指定レビュー（exec モード）を文脈に応じて自動選択できます。 未コミット変更・特定コミット・ベースブランチとの差分など、複数のレビュー対象方法から最適なものを選べます。 プロジェクト内ファイルと ~/.claude 設定ファイルを同時にアクセスでき、プロジェクト規約に基づいた正確なレビューが可能です。 アーキテクチャ・セキュリティ・依存関係など複数の観点から自動的にコードをレビューできます。 codex CLI を活用したコード品質チェックを自動化したい開発者 git の変更差分をプロジェクト規約に基づいてレビューしたいエンジニア セキュリティ（パストラバーサル）やアーキテクチャの依存方向を検査したい開発チーム AI が生成したコードを確実にレビューしたい組織 review モード（git diff ベース）：git rev-parse --is-inside-work-tree と git symbolic-ref refs/remotes/origin/HEAD で前提チェック＆ベースブランチ自動検出。未コミット変更デフォルト（--uncommitted）、--base でベースブランチ指定時は自動検出値使用。exec モード（ファイル指定）：絶対パス確認で Case A / B 判定。Case A（プロジェクトルート or ~/.claude 配下）は codex exec -C Git_Root --add-dir ~/.claude でコピー不要。Case B（外部ファイル）は /tmp にコピー → --skip-git-repo-check 付きで実行 → codex-review-cleanup.sh でクリーンアップ。レビュー指示デフォルト：アーキテクチャ・依存関係・セキュリティ・パストラバーサル・ユーザー入力検証等の観点で実施。

コンテンツビューワーアプリ専用のデザイン原則（コンテンツファースト、静かな上質感、機能美）に基づいて、React/Tailwindコンポーネントを一貫性を持って作成・修正できます。 トップページ、ブラウズページ、ビューワー画面など各画面の役割に応じて、適切なUI存在感レベルを保ちながらコンポーネント設計できます。 OS標準フォント（SF Pro Text/SF Mono等）を活用し、ウェブフォント不要な最適化されたタイポグラフィスケールを実装できます。 5段階の色彩階層（Base/Ground/Card/Raised/Overlay）と5段階のテキスト階層（Primary/Secondary/Tertiary/Subdued/Muted）を用いた統一感のあるカラースキームを構築できます。 ローカルコンテンツビューワー（画像・動画・PDF閲覧アプリ）の一貫性のあるUI設計を進めたいフロントエンド開発者 ビューワーのファイルブラウザ、ツールバー、検索機能など各UIコンポーネントを統一ルールで修正・改善したいデザイナー コンテンツを最大に魅せるための「静かで上質」なダークテーマデザインを実現したい制作チーム コンテンツビューワーのデザイン設計では、画像・動画・PDFというコンテンツを主役とし、UIは脇役に徹することを基本方針とします。3つの設計原則は「コンテンツファースト（ビューワー画面ではUI最小化、表示面積最大化）」「静かな上質感（派手な装飾ではなく素材の質感とディテールで品質を表現）」「機能美（すべての視覚要素に機能的理由があること）」です。画面ごとにUI存在感を調整し、トップページはブランド感（存在感高）、ブラウズ画面はサムネイルグリッド主役（存在感中）、ビューワー画面はツールバー半透明・非表示化（存在感低）とします。フォントスタックはOS標準フォント（UI: SF Pro Text/Segoe UI系、等幅: SF Mono/Cascadia Code系）を使用し、Google Fonts CDN不要で実装します。色彩は5段階サーフェス階層（Base #0a0a0f～Overlay #2a2a3d）と5段階テキスト階層（Primary～Muted）で体系化し、ダークテーマながら画像の色彩が引き立つ青系ニュートラルを採用しています。

赤・緑・リファクタリングサイクルで開発 - 先にテストを書いて失敗させ、最小限の実装でテストを通し、その後コードを整理する三段階プロセスで堅牢なコードを作成できます テスト実行結果を簡潔に把握 - test-runnerエージェントが自動的にテストコマンドを判別し、失敗したテストの詳細だけを抽出して表示するため、コンテキストを汚さずに効率的に開発できます 実装内容をTodoで計画確認 - 実装前に必ずタスク計画を作成してユーザーの確認を得られるため、方向性がズレたまま進む心配がありません 段階的にスラッシュコマンドで進行 - /tdd:red、/tdd:green、/tdd:refactorコマンドでフェーズごとに作業を進められ、TDDのサイクルを自然に実践できます テスト駆動開発（TDD）で開発品質を高めたい開発者・チーム バグの少ないコードを着実に進めたいプロジェクト リファクタリング時の動作検証を自動化したい人 複数の機能を並行開発する際、各フェーズの進捗を明確に管理したい開発チーム

モック過剰を防いで保守性の高いテストを作成 - 外部依存（API、データベース）以外のモック使用を制限することで、リファクタリング時に壊れにくいテストを書けます テストデータを分かりやすく管理 - fixtureに頼らずテストデータをテスト関数内に直接記述するため、各テストで何をテストしているかが一目で理解できます 1つのテストで1つの動作を検証 - 小粒度で明確なテストを書くことで、テスト失敗時に何が壊れたかすぐに特定できます テストの命名ルールで意図を明確化 - test___の形式で命名することで、テストの目的がコード上で一目瞭然になります テストコードの可読性や保守性に悩んでいる開発者 モックの使い過ぎでテストが脆弱になっている課題を解決したい人 テスト駆動開発（TDD）を実践しており、テストの品質を高めたい開発チーム テスト失敗時のデバッグ時間を短縮したい、または新しいメンバーがテストコードを理解しやすくしたい組織