design-describe

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 から始め、タスクに関連するファイルだけを開いてください。

クイックサマリー

目標： スクリーンショットまたは動画を分析し、UI デザインを詳細に記述します。

ワークフロー：

1. 分析 — ビジョン機能を使用して視覚的な入力（スクリーンショット／動画）を処理します
2. 記述 — レイアウト、色、タイポグラフィ、インタラクションを詳しく記述します

主なルール：

• 画像／動画の分析には ai-multimodal スキルを使用します
• デザイン要素（レイアウト、間隔、色、タイポグラフィ、インタラクション）に注目します

懐疑的な姿勢を保ち、批判的思考と順を追った思考を適用してください。すべての主張には追跡可能な根拠と確信度の割合が必要です（確信度は 80% を超える必要があります）。

このスクリーンショット／動画に基づいてデザインを詳しく説明してください。よく考えてください。 $ARGUMENTS

必須スキル（優先順位順）

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 ファイルを作成してください（Context links、Overview with date/priority/statuses、Key Insights、Requirements、Architecture、Related code files、Implementation Steps、Todo list、Success Criteria、Risk Assessment、Security Considerations、Next steps）。
3. 計画の概要をユーザーに報告してください。

---

[重要] 作業を始める前にタスク管理を使って、各ファイルの読み取りを含むすべての作業を小さなタスクに分割してください。これにより、長いファイルによるコンテキストの喪失を防げます。簡単な作業の場合は、AI は省略してよいか必ずユーザーに尋ねてください。

スキルのバリアント： スクリーンショットや動画から UI を説明するデザインスキルのバリアントです。

AI のミスを防ぐための注意事項 — あらゆるタスクで避けるべき失敗パターン：

削除する前に、下流の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードに古い情報が残る可能性があります。削除するファイルを参照しているファイルをすべて洗い出してください。 AI が生成した内容を実際のコードと照合してください。 AI は存在しない API、クラス名、メソッドシグネチャを捏造することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係を最後までたどってください。 定義を変更しても、そこから派生する変数や利用箇所を見落とす可能性があります。依存関係を最後まで追跡してください。 正しさを確認する際は、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることを確認したことにはなりません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップも必ず確認してください。 デバッグ時は、修正する前に「どちらの責任か」を確認してください。 バグが呼び出し側（誤ったデータ）にあるのか、呼び出される側（不適切な処理）にあるのかを追跡してください。症状が現れている箇所にパッチを当てず、責任のあるレイヤーで修正してください。 既存の値には意図があると考え、変更前に理由を確認してください。 定数、上限、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺コードを調べてください。 影響を受ける出力をすべて検証してください。 複数のスタックにまたがる変更では、すべての出力を検証してください。チェックが 1 つ成功しても、すべて成功したとは限りません。 デバッグは全体を先に確認し、目の前の箇所にとらわれないでください。 障害を調査するときは、まずすべての前提条件（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）を列挙してください。その後、コード層の原因を推測する前に、それぞれを証拠に基づいて確認してください。 変更は必要最小限にし、差分を確認してください。 バグ修正では、変更した各行がそのバグに直接関係している必要があります。周辺コードのスタイル変更や改善は行わないでください。機能拡張タスクでは、改善を実装し、その内容を明示してください。 実装前に曖昧さを明らかにし、黙って決めないでください。 依頼に複数の解釈がある場合は、それぞれを所要時間の見積もりとともに提示して質問してください。すべてのレコードを対象にする方法、ファイルベースの方法、またはより複雑な方法を、決めつけて選ばないでください。 批判的思考の姿勢 — 批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な証拠が必要です。行動するには確信度が80％を超えている必要があります。 ハルシネーション対策： 推測を事実として示してはいけません。すべての主張に出典を引用し、不確実な点は率直に認め、出力に誤りがないか自分で確認し、独立した情報源と照合してください。自分の確信度にも懐疑的でいてください。証拠のない確信は、あらゆるハルシネーションの根源です。

必ず注意 批判的思考を適用してください。すべての主張には追跡可能な証拠が必要です。行動するには確信度が80％を超えている必要があります。ハルシネーション対策：推測を事実として示してはいけません。

必ず注意 AI の誤りを防ぐための対策を適用してください。まず全体を見渡してデバッグし、責任のあるレイヤーで修正し、コーディングの前に曖昧さを明らかにし、コンテキストの圧縮後にファイルを読み直してください。

最後に確認する事項

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

[TASK-PLANNING] 行動する前に、タスクの範囲を分析し、タスク管理を使ってタスクとサブタスクを小さく体系的に分割してください。

フックなしプロンプトプロトコルのミラー（自動同期）

ソース：.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 注意の原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、最も重要なルールを上部と下部の両方に配置し、長いコンテキストウィンドウでも指示が守られるようにします。 目標主導の実行： まず成功基準を定義し、検証されるまで繰り返し、観察可能なチェックに合格した場合にのみ停止します。 テストで意図を検証する： テストはビジネスルールや不変条件を保護し、現在の動作をなぞるだけでなく、保護対象の意図が破られたときに失敗するようにします。

[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] ワークフローやスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成または更新してください。その後、各手順の開始時と完了時に、タスク追跡の内容を同期してください。