taptap-maker-builder（TapTap 制造项目搭建） は何をしますか？
この Skill が行うこと
- Agent を素早く使いこなす：1 画面で TapTap 製造とは何か、2 つの創作方式の選び方、初回要件の 5 要素、クレジットとテーマ、Benchmark の読み方を説明；具体的な質問にはルーティングに従い対応するリファレンスのみを読む。
- 企画書からリリースまで：確認ゲート付きのフェーズ 0～6 で、企画書を段階的にプレイ可能なプロジェクトに構築。各フェーズに成果物、テンプレート、受入チェックリストがあり、ユーザーが確認してから次のフェーズに進む。
本 Skill は「どう進めるか」のみを担当し、ユーザーの代わりに実際のプロジェクトを起動はしません。プロジェクトへの変更はすべてユーザー自身の Maker プロジェクト内で行われ、事前に確認を得ます。
いつ使用するか
- ユーザーが TapTap 製造 / Maker / UrhoX / 製造研究所 / ランキング / クレジット / UI テーマ / ローカル MCP の接続方法について質問した場合。
- ユーザーがゲーム企画書や要件文書をアップロード・ペーストし、「組み立てて」「遊べるようにして」「これで作って」と要求した場合。
- ユーザーが Maker の会話要件を作成、クレジット消費を判断、リリース資料を確認、プレビューや実機の問題を調査する必要がある場合。
対象外：Unity / Unreal 等の他エンジン；純粋なアート外注；Maker に関係のない汎用プログラミング。
3 つの鉄則（違反したら停止）
- オンラインドキュメント優先：プロダクトは頻繁に更新されるため、まず https://maker.taptap.cn/llms.txt を読み、必要に応じて対応するドキュメントを読んでください。本 Skill の知識には整理日付があり、オンラインドキュメントと矛盾する場合はオンラインドキュメントを優先します；ドキュメントにない機能、パラメータ、モデル名、価格、上限は決して作り出さないでください。
- 確認ゲートはスキップ不可：フェーズ 0～5 の各フェーズ終了時にはまず「フェーズレポート」を提出し、ユーザーが明確に確認（「確認」「続ける」「OK」）してから次に進んでください。ユーザーが確認しない場合はその場で止めて確認を促してください。
- 勝手に課金・ファイル操作をしない：ユーザーが会話中に明確に要求しない限り、クレジットを消費する生成ツールを呼び出さない；モデルやチャネルを自動で変更しない；ユーザーのファイルを移動、削除、上書きしない；企画書の範囲を超える新システムは事前に同意を得てください。
60 秒プロダクト概要
| 観点 | ポイント |
|---|---|
| プロダクト | TapTap 製造（TapTap Maker）：ゲーム愛好家向け AI ゲーム創作ツール。自然言語による企画設計、コード実装、素材制作、プレビュー反復、リリース準備を実現 |
| 基盤 | UrhoX エンジン + Lua スクリプト；Astroon / BrawlForge / PixelForge の 3 つの UI テーマを内蔵 |
| スローガン | 対話が創作、完成がリリース |
| 2 つの創作方式 | ブラウザワークスペース（プロジェクト、対話、プレビュー、リリースを同一ページで）；ローカル開発モード（Maker MCP でローカルディレクトリに接続、Codex / Cursor / Claude Code をサポート） |
| 公式エントリー | https://maker.taptap.cn/llms.txt（全ドキュメントの総合インデックス、最も新しい情報を提供） |
初回要件の 5 要素（要件を書く前に必ず回答できること）：プレイ目標 / 表現形式 / 操作方法 / コアサイクル / 初回範囲。
クレジット：汎用、基本、アクティビティ、プロジェクト、有料の 5 種類；デフォルトの消費順序は アクティビティ → プロジェクト → 基本、汎用と有料が使用可能かどうかは現在のモデル、プロジェクト範囲、サーバー側の検証にも影響されます。リリースパネルの操作は創作クレジットを消費しません。
Benchmark：実際の UrhoX ヘッドレス実行 + 決定的アサーション、メインボードのトップ指標は L2 通過率；各スコアには 95% 信頼区間が付与され、各順位には可能性の範囲が付与されます——範囲が重なる場合は「現在のサンプルサイズでは順位を確定できない」と解釈します。
references ナビゲーション（必要なものだけ 1 つ読む）
| 質問やシナリオ | 読むもの | 内容 |
|---|---|---|
| プロダクトとは何か、2 つの方式の選び方、MCP のインストール方法、ディレクトリ構造、コラボレーターの追加方法 | ./references/01-product-overview.md | 位置づけと能力範囲、方式比較、インストールコマンド、ディレクトリ構造、ローカルランタイム、コラボレーションルール |
| クレジットの消費方法、何がクレジットを消費するか、結果が不明な場合の対処法、節約方法 | ./references/02-credits-and-cost.md | 5 種類のクレジット、消費順序、コスト管理、uncertain 台帳 |
| どのテーマを選ぶか、テーマの指定方法、素材の仕様と上限、AI 画像生成プロンプトの書き方 | ./references/03-ui-themes-and-assets.md | 3 テーマの適応ジャンルとビジュアルルール、素材 5 種の制限、DWP、素材ディレクトリの規則 |
| ランキングの見方、L2 とは何か、信頼区間と順位範囲の読み方 | ./references/04-benchmark-guide.md | 3 段階評価、各次元の意味と誤解、統計手法、限界 |
| 企画書の分解方法、5 要素が不足している場合の質問方法、最初の要件の書き方 | ./references/05-brief-parsing-and-first-prompt.md | 抽出表、質問の上限と方法、確認シートのポイント、初回要件の良い/悪い例 |
| 反復の提案方法、4 部構成の書き方、プレビュー 5 項目 / リリース前 6 項目 / データ 6 条 | ./references/06-iteration-and-acceptance.md | 4 部構成の書き方、公式の推進順序、受入チェックリスト、一般的な失敗パターン |
| リリースに必要な資料、QR コードテスト版の進め方、共有ページの開き方 | ./references/07-publish-checklist.md | 資料リストと仕様、リリースフロー、テスト版同期、リリース後のアクション |
| 認証情報の保存場所、不可逆な操作、アトミック書き込み、素材の著作権、コラボレーションの安全性 | ./references/08-safety-and-credentials.md | 有効期限、コスト、認証情報、不可逆操作、アトミック書き込み、範囲と著作権 |
ルール：現在の質問に関連するものだけを 1 つ読む；読んだ後に回答し、記憶に基づいて詳細を補わない。
フェーズ概要（0–6）
| フェーズ | 目標 | 成果物 | 確認ゲート | ツール / テンプレート |
|---|---|---|---|---|
| 0 接続 | 創作方式を決定；ローカルモードで MCP、プロジェクトバインディング、既存ディレクトリを確認 | 接続確認 + ディレクトリ確認結果 | ユーザーが方式と環境を確認 | ./scripts/check_project_layout.py |
| 1 解析 | 5 要素を構造化抽出、不足分を一括質問（≤4 問） | 企画書理解確認シート | ユーザーが 5 項目を 1 つずつ確認してから要件作成 | ./assets/brief-confirmation-template.md、./scripts/check_brief.py |
| 2 初回要件 | 公式仕様に沿った最初の要件に変換、最小限のプレイ可能なコアサイクルのみ | 初回要件テキスト + テーマと画面方向 | ユーザーが要件とテーマ方向を確認 | ./assets/first-prompt-template.md |
| 3 反復 | 最小限プレイ可能 → ブロック修正 → テンポ・数値・手触り → 素材・効果音・ガイド資料 | 各ラウンドの 4 部構成要件 + 検証結果 | 各ラウンドの結果受入後に次のラウンドへ | ./assets/feedback-four-part-template.md、./references/06-iteration-and-acceptance.md |
| 4 プレビュー実機 | 5 項目受入 + 実機テスト QR コード | 受入記録、問題リスト | 5 項目すべて合格でリリースへ | ./references/06-iteration-and-acceptance.md、./references/07-publish-checklist.md |
| 5 リリース | 資料を 1 つずつ確認、バージョン一致後にリリース | リリース資料確認シート | ユーザーが資料とバージョンの一致を確認 | ./scripts/check_publish_materials.py、./assets/stage-report-template.md |
| 6 常時 | コストとセキュリティの保護、全フェーズで有効 | リスク通知と確認記録 | 高リスク操作は毎回確認 | ./references/02-credits-and-cost.md、./references/08-safety-and-credentials.md |
推進ルール：各フェーズ終了時にまず「フェーズレポート」を提示 → ユーザーの明確な確認を待つ → 次のフェーズに進む。
フェーズ 0：接続
まず一度に 3 つのことを質問し、複数回に分けて聞かない：
- ブラウザワークスペース を使用するか、ローカル MCP（ローカルディレクトリ + Codex / Cursor / Claude Code）を使用するか？
- 既存のプロジェクトか新規か？プロジェクト名、ゲームの方向性は？
- 再利用する既存の素材やコードディレクトリはあるか？
| 状況 | 推奨 |
|---|---|
| 初めてで、すぐに画面を見たい | ブラウザワークスペース |
| 既存のローカルコードや素材があり、Codex / Cursor / Claude Code のワークフローを使いたい | ローカル MCP |
| Git 連携、共同作業、ローカルでのチェックが必要 | ローカル MCP |
| スマートフォンで手軽に試遊したいだけ | ブラウザワークスペース + 共有 QR コード |
ローカルモードのコマンド（対象ディレクトリで実行；init はプロジェクトを現在のディレクトリにプルします。事前にディレクトリが空か、ユーザーが統合に同意していることを確認してください）：
npx -y @taptap/maker install --ide codex,cursor,claude # 3 つの MCP 設定のみ書き込み
npx -y @taptap/maker init # ログイン + プロジェクト選択/作成 + ディレクトリバインド + プル
- 初期化後の典型的なディレクトリ：assets/（image、sprites、audio、video を含む）と scripts/；実際の構造はプロジェクトによって異なります。
- 操作前に
python ./scripts/check_project_layout.py <プロジェクトルート>を実行し、既存のディレクトリと説明を読んで、使用中のリソースを上書きしないようにしてください。 - コンポーネントの更新：「現在のプロジェクトの Maker MCP と AI DevKit を更新し、実際に使用されているバージョンを教えてください」；本番環境では pd/stable、テスト環境では rnd/latest。
- 認証情報は信頼できるローカル環境にのみ保存し、プロジェクトファイルや Git には書き込まないでください。
確認ゲート 0 のトーク：「X 方式で接続します。プロジェクトディレクトリは Y、既存の構造は Z で、A は上書きしません。確認後、企画書解析に進みます。」
フェーズ 1：企画書解析
フロー：
- 企画書全体を読み、5 要素表を直接抽出します（全文をそのまま繰り返さない）。
- 各項目にラベル付け：あり（原文による）/ 推定（確認が必要）/ 欠落。
- 欠落と重要な曖昧さは一括で質問、≤4 問、各質問に 2～3 つの候補回答を提示し、回答の負担を減らします。
- 「企画書理解確認シート」を作成。「私が理解したこと / 不確定なこと / 初回で省くことを提案するもの」を必ず含める。
- ユーザーが確認してからフェーズ 2 に進みます。
ハードルール：
- 重要な設定（テーマ、主人公、勝敗条件、操作方法、ターゲットプラットフォームと画面方向）は勝手に補完しない；不足している場合は質問するか、明確に「保留」とマークしデフォルトの提案を提示します。
- 企画書内の後期システム（育成、ショップ、マルチプレイ、ランキング、複数チャプター）はすべて「後続バージョン」に入れ、初回範囲には含めない。
- 確認シートには必ず「初回でやらないこと」を明記する。
必要に応じてスクリプトで 5 要素の完全性を確認できます（JSON 構造はスクリプトヘッダーのコメント参照）：
python ./scripts/check_brief.py brief.json
フェーズ 2：初回要件生成
初回要件を書く順序：一言で位置づけ → 5 要素 → 操作と勝敗 → 画面リスト → 範囲外。
- 1 つの要件で 1 つの結果だけを解決する；まず最小限のプレイ可能なコアサイクルを作る。
- 「このラウンドでやらないこと」を明確に示すことは、機能を羅列するよりも範囲を絞り込むのに効果的。
- 同時に確認：UI テーマ（Astroon / BrawlForge / PixelForge）、画面方向（横 / 縦）、視点（2D / 3D）、アートの基本トーン。
- テンプレート：./assets/first-prompt-template.md；良い/悪い例は ./references/05-brief-parsing-and-first-prompt.md を参照。
テーマと方向確認のトーク：「A テーマ（理由：ジャンルに適合）をお勧めします。縦画面 2D。もし B がよければ、B に合わせて変更します。確認後、最初の要件を送ります。」
フェーズ 3：反復構築
公式の推進順序（スキップ不可）：
- 最小限のプレイ可能バージョン（開始、操作、終了、再開が可能）
- ブロックとなるフロー問題の修正（フリーズ、ボタンが押せない、状態がリセットされない）
- テンポ、数値、手触りの調整
- 素材、効果音、ガイド、リリース資料の追加
各ラウンドの要件は 4 部構成で：目標 / 現状 / 制約 / 受入（テンプレート ./assets/feedback-four-part-template.md）。
- 一度に 1 つの結果に集中する；「効果音追加 + 数値変更 + テーマ変更」を同じ要件に書かない。
- 「制約」には保持すべきものを書く（既存の操作、確認済みテーマ、リファクタリングしないモジュール）。
- 「受入」は観察可能な現象として書き、「もっと面白く」とは書かない。
- AI に自身で構築、エラーチェック、検証結果の説明を要求する；複雑な変更は最初に簡潔な計画を提示させる。
- 同じ目標は同じ会話に留める；方向性を変える場合は新しい会話を開始する。
バグ報告時は 5 つの情報をすべて提供：デバイス / ページ、操作手順、実際の現象、期待する現象、再現可能かどうか（スクリーンショットや録画を添付可）。
フェーズ 4：プレビューと実機
5 項目の受入（公式リスト、各項目の結論を記録）：
- 正常に開始できますか？
- 操作は期待通りですか（タッチエリア、ボタンの押しやすさを含む）？
- 成功 / 失敗 / 再開は完全ですか？
- ターゲットデバイスで画面は鮮明ですか（フォントサイズ、コントラスト、セーフエリア）？
- フローを妨げる問題はありますか？
デバイスと共有：
- デスクトッププレビューでは PC / スマホ / タブレットと解像度を切り替え可能（iPhone 17 の Dynamic Island マスクを含み、そのエリアのクリックをブロックします）。
- 実機：プレビューツールバーの「共有」→ リンク / QR コード；共有ページを作成する前に、リリースパネルで完了済みの開発者認証を受けたリリース事業者を選択する必要があります。
- 実機テスト QR コード：「スマホでテストするために QR コードをスキャン」→「テスト版を更新」→ スキャン；コード / 方向 / 設定 / 素材を変更した後は再度更新する必要があります。更新しないと古いバージョンがスキャンされます。
- 縦横画面の切り替えは AI に同時に画面レイアウトとプロジェクト方向設定を変更させる；変更後は再構築し、プレビュー / 実機でボタン、テキスト、タッチ操作を確認します。
受入に不合格の場合はフェーズ 3 に戻って 4 部構成の要件を書き、リリースに飛ばない。
フェーズ 5：リリース準備
資料リスト（1 つずつ確認）：
- ゲームアイコン
- 最低 3 枚のゲームスクリーンショット
- 宣伝画像、横長カバー、縦長カバー
- 縦画面ゲームの場合は別途四角い宣伝画像
- ゲーム名
- ゲーム紹介 ≥10 文字
- 「開発者からのコメント」≥10 文字
- 初回正式リリースに必要な実機テスト動画
フロー：資料生成（クレジット消費、ユーザーの明確な同意が必要）→ リリースパネル確認 → テスト版を更新し QR コードで再確認 → 正式リリース。
- 複数のリリース事業者がある場合は最初に事業者を選択；資料生成フェーズ完了後にリリースボタンが使用可能になります。
- リリースパネルの操作自体は創作クレジットを消費しません。
- リリース前の健全性チェックは ./references/06-iteration-and-acceptance.md（リリース前 6 項目、データチェック 6 条）を参照。
- 確認コマンド：
python ./scripts/check_publish_materials.py materials.json --root <プロジェクトルート>。
フェーズ 6（常時）：コストとセキュリティの保護
各フェーズで実行：
- クレジット：ユーザーが会話中に明確に要求しない限り、クレジットを消費する生成ツールを呼び出さない；高消費の前には「何に使われ、おおよそいくらか、節約できるか」を説明する；モデルやチャネルを自動で変更しない。
- 結果不明の場合は再送信しない：送信後に明確な結果が得られなかった場合 → uncertain とマークし、まずステータスを確認する；どうしても再送信が必要な場合はユーザーに確認し、既に課金されている可能性があることを説明する。
- 認証情報：表示しない、代わりに記入しない、プロジェクトファイルや Git に書き込まない；信頼できるクライアントにのみ許可する。
- 不可逆操作：素材の削除や上書き、モデルの置き換え、チャネルの切り替え、設定のクリア、正式リリース——まず停止し、影響と取り消し方法を説明し、明確な「はい」を得てから実行する。
- 範囲：企画書の範囲内でのみ構築する；新しいシステムやゲームプレイの追加は事前に同意を得る；ユーザーのファイルを勝手に移動、削除しない。
- アトミック書き込み（スクリプトやツールでファイルを書き込む場合）：一時ファイル + 名前変更；空の値で既存の値を上書きしない；破損したファイルは保存して現場を残す。
詳細は ./references/08-safety-and-credentials.md と ./references/02-credits-and-cost.md を参照。
フェーズレポート
次のフェーズに進む前に、./assets/stage-report-template.md を使用して 4 つのブロックを出力：今回のフェーズで行ったこと / 成果物 / 検証結果 / 次のステップと確認が必要な点。レポートの最後は回答可能な確認リクエストでなければなりません。
メンテナンスと有効期限
- 本 Skill の知識整理日：2026-11-03。プロダクトは頻繁に更新されるため、機能、パラメータ、モデル、価格、上限に関してはすべてオンラインドキュメントを優先します。
- 矛盾の処理：オンラインドキュメント > 本 Skill。不一致を発見した場合は、オンラインドキュメントに従って実行し、回答内で違いを説明します。
- 更新方法：まず https://maker.taptap.cn/llms.txt を読み、該当するページを見つけます；原文が必要な場合は、対応する .md アドレスのプレーンテキストを取得します。
- 作成禁止：ドキュメントにない機能、パラメータ、モデル名、価格、上限は、すべて「ドキュメントに記載がありません。確認するか、ページを参照してください」と回答します。
サンプルプロンプト
- 「縦画面 2D の回避ゲームを作りたいです。まず進め方を教えてください。」→ フェーズ 0 / 1。
- 「これが企画書です（添付）。組み立ててください。」→ フェーズ 0 から、段階的に確認。
- 「Maker のクレジットはどう消費されますか？画像 1 枚の生成にはいくらかかりますか？」→ references/02 のみ読み、直接回答、ワークフローに入らない。
- 「ランキングで L2 通過率 60% と 63% の差は大きいですか？」→ references/04 のみ読み、信頼区間と順位範囲を説明。
- 「Astroon テーマでスタート画面を作ってください。ゲームプレイは変更しないで。」→ フェーズ 3、4 部構成の要件を作成。