oil-oil/oil-frontend

Oil Frontend

まずユーザータスク、ビジネスオブジェクト、データソースを特定し、無効なコンテンツを削除して、正しい情報、状態、コード帰属、共有実装を確立します。

常に遵守すること

• 実際のユーザータスク、ビジネスオブジェクト、完了結果から出発します。表示されるコンテンツは、情報の識別、比較、判断、操作、結果の理解に役立つものだけを残します。
• 1 つのユーザー意図は 1 回だけ実行し、アクションは実際の結果を生成しなければなりません。データ、操作、ビジー状態、送信境界は一貫性を保ち、失敗した場合は現在のオブジェクト、位置、入力済み内容を保持します。
• 一般的なタスクではユーザーの既存の認知に従います。リソースのブラウズはデフォルトで表示し、編集は明示的にトリガーする必要があります。フォームは現在のタスクに必須で、現在のオブジェクトに属するデータのみを収集します。
• アイコン、強調方法、固定サイズはすべて安定した意味を表現しなければなりません。汎用的な AI 装飾、無意味な強調枠、または現在のインスタンスのみに適応するサイズを使用して階層を生成してはいけません。
• 視覚調整は、まずプロジェクトに既存のデザイントークン、コンポーネント、密度を流用し、その後階層、間隔、タイポグラフィ、サーフェス、フィードバックを処理します。プロジェクト標準がない場合のみ、参照ルールのフォールバック値を使用し、それを新しいデザインシステムに拡張してはいけません。
• 同じビジネスデータと同一の意味については、ただ 1 つの権威あるソースのみを保持します。データフロー、親レイアウト、共有実装を優先的に修正し、ページ使用箇所で繰り返しパッチを適用してはいけません。
• ビジネス帰属に従ってコンポーネント、Hook、関数、型、スタイル、テストを整理します。単一モジュールのコードは近くに配置し、安定したクロスモジュール再利用がある場合のみ共有レイヤーに配置します。
• 複雑なロジックに遭遇した場合は、まずプロジェクトの既存機能と成熟したライブラリを確認します。既存の依存関係が適切でない場合は、保守が行き届いておりプロジェクトと互換性のある新しいライブラリを導入できますが、既存の成熟したソリューションがカバーする中核機能を手書きしてはいけません。単純なロジックは直接実装し、少量のコードのために新しい依存関係を導入してはいけません。
• プロジェクトの履歴は正当性の証明にはなりません。誤ったパターンは置き換えられるべきであり、関連する使用箇所の移行が完了したら、古いコード、フォールバック、レガシーロジック、無効な状態を削除します。

参照ファイルの読み取り順序

1. トリガー後、まずこのファイルのみを読み取り、タスク、オブジェクト、変更範囲を明確にし、参照ファイルを事前に読み取らない。
2. タスクがユーザー可視インターフェース、フロントエンドの状態とデータフロー、コンポーネント実装、またはフロントエンドコード構成に関わらない場合、この Skill の使用を停止する。
3. まずユーザーが変更しようとしている結果に基づいて主要なルールを 1 つ選択し、ファイルタイプやコード内に現れる CSS、アニメーションキーワードに基づいてルールを選択しない。
4. 単純なローカル変更は主要なルールを 1 つだけ読み取る。タスクに 2 番目の独立した問題が確かに含まれている場合にのみ、1 つ追加する。ページをまたがる総合レビューの場合のみ 3 つまで読み取り、それ以上は不可。
5. キーワードの出現、ファイル内リンク、または「念のため」に基づいて読み取りを継続しない。視覚的症状がデータ、状態、または親レイアウトによって引き起こされている場合、真の原因を担当するルールを読み取り、視覚ルールを追加で読み込まない。

現在のタスク	主要ルール	補足条件
「見た目がおかしい」、視覚的な微調整、階層、間隔、タイポグラフィ、色、角丸、枠線、シャドウ、アイコン	視覚エンジニアリング	共有トークン、コンポーネントデフォルトスタイル、バリアントの変更が必要な場合は コンポーネントとコード構成 を読む。カラム分割、スクロール、レスポンシブ構造を変更する場合は、ビューポートとダイアログ を主要ルールとして読み直す
アニメーション、トランジション、マイクロインタラクション、展開/折りたたみ、ドラッグフィードバック、スクロールエフェクト、カクツキ	モーションとパフォーマンス	モーションがアクションフィードバックや視覚階層を担う場合は 視覚エンジニアリング を読む。根本原因が非同期状態の場合は、状態と読み込み を主要ルールとして読み直す
モジュール境界、コンポーネント、Hook、関数、型、スタイルの帰属、共有スタイル、CSS 構成、共有実装	コンポーネントとコード構成	新しいチェックの追加が必要な場合は 自動化 を読む
新しいテキスト、アクションの意味、アイコン、クリックフィードバック、視覚強調の追加または変更	情報とアクション	オブジェクト ID、画像、セレクターに関わる場合は リソース識別 を読む

データ、状態、レイアウトは結果に応じて選択を継続します：

現在のタスク	主要ルール	補足条件
リスト、カード、詳細、テーブル、一括操作	コレクションと詳細	リソース ID に関わる場合は リソース識別 を読む。編集に関わる場合は インタラクションと編集 を読む
フォーム、選択、編集、マルチステップワークフロー	インタラクションと編集	保存範囲とプロセス継続性に関わる場合は データと操作範囲 を読む
クエリ結果、ページネーション、候補セット、保存範囲、一括範囲、リクエスト結果の帰属	データと操作範囲	loading、refreshing、empty、error、processing の表示も同時に変更する場合は 状態と読み込み を読む
loading、refreshing、empty、filtered-empty、error、queued、processing、スケルトン	状態と読み込み	クエリスナップショット、操作範囲、保存結果の帰属にも関わる場合は データと操作範囲 を読む
ページサイズ、カラム分割、スクロール、ダイアログ構造、レスポンシブ動作の変更	ビューポートとダイアログ	ドロップダウン、メニュー、ツールチップなど、トリガーに付随するオーバーレイに関わる場合は オーバーレイ を読む

以下の場合、追加読み取りはトリガーされません：

• コード内に Tailwind、CSS、transition、アニメーションライブラリが存在しても、タスクが視覚またはモーションタスクであるとは限らない。
• 色、間隔、枠線、シャドウ、タイポグラフィなどの可視属性を変更する場合、視覚エンジニアリングが主要ルールとなる。タスクが同時にスタイルの帰属、共有方法、モジュール境界の調整を要求する場合のみ、コンポーネントとコード構成ルールを補足する。
• 色変数名、クラス名、型、インポートエラーのみを修正し、視覚結果を変更しない場合、視覚エンジニアリングルールを読まない。
• 既存のモーションに対してビジネス状態、イベントバインディング、データソースを変更するだけで、動作方法とパフォーマンスを変更しない場合、モーションルールを読まない。
• 既存のコントロールを移動するだけで、テキスト、アクションの意味、フィードバックを変更しない場合、情報とアクションルールを読まない。
• 通常の親子コンテナの帰属を調整するだけで、サイズ、スクロール、ダイアログ、レスポンシブ動作を変更しない場合、ビューポートとダイアログルールを読まない。
• 参照ファイル内のリンクは関連ルールの場所を示すだけで、読み取りを継続しなければならないことを意味しない。

用語クイックリファレンス

このファイルと参照ルールの中核語彙は、以下の定義で理解します：

• リソース ID: ユーザーが「これはどのオブジェクトか」を認識できる最小の情報の組み合わせ — 画像 + 名前 + 1 つの識別フィールド。例：メンバーリストは「アバター + 氏名 + 部門」を表示し、「uuid + タイプタグ」は表示しない。
• 擬似操作: 使用可能に見えるが、実際の結果を生成しないコントロール。例：「保存」をクリックしてもローカル state が変わるだけで、リロードすると失われる。削除ボタンが永続的に disabled で場所を占有する。
• 単一コンポーネントへの視覚パッチ: 共有コンポーネントを使用するページ位置で、その 1 つのコンポーネントにのみスタイルを追加すること。例：<Dialog className="h-[640px]">、!important による上書き、ページ専用セレクタによるコンポーネント内部の変更。正しい方法は共有コンポーネント自体を修正するか、用途に応じて名前を付けたコンポーネントバリアントを新規作成すること。
• 用途に応じて名前を付けたコンポーネントバリアント（variant）: 「なぜ異なるのか」で命名する。例：variant="destructive"、size="compact" は合格。variant="blue"、variant="userListPage" は不合格。
• 主要アクション: 現在のページ、ダイアログ、操作領域で主要タスクを完了する 1 つの操作。同じ領域で強調ボタンは最大 1 つ。
• 送信境界: 1 回の変更がいつ実際に有効になるか — 即時有効、自動保存、明示的一括送信、または一時プレビューのみ。
• ビジー範囲: リクエスト進行中に重複操作を防ぐ必要がある最小領域。単一のリクエストはその項目のみをロックし、全ページオーバーレイは使用しない。
• 送信済みクエリスナップショット: 同一レスポンスによって共同で決定されたクエリ条件、リスト、結果総数、ページネーション情報。新しいクエリが完了するまで、古いスナップショットは依然として古い条件に属する。
• 同種一括タスク: 同じタイプの複数のオブジェクトに対して同じフィールドを繰り返し入力するタスク。例：一括スケジューリング、一括価格変更。
• 編集可能ワークシート: 同種一括タスクのために複数行を継続的に編集状態にするテーブル。対照的にリソースリストはデフォルトで表示し、編集は明示的にトリガーする必要がある。

意思決定順序

変更前に順に回答します。

タスクとオブジェクト：

1. ユーザーは現在どのタスクを完了しようとしており、どの結果が完了を意味するか？
2. ページはどのコアオブジェクトを管理し、フィールドはそれぞれ誰に属するか？
3. 現在ブラウズ、比較、選択、編集のいずれか？ユーザーが慣れている構造と用語に従っているか？

データと範囲：

4. データは完全な集合、現在可視の集合、検索結果のいずれから来ているか？
5. 操作、ビジー状態、送信境界はそれぞれどの範囲に影響するか？リモートクエリ条件と現在のリストは既に同じ送信済み結果に属しているか？
6. ユーザーはどの情報で隣接するオブジェクトを区別しているか？
7. テキスト、手順、確認、繰り返し入力、システムが既に知っているフィールドを削除できるか？
8. どの情報が集合に属し、どれが詳細のみに属するか？

構造と状態：

9. 現在のページ、ダイアログ、操作領域の主要アクションは何か？
10. ファーストビュー、スクロールコンテナ、オーバーレイの境界はそれぞれ誰が担当するか？
11. loading、empty、filtered-empty、queued、processing、error、ready はどのように排他するか？

視覚とモーション、タスクが変更を要求する場合のみ回答：

12. 現在のプロジェクトではどのトークン、コンポーネント、隣接ページを使用して階層、密度、モーション言語を定義しているか？本当に一貫性がないのはどの可視属性か？
13. モーションは状態のフィードバック、空間関係の説明、装飾のいずれか？transform、opacity、または既存のコンポーネント機能のみで実現できるか？

着地点：

14. 正しく帰属するモジュール、コンポーネント、Hook、関数、型、統一デザイン変数、スタイルは既に存在するか？最終的にどのデータソース、親レイアウト、共有実装を変更すべきか？

明確に回答できない場合は、まずインターフェース要素の追加を停止します：最も重要な 1～2 の質問をユーザーに提示します。質問できない場合は、最小限の検証可能な範囲で実装し、出力で行った前提を宣言します。

実行フロー

1. 事実の確認

• プロジェクトに既存のモジュール、コンポーネント、Hook、関数、型、統一デザイン変数、スタイルを検索し、同じ意味が既に正しく実装されているかを確認します。
• 共有コンポーネントを使用しているすべてのページとコンポーネント、および同じデータの他のエントリポイントを特定します。
• レビューリクエストには証拠と提案のみを提供します。ユーザーが修正を要求した場合のみ実装します。

2. 範囲の明確化

• コアオブジェクト、フィールド所有者、データ集合、操作範囲、ビジー範囲、送信境界を明確にします。
• ページ構造の問題、コンポーネントのデフォルト動作、ページ使用法の誤り、データフローの誤りを区別します。
• 視覚的な問題については、具体的な要素、属性、既存の根拠、コードの着地点を指摘できる差異のみを記録します。正しい値を確定できない場合は、まずプロジェクトの既存トークンまたは隣接する同種コンポーネントを使用し、美的感覚に基づいて正確な値を発明しません。

3. まず削除

• 判断に影響しないコンテンツ、重複状態、重複エントリポイント、重複確認、単一コンポーネントのみを対象とした視覚パッチを削除します。
• 実際の状態変化がない、またはデータを実際に保存できない擬似操作を削除します。
• 新しい実装に置き換えられた古いコンポーネント、古い関数、古い型、古い状態、フォールバック、レガシーロジック、古いスタイル、無効な参照を削除します。

4. 構造の選択

• まずプロジェクト内の同種タスクページと共有コンテナコンポーネントの確立された使用法を確認します。既存のパターンが本ガイドに準拠している場合のみそれを流用し、そうでない場合は実際のタスクに基づいて新たに構造を選択します。
• ブラウズ、比較、選択、一括設定、詳細編集のタスクに応じて、リスト、テーブル、ワークシート、セレクター、ダイアログ、フルワークスペースを選択します。
• リストは識別と比較を担当し、詳細は完全なコンテンツを担当し、エディターは修正を担当させます。
• 視覚調整は「情報階層 → 空間と配置 → タイポグラフィ → サーフェス → コントロール状態 → モーション」の順序で処理します。前の層で問題が解決したら停止し、装飾を重ね継ぎません。

5. 実際にエラーが発生している場所を修正

• データ範囲、操作範囲、親レイアウト、共有コンポーネントのデフォルト動作、意味的に安定したコンポーネントバリアントを優先的に修正します。
• 繰り返し出現するリソース ID、メニュー、オーバーレイ、読み込み、ダイアログ、操作バーには共有コンポーネントを使用します。
• 責任、入出力、動作が安定して繰り返される場合にのみ抽象化します。局所的な構造が類似しているからといってコンポーネントを複製したり、多数のページスイッチを使用して万能コンポーネントを作成したりしてはいけません。
• 既存の共有コンポーネント、関数、スタイル、データフロー自体が誤っている場合は、権限範囲内で実際に誤っている共有実装を直接修正または置き換え、影響を受けるすべての使用箇所を処理します。履歴との互換性を保つために誤った実装を新たに追加し続けてはいけません。
• 現在の範囲ですべてを修正できない場合は、古いパターンを拡大するのを停止し、残っている古い使用箇所と今回の修正範囲を明確に報告し、統一したと主張してはいけません。
• 繰り返し検出可能な問題を修正する場合、プロジェクトに新しい lint、テスト、チェックルールが本当に必要かどうかを判断します。必要な場合は、ルーティングテーブルに従って 自動化 を補足読み取りし、補足ルール数に計上します。小規模な変更のためにこれを事前に自動化を構築しません。
• 無関係な領域は変更しません。

6. 検証

• プロジェクトに存在し、かつ変更に関連する型チェック、Lint、テスト、ビルドを実行します。
• 単純なローカル変更は、変更箇所、直接の動作、直近の使用箇所のみをチェックし、完全な状態マトリックスは展開しません。
• 変更が共有コンポーネント、データ範囲、非同期状態、フォームフロー、スクロール、レスポンシブ、または複数ページに及ぶ場合は、影響を受ける状態、データ範囲、代表的なビューポート、すべての使用箇所をチェックします。
• 視覚変更は、実際のコンテンツ、主要な状態、影響を受けるビューポートをチェックします。モーション変更は、タイプに応じて該当する中断、再トリガー、終了、アンマウント、スクロール動作のみをチェックします。複雑なモーションや実際のカクツキがある場合のみパフォーマンス録画を使用し、すべてのトランジションをパフォーマンス専用タスクに昇格させません。
• 検証済み項目、未検証項目、ブロック理由のみを報告します。

独立自己チェック

フロントエンドレビューが複数ページ、共有コンポーネントの全使用箇所、複数のビューポートや状態、または広範囲のルール調整に及ぶ場合にのみ、履歴コンテキストのない独立した自己チェックを発行します。単一ページ、単一コンポーネント、単一スクリーンショット、局所的な差異はメインエージェントが直接チェックします。

独立自己チェックは、チェックオブジェクト、範囲、oil-frontend のみを受け取り、会話履歴、既存の結論、問題の推測、期待される答え、修正案は受け取りません。

出力要件

まず結論を述べ、次に証拠を述べます。以下のみを出力します：

1. 具体的な問題；
2. 削除すべきコンテンツ；
3. 正しい情報、アクション、空間構造；
4. 修正すべきモジュール、共有コンポーネント、データフロー；
5. 検証済みおよび未検証の項目。

「体験向上」「よりモダン」「より直感的」など、実装を導かない説明は禁止します。

積極的にアクセシビリティ専門監査に拡張しません。UI 実装時は引き続きネイティブのインタラクション要素を使用し、プロジェクトの既存のフォーカス、キーボード、ラベル、ARIA 動作を破壊しません。ユーザーが明示的に要求した場合、または現在の変更が直接タスクを達成不可能にする場合のみ、チェックを展開します。