Run any Skill in Manus with one click

Get Started

omd-lab-02-design-harness

Stars324

Forks27

UpdatedMay 3, 2026 at 08:02

OmD Lab

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

kwakseongjae

kwakseongjae/oh-my-design

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

54 files

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 (영구 보존)

More from this repository

same repository

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-23324

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-22324

omd-init

kwakseongjae/oh-my-design

프로젝트 루트에 DESIGN.md를 부트스트랩 — 실제 기업 레퍼런스 중 컨텍스트 매칭으로 추천하고 선택된 레퍼런스의 톤&매너를 보존한 variation을 생성. DESIGN.md 부재 상태에서의 UI 작업 또는 '디자인 시스템 세팅', 'set up our design system', 「デザインシステムを作って」, 「建立設計系統」류의 요청에 트리거. CLAUDE.md / AGENTS.md / Cursor rule shim도 함께 설치.

2026-06-22324

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-06-22324

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-06-10324

omd-batch-launch

kwakseongjae/oh-my-design

10개 brand 일괄 reference 추가 + 문서 카운트 sync + hyperframes 기반 promo MP4 생성. '10개씩 추천해줘', '한국 IT 10개 추가하고 영상까지', 'batch-launch', 'X 카테고리에서 10개 더' 류 트리거. 매 회 reference count +10, gitignored promo video 1편.

2026-06-10324

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 (영구 보존)