zugzbot 1.0.21 → 1.0.22

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

@@ -1,229 +0,0 @@
----
-name: omd:kr-writer
-description: "한국어 글쓰기 멀티-preset 스킬. 12개 preset 지원 — toss-tech-design (default) / karrot-neighborly / brunch-maker-popular / naver-d2-engineering / biz-formal-report / academic-paper / journalism-broadsheet / kakao-warm-product / line-global-saas / academic-lecture-essay / emotional-brand / legal-disclosure. '한글 글 작성', 'KR rewrite', '토스 톤으로', '당근 톤으로', '브런치 톤으로', '보고서로 써줘', '학술 톤', '신문기사체' 류 트리거."
-user-invocable: true
----
-
-# omd:kr-writer
-
-oh-my-design의 한국어 본문 작성 스킬. **preset_id 인자**로 6개 voice 중 선택.
-
-## 0. preset_id 인자
-
-호출 envelope:
-
-```yaml
-agent: omd-kr-writer
-inputs:
-  preset_id: toss-tech-design  # 또는 아래 6개
-  task: "당근 디자인 분석 글 작성"
-  ...
-```
-
-지원 preset 12개. **자세한 9-field spec + verbatim 한국어 examples**: `data/research/2026-05-18-kr-style-presets.md`
-
-| # | preset_id | 종결 | 분량 (한글) | 용도 |
-|---|---|---|---|---|
-| 1 | `toss-tech-design` ⭐ (default) | 해요체 -요 | 5,500~7,000자 | omd 블로그 본문, 디자인 deep-dive |
-| 2 | `karrot-neighborly` | 해요체 + 동네 lexicon | 3,000~5,000자 | 마케팅, 커뮤니티 글 |
-| 3 | `brunch-maker-popular` | 해요체 80% + 회상 `-했다` | 4,000~6,000자 | 회고, 포스트모템, 메이커 에세이 |
-| 4 | `naver-d2-engineering` | 해요체 + 격식 mix | 자유 | 엔지니어링 분석 글 |
-| 5 | `biz-formal-report` | 하십시오체 -습니다 | 자유 | 보고서·기획서·BRD |
-| 6 | `academic-paper` | 해라체 `-한다`/`-이다` | 자유 | 학술 논문, 연구 노트 |
-| 7 | `journalism-broadsheet` | 해라체 `-다`/`-했다` | 자유 | 보도자료, 신문기사 |
-| 8 | `kakao-warm-product` | 해요체 + 감정 표현 | 자유 | 카카오톡·카카오뱅크 in-app copy |
-| 9 | `line-global-saas` | 해요체 + 다국어 친화 | 자유 | 한일 brand voice, 글로벌 SaaS |
-| 10 | `academic-lecture-essay` | 해요체 + 학술 lexicon | 자유 | 교양 강연, 지식 에세이 |
-| 11 | `emotional-brand` | 해요체 + 외래어 자유 | 자유 | 무신사·29CM 패션 커머스 |
-| 12 | `legal-disclosure` | 하십시오체 + 한자어 | 자유 | 법무·약관·고지사항 |
-
-**호출 시 preset 미지정 → `toss-tech-design` 적용.**
-
-본 문서의 § 1~8은 default preset (`toss-tech-design`)의 상세 spec. 다른 preset 선택 시 research doc의 해당 section 룰로 substitution.
-
-### 전환 매트릭스 (자주 쓰는 6개)
-
-같은 콘텐츠를 다른 preset으로 옮길 때 standard rewrite 룰. 자세한 5-step rule은 research doc §14 참조.
-
-| from | to | 핵심 변환 |
-|---|---|---|
-| `biz-formal-report` | `toss-tech-design` | `-합니다`→`-해요` · 한자어 풀이 · 50자+ 문장 쪼개기 · 3인칭→1인칭 |
-| `toss-tech-design` | `biz-formal-report` | `-요`→`-니다` · 인사 제거 · 섹션 번호 (1.1) · 한자어 회복 |
-| `academic-paper` | `toss-tech-design` | `-한다`→`-해요` · `우리는`→`저는` · 인용 형식 인라인 |
-| `karrot-neighborly` | `toss-tech-design` | "동네" lexicon 제거 · 분석 voice 강화 · 5,500자+ |
-| `journalism-broadsheet` | `toss-tech-design` | `-다`→`-요` · OOO 대표 said → 직접 quote · narrative 1인칭 |
-| `legal-disclosure` | `kakao-warm-product` | 한자어 → 우리말 · 수동 → 능동 · 친근 어휘 보강 |
-
-### 한국어 어말어미 — 6단계 speech level
-
-| 단계 | 격식 | 친근 | 종결예 | preset 매핑 |
-|---|---|---|---|---|
-| 하십시오체 | ✓ | ✗ | -습니다 | biz-formal / legal |
-| 하오체 | ✓ | ✗ | -오, -소 | (구식, 거의 안 씀) |
-| 하게체 | △ | △ | -네, -게 | (구식, 윗사람→아랫사람) |
-| 해라체 | ✗ | ✗ | -다, -한다 | academic / journalism |
-| 해요체 ⭐ | △ | ✓ | -요, -아요 | toss / karrot / kakao / brunch / line / lecture / emotional |
-| 해체 (반말) | ✗ | ✓✓ | -아, -이야 | (사용 안 함 — disrespectful) |
-
-omd 디폴트는 **해요체**. 격식이 필요하면 하십시오체. 학술/뉴스만 해라체. 그 외 모든 경우 해요체.
-
----
-
-## Default preset (toss-tech-design)
-
-oh-my-design 블로그의 한국어 본문을 **Toss Tech 디자인 카테고리** 수준의 voice로 작성. Brunch와 당근 미디엄도 보조 참고.
-
-## 1. Voice DNA — 한국 디자인 블로그 명문 공통 패턴
-
-### 첫 단락 fingerprint (변형 가능)
-
-```
-안녕하세요. [본인 직무] [본인 이름]이에요.
-저는 [구체적인 업무]를 담당하고 있어요.
-[배경 1-2 문장 — 어떤 상황에서 어떤 미션을 받았는지].
-오늘은 [주제]를 나눠보려고 해요.
-```
-
-oh-my-design용 변형:
-```
-안녕하세요. oh-my-design을 만드는 [이름]이에요.
-107개 브랜드의 디자인 시스템을 라이브로 캡쳐해서 카탈로그로 모으고 있어요.
-오늘은 그 중 [브랜드]를 들여다본 이야기를 나누려고 해요.
-```
-
-### 종결 어미 룰
-
-| 사용 | 빈도 |
-|---|---|
-| `-요` | **100%** (default) |
-| `-했어요`, `-있어요`, `-거예요`, `-네요` | 자주 |
-| `-아요`, `-이에요` | 자주 |
-| `-습니다`, `-는다`, `-한다` | **금지** (관공서 톤) |
-| `-입니다`, `-합니다` | **금지** |
-
-### 문장 호흡
-
-- **평균 35~50자/문장**. 80자+ 문장 = 쪼개기.
-- 두 문장 연결: `~했고, ~했어요.` → 가급적 `~했어요. ~했어요.` 두 문장으로.
-- 접속사 `그리고`/`그래서`/`그런데` 남발 금지. 단락 이행은 새 단락으로.
-- 감탄/조사 `~네요`, `~죠`, `~인가요?` 적절히 — 글이 살아남.
-
-### 단락 길이
-
-- **평균 3~5 문장 / 단락**. 80자+ 단락 = 쪼개기.
-- 한 줄 단락 OK — 강조용.
-- 글 전체에서 80% 이상이 짧은 단락.
-
-### 첫 인사 + 마지막 인사
-
-```
-시작: "안녕하세요. ~이에요."
-마무리: 
-  - "여기까지 [주제]에 대해 나눠봤어요."
-  - "혹시 [관련 질문]이 있다면 댓글로 남겨주세요."
-  - "다음 글에서는 [다음 주제]를 들고 올게요."
-```
-
-## 2. 구조 템플릿 — 디자인 시스템 분석 글
-
-### 한국어 H2 헤더 패턴
-
-영문 식 `## Insight 1 — OKLCH-based perceptual color scaling` 같은 무거운 헤더는 금지. 한국어는 **짧고 호흡감 있게**.
-
-| 영문 패턴 | 한국어 변환 |
-|---|---|
-| `## 1. A short history of "the Toss feel"` | `## 토스 느낌의 시작` |
-| `## 2. The atmosphere — calm, confident, deceptively simple` | `## 화면을 열면 흰 캔버스` |
-| `## 3. Insight 1 — OKLCH-based perceptual color scaling` | `## 토스는 색을 수학으로 정의해요` |
-| `## 4. What to steal` | `## 가져가도 좋은 것` |
-| `## 5. What NOT to steal` | `## 따라하면 안 되는 것` |
-
-원칙: 헤더는 **3~12자**. 문장형 OK, 호기심 유발 OK, 결론 spoiler OK.
-
-### 권장 글 구조 (5,500자+ 목표)
-
-1. **인사 + 글 소개** (~300자) — 안녕하세요 인사 + 오늘 분석할 브랜드 소개 + 어떻게 분석했는지
-2. **브랜드 배경** (~600자) — 회사 역사 짧게, 디자인이 왜 지금처럼 됐는지
-3. **첫 인상 — 화면을 열면** (~700자) — 시각 톤, 색, 타입, 첫 느낌
-4. **인사이트 1** (~700자) — 발견 1개, 왜 중요한지, 어떻게 따라할지
-5. **인사이트 2** (~700자)
-6. **인사이트 3** (~700자)
-7. **인사이트 4** (~700자)
-8. **인사이트 5** (~600자) — 더 짧아도 OK
-9. **가져가도 좋은 것** (~400자) — 5개 정리 (불릿 OK)
-10. **따라하면 안 되는 것** (~400자) — 5개 정리
-11. **마무리 + CTA** (~200자) — MCP 설치, design-system 페이지 링크
-
-목표: **5,500자~7,000자** (한국어, 공백 제외).
-
-## 3. 이미지/figure 정책
-
-Toss 글은 단락 2~3개 당 이미지 1개. oh-my-design 본문에서:
-
-- **헤로 이미지**: 글 첫머리, 브랜드 색감 + 타이포 한 컷
-- **인사이트 1~5 각**: 1~2개 이미지 (스크린샷 / 다이어그램 / 컬러 그리드)
-- **figcaption 짧게**: "토스 송금 화면" / "OKLCH 컬러 그리드" / "토스 vs KB의 헤로 비교"
-- **alt 텍스트는 단순한 설명만** — figcaption과 다른 정보
-
-이미지가 부족한 경우:
-- 라이브 캡쳐 (browser-harness로 brand site 스크린샷)
-- CSS 비주얼 컴포넌트 (ColorSwatchGrid, TypeSample 등)
-- 다이어그램 (인라인 SVG, primitive → semantic → component 같은 토큰 트리)
-
-## 4. 인사이트 본문 패턴
-
-각 인사이트는 다음 4 단락 구조 권장:
-
-1. **현상 단락**: "토스를 열면 이상한 게 있어요. ~" — 호기심 hook
-2. **데이터 단락**: "실제로 CSS 번들을 뜯어보니, ~ 81번 등장하더라구요." — 숫자/증거
-3. **이유 단락**: "왜 이렇게 했을까요? ~" — 디자인 thesis
-4. **적용 단락**: "여러분 작업에 가져가려면, ~" — actionable
-
-## 5. 안티패턴 (절대 금지)
-
-- ❌ `-습니다`, `-한다`, `-할 것이다` 등 격식체
-- ❌ `~할 수 있다` 식 가능형 남발 → `~할 수 있어요`
-- ❌ 영어를 한글로 번역만 한 듯한 문장 (`이것은 우리가 만든 시스템이다` — X. `우리가 만든 시스템이에요.` — O)
-- ❌ 영문 인용 부호 그대로 (`"trust comes from clarity"`) → `"신뢰는 깊이가 아니라 명확함에서 온다"` (한글 번역 + 영문 옆에 작게)
-- ❌ 머리말 `## 1. 인사이트 1 — Insight 1: OKLCH-based ~` 식 형식적 헤더
-- ❌ 마지막에 "감사합니다." 한 줄 → 톤 깨짐. 차라리 안 쓰기.
-- ❌ 문단 사이를 `**굵게**` 강조로 도배 — 시각 노이즈
-- ❌ 5,000자 미만 분량 (5분 안 채워짐)
-
-## 6. 어휘 가이드
-
-| 어색한 한자어 | 친근한 한국어 |
-|---|---|
-| 사용자 | 쓰는 사람 / 사용자 (case-by-case, 사용자도 OK) |
-| 설계하다 | 설계하다 / 만들다 |
-| 적용하다 | 적용하다 / 쓰다 |
-| 결과적으로 | 결국 / 그렇게 |
-| 비교했을 때 | 비교하면 |
-| ~에 의하면 | ~에 따르면 |
-| 또한 | 그리고 / 또 |
-| 따라서 | 그래서 |
-| 본인 | 본인 / 자신 / 나 |
-| 일반적으로 | 보통 |
-
-## 7. 실행 절차
-
-1. 영문 원문 본문을 가져옴 (`content/posts/<slug>/index.md`의 EN 부분)
-2. 각 H2 섹션을 한 번에 1개씩 KR로 옮김
-3. 첫 단락에 "안녕하세요 ~" intro 삽입
-4. H2 헤더를 짧은 한국어로 다시 작성
-5. 종결어미 100% `-요`로 통일
-6. figure placeholder `![설명](./images/...png "figcaption")` 삽입 — 인사이트당 1~2개
-7. 마지막에 "여기까지 ~ 나눠봤어요" 마무리
-8. 글 끝에 frontmatter의 `title_ko`, `subtitle_ko` 필드 채움
-
-## 8. Quality bar
-
-- 분량: 5,500자~7,000자 (공백 제외, 한국어 본문)
-- 종결어미 `-습니다` / `-한다` 검사 = 0건
-- 인사이트당 평균 ≥ 2 figure placeholder
-- 첫 단락 "안녕하세요" 인사 포함
-- 가져가도 좋은 것 / 따라하면 안 되는 것 = 각 5개
-
----
-
-이 스킬은 oh-my-design 블로그 한국어 본문의 **단일 source of truth voice guide**. 모든 KR 글은 이 guide를 따른다.

package/.opencode/oh-my-design/.claude/skills/omd-lab-01-designmd-impact/SKILL.md

@@ -1,53 +0,0 @@
----
-name: omd-lab-01-designmd-impact
-description: |
-  OmD Lab #01 — DESIGN.md 유무·생성방식이 UI 결과물에 미치는 영향을 4가지 조건으로 비교.
-  토스 스타일 모바일 UI를 (V1) DESIGN.md 없이, (V2) 수동 작성, (V3) 자동 생성,
-  (V4) 자동 생성 + 5회 피드백 루프로 만들어 동시 비교 뷰로 시각화.
-  사용자가 본인의 Claude Code 안에서 재현 가능한 실험.
-trigger: /omd-lab-01-designmd-impact <setup|v1|v2|v3|v4|compare|all>
----
-
-# OmD Lab #01 — DESIGN.md Impact
-
-본 스킬은 `.experiments/01-designmd-impact/` 디렉토리를 작업 대상으로 한다.
-별도 API 호출 없이, 사용자의 Claude Code 세션 안에서 서브에이전트와 직접 작성을 통해 모든 단계를 수행한다.
-
-## 모드별 동작
-
-| 명령 | 작업 | 산출물 |
-|---|---|---|
-| `setup` | shared/ 자산 검증, Pinterest 핀 안내 | shared/ 검증 리포트 |
-| `v1` | base-prompt만으로 UI 생성 | v1-no-design/output/, chatlog/v1-session.md |
-| `v2` | analysis.md → 표준 9섹션 DESIGN.md 수동 작성 → UI 생성 | v2-with-design/{DESIGN.md, output/}, chatlog/v2-session.md |
-| `v3` | analysis.md → step1-description.md → step2-DESIGN.md(자동 생성) → UI 생성 | v3-describe-to-design/*, chatlog/v3-session.md |
-| `v4` | v3 산출물에서 시작 → feedback-script.md[1..5] 순차 적용 → 5 iteration | v4-iterative-feedback/iterations/iter-01..05/, chatlog/v4-iter-*.md |
-| `compare` | 4-column 동시 스크롤 비교 페이지 빌드 | compare/index.html |
-| `all` | setup → v1 → v2 → v3 → v4 → compare 일괄 실행 | 전체 |
-
-## 공통 원칙
-
-1. **모든 LLM 호출은 Claude Code 세션 내에서**. Anthropic API 직접 호출 금지.
-2. **모든 입출력은 `chatlog/`에 박제**. User 프롬프트, Assistant 응답(요약 + 핵심 출력), 서브에이전트 호출을 markdown으로 기록.
-3. **공통 자산 잠금**. `shared/` 변경 금지 — fonts, reset.css, base-prompt.md, assets는 4버전이 동일하게 사용.
-4. **단계별 재현 가능**. 각 모드는 이전 모드의 산출물을 입력으로 받지만, 입력 파일이 git에 박제되어 있으면 단독 재실행 가능.
-5. **사용자 시각 검증**: `compare` 산출물을 브라우저로 열면 4개 결과를 동시에 스크롤하며 비교 가능.
-
-## 서브에이전트 매핑
-
-| 역할 | subagent_type | 사용 단계 |
-|---|---|---|
-| ui-builder | sc:sc-frontend-architect | V1, V2, V3, V4 매 iter |
-| toss-describer | Explore | V3·V4 step1 (analysis.md 읽고 description 산출) |
-| design-md-author | sc:sc-technical-writer | V3 step2, V4 iter-N의 DESIGN.md 갱신 |
-| preference-merger | general-purpose | V4 매 iter (피드백 → DESIGN.md preference 누적) |
-
-각 서브에이전트 호출 시 프롬프트는 `playbooks/v*.md`에 명시된 템플릿을 따른다.
-
-## 자세한 흐름은 `playbooks/`
-
-- `playbooks/v1.md`
-- `playbooks/v2.md`
-- `playbooks/v3.md`
-- `playbooks/v4.md`
-- `playbooks/compare.md`

package/.opencode/oh-my-design/.claude/skills/omd-lab-01-designmd-impact/playbooks/compare.md

@@ -1,30 +0,0 @@
-# Compare Playbook — 4-column 동시 스크롤 뷰
-
-## 산출물
-`.experiments/01-designmd-impact/compare/index.html`
-
-## 요구사항
-
-### Layout
-- 4 column flex (옵션으로 5번째 column "Reference: Pinterest 핀 8개 슬라이드쇼" 추가 가능)
-- 각 column 헤더: 라벨 + 짧은 설명 + chatlog 링크
-  - V1: "DESIGN.md 없음"
-  - V2: "수동 DESIGN.md"
-  - V3: "자동 DESIGN.md"
-  - V4: "자동 + 피드백 5회"
-- 각 column body: `<iframe src="../v1-no-design/output/index.html">` ... 같이 4개
-
-### 동기화 스크롤
-- 한 iframe이 스크롤 → 나머지 3개 동일 비율로 스크롤
-- 구현: 각 iframe 내부 contentWindow.scrollY를 listen → ratio 계산 → 다른 iframe scrollTo
-
-### 부가 기능
-- 우상단 "Reference 핀 보기" 토글 → `shared/reference-toss/pinterest/pin-*.jpg` 슬라이드쇼 모달
-- 각 column 하단 "📜 chatlog" 링크 → `chatlog/v*-session.md` 새 탭으로
-- 데스크탑 전용. 모바일 안내 메시지만.
-
-### 정적 파일만
-빌드 도구 없음. `index.html` + 인라인 CSS/JS 또는 `compare/style.css`, `compare/sync.js`.
-
-### 실행 안내
-`python3 -m http.server 8080` 또는 그냥 `open compare/index.html` (file://도 동작하도록 path 처리).

package/.opencode/oh-my-design/.claude/skills/omd-lab-01-designmd-impact/playbooks/v1.md

@@ -1,42 +0,0 @@
-# V1 Playbook — DESIGN.md 없이
-
-## 목적
-context로 base-prompt만 전달했을 때 LLM이 만드는 "토스 스타일"의 베이스라인 측정.
-
-## 단계
-
-### 1. ui-builder 서브에이전트 호출
-```
-context: .experiments/01-designmd-impact/shared/base-prompt.md (only)
-output dir: .experiments/01-designmd-impact/v1-no-design/output/
-```
-
-### 2. 산출
-- `v1-no-design/output/index.html`
-- `v1-no-design/output/style.css`
-
-### 3. chatlog 기록
-`chatlog/v1-session.md`에 다음을 박제:
-
-```markdown
-# V1 Session — DESIGN.md 없이
-
-**Date:** <오늘>
-**Inputs:** shared/base-prompt.md
-**Subagent:** sc:sc-frontend-architect (ui-builder 역할)
-
----
-
-## User
-> (base-prompt.md 내용 그대로)
-
-## Assistant (ui-builder)
-- index.html: <간단 요약 — 어떤 구조로 짰는지 한 단락>
-- style.css: <어떤 시스템 토큰 사용했는지 한 단락>
-- 자체 평가: <토스 스러움에 대한 LLM의 자기 평가, 어떤 부분이 모자랄 수 있는지>
-
-→ v1-no-design/output/ 작성 완료
-```
-
-### 4. 평가 메모 (사람)
-일부러 평가 메모를 안 적는다 — V1은 베이스라인이라 raw 결과 그대로.

package/.opencode/oh-my-design/.claude/skills/omd-lab-01-designmd-impact/playbooks/v2.md

@@ -1,34 +0,0 @@
-# V2 Playbook — DESIGN.md 수동 작성
-
-## 목적
-사람이 토스 핀들을 분석해서 직접 작성한 표준 DESIGN.md(9섹션)가 결과물에 어떤 영향을 주는지.
-
-## 단계
-
-### 1. DESIGN.md 작성
-`v2-with-design/DESIGN.md`를 OmD 표준 9섹션 + Philosophy 레이어로 작성.
-근거 자료는 `shared/reference-toss/analysis.md`. 작성 자체는 사람(Claude)이 직접 하되,
-"디자이너가 토스를 보고 표준 DS 문서를 작성한 것처럼" 보이게.
-
-섹션 (omd-add-reference 표준):
-1. Color Palette
-2. Typography
-3. Layout System
-4. Spacing
-5. Components
-6. Iconography
-7. Imagery
-8. Voice & Tone
-9. Motion
-10. (OmD v0.1) Philosophy
-11. (OmD v0.1) Patterns
-12. (OmD v0.1) Anti-patterns
-
-### 2. ui-builder 호출
-```
-context: shared/base-prompt.md + v2-with-design/DESIGN.md
-output: v2-with-design/output/
-```
-
-### 3. chatlog
-`chatlog/v2-session.md` 박제 — User 프롬프트 = base-prompt + "+ DESIGN.md 첨부" 명시.

package/.opencode/oh-my-design/.claude/skills/omd-lab-01-designmd-impact/playbooks/v3.md

@@ -1,33 +0,0 @@
-# V3 Playbook — Description → DESIGN.md → UI
-
-## 목적
-실제 omd:add-reference 흐름 모방. 자연어 설명을 DESIGN.md로 자동 변환한 뒤 그걸로 UI 생성.
-
-## 단계
-
-### 1. step1-description.md 작성
-toss-describer 서브에이전트(Explore)에게 `shared/reference-toss/pinterest/` 8개 핀과
-`shared/reference-toss/analysis.md`를 보고 자연어 설명 작성 요청.
-
-```
-prompt 요약: "토스 핀 8장을 봤다고 가정하고 디자인 시스템을 자연어로 설명해줘.
-색·타이포·레이아웃·컴포넌트·톤·이미저리·모션·철학 순서로.
-실제 사용자가 add-reference에 붙여넣을 만한 자연스러운 한국어 문장으로."
-```
-
-→ `v3-describe-to-design/step1-description.md`
-
-### 2. step2-DESIGN.md 자동 생성
-design-md-author 서브에이전트(sc:sc-technical-writer)에게 step1 → DESIGN.md 변환 요청.
-"omd-add-reference 스킬이 하는 일을 흉내내라"고 명시.
-
-→ `v3-describe-to-design/step2-DESIGN.md` (V2와 같은 9+3섹션 구조)
-
-### 3. ui-builder 호출
-```
-context: shared/base-prompt.md + step2-DESIGN.md
-output: v3-describe-to-design/output/
-```
-
-### 4. chatlog
-`chatlog/v3-session.md`에 step1·step2·UI 빌드 3턴을 모두 박제.

package/.opencode/oh-my-design/.claude/skills/omd-lab-01-designmd-impact/playbooks/v4.md

@@ -1,37 +0,0 @@
-# V4 Playbook — Iterative Feedback Loop (5 iterations)
-
-## 목적
-V3 결과 + 5회의 피드백 turn으로 점진 정제. 피드백을 DESIGN.md의 Preferences 섹션에 누적 → UI 재생성 반복.
-
-## 사전 준비
-- `v4-iterative-feedback/feedback-script.md` (5개 항목, 사전 큐레이션)
-- 시작점: V3 산출물 복제
-  - `v3-describe-to-design/step2-DESIGN.md` → `v4-iterative-feedback/iterations/iter-00/DESIGN.md`
-  - `v3-describe-to-design/output/` → `v4-iterative-feedback/iterations/iter-00/output/`
-
-## iter-N 수행 (N = 1..5)
-
-### a. preference-merger 호출
-```
-input:
-  - iter-(N-1)/DESIGN.md
-  - feedback-script.md[N]
-output:
-  - iter-N/DESIGN.md (Preferences 섹션에 N번 피드백 누적, 충돌은 명시)
-  - iter-N/design-diff.md (이번 턴 변경분만 추출)
-```
-
-### b. ui-builder 호출
-```
-context: shared/base-prompt.md + iter-N/DESIGN.md + iter-(N-1)/output/ (이전 결과 참고)
-output: iter-N/output/
-```
-
-### c. chatlog 기록
-`chatlog/v4-iter-0N.md`에 박제:
-- User: feedback-script.md[N] 본문
-- Assistant (preference-merger): preference 누적 결과 + diff
-- Assistant (ui-builder): 이번 iter에서 변경된 시각 요소 요약
-
-## 종료
-`iter-05` 완료 후 `v4-iterative-feedback/final → iter-05` 심볼릭 링크 (또는 복제).

package/.opencode/oh-my-design/.claude/skills/omd-lab-02-design-harness/SKILL.md

@@ -1,131 +0,0 @@
-<!-- omd:installed-skill — managed by `omd install-skills`. Do not edit; rerun the command to refresh. -->
-
----
-name: omd-lab-02-design-harness
-description: OmD Lab #02 — 디자인 하네스 정교화 실험. 동일 task를 v1, v2, v3... 버전별 하네스 설정으로 돌려서 산출물 품질·토큰 비용·iteration 수·persona ABANDON 율을 비교. 트리거 — '/omd-lab-02', '하네스 lab 시작', '디자인 하네스 v2 돌려서 비교', 'lab #02 자동 비교'.
----
-
-# OmD Lab #02 — Design Harness Refinement
-
-`omd:harness`의 정교화 작업을 위한 실험실. 동일한 design task를 *서로 다른 하네스 설정* (v1, v2, v3, ...)으로 돌려서 품질·비용·실패모드를 비교한다.
-
-## 왜
-
-Lab #01이 "DESIGN.md 유무"의 영향을 봤다면, Lab #02는 **하네스 자체의 설정**(prompt 변형, persona pool, eval rubric, asset 정책 등)이 산출물에 미치는 영향을 본다.
-
-## 디렉토리 구조
-
-```
-skills/omd-lab-02-design-harness/
-├── SKILL.md                       (this file)
-├── playbooks/
-│   ├── v1.md                      (현재 baseline — first full implementation)
-│   ├── v2.md                      (다음 실험 가설)
-│   └── ...
-├── runs/
-│   ├── v1-run-<ts>-<slug>/        ← omd:harness가 v1 설정으로 돌린 산출물 전체
-│   ├── v2-run-<ts>-<slug>/
-│   └── ...
-├── compare/
-│   ├── README.md                  (어떤 task로 어떤 v를 비교했는가)
-│   └── <task-id>/
-│       ├── index.html             (v1 vs v2 vs v3 동시 비교 뷰)
-│       └── metrics.json           (집계 비교 지표)
-└── postmortem-aggregate.md        (전 v 누적 학습)
-```
-
-## Lab Run 프로토콜
-
-### 새 v 정의 (Lab 운영자 — 사용자 또는 Claude)
-
-1. `playbooks/v<N>.md` 작성. 가설을 한 줄로:
-   ```
-   ## Hypothesis
-   v2 raises persona ABANDON budget from 3s → 5s, expecting fewer false-abandon and more useful friction signal.
-   ```
-2. v<N>이 v<N-1>과 *바꾸는 것 정확히 명시*. 1개 변수만 바꾸는 게 원칙.
-3. 변경 점이 sub-agent 프롬프트에 있으면 `playbooks/v<N>/agents-overrides/*.md`로 patch 보관.
-
-### Lab Run 실행
-
-```bash
-# 운영자가 수동 실행
-omd harness "<task>" --lab v2
-# 또는 사용자가 자연어:
-# "이 task를 lab v2 설정으로도 돌려서 v1과 비교해줘"
-```
-
-`--lab v<N>`이 들어오면:
-- `runs/v<N>-run-<ts>-<slug>/` 디렉토리에 산출물 적재
-- v<N>의 agent overrides가 있으면 그걸 임시로 `.claude/agents/`에 덮어씌운 채 실행 (run 종료 시 원복)
-- run.log에 `lab_version: v<N>` 기록
-
-### 비교 뷰 생성
-
-운영자가 동일 task에 대해 v1, v2, ..., vN의 run을 끝내면:
-
-```bash
-omd lab compare --task "<task-slug>" --versions v1,v2,v3
-```
-
-이게 `compare/<task-slug>/index.html`을 만든다. 4-패널 (또는 N-패널) 비교:
-- 각 v의 brief.md / 주요 wireframe / DESIGN.md.patch / persona ABANDON 요약 / 토큰 비용
-- 공통 metrics.json: per-v {iterations, total_tokens, persona_abandon_rate, deterministic_pass_rate, jury_score, time_to_handoff}
-
-### 비교 metrics 정의
-
-```json
-{
-  "task": "토스 스타일 가족 식단 앱 메인",
-  "versions": {
-    "v1": {
-      "iterations": 2,
-      "total_tokens_estimated": 320000,
-      "persona_abandon_rate": 0.5,
-      "deterministic_pass_rate": 1.0,
-      "jury_score_normalized": 0.72,
-      "time_to_handoff_min": 18,
-      "user_satisfied": "?"
-    },
-    "v2": { ... }
-  },
-  "delta_v1_v2": "v2 reduced persona_abandon_rate by 0.25 but raised total_tokens by 12% — net win on signal quality"
-}
-```
-
-## 진행 트랙 (이 Lab의 로드맵)
-
-| v | hypothesis | status |
-|---|---|---|
-| v1 | First full implementation — 8 agents, 10 phases, 3 user checkpoints | active baseline |
-| v2 | (TBD) | pending |
-| v3 | (TBD) | pending |
-
-`playbooks/v1.md`가 baseline 정의. 운영자는 매 회 새 가설로 v<N>.md를 추가한다.
-
-## postmortem-aggregate.md 정책
-
-매 lab run 종료 시, run의 `postmortem.md`에서 *cross-version-relevant* 신호만 발췌해 `postmortem-aggregate.md`에 누적:
-- 자주 발생하는 deterministic gate 실패
-- persona ABANDON 트리거 빈도 분포
-- 사용자가 가장 자주 reject하는 phase 출력
-- 토큰이 가장 많이 새는 sub-agent
-
-이게 다음 v의 가설을 만들어낸다.
-
-## 사용 예 (한 줄 시연)
-
-```
-사용자: "토스 스타일 결제 화면 — Lab #02로 v1, v2 비교"
-→ Claude: omd harness "..." --lab v1 실행 → v1-run 적재
-→ (사용자 체크포인트 진행, ship 결정)
-→ Claude: omd harness "..." --lab v2 실행 (동일 brief 재사용 가능)
-→ omd lab compare --task <slug> --versions v1,v2
-→ compare/<slug>/index.html 결과 제시
-```
-
-## 금지
-
-- v 정의 없이 run 적재 X (반드시 playbooks/v<N>.md 선행)
-- 동일 task의 동일 v 결과를 덮어쓰지 X (timestamp로 보존)
-- runs/ 정리 X (영구 보존)

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

@@ -1,83 +0,0 @@
-<!-- omd:installed-skill — managed by `omd install-skills`. Do not edit; rerun the command to refresh. -->
-
----
-name: omd:learn
-description: "누적된 preference 교정사항을 DESIGN.md에 반영합니다. '프리퍼런스 정리해줘', 'DESIGN.md 업데이트', 'preference 반영', 'fold preferences', 'learn from corrections' 같은 요청에 트리거됩니다."
----
-
-# omd:learn — Preference Fold into DESIGN.md
-
-`.omd/preferences.md`에 누적된 `status: pending` 교정사항을 DESIGN.md에 반영하고, 반영된 엔트리의 상태를 `applied`로 플립한다.
-
-## Phase 1 — 검토
-
-Bash 툴로:
-
-```bash
-omd learn
-```
-
-실행하면 pending 엔트리를 scope별로 그룹화해서 보여준다. 출력을 읽고 사용자에게 **그룹별 요약**을 제시한다 (각 엔트리를 나열하지 말고, scope당 2-3줄로 의도 정리).
-
-예시 출력 형식:
-```
-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)
-```
-
-## Phase 2 — 사용자 확인
-
-"이 교정들을 DESIGN.md에 반영할까요?" 묻는다. 사용자가 동의하면 Phase 3.
-
-## Phase 3 — 적용
-
-1. **DESIGN.md를 Read 툴로 로드**한다.
-2. scope별로 묶어서 **하나의 coherent edit**을 생성한다 (엔트리당 하나의 edit이 아니라, 한 scope의 교정들을 종합).
-3. Edit 툴로 DESIGN.md의 해당 섹션을 수정.
-4. **voice 섹션이나 내러티브를 수정할 때는 DESIGN.md의 기존 문체를 preserve**한다 — 교정 내용만 반영하되 문장 스타일, 길이, 톤은 유지.
-5. 수정 후 `DESIGN.md`의 새 hash를 계산. Bash:
-   ```bash
-   omd sync --force  # shim들의 hash 갱신 (DESIGN.md 해시는 pointer라 바뀌지 않지만 lock만 업데이트)
-   ```
-
-## Phase 4 — 상태 플립
-
-반영한 각 엔트리에 대해:
-
-```bash
-omd learn --mark-applied <pref_id>
-```
-
-반영 안 한 엔트리(충돌, 거부)는:
-
-```bash
-omd learn --mark-rejected <pref_id> --reason "<짧은 이유>"
-```
-
-## 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.
-```
-
-## 금지
-
-- LLM으로 엔트리별 개별 diff를 생성하지 말 것 — scope별 합쳐서 하나의 coherent edit.
-- DESIGN.md의 section 구조(heading 계층)를 바꾸지 말 것.
-- 교정과 관계없는 부분을 "개선"하지 말 것.
-- pending을 건너뛰지 말 것 — 모든 pending에 대해 applied or rejected 플립해야 한다.