redesign

再デザイン

製品がすでに存在し、レイアウト、ビジュアルシステム、操作性をさらに向上させる必要がある場合に、このコマンドを使用します。

実装時のデフォルト

再デザインの出力では、Tailwind CSSをデフォルトで使用します。

• ユーザーが別のスタイリングシステムを明示的に指定しない限り、ビジュアルの更新にはすべてTailwindのユーティリティクラスを使用します。
• 既存のフレームワークとランタイムは維持しつつ、可能な場合はデフォルトでTailwindを使うスタイリング方針に移行します。

UIライブラリの利用

参照を許可するライブラリ：

• UIverse
• FlyonUI（https://flyonui.com/）
• daisyUI

ルール：

• ライブラリは作業を加速するために使い、ページ全体のテンプレートとして使わないでください。
• ライブラリのコンポーネントは、製品のセマンティクスやブランドの方向性に合わせてリファクタリング、変更してください。
• いずれかのライブラリの既成パターンが繰り返されないようにしてください。
• 繰り返しのリスクが高い場合は、ライブラリの利用と独自に考案したコンポーネントを組み合わせてください。

Pretextの統合

テキストのはみ出しや不安定な折り返しが懸念される既存UIを再デザインする場合は、余白や文字サイズを確定する前に@chenglou/pretextを使ってテキストレイアウトを計画してください。

• 必要に応じてインストールします：npm install @chenglou/pretext
• prepare()とlayout()を使い、主要なテキストブロック（ヒーロー、カード、CTAの行、ナビゲーションラベル）を対象幅で検証します。
• 測定結果を使って安全な幅の制約を選び、ブレークポイントをまたぐはみ出しの再発を減らします。
• 正確な行のリズムに基づく再デザインでは、prepareWithSegments()とwalkLineRanges()を使って候補を比較し、最適な構成を選びます。
• プロジェクトが静的HTML／CDNのみの場合、またはJavaScriptのビルド手順がない場合は、Pretextの統合を省略し、代わりにレスポンシブCSSの制約で折り返しを調整します。
• これらの作業は明示せずに行います。求められない限り、ユーザー向けの「Pretextに関する注意事項」は含めないでください。

繰り返し防止の拡張（必須）

再デザインを、標準的なテンプレートに表面的な変更を加えただけのものにしてはいけません。

ルール：

1. 方針を決める前に、コンポーネントとインタラクションの種類を幅広く取り入れた候補を作成します。
2. 繰り返し使われているカード構造を、異なるコンポーネント群（データカード、ナラティブブロック、比較行、実績ストリップ、ユーティリティパネルなど）に置き換えます。
3. 現在のUIブロックが汎用的な場合、実質的な再デザインごとに少なくとも2 new componentsを考案します。
4. モーションが求められる場合、ユーザーへのフィードバックまたは情報の階層に結び付いた、少なくとも1 new animation patternを考案します。
5. 変化が色、角丸、フォントの変更だけにとどまる出力は採用しません。

再デザインの多様性に関する基準（必須）

実質的な再デザインでは、次の条件を満たしてください。

1. ページ内に、構造が実質的に異なるセクションを少なくとも6つ設けます。
2. カード以外を主とするコンテンツモジュールを少なくとも3つ設けます。
3. 製品のコンテキストに合わせて新たに考案したコンポーネントを少なくとも2つ用意します。
4. 既存のパターンがセクションの25%を超えて占めないようにします。

再デザイン後も元のレイアウトの骨格に似ている場合は、確定する前に構造をさらに大きく変更してください。

AIらしさを排除する再デザイン基準（必須）

「テンプレートの着せ替え」に見える再デザインは採用しません。

失敗例：

1. 色やフォントだけを変更し、元のレイアウトの大部分を維持している
2. 繰り返し使われている既成カードを、別の繰り返し使われている既成カードに置き換えている
3. セクションのリズムを変えず、表面的な変更にとどまっている
4. インタラクションロジックのない基本的なフェードインだけにモーションを限定している

最低限満たすべき再デザインの基準：

1. 汎用的な既存ブロックに代わる、明確に新しい構造のモジュールを少なくとも3つ設ける
2. 製品のコンテキストに固有のコンポーネントを少なくとも2つ用意する
3. 元のUIにはない、独自のインタラクションパターンを少なくとも1つ取り入れる

コンポーネント考案のルール

再デザイン用のコンポーネントを考案する場合：

1. 見た目の新しさだけでなく、製品のセマンティクス（ワークフロー、信頼の指標、コンバージョンの手順）を基にします。
2. 状態とレスポンシブ時の挙動を明確に定義します。
3. Tailwindのクラス構成で保守しやすい実装にします。
4. 理解しやすさやフィードバックの速さを向上させる場合にのみ、モーションを追加します。

中核となる目的

ユーザーの操作フローを損なわずに、現在のインターフェースをより明確で、高品質かつ意図の伝わるデザインに変えます。

作業手順

1. まず現在のUIを監査します。

• 階層構造の問題、スペーシングの不整合、構成の弱さ、ありきたりなパターンを特定します。
• 操作上の使いにくさや、フィードバック状態の不足を検出します。
• 維持すべきもの（フロー、中核となる情報アーキテクチャ、重要な文言、ビジネス上の制約）を洗い出します。

2. 再設計の方向性を定めます。

• 明確なビジュアルの主題とレイアウトの類型を選びます。
• タイポグラフィ、セクションのリズム、コントラストを強化します。
• コンポーネントの一貫性とレスポンシブな動作を改善します。

3. 安全に実装します。

• 変更を明示的に求められていない限り、機能とナビゲーションのロジックを維持します。
• フォーム、状態、アクセシビリティに関するリグレッションを避けます。
• 動きは装飾ではなく、明瞭さやフィードバックの向上に役立つ場合に取り入れます。

4. 品質を検証します。

• デスクトップとモバイルでの動作を確認します。
• アニメーションを追加した場合は、動きを減らす設定での動作を確認します。
• 再設計が見た目を変えただけでなく、実質的に改善されていることを確認します。

制約

• ありきたりな「無難なSaaS」の既定デザインを採用しないでください。
• 理由なく重要な情報アーキテクチャを削除しないでください。
• 視覚的な目新しさのために使いやすさを犠牲にしないでください。
• 対象となる利用環境に適したパフォーマンスを維持してください。