frontend-design

Codex 互換性に関する注意：

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

Codex のプロジェクト参照ドキュメントの読み込み（フックなし）

Codex では、実行時に注入されるプロジェクトドキュメントではなく、静的なプロジェクト参照の読み込みを使用します。 コーディング、計画、デバッグ、テスト、レビューを行うときは、次のルーティングに従ってプロジェクトドキュメントを明示的に開いてください。

必ず読むもの：

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

コンテキストが不足している、または古い場合のルート： docs/project-config.json、ドキュメントのインデックス、lessons.md、CLAUDE.md、AGENTS.md、またはタスクで必要な参照ドキュメントが存在しない、あるいは古くなっている場合は、通常のプロジェクト固有の作業を始める前に、$project-init または限定的なセットアップルート（$project-config、$docs-init、$scan-all、$scan --target=<key>、$claude-md-init）を自動実行してください。Codex のミラーまたは AGENTS.md が存在しない、あるいは古くなっている場合は、ユーザーに $sync-codex の実行を依頼し、自動実行しないでください。

状況に応じたドキュメント：

• バックエンド／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
• 仕様書の作成、docs/specs/ のパス、または TC 形式：feature-spec-reference.md、spec-system-reference.md、spec-principles.md
• 動作や公開契約の変更、または仕様書・テスト・コードの同期：上記の仕様書ドキュメントに加えて、workflow-spec-test-code-cycle-reference.md
• 派生仕様書インデックス／ERD／再実装ガイド：spec-system-reference.md と docs/specs/ 内のソース Feature Specs
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：code-review-rules.md と、変更ファイルに応じた上記のドメインドキュメント

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

[BLOCKING] スキルの手順は、宣言された順序で実行してください。ユーザーの明示的な承認なしに、手順を省略、並べ替え、統合してはなりません。 [BLOCKING] 各手順またはサブスキルを呼び出す前にタスク追跡を更新してください。手順の開始時に in_progress、終了時に completed に設定してください。 [BLOCKING] 完了またはスキップしたすべての手順には、簡潔な証拠または明示的なスキップ理由を含めてください。 [BLOCKING] Task ツールを使用できない場合は、同じステータス遷移を適用した、同等の手順ごとの計画トラッカーを作成して維持してください。

クイックサマリー

目標： 汎用的なAIらしい見た目を避け、デザイン品質の高い、個性豊かな本番品質のフロントエンドインターフェースを作成します。

ワークフロー：

1. 入力タイプを判別する — スクリーンショット／画像が提供されているか、ゼロから構築するか
2. デザインガイドラインを抽出する — スクリーンショットの場合：視覚分析ツールを使って色、タイポグラフィ、余白、レイアウトを分析します
3. デザインを検討する — 大胆な美的方向性（トーン、差別化、制約）を選びます
4. コードを実装する — 本番品質で、視覚的に印象的かつ一貫性のあるコードを作成します
5. 品質を検証する — 実装を元のデザインやビジョンと比較します

主なルール：

フロントエンド／UI のコンテキスト（該当する場合）

このタスクにフロントエンドまたは UI の変更が含まれる場合は、

• コンポーネントのパターン：docs/project-reference/frontend-patterns-reference.md
• スタイリング／BEM ガイド：docs/project-reference/scss-styling-guide.md
• デザインシステムのトークン：docs/project-reference/design-system/README.md

SCSS／BEM のルール（標準）： すべてのテンプレート要素に BEM クラスを使用します（block__element--modifier）。マジックナンバーは禁止です。変数／デザイントークンを使用してください。ネストは最大 3 階層です。

• スクリーンショットが入力された場合は、コーディングの前に必ずデザインガイドラインを抽出します
• 個性豊かな特徴的なフォントと、大胆で一貫性のあるカラーパレットを選びます。汎用フォント（Inter、Roboto、Arial）やありきたりな配色は使用しません
• 実装の複雑さを美的な方向性に合わせます（マキシマリストなら精緻に、ミニマリストなら正確に）

批判的に考え、順序立てて思考してください。すべての主張には追跡可能な根拠と確信度が必要です（Idea は 80% を超える必要があります）。

このスキルは、汎用的な「AI らしい低品質」な見た目を避け、個性豊かな本番品質のフロントエンドインターフェースを作成できるようにします。美的な細部や創造的な選択に特に注意を払い、実際に動作するコードを実装してください。

ユーザーは、作成するコンポーネント、ページ、アプリケーション、またはインターフェースのフロントエンド要件を提示します。目的、対象ユーザー、技術的な制約についての情報が含まれる場合もあります。

前提条件

⚠️ 必ず読むこと スクリーンショットを使うワークフローを実行する前に、references/design-extraction-overview.md を読んでください。このファイルには、以下のスクリーンショット／画像入力ワークフローで必要となる、デザインガイドラインの抽出手順、分析プロンプト、視覚的な検証方法が記載されています。アセット生成ワークフローでは、references/asset-generation.md も**⚠️ 必ず読んでください**。

入力タイプとワークフロー

ユーザーがスクリーンショット／画像／デザインリファレンスを提供する場合

スクリーンショット／画像／デザイン入力で必須のワークフロー：

1. ./references/design-extraction-overview.md を使ってデザインガイドラインを抽出する：

   • 視覚分析ツールでスクリーンショット／画像を分析します
   • 色（16 進コード）、タイポグラフィ（フォント、サイズ、ウェイト）、余白のスケール、レイアウトパターン、視覚的階層を抽出します
   • 分析結果をプロジェクトの docs/design-guidelines/extracted-design.md に記録します
   • 詳細な分析プロンプトについては ./references/extraction-prompts.md を参照してください

2. 抽出したガイドラインに従ってコードを実装する：

   • 抽出した正確な色（16 進コード）を使います
   • タイポグラフィの仕様（フォント、サイズ、ウェイト、行の高さ）を合わせます
   • レイアウト構造と余白のシステムを再現します
   • 視覚的階層とコンポーネントのパターンを維持します
   • 美的な方向性と雰囲気を保ちます

3. ./references/visual-analysis-overview.md を使って品質を検証する：

   • 実装を元のスクリーンショットと比較します
   • 色の正確さ、余白の一貫性、タイポグラフィの一致を確認します
   • すべてのデザイン要素が保持されていることを確認します

重要： 実装にすぐ進んではいけません。まずデザインガイドラインを抽出してから、コードを作成してください。

ゼロから構築する場合（スクリーンショットが提供されていない場合）

以下の「デザインを検討する」プロセスに従って、独自のデザインを作成してください。

デザイン思考

コーディングを始める前に、背景を理解し、大胆な美的方向性を定めてください。

• 目的：このインターフェースはどんな課題を解決しますか？誰が使いますか？
• トーン：極端な方向性を選びましょう。極限までミニマル、混沌としたマキシマリズム、レトロフューチャー、オーガニック／ナチュラル、ラグジュアリー／洗練、遊び心のあるおもちゃのような雰囲気、エディトリアル／雑誌風、ブルータリズム／荒削り、アールデコ／幾何学的、ソフト／パステル、インダストリアル／実用本位など、選択肢は数多くあります。これらをインスピレーションの源にしつつ、その美的方向性にふさわしいデザインを形にしてください。
• 制約：技術要件（フレームワーク、パフォーマンス、アクセシビリティ）。
• 差別化：何が忘れられない体験になりますか？使った人が覚えている、たった一つの要素は何ですか？

重要：明確なコンセプトの方向性を選び、精密に実現してください。大胆なマキシマリズムも洗練されたミニマリズムも有効です。大切なのは強度ではなく、意図があることです。

そのうえで、次の条件を満たす動作するコード（HTML/CSS/JS、React、Vue など）を実装してください。

• 本番環境で使える品質と機能性
• 見た目に強いインパクトがあり、記憶に残る
• 明確な美的視点を持ち、一貫性がある
• 細部まで丁寧に磨き上げられている

フロントエンドの美的ガイドライン

次の点に重点を置いてください。

• タイポグラフィ：美しく、個性的で、興味を引くフォントを選びましょう。Arial や Inter のようなありふれたフォントは避け、フロントエンドの美しさを高める、個性と意外性のあるフォントを選んでください。個性のあるディスプレイフォントと、洗練された本文用フォントを組み合わせましょう。
• カラーとテーマ：一貫性のある美的方向性を貫きましょう。一貫性を保つために CSS 変数を使ってください。控えめで均等に配分された配色より、支配的な色に際立つアクセントを加える方が効果的です。
• モーション：エフェクトやマイクロインタラクションにアニメーションを使いましょう。HTML では CSS のみで実現する方法を優先してください。利用できる場合は React で Motion ライブラリを使いましょう（アニメーションには anime.js を使ってください：./references/animejs.md）。大きな効果を生む演出に重点を置いてください。段階的に表示する（animation-delay）ページ読み込み時の、よく練られた一連のアニメーションは、散発的なマイクロインタラクションよりも大きな喜びを生み出します。スクロールに反応する演出や、意外性のあるホバー状態を取り入れましょう。
• 空間構成：意外性のあるレイアウトを使いましょう。非対称、重なり、斜めの流れ、グリッドを崩す要素を取り入れてください。余白をたっぷり取るか、密度を意図的にコントロールしましょう。
• 背景と視覚的な細部：単色で済ませず、雰囲気と奥行きを生み出しましょう。全体の美的方向性に合ったエフェクトやテクスチャを加えてください。グラデーションメッシュ、ノイズテクスチャ、幾何学模様、透明度を重ねた表現、ドラマチックな影、装飾的な罫線、カスタムカーソル、粒子のオーバーレイなど、創造的な表現を取り入れましょう。
• ビジュアルアセット：visual analysis tooling のスキルを使ってアセットを生成し、必要に応じてメディア処理ツールで生成したアセットの背景を削除してください。

ビジュアルアセットの活用

クイックスタート：./references/visual-tooling-overview.md

新しいビジュアルアセットの生成

デザインの美的方向性に合ったヒーロー画像、背景、テクスチャ、装飾要素を生成する場合は、visual analysis tooling スキルを使ってください。これにより、ありきたりな画像を生成するのではなく、デザイン思考と美的ガイドラインに沿ったアセットを作成できます。

提供されたスクリーンショット／画像／デザインの分析

ユーザーから分析または再現するスクリーンショット、写真、デザインの参考資料が提供された場合は、実装の前に ./references/design-extraction-overview.md を使用してデザインガイドラインを抽出してください。スクリーンショットが入力された場合は必須です（上記の「入力タイプとワークフロー」を参照）。

ワークフロー：

• ./references/asset-generation.md - デザインに沿ったビジュアルアセットを生成する
• ./references/visual-analysis-overview.md - アセットの品質を分析、検証する（モジュール式）
• ./references/design-extraction-overview.md - インスピレーションからガイドラインを抽出する（モジュール式）
• ./references/technical-overview.md - 最適化とベストプラクティス（モジュール式）

各概要には、段階的に情報を提示するための詳細なサブモジュールが記載されています。

過度に使われているフォントファミリー（Inter、Roboto、Arial、システムフォント）、ありきたりな配色（特に白背景に紫のグラデーション）、予測しやすいレイアウトやコンポーネントのパターン、そして文脈に応じた個性に欠ける画一的なデザインなど、汎用的なAI生成風の美しさは決して使用しないでください。

創造的に解釈し、その文脈に真に合った、意外性のある選択をしてください。同じデザインを繰り返してはいけません。明るいテーマと暗いテーマ、さまざまなフォントや美学を使い分けてください。生成のたびにありふれた選択（たとえばSpace Grotesk）に収束することは決して避けてください。

重要：実装の複雑さは、美学のビジョンに合わせてください。マキシマリストなデザインには、豊富なアニメーションやエフェクトを備えた精巧なコードが必要です。ミニマリストまたは洗練されたデザインには、抑制、精度、余白、タイポグラフィ、繊細なディテールへの細心の注意が必要です。ビジョンを見事に実現することで、エレガンスが生まれます。

忘れないでください。Claudeは並外れた創造的な仕事ができます。枠にとらわれず、独自のビジョンを徹底して追求すれば何が生み出せるのか、ためらわずに示してください。

関連項目

• interface-design — プロダクト UI（ダッシュボード、管理パネル、SaaS アプリ）
• ui-ux-pro-max
• shadcn-tailwind

---

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

AI のミス防止 — すべてのタスクで避けるべき失敗パターン：

コンテキストが変化した後は、ファイルを読み直してください。 コンテキストの圧縮、中断からの再開、長時間にわたる作業によって記憶が古くなることがあります。作業に取りかかる前に、現在のファイルを確認してください。 生成した内容を根拠となるソースと照合してください。 AI は API、名前、主張、ドキュメント内の事実を幻覚することがあります。文書に記載したり参照したりする前に、関連するソースを確認してください。 削除や名前変更を行う前に、下流の参照を確認してください。 成果物を削除すると、ドキュメント、生成されたミラー、設定、呼び出し元が古くなることがあります。まず参照関係を把握してください。 編集後は影響範囲全体を追跡してください。 定義を変更しても、派生出力や利用側への影響を見落とすことがあります。完了を宣言する前に、影響を受ける連鎖を追跡してください。 最初の出力だけでなく、影響を受けるすべての出力を確認してください。 チェックが 1 つ成功しても、すべて成功したとは限りません。変更によって影響を受けるすべての出力面を検証してください。 既存の値には意図があるものとして扱い、変更する前に理由を確認してください。 定数、上限、フラグ、文言、パターンを変更する前に、周辺のコンテキストと履歴を読んでください。 行動する前に曖昧さを明らかにし、黙って判断しないでください。 複数の妥当な解釈がある場合は、明示的に質問するか、リスクを添えて前提を述べてください。 共有ガイダンスは役割に即したものにしてください。 汎用ガイダンスは、それを受け取るすべてのスキルやエージェントに役立つ必要があります。コード固有の要件は、コード固有のプロトコルにのみ記載してください。

UI システムのコンテキスト — .ts、.html、.scss、.css ファイルに関わるタスクでは、以下を適用してください。

実装前に必ず読んでください：

1. docs/project-reference/frontend-patterns-reference.md — コンポーネントの基底クラス、ストア、フォーム
2. docs/project-reference/scss-styling-guide.md — BEM の手法、SCSS 変数、ミックスイン、レスポンシブ対応
3. docs/project-reference/design-system/README.md — デザイントークン、コンポーネント一覧、アイコン

プロジェクト固有のパスについては、docs/project-config.json を参照してください。

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

• 必ず重要： UI を変更する前に、frontend-patterns-reference、scss-styling-guide、design-system/README を読んでください。

必ず注意： 批判的思考と順序立てた思考を適用してください。すべての主張には適切に追跡可能な証拠が必要です（リポジトリ／コードに関する主張は file:line、調査、製品、コンテンツ、ドキュメントに関する主張はソース URL または成果物のセクション）。行動するには確信度が 80% を超えている必要があります。60% 未満の場合は、推奨しないでください。幻覚防止：推測を事実として提示せず、不確実性は率直に認め、独立した情報源と照合し、自分の確信を疑ってください。

必ず注意： AI のミス防止を適用してください。生成した内容を根拠と照合し、削除や名前変更の前に下流の参照を追跡し、影響を受けるすべての出力を確認し、コンテキストを失った後はファイルを読み直し、行動する前に曖昧さを明らかにしてください。

プロンプト強化の締めくくりのアンカー

重要・必ず注意 このスキルで定められた手順の順序に従ってください。ユーザーから明示的な承認を得ずに、手順を省略、並べ替え、統合しないでください。 重要・必ず注意 各手順／サブスキルの呼び出しでは、実行前に in_progress を設定し、実行後に completed を設定してください。 重要・必ず注意 省略した手順にはすべて明示的な理由を記載してください。完了した手順にはすべて簡潔な根拠を記載してください。 重要・必ず注意 Task ツールが利用できない場合は、同期されたステータスを維持する同等の手順ごとの計画トラッカーを使用してください。

締めくくりのリマインダー

重要・必ず注意 適用中のプロトコル（このスキルに含まれる SYNC／共有ブロックの簡潔な要約）：

• AI の誤り防止： 生成した内容を根拠と照合し、後続の参照を追跡し、影響を受けるすべての出力を検証し、コンテキストを失った後に読み直し、曖昧さを明示してください。

• UI システムのコンテキスト： UI を変更する前に、frontend-patterns、scss-styling、design-system のドキュメントを読んでください。

• 批判的思考： すべての主張に追跡可能な file:line の根拠が必要です。実行に移すのは確信度が80%を超える場合に限ります。

• 必須・重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな todo タスクに分割してください。

• 必須・重要・必ず注意 新しいコードを作成する前に、コードベース内の類似パターンを3つ以上検索してください。

• 必須・重要・必ず注意 すべての主張に file:line の根拠を記載してください（実行に移すのは確信度が80%を超える場合に限ります）。

• 必須・重要・必ず注意 作業の品質を検証するための最終レビュー todo タスクを追加してください。 必須・重要・必ず注意 開始前に以下のファイルを読んでください。

• 必須・重要・必ず注意 開始前に references/design-extraction-overview.md を読んでください。

• 必須・重要・必ず注意 開始前に references/asset-generation.md を読んでください。

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

[IMPORTANT] 作業の規模を分析し、着手前に体系的に多数の小さな todo タスクに分割してください。これは非常に重要です。

Hookless Prompt Protocol Mirror（自動同期）

ソース：.claude/.ck.json + .claude/skills/shared/sync-inline-versions.md（:full ブロック）+ .claude/scripts/lib/hookless-prompt-protocol.cjs

[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 を読み、そこで指定されたプロジェクト参照ドキュメントを開きます。仕様、テストケース、動作変更、公開契約、または docs/specs/ に関する作業では、仕様とテストとコードの同期を保つ必要がある場合、ドキュメントインデックスで指定されたローカル仕様ドキュメント（feature-spec-reference.md、spec-system-reference.md、spec-principles.md、workflow-spec-test-code-cycle-reference.md）を通じて作業を進めます。いずれかのファイル、または必須の参照ドキュメントが見つからないか古い場合は、通常のプロジェクト固有の作業を始める前に、$project-init（または $project-config、$docs-init、$scan-all、$scan --target=<key> などの限定的な下位ルート）を自動実行します。共有コンテキストとローカルドキュメントが利用可能であれば、サポート対象の AI ツールはどれでも実行できます。

1. 検出： プロンプトが明示的なスラッシュ形式のスキル／ワークフローコマンドで始まる場合は、それを直接実行します。それ以外の場合は、ワークフローカタログとスキル一覧に照らしてプロンプトを判定します。
2. 分析： 最適な方法を選びます。直接実行、スキルの呼び出し、標準ワークフローの開始、またはカスタム手順の組み合わせです。
3. 自動選択： 最適な方法を自分で選びます。直接実行、スキル、標準ワークフロー、カスタムワークフローのどれにするかをユーザーに尋ねないでください。
4. 開始： ワークフローを選択した場合は $start-workflow <workflowId> を呼び出し、スキルを選択した場合はそのスキルを呼び出します。カスタムワークフローの場合はカスタム手順を順に実行し、直接実行の場合はタスクに着手します。
5. タスクの作成： 選択した経路に複数のステップが含まれる場合は、実行前にすべてのワークフロー／スキル／カスタム手順についてタスク追跡を作成します。
6. 実行： コンテキストの指示にある ワークフローステップの進行と並列フェーズ のルールに従って進めます。進行はモデル主導です。サブエージェントの完了もインライン呼び出しと同様にステップを進めます。並列フェーズのグループは全メンバーの戻りを待つバリアです。すべてのメンバーが戻るまで次に進まず、決して逐次実行しないでください。

共有 AI-SDD プロトコルマーカー

ソース：.claude/skills/shared/sync-inline-versions.md

SYNC:ai-sdd-artifact-contract

AI-SDD アーティファクト契約 — 共有の仕様駆動開発ルールは、移植可能でソースを正とする状態に保ちます。

1. 再利用可能な AI-SDD の原則は .claude に置き、リポジトリ固有のパス、コマンド、担当者、製品、形式はプロジェクト設定／参照ドキュメントに置きます。
2. サイクルを維持します：spec -> plan -> tasks -> implement -> verify -> update spec/docs。
3. すべての要件または不変条件を、判断、タスク、TC／テスト、ソースの根拠、ドキュメント／仕様の更新まで追跡します。
4. コードからの仕様抽出は、正式な仕様の責任者が承認するまでは参照のみとして扱います。
5. 同期されたコンテキストがあれば、サポート対象の AI ツールはどれでも計画、実装、レビュー、検証を実行できます。複数のツールを使うかどうかは任意です。
6. まず .claude のソースを更新し、その後、生成されたミラーを同期します。.agents、.codex、AGENTS.md を手動で編集しないでください。— 理由：ミラーは生成されたアーティファクトであり、手動編集は次回の同期時に上書きされます
7. docs/project-config.json、ルートの指示ファイル、または必須のプロジェクト参照ドキュメントが見つからないか古い場合は、通常のプロジェクト固有の作業を始める前に、$project-init または限定的な下位ルートを自動実行します。

有効な参照先： 有効なスキルルートにある shared/sdd-artifact-contract.md。

---

SYNC:ai-sdd-artifact-contract:reminder

• MANDATORY shared/sdd-artifact-contract.mdを適用してください。再利用可能なAI-SDDは.claudeに保管し、ローカルルールはプロジェクトのドキュメントに記載してください。
• MANDATORY コードから仕様を抽出したものは、正式に承認されるまでは参照専用です。同期されたコンテキストがあれば、サポート対象のAIツールで実行できます。
• MANDATORY 生成されたミラーを同期する前に、.claudeのソースを更新してください。.agents、.codex、AGENTS.mdは手動で編集しないでください。
• MANDATORY プロジェクト設定、ルートの指示ファイル、または必須の参照ドキュメントがない、あるいは古くなっている場合、プロジェクト固有の作業は自動的に$project-initまたは対象を絞ったセットアップ経路を通じて行ってください。 [TASK-PLANNING] [MANDATORY] ワークフローやスキルの手順を実行する前に、予定されているすべての手順のタスク追跡を作成または更新し、各手順の開始・完了に合わせて同期してください。

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

着手前に、作業を小さなタスクに分割して追跡してください。最後のタスクとして「AIの誤りと教訓を分析する」を追加してください。

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

1. 症状ではなく、失敗モード（推論や前提の誤り）を特定してください。「間違った列挙値を使った」ではなく、「ソースを読まずにAPIが存在すると仮定した」とします。
2. 一般性を検証してください。この失敗モードは3つ以上のコンテキストやコードベースに当てはまりますか。当てはまらない場合は、もう一段階抽象化してください。
3. 普遍的なルールとして記述してください。プロジェクト固有の名前、パス、クラスを取り除き、どのコードベースでも役立つ内容にしてください。
4. 統合してください。同じ失敗モードに起因する複数の誤りは、1つの教訓にまとめてください。
5. 再発判定：「このリマインダーがなければ、今後のセッションで再発しますか？」いいえの場合は、$learnを省略してください。
6. 自動修正判定：「$code-review／$code-simplifier／$security-review／$lintで検出できますか？」はいの場合は、代わりにレビュー用スキルを改善してください。
7. 両方の判定を通過したら、ユーザーに$learnの実行を依頼してください。 [CRITICAL-THINKING-MINDSET] 批判的思考と順を追った思考を適用してください。行動に移すには、すべての主張に追跡可能な根拠があり、確信度が80％を超えている必要があります。 反ハルシネーションの原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力の誤りを自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AIの注意力の原則（初頭効果・親近効果）： 長いプロンプトやプロトコルでは、最も重要な3つのルールを冒頭と末尾の両方に置き、長いコンテキストでも指示への準拠を維持してください。 目標主導の実行： まず成功基準を定め、確認できるまで繰り返し、観察可能なチェック項目に合格した場合にのみ終了してください。 テストで意図を検証する： テストでは、現在の動作をそのままなぞるだけでなく、ビジネスルールや不変条件を保護し、保護対象の意図が崩れたときに失敗するようにしてください。

AIのよくある誤りを防ぐ（システムの教訓）

• コンテキスト圧縮後はファイルを読み直してください。 編集するには、同じコンテキスト内で事前に Read を実行している必要があります。圧縮すると読み取り状態は消去されます。編集前に読み直してください。
• 一括置換の後は古い用語を grep で検索してください。 AI は検索と置換ですべて置き換えられたと過信します。一括編集の後は、ドキュメント／設定／カタログに見落としがないか、リポジトリ全体を grep で検索してください。
• 削除する前に下流の参照を確認してください。 削除によってドキュメントやコードの不整合が連鎖的に発生します。削除前に、参照しているファイルを洗い出してください。
• 記憶を失った後は、新しく作成する前に既存の状態を確認してください。 圧縮すると、それまでの作業の記憶が消えます。再開するには現在の状態を確認してください。決して何も考えずに重複作成しないでください。
• AI が生成した内容は実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、grep で存在を確認してください。
• 編集後は依存関係を最後までたどってください。 定義を変更しても、下流の利用箇所を見落とすことがあります。依存関係を最後までたどってください。
• 名前を変更する場合は、利用側のすべてのファイル形式を grep で検索してください。 一部のファイル形式では参照切れが黙って無視され、コンパイルエラーも発生しません。コード、テンプレート、設定、生成ファイルを検索してください。
• 正しさを検証する際は、コードパスをすべてたどってください。 コードが存在することと、実行されることは同じではありません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップもたどってください。
• ソースの変更に合わせて、正規データを埋め込んでいるドキュメントも更新してください。 ワークフロー、スキーマ、設定などの派生データをインラインで記載しているドキュメントは、気づかないうちに古くなります。ソースとともに、埋め込み先のドキュメントもすべて更新してください。
• コンテキスト復旧後は、サブエージェントの結果を検証してください。 親エージェントのコンテキストが圧縮されている間に、バックグラウンドのエージェントが完了していることがあります。完了したと思い込まず、出力を grep で確認してください。
• 対象リスト全体とサブエージェントへの割り当てを照合してください。 カテゴリごとに並行してサブエージェントを動かすと、境界にある項目が漏れることがあります。作業を進める前に、割り当ての和集合を対象リストと照合してください。
• サブエージェントが引き継ぐ知識は、そのエージェントの .md 定義からのみ得られます。組み込みの Explore ではなく、カスタムのエージェントタイプを使用してください。 ツールを導入するには、権限、知識、強制力（番号付きのワークフロー手順）が必要です。
• サブエージェントの調査結果は、最後にまとめてではなく、随時保存してください。 長時間稼働するサブエージェントは最終書き込み前に制限に達し、調査結果が失われることがあります。報告ファイルにセクションごとに追記するよう指示してください。
• デバッグでは修正する前に「誰の責任か」を確認してください。 呼び出し元（データが誤っている）と呼び出し先（処理が誤っている）をたどってください。責任のあるレイヤーで修正し、症状が現れている箇所だけを修正しないでください。
• 抽出／リファクタリング後は、削除した名前をすべて grep で検索してください。 主なファイルで作業が「完了」していても、ほかのファイルがきれいになっているとは限りません。完了とする前に、削除したシンボルごとに対象範囲全体を grep で検索してください。
• 既存の値には意図があると考え、変更する前に理由を確認してください。 「誤り」とパターンマッチで判断すると、背景を見落とします。定数、上限値、フラグを変更する前に、コメント、git blame、周辺コードを確認してください。
• 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 1 つのビルドが成功しても、すべて成功したとは限りません。複数のスタック（バックエンド／フロントエンド／テスト／ドキュメント）にまたがる変更では、出力をすべて検証してください。
• 近くにあるパターンをコピーする前に、適合性を評価してください。 最も近い例が、同じ前提条件を満たすとは限りません。新しいコンテキストで、同じ制約、基底クラス、スコープ、ライフタイムが適用されるか確認してください。
• デバッグは全体像を優先し、目の前の原因に飛びつかないでください。 最初に思いついたもっともらしい原因へ、いきなり掘り下げてはいけません。すべての前提条件（設定、環境変数、パス、DB、エンドポイント、認証情報、バージョン、DI、データ）を列挙してください。それぞれを推論ではなく証拠（grep／クエリ）で確認してください。「何が分かれば、この仮説は否定されるか」と問いかけてください。何もないなら、それは仮説ではありません。最もコストの高い失敗は、「明らかな」レイヤーを掘り下げ続け、疑いもしなかったレイヤーにバグがあることです。
• 変更は最小限にとどめ、コンテキストを踏まえて差分テストを行ってください。 進め方は 2 通りです。（1）バグ修正 → 各行がバグの修正に結びついていること。スタイル変更はしないこと。未使用になったインポートの整理は、自分の変更によって未使用になったものに限ります。（2）レビュー／機能強化 → 改善を実施し、「主な依頼の範囲外の機能強化：［内容］」として明示します。黙ってスコープを広げてはいけません。差分テスト：「X を依頼されていなかったら、この行は存在しただろうか？」存在しなかったなら、その行を削除するか、追加内容として明示してください。
• 実装前に曖昧さを明らかにし、黙って解釈を選ばないでください。 複数の妥当な解釈がある場合は、それぞれの工数とともに提示してください：「［依頼］には、（1）［N 時間］、（2）［N 時間］の意味が考えられます。どちらを優先しますか？」スコープ／形式／規模／制約に関する前提を、まず列挙してください。より簡単な方法がある場合は、それも伝えてください。黙って解釈を選ばないでください。
• ［最初に必ず行うこと］回答する前に、必ず適切なスキルまたはワークフローを有効化してください。 タスクをワークフローのカタログとスキル一覧に照らして確認し、スキルの呼び出し、または $start-workflow <workflowId> を使って実行してください。確認前に回答したり、コードを書いたりしてはいけません。省略するとプロトコル違反になります。
• Why-Review の敵対的な視点を、計画、判断、設計のレビューに適用してください。 既定の立場は VALIDATOR ではなく SKEPTIC です。却下された選択肢の最も強い論拠を組み立て、提示された理由をそれぞれ逆から問い直し（「何を犠牲にするのか？」）、上位 2～3 個の前提条件をストレステストし、プレモーテム（「リリース後 3 か月で失敗するとしたら、何が壊れるか？」）を行い、作成者が見落とした代替案を 1～2 個提示してください。セクションがあること自体は品質を意味しません。品質とは、因果関係に基づく推論、具体的な緩和策、証拠であり、「こちらのほうがよい」や「注意深く監視する」ではありません。
• 大規模なレビューでは、サブエージェントへのプロンプトで報告の書き込みを最優先にしてください。 多数のファイルを扱うサブエージェントは、最終的な書き込み前に予算を使い切り、調査結果が失われることがあります。プロンプトは次のように設計してください。（1）報告の書き込みを最初の明示的な成果物とする。（2）まとめてではなく、ファイル／セクションごとに追記する。（3）読み取りで予算を使い切らないよう、スコープを限定する。報告ファイルがなく、文の途中で途切れていたら、同じプロンプトを再実行せず、より狭いスコープで再実行してください。
• コンテキスト圧縮後に作業を再開する際は、以前のフェーズの成果をすべて再検証してください。 要約に書かれているのは意図であり、環境の状態（git インデックス、ファイルシステム、プロセス）ではありません。再開時は、まず git status、変更したファイルの再読み込み、ファイルシステムの確認を行ってください。「完了した」という主張は、証拠で確認されるまでは未検証の仮説です。
• OOM／メモリの問題では、行サイズより先に行数を確認してください。 切り分けの手順：（1）クエリに上限がない場合 — トリガーとなる条件を DB で絞り込めていませんか？フィルターを DB に適用すれば、OOM を解消できます。（2）行が大きい場合 — プロジェクションによって比例して削減できます。投資対効果では、プロジェクションより行数の削減が優れています。
• ドメイン概念を汎用／共有／インフラのレイヤーに持ち込まないでください。 再利用可能なレイヤー（共有ライブラリ、フレームワーク、インフラモジュール）が、利用側固有のドメイン概念（テナント／顧客／製品 ID、ビジネスエンティティ、機能ルール）を参照してはいけません。こうした依存が入り込んでもコンパイルや実行は成功するため、レビューをすり抜け、知らないうちに「再利用可能」なレイヤーが特定の利用側に結合されます。共有型にはドメイン概念を含めず、サブクラス化／コンポジションを通じてドメインのフィールドやロジックを利用側に配置してください。— 理由：ある利用側のドメインに結合したレイヤーは、もはや再利用可能ではありません。