comparison-lab

이 스킬이 하는 일

"X에 대한 몇 가지 옵션을 비교해줘"라는 요청을 실제로 작동하는 도구로 바꿉니다. 진정으로 독립적이고 연구에 기반한 여러 변형안을 생성하고, 각각을 하나의 공유 가능한 비교 보드에 패널로 렌더링하여 사람이 비교하고, 우승자를 선택하고, 피드백을 남길 수 있도록 합니다. 선택과 피드백은 다시 여러분에게 돌아오고, 우승한 변형안을 더욱 발전시킵니다.

이는 모든 것에 적용됩니다: 대체 솔루션 접근법, UI/컴포넌트 디자인, 테스트/평가 전략, 생성된 미디어(코드, 이미지, 오디오, 텍스트). 보드는 의존성이 없는 독립형 HTML 파일이므로 어떤 프로젝트에든 바로 넣을 수 있습니다.

$ARGUMENTS는 비교할 대상입니다. 모호하다면(무엇을 비교하는지, 어떤 차원을 변경하는지, 어떤 주제에 대해), 생성 전에 1-2개의 명확한 질문을 던지십시오.

핵심 원칙 (기본 중의 기본 — 절대 건너뛰지 마세요)

1. 진정하고 독립적인 변형안 — 단순한 파라미터 조정이 아닙니다. 각 변형안은 실제로 이름이 있는 기술입니다. 두 변형안이 오직 파라미터 값만 다르다면, 이는 하나의 접근법을 두 번 샘플링한 것에 불과합니다 — 하나로 통합하세요. 테스트: 두 변형안을 같은 문장으로 설명할 수 있고 숫자만 바꾼다면, 독립적이지 않습니다.
2. 연구 자체가 교정 단계입니다. 해당 도메인에 문헌이나 확립된 관행이 있다면, 변형안을 설계하기 전에 실제 이름이 있는 기술들을 조사하세요 — WebSearch / 문서 / references/를 사용하세요. 상상력으로 메뉴를 추측하면 과하거나 부족합니다. (참고: reference.md §1의 도메인별 연구 프롬프트)
3. 통제된 비교. 모든 입력값을 고정하세요; 오직 테스트 대상 차원만 변경합니다. 한 행의 모든 카드에 걸쳐 동일한 시드/시나리오/프롬프트/사본을 사용합니다. 행의 목표에 고정된 입력값을 명시하세요. 한 행 = 하나의 변경된 차원입니다.
4. 객관적인 뱃지. 측정 가능한 모든 것에 대해 패널당 색상으로 구분된 지표 뱃지를 첨부하세요 (목표로부터의 거리, 통과율, 지연 시간, 번들 크기, 대비 비율, ...). 그래야 선택이 감이 아닌 증거에 기반합니다.
5. 혼동 변수 분리 — 하나의 결과물에 대한 여러 관점. 동일한 출력물의 여러 관점을 볼 가치가 있다면, 카드에 content.views 토글을 제공하세요 (예: Notation / Piano-roll / Audio / Raw / Diff). 전형적인 예는 RAW vs PROCESSED입니다 — 가공된 결과물 옆에 원본 결과물을 렌더링하여 사람이 번역/색상 변환/정규화/직렬화/압축 파이프라인의 어떤 단계가 나쁜 결과를 초래했는지 알 수 있게 합니다; content.raw는 이를 위한 2-뷰 단축키입니다. 절대 가짜 토글을 만들지 마세요. 진정으로 차이가 있을 때만 뷰를 추가하세요 — 가공된 결과와 원본 결과가 동일하다면 (충실한 변환), 토글을 제거하세요. 아무 효과 없는 토글은 없는 것보다 나쁩니다; 보드는 바이트가 동일한 뷰를 자동으로 축소하고, 뷰가 1개 이하이면 토글을 자동으로 숨깁니다.
6. 지표 vs 결과물 정직성. 실제 결과물을 지표 뱃지 옆에 렌더링하고 불일치를 드러내도록 하세요. 표기법에 분명히 낮춰진 3도가 있는데 "거리" 뱃지가 0이라면, 그 모순이 바로 발견입니다 — 지표가 무언가를 무시하고 있다는 뜻입니다. 이를 표면화하는 것이 핵심입니다; 숫자 뒤에 결과물을 숨기거나 숫자를 결과물에 맞추려 하지 마세요.
7. 실제 콘텐츠 게이트. 모든 패널은 실제 출력을 보여줍니다 — 절대 스텁, 플레이스홀더, 바이트 크기 확인이 아닙니다. 실제 콘텐츠가 렌더링되는지 확인하세요. 오디오의 경우, 콘텐츠가 실제로 들려야 합니다 — 샘플 소스를 차단한 상태에서 확인합니다 (reference.md §9 오프라인 게이트) — 단순히 렌더링만 되어서는 안 됩니다.
8. 하나의 공유 가능한 표면. 흩어진 결과물이 아닌, 사람이 열 수 있는 단일 보드(파일 또는 링크)를 출력하세요.
9. 체크포인트 규율. 가장 위험/대표성이 높은 조각을 먼저 구축하세요 (한 주제, 한 행, 실제 콘텐츠 + 해당되는 경우 오디오/재생 포함). 모든 차원으로 확장하기 전에 사람에게 보여주고 피드백을 받으세요.
10. 루프를 닫으세요. 사람이 보드에서 직접 우승자를 선택하고 피드백을 남깁니다; 그 내보내기가 다시 여러분에게 돌아와 개선 작업을 하게 합니다. 그런 다음 우승자를 심화시키세요.
11. 주제별 우승자 + 융합. 최적의 변형안이 주제별로 다를 때, 주제별 우승자를 표면화하고 우승 특성을 결합하는 융합/종합 라운드를 추가하세요. 하나의 전역 우승자를 강제하지 마십시오. 여러 주제를 사용하는 이유는 단일 접근법이 모든 곳에서 우승하는 경우가 드물다는 점을 드러내기 위해서입니다 — 이를 평균화하여 없애지 말고 존중하세요.

워크플로우

1. 비교 대상을 명확히 하세요. $ARGUMENTS에서 다음을 확정하세요: 비교 대상, 행별로 변하는 단일 차원, 통제된 주제/시드 (2개가 기본값). 진정으로 모호한 경우에만 질문하세요.

2. 실제 변형안을 조사하세요. 해당 도메인에 확립된 기술이 있다면 먼저 찾아보세요 (reference.md §1에 연구 프롬프트가 있습니다). 행당 2-6개의 이름이 있는, 진정으로 독립적인 접근법의 짧은 목록을 만드세요. 파라미터만 다른 두 개는 거부하세요.

3. 각 변형안에 대한 실제 콘텐츠를 생성하세요. 각 (주제, 행, 변형안)에 대해 실제 결과물을 생성하고 콘텐츠 종류를 선택하세요: html (UI/텍스트), code, image, iframe, audio (WebAudio 합성 포함), 또는 passfail (테스트/평가). reference.md §2의 양식 테이블을 참조하세요. 하나의 출력에 대해 여러 관점을 제공하려면 content.views를 명명된 뷰 목록으로 설정하세요 (첫 번째가 기본값; 동일한 뷰는 축소되고, 토글은 1개 이하일 때 자동으로 숨겨집니다) — 또는 파이프라인이 진실을 숨길 수 있는 경우 content.raw 2-뷰 단축키를 사용하세요 (원칙 5). 측정 가능한 곳에는 객관적인 badges를 첨부하고, 실제 결과물 옆에 표시하여 모순이 드러나도록 하세요 (원칙 4, 6).

실제 도메인 결과물 렌더링 (악보, 차트, 다이어그램): 안정적인 경로는 헤드리스 페이지에서 <svg>로 렌더링한 후, svg.outerHTML을 가져와 html 콘텐츠 종류로 임베드하는 것입니다 (인라인 SVG — <img> data-URI가 아닙니다. data-URI는 SVG 네임스페이스를 잃어버려 깨져서 렌더링됩니다). 글리프 렌더러(예: VexFlow/Bravura)는 렌더링 페이지와 보드 모두에 base64 @font-face로 폰트를 인라인해야 하며, 렌더링 및 스크린샷 전에 document.fonts.ready를 기다려야 합니다. template/render-artifacts.example.mjs는 이를 위한 복사-적응용 하네스입니다; reference.md §6에 전체 레시피와 주의사항이 있습니다.

4. 템플릿에서 보드를 빌드하세요. template/comparison-lab.html을 프로젝트에 복사하세요 (서빙 가능한 곳, 또는 file:// 사용을 위해 아무 곳에나). template/README.md의 스키마를 사용하여 그 옆에 data.json에 데이터셋을 작성하세요. 새로운 UI를 직접 만들지 마세요 — 템플릿이 이미 포스트잇 보드, 뱃지, 토글, 버튼, 내보내기를 제공합니다.

• http(s)로 서빙: data.json이 자동으로 가져와집니다.
• 더블 클릭 (file://): HTML의 <script id="inline-data"> 블록에 데이터셋을 붙여넣으세요 (형제 파일 가져오기는 file://에서 차단됩니다).

5. 실제 콘텐츠가 렌더링되는지 확인하세요. 보드를 열고 모든 패널에 실제 출력(플레이스홀더가 아님)이 표시되는지, 뱃지에 색상이 있는지, views/raw 토글이 있는 곳에서 작동하는지 (그리고 진정한 두 번째 뷰가 없으면 토글이 없는지), Pick/Feedback/Export가 작동하는지 확인하세요. 헤드리스 브라우저에 접근할 수 있다면 스크린샷을 찍으세요 — 폰 너비에서도 찍으세요 (보드는 모바일 우선입니다). 초안처럼 보이는 부분을 수정하세요.

6. 체크포인트 — 가장 위험한 조각을 공유하세요. 첫 번째 주제/행이 완전히 구축된 보드(링크 또는 파일)를 사람에게 건네주세요. 나머지로 확장하기 전에 피드백을 받으세요. 이것이 원칙 9입니다 — 조용히 모든 것을 만들지 마세요.

7. 선택 수집 + 우승자 심화. 사람이 우승자를 선택하고 메모를 남긴 후 Export picks + feedback(Markdown 또는 JSON)을 클릭합니다. 이를 다시 가져와 선택된 변형안을 심화시키세요 — 선택한 것을 개선, 강화, 또는 프로덕션 수준으로 만드세요.

보드 UI (템플릿이 제공하는 것)

깔끔한 화이트 보드에 포스트잇 카드 — 고대비 검은색 텍스트, 미묘한 그림자, 카드당 파스텔 색상 헤더 스트립, 반듯하고 정렬됨. 실제 포스트잇/칸반 보드에 맞춰 보정됨.

• 헤더: 제목, 고정된 소개, 주제/시드 전환기 (통제된 입력을 변경하는 버튼), 뱃지 범례, Reset, Export picks + feedback.
• 각 카드 (포스트잇): 변형안 레이블, 한 줄짜리 기술 설명, 일반 콘텐츠 슬롯 (인라인 HTML/SVG, <img>, 샌드박스 <iframe>, <audio>/합성, <pre><code>, 또는 합격/불합격 체크리스트 렌더링 — 데이터에 따라 결정됨), 색상으로 구분된 지표 뱃지, 데이터가 content.views 또는 content.raw를 제공할 때 선택적 명명된 뷰 토글 (알약 행).
• 카드당 버튼: ★ Pick (우승자 하이라이트 전환), ✎ Feedback (인라인 메모), 활성 뷰를 따르는 콘텐츠 액션 (▶ Play, ⤢ Open, ⧉ Copy).
• Export는 사람의 선택 + 메모를 복사 가능한 Markdown 또는 JSON으로 덤프합니다. 선택 + 메모는 localStorage에 유지됩니다.
• 제로 의존성, 제로 네트워크 — 파일을 열기만 하면 작동합니다. 모바일 우선: 폰에서 카드는 한 열로 축소되고, 탭 대상은 ≥40px이며, 주제 전환기는 고정 헤더에서 접근 가능하고, 본문 텍스트는 읽기 쉽습니다. 마우스 및 터치에 친화적이며, reduced-motion을 존중합니다.

파일

파일	목적
template/comparison-lab.html	보드. 자체 포함 (인라인 CSS + vanilla JS), 모바일 우선. 있는 그대로 복사하세요; 다시 만들지 마세요.
template/data.sample.json	일반성을 증명하는 작동 데이터셋 (html, code, passfail, image+raw, N-뷰 content.views 토글, 2개 주제에 걸친 오디오). 복사 → data.json, 편집.
template/render-artifacts.example.mjs	실제 도메인 결과물(악보/차트/다이어그램)을 보드로 렌더링하기 위한 복사-적응용 하네스 — 렌더러 번들, 글리프 폰트 인라인, 헤드리스에서 인라인 SVG 추출, 주입 및 스크린샷. ADAPT THIS 블록을 편집하세요.
template/README.md	data.json 채우는 방법; 전체 스키마, 필드별 설명 (content.views 포함); 내보내기 형식.
reference.md	변형안 설계 심층 분석 + 도메인별 연구 프롬프트 (§1), 양식 렌더링 테이블 (§2), 뱃지 (§3), 스키마 포인터 (§4), 원본-대-가공 이야기를 포함한 실제 음악 예제 (§5), 실제 결과물 렌더링 + 헤드리스 하네스 (§6), content.views 스키마 + 지표-대-결과물 교훈 (§7), 모바일 우선 체크리스트 (§8).

참고 사항

• 이는 (브레인스토밍과 같은) 접근 방식 스킬입니다 — 슬래시 호출 가능 그리고 모델 호출 가능합니다. disable-model-invocation을 설정하지 마세요.
• HTML 템플릿을 그대로 복사하세요 — 모든 UI 작업은 완료되었습니다. 여러분의 작업은 데이터입니다: 진짜 변형안 + 실제 콘텐츠 + 뱃지.
• 거의 동일한 변형안으로 가득 찬 보드를 제공하지 마세요. 각 변형안을 독립적인 기술로 명명할 수 없다면 2단계를 수행하지 않은 것입니다.
• 콘텐츠를 위조하지 마세요. 플레이스홀더 패널은 목적을 무효화합니다 (원칙 7).
• 효과 없는 토글을 제공하지 마세요. 진정으로 차이가 있을 때만 views/raw 뷰를 추가하세요 — 동일한 뷰는 자동으로 축소되지만, 실제 차이를 위해 설계하세요 (원칙 5).
• 더 큰 대화형 미리보기의 경우, 거대한 html 문자열보다 srcdoc이 있는 iframe을 선호하세요. 렌더링된 SVG의 경우, <img> data-URI가 아닌 html 종류를 통해 임베드하세요 (reference.md §6).
• 생성된 미디어는 인라인(data: URI, WebAudio 합성)으로 유지하여 보드가 단일 공유 가능한 오프라인 파일로 남도록 하세요.