GoDD MCP α 公式ドキュメント

初回導入から日常の開発、品質確認、公開まで。やりたいことから選び、コピーできる例で今すぐ始められます。

はじめる

必要なものを用意して、4つの入力を順番に実行します。

ライセンスキーが必要です

GoDD MCP α の利用には有効な GoDD ライセンスキーが必要です。1つの製品ライセンスで通常機能を利用でき、追加の監査キーを発行する必要はありません。

料金プランを確認してアカウントを登録
サブスクリプションを選択
ダッシュボードからライセンスキーを発行

3ステップで開始

Node.js 22以上と、Cursor・Claude Code・Codex・Kimi CLI・Antigravityのいずれかを用意してください。

npm install -g @autodevjapan/godd-mcp-alpha

godd-a install --license-key=YOUR_LICENSE_KEY

godd-a init

/godd-a/dev プロフィール編集機能を追加して

目的から選ぶ

代表的な流れを選ぶと、次に使うコマンドが分かります。

機能を作って公開する

要件を整理して実装し、品質を確認してレビューへ渡します。

1/godd-a/dev
2/godd-a/check
3/godd-a/ship

不具合を安全に直す

影響範囲を調べ、再現テストを作り、回帰がないことを確認します。

1/godd-a/impact
2/godd-a/test
3/godd-a/check

変更を説明して共有する

利用者向け文書とレビュー結果を揃えて Pull Request を作ります。

1/godd-a/docs
2/godd-a/review
3/godd-a/pr

全機能リファレンス

項目を開くと、使う場面、前提、入力例、期待結果、対処方法を確認できます。

開発・品質

/godd-a/dev/godd-a-dev要件確認から実装、テスト、品質確認、文書更新までを段階的に進めます。

できること: 要件確認から実装、テスト、品質確認、文書更新までを段階的に進めます。
使う場面: 機能追加や不具合修正を、計画と検証を伴って進めたいとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: 変更範囲が整理され、実装と必要な検証結果が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「変更範囲が整理され、実装と必要な検証結果が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/dev ログイン失敗時の再試行を追加して

次に使う機能

/godd-a/check /godd-a/ship

/godd-a/check/godd-a-check仕様、テスト、型、lint、セキュリティの品質ゲートを確認します。

できること: 仕様、テスト、型、lint、セキュリティの品質ゲートを確認します。
使う場面: 変更をコミットまたはレビューへ渡す前。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象差分と、プロジェクトで実行できる検証コマンドを確認してください。
期待結果: 実行した検証と PASS、FAIL、INCONCLUSIVE の根拠が示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象差分と、プロジェクトで実行できる検証コマンドを確認してください。「実行した検証と PASS、FAIL、INCONCLUSIVE の根拠が示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/check

次に使う機能

/godd-a/test /godd-a/review

/godd-a/ship/godd-a-ship品質確認からコミット、push、PR 作成までを一続きで進めます。

できること: 品質確認からコミット、push、PR 作成までを一続きで進めます。
使う場面: 検証済みの変更をレビュー可能な状態で公開したいとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。
期待結果: 品質ゲートを通過した変更のブランチと PR 情報が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。「品質ゲートを通過した変更のブランチと PR 情報が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/ship

次に使う機能

/godd-a/pr /godd-a/deploy

/godd-a/review/godd-a-review変更を品質、設計、セキュリティ、運用の観点からレビューします。

できること: 変更を品質、設計、セキュリティ、運用の観点からレビューします。
使う場面: PR を提出する前、または第三者視点の確認が必要なとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象差分と、プロジェクトで実行できる検証コマンドを確認してください。
期待結果: 重要度付きの指摘、根拠、修正候補が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象差分と、プロジェクトで実行できる検証コマンドを確認してください。「重要度付きの指摘、根拠、修正候補が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/review

次に使う機能

/godd-a/check /godd-a/commit

/godd-a/test/godd-a-test変更に必要なテストを作成または実行します。

できること: 変更に必要なテストを作成または実行します。
使う場面: 不具合の再現、機能の受け入れ条件、回帰防止を確認するとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象差分と、プロジェクトで実行できる検証コマンドを確認してください。
期待結果: 実行コマンド、終了状態、失敗時の原因が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象差分と、プロジェクトで実行できる検証コマンドを確認してください。「実行コマンド、終了状態、失敗時の原因が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/test ログイン再試行の回帰テストを追加して

次に使う機能

/godd-a/check /godd-a/e2e

GitHub・リリース

/godd-a/commit/godd-a-commit検証済みの変更を意図が伝わる単位でコミットします。

できること: 検証済みの変更を意図が伝わる単位でコミットします。
使う場面: 1つの変更目的が完了し、必要なテスト証拠が揃ったとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象差分と、プロジェクトで実行できる検証コマンドを確認してください。
期待結果: 対象差分だけが適切なメッセージでコミットされます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象差分と、プロジェクトで実行できる検証コマンドを確認してください。「対象差分だけが適切なメッセージでコミットされます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/commit

次に使う機能

/godd-a/push

/godd-a/push/godd-a-push現在のブランチを設定済みリモートへ送信します。

できること: 現在のブランチを設定済みリモートへ送信します。
使う場面: ローカルのコミットを共有または PR 化するとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。
期待結果: 送信先ブランチと push 結果が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。「送信先ブランチと push 結果が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/push

次に使う機能

/godd-a/pr

/godd-a/pr/godd-a-prリポジトリのテンプレートに沿った Pull Request を作成します。

できること: リポジトリのテンプレートに沿った Pull Request を作成します。
使う場面: 変更をレビュー依頼できる状態にしたとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。
期待結果: 要約、検証結果、関連 Issue を含む PR が作成されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。「要約、検証結果、関連 Issue を含む PR が作成されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/pr

次に使う機能

/godd-a/review /godd-a/deploy

/godd-a/deploy/godd-a-deploy検証とロールバック方針を確認してデプロイを進めます。

できること: 検証とロールバック方針を確認してデプロイを進めます。
使う場面: 承認済みの変更をステージングまたは本番へ反映するとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象環境、デプロイ権限、承認、復旧手順を確認してください。
期待結果: 対象環境、検証結果、復旧手順を含む実行結果が示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象環境、デプロイ権限、承認、復旧手順を確認してください。「対象環境、検証結果、復旧手順を含む実行結果が示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/deploy production

次に使う機能

/godd-a/release

/godd-a/release/godd-a-release変更履歴から SemVer に沿ったリリースノートを作成します。

できること: 変更履歴から SemVer に沿ったリリースノートを作成します。
使う場面: 新しいバージョンを利用者へ案内するとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。
期待結果: 利用者向け変更点、注意事項、更新手順が整理されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。「利用者向け変更点、注意事項、更新手順が整理されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/release 1.4.0

次に使う機能

/godd-a/deploy

/godd-a/github/godd-a-githubリポジトリ設定やブランチ保護の確認・設定を支援します。

できること: リポジトリ設定やブランチ保護の確認・設定を支援します。
使う場面: 新規リポジトリの準備やレビュー規則を整えるとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。
期待結果: 必要な設定差分と適用結果が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。 Git remote、GitHub 認証、対象ブランチへの権限を確認してください。「必要な設定差分と適用結果が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/github main のブランチ保護を設定して

次に使う機能

/godd-a/pr /godd-a/ship

ドキュメント・設計

/godd-a/docs/godd-a-docsコード変更に合わせて利用者向け文書を作成または更新します。

できること: コード変更に合わせて利用者向け文書を作成または更新します。
使う場面: セットアップ、操作、設定など利用者に見える挙動が変わったとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象読者、更新対象の文書、出力先を確認してください。
期待結果: 対象文書が更新され、実装との整合性が確認されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象読者、更新対象の文書、出力先を確認してください。「対象文書が更新され、実装との整合性が確認されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/docs セットアップ手順を現在のCLIに合わせて更新して

次に使う機能

/godd-a/dev /godd-a/slide

/godd-a/adr/godd-a-adr重要な技術判断を Architecture Decision Record として残します。

できること: 重要な技術判断を Architecture Decision Record として残します。
使う場面: 複数案から長期的な設計方針を選ぶとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。判断対象、制約、比較したい選択肢を確認してください。
期待結果: 背景、選択肢、判断、影響を含む ADR が作成されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。判断対象、制約、比較したい選択肢を確認してください。「背景、選択肢、判断、影響を含む ADR が作成されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/adr 監査ログに PostgreSQL を採用する

次に使う機能

/godd-a/diagram /godd-a/docs

/godd-a/map/godd-a-mapアーキテクチャと依存関係を Mermaid の知識グラフにします。

できること: アーキテクチャと依存関係を Mermaid の知識グラフにします。
使う場面: 初めて触るコードベースを理解するときや大きな変更の前。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: 主要コンポーネントと依存方向を示す図が更新されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「主要コンポーネントと依存方向を示す図が更新されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/map

次に使う機能

/godd-a/impact /godd-a/diagram

/godd-a/diagram/godd-a-diagramコード変更に合わせて Mermaid の構成図を更新します。

できること: コード変更に合わせて Mermaid の構成図を更新します。
使う場面: 依存関係、状態遷移、複数コンポーネントの連携が変わったとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象読者、更新対象の文書、出力先を確認してください。
期待結果: コードと整合する図と変更内容が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象読者、更新対象の文書、出力先を確認してください。「コードと整合する図と変更内容が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/diagram

次に使う機能

/godd-a/map /godd-a/docs

/godd-a/slide/godd-a-slideプロジェクト文書から Marp 形式の説明スライドを作成します。

できること: プロジェクト文書から Marp 形式の説明スライドを作成します。
使う場面: 設計や進捗をレビュー、説明、共有するとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象読者、更新対象の文書、出力先を確認してください。
期待結果: 発表可能なスライド本文と確認事項が作成されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象読者、更新対象の文書、出力先を確認してください。「発表可能なスライド本文と確認事項が作成されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/slide docs/product-overview.md

次に使う機能

/godd-a/docs

/godd-a/design/godd-a-designコードベースを基に画面デザインを作成または更新します。

できること: コードベースを基に画面デザインを作成または更新します。
使う場面: UI 実装前の合意形成や既存画面との同期が必要なとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。起動できる検証環境、テスト用アカウント、期待する画面遷移を確認してください。
期待結果: 対象画面のデザインと実装上の注意点が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。起動できる検証環境、テスト用アカウント、期待する画面遷移を確認してください。「対象画面のデザインと実装上の注意点が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/design ダッシュボード

次に使う機能

/godd-a/e2e /godd-a/dev

/godd-a/retro/godd-a-retro指定期間の実装内容を振り返りレポートとして書き出します。

できること: 指定期間の実装内容を振り返りレポートとして書き出します。
使う場面: スプリントの締めや引き継ぎで、期間内の作業を一覧にしたいとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。振り返りたい期間と、必要であれば git author の絞り込みを確認してください。
期待結果: .godd/retro/ 配下の gitignore 済み Markdown に期間内の実装履歴が出力されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。振り返りたい期間と、必要であれば git author の絞り込みを確認してください。「.godd/retro/ 配下の gitignore 済み Markdown に期間内の実装履歴が出力されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/retro since:1w

次に使う機能

/godd-a/learn /godd-a/docs

プロジェクト・運用

/godd-a/runテキストで指定した GoDD コマンドを実行します。

できること: テキストで指定した GoDD コマンドを実行します。
使う場面: ネイティブのスラッシュコマンドが使えないクライアントから呼び出すとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: 指定した公開コマンドが選択され、その手順が開始されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「指定した公開コマンドが選択され、その手順が開始されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/run /godd-a/check

次に使う機能

/godd-a/dev

/godd-a/setup/godd-a-setupプロジェクトの技術構成を確認し、開発環境の準備を案内します。

できること: プロジェクトの技術構成を確認し、開発環境の準備を案内します。
使う場面: 新しいリポジトリへ参加した直後や、推奨構成で始めるとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: 不足情報が確認され、再現可能なセットアップ手順が作られます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「不足情報が確認され、再現可能なセットアップ手順が作られます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/setup TypeScript と React のプロジェクトを準備して

次に使う機能

/godd-a/config /godd-a/dev

/godd-a/impact/godd-a-impact変更候補の参照先と影響範囲を横断的に調べます。

できること: 変更候補の参照先と影響範囲を横断的に調べます。
使う場面: 共有関数、型、設定を変更する前。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: 影響する利用箇所、テスト、文書と未確認事項が整理されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「影響する利用箇所、テスト、文書と未確認事項が整理されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/impact src/auth/session.ts

次に使う機能

/godd-a/dev /godd-a/map

/godd-a/config/godd-a-config技術構成を検出して config.godd を生成または修復します。

できること: 技術構成を検出して config.godd を生成または修復します。
使う場面: 初期化後の設定不足や不整合を直したいとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: 検証済みのプロジェクト設定と確認事項が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「検証済みのプロジェクト設定と確認事項が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/config

次に使う機能

/godd-a/setup /godd-a/dev

/godd-a/questions/godd-a-questions未確定事項の一覧を対話形式で解消します。

できること: 未確定事項の一覧を対話形式で解消します。
使う場面: 実装前に要件や選択肢の回答をまとめたいとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: 回答済み項目と残っている確認事項が区別されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「回答済み項目と残っている確認事項が区別されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/questions

次に使う機能

/godd-a/dev

/godd-a/e2e/godd-a-e2eブラウザで重要な利用者フローを操作して検証します。

できること: ブラウザで重要な利用者フローを操作して検証します。
使う場面: 画面遷移や複数画面にまたがる操作を確認するとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。起動できる検証環境、テスト用アカウント、期待する画面遷移を確認してください。
期待結果: 操作手順、期待結果との差、再現証拠が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。起動できる検証環境、テスト用アカウント、期待する画面遷移を確認してください。「操作手順、期待結果との差、再現証拠が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/e2e 購入完了までのフローを確認して

次に使う機能

/godd-a/test /godd-a/check

/godd-a/learn/godd-a-learnプロジェクト固有の規約、パターン、注意点を保存・参照します。

できること: プロジェクト固有の規約、パターン、注意点を保存・参照します。
使う場面: 繰り返し使う判断や失敗回避策を次回へ残したいとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: 再利用できる短い学習項目として記録されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「再利用できる短い学習項目として記録されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/learn API の命名規約を保存して

次に使う機能

/godd-a/dev /godd-a/scratchpad

/godd-a/scratchpad/godd-a-scratchpad会話をまたいで使う作業メモを保存、検索、呼び出しします。

できること: 会話をまたいで使う作業メモを保存、検索、呼び出しします。
使う場面: 一時的だが次のセッションでも必要な前提を残すとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。対象ファイル、依頼する変更、完了条件を確認してください。
期待結果: メモの保存結果または一致する検索結果が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。対象ファイル、依頼する変更、完了条件を確認してください。「メモの保存結果または一致する検索結果が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/scratchpad save "決済フローはステージングで確認済み"

次に使う機能

/godd-a/learn /godd-a/dev

/godd-a/metrics/godd-a-metricsトークン効率と、利用可能な品質・予算・学習指標を報告します。

できること: トークン効率と、利用可能な品質・予算・学習指標を報告します。
使う場面: 運用改善の判断材料を、測定根拠付きで確認するとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。比較対象、測定条件、利用できる検証結果を確認してください。
期待結果: 検証できた指標だけが標本情報とともに表示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。比較対象、測定条件、利用できる検証結果を確認してください。「検証できた指標だけが標本情報とともに表示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/metrics

次に使う機能

/godd-a/check /godd-a/plan

/godd-a/plan/godd-a-plan承認済み計画を中断・再開可能な単位で順番に実行します。

できること: 承認済み計画を中断・再開可能な単位で順番に実行します。
使う場面: 複数タスクを期限と状態を保ちながら安全に進めるとき。
前提条件: GoDD MCP α をインストールし、対象リポジトリで godd-a init を完了してから実行します。判断対象、制約、比較したい選択肢を確認してください。
期待結果: 次に実行すべき1タスクと計画状態が提示されます。
うまくいかないとき: コマンドが認識されない場合は godd-a version で導入状態を確認し、MCP クライアントを再起動してから再実行します。判断対象、制約、比較したい選択肢を確認してください。「次に実行すべき1タスクと計画状態が提示されます。」にならない場合は、対象と権限を明示して再実行してください。

入力例

/godd-a/plan start docs/approved-plan.md

次に使う機能

/godd-a/dev /godd-a/check

クライアントでの呼び出しと管理

普段の依頼はチャットから、導入や更新確認はターミナルから行います。

チャットから依頼する

基本は /godd-a/<機能> の後に依頼内容を続けます。直接呼び出せない場合は run を使えます。

/godd-a/dev プロフィール編集機能を追加して

/godd-a/run /godd-a/check

公開 CLI リファレンス

godd-a install [--license-key=KEY] [--client=<id|all>]対応クライアントを検出して GoDD MCP α を登録します。

できること: 対応クライアントを検出して GoDD MCP α を登録します。
使う場面: 初回導入、クライアント追加、接続設定の修復時。
前提条件: Node.js 22 以上、ライセンスキー、対象クライアントが必要です。
期待結果: 登録したクライアント名と設定結果が表示されます。
うまくいかないとき: クライアントが検出されない場合は、そのクライアントを一度起動して設定ディレクトリを作成し、対応一覧にあるクライアント名を指定して再実行します。

入力例

godd-a install --license-key=YOUR_LICENSE_KEY

次に使う機能

godd-a init [--force] [--lang=LANG] [--auto]godd-a version

godd-a init [--force] [--lang=LANG] [--auto]対象プロジェクトへ config.godd と必要な案内ファイルを生成します。

できること: 対象プロジェクトへ config.godd と必要な案内ファイルを生成します。
使う場面: リポジトリで GoDD を初めて使うとき、または設定を再生成するとき。
前提条件: godd-a install 完了後、対象リポジトリのルートで実行します。
期待結果: 検出した技術構成と生成・更新したファイルが表示されます。
うまくいかないとき: 生成先が想定と違う場合は、リポジトリのルートへ移動し、config.godd のドキュメントディレクトリ設定を確認してから再実行します。

入力例

godd-a init --lang=ja

次に使う機能

godd-a install [--license-key=KEY] [--client=<id|all>]godd-a skills [candidates|promote <name>|demote <name>]

godd-a uninstall [--client=<id|all>]指定クライアントから GoDD の登録と管理対象コマンドを削除します。

できること: 指定クライアントから GoDD の登録と管理対象コマンドを削除します。
使う場面: クライアントを使わなくなったとき、または登録をやり直すとき。
前提条件: 削除対象のクライアント ID を確認します。
期待結果: GoDD が管理する設定だけの削除結果が表示されます。
うまくいかないとき: 対象が見つからない場合はクライアント ID の綴りを確認します。削除後も表示される場合はクライアントを再起動して設定を読み直します。

入力例

godd-a uninstall --client=cursor

次に使う機能

godd-a install [--license-key=KEY] [--client=<id|all>]godd-a version

godd-a serveMCP stdio サーバーを起動します。

できること: MCP stdio サーバーを起動します。
使う場面: 通常はクライアントが自動実行し、接続診断時だけ手動確認します。
前提条件: godd-a install でクライアント登録を完了しておきます。
期待結果: サーバーが標準入出力でクライアントからの接続を待機します。
うまくいかないとき: 接続直後に終了する場合は MCP クライアント側の起動コマンドと環境変数を確認し、同じ端末で直接起動して stderr の診断を確認します。

入力例

godd-a serve

次に使う機能

godd-a install [--license-key=KEY] [--client=<id|all>]godd-a version

godd-a compatibilityクライアント別の圧縮機能互換性を表示します。

できること: クライアント別の圧縮機能互換性を表示します。
使う場面: クライアント選定や圧縮機能の導入判断をするとき。
前提条件: GoDD MCP α を導入済みにします。
期待結果: OS、shell、利用方法、利用できない場合の対処が表示されます。
うまくいかないとき: 利用中のクライアントが表にない場合は圧縮機能を有効にせず、表示された OS と shell が実環境に一致するか確認します。

入力例

godd-a compatibility

次に使う機能

godd-a install [--license-key=KEY] [--client=<id|all>]godd-a version

godd-a codec-capability verify --npm-version <version> --manifest <path> --artifact <path> --runner <path>配布 codec の manifest、artifact、runner、既知結果を検証します。

できること: 配布 codec の manifest、artifact、runner、既知結果を検証します。
使う場面: リリース担当者が配布物の整合性を確認するとき。
前提条件: 検証対象4ファイルと npm バージョンを用意します。
期待結果: 成功結果、または安全な失敗理由が返ります。
うまくいかないとき: 検証に失敗した場合は manifest が参照する artifact・runner・既知結果を同じ配布物から揃え、ファイルの欠落や改変がない状態で再実行します。

入力例

godd-a codec-capability verify --npm-version 2.0.1 --manifest manifest.json --artifact codec.bin --runner codec-runner

次に使う機能

godd-a version godd-a compatibility

godd-a impact evidence cobol --root <path> [--source-format fixed|free|variable]COBOL の COPY、CALL、EXEC 関係を上限付きで抽出します。

できること: COBOL の COPY、CALL、EXEC 関係を上限付きで抽出します。
使う場面: COBOL 変更の影響分析に決定的な証拠を追加するとき。
前提条件: 対象リポジトリ内の COBOL root と必要なら source format を確認します。
期待結果: 確定 edge と unresolved / inconclusive を分けた JSON が返ります。
うまくいかないとき: root や COPYBOOK を読めない場合はリポジトリ内の相対パスを指定し、source format を確認します。未解決の CALL や COPY は調査項目として扱います。

入力例

godd-a impact evidence cobol --root src/cobol --source-format fixed

次に使う機能

godd-a init [--force] [--lang=LANG] [--auto]godd-a version

godd-a dataset coverage --ledger <path>標準入力のサンプル結果を検証し、進捗ファイルへ保存します。

できること: 標準入力のサンプル結果を検証し、進捗ファイルへ保存します。
使う場面: データセット処理の完了範囲と未処理範囲を追跡するとき。
前提条件: 保存先の親ディレクトリと、下記形式の JSON ファイルを用意します。
期待結果: 検証済みサンプルだけが進捗へ反映され、結果 JSON が返ります。
うまくいかないとき: 入力が拒否された場合は直前の出力にある generation と digest を次の JSON へ反映し、未発行 sample や期限切れ attempt を送っていないか確認します。

入力例

godd-a dataset coverage --ledger .godd/dataset-coverage.json

入力JSON（ファイルとして保存）

{
  "action": "initialize",
  "generation": { "source_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "split": "eval", "epoch": 1 },
  "assigned_sample_ids": ["private-video"],
  "expected_sample_ids": ["private-video"],
  "retry_policy": {
    "max_attempts": { "DecodeError": 1, "AnnotationMissing": 1, "FrameExtraction": 1, "SourceUnavailable": 1, "ResourceExhausted": 1, "AttemptTimeout": 1 },
    "backoff": { "max_backoff_ms": 0 },
    "attempt_timeout_ms": 600000,
    "run_wall_time_budget_ms": 3600000,
    "infrastructure_failure_storm_threshold": 2
  },
  "thresholds": { "min_coverage_ratio": 1.0, "max_class_failure_ratio": 0.1, "max_split_accepted_ratio_variance": 0.0, "max_replacement_ratio": 0.0 },
  "declared_threshold_digest": "343eb2b12236e6984358603780f16fd03c23a07ccd199f04d6a404ebbd350142",
  "declared_expected_sample_id_digest": "1b442df4911573935107a07e6cda5dafccc5832c09d7a8d38b6475be6ef47fc3",
  "replacement_policy": "forbidden"
}

PowerShell

Get-Content -Raw dataset-action.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

Bash / zsh

cat dataset-action.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

操作別の使い方

initialize

できること: initialize は「1件を対象に進捗記録が開始されます」を目的に使います。
前提条件: 必要: 表示されたJSONと作成済みの.goddディレクトリ。
期待結果: 結果: 1件を対象に進捗記録が開始されます。
うまくいかないとき: 失敗時: 全項目をそのままコピーし、未使用の保存先を指定してください。

{
  "action": "initialize",
  "generation": { "source_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "split": "eval", "epoch": 1 },
  "assigned_sample_ids": ["private-video"],
  "expected_sample_ids": ["private-video"],
  "retry_policy": {
    "max_attempts": { "DecodeError": 1, "AnnotationMissing": 1, "FrameExtraction": 1, "SourceUnavailable": 1, "ResourceExhausted": 1, "AttemptTimeout": 1 },
    "backoff": { "max_backoff_ms": 0 },
    "attempt_timeout_ms": 600000,
    "run_wall_time_budget_ms": 3600000,
    "infrastructure_failure_storm_threshold": 2
  },
  "thresholds": { "min_coverage_ratio": 1.0, "max_class_failure_ratio": 0.1, "max_split_accepted_ratio_variance": 0.0, "max_replacement_ratio": 0.0 },
  "declared_threshold_digest": "343eb2b12236e6984358603780f16fd03c23a07ccd199f04d6a404ebbd350142",
  "declared_expected_sample_id_digest": "1b442df4911573935107a07e6cda5dafccc5832c09d7a8d38b6475be6ef47fc3",
  "replacement_policy": "forbidden"
}

PowerShell

Get-Content -Raw dataset-initialize.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

Bash / zsh

cat dataset-initialize.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

issue

できること: issue は「試行番号1と期限が返ります」を目的に使います。
前提条件: 必要: initialize済みの保存先とdataset-issue.json。
期待結果: 結果: 試行番号1と期限が返ります。
うまくいかないとき: 失敗時: 先にinitializeし、同じsample idを指定してください。

{"action":"issue","canonical_sample_id":"private-video","requested_position":0}

PowerShell

Get-Content -Raw dataset-issue.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

Bash / zsh

cat dataset-issue.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

report

できること: report は「対象サンプルの成功が記録されます」を目的に使います。
前提条件: 必要: issueが返した試行番号とdataset-report.json。
期待結果: 結果: 対象サンプルの成功が記録されます。
うまくいかないとき: 失敗時: 期限内にissueが返した試行番号を指定してください。

{"action":"report","canonical_sample_id":"private-video","attempt":1,"outcome":"Accepted"}

PowerShell

Get-Content -Raw dataset-report.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

Bash / zsh

cat dataset-report.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

sweep

できること: sweep は「期限切れ試行の件数が返り、再試行可能になります」を目的に使います。
前提条件: 必要: initialize済みの保存先。
期待結果: 結果: 期限切れ試行の件数が返り、再試行可能になります。
うまくいかないとき: 失敗時: 保存先とJSONの綴りを確認してください。

{"action":"sweep"}

PowerShell

'{"action":"sweep"}' | godd-a dataset coverage --ledger .godd/dataset-coverage.json

Bash / zsh

printf '%s' '{"action":"sweep"}' | godd-a dataset coverage --ledger .godd/dataset-coverage.json

finalize

できること: finalize は「最終的な達成結果が返ります」を目的に使います。
前提条件: 必要: 全対象のreport完了とdataset-finalize.json。
期待結果: 結果: 最終的な達成結果が返ります。
うまくいかないとき: 失敗時: initializeと完全に同じしきい値とdigestを使ってください。

{"action":"finalize","thresholds":{"min_coverage_ratio":1.0,"max_class_failure_ratio":0.1,"max_split_accepted_ratio_variance":0.0,"max_replacement_ratio":0.0},"replacement_policy":"forbidden","declared_threshold_digest":"343eb2b12236e6984358603780f16fd03c23a07ccd199f04d6a404ebbd350142","declared_expected_sample_id_digest":"1b442df4911573935107a07e6cda5dafccc5832c09d7a8d38b6475be6ef47fc3"}

PowerShell

Get-Content -Raw dataset-finalize.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

Bash / zsh

cat dataset-finalize.json | godd-a dataset coverage --ledger .godd/dataset-coverage.json

次に使う機能

godd-a init [--force] [--lang=LANG] [--auto]godd-a operate [--session=<id>] [--timeout-ms=<ms>] -- <program> [args...]

godd-a gateway doctor [--no-probe]接続先の設定と疎通状態を診断します。

できること: 接続先の設定と疎通状態を診断します。
使う場面: 接続先を有効化するとき、または接続できない原因を調べるとき。
前提条件: 必要に応じて GODD_PROVIDER_GATEWAY_URL を設定します。
期待結果: 秘密情報を含まない設定・疎通診断が表示されます。
うまくいかないとき: 接続不可の場合は GODD_PROVIDER_GATEWAY_URL が HTTPS の正しい接続先か確認し、接続先の稼働とネットワーク到達性を確認します。

入力例

godd-a gateway doctor

次に使う機能

godd-a version godd-a compatibility

godd-a plan audit <record|verify> [...]計画の中断、再開、逸脱を記録または検証します。

できること: 計画の中断、再開、逸脱を記録または検証します。
使う場面: 承認済み計画を中断・再開したとき、または計画から逸脱したとき。
前提条件: 進行中の approved plan と GODD_LICENSE_KEY が必要です。
期待結果: 記録の検証結果または安全な失敗理由が返ります。
うまくいかないとき: 検証できない場合は同じ run ID とライセンスを使用しているか確認します。ライセンス更新後の作業は新しい run ID で開始します。

入力例

godd-a plan audit verify

操作別の使い方

record

できること: record は「中断理由が記録されます」を目的に使います。
前提条件: 必要: 進行中の承認済み計画とライセンスキー。
期待結果: 結果: 中断理由が記録されます。
うまくいかないとき: 失敗時: 計画が進行中で、--event が interrupted、resumed、plan-deviation のいずれかか確認してください。

godd-a plan audit record --event interrupted --reason-code user_pause --expected-step test --actual-step test

verify

できること: verify は「保存した記録の整合性が確認されます」を目的に使います。
前提条件: 必要: 記録時と同じプロジェクトとライセンス。
期待結果: 結果: 保存した記録の整合性が確認されます。
うまくいかないとき: 失敗時: 進行中の計画とライセンスが記録時から変わっていないか確認してください。

godd-a plan audit verify

次に使う機能

godd-a init [--force] [--lang=LANG] [--auto]godd-a version

godd-a research <start|checkpoint|status|complete|abort> [options]中断可能な調査の最小チェックポイントを保存・確認します。

できること: 中断可能な調査の最小チェックポイントを保存・確認します。
使う場面: 長い調査を複数セッションに分けるとき。
前提条件: 対象プロジェクトで保存可能な要約と公開 HTTPS source を用意します。
期待結果: 本文や秘密を保存せず、調査状態が JSON で返ります。
うまくいかないとき: session が見つからない場合は正確な session ID を status へ渡します。保存拒否時は要約から秘密情報を除き、source を公開 HTTPS URL に直します。

入力例

godd-a research start --session research-1 --topic "API retry policy"

操作別の使い方

start

できること: start は「新しい調査セッションが作成されます」を目的に使います。
前提条件: 必要: 未使用のセッション名と機密を含まない調査テーマ。
期待結果: 結果: 新しい調査セッションが作成されます。
うまくいかないとき: 失敗時: すでに進行中でないセッション名へ変更してください。

godd-a research start --session research-1 --topic "API retry policy"

checkpoint

できること: checkpoint は「途中経過が保存されます」を目的に使います。
前提条件: 必要: 進行中のセッション、短い要約、必要なら公開HTTPS URL。
期待結果: 結果: 途中経過が保存されます。
うまくいかないとき: 失敗時: 機密文を除き、queryのない公開HTTPS URLを使ってください。

godd-a research checkpoint --session research-1 --summary "Retry rules confirmed" --source https://example.com/retry

status

できること: status は「現在の要約と状態が表示されます」を目的に使います。
前提条件: 必要: 作成済みのセッション名。
期待結果: 結果: 現在の要約と状態が表示されます。
うまくいかないとき: 失敗時: start が返したセッション名を確認してください。

godd-a research status --session research-1

complete

できること: complete は「セッションが完了になります」を目的に使います。
前提条件: 必要: 調査を終えた進行中のセッション。
期待結果: 結果: セッションが完了になります。
うまくいかないとき: 失敗時: 先に最終要約をcheckpointで保存してください。

godd-a research complete --session research-1

abort

できること: abort は「セッションが中止になります」を目的に使います。
前提条件: 必要: 進行中のセッションと機密を含まない理由コード。
期待結果: 結果: セッションが中止になります。
うまくいかないとき: 失敗時: --session と --reason の両方を指定してください。

godd-a research abort --session research-1 --reason superseded

次に使う機能

godd-a init [--force] [--lang=LANG] [--auto]godd-a operate [--session=<id>] [--timeout-ms=<ms>] -- <program> [args...]

godd-a operate [--session=<id>] [--timeout-ms=<ms>] -- <program> [args...]利用者が指定したプログラムを状態管理・期限付きで実行します。

できること: 利用者が指定したプログラムを状態管理・期限付きで実行します。
使う場面: JSON/NDJSON を返す外部エージェント操作を機械的に実行するとき。
前提条件: 対象 program と JSON/NDJSON 出力契約を確認します。
期待結果: turn、終了状態、exit code だけを含む JSON が返ります。
うまくいかないとき: 子プログラムが失敗する場合は、それ単体で改行終端 JSON/NDJSON を stdout に返すことを確認し、必要なら timeout を実行時間より長くします。

入力例

godd-a operate --timeout-ms=30000 -- node worker.mjs

次に使う機能

godd-a init [--force] [--lang=LANG] [--auto]godd-a research <start|checkpoint|status|complete|abort> [options]

できること: 分割作業の作成、予約、結果報告、期限切れ、放棄、状態確認を行います。
使う場面: 大きな処理を重複なく分割し、worker ごとの進捗を管理するとき。
前提条件: 既存 shard plan の state directory を確認します。plan 作成時は source root と N/M selector も必要です。
期待結果: shard と lease の現在状態が機械可読な JSON で返ります。
うまくいかないとき: lease や report が拒否された場合は最新の status を取得し、そこにある generation、revision、担当 shard と同じ値で入力を作り直します。

入力例

godd-a shard partition status --state-dir .godd/shard-state

操作別の使い方

plan

できること: plan は「2分割の作業が作成されます」を目的に使います。
前提条件: 必要: 既存の入力ディレクトリと未使用の保存先。
期待結果: 結果: 2分割の作業が作成されます。
うまくいかないとき: 失敗時: --selector が N/M 形式で、入力がプロジェクト内にあるか確認してください。

godd-a shard partition plan --state-dir .godd/shards --source-root data --selector 1/2

lease

できること: lease は「1番目の部分が60秒予約され、report用に保存されます」を目的に使います。
前提条件: 必要: 作成済みの分割作業と未予約の担当部分。
期待結果: 結果: 1番目の部分が60秒予約され、report用に保存されます。
うまくいかないとき: 失敗時: statusで確認し、期限切れを待つか明示的に引き継いでください。

godd-a shard partition lease --state-dir .godd/shards --selector 1/2 --ttl-ms 60000

PowerShell

godd-a shard partition lease --state-dir .godd/shards --selector 1/2 --ttl-ms 60000 | Set-Content -Encoding utf8NoBOM shard-lease.json

Bash / zsh

godd-a shard partition lease --state-dir .godd/shards --selector 1/2 --ttl-ms 60000 > shard-lease.json

report

できること: report は「完了した項目が記録されます」を目的に使います。
前提条件: 必要: leaseの出力を保存したshard-lease.json。
期待結果: 結果: 完了した項目が記録されます。
うまくいかないとき: 失敗時: 最新のlease出力をshard-lease.jsonへ保存し、期限内に再実行してください。

{"plan_generation":{"source_generation":"<plan output>","expected_set_digest":"<plan output>"},"sequence_id":"<lease assigned_ids[0]>","reporting_shard_index":1,"lease_generation":1,"expected_state":"assigned","expected_ledger_revision":0,"outcome":"completed"}

PowerShell

node -e "const l=require('./shard-lease.json');process.stdout.write(JSON.stringify({plan_generation:l.plan_generation,sequence_id:l.assigned_ids[0],reporting_shard_index:l.shard_index,lease_generation:l.lease_generation,expected_state:'assigned',expected_ledger_revision:l.ledger_revision,outcome:'completed'}))" | godd-a shard partition report --state-dir .godd/shards

Bash / zsh

node -e "const l=require('./shard-lease.json');process.stdout.write(JSON.stringify({plan_generation:l.plan_generation,sequence_id:l.assigned_ids[0],reporting_shard_index:l.shard_index,lease_generation:l.lease_generation,expected_state:'assigned',expected_ledger_revision:l.ledger_revision,outcome:'completed'}))" | godd-a shard partition report --state-dir .godd/shards

expire

できること: expire は「期限切れの予約が解放されます」を目的に使います。
前提条件: 必要: 作成済みの分割作業。
期待結果: 結果: 期限切れの予約が解放されます。
うまくいかないとき: 失敗時: 保存先を確認し、予約期限後に再実行してください。

godd-a shard partition expire --state-dir .godd/shards

abandon

できること: abandon は「予約が再割り当て可能になります」を目的に使います。
前提条件: 必要: 選択した担当部分が所有する予約。
期待結果: 結果: 予約が再割り当て可能になります。
うまくいかないとき: 失敗時: 予約取得時と同じselectorを使ってください。

godd-a shard partition abandon --state-dir .godd/shards --selector 1/2

status

できること: status は「現在の進捗と残り項目が表示されます」を目的に使います。
前提条件: 必要: 作成済みの分割作業。
期待結果: 結果: 現在の進捗と残り項目が表示されます。
うまくいかないとき: 失敗時: 先にplanを作るか、保存先を修正してください。

godd-a shard partition status --state-dir .godd/shards

次に使う機能

godd-a operate [--session=<id>] [--timeout-ms=<ms>] -- <program> [args...]godd-a version

godd-a realtime <admission|admission-dev> --evaluated-at-ms <u64>リアルタイム処理を開始してよいかを、指定時刻の情報で判定します。

できること: リアルタイム処理を開始してよいかを、指定時刻の情報で判定します。
使う場面: 本番または開発環境で realtime worker を起動する直前。
前提条件: 下記形式のイベント JSON を標準入力へ渡し、実行時点の Unix epoch ミリ秒を指定します。
期待結果: 開始可能かどうかと、拒否された場合の理由が返ります。
うまくいかないとき: 開始が拒否された場合は返された理由を確認し、requested_at と evaluated-at-ms を同じ現在時刻から作り、期限と evidence generation を更新します。

入力例

godd-a realtime admission --evaluated-at-ms ([DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds())

PowerShell

$nowMs = [DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds(); node -e "const n=Number(process.argv[1]);const h='a'.repeat(64);const requested=new Date(Math.floor(n/1000)*1000).toISOString().replace('.000Z','Z');process.stdout.write(JSON.stringify({schema_version:1,principal_fingerprint:'principal:sha256:'+h,resource_id:'resource:sha256:'+h,resource_generation:7,action:'player:join',evidence:[{kind:'membership',generation:7,outcome:'present',evidence_fingerprint:'evidence:sha256:'+h}],policy_generation:3,requested_at:requested,deadline_ms:60000}))" $nowMs | godd-a realtime admission --evaluated-at-ms $nowMs

Bash / zsh

now_ms="$(node -p Date.now())"; node -e "const n=Number(process.argv[1]);const h='a'.repeat(64);const requested=new Date(Math.floor(n/1000)*1000).toISOString().replace('.000Z','Z');process.stdout.write(JSON.stringify({schema_version:1,principal_fingerprint:'principal:sha256:'+h,resource_id:'resource:sha256:'+h,resource_generation:7,action:'player:join',evidence:[{kind:'membership',generation:7,outcome:'present',evidence_fingerprint:'evidence:sha256:'+h}],policy_generation:3,requested_at:requested,deadline_ms:60000}))" "$now_ms" | godd-a realtime admission --evaluated-at-ms "$now_ms"

操作別の使い方

admission

できること: admission は「開始可否または明確な拒否理由が返ります」を目的に使います。
前提条件: 必要: 同じ現在時刻から生成したイベントJSONと評価時刻。
期待結果: 結果: 開始可否または明確な拒否理由が返ります。
うまくいかないとき: 失敗時: requested_atと評価時刻を同じ値から生成し、各fingerprintを確認してください。

godd-a realtime admission --evaluated-at-ms $nowMs

PowerShell

$nowMs = [DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds(); node -e "const n=Number(process.argv[1]);const h='a'.repeat(64);const requested=new Date(Math.floor(n/1000)*1000).toISOString().replace('.000Z','Z');process.stdout.write(JSON.stringify({schema_version:1,principal_fingerprint:'principal:sha256:'+h,resource_id:'resource:sha256:'+h,resource_generation:7,action:'player:join',evidence:[{kind:'membership',generation:7,outcome:'present',evidence_fingerprint:'evidence:sha256:'+h}],policy_generation:3,requested_at:requested,deadline_ms:60000}))" $nowMs | godd-a realtime admission --evaluated-at-ms $nowMs

Bash / zsh

now_ms="$(node -p Date.now())"; node -e "const n=Number(process.argv[1]);const h='a'.repeat(64);const requested=new Date(Math.floor(n/1000)*1000).toISOString().replace('.000Z','Z');process.stdout.write(JSON.stringify({schema_version:1,principal_fingerprint:'principal:sha256:'+h,resource_id:'resource:sha256:'+h,resource_generation:7,action:'player:join',evidence:[{kind:'membership',generation:7,outcome:'present',evidence_fingerprint:'evidence:sha256:'+h}],policy_generation:3,requested_at:requested,deadline_ms:60000}))" "$now_ms" | godd-a realtime admission --evaluated-at-ms "$now_ms"

admission-dev

できること: admission-dev は「開発用の実行でも同じ判定が返ります」を目的に使います。
前提条件: 必要: 開発環境で同じ現在時刻から生成したイベントJSONと評価時刻。
期待結果: 結果: 開発用の実行でも同じ判定が返ります。
うまくいかないとき: 失敗時: 開発workerを始める前に生成したイベントを修正してください。

godd-a realtime admission-dev --evaluated-at-ms $nowMs

PowerShell

$nowMs = [DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds(); node -e "const n=Number(process.argv[1]);const h='a'.repeat(64);const requested=new Date(Math.floor(n/1000)*1000).toISOString().replace('.000Z','Z');process.stdout.write(JSON.stringify({schema_version:1,principal_fingerprint:'principal:sha256:'+h,resource_id:'resource:sha256:'+h,resource_generation:7,action:'player:join',evidence:[{kind:'membership',generation:7,outcome:'present',evidence_fingerprint:'evidence:sha256:'+h}],policy_generation:3,requested_at:requested,deadline_ms:60000}))" $nowMs | godd-a realtime admission-dev --evaluated-at-ms $nowMs

Bash / zsh

now_ms="$(node -p Date.now())"; node -e "const n=Number(process.argv[1]);const h='a'.repeat(64);const requested=new Date(Math.floor(n/1000)*1000).toISOString().replace('.000Z','Z');process.stdout.write(JSON.stringify({schema_version:1,principal_fingerprint:'principal:sha256:'+h,resource_id:'resource:sha256:'+h,resource_generation:7,action:'player:join',evidence:[{kind:'membership',generation:7,outcome:'present',evidence_fingerprint:'evidence:sha256:'+h}],policy_generation:3,requested_at:requested,deadline_ms:60000}))" "$now_ms" | godd-a realtime admission-dev --evaluated-at-ms "$now_ms"

次に使う機能

godd-a operate [--session=<id>] [--timeout-ms=<ms>] -- <program> [args...]godd-a version

godd-a version導入済みバージョンを表示し、更新の有無を確認します。

できること: 導入済みバージョンを表示し、更新の有無を確認します。
使う場面: 不具合調査、更新前、サポートへ環境を伝える前。
前提条件: GoDD MCP α がグローバルに導入済みである必要があります。
期待結果: 現在版と、取得できた場合は利用可能な最新版が表示されます。
うまくいかないとき: 最新版を取得できない場合はネットワークやプロキシ設定を確認します。現在版だけ表示された場合も、その値は環境情報として利用できます。

入力例

godd-a version

次に使う機能

godd-a install [--license-key=KEY] [--client=<id|all>]godd-a compatibility

godd-a skills [candidates|promote <name>|demote <name>]再利用候補を確認し、プロジェクト知識を skill に昇格または降格します。

できること: 再利用候補を確認し、プロジェクト知識を skill に昇格または降格します。
使う場面: 繰り返し使う知識を管理するとき。
前提条件: 対象プロジェクトで godd-a init を完了しておきます。
期待結果: 候補一覧または promote/demote の結果が表示されます。
うまくいかないとき: 候補や対象 skill が見つからない場合はプロジェクトのルートで実行し、candidates で正確な名前を確認してから promote または demote をやり直します。

入力例

godd-a skills candidates

操作別の使い方

candidates

できること: candidates は「利用範囲を広げられる候補と理由が表示されます」を目的に使います。
前提条件: 必要: 個人用skillを含むプロジェクト。
期待結果: 結果: 利用範囲を広げられる候補と理由が表示されます。
うまくいかないとき: 失敗時: プロジェクトルートから実行してください。

godd-a skills candidates

promote

できること: promote は「skillをプロジェクト全体で使えるようになります」を目的に使います。
前提条件: 必要: candidatesで利用可能と表示されたskill名。
期待結果: 結果: skillをプロジェクト全体で使えるようになります。
うまくいかないとき: 失敗時: BLOCKEDの理由をすべて解消してください。

godd-a skills promote api-review

demote

できること: demote は「skillが個人用の範囲へ戻ります」を目的に使います。
前提条件: 必要: 個人用へ戻せるプロジェクトskill。
期待結果: 結果: skillが個人用の範囲へ戻ります。
うまくいかないとき: 失敗時: 正確なskill名と現在の利用範囲を確認してください。

godd-a skills demote api-review

次に使う機能

godd-a init [--force] [--lang=LANG] [--auto]godd-a version

困ったとき

まず導入状態とクライアントの再起動を確認してください。

コマンドが見つからない

godd-a version で導入状態を確認し、godd-a install を再実行してから MCP クライアントを再起動します。

godd-a version

追加監査キーは不要

通常は現在のライセンスキーだけで plan audit を利用できます。追加キーの発行・登録は不要です。

ライセンスとサポート

利用プラン、ライセンス発行、利用可能なサポート内容は料金ページで確認できます。