시니어 디자인 리뷰은(는) 무엇을 하나요?
모호한 '더 좋게 만들어 줘'를 검증 가능한 디자인 결정으로 전환합니다. 출력은 실제 파일, 토큰 및 참조 패턴을 인용하는 구조화된 비평과 엔지니어가 구현할 수 있는 명세입니다.
사용 시기
사용자가 다음을 요청할 때 이 스킬을 사용하세요:
- 기존 화면, 플로우 또는 컴포넌트를 리뷰, 비평 또는 '압박 테스트'할 때
- 다른 사람(예: 주니어 디자이너 또는 다른 에이전트)이 작성한 제안을 평가할 때
- 구현 전에 무엇을 삭제, 추가, 수정 또는 유지할지 결정할 때
- 스크린샷으로부터 모바일 플로우를 수정할 때
사용하지 말아야 할 때
- 소규모 로컬 수정 예: "이 카드의 패딩을 늘려 주세요" 또는 "이 레이블을 '저장'으로 바꿔 주세요". 변경을 직접 수행하세요. 전체 리뷰는 노이즈입니다.
- 대화형 프로토타입 제작 대화형 목업 워크플로를 사용하세요. 이 스킬은 그 입력이 될 수 있습니다.
- UI와 무관한 코드 리뷰, 성능 튜닝 또는 백엔드 설계
- 구체적인 인터페이스가 없는 브랜드 또는 마케팅 전략
입력
저장소 또는 사용자가 안전하게 제공할 수 있는 것을 수집하세요. 누락된 입력은 개방형 질문으로 나열되며, 절대 임의로 생성되지 않습니다.
- 디자인 토큰(색상, 서체, 간격, 둥글기, 모션) — 파일 경로
- 대상이 닮아야 할 표준 기존 컴포넌트
- 이전에 승인된 유사 작업의 예시(선택 사항, 유용함)
- 대상 구현 및/또는 스크린샷
- 알려진 플랫폼 제약사항(내비게이션 모델, OS 규칙, 최소 목표)
- 사용자의 불만 사항(가능한 경우 그대로 인용)
컨텍스트 양식은 templates/context.md에 있습니다.
워크플로
1. 명시적인 초기 제안 초안 작성
비평 전에 templates/proposal.md를 사용하여 제안을 작성하세요: 문제, 인용된 문제점, 디자인 원칙, 정보 아키텍처 스케치, 액션 및 개방형 질문. 사용자가 제안을 제공한 경우, 그 제안을 변경 없이 입력으로 사용하세요.
2. 새로운 패스로 리뷰 실행
리뷰어는 다음 순서로 읽습니다: 토큰, 표준 컴포넌트, 이전 예시, 대상 구현/스크린샷, 플랫폼 제약사항, 그리고 마지막으로 제안. 증거를 먼저 읽으면 제안의 프레이밍에 고정되는 것을 방지합니다.
- 런타임이 진정으로 분리된 컨텍스트(공유 기록이 없는 하위 에이전트 또는 새 세션)를 시작할 수 있다면 이를 사용하고 명시하세요.
- 그렇지 않다면 직접 별도의 패스를 실행하고 정직하게 레이블을 지정하세요: "단일 에이전트 별도 패스 — 독립적인 동료 리뷰가 아님."
리뷰어 페르소나는 품질 렌즈(까다로운 시니어 제품 디자이너)입니다. 페르소나를 대신하여 고용 이력, 자격 증명 또는 경력을 절대 언급하지 마세요.
3. 리뷰 작성
templates/review.md를 사용하세요. 섹션:
- TL;DR — 3~5줄: 평결과 가장 중요한 변경 사항
- A. 구조적 비평 — 이것이 올바른 화면/플로우인가?
- B. 정보 아키텍처 및 계층 구조
- C. 액션 의미론 — 기본, 보조, 파괴적, 실행 취소, 명명
- D. 메커니즘 및 제스처 — 탭, 스와이프, 드래그, 키보드, 검색 가능성
- E. 시각 및 모션 — 토큰, 리듬, 밀도, 전환
- F. 접근성 및 국제화
- G. 누락된 질문 — 5개를 목표로 하지만 의미 있는 것만 포함
- H. 정제된 명세 및 삭제 / 추가 / 수정 / 유지 원장
각 렌즈에 대한 자세한 지침은 references/review-lenses.md에 있습니다. 접근성 및 i18n 체크리스트는 references/accessibility-i18n.md에 있습니다.
리뷰를 읽을 가치 있게 만드는 규칙
- 압박 테스트하세요. 도장 찍지 마세요. 모든 주장에는 특정 참조가 필요합니다: 파일 경로, 토큰 이름, 컴포넌트 이름, 스크린샷 영역 또는 명명된 참조 패턴(예: "iOS Mail 스와이프하여 보관").
- 진부한 표현 금지. "시각적 계층 구조 개선"은 결과가 아닙니다. "'마감일' 날짜가 제목과 같은 크기로
text.secondary를 사용하므로 마감일이 한눈에 보이지 않습니다"가 맞습니다. - 강제 삭제 금지. 현재 구조가 올바르다면 그렇게 말하고 입증된 유지를 기록하세요. 변화 자체를 위한 변화는 결함입니다.
- 측정값 임의 생성 금지. 대비 비율, WCAG 통과/실패 수준 또는 성능 수치를 계산하거나 측정하지 않은 경우 명시하지 말고, 측정한 경우 어떻게 측정했는지 보여주세요. 그렇지 않으면 "측정되지 않음 — 대비 도구로 확인"이라고 작성하세요.
- 상태 커버. 빈 상태, 로딩, 오류, 오프라인, 긴 콘텐츠 및 매우 짧은 콘텐츠.
- 비색상 신호. 상태는 색상에만 의존해서는 안 됩니다.
- 키보드 및 스크린 리더 경로는 사용자 정의 제스처를 포함한 모든 액션에 대해 제공해야 합니다.
- 텍스트 확장 (많은 언어에서 약 30~40% 더 긴 문자열 허용) 및 관련된 경우 오른쪽에서 왼쪽 레이아웃.
- 모든 애니메이션에 대한 축소 모션 대안.
선택사항: 이전 작업과 비교
이전에 승인된 예시가 있는 경우, E 또는 H 아래에 "이전 작업과의 일관성"에 대한 짧은 메모를 추가하세요. 유용하지만 필수는 아닙니다.
출력물
proposal.md(초안을 작성한 경우)- TL;DR, A-H 및 원장을 포함한
review.md - 사용자에게 전달하는 짧은 요약: 평결, 상위 3가지 변경 사항 및 구현을 막는 개방형 질문
수용 조건
references/review-lenses.md#acceptance-checks를 참조하세요. 모든 원장 항목에 이유와 참조가 없거나, 측정되지 않은 숫자를 사실로 명시하는 경우 리뷰는 실패합니다.
라이선스 고지
다음 고지는 이 독립형 스킬 및 지원 파일과 함께 전달됩니다.
MIT License
Copyright (c) 2026 jamesonedge
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.