shixun926-dotcom/Frontend-Workflow

Frontend Workflow：フロントエンドプロジェクト全体制御

一、最優先：まずプロジェクトを読み込む

ファイルを変更する前に、必ず以下の手順を実行すること：

1. プロジェクトルートの AGENTS.md、CLAUDE.md、README、およびその他の適用可能な開発規範を読む。
2. package.json、ロックファイル、ビルド設定、ルーティング設定、既存コンポーネントを確認する。
3. 現在のプロジェクトの技術スタック、フレームワークバージョン、UIコンポーネントライブラリ、CSS方式、実行コマンドを特定する。
4. フロントエンドとバックエンドが分離されたプロジェクトの場合は、フロントエンドとバックエンドの境界を明確にし、バックエンドのインターフェース契約を勝手に変更しない。
5. プロジェクトに既存のデザインシステム、コンポーネント規範、ページスタイルがある場合は、それを引き継ぎ改善することを優先し、再構築しない。

ユーザーの説明やディレクトリ名だけで技術スタックを判断せず、必ず実際のファイルを確認すること。

二、技術スタックを特定し、スキルの使用方法を決定する

ケース A：React プロジェクト

次の順序で実行する：

1. frontend-design：ビジュアル方向性、デザイン規範、ページレイアウトを決定する。
2. frontend-production-shadcn：プロジェクトの互換性を確認した上で、コンポーネント、レイアウト、インタラクションを実装する。
3. premium-ui：実際のページをチェックし、修正を推進する。

プロジェクトがすでにReact、Tailwind CSS、shadcn/uiなどの該当技術を採用しているか、明示的に許可している場合にのみ、このスキルの具体的なコンポーネント実装方式を直接使用すること。

ケース B：Vue 3 プロジェクト

次の順序で実行する：

1. frontend-design：ビジュアル方向性、デザイン規範、ページレイアウトを決定する。
2. frontend-production-shadcn はデザイン規範とエンジニアリング品質の参考としてのみ使用し、React、JSX、React Hooks、shadcn/ui に固有の実装指示は実行しない。
3. プロジェクトの既存の Vue 3、TypeScript、ルーティング、UIコンポーネントライブラリ、CSS方式を使用して実装を完了する。
4. premium-ui：実際のページをチェックし、修正を推進する。

第2のスキルに合わせるために Vue 3 プロジェクトを React に移行してはならない。

ケース C：その他の技術スタック

まずプロジェクトの既存技術と制約を確認する。frontend-design をビジュアル計画に使用し、frontend-production-shadcn の移行可能なデザイン原則を参考として、現在のプロジェクトに適した技術で実装を完了する。最後に premium-ui のレビュー手法で承認する。

三、3つのフェーズを厳格に実行する

フェーズ一：ビジュアルデザイン

frontend-design を呼び出す。

要件：

• ページの目的、主要ユーザー、コア操作を明確にする。
• ビジュアル方向性、フォント、色、間隔、レイアウト、情報階層を決定する。
• 実質的に異なるデザイン方向性を提案し、最終的な選択理由を説明する。
• 実行可能なデザイン規範を作成してから実装を開始する。

フェーズ二：エンジニアリング実装

技術スタックに応じて frontend-production-shadcn を呼び出すか、そのデザイン原則のみを参考にする。

要件：

• まず既存のコンポーネントと依存関係を再利用する。
• 完全なページ、ナビゲーション、フォーム、レスポンシブレイアウト、インタラクション状態を実装する。
• ローディング、空データ、エラー、無効状態、成功フィードバックを処理する。
• 実際のビジネスロジックを保持し、偽のインタラクションで機能を完了したふりをしない。
• 許可なく大規模なリファクタリングやフレームワークの交換を行わない。

フェーズ三：ビジュアル承認

premium-ui を呼び出し、実際の実装を確認する（コードを読むだけではない）。

要件：

• プロジェクトを起動し、利用可能なブラウザまたはスクリーンショットツールを使用してページを確認することを優先する。
• タイポグラフィ、整列、余白、色、階層、コンポーネントの一貫性、レスポンシブ表現をチェックする。
• ボタン、フォーム、ナビゲーション、主要なインタラクションが有効かどうかをチェックする。
• デザイン目標と実際の効果の差を記録する。
• 発見された問題を修正し、再チェックする。

環境にブラウザまたはスクリーンショット機能がない場合は、実際のビジュアル承認を完了できないことを明確に述べ、ページ効果をチェックしたと主張してはならない。

四、実行ルール

1. 各フェーズ完了後、結論を簡単に報告してから次のフェーズに進む。
2. 特定のスキルが存在しない、ロードされていない、または実行できない場合は、その旨を明確に述べ、実行可能な代替手段を採用する。
3. 他のスキルが自動的に実行されることを想定してはならない。必要に応じて明示的に呼び出しまたは読み取りを要求する。
4. ユーザーの明確な要求、プロジェクト規範、既存の技術スタックに従う。
5. ビジュアル効果を追求するために、アクセシビリティ、保守性、パフォーマンス、ビジネスの正確性を犠牲にしてはならない。
6. 完了後、プロジェクトがサポートするビルド、チェック、テストコマンドを実行し、結果を報告する。

五、最終成果物

完了後に報告すること：

• 特定した技術スタックとバージョン。
• 採用したデザイン方向性と主要なデザイン決定。
• 変更した主要ファイルとその機能。
• 3つのフェーズそれぞれの実行状況。
• ビルド、テスト、実際のビジュアルチェックの結果。
• 未解決の問題と、手動確認が必要な事項。