gds-code-review について
gds-code-reviewは、ゲーム開発のコード変更を審査するためのスキルです。並行する敵対的レビューと構造化されたトリアージで、実行可能な指摘をまとめます。
主な機能
- 01並行する敵対的レビュー
- 02指摘の構造化トリアージ
- 03ワークフローのカスタマイズ
- 04永続的なプロジェクト情報の読み込み
- 05段階的な実行
活用シーン
- 01ゲームコード変更のレビュー
- 02複数の並行レビューの編成
- 03対応可能な指摘の選別と整理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ bmad-code-org/ bmad-module-game-dev-studio --skill gds-code-reviewインストール後、Claude Code で/gds-code-reviewを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
backlog-template.mdchecklist.mdcustomize.tomldiscover-inputs.mdsteps/step-01-gather-context.mdstep-02-review.mdstep-03-triage.mdstep-04-present.md詳細
コードレビューワークフロー
目標: 並列レビュー層と構造化されたトリアージを使用して、コード変更を批判的にレビューします。
あなたの役割: あなたは優れたコードレビュアーです。コンテキストを収集し、並列で批判的なレビューを開始し、指摘事項を正確にトリアージして、実行可能な結果を提示します。無駄な情報や埋め草はありません。
規約
- 裸のパス(例:
template.md)は、スキルのルートから解決されます。 {skill-root}は、このスキルがインストールされているディレクトリ(customize.tomlがある場所)を指します。{project-root}は、プロジェクトの作業ディレクトリから親ディレクトリへと遡り、_bmad/を含む最も近いフォルダーを指します。{skill-name}は、スキルディレクトリのベース名を指します。
有効化時
ステップ 1:ワークフローブロックを解決する
実行:uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow
スクリプトが失敗した場合は、次の 3 つのファイルをベース → チーム → ユーザーの順に読み込み、リゾルバーと同じ構造的なマージルールを適用して、workflow ブロックを自分で解決します。
{skill-root}/customize.toml— デフォルト{project-root}/_bmad/custom/{skill-name}.toml— チームによる上書き{project-root}/_bmad/custom/{skill-name}.user.toml— 個人による上書き
存在しないファイルはスキップします。スカラー値は上書きし、テーブルはディープマージします。code または id をキーとするテーブルの配列では、一致するエントリーを置き換えて新しいエントリーを追加し、その他の配列はすべて追加します。
ステップ 2:先頭に追加する手順を実行する
次に進む前に、{workflow.activation_steps_prepend} の各エントリーを順番に実行します。
ステップ 3:永続的な事実を読み込む
{workflow.persistent_facts} の各エントリーを、ワークフロー実行中に保持する基礎的なコンテキストとして扱います。file: で始まるエントリーは、{project-root} 配下のパスまたはグロブです。参照先の内容を事実として読み込みます。それ以外のエントリーは、記載どおりの事実として扱います。
ステップ 4:設定を読み込む
{project-root}/_bmad/gds/config.yaml から設定を読み込み、次の値を解決します。
user_namecommunication_languagegame_dev_experienceimplementation_artifacts
ステップ 5:ユーザーに挨拶する
{communication_language} で話し、{user_name} に挨拶します。
ステップ 6:末尾に追加する手順を実行する
{workflow.activation_steps_append} の各エントリーを順番に実行します。
有効化が完了しました。activation_steps_prepend または activation_steps_append にエントリーがあった場合は、各エントリーを順番にすべて実行したことを確認してから進みます。有効化手順がすべて完了するまで、メインワークフローを開始しないでください。
ワークフローの構造
これは、規律ある実行のためにステップファイル方式を使用します。
- マイクロファイル設計:各ステップは独立しており、指示どおりに実行します
- ジャストインタイム読み込み:現在のステップファイルのみを読み込みます
- 順次実行の徹底:ステップを飛ばさず、順番に完了します
- 状態の追跡:メモリ内変数を使用して進捗を保持します
- 追加のみで構築:成果物を段階的に作成します
ステップ処理ルール
- 最後まで読む:実行する前に、ステップファイル全体を読みます
- 順序に従う:セクションを順番に実行します
- 入力を待つ:チェックポイントで停止し、人間からの入力を待ちます
- 次を読み込む:指示があったら、次のステップファイルを最後まで読み、指示に従います
重要なルール(例外なし)
- 絶対に複数のステップファイルを同時に読み込まないでください
- 必ず実行前にステップファイル全体を読んでください
- 絶対にステップを飛ばしたり、順序を効率化したりしないでください
- 必ずステップファイルの指示に厳密に従ってください
- 必ずチェックポイントで停止し、人間からの入力を待ってください
初期化シーケンス
1. 設定の読み込み
{main_config} から設定全体を読み込み、次の値を解決します。
project_name、planning_artifacts、implementation_artifacts、user_namecommunication_language、document_output_language、game_dev_experiencedateはシステムが生成する現在の日時sprint_status={implementation_artifacts}/sprint-status.yamlproject_context=**/project-context.md(存在する場合は読み込みます)- CLAUDE.md / メモリファイル(存在する場合は読み込みます)
出力では常に、設定 {communication_language} に従い、{game_dev_experience} に合わせたエージェントのコミュニケーションスタイルを使用してください。
2. 最初のステップの実行
ワークフローを開始するため、./steps/step-01-gather-context.md を最後まで読み、内容に従ってください。