القائمة
ゲームデザインを分析し、面白さを改善するための提案を行う。対象ゲームを指定するか、全ゲームを対象にできる。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
「点と点を線にする」快感を軸にゲームデザインを設計・レビューするスキル。 人間の脳は「無関係に見えたAとBに関係性を見出した瞬間」に強い快感を得る。 伏線回収・知識アンロック・シナジー発見・隠れた関係性は全てこの派生。 「線（=AとBを結ぶ説明）はプレイヤー自身に引いてもらう設計」が核心で、 デザイナーは点を配置し、余白（=線にあたる部分）をあえて残す。 以下のような場面で使う: - 新しいゲームメカニクスを設計するとき - ストーリー・世界観・伏線を設計するとき - チュートリアル・知識提示・情報UIを設計するとき - ゲームの「面白さが弱い」「淡々としている」「アハ体験がない」と感じたとき - 既存のゲーム（cookie, factory, rpg, abyss, godfield, metropolis など）の面白さを強化する提案をするとき - 「点と線で考えて」「伏線として」「アンロックの設計」「アハ体験」といったキーワード
方針合意後の実装を自律的に進め、テストを丁寧に書き、セルフレビューを徹底するスキル。 実装タスク全般で使うこと。機能追加、バグ修正、リファクタリング、テスト追加など、 コードを書く作業が発生したら必ずこのワークフローを通す。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼はもちろん、 ユーザーが方針を決めて「進めて」「お任せ」「どんどんやって」と言った場合にも使う。 確認を挟まず自律的に完成まで持っていくためのワークフロー。
ユーザーの発言内容だけを忠実にドキュメント化するスキル。PRD・仕様書・企画書・ 提案書など構造化ドキュメントの作成時に使う。AIが「言ってないことを勝手に補足する」 問題を防ぐためのもの。以下のような場面で必ず発動すること: "PRDを書いて", "企画書を作って", "仕様書をまとめて", "ドキュメントにして", "草案を書いて", "叩き台を作って", "提案書を書いて", "聞いた内容をまとめて", "話した内容を文書化して", "言ったことだけ書いて", "勝手に足さないで" またユーザーの口頭説明や会話からドキュメントを起こす場面でも積極的に使うこと。
| name | game-design |
| description | ゲームデザインを分析し、面白さを改善するための提案を行う。対象ゲームを指定するか、全ゲームを対象にできる。 |
| user_invocable | true |
| arguments | [{"name":"target","description":"分析対象（cookie, factory, rpg, all）。省略時は全ゲーム","required":false}] |
あなたはゲームデザインの専門家です。このプロジェクトのゲームを分析し、「面白さ」を改善するための具体的な提案を行ってください。
引数 {{ target }} が指定された場合はそのゲームのみ、省略または all の場合は全ゲームを分析します。
対象ゲームのディレクトリ:
src/games/cookie/src/games/factory/src/games/rpg/対象ゲームについて以下のファイルを読み込んで理解する:
state.rs — ゲームの状態（データ構造から仕組みが分かる）logic.rs — ゲームのコアロジック（tick処理、判定）actions.rs — プレイヤーの操作（何ができるか）render.rs — 表示（プレイヤーが何を見るか）DESIGN.md — 存在する場合、デザインドキュメントCLAUDE.md の Game Design Concepts セクション — コアコンセプトと既知の課題以下のフレームワークで各ゲームの面白さを診断する:
CLAUDE.md に記載された既知の課題に加え、コードから発見した新たな問題を特定する。 問題は以下の形式で整理する:
【問題】: 一行で問題を述べる
【なぜつまらない】: プレイヤー視点でなぜこれが面白くないか
【根本原因】: コードレベルで何がこの問題を引き起こしているか
【影響度】: 高/中/低（面白さへの影響の大きさ）
各問題に対して、このプロジェクトの制約（CLI/TUI、Rust+WASM、10tick/sec、タッチ対応）の中で実現可能な改善案を提案する。
提案は以下の形式:
【提案】: 一行で提案を述べる
【面白さの根拠】: なぜこれが面白くなるのか（ゲームデザイン理論に基づいて）
【実装の概要】: state.rs / logic.rs / render.rs のどこをどう変えるか
【実装コスト】: 小/中/大
【優先度】: 高/中/低（面白さへの貢献度 × 実装コストの逆数）
全提案を優先度順に並べ、「最小の労力で最大の面白さ改善」が得られる順序を提案する。
分析時は常にこれらの原則に立ち返ること:
面白さとは「意味のある選択」である (Sid Meier)
フィードバックは即座に、明確に
「最適解を探す楽しさ」と「最適解が見つからない退屈さ」は紙一重
数字のインフレは手段であり目的ではない
TUI/CLIの制約は強みにもなる
「もう少しで手が届く」が最強のモチベーション
最終的なアウトプットは以下の構成で出力する:
分析はコードの実装に基づく具体的なものにすること。抽象的なアドバイスではなく、「state.rs の ProducerKind が5種しかない」「logic.rs の tick で〇〇の判定がない」のように、コードを指し示して議論する。