Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

omd-lab-02-design-harness

Étoiles334

Forks29

Mis à jour3 mai 2026 à 08:02

OmD Lab

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

kwakseongjae

kwakseongjae/oh-my-design

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

Explorateur de fichiers

54 fichiers

SKILL.md

readonly

name	omd-lab-02-design-harness
description	OmD Lab

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)

playbooks/v<N>.md 작성. 가설을 한 줄로:

## Hypothesis
v2 raises persona ABANDON budget from 3s → 5s, expecting fewer false-abandon and more useful friction signal.

v이 v과 바꾸는 것 정확히 명시. 1개 변수만 바꾸는 게 원칙.
변경 점이 sub-agent 프롬프트에 있으면 playbooks/v<N>/agents-overrides/*.md로 patch 보관.

Lab Run 실행

# 운영자가 수동 실행
omd harness "<task>" --lab v2
# 또는 사용자가 자연어:
# "이 task를 lab v2 설정으로도 돌려서 v1과 비교해줘"

--lab v<N>이 들어오면:

runs/v<N>-run-<ts>-<slug>/ 디렉토리에 산출물 적재
v의 agent overrides가 있으면 그걸 임시로 .claude/agents/에 덮어씌운 채 실행 (run 종료 시 원복)
run.log에 lab_version: v<N> 기록

비교 뷰 생성

운영자가 동일 task에 대해 v1, v2, ..., vN의 run을 끝내면:

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 정의

{
  "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.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.md 선행)
동일 task의 동일 v 결과를 덮어쓰지 X (timestamp로 보존)
runs/ 정리 X (영구 보존)

Plus depuis ce dépôt

même dépôt

omd-add-reference

kwakseongjae/oh-my-design

URL 또는 brand id 입력 → 3-tier 검증 파이프라인(Tier 1 라이브 + Tier 2 getdesign/refero + Tier 3 reconcile)으로 references/<id>/DESIGN.md를 신규 생성(CREATE)하거나 기존 섹션을 검증·갱신(UPDATE). '레퍼런스 추가/수정', 'X DS 검증', 'X 컴포넌트 다시 뽑아줘' 류에 트리거.

2026-07-14334

omd-add-reference

kwakseongjae/oh-my-design

2026-07-14334

omd-migrate

kwakseongjae/oh-my-design

단일 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' 류에 트리거.

2026-07-14334

omd-reference-capture

kwakseongjae/oh-my-design

선택된 reference brand의 라이브 사이트에서 디자인 컨텍스트(토큰·구조·visual reference)를 캡쳐. brand homepage 패칭, 컴퓨티드 스타일 inspect, 로고/스크린샷을 assets/_reference/<id>/ 로 가져와 attribution.md + LICENSE-NOTE.md와 함께 저장. '뱅크샐러드 에셋 가져와줘', 'X 사이트 패칭', 'X reference 캡쳐', 'X 라이브 스타일 추출', '브랜드 자료 받아와' 류 요청에 트리거. omd:init 직후 또는 omd:harness 중간에 호출 가능. DESIGN.md는 이 스킬이 만들지 않음 (omd:init 책임).

2026-07-14334

omd-feel

kwakseongjae/oh-my-design

디자인·프론트 업계가 '감'으로 쓰던 인터페이스 디테일을 수치화한 규칙으로 적용(APPLY)하거나 감사(AUDIT)한다. Jakub Krehel의 make-interfaces-feel-better 철학을 계승 + HIG/Material/WCAG/DS 토큰/실무자 리서치로 확장한 17축·113규칙(provenance 등급별). 모션 타이밍·이징·동심원 radius·tabular-nums·44px 타깃·focus ring·prefers-reduced-motion 등. 'feel 좋게 다듬어줘', '인터페이스 디테일 적용', 'feel 점검', '마이크로 인터랙션 손봐줘', 'make this feel better', 'polish the interactions', 「インターフェースの細部を詰めて」, 「介面細節打磨」 류에 트리거. 브랜드 토큰은 DESIGN.md(omd:apply)가 우선.

2026-06-23334

omd-harness

kwakseongjae/oh-my-design

화면 전체나 신규 surface를 처음부터 디자인할 때의 진입점 — Discovery→Wireframe→Components→Microcopy→Validation 파이프라인을 omd-master 오케스트레이터로 실행. 트리거: '랜딩페이지', '랜딩 페이지', '랜딩 만들어줘', '홈 화면', '첫 화면', '프로토타입', '그럴싸한', '구색 갖춰', 'first screen', 'first impression', 'landing page', 'landing', 'prototype', 'MVP UI', 'home', 'production-ready', 'wireframe to production', '랜딩 처음부터', 'production-ready', '一からデザイン', '從頭設計'. 자연어 발화('그럴싸한 랜딩 만들어줘', 'MVP UI 잡아줘', '프로토타입이라도 구색 갖춰서')에도 자동 트리거. 단일 컴포넌트 수정은 omd:apply.

2026-06-22334

name	omd-lab-02-design-harness
description	OmD Lab

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)

playbooks/v<N>.md 작성. 가설을 한 줄로:

## Hypothesis
v2 raises persona ABANDON budget from 3s → 5s, expecting fewer false-abandon and more useful friction signal.

v이 v과 바꾸는 것 정확히 명시. 1개 변수만 바꾸는 게 원칙.
변경 점이 sub-agent 프롬프트에 있으면 playbooks/v<N>/agents-overrides/*.md로 patch 보관.

Lab Run 실행

# 운영자가 수동 실행
omd harness "<task>" --lab v2
# 또는 사용자가 자연어:
# "이 task를 lab v2 설정으로도 돌려서 v1과 비교해줘"

--lab v<N>이 들어오면:

runs/v<N>-run-<ts>-<slug>/ 디렉토리에 산출물 적재
v의 agent overrides가 있으면 그걸 임시로 .claude/agents/에 덮어씌운 채 실행 (run 종료 시 원복)
run.log에 lab_version: v<N> 기록

비교 뷰 생성

운영자가 동일 task에 대해 v1, v2, ..., vN의 run을 끝내면:

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 정의

{
  "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.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.md 선행)
동일 task의 동일 v 결과를 덮어쓰지 X (timestamp로 보존)
runs/ 정리 X (영구 보존)