critique

critique skill 개요

critique skill이 하는 일

critique skill은 페이지, 기능, 컴포넌트를 단순히 “작동하는 UI”가 아니라 설계된 사용자 경험으로 평가하는 구조화된 UX 리뷰 워크플로우입니다. 시각적 위계, 정보 구조, 감정적 톤, 인지 부하, 사용성 휴리스틱을 점검하도록 모델을 유도하고, 그 결과를 두루뭉술한 감상이 아니라 실행 가능한 피드백으로 바꿔줍니다.

critique skill 설치가 잘 맞는 사람

이 critique skill은 인터페이스에 대해 빠른 UX 감사 스타일의 피드백이 자주 필요한 디자이너, 프론트엔드 엔지니어, 프로덕트 팀, AI 빌더에게 가장 잘 맞습니다. 특히 스크린샷, 라이브 페이지, 이미 구현된 컴포넌트가 있고, “이 디자인 어때?” 같은 일반적인 프롬프트보다 더 날카롭고 구조적인 리뷰가 필요할 때 유용합니다.

가장 잘 맞는 작업

critique는 실제 과제가 “이 인터페이스가 왜 잘 작동하거나 실패하는지, 사용자가 어디서 막히는지, 무엇을 먼저 바꿔야 하는지 알려줘”일 때 쓰는 것이 가장 적합합니다. 디자인 리뷰, 출시 전 점검, AI가 생성한 UI 정리, 그리고 미적 평가보다 우선순위 판단이 중요한 UX Audit용 critique 워크플로우에 잘 맞습니다.

이 skill이 다른 점

critique의 가장 큰 차별점은 분명한 관점을 가진다는 점입니다. 넓은 범위의 디자인 코멘트에서 멈추지 않습니다. “AI slop” 패턴을 명시적으로 점검하고, 휴리스틱 점수를 사용하며, 페르소나 기반 테스트까지 권장합니다. 그래서 일반적인 critique 프롬프트보다 결과가 더 진단적이고, 반복 실행해도 일관성을 내기 쉽습니다.

사용 전 반드시 알아야 할 의존성

이 skill은 실무에서 단독으로 쓰는 도구가 아닙니다. 자체 지침상 먼저 /frontend-design skill을 사용해야 하며, 그 skill의 컨텍스트 수집 프로토콜도 따라야 합니다. 아직 디자인 컨텍스트가 없다면, 저장소에서는 critique 전에 /teach-impeccable를 실행하라고 안내합니다. 도입 전에 꼭 이해해야 할 가장 큰 장벽이 바로 이 의존성입니다.

critique skill 사용 방법

설치 컨텍스트와 저장소 경로

critique skill은 pbakaus/impeccable 저장소의 .agents/skills/critique에 있습니다. skill loader를 쓴다면 해당 저장소에서 설치한 뒤 critique skill을 선택하면 됩니다. 환경이 저장소 기반 직접 로딩을 지원한다면 다음을 가리키세요.

• pbakaus/impeccable
• skill: critique

설치 전에 직접 확인하고 싶다면 여기부터 보는 것이 좋습니다:

• .agents/skills/critique/SKILL.md
• .agents/skills/critique/reference/cognitive-load.md
• .agents/skills/critique/reference/heuristics-scoring.md
• .agents/skills/critique/reference/personas.md

critique skill 첫 설치 전에 먼저 읽어야 할 점

이걸 그냥 붙여 넣는 프롬프트 조각처럼 다루면 안 됩니다. 이 skill은 사전에 디자인 컨텍스트가 준비되어 있다는 전제를 깔고 있습니다. 저장소에서도 /frontend-design을 필수로 두고, critique를 실행하기 전에 그 컨텍스트 수집 프로토콜을 따르라고 명시합니다. 이 단계를 건너뛰면 모델이 목표, 대상 사용자, 인터페이스 의도를 모른 채 답하게 되어 결과 품질이 눈에 띄게 떨어집니다.

critique skill에 필요한 입력

제대로 된 critique를 받으려면 다음 정보를 주는 것이 좋습니다:

• 리뷰할 인터페이스 범위
• 스크린샷 또는 명확한 시각 설명
• 제품 목표
• 타깃 사용자
• 사용자가 완료하려는 핵심 작업
• 플랫폼, 브랜드, 접근성, 전환 목표 같은 제약 조건

최소 입력만으로도 작동은 하지만, 모델이 “무엇이 성공인지”를 알수록 critique 품질은 훨씬 좋아집니다.

가장 좋은 호출 패턴

이 skill의 인자 힌트는 [area (feature, page, component...)]입니다. 실전에서는 다음처럼 범위를 구체적으로 주는 것이 좋습니다:

• critique checkout page
• critique onboarding modal
• critique dashboard sidebar
• critique pricing page for UX Audit

“critique my app”처럼 넓게 말하는 것보다 범위를 특정할수록 더 실행 가능한 피드백이 나옵니다.

거친 요청을 강한 critique 프롬프트로 바꾸는 법

약한 요청:

• “Critique this UI.”

더 좋은 요청:

• “Critique this settings page for UX Audit. The goal is to help first-time users enable notifications without confusion. Audience is non-technical SMB owners. Prioritize visual hierarchy, cognitive load, and whether the main action is obvious.”

왜 이 방식이 잘 작동하나:

• 어떤 사용자인지 명시합니다
• 어떤 작업인지 명시합니다
• 성공 기준을 명시합니다
• 무엇을 우선적으로 볼지 skill에 알려줍니다

실전에서 추천하는 워크플로우

실무에서 유용한 critique guide 흐름은 다음과 같습니다:

1. /frontend-design으로 컨텍스트를 수집합니다.
2. 제품 목표와 사용자 작업을 명시합니다.
3. 정확한 화면, 기능, 컴포넌트를 critique에 넘깁니다.
4. 심각도 기준으로 findings를 묶어 달라고 요청합니다.
5. 첫 리뷰가 끝나면 엔지니어링 제약이나 브랜드 제약을 반영한 수정 권고안을 다시 요청합니다.

critique와 리디자인을 한 번에 시키는 것보다 이 순서가 더 안정적으로 작동합니다.

critique skill이 특히 잘 평가하는 것

저장소 기준으로 보면, critique skill이 특히 강한 영역은 다음과 같습니다:

• 전형적인 AI 생성 UI 패턴 탐지
• 위계와 명확성 평가
• 인지 과부하 식별
• 휴리스틱 점수 적용
• 관련 페르소나를 통한 플로우 검증

즉, 겉보기엔 세련됐지만 실제로는 사용자를 실패하게 만드는 지점을 가려내는 데 유용합니다.

reference 파일을 잘 활용하는 방법

reference 파일은 보기보다 훨씬 중요합니다.

reference/cognitive-load.md는 작업 자체의 복잡성과, 설계가 불필요하게 만든 복잡성을 구분하도록 모델을 도와줍니다. 그래서 권고안의 질이 더 좋아집니다.

reference/heuristics-scoring.md는 Nielsen 휴리스틱 전반에 걸쳐 0–4 점수 프레임을 추가합니다. 여러 화면을 비교 가능한 기준으로 리뷰하고 싶을 때 특히 유용합니다.

reference/personas.md는 선택적으로 쓰는 편이 가장 좋습니다. 매번 다섯 개를 억지로 다 적용하기보다, 실제 대상 사용자에 맞는 페르소나 2–3개를 고르세요.

UX Audit용 critique에 좋은 프롬프트

목표가 UX Audit용 critique라면, 다음처럼 구조화된 출력 형식을 요청하는 것이 좋습니다:

• 상위 5개 사용성 리스크
• 간단한 근거가 포함된 휴리스틱 점수
• 선택한 페르소나별로 예상되는 실패 지점
• 우선순위가 가장 높은 수정 항목부터
• 바꾸지 말아야 할 요소

이 형식이면 팀에 바로 전달해도 될 정도로 리뷰 결과를 재가공 없이 활용하기 쉽습니다.

출력 품질을 떨어뜨리는 흔한 오용

가장 큰 오용은 인터페이스도, 스크린샷도, 작업 맥락도 없이 디자인 피드백만 요구하는 것입니다. 또 하나 흔한 실수는 critique skill을 완전히 새로운 UI를 처음부터 생성하는 용도로 쓰는 것입니다. 이 skill은 풀 디자인 시스템을 발명하는 것보다, 문제를 평가하고 우선순위를 매기는 데 더 적합합니다.

critique skill FAQ

critique는 초보자도 쓰기 쉬운가요?

네, 다만 기본 컨텍스트를 제공할 때만 그렇습니다. 초보자도 화면 하나와 사용자 목표 하나만 공유해도 빠르게 가치를 얻을 수 있습니다. 반대로 이 정보가 없으면 critique skill은 그럴듯하게 말하면서도 실제 제품 문제를 놓칠 수 있습니다.

일반 critique 프롬프트보다 더 나은가요?

대체로 그렇습니다. 차이는 단순한 문구가 아니라 내장된 리뷰 프레임에 있습니다. AI slop 탐지, 인지 부하 분석, 휴리스틱 점수, 페르소나 테스트가 포함되어 있어, 일반 프롬프트보다 critique usage의 일관성이 높습니다.

먼저 frontend-design skill이 꼭 필요한가요?

사실상 그렇습니다. 저장소에서 이를 필수로 표시합니다. critique를 설치한 첫날부터 제대로 활용하고 싶다면, 단독 사용보다는 /frontend-design과 함께 쓸 계획을 세우는 편이 맞습니다.

어떤 종류의 산출물이 가장 잘 맞나요?

가장 좋은 입력은 스크린샷, 렌더링된 페이지, 프로토타입, 또는 작업 맥락이 분명한 상세 인터페이스 설명입니다. 코드만 있는 경우는 UI 동작이 설명되거나 눈에 보이지 않는 이상 활용도가 떨어집니다.

언제 critique를 쓰지 말아야 하나요?

다음이 필요할 때는 critique를 쓰지 마세요:

• 깊이 있는 코드 수준 구현 리뷰
• 접근성 규정 준수 감사 자체
• 분석 데이터 기반 전환 진단
• 검토할 기존 인터페이스 없이 전면 리디자인

이 도구는 UX 중심 평가기이지, 전문 감사 도구를 대체하는 것은 아닙니다.

critique로 여러 디자인 옵션을 비교할 수 있나요?

네. 비교 점수와 트레이드오프를 요청하면 나란히 검토하는 용도로 잘 작동할 가능성이 큽니다. 비교를 공정하게 유지하려면 각 옵션에 동일한 작업 맥락과 사용자 맥락을 제공하세요.

critique skill 개선 방법

화면만이 아니라 인터페이스 목표를 알려주세요

critique 결과를 개선하는 가장 좋은 방법 하나만 꼽자면, 그 인터페이스가 무엇을 달성하려는지 설명하는 것입니다. 저장소에서도 이를 명시적으로 요구합니다. 화면이 아무리 예뻐도 핵심 작업이 불분명하면 실패할 수 있고, 이 skill은 바로 그런 문제를 잡아내도록 설계되어 있습니다.

심각도, 근거, 수정안을 함께 요구하세요

실행으로 이어지는 출력을 원한다면 critique skill에 findings를 다음 형식으로 정리해 달라고 요청하세요:

• 문제
• 왜 중요한지
• UI에서 보이는 근거
• 심각도
• 권장 수정안

이렇게 하면 공허한 코멘트를 막고, 리뷰 결과의 우선순위를 정하기도 쉬워집니다.

실제 사용자와 맞는 페르소나를 고르세요

페르소나 테스트는 관련 있는 전형만 골랐을 때 훨씬 강력해집니다. 예를 들어:

• 온보딩에는 first-time user
• 복잡한 대시보드에는 impatient power user
• 금융 또는 파괴적 작업 흐름에는 anxious user

모든 페르소나를 과하게 다 쓰면 오히려 critique가 흐려질 수 있습니다.

구체적 제약으로 약한 프롬프트를 보강하세요

더 강한 critique guide 프롬프트에는 다음과 같은 제약이 포함됩니다:

• mobile-only
• brand cannot change colors
• must keep current information architecture
• engineering team can only make low-effort fixes this sprint

제약이 있어야 더 현실적인 권고안이 나옵니다.

가장 흔한 실패 모드를 주의하세요

가장 대표적인 실패 모드는 실제 사용자 작업과 연결되지 않는, 넓고 세련돼 보이는 피드백입니다. 첫 출력이 지나치게 일반적이라면 다음과 같은 후속 질문을 던지세요:

• “Which issue most likely blocks task completion?”
• “What would confuse a first-time user in the first 10 seconds?”
• “Which recommendation has the highest impact with lowest implementation effort?”

휴리스틱 점수는 신중하게 사용하세요

점수는 비교와 우선순위 판단에 유용하지만, 잘못하면 정밀해 보이는 착시를 만들 수 있습니다. 각 점수 아래에 짧은 근거도 함께 요청하세요. 그래야 critique skill이 임의의 숫자가 아니라 실제로 보이는 UI 문제에 기반해 평가하도록 유지할 수 있습니다.

critique는 두 번에 나눠 실행하세요

고품질 워크플로우는 보통 다음과 같습니다:

1. 1차 패스: 문제 진단
2. 2차 패스: 실제 제약 안에서 해결책 구체화

진단과 리디자인을 분리하면 더 명확해지고, 대체로 더 믿을 만한 권고안이 나옵니다.

첫 critique 이후 출력을 더 좋게 만드는 법

첫 실행 후에는 다음을 다시 입력해 주세요:

• 사용자에 대한 잘못된 가정의 정정
• 수정된 상태의 스크린샷
• 모델이 무시한 제약 조건
• 팀이 동의하거나 동의하지 않는 findings

critique skill은 한 번에 판정하는 심판처럼 쓸 때보다, 반복적으로 검토하는 리뷰어처럼 다룰 때 더 좋아집니다.

이 skill의 강점이 가장 잘 드러나는 곳에 쓰세요

이 critique skill은 겉보기에는 완성도가 높지만 UX 문제가 숨어 있을 수 있는 인터페이스에서 가장 가치가 큽니다. 예를 들면 AI가 생성한 랜딩 페이지, 대시보드, 온보딩 플로우, 설정 패널, 기능 밀도가 높은 화면들입니다. 이런 곳에서 anti-pattern 탐지와 인지 부하 프레이밍이 가장 큰 정보 가치를 제공합니다.

도입 전 트레이드오프를 이해하세요

트레이드오프는 단순합니다. critique는 일반 프롬프트보다 더 엄격한 UX 피드백을 제공하지만, 그만큼 컨텍스트를 충분히 제공하고 이 skill의 분명한 프레임워크를 받아들여야 합니다. 가볍고 즉흥적인 의견만 필요하다면 일반 프롬프트가 더 빠를 수 있습니다. 반대로 반복 가능한 UX Audit용 critique가 필요하다면 이 skill이 더 잘 맞습니다.