shape

shape skill 개요

shape가 하는 일

shape skill은 코드를 쓰기 전에 기능을 먼저 정의하는, 기획 중심 UX/UI 워크플로입니다. 곧바로 레이아웃이나 컴포넌트부터 만드는 대신, 구조화된 디스커버리 인터뷰를 진행하고 그 답변을 디자인 브리프로 정리합니다. 그래서 팀이 무엇을 만들지는 대략 알고 있어도, 사용자 목표·제약 조건·상태·엣지 케이스·구현 방향이 아직 명확하지 않을 때 특히 유용합니다.

shape skill을 설치하면 좋은 사람

shape skill은 프로덕트 관점으로 만드는 빌더, 디자이너, 프론트엔드 엔지니어, 그리고 프로토타이핑 전에 더 나은 결정을 내리고 싶은 AI 협업 팀에 가장 잘 맞습니다. 특히 shape for UI Design은 기능 정의가 아직 모호할 때 효과적입니다. 예를 들면 새로운 플로우, 대시보드, 폼, 온보딩, 설정 화면처럼 “UI만 일단 생성해줘”로 접근하면 사용자가 실제로 해결하려는 일을 놓치기 쉬운 인터페이스 작업에 적합합니다.

사람들이 일반 프롬프트보다 shape를 고르는 이유

일반적인 프롬프트는 즉시 목업이나 컴포넌트 아이디어를 내놓는 경우가 많습니다. 반면 shape는 의도적으로 속도를 늦춥니다. 먼저 맥락을 수집한 뒤, 나중에 구현용 스킬로 넘길 수 있는 디자인 브리프를 만든다는 점이 핵심 차별점입니다. 저장소에서도 범위를 분명히 밝힙니다. 이 스킬은 코딩이 아니라 디자인 기획용입니다. 피상적인 UI 제안은 줄이고, 근거 있는 프로덕트 결정을 원한다면 이 경계가 오히려 큰 장점입니다.

shape skill 사용 방법

설치 맥락과 필수 선행 조건

다음과 같이 skills 워크플로를 사용해 pbakaus/impeccable 저장소에서 스킬을 설치합니다:
npx skills add pbakaus/impeccable --skill shape

도입 시 가장 중요한 포인트는 SKILL.md에 적힌 선행 조건입니다. shape skill은 먼저 /impeccable이 필요합니다. 이 스킬은 /impeccable을 호출하고, 해당 Context Gathering Protocol을 따른 뒤, 아직 디자인 맥락이 없다면 shape skill을 쓰기 전에 /impeccable teach를 실행해야 한다고 명시합니다. 이 단계를 건너뛰면 의도된 워크플로와 다르게 사용하는 셈입니다.

shape가 잘 작동하려면 어떤 입력이 필요한가

인자 힌트는 [feature to shape]이지만, 기능 이름 한 줄만으로는 대개 부족합니다. 더 좋은 shape usage는 아래 정보에서 시작합니다:

• 기능의 목표
• 대상 사용자 또는 역할
• 현재 워크플로 또는 불편한 지점
• 성공 기준
• 플랫폼, 권한, 컴플라이언스, 기존 디자인 시스템 같은 강한 제약
• 이미 알고 있는 엣지 케이스나 제외 범위

약한 입력 예시: Shape a notifications page.
더 강한 입력 예시: Shape a notifications center for account admins who miss urgent billing and security events. It must work on desktop first, reuse our existing table and filter patterns, and avoid adding real-time infrastructure in v1.

실전 워크플로와 먼저 읽어야 할 파일

먼저 SKILL.md를 읽고, 이를 운영 계약서처럼 다루는 것이 좋습니다. 이 저장소 스냅샷에서는 해당 파일만 공개되어 있으므로, 핵심 가치는 대부분 그 순서를 제대로 따르는 데 있습니다:

1. /impeccable로 디자인 맥락을 수집합니다.
2. shape는 구현 단계가 아니라 기획 단계에서 사용합니다.
3. 스킬이 디스커버리 인터뷰를 진행하게 둡니다.
4. 인터뷰 결과를 디자인 브리프로 정리합니다.
5. 그 브리프를 /impeccable craft, /impeccable, 또는 다른 구현 워크플로에 넘깁니다.

이 순서가 중요한 이유는, 이 스킬이 UI 작업을 시작하기 전에 추측을 줄이도록 최적화되어 있기 때문입니다. 한 번에 완성도 높은 화면을 바로 뽑아내는 용도는 아닙니다.

더 나은 결과를 내는 프롬프트 패턴

shape skill을 효과적으로 호출하려면, 인터뷰와 최종 산출물을 모두 명시적으로 요청하는 것이 좋습니다. 예를 들면 이런 구조입니다:

• shape할 기능
• 주요 사용자
• 현재 문제
• 반드시 지켜야 할 제약
• 브리프에서 정리되길 원하는 결정 사항

예시:
Use shape to plan a bulk-edit inventory feature for operations managers. Interview me first. Focus on user intent, error prevention, empty/loading/failure states, permissions, and what the v1 interaction model should be. Output a design brief I can hand to implementation.

이 방식이 “X를 위한 UI를 디자인해줘”보다 나은 이유는, 방향을 섣불리 고정하기 전에 필요한 확인 질문을 할 여지를 shape에 주기 때문입니다.

shape skill FAQ

shape skill은 코딩용인가, 기획용인가?

shape skill은 기획용입니다. 저장소에서도 분명히 말하듯, 이 스킬은 코드를 작성하지 않습니다. 출력물은 이후 구현을 안내하는 디자인 브리프입니다. 당장 코드가 필요하다면 시작점으로는 맞지 않습니다. 반대로 제품과 UI 의사결정을 먼저 더 탄탄하게 만들고 싶다면 잘 맞습니다.

언제 shape가 일반 프롬프팅보다 더 좋은가?

기능 정의가 덜 되어 있거나, 리스크가 있거나, 사용자 접점이 크거나, 상태와 트레이드오프가 복잡할 가능성이 높을 때 shape를 쓰는 것이 좋습니다. 일회성 목업이라면 일반 프롬프트가 더 빠를 수 있습니다. 하지만 워크플로, 사용자 요구, 제약, 핸드오프 품질까지 생각해야 한다면 shape가 더 적합합니다.

초보자도 shape를 쓸 수 있나?

그렇습니다. 단, 한 가지 조건은 있습니다. 초보자라도 디스커버리 인터뷰에 답할 수 있을 만큼의 제품 맥락은 갖고 있어야 합니다. 이 스킬이 구조를 제공해주긴 하지만, 사용자, 제약, 성공 지표를 대신 지어내주지는 않습니다. UX 기획이 익숙하지 않더라도, 인터뷰 중심 접근이 오히려 도움이 됩니다. 원래라면 반드시 답했어야 할 질문들을 드러내주기 때문입니다.

언제 shape for UI Design을 쓰지 말아야 하나?

문제가 이미 완전히 정의되어 있거나, 아주 작은 시각적 수정만 필요하거나, 작업이 사용자 상호작용과 무관한 순수 기술 과제라면 shape for UI Design은 건너뛰는 편이 낫습니다. 또한 선행 맥락 수집 단계를 거부한다면 적합하지 않습니다. 이 스킬은 그 기반 정보에 의존합니다.

shape skill을 더 잘 활용하는 방법

shape에 더 좋은 기획 입력 주기

가장 큰 품질 변수는 입력 품질입니다. shape에 좋은 입력이란 단순히 기능 이름을 넘는 정보입니다. 사용자 유형, 작업 빈도, 실패 비용, 기존 패턴, 비즈니스 규칙, 그리고 범위 밖에 둬야 할 사항까지 포함하세요. 스킬이 이후 인터뷰를 진행하더라도, 시작 맥락이 풍부할수록 브리프는 더 날카로워지고 뻔한 추천은 줄어듭니다.

가장 흔한 실패 원인 피하기: 성급한 해법 제시

이 저장소가 가장 강하게 경고하는 부분은 디자인 결정을 너무 일찍 내려버리지 말라는 점입니다. shape skill의 흔한 오용은 사용자 문제를 명확히 하기 전에 화면, 카드, 탭, 레이아웃부터 요구하는 것입니다. 대화가 너무 빨리 인터페이스 패턴으로 넘어간다면 방향을 다시 잡으세요. 먼저 충족되지 않은 사용자 요구, 작업 흐름, 상태, 트레이드오프, 제약을 물어보도록 유도해야 합니다.

프롬프트만이 아니라 디자인 브리프를 반복 개선하기

첫 번째 결과를 받은 뒤에는, 불명확한 결정을 다시 따져보면서 브리프를 개선하는 것이 좋습니다:

• 가장 중요한 사용자 목표는 무엇인가?
• 빠진 상태는 없는가?
• 검증이 필요한 가정은 무엇인가?
• v1에서 의도적으로 제외한 것은 무엇인가?
• 어떤 부분이 구현 단계에서 모호함을 만들 수 있는가?

이런 식의 반복 개선이 “더 나은 UI를 만들어줘”를 계속 요청하는 것보다 shape usage를 훨씬 더 좋게 만듭니다.

shape를 후속 실행 워크플로와 연결하기

shape install의 실질적인 가치를 높이려면, 이를 체인의 첫 단계로 보는 것이 가장 좋습니다. 먼저 shape로 브리프를 만들고, 그 브리프를 /impeccable craft나 다른 구현 스킬로 넘기세요. 핸드오프 산출물이 좋을수록, 이후 코드 생성이나 디자인 생성도 사용자의 실제 요구에 더 잘 맞고, 그럴듯해 보이기만 하는 약한 UI로 흐를 가능성은 줄어듭니다.