利用者が触れる面を試作で先に固める

機能の要件を文書にする前に、利用者が触れる面の試作を作り、/show-prototype で人と往復して固め、決定を docs/features/<slug>/ux.md に書き出す。要件・受入基準・クリティカル設計の文書化は /define-feature が行う。

本スキルは対話前提である。メインセッションで人と往復する。対話相手の人がいない（headless）で起動された場合は、手順 1〜3（媒体の推定・場面の一覧・試作の作成）までを進め、試作を見せる手順 4 の前で停止して報告する。媒体と場面の一覧は人に確かめられないため、scenes.md に「推定のまま」と印を付けて書き、報告にも同じ印で書く。ux.md は書かない。呼び出し元のエージェントを人の代わりにして試作を固めない。

入力

テーマや機能名: $ARGUMENTS（無ければ人に聞く）。{slug} は機能名をケバブケースにしたもの（例: task-export）。

起動したら docs/features/*/prototype/ を探す。<slug> と一致するものが無くても、機能名に近いものがあれば同じ機能かを人に確かめ、同じならその <slug> を使う。既存の試作があれば、作り直さずその試作から再開する。再開するときは prototype/scenes.md を読み、媒体か場面の一覧に「推定のまま」の印が残っていれば、手順 1・2 の確認からやり直す。

手順

1. 媒体を決める

マニフェスト・ディレクトリ構成・既存の画面やコマンドの定義と、テーマの文面から媒体（Web・CLI・API・バッチ・ゲームの画面の流れ）を推定し、推定の根拠を添えて人に確かめる。1 つの機能が複数の媒体に触れるなら、触れる媒体をすべて挙げて確かめる。決めた媒体は手順 2 の scenes.md に書く。

2. 場面の一覧を決める

利用者が通る主要な流れと、そこで出会う状態（通常・空・エラー・権限なし等）を場面の一覧にして人に確かめる。この一覧が手順 4 の固め終わりの判定に使う網羅の基準になる。

媒体と場面の一覧を docs/features/<slug>/prototype/scenes.md に書く。範囲から外した場面は理由とともに残す（手順 4 で外した場面もここへ足す）。

# {機能名} の場面の一覧

- 媒体: {Web / CLI / ...}（人が確かめた / 推定のまま）
- 場面の一覧: 人が確かめた / 推定のまま

| # | 媒体 | 場面 | 状態（対象 / 範囲外） | 範囲外の理由 |
|---|------|------|---------------------|-------------|

3. 試作を作る（媒体ごと）

置き場所は docs/features/<slug>/prototype/。媒体が 1 つなら直下に置き、複数なら媒体ごとのサブディレクトリ（web/・cli/・api/・batch/・game/）に分ける。

• Web: 静的な HTML。状態ごとに 1 ファイルとし、遷移はリンクで表す。入口は index.html に固定し、そこから全状態へリンクでたどれるようにする。file:// で開いて動く作りに限る（<script type="module">・fetch・外部の CDN を使わない。データは HTML に直接書く。通常の <script> は使ってよい）
• CLI: 場面ごとに、入力したコマンドと出力・エラー時の表示と終了コード・--help を Markdown に書く
• API: 呼び出しごとに、リクエストとレスポンスの組（正常・エラー・ページング）を書く
• バッチ: 入力と出力のサンプル・ログ・通知の文面・失敗したときに運用の担当者が見るものを書く
• ゲームの画面の流れ: Web と同じ作り（入口は index.html）の静的な HTML で、画面の流れ・HUD の配置・操作の割り当て・1 ループを表す。手触り（操作の重さ・テンポ・当たり判定）と見た目（絵・演出）は扱わない

既存の画面・コマンドを変える機能では、変える画面・場面だけを、いまの見た目をおおまかに写して作る。既存の素材は参照してよく、無いもの（画像を含む）は置き場所と大きさを示すプレースホルダーにする。本番のコード・スタイル・技術スタックは取り込まない。本番のデータ・外部サービスに接続しない。

4. /show-prototype で往復して固める

媒体ごとに /show-prototype を順に呼び、試作のディレクトリ（媒体が複数なら媒体のサブディレクトリ）と媒体を渡す。媒体が 1 つで scenes.md が同じディレクトリにあるときは、scenes.md は場面の一覧であって試作のファイルではないと添える。

すべての媒体の /show-prototype が返ったら、次を人に聞く。

• 見せていない場面: 報告の「見せた画面・場面」を scenes.md の対象の場面と突き合わせ、一度も見せていない場面があれば、見せるか範囲から外すかを聞く。範囲から外すなら scenes.md の状態を範囲外にして理由を書く
• 見送り: 報告の「見送った点」（媒体を変える・作り直しになる指摘）があれば、1 件ずつ試作を作り直すか、ux.md の未決に残すかを聞く
• 試作の制約: 報告の「試作の制約」が 1 件以上あれば、1 件ずつ試作を作り直すか、ux.md の未決に残すかを聞く

作り直すと決めたものがあれば手順 3 へ戻って試作を直し、手順 4 の頭から /show-prototype を呼び直す。見せると決めた場面があれば（作り直しが無くても）手順 4 の頭へ戻って /show-prototype を呼び直す。

最後の /show-prototype が返り、上の問いがすべて片付いたら、本スキル自身が人に「これで固めてよいか」を確かめる。次の 3 つがそろったら固め終わりとする。

• 人が本スキルの問いに「これで固める」と答えた
• すべての feedback.md で状態が「未反映」の行が 0 件
• scenes.md の対象の場面がすべて一度は見せてある

5. 決定を書き出す

docs/features/<slug>/ux.md に次の形で書く。シナリオの表は、実装後の /demo のシナリオに写せる粒度で書く（完了条件との対応付けは /define-feature が行う）。

# {機能名} の UX の決定

- 媒体: {Web / CLI / API / バッチ / ゲームの画面の流れ}
- 試作: docs/features/<slug>/prototype/
- 指摘一覧: {feedback.md のパス}（反映済み N 件 / 見送り N 件）

## 決定

| # | 画面・場面 | 決めたこと | 出どころ（feedback.md の # か手順） |
|---|-----------|-----------|----------------------------------|

## シナリオ

| # | シナリオ | 前提 | 操作 | 見えるもの | 試作のファイル |
|---|---------|------|------|-----------|--------------|

## 未決・見送り

- {見送り・試作の制約と、未決に残した理由}

## 範囲外

- {範囲から外した場面と理由・試作で扱わなかったこと}

• 指摘一覧は媒体ごとに 1 行ずつ書く
• 決定の表の出どころは、指摘から来たものは feedback.md の #（媒体が複数なら web#3 のように媒体を前に付ける）、指摘から来ていないものは 手順 1・手順 2 のように手順で書く
• 「未決・見送り」には、未決に残すと決めた見送りと試作の制約を書く。作り直して解決したものは書かない
• 「範囲外」には、scenes.md で範囲外にした場面と理由、試作で扱わなかったことを書く

試作は固めた時点の写しであり、実装後に更新しない。

6. 完了報告

## UX の決定 完了

- UX の決定: docs/features/<slug>/ux.md
- 試作: docs/features/<slug>/prototype/
- 決定 N 件 / シナリオ N 件 / 未決・見送り N 件

次のステップ:
/define-feature {機能名}（ux.md を渡す）

人が途中でやめた場合は、試作・scenes.md・feedback.md をそのまま残し、同じ機能名で本スキルを呼び直すと再開できることを示して終わる。

注意事項

• 試作を見せる・指摘を記録して反映するのは /show-prototype の役目であり、本スキルでは行わない
• 要件・受入基準・クリティカル設計は決めない（/define-feature の役目）
• 画像・演出は生成しない
• 試作（scenes.md を含む）と ux.md は機能仕様と一緒にコミットする。本スキルはコミットしない