zugzbot 1.0.21 → 1.0.23

package/.opencode/oh-my-design/.claude/skills/omd-locale-adapter/SKILL.md

@@ -1,124 +0,0 @@
----
-name: omd:locale-adapter
-description: "한국어 본문을 EN/JP/ZH-TW로 **번역이 아닌 adaptation**. 문화 레퍼런스 swap, JP honorific 정합, ZH-TW 번체 idiom. KR은 항상 source of truth. '다국어 적용', 'EN 버전 만들어줘', 'JP로 옮겨줘' 류 트리거."
-user-invocable: true
----
-
-# omd:locale-adapter
-
-KR 본문을 받아 EN/JP/ZH-TW로 **adapt**한다. 직역이 아니라 각 문화의 디자인 블로그 voice로 다시 쓴다.
-
-참조: Frontitude brand-voice translation model, LINE localization playbook.
-
-## 0. Source of truth
-
-**KR이 canonical**. EN/JP/ZH-TW는 derivative. KR이 갱신되면 다른 locale도 무효화.
-
-## 1. 대상 locale별 룰
-
-### 1.1 EN (en)
-
-- Voice baseline: Stripe Press / Linear changelog / Vercel blog
-- 문장 길이: 15~25 words (KR 35~50자 ≈ EN 15~25 words)
-- 1인칭: "we" or "I" 자연스럽게
-- 문화 swap:
-  - "토스" → "Toss (Korea's leading fintech)" (첫 출현만)
-  - "당근" → "Karrot (a hyperlocal Korean marketplace)"
-  - 김치/돌잔치 등 강한 KR-only ref → 영미권 equivalent or 짧은 gloss
-  - "안녕하세요" 인사 → "Hi, I'm [name]." 또는 informal opener
-- 분량: KR 자수의 0.45~0.55 (영어가 짧음)
-- 헤더: KR 짧은 헤더 → EN은 좀 더 descriptive OK ("토스 느낌의 시작" → "What gives Toss its 'feel'")
-
-### 1.2 JP (ja)
-
-- Voice baseline: note.com デザイン カテゴリ, クックパッド開発者ブログ
-- 종결: です・ます 일관 (敬体)
-- 격식 register: 영미보다 한 단계 더 정중
-- 문화 swap:
-  - "토스" → "Toss (韓国最大級のフィンテック)"
-  - 한국 특유의 이웃문화 ref → 일본식 「ご近所」 비유
-  - 존경어/겸양어 자연스럽게 ("저는 ~한다고 생각해요" → "私は〜と考えています")
-- 분량: KR 자수의 0.85~1.0
-- 헤더: 한국어 짧은 헤더와 비슷한 호흡 ("토스 느낌の始まり")
-- 한자: 常用漢字 위주. 어려운 한자는 仮名 병기.
-
-### 1.3 ZH-TW (zh-tw)
-
-- Voice baseline: 數位時代, INSIDE 硬塞網
-- **번체** (簡体 금지). 「設計」「顯示」「優化」.
-- 문화 swap:
-  - "토스" → "Toss (南韓金融科技龍頭)"
-  - "당근" → "Karrot (南韓地區型二手交易平台)"
-  - 한국 idiom → 中華圈 idiom (가능한 경우)
-- 분량: KR 자수의 0.6~0.75
-- 인용부호: 「」 사용
-- 헤더: KR 짧은 헤더와 비슷한 호흡 (「Toss 給人的感覺，從何而來」)
-
-## 2. Adaptation 7단계 절차
-
-1. KR canonical 본문 + 출간된 frontmatter 읽기
-2. 글 전체 thesis 한 줄로 추출 (locale 다 동일해야 함)
-3. 각 H2 섹션을 1개씩 옮김 — **문장 단위 직역 금지**, 단락 단위 의역
-4. 문화 ref 발견 시 위 swap 룰 적용 + 첫 출현에 gloss
-5. 인용/코드/URL/figure src는 그대로 보존
-6. 헤더 number 일관성 유지 (KR=5 H2면 다른 locale도 5)
-7. frontmatter `title_<locale>`, `subtitle_<locale>` 채우기
-
-## 3. 보존 (절대 변경 금지)
-
-- 코드 블록 내부 (변수명, 함수명, 주석 영문 유지)
-- URL, 파일 경로
-- 사람 이름 / 회사명 (단, 첫 출현에 gloss는 OK)
-- figure src
-- frontmatter slug
-- 수치 / 통계
-
-## 4. 비전형 케이스
-
-| 원문 | 대응 |
-|---|---|
-| KR 특유의 이모지 사용 패턴 (`ㅎㅎ`, `^^`) | EN/JP/ZH-TW에서 제거. 톤은 다른 방식으로 표현. |
-| 한자어 농담 | locale 등가 농담 없으면 그냥 의미만 유지하고 농담 톤 표시 |
-| `안녕하세요` 같은 의례 인사 | EN은 informal greeting, JP는 「こんにちは」, ZH-TW는 「大家好」 |
-| Toss/당근 같은 회사명 인지도 차이 | 첫 등장에서 1줄 gloss, 이후 그대로 |
-
-## 5. 출력 형식
-
-```
-content/posts/<slug>/index.ko.md    ← source
-content/posts/<slug>/index.en.md    ← this skill 생성
-content/posts/<slug>/index.ja.md
-content/posts/<slug>/index.zh-tw.md
-```
-
-각 파일 frontmatter에:
-```yaml
-locale: en
-source_locale: ko
-source_revision: <git sha of ko at time of adaptation>
-adapted_at: <ISO date>
-```
-
-## 6. 품질 체크 (self-audit)
-
-각 locale 생성 후 writer가 직접 검증:
-- H2 카운트가 KR과 일치
-- 인용 / 통계 누락 0건
-- figure src 경로 일치
-- 분량이 위 1.x의 비율 범위
-- 첫 출현 회사명 모두 gloss 처리됨
-- 코드 블록 변경 0건
-
-미달 시 동일 locale 재작성 (orchestrator round 카운터 증가).
-
-## 7. KR 갱신 시 staleness
-
-KR이 수정되면 EN/JP/ZH-TW의 `source_revision`이 outdated. orchestrator가 다시 호출. 부분 갱신 가능 (수정된 H2 섹션만 re-adapt).
-
-## 8. Anti-patterns
-
-- ❌ Google Translate 톤 — 직역 흔적
-- ❌ KR-only ref를 그대로 둠 (예: "강남에서 일하는데" → 영어판에 그대로)
-- ❌ 분량 mismatch (EN이 KR과 같은 자수)
-- ❌ 헤더 number 불일치
-- ❌ KR 없이 EN을 먼저 작성 (KR=canonical 원칙 위배)

package/.opencode/oh-my-design/.claude/skills/omd-migrate/SKILL.md

@@ -1,307 +0,0 @@
----
-name: omd:migrate
-description: "단일 brand의 references/<id>/DESIGN.md를 Apple-tier 깊이로 풀 마이그레이션. 9 quality gate 전부 통과 — §4 canonical schema + ≥2 surface live inspect + Tier 2 cross-check + .verification.md conflict matrix + 검증된 §10-15 philosophy + footer + tests + visual smoke. 'X 마이그레이션', 'X apple 깊이로', 'X 풀 검증', 'omd:migrate stripe' 류에 트리거."
-argument-hint: "<brand-id> [--skip-gate G3,G5] [--surfaces home,checkout,docs]"
-user-invocable: true
----
-
-# omd:migrate — Single-brand Apple-tier deep migration
-
-`spec/migration-checklist.md`의 9 quality gate를 한 brand에 대해 모두 충족시킨다. **현재 67 brand 중 1개(apple)만 통과 상태.** 이 스킬은 나머지 66개를 하나씩 끌어올리는 도구.
-
-다음 패턴 트리거:
-- `omd:migrate stripe`
-- `stripe 마이그레이션`
-- `stripe apple 깊이로 풀 검증`
-- `stripe 풀 마이그레이션`
-
-자연어 OK. 슬래시 없어도 됨.
-
----
-
-## Pre-flight (자동)
-
-브랜드 인자 받고:
-
-1. `web/references/<id>/DESIGN.md` 존재 확인 (없으면 에러: "use omd:add-reference for new ref")
-2. 현재 9 gate 상태 평가:
-   ```
-   G1 schema:   [✓/✗] (grep variant blocks per category)
-   G2 ≥4 cats:  [✓/✗] (count category headers)
-   G3 surfaces: [count] live inspect already done
-   G4 Tier 2:   [✓/✗] refero/getdesign attempt logged
-   G5 verif.md: [✓/✗] file exists
-   G6 philo:    [count verified vs illustrative]
-   G7 footer:   [✓/✗] **Verified:** present
-   G8 tests:    last npm test result
-   G9 smoke:    not auto-checkable; ask user to verify after
-   ```
-3. 사용자에게 현재 상태 + 작업할 gate 보고. `--skip-gate` flag로 일부 스킵 가능.
-
----
-
-## Phase G1+G2 — §4 canonical schema audit
-
-목표: `**Variant Name**` + bullet `Field: value` 형식으로 모든 컴포넌트 카테고리 정리.
-
-1. `grep -c '^### \|^\*\*[A-Z]' web/references/<id>/DESIGN.md` 으로 §4 구조 파싱
-2. 각 카테고리(Buttons / Inputs / Cards / Badges / Tabs / Toggles / Toasts / Dialogs / Avatars / Lists / Navigation)에 대해:
-   - 카테고리가 prose paragraph면 → schema로 변환 (사용자 컨펌 후)
-   - 카테고리에 variant block 1개뿐이면 → 라이브 inspect 데이터를 기반으로 추가
-3. **최소 4 카테고리** 충족 확인 (브랜드 surface에 실제로 그 카테고리가 있을 때만)
-4. 각 variant block은 다음 fields 모두:
-   ```
-   **<Variant Name>**
-   - Background: <value>
-   - Text: <value>
-   - Border: <value | none>
-   - Radius: <value>
-   - Padding: <value>
-   - Font: <size> / <weight> / <family>
-   - Use: <one-line context>
-   ```
-
-#### 🚨 §4 작성 강제 규칙 (이거 어기면 builder Components 섹션이 통째로 안 나옴)
-
-**1줄 = 1필드.** 절대 슬래시(`/`)·콤마로 여러 필드를 한 줄에 결합하지 말 것. 파서(`extract-components`)는 `^- Field: value$` 패턴만 인식한다.
-
-❌ **금지** — 슬래시 multi-field (KRDS 초기 작성에서 36 variants 중 35개가 안 보였던 케이스):
-```
-- Background: `#256EF4` / Text: `#FFFFFF` / Border: 1px solid `#256EF4`
-```
-
-✅ **필수** — 1필드 1불릿:
-```
-- Background: `#256EF4`
-- Text: `#FFFFFF`
-- Border: 1px solid `#256EF4`
-```
-
-**예외**: `- Font: <size> / <weight> / <family>` 는 한 필드(`font`)의 정해진 sub-syntax. Background·Text·Border 등 별도 필드를 합치는 것과 다르다.
-
-**State variants** (Hover/Pressed/Focus/Disabled/Required/Error): 동일 variant 블록 내 별도 `- Hover:` / `- Pressed:` 불릿. 별도 `**Variant**` 블록 만들지 않는다.
-
-**Size scale** (xsmall/small/medium/large/xlarge): 1개 `**Variant**`에 default 사이즈만 불릿. 나머지 사이즈는 그 블록 뒤 markdown 테이블로. variant 5개로 쪼개지 않는다.
-
-**자가 검증 (G1+G2 통과 조건)**:
-```bash
-S4=$(awk '/^## 4\./,/^## 5\./' web/references/<id>/DESIGN.md)
-slash=$(echo "$S4" | grep -E "^- " | grep -cE " / [A-Za-z][a-z]+:")
-[ "$slash" -gt 0 ] && echo "❌ FAIL: $slash 슬래시 multi-field 잔존" && exit 1
-echo "✓ canonical schema clean"
-```
-
-이 검사 실패 시 G1+G2 ✗ → 수정 → 재검증. footer-only fix로 우회 금지.
-
-**Figma 케이스 예시** (현재 G1+G2 ✗):
-- Cards/Navigation/Distinctive가 prose → schema 변환 필요
-- Black Pill variant data가 Icon variant와 conflate → 분리 필요
-
----
-
-## Phase G3 — Tier 1 live inspect (≥2 surfaces)
-
-playwright로 brand의 **다른 컨텍스트 surface 2개 이상** navigate + evaluate:
-
-| Brand type | Surfaces 권장 |
-|---|---|
-| 마케팅 + 제품 분리 (Apple, Toss, Spotify) | marketing home + product/checkout |
-| 컨슈머 (Airbnb, Coinbase) | home + listing/asset detail |
-| 개발자 도구 (Stripe, Vercel, Linear) | home + docs/dashboard |
-| 동아시아 (Kakao, Karrot) | KR locale + secondary surface |
-| Auto luxury (BMW, Ferrari) | home + configurator (cookie banner 너머까지) |
-
-각 surface에 대해:
-1. `mcp__playwright__browser_navigate(<url>)`
-2. `mcp__playwright__browser_evaluate` — `getComputedStyle` 추출 패턴 (스킬 SKILL.md 또는 omd-add-reference 참고)
-3. raw observations를 `web/references/<id>/.verification.md`에 append
-
----
-
-## Phase G4 — Tier 2 cross-check
-
-**둘 다 시도** (✓는 결과가 0건이어도 시도했다는 증거):
-
-1. `WebFetch https://getdesign.md/<id>` — getdesign 데이터 (대부분 directory only이지만 로그)
-2. **playwright** `https://styles.refero.design/?q=<brand>` (WebFetch는 SSR shell만 반환하므로 playwright 필수):
-   - search → 결과 카드 collect (`a[href^="/style/"]`)
-   - 각 결과 카드에 대해 `WebFetch /style/<uuid>` 으로 detail 추출
-   - 한 brand에 multiple style 페이지 있으면 (Apple 4개, Airbnb 2개) 전부 수집
-
-`.verification.md`에 Tier 2 raw observations append.
-
----
-
-## Phase G5 — Conflict matrix → `.verification.md`
-
-`web/references/<id>/.verification.md` 형식 (Apple 참고):
-
-```markdown
-# <Brand> — Verification Notes (YYYY-MM-DD)
-
-## Tier 1 — live DOM (playwright getComputedStyle)
-### Surfaces inspected
-- <url 1>
-- <url 2>
-
-### Raw observations
-**<Component class> — <Variant>**
-- bg: <value>
-- color: <value>
-- ...
-
-## Tier 2a — getdesign.md
-- result: <data | "directory only" | "404">
-
-## Tier 2b — styles.refero.design
-- result: <list of style UUIDs and their data | "no record">
-
-## Conflict Matrix
-
-| Field | Tier 1 (live) | getdesign | refero | Resolution |
-|---|---|---|---|---|
-
-### Resolution rule
-- All three agree → use that value
-- Tier 1 ≠ Tier 2 → Tier 1 wins **only if** Tier 1 evidence is timestamped/inspectable now
-- Two Tier 2 sources disagree, Tier 1 silent → flag `(unresolved)` and document in footer
-- Earlier mistakes to revert → list explicitly
-
-### Unresolved
-- (none | list)
-
-## Components to write/revise in §4
-1. <list>
-```
-
-**Conflict 발견 시 사용자에게 채팅으로 보고하고 결정 받음** (silent 해결 금지).
-
----
-
-## Phase G6 — Philosophy depth pass (§10-15)
-
-**현재는 inline-handwritten freehand. 이 스킬에서는 다음을 강제:**
-
-### 6-1. Source minimum
-- WebFetch `<domain>/about`
-- WebFetch `<domain>/manifesto` 또는 `<domain>/mission` (있다면)
-- WebSearch: `"<brand>" voice tone guidelines`
-- 창업자 인터뷰 / 에세이 (≥1)
-- 최소 3 source 확보, 못 하면 §11 narrative에 명시
-
-### 6-2. Voice samples 검증
-- §10 voice samples ≥3개 중 **최소 2개는 `verified: <url>` 마킹** 필수
-- `illustrative: not verified` 마킹은 "패턴은 맞는데 라이브 UI 텍스트 아님" 명시
-- 추론 샘플에 구체 수치/브랜드 전용 용어 금지 (`<amount>`, `<product>` 자리표시자)
-
-### 6-3. Brand Narrative 사실 검증
-- §11에 적힌 창업자 이름 / 창업 연도 / 주요 마일스톤 / IPO 등 → WebSearch로 1차 확인
-- 미검증 수치는 `<!-- not re-verified in this pass -->` 인라인 주석
-
-### 6-4. Style ref pick
-- `--style-ref <id>` flag 또는 자동 (KR→toss, JP→line, US engineering→stripe, US minimal→claude, EU→stripe, 기타→notion)
-
-### 6-5. Diagnostic rubric
-omd-add-reference Phase 10-6 rubric 적용 (D1-D11). Pass: ≥9 green, no red, yellow ≤2.
-
----
-
-## Phase G7 — Footer 갱신
-
-`§4` 끝 / `§15` 끝 두 곳에 footer 박음 (이미 있으면 augment, 없으면 신규):
-
-```markdown
----
-
-**Verified:** YYYY-MM-DD (omd:migrate)
-**Tier 1 sources:** <url 목록 + 각 surface 핵심 발견>
-**Tier 2 sources:** <refero style URL + getdesign URL or "no record">
-**Tier 2 status:** <unavailable / partial / complete>
-**Conflicts unresolved:** <none | list>
-**Philosophy sources:** <Tier 1 + Tier 2 for §10-15>
-**Style ref:** <picked>
-**Migration depth:** Apple-tier (G1-G9 all passed | G3 partial: skipped <reason>)
-```
-
----
-
-## Phase G8 — Tests
-
-```
-cd web && npm test --silent
-```
-215+ passing 유지. 깨지면:
-- fixture 영향이면 `generate-css.test.ts` 합성 fixture 사용 중인지 확인
-- 그 외면 사용자에게 보고 후 중단
-
----
-
-## Phase G9 — Visual smoke
-
-스킬은 자동 체크 못 함. 사용자에게 명시적 안내:
-
-```
-다음을 확인해주세요:
-1. 로컬 dev server: `cd web && pnpm dev` (or `npm run dev`)
-2. /reference/<id> 페이지 로드
-3. 체크포인트:
-   - Hero 카드 라이트/다크 모드 둘 다 OK
-   - Components 섹션에 G2 통과한 모든 카테고리가 spec card로 렌더
-   - white-on-white 텍스트 없음
-   - Circular variants가 정사각 (이전 ellipse 버그 없음)
-   - Radius cap regression 없음 (1280px 같은 값 안 박힘)
-4. OK면 spec/migration-checklist.md G9 컬럼 ✓
-```
-
----
-
-## Phase R — Report + checklist update
-
-마지막에:
-
-1. `spec/migration-checklist.md`의 해당 brand row 갱신 (gate별 ✓/✗/~)
-2. 하단 "Per-brand migration log" 테이블에 row append
-3. 사용자에게 다음 형식으로 보고:
-
-```
-✅ <brand> migration 완료 (omd:migrate)
-
-Gates:
-  G1 schema     ✓
-  G2 ≥4 cats    ✓ (Buttons, Inputs, Cards, Badges, ...)
-  G3 surfaces   ✓ (N개: <url 목록>)
-  G4 Tier 2     ✓ (refero: <result>, getdesign: <result>)
-  G5 verif.md   ✓ (~N lines)
-  G6 philo      ✓ (M voice verified / K illustrative; sources: ...)
-  G7 footer     ✓
-  G8 tests      ✓ (215/215)
-  G9 smoke      ⚠️  pending — 사용자 확인 필요
-
-Conflicts unresolved: <none | list>
-Earlier mistakes reverted: <list>
-.verification.md: web/references/<id>/.verification.md
-
-다음 단계:
-- /reference/<id> 시각 확인 → G9 ✓
-- 다음 brand: omd:migrate <next>
-```
-
----
-
-## 안티패턴 (절대 금지)
-
-- ❌ Tier 2 (refero/getdesign) 시도 안 하고 G4 ✓ 표기
-- ❌ Live inspect 1 surface로 G3 ✓ 표기 (≥2 mandatory)
-- ❌ §4 footer만 박고 §4 본문 안 건드림 ("footer-only 안티패턴" — 이전 batch 1·2의 실수)
-- ❌ §10-15 voice samples 전부 illustrative로 두고 G6 ✓ 표기
-- ❌ Conflict 발견했는데 silent하게 결정
-- ❌ `.verification.md` 없이 G5 ✓ 표기
-
-## Triggers (자연어)
-
-- `omd:migrate <brand>`
-- `<brand> apple 깊이로`
-- `<brand> 풀 마이그레이션`
-- `<brand> 깊게 검증`
-- `next migrate` → checklist 다음 우선순위 brand 자동 선택
-- `migrate figma` → figma 마이그레이션 시작

package/.opencode/oh-my-design/.claude/skills/omd-orchestrator/SKILL.md

@@ -1,124 +0,0 @@
----
-name: omd:orchestrator
-description: "멀티 에이전트 디자인 워크플로우 supervisor. omd-kr-writer, omd-locale-adapter, omd-designer-review, omd-final-qa, omd-codex-image를 routing. 2-round revision cap 유지. 블로그/컴포넌트/아티클 등 multi-role 작업에 트리거 ('블로그 글 작성', 'KR+EN 동시 발행', '디자인 리뷰 받고 다듬어줘')."
-user-invocable: true
----
-
-# omd:orchestrator
-
-omd v0.2 agent layer의 **supervisor**. 한 글/한 컴포넌트가 여러 specialist를 거쳐야 할 때 routing을 책임진다.
-
-채택 패턴: **Anthropic orchestrator-workers** (Building effective agents, 2024-12) + **LangGraph supervisor**의 revision-cap. 자세한 비교는 `data/research/2026-05-18-agent-landscape.md` §1.
-
-> 런타임 dependency 없음. Claude Code의 subagent 호출 메커니즘이 그대로 orchestrator-workers 토폴로지를 구현한다.
-
-## 0. Worker 카탈로그
-
-| 역할 | subagent | 용도 |
-|---|---|---|
-| Writer | `omd-kr-writer` | 한국어 본문 작성. `preset_id` 인자로 voice 결정. |
-| Localizer | `omd-locale-adapter` | KR → EN/JP/ZH-TW **adaptation** (번역 아님) |
-| Visual reviewer | `omd-designer-review` | DESIGN.md 대비 typo/색/spacing/state 검수 |
-| Critic | `omd-final-qa` | Read-only rubric verdict. 2-round cap 강제. |
-| Image materializer | `omd-codex-image` | `<!-- omd:gen-image -->` 블록을 채널별로 실체화 (Codex native gen / asset-curator fallback / OpenCode user-queue) |
-
-## 1. 입력
-
-사용자 요청. 예:
-- "당근 디자인 시스템 분석 글 작성, KR + EN, 5500자+"
-- "이 컴포넌트 디자인 리뷰 받고 카피 다듬어줘"
-- "이 글 final QA 거쳐서 출간 ready로"
-
-## 2. Routing decision tree
-
-```
-사용자 요청 도착
-├─ "글 작성" 키워드 → Stage 1: omd-kr-writer
-├─ 다국어 요청 ("EN", "영문", "JP") → Stage 3 추가
-├─ artifact 첨부 + "리뷰" → Stage 2부터 진입
-└─ "출간 ready" → Stage 4 final-qa로 직행
-```
-
-## 3. 표준 5-stage 워크플로우 (블로그 글 기준)
-
-```
-Stage 1  WRITE       omd-kr-writer  (preset=toss-tech-design)
-Stage 2  REVIEW      omd-designer-review  (artifact + brand DESIGN.md)
-Stage 2r REVISION    omd-kr-writer  (review feedback 반영)  ← max 2 round
-Stage 3  LOCALIZE    omd-locale-adapter  (KR → EN/JP)
-Stage 4  CRITIC      omd-final-qa  (rubric, read-only)
-Stage 4r REVISION    omd-kr-writer  (final-qa feedback)  ← max 2 round (Stage 2와 별도 카운트)
-Stage 4i IMAGES      omd-codex-image  (`<!-- omd:gen-image -->` 블록 처리, 채널별 분기)
-Stage 5  HANDOFF     사용자에게 최종 artifact + revision log + image manifest
-```
-
-## 4. Revision cap (hard)
-
-각 critic gate (designer-review, final-qa)는 **최대 2 round**.
-
-```
-revision_state = {
-  "designer_review": { "round": 0, "max": 2 },
-  "final_qa":        { "round": 0, "max": 2 }
-}
-```
-
-Round 2 후에도 BLOCK이면:
-1. 사용자에게 escalate ("designer-review가 2회 fail. 강제 통과? 재작성? 폐기?")
-2. 강제 통과 시 known issues 섹션을 artifact frontmatter에 명시
-3. 재작성 시 Stage 1로 회귀, 카운터 리셋
-
-## 5. Handoff 로그 (필수)
-
-각 stage 전후로 `<work_dir>/.orchestrator.log`에 append:
-
-```
-[2026-05-18T10:23:11] STAGE=write  agent=omd-kr-writer  status=ok  artifact=content/posts/karrot/index.ko.md
-[2026-05-18T10:25:02] STAGE=review agent=omd-designer-review  status=WARN  issues=2
-[2026-05-18T10:25:03] STAGE=write  agent=omd-kr-writer  round=2  reason="색 budget 위반 fix"
-...
-```
-
-## 6. State 직렬화
-
-Orchestrator 자체는 stateless. 모든 state는 파일 시스템:
-- artifact: `content/posts/<slug>/index.<locale>.md`
-- review reports: `content/posts/<slug>/.reviews/round-<N>.md`
-- final verdict: `content/posts/<slug>/.reviews/final-qa.md`
-
-## 7. Subagent 호출 규약
-
-Claude Code subagent 호출 시 다음 envelope:
-
-```yaml
-agent: omd-kr-writer
-inputs:
-  task: "당근 디자인 분석 글 작성"
-  preset_id: toss-tech-design
-  brand_design_md: references/karrot/DESIGN.md
-  target_length: 6000
-  output_path: content/posts/karrot/index.ko.md
-revision_round: 0
-prior_review: null  # 또는 review report 경로
-```
-
-응답을 받으면 `.orchestrator.log`에 기록 후 다음 stage 결정.
-
-## 8. Anti-patterns (금지)
-
-- **3+ round revision loop** — cost runaway. Round 2에서 escalate.
-- **Critic의 직접 수정** — final-qa는 read-only. Writer로 round-trip해야.
-- **Stage skip** — designer-review 없이 final-qa 진입 금지 (rubric 불충분).
-- **병렬 stage 같은 artifact 수정** — race condition. writer/locale-adapter는 직렬.
-- **rubber-stamp** — final-qa가 "looks good" 응답 시 orchestrator는 rejected로 처리.
-
-## 9. 병렬화 허용 케이스
-
-- KR이 PASS된 뒤 EN/JP/ZH-TW **localization은 병렬** (각각 다른 파일이라 conflict 없음)
-- DESIGN.md re-read는 stage마다 강제 (Anthropic best practice — memory hallucination 방지)
-
-## 10. 종료 조건
-
-- final-qa verdict = PASS → handoff stage로
-- final-qa round 2 BLOCK → 사용자 escalation
-- 사용자가 명시적으로 abort → `.orchestrator.log`에 ABORT 기록 후 종료

package/.opencode/oh-my-design/.claude/skills/omd-release-hygiene/SKILL.md

@@ -1,113 +0,0 @@
----
-name: omd:release-hygiene
-description: "오픈소스 릴리스 위생 루틴. 새 기능/스킬/에이전트를 추가했을 때 (1) 부산물(v1/v2 .bak, _source, 로그, scratch dir)이 changeset에 없는지, (2) 문서(README/docs/home)가 동기화됐는지, (3) npm 배포 대상인지(skills/ + files vs .claude local-preview) 판단했는지 체크리스트로 강제. '릴리스 준비', '커밋 전 점검', 'push 전에 정리', '배포 위생', 'release hygiene' 류 트리거. husky pre-commit이 부산물 게이트를 자동 실행."
-user-invocable: true
----
-
-# omd:release-hygiene
-
-오픈소스 레포가 "최적의 결과물만 push"하도록 강제하는 루틴. 실험 과정에서 생긴 부산물이 public repo로 새는 것을 막고, 새 deliverable이 문서/패키징과 어긋나지 않게 한다.
-
-자동 게이트는 [`scripts/check-release-hygiene.sh`](../../../scripts/check-release-hygiene.sh)가 husky `pre-commit`에서 돌린다. 이 스킬은 그 게이트가 잡지 못하는 *판단*(문서 동기화, npm 배포 여부)을 사람/에이전트가 책임지게 한다.
-
-## 0. 언제 트리거하나
-
-- 새 스킬 / 에이전트 / CLI 플래그 / 큰 기능을 추가한 직후
-- 커밋 또는 push 직전 ("정리하고 올리자")
-- 실험(`experiments/`, `.promo/`)을 돌린 세션의 마무리
-
-## 1. 4-항목 체크리스트 (전부 통과해야 push)
-
-### [1] 부산물 0건 (자동 + 수동)
-
-자동: `bash scripts/check-release-hygiene.sh staged` — pre-commit이 이미 실행.
-수동 확인 대상 (게이트 정규식 밖일 수 있는 것):
-
-- 반복 드래프트: `*.v1.html`, `*-draft`, `*-old`, `*-copy`
-- 빌드 스크립트가 산출물 옆에 남은 경우: `build.mjs`, `crop-*.mjs` (experiments 안이면 gitignore로 OK)
-- 에이전트 로그 / 리뷰 덤프: `.orchestrator.log`, `.reviews/`
-- 소스 크롭 / 컨택트 시트: `_source-*`, `*-contact-sheet*`
-
-판단 기준: **"이 파일이 6개월 뒤 처음 보는 기여자에게 의미가 있나?"** No면 부산물.
-
-### [2] scratch 디렉토리는 gitignore (절대 추적 X)
-
-`.gitignore`에 다음이 있어야 한다 (이미 설정됨):
-
-```
-experiments/      # 갤러리 + 브랜드 목업 + 저니 (로컬 전용)
-.promo/           # hyperframes 프로모 영상
-.experiments/     # /omd-lab-* 런
-.codex/           # codex 채널 self-install 산출물
-.agents/skills/omd*/   # generic-agent 채널 self-install
-web/.husky/       # root .husky의 중복본
-```
-
-새 채널/툴이 self-install 산출물을 만들면 같은 패턴으로 추가.
-
-### [3] 문서 동기화 (deliverable 추가 시)
-
-새 스킬/에이전트를 추가했으면 다음을 **전부** 갱신:
-
-| 위치 | 무엇을 |
-|---|---|
-| `README.md` | 스킬 표 / 카운트. shipped vs local-preview 구분 명시 |
-| `web/src/app/docs/page.tsx` | `SKILLS` 또는 `V2_SKILLS` 배열 + 섹션 eyebrow 카운트 + 상단 nav anchor |
-| `web/src/components/landing-v2/sections.tsx` | "N skills + M sub-agents" 하드코딩 카운트 — **번들(npm) 기준**으로만. local-preview는 카운트에서 제외 |
-
-홈 화면 카운트는 **npm 번들 기준**이다. local-preview 스킬을 더해도 홈 카운트는 안 올린다 (그게 일관성 신호).
-
-### [4] npm 배포 판단 (shipped vs local-preview)
-
-새 스킬/에이전트가 npm 패키지로 나갈지 결정한다. 두 갈래:
-
-**Shipped (번들)** — 다음을 *모두* 해야 함:
-1. `skills/<name>/SKILL.md`로 복사 (package source). `.claude/skills/`는 dogfood 미러.
-2. 에이전트는 `agents/<name>.md`로 복사 (`agents/`는 통째로 ship).
-3. `package.json`의 `files` 배열에 `skills/<name>` 추가 (files가 npm tarball을 gate).
-4. 스킬이 의존하는 스크립트/데이터도 `files`에 포함 (예: `data/research/*.md`). 외부 스크립트 의존이 실효성 없으면 ship 전에 제거 (precedent: kr-spellcheck heuristic은 recall 낮아 폐기).
-5. README/docs에서 "preview" 딱지 제거, 홈 카운트 +1.
-6. 버전 bump: 기능 추가 = minor. **단, 버전 bump와 `npm publish`는 사용자 명시 요청 시에만.**
-
-**Local-preview (dogfood만)** — 기본값:
-- `.claude/skills/` + `.claude/agents/`에만 존재. `skills/`·`files`에는 넣지 않음.
-- README/docs에 "local preview, not bundled" 명시 + 수동 채택 방법(디렉토리 복사) 안내.
-- 기존 local-only 선례: `omd-add-reference`, `omd-batch-launch`, `omd-migrate`, `omd-lab-*`.
-- 기존 shipped 선례: v0.2 agent layer (orchestrator / kr-writer / locale-adapter / designer-review / final-qa / codex-image) — 6 skills + 6 agents.
-
-**판단 휴리스틱**: 미완성 의존성(없는 스크립트 참조 등)·preview 성숙도·매 설치마다 footprint 증가가 걸리면 → local-preview. 안정적이고 자급자족이며 모든 채널에서 작동하면 → shipped 후보.
-
-## 2. 실행 순서 (에이전트용)
-
-```
-1. bash scripts/check-release-hygiene.sh all      # 부산물 전수 스캔
-2. git status --porcelain | grep -iE '_old|_source|\.bak|v[0-9]\.|contact-sheet'  # 이중 확인
-3. .gitignore에 scratch dir 누락 없는지 확인
-4. 이번 changeset에 새 스킬/에이전트가 있나? → [3] 문서 동기화
-5. 새 스킬을 ship할까? → [4] 판단. 기본 local-preview
-6. 사용자에게 요약 보고. 커밋/푸시는 명시 요청 시에만.
-```
-
-## 3. 출력 형식
-
-```
-release-hygiene
-  [1] byproducts:   ✓ 0 in changeset
-  [2] scratch dirs: ✓ experiments/ .promo/ .codex/ ignored
-  [3] docs sync:    ✓ README + /docs updated  (or: N/A — no new deliverable)
-  [4] npm decision: local-preview (joins omd-migrate et al.)  (or: shipped → files updated)
-```
-
-## 4. 금지
-
-- ❌ `experiments/` / `.promo/` 를 `git add -f`로 강제 추적
-- ❌ 부산물 게이트를 `--no-verify`로 우회 (긴급시 외)
-- ❌ 사용자 요청 없이 버전 bump 또는 `npm publish`
-- ❌ local-preview 스킬을 홈 화면 번들 카운트에 합산
-- ❌ shipped로 승격하면서 의존 스크립트를 `files`에 빠뜨림 (= 깨진 설치)
-
-## 5. 관련
-
-- `scripts/check-release-hygiene.sh` — 자동 부산물 게이트 (pre-commit)
-- `.husky/pre-commit` — 게이트 + catalog-integrity 실행
-- `package.json#files` — npm tarball allowlist (shipped 판단의 ground truth)