12장

신규 variant 승격 실습 예시

co-retail 프로토타입을 기준으로 두 경로를 손으로 비교해보는 실습 가이드  |  ← 레퍼런스 문서로 돌아가기

대상 저장소ai-workspace-standards, main 브랜치
이 파일의 목적11장에서 설명한 승격(Phase B) 개념을 6장 §2에서 만든 co-retail 프로토타입에 적용해보는 실습
레퍼런스 문서11_VariantAdvanced_Chapter.html — 각 시나리오에서 링크로 연결됩니다
작성일2026년 7월 14일
● 초급 Getting Started 정식 템플릿과 아직 승격되지 않은 프로토타입이 구조적으로 무엇이 다른지 직접 눈으로 비교
G-1 초급 템플릿 구조 vs 프로토타입 구조 비교
6장 §2에서 templates/co-work/로 프로젝트를 스캐폴딩했고, Projects/co-retail/에 Phase A 프로토타입도 만들었다. 두 디렉터리를 나란히 놓고 어떤 파일이 정식 템플릿에는 있는데 프로토타입에는 없는지 직접 확인해보려 한다. 연습용 워크스페이스(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. 두 디렉터리 목록 나란히 비교

    정식 variant인 co-work과 아직 프로토타입 단계인 co-retail의 최상위 파일 목록을 비교한다.

    diff <(ls templates/co-work/) <(ls Projects/co-retail/)
  2. 정식 템플릿에만 있는 항목 확인

    보통 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)가 스캐폴딩 대상으로 등록되기 위한 메타데이터(버전, skill_manifest, script_manifest)를 담는다. Phase A 프로토타입 단계에서는 아직 이 파일이 없거나 최소한으로만 존재하는 게 정상이다 — 이 차이 자체가 "아직 승격되지 않았다"는 신호다.
이 비교를 미리 해두면, 다음 D-1 시나리오에서 PROMOTION_CHECKLIST.md를 채울 때 무엇이 빠져 있는지 바로 알 수 있다.
● 중급 Daily Workflow co-retail을 승격 가능한 상태로 만들기 위해 체크리스트와 매니페스트를 채워보기
D-1 중급 승격 체크리스트 채워보기
G-1에서 확인한 빈틈들을 실제로 메워보려는 실무자의 상황이다. co-retail 프로토타입을 정식 승격 대상으로 만들려면 PROMOTION_CHECKLIST.md의 조건들과 variant.jsonskill_manifest/script_manifest를 채워야 한다.
사용 요소
PROMOTION_CHECKLIST.md skill_manifest script_manifest
단계별 실행
  1. PROMOTION_CHECKLIST.md 항목 점검

    체크리스트에는 대체로 "필수 검증 스크립트 통과", "플랫폼 패리티 확보", "에이전트 frontmatter 완결성" 같은 항목이 들어간다. co-retail의 경우 6장 §2에서 만든 researcher.md, writer.md가 필수 필드를 모두 갖췄는지부터 다시 확인한다. 두 스크립트는 서로 다른 것을 검사하므로 각각 실행하고 결과를 따로 확인한다.

    ① 에이전트 frontmatter 완결성 검사 — name, tier, handoff 등 필수 필드가 빠짐없이 채워졌는지 확인한다.

    bun run agent:verify

    ② 스킬 매니페스트 검사 — 베리언트(variant)가 참조하는 스킬이 실제로 존재하고 네 플랫폼(.claude/.gemini/.agents/.codex)에 고르게 배포돼 있는지 확인한다.

    bun scripts/validate-skills.ts
  2. variant.json에 manifest 정의

    co-retail이 사용하는 스킬(예: campaign-research, copywriting)과 변형 전용 스크립트가 있다면 skill_manifest.variant_specificscript_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 템플릿을 기준으로 채워야 한다 — 여기 예시는 일반적인 흐름을 보여주는 것이지 항목의 전체 목록이 아니다.
● 고급 Power User 실제 승격 파이프라인 명령과 사후 검증 절차
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)를 공개(publish)할 의도가 있을 때만 실행하고, 단순히 흐름을 구경하려는 목적이라면 명령을 직접 실행하지 말고 읽기만 하라.
단계별 실행
  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. 플랫폼 패리티 수동 확인

    .claude/.gemini/, 그리고 .agents/·.codex/의 commands·skills·prompts 디렉터리 목록이 서로 대응하는지 diff로 확인한다(Claude/Gemini/Antigravity/Codex 네 플랫폼 패리티).

    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/)
    diff <(ls templates/co-retail/.agents/skills/) <(ls templates/co-retail/.codex/skills/)
  3. 최종 게이트 — validate-templates.ts

    모든 절차가 끝난 뒤 마지막으로 구조 검증을 한 번 더 돌려, 신규 베리언트(variant)가 워크스페이스 전체 규정을 만족하는지 확인한다.

    bun scripts/validate-templates.ts
파이프라인의 reconcile 단계는 Projects/co-retail/에 있던 파일 중 공통 파일(L0/common)과 동일한 것은 제거해 중복을 없앤다. 다만 스킬 디렉터리는 이 reconcile 대상에서 의도적으로 제외되므로, 승격 후 .claude/skills/.gemini/skills/에 스킬이 그대로 남아 있는지 별도로 확인해야 한다.
프로토타입 파일 공통 파일과 비교 동일 → extends 참조 변환 누락 → 복사 도메인 전용 → _ORIGIN.md 이관
_ORIGIN.md의 "Manual Phase B Steps" 절이 있다면, 파이프라인이 자동으로 옮기지 못한 도메인 전용 디렉터리 목록이 거기 적혀 있다 — 이 목록을 빠짐없이 수동으로 옮겼는지 마지막으로 대조한다. 예를 들어 co-retail의 _ORIGIN.md라면 아래처럼 적혀 있을 수 있다.
## Manual Phase B Steps
- [ ] brand-assets/ 디렉터리를 templates/co-retail/brand-assets/로 복사
- [ ] campaign-templates/ 아래 캠페인 브리프 골격 파일을 그대로 이관
- [ ] channel-configs.json의 채널 목록 초기값을 빈 배열로 초기화
이런 항목은 reconcile이 다루는 "공통 파일 중복 제거"와는 성격이 다른, variant 고유의 자산이므로 파이프라인이 알아서 처리해주지 않는다 — 체크박스를 하나씩 직접 확인하며 옮겨야 한다.
승격 파이프라인 완료 상태 Phase A 프로토타입 reconcile 체크리스트 통과 templates/ 에 병합 new-project.ts로 스캐폴딩 가능 완료 Phase A 변환 검증 병합 배포 준비 완료

ai-workspace-standards main 브랜치 기준 | 2026년 7월 14일 작성
← 핸드북 홈으로