第12章

新規Variant昇格実習例

co-retailプロトタイプをベースに、2つの経路を並べて比較する実習ガイド  |  ← 参考ドキュメントに戻る

対象リポジトリai-workspace-standards、mainブランチ
本ファイルの目的第11章の昇格(Phase B)の概念を、第6章§2で作成したco-retailプロトタイプに適用する実習
参考ドキュメント11_VariantAdvanced_Chapter_ja.html — 各シナリオからリンク
執筆日2026年7月14日
● 初級 入門 昇格済みの正式テンプレートが、まだ昇格されていないプロトタイプと構造的にどう違うかを実際に確認する
G-1 初級 テンプレート構造とプロトタイプ構造の比較
第6章§2で、templates/co-work/からプロジェクトをスキャフォールディングし、同時にProjects/co-retail/にPhase Aプロトタイプを作成した。ここでは2つのディレクトリを並べて配置し、正式テンプレートには存在するがプロトタイプには存在しないファイルが正確にどれかを確認する。練習用ワークスペース(ai-workspace-standards-demo)内で継続していることを前提とする。
使用要素
variant.json README_ko.md docs/adr/
公式テンプレート vs Phase A プロトタイプ構造比較 templates/co-retail/ (公式テンプレート) 検証完了 variant.json バージョン・マニフェストメタデータ README.md / README_ko.md 完全なドキュメント docs/adr/ アーキテクチャ決定記録 .claude/ / .gemini/ プラットフォームパリティ確保 agents/*.md エージェントフロントマター完備 skills/ スキルマニフェスト登録完了 タグ: v1.0.0 vs Projects/co-retail/ (Phase A) 進行中 variant.json 未整備または最小構成 README.md / README_ko.md ドラフトまたは未作成 docs/adr/ ディレクトリなし .claude/ / .gemini/ スキャフォールド時に生成 agents/*.md フィールド欠落の可能性 skills/ マニフェスト未登録 タグ: なし (昇格待ち)
ステップバイステップ
  1. 2つのディレクトリの内容を並べて比較する

    公式variantであるco-workと、まだプロトタイプ段階のco-retailのトップレベルのファイル一覧を比較する。

    diff <(ls templates/co-work/) <(ls Projects/co-retail/)
  2. 公式テンプレートにのみ存在する項目を確認する

    通常、variant.jsonREADME.md/README_ko.mddocs/adr/は公式テンプレートには存在するが、Phase Aプロトタイプ段階ではまだ欠落しているか空のままである。まず、公式テンプレート(co-work)側にこれらのファイルが実際に存在することを確認する。

    ls templates/co-work/variant.json templates/co-work/README_ko.md templates/co-work/docs/adr/

    次に、co-retailプロトタイプのフォルダ一覧を確認し、上記ファイルがまだ存在しないことを確認する。

    ls Projects/co-retail/
variant.jsonには、variantを公式のスキャフォールディングターゲットとして登録するために必要なメタデータ(version、skill_manifest、script_manifest)が含まれている。Phase Aプロトタイプ段階ではこのファイルが存在しない、あるいは最小限の内容しかないのは正常であり、この差異自体が「まだ昇格されていない」という信号となる。
事前にこの比較を行っておくことで、次のシナリオD-1でPROMOTION_CHECKLIST.mdに記入する際、何が不足しているかをすぐに把握できる。
● 中級 日常ワークフロー co-retailを昇格対象にするために必要なチェックリストとマニフェストを記入する
D-1 中級 昇格チェックリストの記入
G-1で特定されたギャップを実際に埋めようとする実践者の状況である。co-retailプロトタイプを公式昇格の対象にするには、PROMOTION_CHECKLIST.mdの条件を満たし、variant.json内のskill_manifest/script_manifestを記入する必要がある。
使用要素
PROMOTION_CHECKLIST.md skill_manifest script_manifest
ステップバイステップ
  1. PROMOTION_CHECKLIST.mdの項目を確認する

    チェックリストには一般に「必須検証スクリプトが通過すること」「プラットフォームパリティが確保されていること」「エージェントのフロントマターが完了していること」などの項目が含まれる。co-retailの場合、第6章§2で作成したresearcher.mdwriter.mdにすべての必須フィールドが揃っているかを再確認するところから始める。2つのスクリプトは異なる内容をチェックするため、それぞれ別々に実行し結果を個別に確認する。

    ① エージェントフロントマター完全性チェック — name、tier、handoffなどの必須フィールドがすべて入力されていることを確認する。

    bun run agent:verify

    ② スキルマニフェストチェック — variantが参照するスキルが実際に存在し、3つのプラットフォーム(.claude/.gemini/.agents)に均等にデプロイされていることを確認する。

    bun scripts/validate-skills.ts
  2. variant.jsonにマニフェストを定義する

    co-retailが使用するスキル(例:campaign-research、copywriting)をskill_manifest.variant_specificに登録し、variant固有のスクリプトがあればscript_manifestに登録する。

    {
      "name": "co-retail",
      "inherits_common": "1.0.0",
      "skill_manifest": {
        "variant_specific": ["campaign-research", "copywriting"]
      },
      "script_manifest": []
    }
skill_manifest.variant_specificは、このvariantが共通セット以外に必要とするスキルを宣言する場所である。ここに登録されていないスキルは、昇格パイプラインのreconcileステップで削除されるリスクがある。
チェックリストの項目は、リポジトリ内の実際のPROMOTION_CHECKLIST.mdテンプレートに基づいて記入しなければならない — ここでの例は全体的な流れを示すものであり、項目の完全なリストではない。
● 上級 上級ユーザー 実際の昇格パイプラインコマンドと、昇格後の検証手順
P-1 上級 昇格パイプラインの実行と検証
D-1を完了し、プロトタイプが昇格の準備ができていると判断した経験豊富な実践者が、実際にl3-to-variant-pipeline.tsを実行してco-retailを公式のtemplates/co-retail/に変換する。ここから先は実際のgit履歴に痕跡を残す、取り返しのつかない操作である。
Phase A プロトタイプ agent:verify validate-templates.ts 昇格チェックリスト作成 l3-to-variant-pipeline.ts templates/ co-retail/ (公式)
このシナリオは、実際のgit管理ワークスペースに実質的な変更を加える操作である。variantを本当に公開する意思がある場合にのみ実行すること。フローを観察したいだけであれば、コマンドを実行せずに読むだけで十分である。
ステップバイステップ
  1. 昇格パイプラインを実行する

    --l3-pathはPhase Aプロトタイプのパス、--nameは最終的なvariant名、--typeはドメインタイプ、--descriptionはvariantの説明である。--descriptionと、オプションフラグの--version(デフォルト0.1.0)、--status(デフォルトbeta)は、昇格結果のtemplates/co-retail/variant.jsonに直接書き込まれる。

    bun scripts/l3-to-variant-pipeline.ts --l3-path=Projects/co-retail --name=co-retail --type=collaboration --description="Retail domain agent team"
  2. プラットフォームパリティを手動で確認する

    diffを使用して、.claude/.gemini/.agents/のcommands/skillsディレクトリ一覧が対応していることを確認する(Claude/Gemini/Antigravityの3プラットフォームパリティ)。

    diff <(ls templates/co-retail/.claude/commands/) <(ls templates/co-retail/.gemini/commands/)
    diff <(ls templates/co-retail/.gemini/commands/) <(ls templates/co-retail/.agents/commands/)
    diff <(ls templates/co-retail/.claude/skills/) <(ls templates/co-retail/.gemini/skills/)
    diff <(ls templates/co-retail/.gemini/skills/) <(ls templates/co-retail/.agents/skills/)
  3. 最終ゲート — validate-templates.ts

    すべてのステップが完了した後、構造検証をもう一度実行し、新しいvariantがワークスペース全体のルールを満たしていることを確認する。

    bun scripts/validate-templates.ts
パイプラインのreconcileステップは、共通ファイル(L0/common)と同一のファイルをProjects/co-retail/から削除することで重複を除去する。ただし、スキルディレクトリは意図的にこのreconcileステップから除外されているため、昇格後に.claude/skills/.gemini/skills/にスキルが引き続き残っていることを別途確認する必要がある。
プロトタイプファイル 共通ファイルとの 比較 同一 → extends 参照に変換 欠落 → コピー ドメイン固有 → _ORIGIN.md へ移管
_ORIGIN.mdに「Manual Phase B Steps」セクションがある場合、パイプラインが自動的に移動できなかったドメイン固有のディレクトリがリストされている — そのリストのすべての項目を手動で移動したか、最終確認する。例えば、co-retailの_ORIGIN.mdは以下のようになることがある。
## Manual Phase B Steps
- [ ] Copy the brand-assets/ directory to templates/co-retail/brand-assets/
- [ ] Carry over the campaign brief skeleton files under campaign-templates/ as-is
- [ ] Reset the initial channel list in channel-configs.json to an empty array
これらの項目は、reconcileが処理する「共通ファイルの重複除去」とは異なる種類の作業である — variant固有のアセットであるため、パイプラインは自動処理しない。各チェックボックスを確認し、自分で移動する必要がある。
昇格パイプライン完了状態 Phase A プロトタイプ reconcile チェックリスト 合格 templates/ に マージ new-project.ts で スキャフォールド可能 完了 Phase A 変換 検証 マージ デプロイ準備完了

ai-workspace-standardsのmainブランチに基づく | 2026年7月14日執筆
← ハンドブックホームに戻る