UIラボ: UX提案
UX提案は3つのフェーズを経ます:
- モック — プロジェクトのラボノートで指定されたプラットフォーム上で、ラボコードのみを変更します。オーナーがオプションをタップして確認します。
- ラウンドを終了する — ラウンドにタグを付け、
docs/ux-history/に書き込み、ラボファイルを削除します。 - 本番反映 — オーナーがオプションを選択し、計画を承認した後、そのオプションが実際の画面になります。共有ロジックと、アプリに別のプラットフォームがある場合はそのプラットフォームも含めて反映します。
プロジェクトのラボノート
このスキルはプロセスです。各プロジェクトの詳細は .claude/ui-lab.md にあります。最初にこれを読んでください。以下の情報が含まれています:
- プラットフォーム: このマシンで使用するラボアプリ (
uname -s)、そのID、ラボコードの場所、画面を開くコマンド; - オプションフォルダ: プラットフォームごとのフォルダとパッケージ、および文字列の場所;
- ファイル: オプション画面が使用するテーマや色、プロモーション時に状態が移動する場所;
- サンプルデータ: オプションがデータを構築する元;
- フェイクとエッジケース: このアプリで表示できない架空のデータと、確認すべきケース;
- スクリーンショット: プラットフォームごとの撮影方法;
- 本番反映: ターゲットパス、他のプラットフォームの処理、更新するドキュメント、リリースビルドコマンド;
- ラボ自体の動作方法（ドキュメントリンク）。
ノートがこのスキルと異なる場合はノートが優先されます。プロジェクトに .claude/ui-lab.md がない場合、または以下に必要な情報が不足している場合は、推測せずにオーナーに確認し、その回答をノートに追加してください。
フェーズ1: モック
現在のブランチから ux/<screen> ブランチで作業し、別のマシンがラウンドをプルできるようにします。ツリーにあなたのものではない未コミットの変更がある場合は、切り替える前に確認してください。
オプションごとに1つのフォルダ
各オプションは独自のフォルダ（ノートに場所が記載）に配置されるため、単独で削除、復元、または本番反映できます。画面のパッケージ内にあるため、本番反映はファイルの移動です。
| ファイル | 内容 | 本番反映時 |
|---|---|---|
<Screen>Option<B> | 画面, <Screen>Screen<B>(state, actions): プロダクション品質（アプリの文字列とテーマ、ノートに従う）で、ラボタイプは含まない | アプリに移動 |
<Screen>Option<B>State | アプリのロジックがまだ生成しない状態。アプリが生成するであろう形に成形 | ノートに指定された場所に移動 |
<Screen>Option<B>Lab | サンプルデータ、フェイク動作、何もしないアクション、およびその上にフェイクする内容を示す LabOption 値 | 削除 |
| オプションの文字列（アプリが文字列リソースを使用する場合。名前と場所はノートに従う） | オプションの新しいテキスト | アプリの文字列に移動 |
- フォルダ（およびリソースがフォルダに配置できない場合の文字列ファイル）に加えて、オプションは
LabScreensの画面リストに1行追加します（<screen>OptionB,）。 - フォルダ内のすべては
privateです。ただし、画面、その状態、およびLabOption値は除きます。これらの名前にはオプションが含まれているため、オプション間で競合することはありません。 - 既存のアプリコンポーネントの変更バージョンが必要なオプションは、そのフォルダ内に独自のコピーを使用します。
- サンプルデータは、ノートに指定されたソースからそのまま取得し、オプションが
Labファイルで追加するものも含みます。ノートでデータが本物であると指定されている場合、テキストをでっち上げないでください。
手順
- ラボで画面を開き、
current（現在アプリにある画面）を確認します。 - 2～3の異なる方向性をオプション
a,b,cとしてcurrentの後に作成し、それぞれに何を変更するかの1行メモを付けます。 - 各
LabOption値の上に、そのオプションがフェイクする内容をリストします: アプリのロジックに欠けているデータ、構築されていない動作、および表示できない架空のデータ（ノートにこのアプリの通常のものがリストされています）。 - ノートにリストされているエッジケースと、画面にとって異常なものを確認します。デザインを変更するケースは独自のオプション（
a-rtl,a-dark）になります。 - ビルドし、各オプションを開いてスクリーンショットを確認します（コマンドはノートにあります。android-emulator スキルはAndroidデバイスをカバーします）。電話からの全黒のスクリーンショットはロックされていることを意味します: オーナーにロック解除を依頼してください。
- ブランチにコミットし、オーナーにオプションID（
<screen> <option>）、各オプションがフェイクする内容、およびデバイスを伝えます。
オーナーがオプションの変更を依頼した場合、変更は独自のフォルダに新しいオプション（b の隣に b2）として作成されます。オーナーが却下したオプションはラウンドが終了するまで残り続け、ラウンドのタグにはそれらすべてが含まれます。
フェーズ2: ラウンドを終了する
オーナーがオプションを選択したか、すべてを却下した場合:
- すべてのオプションがまだ含まれている状態で、ラウンドの最後のコミットにタグを付け、タグをプッシュします:
git tag ux/<screen>/<yyyy-mm-dd> && git push origin ux/<screen>/<yyyy-mm-dd>。タグはブランチが削除された後もコードにアクセスできるようにします。同じ日に2回目のラウンドがある場合は-2を付けます。 - 以下の形式で
docs/ux-history/<screen>/<yyyy-mm-dd>-<topic>.mdを作成し、ノートに指定された場所（画面のドキュメントなど）にリンクします。 - 他のオプションのフォルダ、文字列ファイル、
LabScreensの行を削除します。選択されたオプションはフェーズ3まで残ります。 - コミットします。すべてのオプションが却下された場合、ラウンドはここで終了します: ブランチをマージするか（履歴ファイルが唯一の恒久的な変更です）、オーナーの好みに応じて削除します。
# <Screen> — <topic> (<yyyy-mm-dd>, <platform>)
Tag: `ux/<screen>/<yyyy-mm-dd>`
## オプション
- **a — <name>**: <変更内容>。*選択済み*、<commit> で本番反映。
- **b — <name>**: <変更内容>。*却下*: <理由（指定されている場合）>。
## フェイクした内容
- b: <モックで表示した、アプリがまだ実行できない内容>。
## オプションの復元
git checkout ux/<screen>/<yyyy-mm-dd> -- <オプションフォルダ> <文字列ファイル>
次に `<screen>Option<B>,` を `LabScreens` に追加します。
タグ時点で使用していた <コンポーネントとサンプルデータ> に対してビルドされています。復元後のコンパイルエラーは、オプションのコピーとサンプルデータにあります。そこで修正してください。
復元
オーナーが以前のオプションを要求した場合、その履歴ファイルに従います: タグから ux/<screen> ブランチにパスをチェックアウトし、LabScreens 行を追加し、オプションのフォルダ内でコンパイルできなくなったものを修正し、開きます。それが新しいラウンドの有効なオプションになります。
フェーズ3: 本番反映
選択されたオプションでラウンドが終了したら、プランモードに入り（EnterPlanMode）、ExitPlanMode で計画を提示します。オーナーはボタンでそれを承認します。計画は以下をカバーします:
- 移動するファイルと、それらが置き換える画面;
- フェイクされた各項目の背後にあるロジック作業: 提案された状態、ビューモデルまたはコントローラーの変更、およびそれらのテスト;
- アプリに別のプラットフォームがある場合、ノートに従ったそのプラットフォーム;
- ノートが更新を指示するドキュメント。
承認後、同じブランチ上で:
git mvでオプションの画面ファイルをアプリに移動し（ターゲットはノートに従う）、古い画面を置き換え、関数またはビューに画面の名前を付けます。- オプションの接頭辞やテーブルなしで、その文字列をアプリの文字列に移動します。
- その状態をノートに指定された場所に移動し、テストでアプリのロジックに生成させ、アクションを接続します。
- コピーしたコンポーネントをオリジナルに統合し、フォルダの残りと
LabScreens行を削除します。LabScreensの画面のcurrentを昇格された画面にポイントします。 - ノートのコマンドでリリースビルドを行います。ラボコードへの参照があるとコンパイルに失敗します。
- 計画の他のプラットフォームとドキュメント部分を実行し、本番反映のコミットをラウンドの履歴ファイルに記録します。
ブランチのマージはオーナーの判断に委ねられます。