designloop

designloop은(는) 무엇을 하나요?

기존 인터페이스 또는 그 주변의 글쓰기 품질을 추측이 아닌 측정을 통해 향상시키는 루프입니다. 각 라운드: 동일한 방식으로 UI를 캡처(또는 텍스트 스냅샷)하고, 새로운 평가자가 고정된 루브릭에 따라 점수를 매기고, 발견된 문제를 수정한 후 반복합니다. 이는 dream-loop의 평가 방법(라운드마다 새로운 평가자, 깐깐하게 평가, 회귀는 낮은 점수)을 대상 이미지 일치 대신 UI 폴리쉬에 적용한 것과, Theo(t3.gg)의 Agents Sucked At UI (Until Today)에서 소개한 UI 디자인에 대한 언덕 오르기 접근 방식을 모델로 합니다.

루프는 세 가지 분리 원칙 덕분에 작동합니다. 이를 유지하십시오:

• 평가자는 절대 구현하지 않고, 구현자는 절대 평가하지 않습니다. 수정 사항을 작성한 에이전트는 관대하게 점수를 매깁니다.
• 각 라운드마다 평가자는 새로운 인물입니다. 이전 라운드를 본 평가자는 자신의 이전 평결에 고정됩니다. 새로운 평가자에게 루브릭, 새로운 캡처 및 이전 평결(점수 일관성을 유지하고 회귀를 명명하기 위해)을 제공하고, 대화 내용은 제공하지 마십시오.
• 캡처 세트는 고정됩니다. N 라운드가 0 라운드와 동일한 표면, 상태 및 테마를 보여주는 경우에만 점수를 비교할 수 있습니다.

세 가지 모드

루프 자체는 세 가지 모드 모두 동일합니다. 평가자가 측정하는 기준이 다를 뿐입니다. 먼저 모드를 결정하십시오. 모드는 루브릭, 물어볼 질문 및 예상되는 변경량을 결정하기 때문입니다.

• Professional Polish — 객관적인 패스, 시니어 제품 디자이너가 확인하는 사항: 모든 곳에서 사용되는 일관된 토큰 및 표면, 더 적은 수의 글꼴 크기 및 두께, 일관된 간격 척도, 가독성 및 대비, 히트 타겟 및 커서 영역, 상태 커버리지, 라이트/다크 패리티, 모션 품질. 목표는 앱 자체의 최고의 모습입니다. 취향 변경은 해당되지 않습니다. references/mode-polish.md를 읽으십시오.
• Art Direction — 특정 디자인 방향을 향한 주관적인 패스: 명명된 스타일("그래픽 리얼리즘", "ASCII 아트와 브루탈리스트, 다이나믹 레이아웃이 있는 네온 팝"), 참조 세트, 생성된 대상 이미지 또는 일치시킬 Figma 디자인. 평가자는 UI가 해당 방향을 얼마나 잘 표현하는지 점수를 매깁니다. 더 큰 시각적 변화가 예상되므로 글꼴, 색상 및 레이아웃 특성이 고려 대상입니다. references/mode-art-direction.md를 읽으십시오.
• Writing — 단어에 적용된 루프: UI 카피(레이블, 오류, 빈 상태, 온보딩), 문서 및 제품 페이지, 또는 독립적인 글. 평가자는 명확성, 간결성, 어조, 일관성 및 정확성을 기준으로 특정 독자를 위해 점수를 매기며, 독자 테스트(새로운 에이전트가 텍스트를 처음 읽고 무엇을 할지 말함)가 뒷받침됩니다. 의미는 고정되고 단어는 개선됩니다. references/mode-writing.md를 읽으십시오. 이 파일은 아래 각 단계가 어떻게 변경되는지(표면 대신 텍스트, 캡처 대신 스냅샷, 토큰 대신 용어집) 설명합니다.

요청이 명확하면 모드를 유추하십시오. ("tighten", "consistent", "sloppy" → Polish; "make it look like", "more artistic", 스타일 이름, Figma 링크 → Art Direction; "copy", "wording", "docs", "error messages", "this post" → Writing). 그렇지 않으면 물어보십시오. 사용자는 두 가지 이상을 원할 수 있습니다. 먼저 Art Direction을 실행하여 디자인을 설정한 다음, Polish 패스로 일관성을 유지하고, 카피에 대한 Writing 패스를 각각 고유한 루브릭을 가진 별도의 루프로 실행하십시오. 하나의 루브릭에 혼합하지 마십시오. 그렇지 않으면 평가자가 일관성과 스타일을 서로 교환하게 되어 점수가 의미를 잃게 됩니다.

1단계: 사용자 인터뷰

모드를 결정한 후, AskUserQuestion(두 번의 호출, 각각 최대 4개의 질문)을 사용하여 나머지를 물어보십시오. 사용자의 메시지가 이미 답변한 질문은 건너뛰고, 먼저 권장 옵션을 제시하십시오. 답변은 브리프 파일(3단계)에 저장되며, 모든 하위 에이전트가 읽는 파일입니다.

1. 목표(Goal) — 이 작업이 완료되었을 때 무엇이 더 나아져야 하는지, 사용자의 말로 표현하십시오. ("Chrome feels inconsistent", "menus are sloppy", "feels janky".) 또한 금지 사항: 사용자가 직접 처리하려는 표면, 허용되는 변경량( tighten vs. restyle vs. redesign). 대부분의 사용자는 리디자인이 아닌 개선(tightening)을 원합니다. 모든 브리프에서 이를 언급하지 않으면 구현자가 지나치게 개선할 수 있습니다.
2. 집중 영역(Focus) (다중 선택) — 가장 중요한 차원은 무엇입니까? 이는 루브릭 가중치를 설정합니다. 옵션은 모드에 따라 다르며 해당 참조 파일에 나열됩니다. (Polish: 일관성 및 토큰, 타이포그래피, 간격 및 레이아웃, 가독성, 상호작용 및 히트 타겟, 모션, 성능; Art Direction: 선택한 디자인의 특성 및 UI의 어느 부분이 이를 반영해야 하는지; Writing: 명확성, 간결성, 구조, 어조 및 톤, 일관성, 유용성, 정확성). Writing 모드에서는 references/mode-writing.md의 추가 질문(독자와 목적, 어조 샘플, 고정된 사항, 길이 및 현지화 제한)도 물어보십시오.
3. 기준선(Baseline) — 오늘날 UI의 상태는 어떻습니까? 사용자가 10점 만점에 점수를 주거나, 평가자가 먼저 점수를 매깁니다. 사용자가 의견이 있을 경우 두 가지를 모두 수행하는 것을 권장합니다. 사용자의 숫자는 평가자를 보정합니다. (사용자가 6점이라고 하고 평가자가 8점이라고 하면 루브릭이 너무 관대한 것입니다. 1라운드 전에 강화하십시오.)
4. 중단 조건(Stop condition) — 목표 점수(예: 모든 그룹 및 테마에서 ≥9/10), 라운드 수, 또는 먼저 도달하는 조건. "N 라운드로 제한된 목표 점수"를 권장합니다. 무제한 루프는 많은 토큰을 사용할 수 있음을 경고하십시오.
5. 하위 에이전트 지능(Subagent intelligence) — 평가자와 구현자가 어떤 모델과 노력(Effort)으로 실행될지 결정합니다. 옵션: 최고 가용(가장 느리지만 가장 철저함), 균형(세션 자체 모델 및 노력), 빠름(캡처 및 기계적 수정에는 저렴한 모델, 평가에는 강력한 모델). 평가는 지능이 가장 중요한 부분입니다. 사용자가 비용을 절약하려면 캡처 및 기계적 구현부터 절약하십시오.
6. 참조(References) — 사용자가 좋아하거나 일치시켜야 하는 디자인이 있습니까? 웹사이트, 앱, 스크린샷, Figma 링크, 디자인 시스템, 또는 명명된 가이드라인 또는 스킬(플랫폼 HIG, 디자인-엔지니어링 스킬). 각각에 대해 사용자가 무엇을 좋아하는지 물어보십시오(밀도, 메뉴, 모션). 이유 없이 "이 사이트처럼"이라고 하면 전체가 복사됩니다. Polish 모드에서 참조는 선택 사항이며 일반적으로 가이드라인입니다. Art Direction 모드에서는 루프에 대상이 필요합니다: 스타일 설명, 참조, Figma 디자인 또는 생성된 이미지. 사용자가 없는 경우, 수집 또는 생성하겠다고 제안하십시오("참조 및 대상" 참조).
7. 전달(Delivery) — 브랜치만, PR(병합되지 않음), 및/또는 실행 가능한 빌드. 기본값: 브랜치 + 병합되지 않은 PR. 사용자가 요청하지 않는 한 절대 병합하거나 릴리스하지 마십시오.

사용자가 제공한 모든 내용을 .designloop/references/(3단계)에 넣고 루브릭에 나열하여 모든 평가자와 구현자가 동일한 소스에서 작업하도록 하십시오.

2단계: 프로젝트 설정 연구

규칙을 작성하기 전에 이 프로젝트가 실제로 어떻게 실행, 테스트 및 배포되는지 알아내어, 루프가 자체적인 방식을 강요하지 않고 사용자의 습관을 따르도록 하십시오. 먼저 살펴보고, 그 다음 물어보십시오. 저장소와 머신이 알려줄 수 있는 것을 읽고, 여전히 불분명하거나 선호도의 문제인 것에 대해서만 물어보십시오.

다음을 찾으십시오:

• 이미 작성된 지침: CLAUDE.md / AGENTS.md, README 및 CONTRIBUTING, 메모리 노트, 및 이전 에이전트 규칙 파일. 이는 추론된 것보다 우선합니다.
• 앱이 실행되는 방식 및 구동 방법: package scripts, Makefile, dev vs. production 빌드, 및 앱을 캡처할 수 있는 것(브라우저/CDP, Playwright, 시뮬레이터 또는 디바이스 도구, 기존 스크린샷 또는 e2e 설정). 앱을 자동으로 구동할 수 있는 것이 없으면 그렇게 말하고 사용자에게 캡처 방법을 물어보십시오.
• 프로젝트가 신뢰하는 검사: 타입 체크, 린트, 테스트, 빌드, 및 현재 통과하는지 여부.
• Git 습관: 기본 브랜치, 브랜치 명명 규칙, worktree가 이미 사용 중인지, 커밋 메시지 규칙, 작업이 PR을 통해 이루어지는지 여부.
• 실행이 저장소 외부에서 건드릴 수 있는 것: 실제 계정, 유료 API 또는 AI 백엔드, 메시징, 프로덕션 데이터, 사용자 자신의 앱 프로필 또는 디바이스. 목(mock), 데모 또는 샌드박스 모드가 있는지 확인하십시오.
• 디자인 도구가 연결되었는지: 사용자가 Figma 링크(또는 다른 디자인 도구 링크)를 제공한 경우, 이를 읽을 수 있는 Figma 커넥터 또는 MCP 서버가 있는지, 로그인되어 있는지 확인하십시오.
• 여기서 이미지를 생성할 수 있는지: 이 세션이 실제로 호출할 수 있는 것을 확인하고 가정하지 마십시오. 일부 도구 모음에는 이미지 생성 기능이 내장되어 있습니다(Codex). 다른 도구 모음에서는 설치된 스킬, 플러그인 또는 MCP 서버(Higgsfield 또는 다른 이미지 모델)에서 제공됩니다. 사용 가능한 도구와 스킬을 살펴보십시오. 없으면 루프는 여전히 작동합니다. 대상 이미지는 선택 사항입니다.
• 병렬 작업에 중요한 머신 제한: 사용 가능한 디스크 공간, 이미 사용 중인 포트, 실행 중인 다른 에이전트 또는 개발 서버.

그런 다음, 찾은 내용으로 해결할 수 없었던 선택 사항에 대해서만 한 번의 AskUserQuestion 호출로 사용자와 확인하십시오. 일반적인 사항:

• 작업 위치: 현재 브랜치, 새 브랜치, 또는 구현자별 별도 worktree(구현자가 병렬로 실행되는 경우 필요).
• 테스트 방법: 개발 서버만, 또는 완료 전에 프로덕션/패키징된 빌드도 포함; 어떤 테마, 창 크기 또는 디바이스가 포함되는지.
• 건드리거나 사용해서는 안 되는 것: 실제 계정 및 유료 서비스, 캡처에 목(mock) 모드가 허용되는지 여부.
• 한 번에 얼마나 많이 실행할지: 병렬 구현자 또는 한 번에 하나씩.

질문에서 추론한 내용을 명시하십시오("X를 찾았으므로 Y를 계획합니다"). 그러면 사용자가 빠르게 수정할 수 있습니다. 결과를 RULES.md(다음 단계)에 기록하고, 어떤 규칙이 사용자로부터 왔고 어떤 규칙을 추론했는지 기록하십시오.

3단계: 설정

소스 트리 외부에 작업 폴더를 만들거나, 저장소 내부에 git이 무시하는 .designloop/ 폴더를 만드십시오:

.designloop/
  BRIEF.md        # 인터뷰 답변: 목표, 포함/제외 범위, 변경 허용 한도, 집중 영역, 중단 조건
  RUBRIC.md        # references/rubric.md에서 가져와 선택한 집중 영역에 대해 가중치를 부여한 것
  RULES.md         # 2단계에서 얻은 이 프로젝트의 작업 규칙 (references/briefs.md 참조)
  references/      # 사용자가 좋아하는 것과 대상 이미지 (아래 참조)
  capture/         # 캡처 스크립트 및 표면 목록
  round-0/ …       # 라운드별: 테마별 스틸 이미지, videos/, index.json, judge-*.md

무엇이든 생성하기 전에 이 파일들을 작성하십시오. 하위 에이전트는 컨텍스트 없이 시작되므로 파일이 컨텍스트입니다. 브리프를 다시 입력하는 대신 파일을 가리키십시오.

• RUBRIC.md — 모드의 참조 파일(references/mode-polish.md 또는 references/mode-art-direction.md)의 루브릭으로 시작하고, references/rubric.md의 공유 헤더와 평가자 출력 형식을 포함하십시오. 사용자의 집중 영역에 맞게 가중치를 조정하고, IN 및 OUT 범위 목록을 명시적으로 작성하고, 최고 점수가 무엇을 의미하는지 정의하십시오.
• RULES.md — 2단계에서 확립된 사항: 앱을 실행하고 구동하는 방법, git에서 작업할 위치, 실행할 검사, 건드리거나 사용해서는 안 되는 것, 정리 방법. references/briefs.md에는 포함해야 할 사항 목록이 있습니다.
• 표면 목록 — 범위 내의 모든 표면, 각각 평가할 가치가 있는 상태(rest, hover, open, selected, empty, error, busy)와 각 테마. 관련 표면을 2~3개의 그룹으로 나누어 각 평가자가 집중적으로 살펴볼 수 있도록 하십시오. 50개의 스크린샷을 한 평가자가 훑어보는 것은 피하십시오.

시작하기 전에 프로젝트의 검사가 통과하는지 확인하여 나중에 발생하는 실패가 자신의 책임임을 알 수 있도록 하십시오.

참조 및 대상

루브릭은 일반적으로 '좋음'이 무엇인지 말합니다. 참조는 '좋음'이 이 사용자에게 어떻게 보이는지 말합니다. Art Direction 모드에는 항상 어떤 종류의 대상이 있습니다. Polish 모드는 루브릭만으로 실행될 수 있으며, 앱 자체의 최상의 표면을 표준으로 삼습니다.

세 가지 종류의 대상이 있으며, 각각 다른 권위를 지닙니다. 각 파일이 어떤 것인지 references/README.md에 명시하십시오. 평가자와 구현자는 이를 다르게 취급해야 하기 때문입니다:

• 명세(Spec) (사용자가 일치시키라고 한 Figma 디자인): 권위적입니다. 일치시키십시오.
• 참조(Reference) (사용자가 좋아하는 사이트, 앱, 스크린샷): 명명된 특성만 일치시키고, 전체를 일치시키지 마십시오.
• 생성된 이미지(Generated image) : 느낌에 대한 방향일 뿐입니다.

사용자가 제공한 참조. .designloop/references/에 짧은 README.md와 함께 저장하십시오. 각각에 대해 무엇이며 사용자가 무엇을 좋아하는지 설명하십시오. 웹사이트 또는 앱의 경우 관련 부분의 스크린샷을 캡처하십시오(매력이 모션인 경우 클립도 포함). 그러면 평가자가 변경될 수 있는 페이지를 다시 가져오는 대신 매 라운드 동일한 것을 볼 수 있습니다. 좋아하는 점을 구체적이고 확인 가능한 특성으로 루브릭에 전환하십시오("행 높이 약 28px", "하나의 강조 색상", "메뉴가 200ms 미만으로 페이드 인"). 평가자는 분위기가 아닌 특성에 점수를 줄 수 있기 때문입니다.

직접 수집한 참조. 사용자가 방향을 원하지만 예시가 없는 경우, 목표에 맞는 잘 알려진 제품 3~4개를 제안하고, 보여주고, 사용자가 선택하도록 하십시오. 사용자를 대신하여 선택하지 마십시오.

Figma 디자인. 사용자가 Figma 링크를 제공한 경우, 이 세션에서 Figma 커넥터 또는 MCP 서버를 사용할 수 있는지 확인하십시오(2단계). 가능한 경우, 먼저 자체 스킬이나 지침을 로드한 다음, 각 연결된 프레임에 대해 다음을 가져오십시오: 리