新規Variant昇格実習例
co-retailプロトタイプをベースに、2つの経路を並べて比較する実習ガイド | ← 参考ドキュメントに戻る
templates/co-work/からプロジェクトをスキャフォールディングし、同時にProjects/co-retail/にPhase Aプロトタイプを作成した。ここでは2つのディレクトリを並べて配置し、正式テンプレートには存在するがプロトタイプには存在しないファイルが正確にどれかを確認する。練習用ワークスペース(ai-workspace-standards-demo)内で継続していることを前提とする。
-
2つのディレクトリの内容を並べて比較する
公式variantであるco-workと、まだプロトタイプ段階のco-retailのトップレベルのファイル一覧を比較する。
diff <(ls templates/co-work/) <(ls Projects/co-retail/)
-
公式テンプレートにのみ存在する項目を確認する
通常、
variant.json、README.md/README_ko.md、docs/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プロトタイプ段階ではこのファイルが存在しない、あるいは最小限の内容しかないのは正常であり、この差異自体が「まだ昇格されていない」という信号となる。
PROMOTION_CHECKLIST.mdに記入する際、何が不足しているかをすぐに把握できる。
PROMOTION_CHECKLIST.mdの条件を満たし、variant.json内のskill_manifest/script_manifestを記入する必要がある。
-
PROMOTION_CHECKLIST.mdの項目を確認する
チェックリストには一般に「必須検証スクリプトが通過すること」「プラットフォームパリティが確保されていること」「エージェントのフロントマターが完了していること」などの項目が含まれる。co-retailの場合、第6章§2で作成した
researcher.mdとwriter.mdにすべての必須フィールドが揃っているかを再確認するところから始める。2つのスクリプトは異なる内容をチェックするため、それぞれ別々に実行し結果を個別に確認する。① エージェントフロントマター完全性チェック — name、tier、handoffなどの必須フィールドがすべて入力されていることを確認する。
bun run agent:verify
② スキルマニフェストチェック — variantが参照するスキルが実際に存在し、3つのプラットフォーム(.claude/.gemini/.agents)に均等にデプロイされていることを確認する。
bun scripts/validate-skills.ts
-
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テンプレートに基づいて記入しなければならない — ここでの例は全体的な流れを示すものであり、項目の完全なリストではない。
l3-to-variant-pipeline.tsを実行してco-retailを公式のtemplates/co-retail/に変換する。ここから先は実際のgit履歴に痕跡を残す、取り返しのつかない操作である。
-
昇格パイプラインを実行する
--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"
-
プラットフォームパリティを手動で確認する
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/)
-
最終ゲート — validate-templates.ts
すべてのステップが完了した後、構造検証をもう一度実行し、新しいvariantがワークスペース全体のルールを満たしていることを確認する。
bun scripts/validate-templates.ts
Projects/co-retail/から削除することで重複を除去する。ただし、スキルディレクトリは意図的にこのreconcileステップから除外されているため、昇格後に.claude/skills/と.gemini/skills/にスキルが引き続き残っていることを別途確認する必要がある。
_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
ai-workspace-standardsのmainブランチに基づく | 2026年7月14日執筆
← ハンドブックホームに戻る