design-review

design-review 스킬 개요

design-review가 하는 일

design-review는 실제 코드베이스에서 시각적 불일치, 간격 문제, 위계 문제, AI스러운 패턴, 그리고 다듬어지지 않은 느린 인터랙션을 잡아내고, 검증을 거치며 반복적으로 수정하는 디자인 QA 스킬입니다. “뭔가 어색하다”는 감각을 구체적인 소스 변경과 수정 전후 검증으로 이어가고 싶은 팀에 가장 잘 맞습니다.

누가 사용하면 좋은가

라이브 인터페이스를 점검하거나, 구현을 다듬거나, 이미 코드에 존재하는 UI를 리뷰해야 할 때 design-review 스킬을 사용하세요. 시각적 일관성이 새 레이아웃 생성보다 중요한 앱을 다루는 제품 디자이너, 프런트엔드 엔지니어, 그리고 에이전트에게 특히 잘 맞습니다.

무엇이 다른가

일반적인 UX Audit 프롬프트와 달리 이 design-review 가이드는 작업 흐름을 전제로 설계되어 있습니다. 문제를 찾아내고, 원자적으로 수정하고, 결과를 다시 확인하도록 만들어져 있습니다. 또한 plan-mode 분리를 지원하는데, 즉시 편집보다 먼저 검토를 하고 싶을 때 특히 중요합니다.

design-review 스킬 사용 방법

설치하고 작업을 연결하기

먼저 skills manager에서 design-review 설치 명령을 실행한 뒤, 검토할 UI가 들어 있는 repo를 에이전트에 연결하세요. plan mode로 작업 중이라면 /plan-design-review로 라우팅하고, 코드 변경이 필요하다면 스킬에 설명된 active review 경로를 사용하세요.

스킬에 맞는 입력을 주기

좋은 design-review 사용 프롬프트는 화면, 사용자 흐름, 그리고 중요하게 보는 실패 지점을 분명히 적습니다. 더 나은 예: “모바일에서 checkout modal의 간격, 위계, 버튼 명확성을 검토한 다음 가장 심한 문제를 수정해줘.” 더 나쁜 예: “이걸 더 좋아 보이게 해줘.” 첫 번째는 스킬에 목표, 제약, 성공 조건을 함께 줍니다.

먼저 읽어야 할 파일

fit 판단에 실제로 도움이 되는 design-review 가이드를 보려면 SKILL.md를 먼저 읽고, 있으면 SKILL.md.tmpl 같은 생성 템플릿 파일도 확인하세요. 또한 이 repo는 지원 스크립트나 문서보다 스킬 본문을 중심으로 구성되어 있으므로, prompt-routing이나 helper 관례가 있는지도 repo tree에서 함께 살펴보세요.

리뷰 루프로 실행하기

이 스킬은 짧은 사이클로 쓰는 것이 좋습니다. 점검하고, 패치하고, 검증하고, 다시 반복하세요. 무엇을 왜 바꿨는지 보여 달라고 요청하고, typography, spacing, interaction latency처럼 한 번에 한 가지 문제군만 다루는 편이 좋습니다. 그래야 리뷰의 초점이 흐트러지지 않고 회귀도 더 쉽게 찾을 수 있습니다.

design-review 스킬 FAQ

design-review는 최종 다듬기용만인가요?

아닙니다. design-review 스킬은 live-site 다듬기, codebase 정리, 그리고 이미 시각적 품질이 존재하지만 더 조여야 하는 UX Audit 스타일 점검에 모두 유용합니다. 초기 콘셉트 아이데이션보다는 구현된 인터페이스를 고치고 검증하는 데 더 적합합니다.

디자이너가 아니어도 사용할 수 있나요?

가능합니다. 다만 화면과 문제를 명확하게 설명해야 합니다. 디자이너가 아닌 사용자는 막연히 리디자인을 요청하기보다, 무엇이 어색한지, 사용자가 누구인지, 성공이 무엇인지 구체적으로 적을수록 더 좋은 결과를 얻습니다.

일반 프롬프트와 뭐가 다른가요?

일반 프롬프트는 제안을 내놓는 데 그칠 수 있지만, design-review는 코드 안의 문제를 찾아내고, 수정하고, 결과를 확인하는 흐름에 맞춰져 있습니다. 조언만 필요하다면 이 스킬은 과할 수 있지만, 측정 가능한 UI 수리가 필요하다면 훨씬 잘 맞습니다.

언제 design-review를 쓰지 말아야 하나요?

과제가 전략적 판단만 필요하거나, 브랜드 수준의 결정이거나, 인터페이스 없이 콘텐츠만 다루는 경우에는 쓰지 않는 편이 낫습니다. 또 코드베이스에 접근할 수 없거나 변경 후 스크린샷으로 검증할 수 없다면 적합도가 떨어집니다. 이 스킬의 가치는 반복 검증에서 나오기 때문입니다.

design-review 스킬 개선 방법

구체적인 리뷰 대상을 먼저 정하기

가장 좋은 design-review 결과는 범위가 좁을 때 나옵니다. 한 페이지, 한 컴포넌트, 하나의 사용자 흐름으로 대상부터 좁히세요. viewport, device context, 핵심 관심사를 함께 주는 것이 좋습니다. 예: “desktop settings page, alignment와 scanability에 집중” 또는 “mobile pricing card, tap clarity에 집중.”

무엇을 최적화할지 명확히 말하기

일관성, 접근성, 전환 명확성, 상호작용 속도 중 무엇이 가장 중요한지 처음부터 알려 주세요. 그래야 design-review 스킬이 경쟁하는 수정안 사이에서 우선순위를 정하기 쉽습니다. 특히 한 변경이 한 영역을 개선하는 대신 다른 영역을 약화시킬 때 더 중요합니다.

흔한 실패 패턴을 경계하기

입력이 약할 때 흔한 표현은 “더 깔끔하게 해줘”, “디자인을 개선해줘”, “전체를 점검해줘”입니다. 이런 프롬프트는 범위가 넓고 신호가 낮은 결과를 부르기 쉽습니다. 더 강한 입력은 결함의 종류, 컴포넌트, 허용 가능한 변화 폭을 명시합니다. 그래야 불필요한 수정이 줄고 design-review 사용 루프도 더 좋아집니다.

증거를 보며 반복하기

첫 번째 패스가 끝난 뒤에는 남은 상위 문제, 정확히 바뀐 파일, 그리고 스크린샷 기준으로 아직 보이는 회귀가 무엇인지 물어보세요. 결과가 거의 맞지만 아직 부족하다면 brief를 더 날카롭게 조정하세요. 예: “layout은 유지”, “color palette는 변경하지 말 것”, “hierarchy와 spacing만 수정.”