bright-y/static-prototype-splitter

Static Prototype Splitter

このスキルは、完了またはほぼ完了した静的プロトタイプを、デモ、反復、移行、または引き渡しのためのよりクリーンなデリバラブルに変換するために使用します。

目的は製品を再設計することではありません。既存のビジュアルの方向性とインタラクションの意図を維持しながら、プロトタイプを開いたり、検査したり、修正したり、移行したりしやすくします。

スコープと引き渡し

• このスキルは、既存の静的プロトタイプから新たな分割、コンポーネント化、または引き渡し用デリバラブルを作成するために使用します。すでに整理されたプロトタイプに対する継続的な編集には、prototype-maintenanceが利用可能な場合はそれを使用してください。必須の依存関係ではありません。
• 小さなコピーやスタイルの変更の場合は、プロトタイプを再構築せずに要求された変更を行います。
• 既存のフレームワークプロジェクトは確立されたスタックを維持し、React/Vueなどのプロジェクトを明示的に要求されない限り静的HTMLに平坦化しないでください。
• ファイルの置換、設定、依存関係、ネットワークアクセス、ローカルサーバー、保存データに関するユーザーの承認ルールに従ってください。このスキルはそれらの権限を付与しません。

デフォルトの原則

• ソースファイルを保持します。ユーザーが明示的に要求しない限り、元のプロトタイプを上書きしないでください。
• 生成されたデリバラブルにはタイムスタンプ付きの出力フォルダを作成します。
• 編集は構造、パス、再利用可能なアセット、および基本的なインタラクションワイヤリングに集中します。
• 元の言語、製品用語、ビジュアルスタイル、およびページ階層を維持します。
• ユーザーがフレームワークを要求しない限り、プレーンな静的HTML/CSS/JSを優先します。
• 無関係な再設計、依存関係のインストール、ビルドツール、またはフレームワークの移行は避けてください。
• プロトタイプに分割ページと完全なプレビューの両方が必要な場合、分割ページファイルを単一の真実のソースとして扱います。結合エントリにページコンテンツやインタラクションロジックの2つ目の異なるコピーを維持しないでください。
• 結合エントリは、ルーティング、テンプレート、共有モジュール、または小さなビルド/同期スクリプトを介して分割ページソースから構成、読み込み、または生成する必要があります。信頼性のために一時的な結合実装が必要な場合は、重複を指摘し、それ以上ページレベルの反復を進める前に調整することを推奨します。
• 後続のページ編集では、まず特定の分割ページとそのページレベルのスクリプトを修正し、次に結合プレビューを更新または再生成して、ユーザーが同じ変更を2回行う必要がないようにします。

トリガー条件

以下の依頼があった場合にこのスキルをトリガーします。

• 大きなHTMLプロトタイプを個別ページに分割する。
• 静的プロトタイプをデリバラブルフォルダに整理する。
• 静的HTMLプロトタイプをコンポーネント化する。
• プロトタイプを引き渡しやデモ用にパッケージ化する。
• 製品デザインプロトタイプのよりクリーンなバージョンを作成する。
• シングルファイルの静的アプリをマルチページまたは静的コンポーネント構造に変換する。
• 後でVue、React、Taro、uni-app、微信小程序、または別のフロントエンドスタックに移行するためのプロトタイプを準備する。

推奨出力形状

リクエストに基づいて1つ以上の形状を選択してください。

分割ファイル版

ユーザーが静的なデモページやページごとのデザイン反復を必要とする場合に使用します。

推奨構造：

出力ディレクトリ_YYYYMMDD-HHMMSS/
├── 分割ファイル版/
│   ├── index.html
│   ├── page-a.html
│   ├── page-b.html
│   └── assets/
│       ├── styles.css
│       └── app.js
└── README.md

ガイドライン：

• 主要なビューごとに1つのHTMLファイルを作成します。
• 可能な限り通常のリンクを介してページナビゲーションを維持します。
• 共有CSSと軽量なJSをassets/に抽出します。
• 各ページがブラウザで個別に開けるようにします。
• ページ名は意味があり、安定しているものにします。

コンポーネント化版

プロトタイプを後でフロントエンドフレームワークに移行しやすくする場合に使用します。

推奨構造：

出力ディレクトリ_YYYYMMDD-HHMMSS/
├── コンポーネント化版/
│   ├── index.html
│   └── assets/
│       ├── styles.css
│       ├── components.js
│       ├── data.js
│       └── app.js
└── README.md

ガイドライン：

• index.html: シェル、ルートコンテナ、スクリプト/スタイルの参照。
• assets/styles.css: 共有スタイル。
• assets/data.js: モックデータとビジネスデータ（有用な場合）。
• assets/components.js: 再利用可能なHTMLレンダリング関数またはコンポーネントテンプレート。
• assets/app.js: ルート切り替え、状態、イベントバインディング、および単純なインタラクション。
• ユーザーが特定のフレームワークを要求しない限り、このバージョンはフレームワークフリーに保ちます。
• 分割されたHTMLページも存在する場合、それらのコンテンツをapp.js内に手動で複製しないでください。代わりに、共有テンプレートのインポート、ページフラグメントの読み込み、または決定論的な同期ステップを使用して、分割ページがメンテナンスソースのままになるようにします。

分割ページからの結合プレビュー版

ユーザーが各ページを個別に編集可能にしつつ、完全なインタラクティブプレビューも1つ必要とする場合に使用します。

推奨構造：

prototype/
├── app.html                  # 完全なプレビューシェル
├── pages/
│   ├── welcome.html
│   ├── templates.html
│   └── ...
├── assets/
│   ├── css/styles.css
│   ├── js/common.js
│   ├── js/router.js          # プレビュールーティング/構成のみ
│   └── js/pages/
│       ├── templates.js
│       └── ...
└── README.md

ガイドライン：

• ページマークアップとページ固有の動作はpages/とassets/js/pages/に保持します。
• app.htmlはシェルとして維持します：デバイスフレーム、ナビゲーション、ルートコンテナ、共有スクリプト/スタイル参照。
• router.jsはページの読み込み、共有ナビゲーションのバインド、状態の維持、プレビュー固有の懸念事項に集中させます。
• すべてのページを手作業で書き直す長大なapp-combined.jsは避けてください。短期回避策として存在する場合は、生成されたものまたは一時的なものとしてマークし、多くのページ編集を行う前に分割ページと調整します。
• ユーザーが1つのページの修正を依頼した場合、プレビューシェルや共有スタイルに本当に調整が必要でない限り、そのページとそのページスクリプトのみを編集します。

パッケージ化された引き渡しフォルダ

ユーザーが完全なパッケージまたは配信バンドルを依頼した場合に使用します。

推奨構造：

製品プロトタイプ完全パッケージ_YYYYMMDD-HHMMSS/
├── 使用説明書.md
├── 元のファイル/
├── 分割ファイル版/
└── コンポーネント化版/

ガイドライン：

• デモと引き渡しに必要なファイルのみを含めます。
• ソースのファイル名は認識可能なままにします。
• アーカイブを作成する場合は、タイムスタンプ付きの名前を使用します。
• ユーザーが確認しない限り、中間生成フォルダは削除しないでください。

ワークフロー

1. プロトタイプファイルを調査します。

   • エントリファイル、主要ビュー、共有CSS、共有JS、インラインイベントハンドラ、アセット、外部CDN依存関係、ダイアログ、ドロワー、タブ、ページナビゲーションを特定します。
   • 編集前にrg --filesと対象を絞った読み取りを使用します。

2. 出力形状を決定します。

   • ユーザーが単に分割を依頼した場合：分割ファイル版を作成します。
   • ユーザーが移行準備またはコンポーネント化を依頼した場合：コンポーネント化版を作成します。
   • ユーザーが納品を依頼した場合：使用説明書付きの完全なパッケージを作成します。
   • 不明な場合、リクエストを満たす最小の出力を選択します。複数のバージョンは、明確なニーズがある場合にのみ作成し、共有コンテンツと動作については1つの信頼できるソースを維持します。

3. タイムスタンプ付きの出力フォルダを作成します。

   • 推奨タイムスタンプ形式：YYYYMMDD-HHMMSS。
   • 元のファイルは変更せずに保持します。

4. 抽出と整理を行います。

   • 共有CSSを共通のスタイルシートに移動します。
   • 共有JSを共通のスクリプトに移動します。
   • アセットパスを正規化します。
   • 主要ビューを個別のHTMLファイルまたはコンポーネントテンプレートに変換します。
   • デモに重要なインタラクションを維持します：ナビゲーション、タブ、ドロワー、モーダル、トグル、リスト詳細遷移、基本フォーム、ファイル入力。

5. ランタイムと抽出の詳細を解決します。

   • 実装前に開き方を選択します：直接file://ページ、またはフラグメントやESモジュールをフェッチする場合はHTTPプレビュー。HTTPを必要とする設計に対してダブルクリック操作を約束しないでください。可能な場合は既存のプレビューサーバーを再利用します。新しいサーバーの起動はユーザーの承認ルールに従います。
   • 完全なHTMLドキュメントとロード可能なフラグメントは明確に区別します。フラグメントをシェルに読み込む場合、その相対アセットとナビゲーションURLをシェルのベースに合わせて正規化します。フラグメントをそのまま挿入しても、ソースドキュメントのベースURLは保持されず、スクリプトも確実に実行されません。
   • インラインCSSをスタイルシートに移動する場合、url(...)、フォント、およびインポートパスを新しいスタイルシートからの相対パスに再ベースします。カスケード順序、詳細度、およびレスポンシブ動作を維持します。
   • 1つの一貫したスクリプトモデルを維持します。クラシックスクリプトのロード順序と共有状態を維持します。モジュールのインポート/エクスポート境界を維持します。明示的なブリッジなしでは、インラインハンドラはモジュールローカルな関数にアクセスできません。
   • ページの動作を明示的にマウントし、ビューを離れるときにリスナーやタイマーをクリーンアップします。ページを再訪したときにアクションが2回登録されないことを確認します。
   • 分割前に既存のストレージキーと状態遷移を棚卸しします。デモを動作させるためにストレージをクリアしたり、ユーザー作成データを黙って上書きしたりしないでください。

6. 引き渡しドキュメントを作成します。

   • ソースファイル、生成時刻、エントリページ、フォルダの目的、推奨される次のステップを含めます。
   • ドキュメントは簡潔で役立つものにします。

7. 検証します。

   • エントリHTMLファイルが存在することを確認します。
   • 各エントリまたは構成されたビューから、リンクされたCSS/JSパス、CSSアセットURL、フラグメントアセット、およびナビゲーションターゲットを確認します。
   • 可能な場合はローカルで開くかプレビューします。
   • ビジュアルプロトタイプの場合、ブラウザツールが利用可能であればデスクトップ/モバイルレイアウトを検証します。
   • 元のプロトタイプと主要なルートおよびインタラクションを比較します：初回レンダリング、前後ナビゲーション、ビューの再訪、モーダルの確認/キャンセル、および該当する場合は更新後の保存状態。
   • 未検証の動作や外部CDN依存関係のリスクについて言及します。外部リソースを確認せずにオフラインサポートを主張しないでください。

README / 使用説明書テンプレート

ユーザーまたはプロジェクトの言語で簡潔なREADMEを使用してください。以下の中国語の例は適応可能です。実際に生成されたエントリのみをリストし、HTTPが必要かどうかを記載します：

# プロジェクトプロトタイプ整理

生成時刻：YYYY-MM-DD HH:mm:ss

ソースファイル：元のファイル名.html

## 推奨開き方

- `分割ファイル版/index.html`
- `コンポーネント化版/index.html`

## 分割ファイル版

静的プロトタイプのデモとページごとのデザイン調整に適しています。各ページは独立したHTMLであり、ページ間はファイルリンクで遷移します。

## コンポーネント化版

Vue、React、Taro、uni-app、微信小程序、またはその他のフロントエンド構造への継続的な進化に適しています。

## 説明

- 元のファイルは変更されていません。
- 共通スタイルとスクリプトは`assets/`に整理されています。
- さらにエンジニアリング化する場合、`components.js`、`data.js`、`app.js`の移行を優先できます。

品質チェックリスト

最終応答の前に、以下を確認してください：

• 元のソースファイルが保存されている。
• 出力フォルダにタイムスタンプがある。
• エントリファイルの名前が明確である。
• アセットパスが各HTMLファイルから相対的に機能する。
• ページ間またはビュー間のナビゲーションが機能する。
• 重要なインタラクションが失われていない。
• READMEまたは使用説明書で開くファイルが説明されている。
• 最終応答に保存されたパスと検証結果が含まれている。