mcpField
A
adopt

adopt

github.com/donchitosエージェントワークフロー28.5k459 回インストール1 週間前に更新
リポジトリ

adopt について

adoptは、既存プロジェクトをテンプレートのワークフローに移行するチーム向けのClaudeスキルです。成果物の形式とインフラをスキルパイプラインに照らして監査し、優先順位付きの移行計画を作成します。

主な機能

  1. 01GDD、ADR、ストーリー形式の監査
  2. 02インフラ成果物の不足確認
  3. 03全体監査と対象別監査
  4. 04移行課題の優先順位付け
  5. 05確認可能な導入計画の作成

活用シーン

  1. 01テンプレート導入前の既存プロジェクト評価
  2. 02GDD、ADR、ストーリーの形式問題の特定
  3. 03プロジェクトインフラ移行の計画

インストール

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

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

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

同梱ファイル

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

references/
1-detect.md
2-format-audit.md
3-classify.md
4-migration-plan.md
5-summary.md
6-write.md
7-first-action.md

詳細

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

上記で解決済みです。そのまま使用してください。/adopt は、移行状態を報告および書き込む際に、project.yaml と従来の設定ファイルも直接確認します。この生の確認は意図的なものであり、上記の解決済みの値とは別に行われます。

Adopt — ブラウンフィールドテンプレートの採用

このスキルでは、既存のプロジェクトの成果物が、テンプレートのスキルパイプラインの形式に準拠しているかを監査し、優先順位を付けた移行計画を作成します。

これは /project-stage-detect ではありません。 /project-stage-detect が答えるのは、「何が存在するか」です。 /adopt が答えるのは、「存在するものは、テンプレートのスキルで実際に機能するか」です。

プロジェクトに GDD、ADR、ストーリーがあっても、成果物の内部形式が適切でなければ、形式に依存するすべてのスキルが気付かれないまま失敗したり、誤った結果を生成したりする可能性があります。

出力： docs/adoption-plan-[date].md — 永続的に保存され、確認可能な移行計画です。

引数モード：

監査モード： $ARGUMENTS（空欄の場合は full）

  • 引数なし / full：すべての成果物タイプを完全に監査します
  • gdds：GDD の形式準拠のみを監査します
  • adrs：ADR の形式準拠のみを監査します
  • stories：ストーリーの形式準拠のみを監査します
  • infra：インフラストラクチャ成果物の不足のみを監査します（レジストリ、マニフェスト、スプリントステータス、stage.txt）

自動化モード：modes.automation を解決します（project.local.yaml → project.yaml → デフォルトの collaborative）。すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います（collaborative は常に質問 · guided は重要な場合のみ質問 · autonomous はログを記録して続行； automation_always_ask カテゴリーでは常に質問します）。

workflow（.claude/docs/workflow-modes.md に準拠）。これは Phase 2 の監査範囲と Phase 3 の重大度を定めます。full はすべてのドキュメントタイプを完全な構造で監査します。standard は 必須のドキュメント／セクションのみを監査します（任意のセクションは不足ではなく、参考情報として扱います）。 minimal は design/game-brief.md の形式チェックです。GDD／ADR／UX は想定されません。Phase 2 を参照してください。

Phase 1：プロジェクト状態の検出

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

Phase 2：形式の監査

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

Phase 3：不足項目の分類と優先順位付け

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

Phase 4：移行計画の作成

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

Phase 5：概要の提示と書き込みの確認

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

Phase 6：採用計画の書き込み

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

Phase 7：最初のアクションの提案

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

協調プロトコル

collaborative モード（デフォルト）に適用されます。 guided モードと autonomous モードについては、.claude/docs/automation-modes.md を参照してください。以下の ルールは、協調モードで求められる動作を説明するものであり、すべてのモードに共通するものではありません。

  1. 黙って読み進める — 何かを提示する前に、監査を最後まで完了します
  2. 最初に概要を示す — 書き込みを依頼する前に、ユーザーが対象範囲を確認できるようにします
  3. 書き込む前に確認する — 導入計画ファイルを作成する前に、必ず確認を求めます
  4. 提案するが、強制しない — 計画は助言であり、何をいつ修正するかはユーザーが決めます
  5. 一度に一つの操作を行う — 計画を引き渡した後は、同時に実行する項目を6つ並べるのではなく、次の具体的なステップを一つ提示します
  6. 既存の成果物を再生成しない — 既存の内容に不足している部分だけを補い、 すでに内容のある GDD、ADR、ストーリーを書き直さないでください

コメント

Markdown 対応