zugzbot 1.0.21 → 1.0.22

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

@@ -1,121 +0,0 @@
----
-name: omd:learn
-description: ".omd/preferences.md의 status:pending 항목을 DESIGN.md에 정식 merge하고 status를 applied로 플립. '프리퍼런스 정리해줘', 'fold preferences', 'apply all corrections', 「好みをDESIGN.mdに反映」, 「套用偏好」류의 요청에 트리거. 단발성 교정 기록은 omd:remember."
----
-
-# omd:learn — Preference Fold into DESIGN.md
-
-`.omd/preferences.md`에 누적된 `status: pending` 교정사항을 DESIGN.md에 반영하고, 반영된 엔트리의 상태를 `applied`로 플립한다. **CLI 호출 없음** — Read/Edit 툴로 직접 처리.
-
-## Phase 1 — 검토
-
-`Read .omd/preferences.md` → frontmatter + 엔트리들 파싱:
-
-- 엔트리 분리: `## ` heading 기준 split
-- 각 엔트리의 `omd-meta` 코드블록에서 `id`, `scope`, `status` 추출
-- `status: pending`만 필터
-
-scope별로 그룹화해서 사용자에게 요약:
-
-```
-components.button (3 pending):
-  - CTAs never uppercase (pref_xxx, pref_yyy)
-  - primary fill should be brand-500 not 600 (pref_zzz)
-
-spacing (1 pending):
-  - 8pt grid, not 4pt (pref_aaa)
-```
-
-엔트리당 한 줄이 아니라 **scope당 2-3줄로 의도 정리**.
-
-## Phase 2 — 사용자 확인
-
-"이 교정들을 DESIGN.md에 반영할까요?" 묻기. 동의 → Phase 3.
-
-거부 → 어떤 scope를 reject할지 묻고 Phase 4 reject 분기로.
-
-## Phase 3 — DESIGN.md 적용
-
-1. `Read DESIGN.md` 로드
-2. scope별로 묶어서 **하나의 coherent edit** 생성 (엔트리당 하나가 아니라 한 scope의 교정들을 종합)
-3. Edit 툴로 DESIGN.md의 해당 섹션 수정:
-   - `components.button` → DESIGN.md §8 (Components → Button) 또는 §13 (Components 상세)
-   - `color` → §2 (Color Palette)
-   - `typography` → §3
-   - `spacing` → §4 (Spacing scale)
-   - `voice` → §10 (Voice & Tone)
-   - `motion` → §15 (Motion & Easing)
-   - `visualTheme` → §1 (Visual Theme)
-4. **voice/내러티브 수정 시 DESIGN.md의 기존 문체 preserve** — 교정 내용만 반영, 문장 스타일/길이/톤 유지
-5. **§10-15 (Brand Philosophy 레이어)는 reference voice 보존이 우선** — preference가 §10-15 본문 자체를 다시 쓰라고 하지 않는 한 본문은 건드리지 않고 §1-9의 axes만 수정
-
-## Phase 4 — 상태 플립
-
-반영한 엔트리: 해당 엔트리의 omd-meta 블록을 Edit 툴로:
-- `status: pending` → `status: applied`
-- `applied_at: <ISO timestamp>` 라인 추가
-- (선택) `applied_design_md_hash: <DESIGN.md sha256>` 추가. hash 계산:
-  ```bash
-  node -e "console.log(require('crypto').createHash('sha256').update(require('fs').readFileSync('DESIGN.md')).digest('hex').slice(0,12))"
-  ```
-
-거부한 엔트리:
-- `status: pending` → `status: rejected`
-- `rejected_reason: "<짧은 이유>"` 라인 추가
-
-상위 엔트리가 누적된 작은 교정을 통합·대체했으면:
-- 작은 엔트리들은 `status: superseded`
-- `superseded_by: <상위 pref_id>` 추가
-
-## Phase 5 — 결과 요약
-
-한 문단:
-- 반영된 교정 수 (scope별)
-- 거부된 교정 수 + 이유
-- 사용자에게 `.omd/preferences.md` 직접 확인 안내
-
-```
-4 preferences applied to DESIGN.md
-  - components.button: CTAs never uppercase, primary brand-500
-  - spacing: 8pt grid
-1 rejected (conflicts with base reference radius)
-
-Review .omd/preferences.md for details.
-```
-
-## Fold-in 제안에서 호출된 경우 (`.omd/foldin-proposal.json`)
-
-SessionStart 컨텍스트의 OMD FOLD-IN PROPOSAL → AskUserQuestion 승인 경로로 호출되었으면 Phase 2 확인은 이미 끝난 것 — 다시 묻지 말 것.
-
-제안 없이 사용자가 직접 omd:learn을 부른 경우에도 `.omd/foldin-proposal.json`이
-`"status": "proposed"`로 존재하면: 그 scopes를 이번 폴드 대상에 포함할지 Phase 2에서
-함께 확인하고, 처리 후 아래와 동일하게 status를 갱신한다 (proposed인 채로 방치 금지 —
-다음 세션이 또 물어본다).
-
-- **승인된 scope만** Phase 3-4로 처리. 미승인 scope의 pending 엔트리는 건드리지 않는다
-- 처리 후 `.omd/foldin-proposal.json`의 status를 Edit 툴로 갱신:
-  - 전부 반영 → `"status": "applied"` + `"applied_at": "<ISO timestamp>"` 필드 추가
-  - 일부만 반영 → `"status": "partial"` + `scopes` 배열을 **남은(미승인) scope만**으로 갱신
-  - 전부 거절("나중에") → `"status": "snoozed"` + `"snoozed_at": "<ISO timestamp>"` 필드 추가
-  - status 값은 **JSON 계약상 영문 고정** (`proposed`/`applied`/`partial`/`snoozed`) —
-    번역·한글화 금지 (훅이 문자열 비교로 읽는다)
-
-## 옵션 패턴
-
-사용자가 특정 작업만 요청하는 경우:
-
-- **"pending만 보여줘"** → Phase 1만, Phase 2-5 생략
-- **"X scope만 반영"** → 해당 scope만 Phase 3에서 처리
-- **"<pref_id>를 applied로 표시"** → Phase 4의 single-entry 플립만
-- **"<pref_id>를 rejected로 표시 + 이유"** → 동일
-- 플립 전 현재 status를 먼저 Read로 확인: 이미 같은 값이면 no-op 보고,
-  `superseded`/`rejected` → `applied` 전환은 **금지** (이력 오염 — 사용자에게
-  "이 항목은 X 상태예요. 되살리려면 omd:remember로 재캡처하세요"라고 안내)
-
-## 금지
-
-- LLM으로 엔트리별 개별 diff를 생성하지 말 것 — scope별 합쳐서 하나의 coherent edit
-- DESIGN.md의 section heading 계층을 바꾸지 말 것
-- 교정과 관계없는 부분을 "개선"하지 말 것
-- pending을 건너뛰지 말 것 — 모든 pending에 applied/rejected/superseded 중 하나로 플립
-- omd-meta 블록 외부 (body) 수정 금지 — 교정 본문은 영구 기록

package/.opencode/oh-my-design/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/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 기록 후 종료