mcpField
D
design-system

design-system

github.com/donchitos開発29.1k538 回インストール2 週間前に更新
リポジトリ

design-system について

Claude向けのゲーム設計文書を共同作成するスキルです。コンテキスト収集からセクションごとの草案作成、検証まで進め、承認後に段階的に書き込み、進捗を記録して専門エージェントに相談します。

主な機能

  1. 01GDDの段階的な作成ガイド
  2. 02承認後の段階的な書き込み
  3. 03文書間の一貫性確認
  4. 04専門エージェントへの振り分け
  5. 05セッションの復旧と再開

活用シーン

  1. 01ゲームシステムのGDD作成
  2. 02中断した設計セッションの再開
  3. 03複雑なセクションへの専門家の助言

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/donchitos/claude-code-game-studios --skill design-system

インストール後、Claude Code で/design-systemを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
1-parse-arguments.md
2-gather-context.md
3-file-skeleton.md
4-section-design.md
5-post-design.md

詳細

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,docs.density,system_overrides

上記で解決済みです。そのまま使用してください。--review は review_mode を上書きします。ブロックがない場合は、.claude/docs/config-resolution.md のデフォルト値が適用されます。

デザインシステム

このスキルが呼び出されたとき：

1. 引数の解析と検証

今すぐ references/1-parse-arguments.md を読み、この指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された、または再開された場合は、もう一度読み直してください。

2. コンテキストの収集（読み取りフェーズ）

今すぐ references/2-gather-context.md を読み、この指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された、または再開された場合は、もう一度読み直してください。

3. ファイルの骨組みを作成

今すぐ references/3-file-skeleton.md を読み、この指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された、または再開された場合は、もう一度読み直してください。

4. セクションごとのデザイン

今すぐ references/4-section-design.md を読み、この指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された、または再開された場合は、もう一度読み直してください。

5. デザイン後の検証

今すぐ references/5-post-design.md を読み、この指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮された、または再開された場合は、もう一度読み直してください。

6. 専門エージェントへのルーティング

このスキルでは、ドメインの専門知識を持つ専門エージェントに委任します。メインセッションが全体の流れを調整し、エージェントが専門的な内容を提供します。

ここでの行は、意図的に9つの Category 値より細分化されています — 戦闘に適した専門家は経路探索に適した専門家とは異なり、どちらも Gameplay に分類されます。次の2段階で選びます。まず、systems-index.md からシステムの Category を確認し、次に、そのシステムが実際に行う処理に一致する行を選びます。すべてのカテゴリに少なくとも1つの行があるため、該当なしにはなりません。

Category以下から選ぶ行
Gameplay戦闘／ダメージ／体力 · AI／経路探索／行動 · アニメーション／キャラクター移動 · キャラクターシステム · カメラ／入力／操作
Core基盤／インフラストラクチャ · カメラ／入力／操作
Persistence基盤／インフラストラクチャ
Economy経済／戦利品／クラフト
Progression成長／XP／スキル
UIUI システム · ビジュアルエフェクト（システムが HUD に隣接する VFX の場合）
Audioオーディオシステム
Narrative会話／クエスト／伝承
Meta基盤／インフラストラクチャ（分析、チュートリアルの仕組み） · UI システム（アクセシビリティ設定画面）

2つの行が該当する場合は、両方の Primary エージェントを組み合わせて起動し、その理由を説明します。

システムの種類Primary AgentSupporting Agent(s)
基盤／インフラストラクチャ（イベントバス、セーブ／ロード、シーン管理、サービスロケーター）systems-designergameplay-programmer（実現可能性）、engine-programmer（エンジン統合）
戦闘、ダメージ、体力game-designersystems-designer（計算式）、ai-programmer（敵 AI）、art-director（被弾フィードバックのビジュアル方針、VFX の意図）
経済、戦利品、クラフトeconomy-designersystems-designer（成長曲線）、game-designer（ゲームループ）
成長、XP、スキルgame-designersystems-designer（成長曲線）、economy-designer（消費先）
会話、クエスト、伝承game-designernarrative-director（ストーリー）、writer（コンテンツ）、art-director（キャラクターのビジュアル設定、シネマティックなトーン）
UI システム（HUD、メニュー）game-designerux-designer（フロー）、ui-programmer（実現可能性）、art-director（ビジュアルスタイルの方針）、technical-artist（レンダリング／シェーダーの制約）
オーディオシステムgame-designeraudio-director（方針）、sound-designer（仕様）
AI、経路探索、行動game-designerai-programmer（実装）、systems-designer（スコアリング）
レベル／ワールドシステムgame-designerlevel-designer（空間設計）、world-builder（伝承）
カメラ、入力、操作game-designerux-designer（操作感）、gameplay-programmer（実現可能性）
アニメーション、キャラクター移動game-designerart-director（アニメーションスタイル、ポーズ表現）、technical-artist（リグ／ブレンドの制約）、gameplay-programmer（操作感）
ビジュアルエフェクト、パーティクル、シェーダーgame-designerart-director（VFX のビジュアル方針）、technical-artist（パフォーマンス予算、シェーダーの複雑さ）、systems-designer（トリガー／状態の統合）
キャラクターシステム（ステータス、アーキタイプ）game-designerart-director（キャラクターのビジュアルアーキタイプ）、narrative-director（キャラクターの成長との整合性）、systems-designer（ステータス計算式）

Agent ツールを使って委任する場合：

  • 次の情報を提供します：システム名、ゲームコンセプトの概要、依存する GDD の抜粋、作業対象のセクション、専門家の意見が必要な具体的な質問
  • エージェントは分析や提案をメインセッションに返します
  • メインセッションは AskUserQuestion を通じて、エージェントの出力をユーザーに提示します
  • ユーザーが決定し、メインセッションがファイルに書き込みます
  • エージェントはファイルに直接書き込みません — すべてのファイル書き込みはメインセッションが担当します

7. 復旧と再開

セッションが中断された場合（コンパクション、クラッシュ、新しいセッション）：

  1. production/session-state/active.md を読みます。現在のシステムと、完了しているセクションが記録されています
  2. design/gdd/[system-name].md を読みます。実際の内容があるセクションは完了済みで、[To be designed] のセクションはまだ作業が必要です。セクションごとに読みます。Grep ツール（パターン ^#、コンテンツモード）で見出しを探し、offset と limit を指定して該当範囲を Read します。
  3. 次の未完了セクションから再開します。完了済みのセクションについて、再度話し合う必要はありません

これが段階的な執筆が重要な理由です。承認済みの各セクションは、どのような中断があっても保持されます。

コラボレーションプロトコル

collaborative モード（デフォルト）の場合。 guided モードと autonomous モードについては、.claude/docs/automation-modes.md のモード別ルールを参照してください。以下の「決して」の項目は、コラボレーションモードで求められる内容であり、すべてのモードに普遍的に適用されるものではありません。

このスキルでは、すべての手順で協調的な設計原則に従います。

  1. すべてのセクションで 質問 -> 選択肢 -> 決定 -> 草案 -> 承認 の順に進めます
  2. あらゆる意思決定の段階で AskUserQuestion を使用します（説明 -> 記録のパターン）。
    • フェーズ 2：「開始する準備はできていますか。それとも、もう少し情報が必要ですか？」
    • フェーズ 3：「スケルトンを作成してもよいですか？」
    • フェーズ 4（各セクション）：設計に関する質問、アプローチの選択肢、草案の承認
    • フェーズ 5：「エンティティレジストリを更新してもよいですか？ システムインデックスを更新してもよいですか？ 次は何をしますか？」。「設計レビューを実行しますか？」ではありません。§5c では /design-review をインラインで提案することを禁止しています。レビューを行うエージェントに、このセッションの設計履歴を引き継がせてはならないためです。フェーズ 5c では引き継ぎを提示しますが、質問はしません。
  3. スケルトンの作成前、および各セクションの書き込み前に、「[filepath] に書き込んでもよいですか？」 と尋ねます
  4. 段階的な執筆：各セクションは承認後すぐにファイルへ書き込みます
  5. セッション状態の更新：各セクションの書き込み後に更新します
  6. 相互参照：各セクションで既存の GDD を確認し、矛盾がないか調べます
  7. 専門家へのルーティング：複雑なセクションでは専門エージェントの意見を求め、ユーザーに提示して判断してもらいます。黙って書き込むことはありません

決して GDD 全体を自動生成し、既成事実として提示してはなりません。 決して ユーザーの承認なしにセクションを書き込んではなりません。 決して 矛盾を指摘せずに、既存の承認済み GDD と矛盾してはなりません。 常に 決定の根拠（依存関係にある GDD、柱、ユーザーの選択）を示します。

コンテキストウィンドウの確認

このスキルは長時間にわたって実行されます。各セクションを書き込んだ後、ステータス行でコンテキストが 70% 以上になっているか確認してください。その場合は、次の通知を回答に追加します。

コンテキストが上限に近づいています（≥70%）。 進捗は保存されています。承認済みのセクションはすべて design/gdd/[system-name].md に書き込まれています。続行する準備ができたら、新しい Claude Code セッションを開き、/design-system [system-name] を実行してください。完了済みのセクションを検出し、次のセクションから再開します。

次のステップの推奨事項

  • 新しいセッションで /design-review design/gdd/[system-name].md を実行し、完成した GDD を独立して検証します
  • /consistency-check を実行し、この GDD の値が他の GDD と矛盾していないか確認します
  • /map-systems next を実行し、次に優先度の高い未設計のシステムに進みます
  • すべての MVP GDD の作成とレビューが完了したら、/gate-check technical-setup を実行します

コメント

Markdown 対応