mcpField
G
gds-code-review

gds-code-review

github.com/bmad-code-orgテスト・品質26245 回インストール5 週間前に更新
リポジトリ

gds-code-review について

gds-code-reviewは、ゲーム開発のコード変更を審査するためのスキルです。並行する敵対的レビューと構造化されたトリアージで、実行可能な指摘をまとめます。

主な機能

  1. 01並行する敵対的レビュー
  2. 02指摘の構造化トリアージ
  3. 03ワークフローのカスタマイズ
  4. 04永続的なプロジェクト情報の読み込み
  5. 05段階的な実行

活用シーン

  1. 01ゲームコード変更のレビュー
  2. 02複数の並行レビューの編成
  3. 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.md
checklist.md
customize.toml
discover-inputs.md
steps/
step-01-gather-context.md
step-02-review.md
step-03-triage.md
step-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 ブロックを自分で解決します。

  1. {skill-root}/customize.toml — デフォルト
  2. {project-root}/_bmad/custom/{skill-name}.toml — チームによる上書き
  3. {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_name
  • communication_language
  • game_dev_experience
  • implementation_artifacts
ステップ 5:ユーザーに挨拶する

{communication_language} で話し、{user_name} に挨拶します。

ステップ 6:末尾に追加する手順を実行する

{workflow.activation_steps_append} の各エントリーを順番に実行します。

有効化が完了しました。activation_steps_prepend または activation_steps_append にエントリーがあった場合は、各エントリーを順番にすべて実行したことを確認してから進みます。有効化手順がすべて完了するまで、メインワークフローを開始しないでください。

ワークフローの構造

これは、規律ある実行のためにステップファイル方式を使用します。

  • マイクロファイル設計:各ステップは独立しており、指示どおりに実行します
  • ジャストインタイム読み込み:現在のステップファイルのみを読み込みます
  • 順次実行の徹底:ステップを飛ばさず、順番に完了します
  • 状態の追跡:メモリ内変数を使用して進捗を保持します
  • 追加のみで構築:成果物を段階的に作成します
ステップ処理ルール
  1. 最後まで読む:実行する前に、ステップファイル全体を読みます
  2. 順序に従う:セクションを順番に実行します
  3. 入力を待つ:チェックポイントで停止し、人間からの入力を待ちます
  4. 次を読み込む:指示があったら、次のステップファイルを最後まで読み、指示に従います
重要なルール(例外なし)
  • 絶対に複数のステップファイルを同時に読み込まないでください
  • 必ず実行前にステップファイル全体を読んでください
  • 絶対にステップを飛ばしたり、順序を効率化したりしないでください
  • 必ずステップファイルの指示に厳密に従ってください
  • 必ずチェックポイントで停止し、人間からの入力を待ってください

初期化シーケンス

1. 設定の読み込み

{main_config} から設定全体を読み込み、次の値を解決します。

  • project_name、planning_artifacts、implementation_artifacts、user_name
  • communication_language、document_output_language、game_dev_experience
  • date はシステムが生成する現在の日時
  • sprint_status = {implementation_artifacts}/sprint-status.yaml
  • project_context = **/project-context.md(存在する場合は読み込みます)
  • CLAUDE.md / メモリファイル(存在する場合は読み込みます)

出力では常に、設定 {communication_language} に従い、{game_dev_experience} に合わせたエージェントのコミュニケーションスタイルを使用してください。

2. 最初のステップの実行

ワークフローを開始するため、./steps/step-01-gather-context.md を最後まで読み、内容に従ってください。

コメント