design-screenshot

Codex 互換性に関する注意：

• Codex では、リポジトリのスキルを $skill-name で呼び出します。このミラーコピーでは、従来の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーに関する要件：ワークフローまたはスキルの手順を実行する前に、すべての手順についてタスク追跡を作成または更新し、進捗に応じて同期してください。
• ユーザーへの質問を促す指示は、Codex でユーザーに直接質問することを意味します。
• Claude 固有のモード切り替え指示がある場合は無視してください。
• 厳格な実行契約：ユーザーがスキルを明示的に呼び出した場合は、記載どおりにそのスキルのプロトコルを実行してください。
• サブエージェントの承認：スキルがユーザーによって呼び出された場合、または AI が検出した場合に、そのプロトコルでサブエージェントが必要とされているなら、そのスキルの有効化によって、そのタスクに必要な spawn_agent サブエージェントの使用が許可されます。
• ユーザーが逸脱を事前に明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。
• ワークフロースキルでは、列挙された子スキルの各手順を明示的に実行し、各手順の証拠を報告してください。
• 必須の手順またはツールをこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

Codex プロジェクト参照の読み込み（フックなし）

Codex には、Claude のフックによるドキュメントの自動挿入機能はありません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、このルーティングに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むドキュメント：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー／テスト設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* 全体のカタログへの案内）
• docs/project-reference/lessons.md（常に適用するガードレールとアンチパターン）

状況に応じて読むドキュメント：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画、または TC のマッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：変更対象ファイルに応じて、上記のドメインドキュメントと code-review-rules.md

すべてのドキュメントを無差別に読まないでください。まず docs-index-reference.md を確認し、タスクに関連するファイルだけを開いてください。

概要

目標： スクリーンショットを分析し、デザインを機能するコードとして再現します。

ワークフロー：

1. 分析 — ビジョン機能を使ってスクリーンショットを処理します
2. 調査 — 一致するデザインパターンを探すために ui-ux-pro-max を実行します
3. 実装 — デザインサブエージェントを使って、デザインをコードとして再現します

主なルール：

• デザインに関する知見を得るため、必ず最初に ui-ux-pro-max を有効化してください
• スクリーンショットに可能な限り忠実に合わせてください
• 詳細なスクリーンショット分析には ai-multimodal を使用してください

懐疑的な姿勢を保ってください。批判的思考と段階的思考を適用してください。すべての主張について、追跡可能な証拠と確信度（Idea は 80% 超）を示してください。

必須スキル（優先順）

1. ui-ux-pro-max - デザイン知見データベース（必ず最初に有効化）
2. frontend-design - スクリーンショットの分析と再現

高品質を維持しながら、トークンを効率的に使用してください。

ワークフロー：

1. ai-multimodal スキルを使って、スクリーンショットの詳細を徹底的に説明します（デザインスタイル、トレンド、フォント、色、枠線、間隔、各要素の位置・サイズ・形状・質感・素材、光、影、反射、屈折、ぼかし、発光、画像、背景の透明度、トランジションなど）。
   • 重要： スクリーンショットに使われているフォント名（Google Fonts）とフォントサイズを予測してみてください。Inter や Poppins だけを使わないでください。
2. ui-ux-designer サブエージェントを使い、プログレッシブディスクロージャーの構成に沿ってデザイン計画を作成し、最終的な成果物がスクリーンショットと一致するようにします。
   • ## Naming セクションの命名パターンを使ってディレクトリを作成します。
   • 概要への入り口となる plan.md を保存します。内容は汎用的なものにし、80 行未満に収め、各フェーズのステータス／進捗とリンクを記載します。
   • 各フェーズについて、以下のセクションを含む phase-XX-phase-name.md ファイルを作成します（コンテキストへのリンク、日付／優先度／ステータスを含む概要、主なインサイト、要件、アーキテクチャ、関連するコードファイル、実装手順、ToDo リスト、成功基準、リスク評価、セキュリティ上の考慮事項、次のステップ）。
   • 各調査レポートの Markdown は、依頼されたすべての項目と引用を網羅しつつ、簡潔に（150 行以内に）まとめます。
3. 次に、計画に沿って順を追って実装します。
4. ユーザーから指定がない場合は、純粋な HTML／CSS／JS でデザインを作成します。
5. 変更内容を要約してユーザーに報告し、すべてを簡潔に説明したうえで、変更を確認して承認するよう依頼します。
6. ユーザーが変更を承認したら、必要に応じて ./docs/design-guidelines.md のドキュメントを更新します。

重要な注意事項：

• Dribbble、Behance、Awwwards、Mobbin、TheFWAで数々の賞を受賞したトップクラスのUI/UXデザイナーとしてのスキルを常に忘れないでください。
• AI による画像生成には ai-multimodal スキルを使い、画像や動画の生成、画像の編集などを行えることを忘れないでください。実際のアセットを使ったデザインを作成してください。
• 生成したアセットは、ai-multimodal スキルを使って必ず確認・分析し、品質を再確認してください。
• 必要に応じて、media-processing スキル（RMBG）を使って生成したアセットの背景を削除してください。
• ストーリー性のあるデザイン、没入感のある3D体験、マイクロインタラクション、インタラクティブなインターフェースを作成してください。
• 必要に応じて、./docs/design-guidelines.md のドキュメントを維持・更新してください。

---

[IMPORTANT] 作業を始める前に、ファイルの読み込みも含むすべての作業を小さなタスクに分割し、タスク管理してください。長いファイルによるコンテキストの喪失を防ぐためです。簡単なタスクの場合は、スキップするかどうかを必ずユーザーに確認してください。

よく考えて計画を立て、次のスクリーンショットに完全に従ってデザインを作成してください： $ARGUMENTS

スキルのバリエーション： デザインスキルのバリエーション — スクリーンショットから再現・実装します。

AIのミス防止 — すべてのタスクで、次の失敗パターンを避けてください：

削除する前に、後続の参照箇所を確認してください。 コンポーネントを削除すると、ドキュメントやコードが古くなる問題が連鎖します。削除に先立ち、参照しているファイルをすべて特定してください。 AIが生成した内容を実際のコードと照合してください。 AIはAPI、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントへの記載や参照を行う前に、必ず grep で存在を確認してください。 編集後は依存関係を最後までたどってください。 定義を変更しても、その定義から派生する下流の変数や利用箇所が漏れることがあります。依存関係を最後まで追跡してください。 正しさを検証する際は、すべてのコードパスをたどってください。 コードが存在することを確認しただけでは、実行されることの確認にはなりません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップも確認してください。 デバッグ時は、修正前に「どちらの責任か」を確認してください。 呼び出し元が誤ったデータを渡しているのか、呼び出し先が誤って処理しているのかを追跡してください。責任のあるレイヤーを修正し、症状が現れた箇所だけをパッチしないでください。 既存の値には意図があると考え、変更前に理由を確認してください。 定数、上限、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 複数のスタックに影響する変更では、すべての出力を検証してください。ひとつのチェックが成功しても、すべてのチェックが成功したことにはなりません。 全体を先に見るデバッグを行い、目の前の箇所だけにとらわれないでください。 失敗を調査する際は、まず前提条件をすべて列挙してください（設定、環境変数、DB名、エンドポイント、DI登録、データの前提条件）。その後、コードレイヤーに関する仮説を立てる前に、各項目を証拠と照らして確認してください。 変更は必要最小限にとどめ、差分を検証してください。 バグ修正では、変更するすべての行がバグに直接関係している必要があります。隣接するコードのスタイル変更や改善は行わないでください。機能強化のタスクでは、改善を実装し、その内容を明示してください。 実装前に曖昧さを明らかにし、黙って解釈を決めないでください。 依頼に複数の解釈がある場合は、それぞれの所要時間の見積もりとともに提示し、確認してください。全レコード対象、ファイルベース、または複雑な方法を前提にしてはいけません。

批判的思考の姿勢 — 批判的思考と段階的な思考を適用してください。実行に移す前に、すべての主張について追跡可能な証拠を確認し、確信度が80％を超えていることを確かめてください。 幻覚の防止： 推測を事実として提示してはいけません。すべての主張について情報源を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆる幻覚の根本原因です。

必ず注意してください： 批判的思考を適用してください。実行に移す前に、すべての主張について追跡可能な証拠を確認してください。幻覚を防止し、推測を事実として提示してはいけません。

必ず注意してください： AIのミス防止策を適用してください。全体を先に見るデバッグ、責任のあるレイヤーでの修正、実装前の曖昧さの提示、コンパクション後のファイルの再読を徹底してください。

最後のリマインダー

• 必須・重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな ToDo タスクに分割してください
• 必須・重要・必ず注意 新しいコードを作成する前に、コードベース内で類似パターンを 3 つ以上検索してください
• 必須・重要・必ず注意 すべての主張に file:line の根拠を示してください（確信度が 80％ を超える場合に実行）
• 必須・重要・必ず注意 作業品質を確認するための最終レビュー ToDo タスクを追加してください

[TASK-PLANNING] 作業を始める前に、タスクの範囲を分析し、タスク追跡を使って小さな ToDo タスクとサブタスクに体系的に分割してください。

フックレス・プロンプト・プロトコル・ミラー（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・必ず・重大。いかなる理由でも省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルの文面はプロジェクトに依存しないものとし、プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認します。共有 AI-SDD は shared/sdd-artifact-contract.md を適用してください。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されたプロジェクトリファレンス文書を開いてください。共有コンテキストとローカル文書を利用できる場合は、サポート対象のあらゆる AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップの組み合わせのほうが適しているかも評価します
3. 質問（必須形式）： ユーザーが明示的にワークフロー／スキルを呼び出しており、ローカルプロトコルでその明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します：
   • 質問：「どのワークフローを有効にしますか？」
   • オプション 1：「[最適なワークフロー] を有効にする（推奨）」
   • オプション 2：「カスタムワークフローを有効にする：[ステップ1 → ステップ2 → ...]」（理由を 1 行で記載）
4. 有効化（確認後）： 標準ワークフローには $workflow-start <workflowId> を呼び出します。カスタムのステップは手動で順に実行します
5. タスクの作成： すべてのワークフローステップについて、タスク追跡を使ってタスクを作成します
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と順序立てた思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が 80％ を超える場合に実行します。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を引用し、不確実性は率直に認め、出力に誤りがないか自己確認し、独立した情報源と相互参照し、自分の確信度にも懐疑的でいてください。根拠のない確信は、あらゆるハルシネーションの根源です。 AI 注意の原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、最も重要な 3 つのルールを冒頭と末尾の両方に配置し、長いコンテキストでも指示への準拠を保てるようにします。 目標主導の実行： まず成功基準を定義し、検証できるまで繰り返します。観察可能なチェックに合格した場合にのみ停止します。 テストで意図を検証： テストは、現在の動作をただ反映するだけでなく、ビジネスルールや不変条件を保護し、保護対象の意図が破られた場合に失敗するようにしてください。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分けて（タスク追跡を行って）ください。最後のタスクとして「AI のミスと教訓を分析する」を追加してください。

教訓を抽出する — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論や前提の誤り）に名前を付けます。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」。
2. 汎用性を確認します。この失敗モードは、3 つ以上の状況やコードベースに当てはまりますか？当てはまらない場合は、もう 1 段階抽象化してください。
3. 普遍的なルールとして記述します。プロジェクト固有の名前、パス、クラスを取り除き、どのコードベースでも役立つ内容にしてください。
4. まとめます。同じ失敗モードに起因する複数のミスは、1 つの教訓にまとめてください。
5. 再発確認：「このリマインダーがなくても、今後のセッションで再発しますか？」いいえの場合は、$learn を省略します。
6. 自動修正確認：「$code-review／$code-simplifier／$security／$lint で検出できますか？」はいの場合は、代わりにレビューのスキルを改善してください。
7. **両方の確認を通過した場合：**ユーザーに $learn の実行を依頼してください。 [TASK-PLANNING] [MANDATORY] ワークフローやスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成または更新してください。その後、各手順の開始時と完了時に、タスク追跡の内容を同期してください。