npm - zugzbot - Versions diffs - 1.0.20 → 1.0.22 - Mend

zugzbot 1.0.20 → 1.0.22

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1272) hide show

package/.opencode/oh-my-design/skills/omd-init/SKILL.md DELETED Viewed

@@ -1,314 +0,0 @@
----
-name: omd:init
-description: "프로젝트 루트에 DESIGN.md를 부트스트랩 — 실제 기업 레퍼런스 중 컨텍스트 매칭으로 추천하고 선택된 레퍼런스의 톤&매너를 보존한 variation을 생성. DESIGN.md 부재 상태에서의 UI 작업 또는 '디자인 시스템 세팅', 'set up our design system', 「デザインシステムを作って」, 「建立設計系統」류의 요청에 트리거. CLAUDE.md / AGENTS.md / Cursor rule shim도 함께 설치."
----
-# omd:init — DESIGN.md Bootstrap
-프로젝트에 DESIGN.md + AI 코딩 에이전트용 shim 3종을 한 번에 세팅. 레퍼런스 톤&매너는 **preserve**하고, 사용자 프로젝트 맥락은 controlled-vocabulary delta_set으로만 반영.
-**CLI 호출 없음** — Read/Write/Bash(파일 작업만) 툴로 직접 처리. (이전 버전은 `omd init recommend` 등 CLI subcommand를 호출했으나 현재 CLI binary는 `install-skills`만 노출. 이 skill은 self-contained하게 동작.)
-## 전체 플로우
-```
-Phase 1: 사용자 맥락 파악 (1-2 질문)
-Phase 2: 레퍼런스 추천 (fingerprint 기반 in-head 점수)
-Phase 3: 사용자가 1개 선택
-Phase 3.5: 적용 형태 확인 (루트 부트스트랩 / 참고용 저장 / 기존 파일 교체 여부)
-Phase 4: 레퍼런스 DESIGN.md Read + delta_set 추출
-Phase 4.5: Philosophy Layer 입력 수집
-Phase 5: Hybrid variation으로 DESIGN.md 작성
-Phase 6: Shim 3종 설치 (omd:sync skill 위임)
-Phase 7: 요약 출력
-```
-## Phase 1 — 맥락 파악
-이미 충분한 description이 있으면 skip. 부족하면 **최대 2개** 질문:
-1. 프로젝트 유형/도메인 (SaaS / 랜딩 / 대시보드 / 이커머스 / 커뮤니티 등)
-2. 분위기 키워드 (warm, minimal, premium, playful, dense, airy 등)
-한 번에 하나씩, 또는 통합해서 한 번에. 질문 쌓지 말 것.
-## Phase 2 — 레퍼런스 추천 (file-based, no CLI)
-### 2.1 카탈로그 로드
-다음 파일을 Read 툴로 전체 로드 (있는 순서대로 fallback):
-1. `.claude/data/reference-fingerprints.json` (사용자 프로젝트에 설치된 카탈로그 — 표준 경로)
-2. `node_modules/oh-my-design-cli/data/reference-fingerprints.json` (npm 설치 직접 경로)
-3. `data/reference-fingerprints.json` (개발 환경)
-스키마: `{ count, items: [{ id, primary_color_hex, category, visual_theme, voice_fingerprint, tone_keywords, antipatterns, signature_motion, has_personas, category_raw }] }`.
-추가 보조 파일 (있으면 같이 로드):
-- `.claude/data/vocabulary.json` — controlled vocab axes/keywords
-- `.claude/data/reference-tags.md` — human-readable keyword matrix
-### 2.2 task 분석 (silent, in-head)
-사용자의 description에서 다음 추출:
-- **명시 brand hint**: 한글/영문 brand 이름 직접 언급 (예: "토스 같은" → `toss`, "뱅크샐러드 톤" → `banksalad`, "Linear-clone" → `linear.app`). brand 이름과 id 매핑은 일반 지식 사용 + `items[].id` 또는 `items[].category_raw`에서 cross-check.
-- **vocab 키워드**: warm / minimal / dense / playful / formal / editorial / clinical 등 (vocabulary.json 참조)
-- **카테고리 추측**: Consumer Tech / Fintech / Productivity / E-commerce / Design Tools / Developer Tools / AI & LLM / Mobility / HR / Real Estate / Healthcare / Government
-### 2.3 점수 계산 (in-head, deterministic)
-각 item에 대해:
-- brand hint match → **+5점**
-- `tone_keywords` ∩ task vocab 키워드 → 매칭당 **+1점**
-- `category` 일치 → **+1점**
-Top 5 정렬. 모든 추천 id는 `items[].id`에 **반드시** 존재 — hallucination 금지.
-### 2.4 사용자에게 제시
-prose로:
-```
-"<task 핵심 한 줄>"을 보니 <top1.id>가 가장 잘 맞을 것 같아요 — <visual_theme 핵심 한 줄 + 매칭 키워드 1-2개>.
-이대로 가시려면 go (또는 <top1.id>).
-다른 후보: <top2.id> (한 줄 이유) · <top3.id> (...) · <top4.id> (...) · <top5.id> (...)
-본인이 아는 다른 reference 있으면 id로 알려주세요 (예: vercel) — 카탈로그에 없으면 알려드립니다.
-```
-vocab axis conflict 있으면 (예: formal ↔ playful) 먼저 알리고 우선시할 축을 묻기.
-**Claude Code 채널이면 위 prose 대신 AskUserQuestion 툴 1개로 제시** (사용자가 화살표로 고르는 selectable UI — #21). question 1개에 top-5 후보 id 5개를 option으로:
-```
-question: ""<task 핵심 한 줄>"에 맞는 레퍼런스를 골라주세요"
-header: "Reference"
-options: top1~top5 각각 → label = <id>, description = fingerprint 기반 1줄 (<category> · <tone_keywords 1-2개>)
-  - top1에는 label에 "(추천)" 표시
-```
-(AskUserQuestion이 자동 "Other"를 추가하므로 카탈로그의 다른 id를 자유 입력으로 답하는 것도 그대로 가능.) Codex / OpenCode 등 AskUserQuestion이 없는 채널은 위 prose 포맷 유지. 점수 계산·채택 로직(Phase 3)은 어느 쪽이든 동일.
-## Phase 3 — 사용자 선택
-- `go` 또는 top-5 안 id → 그 id 채택
-- top-5 밖이지만 카탈로그 안 id → 그대로 채택
-- 카탈로그에 없는 id → "해당 id는 카탈로그에 없어요. top-5 중에서 골라주세요."
-- "중단" → 종료
-## Phase 3.5 — 적용 형태 확인
-레퍼런스 확정 직후, 어떻게 적용할지 묻는다. 먼저 프로젝트 루트에 `DESIGN.md`가
-이미 있는지 확인하고, **Claude Code 채널이면 AskUserQuestion 1개** (타 채널은
-prose)로:
-- 루트에 DESIGN.md **없음**:
-  1. **프로젝트 디자인 시스템으로 설정 (추천)** — `<id>` 톤을 보존한 변형본을
-     루트 `DESIGN.md`로 부트스트랩 (Phase 4~7 전체 진행)
-  2. **참고용으로만 저장** — 루트 변경 없음. `<id>` 원본을
-     `design-references/<id>.md`로 복사하고 종료. "나중에 프로젝트에 적용하려면
-     다시 omd:init을 불러주세요" 안내. (변형 생성·셤 설치 안 함)
-- 루트에 DESIGN.md **이미 있음** (option description에 그 파일의 §0/§1 요약
-  한 줄을 보여줄 것):
-  1. **교체 (추천)** — 기존 파일은 `DESIGN_DEPRECATED.md`로 보존됨을 명시
-  2. **참고용으로만 저장** — 위와 동일
-  3. **중단**
-②(참고용) 선택 시: Phase 4.1로 원문만 확보해 `design-references/<id>.md`에
-attribution 1줄(소스 URL + 날짜)과 함께 저장 → Phase 7 요약만 출력하고 종료.
-Phase 4.2~6은 건너뛴다.
-## Phase 4 — 레퍼런스 DESIGN.md 로드
-### 4.1 경로 결정
-선택된 id를 `<id>`로 하고, 다음 순서로 Read (먼저 존재하는 것 사용):
-<!-- omd:catalog-resolution-order — omd-harness/omd-reference-capture SKILL.md + agents/omd-master.md 와 동일 순서 강제. drift guard: test/unit/core/catalog-resolution-order.test.ts -->
-1. `.claude/data/references/<id>/DESIGN.md` (installer가 복사 — npx 설치 기본 경로)
-2. `node_modules/oh-my-design-cli/web/references/<id>/DESIGN.md` (로컬 npm 설치 직접 경로)
-3. `web/references/<id>/DESIGN.md` (개발 레포)
-4. `https://oh-my-design.kr/design-systems/<id>.md` 를 fetch (WebFetch 또는 `curl -fsSL`) — 1~3 로컬 경로가 전부 없을 때 (npx 설치가 기본 경로라 흔한 상황). 200이면 응답 본문이 곧 reference DESIGN.md다. 가져온 내용을 `.claude/data/references/<id>/DESIGN.md`로 저장해 다음 실행부터는 로컬 캐시(경로 1)로 잡히게 한다.
-4까지 전부 실패하면 **절대 DESIGN.md를 임의로 지어내지 말 것.** 사용자에게
-"레퍼런스 `<id>` 원문을 찾지 못했어요 (오프라인이거나 카탈로그 미배포).
-네트워크 연결 후 재시도하거나 다른 레퍼런스를 골라주세요"라고 보고하고 종료.
-전체 내용을 `reference_md` 변수로 보관 (Phase 5의 입력).
-### 4.2 기존 DESIGN.md 처리
-프로젝트 루트에 이미 `DESIGN.md`가 있으면 (Phase 3.5에서 이미 "교체"를 확인받은
-상태 — 여기서 다시 묻지 않는다):
-1. Read로 내용 확인
-2. Bash로 `mv DESIGN.md DESIGN_DEPRECATED.md`
-3. `DESIGN_DEPRECATED.md` 최상단에 다음 헤더 prepend (Edit 툴):
-   ```html
-   <!-- omd:deprecated
-   replaced_at: <ISO-8601 today>
-   replaced_by: ./DESIGN.md (bootstrapped from <id>)
-   reason: omd:init bootstrap
-   -->
-   ```
-### 4.3 init-context 기록
-`.omd/init-context.json` 작성 (없으면 mkdir):
-```json
-{
-  "reference_id": "<id>",
-  "description": "<원본 사용자 description>",
-  "mode": "clone | inspired",
-  "delta_set": {
-    "axes": { /* description에서 추출한 vocab axis ↦ shift 값 */ },
-    "voiceHints": [ /* 추출된 voice 힌트 */ ],
-    "matchedKeywords": [ /* 매칭된 vocab 키워드 */ ],
-    "warnings": [ /* axis conflict 등 */ ]
-  },
-  "bootstrapped_at": "<ISO-8601>"
-}
-```
-빌더(oh-my-design.kr/builder)발 프롬프트에는 "Components: button, input, ..." 목록과
-"(builder config: <URL>)"이 붙어올 수 있다. 컴포넌트 목록은 `"requested_components": ["button", "input", ...]`
-키로 함께 기록하고, builder URL은 출처 표기용으로만 보존 — fetch하지 말 것.
-`mode` 값 결정:
-- omd:reference-capture가 먼저 돌았으면 그 결과 사용 (`.omd/init-context.json` 기존값)
-- 아직 정해지지 않았으면 사용자에게 묻기 (omd:reference-capture Phase 0과 동일한 prompt). 라이브 캡쳐 없이 omd:init만 단독으로 도는 경우는 사실상 inspired 외엔 의미 없으므로 기본 `inspired`.
-`axes` 표준 키: `color.hue_deg` (도), `color.saturation_pct` (%p), `color.lightness_pct` (%p), `radius.delta_px` (px), `density.shift` (-2 ~ +2), `tracking.shift` (-0.01em ~ +0.01em).
-## Phase 4.5 — Philosophy Layer 입력 수집 (CRITICAL)
-§11 (Brand Narrative), §12 (Principles), §13 (Personas)는 레퍼런스의 검증된 historical facts에 기반. 단순 domain swap하면 거짓 brand claim을 ship하는 사고가 난다.
-Phase 5B 진입 전 사용자에게 한 번에 묻기:
-```
-DESIGN.md의 §11-13 (Brand Narrative / Principles / Personas)에는 사실 정보가 들어갑니다. 다음을 알려주시거나 "skip"이라고 답해주세요:
-1. 프로젝트 이름 / 창립 시점 (대략)
-2. 핵심 thesis 한 문장 (e.g. Airbnb의 "Belong Anywhere")
-3. 공식 tagline 또는 거부하는 카테고리 default
-4. 타겟 사용자 segment 2-4개
-답변 받으면 → §11-13에 반영
-"skip" → §11-13은 [FILL IN: ...] placeholder + omd:limitation 코멘트
-```
-부분 답변은 받은 부분만 사용, 나머지 skip.
-## Phase 5 — Hybrid Variation 생성 (핵심)
-`reference_md` + `.omd/init-context.json` `delta_set`을 입력으로 새 `DESIGN.md` 작성.
-### Phase 5A — Voice Fingerprint 내부 추출 (silent)
-출력 금지. 작성 전 머릿속으로 파악:
-- 평균 문장 길이 밴드
-- 어휘 register (engineering-terse / editorial-warm / clinical / playful 중)
-- 은유 밀도
-- 기술 밀도 (token-heavy / prose-heavy / balanced)
-- 문단 리듬 (list-forward / paragraph-forward)
-Phase 5B emit하는 모든 내러티브를 이 fingerprint에 정확히 맞춰야 한다.
-### Phase 5B — 새 DESIGN.md emit
-**엄격 규칙 (위반 = regression)**:
-1. **Section 구조 frozen**: 레퍼런스의 H2/H3 heading을 같은 순서로 그대로. 추가/삭제/이름 변경 금지.
-2. **Token 값 해석 우선순위** (위에서 아래로):
-   1. `assets/_reference/<id>/tokens.json` `live_overrides` 블록 — **현재 라이브 사이트의 토큰** (omd:reference-capture가 라이브 inspect로 얻은 값). 있으면 이걸 base로.
-   2. `web/references/<id>/DESIGN.md` (또는 `node_modules/.../web/references/<id>/DESIGN.md`) — **DESIGN.md가 brand intent로 기록한 canonical 값**. live_overrides 없으면 이걸 base로.
-   3. `delta_set.axes` — 사용자 customization. base 위에 가산.
-      - 색상: HSL 변환 후 `color.hue_deg` / `saturation_pct` / `lightness_pct` 적용.
-      - radius: `radius.delta_px`만큼 가산 (음수도 가능).
-   - 그 외 토큰은 손대지 말 것. "개선" 금지.
-   - **canonical과 live가 충돌하면** 사용자에게 한 줄로 알림 + 라이브 사용 (예: "Banksalad canonical은 `#04c584` 2px radius, 라이브는 `#13bd7e` 41px pill — 라이브 기준으로 진행합니다. canonical로 가시려면 'use canonical'이라고 알려주세요.").
-   - **단 brand essence (voice·principles·motion philosophy·voice samples)는 canonical 절대 권위.** live는 visual surface(토큰·컴포넌트 shape)에만 적용.
-3. **내러티브는 Phase 5A fingerprint에 매칭**: 도메인 예시 교체 시 문장 길이/register/은유 밀도 그대로. 명사만 swap, 동사/형용사/framing 손대지 말 것.
-4. **새 philosophy 도입 금지**: OmD v0.1 layer, 없던 원칙 추가 금지. delta-derived 노트는 새 bullet으로 넣지 말고 기존 bullet에 자연스럽게 통합.
-5. **해결 불가능 delta는 top-of-file HTML comment**: `<!-- omd:unresolved: <axis> -->` 상단 추가, 해당 token은 건드리지 않음.
-6. **Voice hints 반영**: `delta_set.voiceHints`는 Voice 섹션 내러티브에 반영하되 레퍼런스 voice 스타일 안에서만. "contractions ok" → Voice 원칙 bullet에 한 줄 추가.
-7. **§11-13 처리 분기**:
-   - Phase 4.5에서 정보 제공: 그 정보로 §11/12/13 작성. verbatim 인용은 사용자가 직접 준 표현만. 레퍼런스의 시간 표현·공식 인용 모두 사용자 맥락으로 대체.
-   - Phase 4.5에서 skip: §11-13 본문을 `[FILL IN: <섹션 목적 한 줄>]` placeholder + 각 섹션 상단 `<!-- omd:limitation Reference §X requires project-specific facts. Replace before shipping; do not fabricate. -->`.
-   - §14 (States), §15 (Motion): 일반 Hybrid 적용 (구체 명사만 swap).
-8. **Frontmatter**:
-   ```yaml
-   ---
-   omd: 0.1
-   brand: <Project Name or "Project">
-   bootstrapped_from: <id>
-   bootstrapped_at: <ISO-8601>
-   ---
-   ```
-### Phase 5C — 파일 작성
-Write 툴로 `DESIGN.md` emit.
-## Phase 6 — Shim 설치
-CLI subcommand 없음. 두 가지 옵션:
-**옵션 A (권장)**: omd:sync skill 위임. 같은 conversation에서 Skill 툴로:
-```
-Skill: omd:sync
-args: --force
-```
-omd:sync skill이 `CLAUDE.md`, `AGENTS.md`, `.cursor/rules/omd-design.mdc` shim 3종을 생성/갱신하고 `.omd/sync.lock.json` 업데이트.
-**옵션 B**: omd:sync skill을 호출할 수 없는 환경이면 직접 Write로 shim 작성. 템플릿은 `.claude/skills/omd-sync/SKILL.md` (설치 경로; dev 레포에서는 `skills/omd-sync/SKILL.md`) §"shim body" 참조. 최소한:
-- `CLAUDE.md`: managed block ("<!-- omd:managed:start --> ... <!-- omd:managed:end -->") 안에 DESIGN.md 참조 + 핵심 token 요약
-- `AGENTS.md`: 동일 패턴
-- `.cursor/rules/omd-design.mdc`: 전체 파일 omd 전용 — frontmatter + DESIGN.md 인용
-이후 `.omd/sync.lock.json`에 각 shim의 hash 기록.
-## Phase 7 — 요약 출력
-한 문단으로:
-- Base reference + 프로젝트 context 한 줄 요약
-- 적용된 주요 delta 2-3개 (e.g. "primary hue shifted warm by +12°, radius +4px")
-- 생성된 파일 목록 (DESIGN.md + shims)
-- DESIGN_DEPRECATED.md 있으면 언급
-- 다음 스텝: `omd:apply`로 UI 작업 시작 또는 `omd:harness`로 전체 surface 디자인 또는 `omd:remember`로 선호 추가 로깅
-예시:
-```
-✓ DESIGN.md created (based on banksalad, 한국 핀테크 랜딩 맥락)
-  - primary hue 유지 (#04c584 그대로)
-  - radius 유지 (2px 시스템)
-  - voice hints: 데이터 어드바이저 톤
-Shim files:
-  ✓ CLAUDE.md (managed block)
-  ✓ AGENTS.md (managed block)
-  ✓ .cursor/rules/omd-design.mdc
-Next:
-  - UI 작업 시작 → omd:apply로 자동 라우팅됨
-  - 전체 surface 디자인 (랜딩, 대시보드 등) → omd:harness
-  - 디자인 선호 로깅 → /omd:remember <note>
-```
-## 금지
-- Phase 5A fingerprint를 출력하지 말 것 (내부 전용).
-- `delta_set.axes`에 없는 token을 마음대로 바꾸지 말 것.
-- 레퍼런스에 없는 section/heading을 추가하지 말 것.
-- `.omd/init-context.json`을 직접 편집할 때 schema 어기지 말 것.
-- DESIGN.md가 이미 있는데 백업 없이 덮어쓰지 말 것 (Phase 4.2 rename 절차 준수).
-- **존재하지 않는 CLI subcommand (`omd init recommend`, `omd init prepare`, `omd sync`)를 호출하지 말 것** — 현 CLI binary는 `install-skills`만 제공.

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

@@ -1,299 +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개. 각 preset의 핵심 spec은 아래 **§9 (preset 요약 spec)** 에 self-contained로 수록 — 이 SKILL.md만으로 12개 preset 전부 실행 가능. (풀 9-field spec + verbatim 한국어 examples + 출처는 dev 레포의 `data/research/2026-05-18-kr-style-presets.md` — npx 배포본에는 미포함.)
-| # | 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 선택 시 §9의 해당 preset 요약 spec 룰로 substitution.
-### 전환 매트릭스 (자주 쓰는 6개)
-같은 콘텐츠를 다른 preset으로 옮길 때 standard rewrite 룰 — 아래 핵심 변환 + §9 spec만으로 수행 가능. (확장 5-step rule은 dev 레포 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을 만드는 [이름]이에요.
-100개가 넘는 브랜드의 디자인 시스템을 라이브로 캡쳐해서 카탈로그로 모으고 있어요.
-오늘은 그 중 [브랜드]를 들여다본 이야기를 나누려고 해요.
-```
-### 종결 어미 룰
-| 사용 | 빈도 |
-|---|---|
-| `-요` | **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개
-## 9. Preset 요약 spec (non-default 11개)
-toss-tech-design 외 preset 호출 시 아래 요약 spec이 §1 (voice) / §5 (안티패턴) / §6 (어휘) 룰을 대체한다. 분량은 §0 표의 분량 컬럼, 구조(§2~4)는 preset 성격에 맞게 준용.
-### karrot-neighborly — 당근 동네체
-- register: 해요체 (가끔 "~답니다"/"~지요") · 문장 25~45자
-- opening: "안녕하세요, [동네] 이웃 여러분." / closing: "오늘도 따뜻한 하루 보내세요."
-- 금지: 차가운 비즈니스 한자어("고객", "유저") · 외래어 남발("커뮤니티"보단 "동네") · 단정적 -다 종결
-- 선호: "동네/이웃/우리/근처" lexicon · 다정한 호명("이웃님") · 골목·계절·온도가 묻어나는 묘사어
-### brunch-maker-popular — 브런치 에세이체
-- register: 해요체 80% + 회상 해체 혼용 (1~2문단당 한 번 "-했다") · 문장 40~80자, 시처럼 끊기는 호흡
-- opening: 개인 일화 한 줄 ("그날 저녁, 나는 ~") / closing: 여운 남기는 단문 ("그래서 나는 오늘도 ~.")
-- 금지: 보고서식 bullet · 차트 인용 · 단정적 톤("~해야 한다")
-- 선호: 1인칭 "나"의 일화 · 감각어(냄새·빛·소리) · 단문/만연체 교차 · 은유 · 짧은 의문문("정말 그럴까?")
-### naver-d2-engineering — NAVER D2 기술체
-- register: 하십시오체(-합니다/-입니다) · 문장 40~70자, 명확한 주어-서술 구조
-- opening: "안녕하세요. [팀명] [이름]입니다. 이 글에서는 ~을 다룹니다." / closing: "이 글이 ~ 도움이 되길 바랍니다."
-- 금지: 과도한 1인칭 감정 표현 · 비속어/인터넷 약어 · "~해요" 혼용 (문서 내 통일성)
-- 선호: 정확한 기술 용어 + 영문 병기 · "먼저/다음으로/마지막으로" 구조 신호어 · 코드 블록·도식과 본문 1:1
-### biz-formal-report — 보고서 사무체
-- register: 하십시오체(-합니다) 또는 명사형 종결(-함/-임/-하였음) · 문장 30~55자, 짧고 단정
-- opening: "1. 개요 / 본 보고서는 ~을 목적으로 작성되었습니다." / closing: "이상입니다." / "끝."
-- 금지: 1인칭 "저/우리" 남발 (회사·부서 단위로 대체) · 감정 형용사 · 의문문 · 이모지/외래어 남용
-- 선호: 섹션 번호(1.1, 1.2.1) · 명사형 종결("진행함", "확인됨") · 사무 한자어("검토/보고/회신/추진") · 결론→근거 역피라미드 · 핵심 수치 bold
-### academic-paper — 학술 논문체
-- register: 해라체(-한다/-이다) 평어체 · 문장 50~90자, 복문 빈번
-- opening: "본 연구는 ~을 목적으로 한다." / closing: "후속 연구에서는 ~을 다룰 필요가 있다." / "본 연구의 한계는 ~이다."
-- 금지: 비격식체 · 1인칭 단수("필자"·"본 연구자"로 대체) · 감정 형용사 · 인용 없는 단정
-- 선호: 한자어 비중 높음("선행연구/유의수준/검정") · 수동·피동("측정되었다") · 괄호 인용(저자, 연도) · "따라서/그러나/한편" 접속어
-### journalism-broadsheet — 신문 기사체
-- register: 해라체(-다/-었다) · 문장 35~60자, 리드 문장 명확
-- opening: 리드 = 핵심 사실 한 줄 ("~가 ~했다고 ~일 밝혔다.") / closing: "한편, ~." (배경 정보 마무리)
-- 금지: 1인칭 (기명 칼럼 제외) · "~요/~네요" · 추측만 나열 · 감정 형용사
-- 선호: 5W1H 리드 · 직접 인용("~라고 밝혔다/말했다/강조했다") · 출처 표기("OOO 대표") · "한편/이에 대해/앞서"
-### kakao-warm-product — 카카오 따뜻한 프로덕트체
-- register: 해요체, Toss보다 약간 더 감정적 · 문장 20~40자 (microcopy는 더 짧게)
-- opening: "~ 축하해요!" / "~을(를) 시작해볼까요?" / closing: "오늘도 좋은 하루 보내세요." / "더 알아보기 →"
-- 금지: 비즈니스 한자어("승인/수행/처리" → 부드러운 동사) · 부정·경고 직설("실패/오류" → "다시 시도해볼까요?") · 명령형("입력하시오" → "입력해주세요")
-- 선호: "축하해요/고마워요/함께해요" · "혜택/선물/응원" 어휘 · 짧은 의문문("같이 시작해볼까요?")
-### line-global-saas — LINE 한국어 (cross-locale)
-- register: 하십시오체(-합니다), D2보다 한자어 비중 낮음 · 문장 35~55자, 번역 친화적 단순 구조
-- opening: "이 글에서는 ~을 소개합니다." / "안녕하세요, LINE의 ~입니다." / closing: "감사합니다." / "다음 글에서 ~을 이어 다루겠습니다."
-- 금지: 한국 내수 전용 비유·시사 (동시 번역 시 문제) · 4자 숙어("일석이조") · 비격식체
-- 선호: SVO 단순 구조·능동태 · 영문 약어 병기("LINE 디자인 시스템(LDS)") · terminology 통일 · 중립 호명("독자/사용자")
-### academic-lecture-essay — 교양 강연체
-- register: 해요체 우세 + 학술 한자어 자유 혼용 · 문장 40~70자, 강의처럼 호흡 길게
-- opening: "여러분, ~을 한 번 생각해볼까요?" / closing: "결국 ~인 거죠." / "그래서 저는 ~라고 생각해요."
-- 금지: 보고서식 bullet · 인용 없는 단정
-- 선호: "~인 거죠/~라는 거예요" · 청자에게 묻는 구조("그렇다면 왜 그럴까요?") · 비유와 일상 예시 · 학문 한자어 즉시 풀이("엔트로피, 그러니까 무질서의 정도")
-### emotional-brand — 패션 커머스 트렌디체
-- register: 해요체 + 체언/명사 종결 자유 혼용("오늘의 픽.") · 헤드라인 15~30자, 본문 40자 내외
-- opening: 명사형 후크 ("이번 주의 무드." / "여름밤, 우리가 입어야 할 것.") / closing: "지금, [브랜드]에서." / "더 보기 →"
-- 금지: 보고서 한자어 · "~합니다" 일변도 (브랜드 거리감) · 길고 설명적인 문장
-- 선호: 외래어·영문 자유("무드/감도/베이직/에디트") · 컬러·재질·실루엣 어휘 · 시즌·시간성 cue("이번 주/오늘 밤/5월의") · 짧은 명령형("입어볼 것.")
-### legal-disclosure — 법무 약관체
-- register: 하십시오체(-합니다) 우세 + 명사 종결("~함") · 문장 50~100자, 의도적으로 길고 한정조건 빽빽
-- opening: "본 약관은 ~을 규정함을 목적으로 합니다." / "제1조 (목적)" / closing: "본 약관은 ~일부터 시행합니다." / "부칙. ~"
-- 금지: 1·2인칭 친밀 표현 · 비격식체 · 감정 형용사 · 모호한 수식("좀", "약간")
-- 선호: "~합니다/~됩니다/~할 수 있습니다" · 수동·피동("간주됩니다/처리됩니다") · 정의 조항("이 약관에서 사용하는 용어의 정의는 다음과 같습니다.") · 법률 한자어("의무/책임/면책/준수") · 조·항·호 번호 체계
----
-이 스킬은 oh-my-design 블로그 한국어 본문의 **단일 source of truth voice guide**. 모든 KR 글은 이 guide를 따른다.