roblox-to-issues

Roblox → Issue（バーティカルスライス）

計画を、それぞれ単独で実装してプレイテストできる小さな Issue に分割します。「ゲーム全体を一気に作り、すべてが中途半端に壊れている」状態を防ぐ方法です。

トラッカーの場所とラベルの用語は、CLAUDE.md / docs/agents/ に記載されているはずです。見つからない場合は、setup-roblox-skills を実行してください。スライスは GitHub Issue（gh）または roadmap/<feature-slug>/slices/ 配下の Markdown ファイルとして公開します。どちらにするかは、セットアップ時の設定に従います。いずれの場合も、ROADMAP.md は人が読めるインデックスとして維持してください。

Roblox のバーティカルスライスとは

曳光弾のように、プレイヤーが実際に体験できる最小限のエンドツーエンドの経路です。通過するすべてのレイヤー（クライアント入力、サーバー権限、リモート、DataStore、UI）を横断し、単一の水平レイヤーにとどまりません。

• 正しい例（垂直）：「プレイヤーが鉱石をタップすると、サーバーがコインを 1 枚付与し、HUD に新しい残高が表示され、その残高は再参加しても維持される。」入力 + リモート + サーバー + データ + UI に触れています。プレイ可能です。
• 誤った例（水平）：「経済モジュール全体を作る。」「UI 全体を作る。」すべてが完了するまで何もプレイできません。まさに避けようとしている事態です。

スライスのルール

• 各スライスは、プレイヤー向けの狭い範囲の機能を完全に提供します。
• 各スライスは単独で、Studio のプレイテストで検証可能でなければなりません（これが受け入れの基準です）。
• 少数の大きなスライスより、多数の小さなスライスを優先してください。単独でプレイテストできないスライスは分割します。
• 価値のある状態（通貨、インベントリ、購入、報酬、進行状況）は、最初のスライスからサーバーが権限を持つようにします。後で修正するつもりでクライアントを信頼する近道を使ってはいけません。
• 最初のスライスは曳光弾です。コアループをエンドツーエンドで実証する最小の要素（1 回のアクション → 1 つの報酬 → 目に見える次の目標）です。何よりも先に作成してください。

スライスの種類

• AFK — 人間の判断なしで作成・検証できます。こちらを優先してください。
• HITL — 人間の対応が必要です。デザインの承認、バランスに関する判断、またはユーザーにしか実行できない Studio 操作などが該当します。UI のスライスは、承認済みの UI デザイン成果物ができるまでHITLです（roblox-game-ux を参照）。UI デザインがない場合は、まずデザイン承認スライスを作成し、UI スライスがそれに依存するようにしてください。

プロセス

1. コンテキストを集める

PRD / 会話を基に作業します。ユーザーから参照情報（Issue 番号、ROADMAP.md の行、またはファイルパス）が渡された場合は、全文を読んでください。現在のプレースの状態を確認する必要がある場合は、roblox-studio-workflow を介して接続します。ゲーム内で使われている用語を使用してください。

2. スライスを作成する

コアループの曳光弾をスライス 1にし、その後、機能を外側へ広げる順序にします（永続化 → 進行 → ソーシャル → 収益化 → 仕上げ）。後続の各スライスは、すでにプレイ可能なスライスを基盤にします。

3. ユーザーに確認する

分割案を番号付きリストで提示します。各スライスについて、以下を示してください。

• タイトル — 短く、プレイヤーに伝わるもの。
• 種類 — AFK / HITL。
• 依存先 — 先にリリースする必要があるスライス。
• プレイテストの確認項目 — 動作を証明するために Studio 内で実行する具体的な操作。
• サーバーが権限を持つか？ — はい / いいえ、および保護する状態。

粒度は適切か（粗すぎる / 細かすぎる）、依存関係は正しいか、さらに分割すべきスライスはあるか、HITL / AFK の分類は正しいかを質問してください。承認されるまで調整を続けます。

4. 公開する

承認された各スライスを、needs-triage ラベル / ステータスを付けて設定済みのトラッカーに公開します。実際の ID を参照できるよう、依存されるスライスから先に公開してください。パックの規則に従い、各スライスを ROADMAP.md にチェックボックスとして反映します。[ ] は未着手、[~] は実装とテストが済み承認待ち、[x] は実装 + プレイテスト + 人間による明示的な承認がすべて完了した場合にのみ使用します。

## 作成するもの

このスライスで実現する、プレイヤー向けのエンドツーエンドの動作。レイヤーごとの実装方法ではなく、プレイヤーが何をし、サーバーが何をするかを説明してください。

関係するレイヤー

• クライアント：...
• サーバー（権限を持つ）：...
• リモート：...
• データ / 永続化：...
• UI：...

プレイテストの確認（受け入れ条件）

• Studio のプレイテストで、 を実行すると になります。
• 価値のある状態はサーバーで検証され、再参加後も保持されます（該当する場合）。
• 新たなコンソールエラーがありません。
• モバイル：スマートフォンサイズのビューポートで読みやすく、タップしやすいこと（UI の場合）。

UI デザイン成果物

UI のスライスでは、承認済みの成果物をリンクするか（roblox-game-ux を参照）、または「UI デザインの承認待ち」と記載してください。

ブロック要因

ブロックしているスライスを記載するか、「なし — すぐに着手できます」と記載してください。

親 PRD／Issue は閉じたり変更したりしないでください。

次の手順

roblox-triage を実行してスライスを整理し、ビルド可能な状態のものに印を付けます。その後、各スライスを担当フェーズのスペシャリスト（例：roblox-luau-architecture、roblox-combat-systems、roblox-ui-implementation、roblox-datastore-persistence）とともに実装し、roblox-playtest-qa で検証してください。スライスの順序を決定する包括的な役割として、roblox-game-development-lifecycle を維持してください。