prototype

개요: prototype 스킬

prototype 스킬이 하는 일

prototype 스킬은 실제 구현에 들어가기 전에, 딱 한 가지 구체적인 질문에 답하는 일회성 코드를 빠르게 만드는 데 도움을 줍니다. 단순한 프롬프트만으로는 부족할 때, 상태 전환이나 데이터 형태, UI 방향을 실행 가능한 형태로 시험해 보고 바로 버릴 수 있어야 하는 경우에 가장 적합합니다.

누가 설치하면 좋은가

평소에 “prototype 해줘”, “몇 가지 옵션 보여줘”, “어떤 형태가 맞는지 모르겠어” 같은 말을 자주 한다면 prototype 스킬을 설치하세요. 특히 기존 repo 안에서 작업할 때 유용합니다. 빈 샌드박스에서 새로 시작하는 대신, 프로토타입이 로컬 컨벤션을 따라야 할 때 강점이 큽니다.

무엇이 다른가

이 prototype 스킬은 흔한 브레인스토밍 프롬프트처럼 넓게 아이디어만 뽑아내는 방식이 아닙니다. 초반에 분기부터 강제로 정합니다. 로직 중심의 터미널 프로토타입을 만들지, 아니면 여러 시각적 변형이 있는 UI 프로토타입을 만들지 먼저 고르게 합니다. 이 선택이 핵심 가치입니다. 잘못된 종류의 프로토타입에 시간을 쓰는 일을 막아주기 때문입니다.

적합한 경우와 맞지 않는 경우

디자인 탐색, 비즈니스 규칙의 예외 처리, 상태 머신의 불확실성, “이건 어떤 모습이어야 하지?” 같은 작업에는 prototype을 쓰세요. 이미 최종 구현 형태를 알고 있거나, 실행 가능한 프로토타입이 아니라 텍스트 설명만 필요하다면 건너뛰는 편이 낫습니다.

prototype 스킬 사용 방법

설치하고 소스 위치 확인하기

npx skills add mattpocock/skills --skill prototype로 prototype 스킬을 설치하세요. 그다음에는 먼저 SKILL.md를 읽고, 질문의 성격에 따라 LOGIC.md 또는 UI.md를 확인하면 됩니다. 더 넓은 맥락이 필요하다면 repo 안의 README.md, AGENTS.md, metadata.json, 그리고 주변의 rules/, resources/, references/ 폴더도 함께 훑어보세요.

올바른 분기 선택하기

prototype 사용에서 가장 중요한 결정은 단순합니다. 로직 질문이면 LOGIC.md, 시각적 질문이면 UI.md입니다. 프롬프트가 모호하다면 주변 코드를 보고 추론하세요. 백엔드나 모델 중심 코드는 보통 로직 쪽에 가깝고, 페이지나 컴포넌트는 보통 UI 쪽입니다. 사용자가 바로 응답할 수 있는 상황이라면, 만들기 전에 확인 질문을 하나 던지는 것이 좋습니다.

대략적인 아이디어를 쓸 수 있는 프롬프트로 바꾸기

좋은 prototype guide 프롬프트는 질문, 대상 표면, 제약 조건을 함께 적습니다. 예를 들어 “이 구독 상태 머신이 취소, 유예 기간, 복귀 흐름을 제대로 처리하는지 프로토타입해줘”는 “billing prototype 해줘”보다 훨씬 좋습니다. UI 작업이라면 어떤 화면에 속하는지, 어떤 기존 데이터는 반드시 실제값이어야 하는지, 변형을 몇 개 원하는지도 함께 말하세요. 질문이 구체적일수록, 엉뚱한 결과물이 나올 가능성은 줄어듭니다.

먼저 읽을 파일

분기 규칙과 공통 제약을 이해하려면 SKILL.md부터 보세요. 그다음에는 아주 작은 대화형 상태 탐색기가 필요하면 LOGIC.md, 한 라우트에서 여러 레이아웃이 필요하면 UI.md를 읽으면 됩니다. 이 파일들은 아이디어 설명보다 실제 워크플로를 보여주기 때문에, 설치 여부를 판단하는 데 가장 빠른 경로입니다.

prototype 스킬 FAQ

prototype은 프런트엔드 작업에만 쓰나요?

아니요. prototype 스킬은 의도적으로 두 갈래로 나뉘어 있습니다. 하나는 UI 탐색용이고, 다른 하나는 비즈니스 로직이나 상태 모델링용입니다. “이건 어떤 모습이어야 하지?”를 시험하려면 UI 분기를, “이 상태 변화가 논리적으로 맞나?”를 시험하려면 로직 분기를 쓰세요.

일반 프롬프트와 무엇이 다른가요?

일반 프롬프트로도 목업을 요청할 수는 있지만, prototype 스킬은 추측을 줄이는 워크플로를 추가합니다. 분기를 고르고, 작업을 일회성으로 유지하며, 실제로 검토 가능한 결과물 쪽으로 출력을 유도합니다. 그래서 잘못된 설계를 선택했을 때의 비용이 큰 상황에서 더 유용합니다.

prototype 스킬은 초보자에게도 친화적인가요?

질문을 분명하게 설명할 수 있다면 그렇습니다. 다만 요청이 모호하면 초보자 친화적이지 않을 수 있습니다. 이 스킬은 올바른 분기를 고르고 호스트 프로젝트의 컨벤션에 맞춰야 하기 때문입니다. 런타임이나 페이지 구조를 모른다면, 조금 더 많은 맥락을 제공해야 할 가능성이 큽니다.

Prototypes에 prototype을 쓰면 안 되는 때는 언제인가요?

최종 프로덕션 구현, 대규모 아키텍처 재설계, 또는 카피라이팅이나 아이데이션만 필요한 요청에는 쓰지 마세요. prototype 스킬은 그대로 배포할 완성품보다, 판단을 돕는 일회성 산출물이 필요할 때 가장 강합니다.

prototype 스킬 개선 방법

결론이 아니라 질문을 말하세요

prototype 스킬의 출력을 개선하는 가장 좋은 방법은, 풀어야 할 불확실성을 설명하는 것입니다. “더 나은 체크아웃을 만들어줘”보다는 “한 페이지 체크아웃이 쿠폰 입력, 배송 선택, 결제 오류를 답답하지 않게 처리할 수 있는지 테스트해줘”가 훨씬 낫습니다. 그래야 스킬이 실제 판단 대상으로 삼을 수 있습니다.

최소한의 실제 맥락을 제공하세요

더 좋은 prototype guide 결과를 원한다면, 호스트 라우트, 관련 데이터 형태, 유지해야 하는 기존 컴포넌트, 그리고 프레임워크·런타임·새 의존성 금지 같은 제약을 함께 넣으세요. 실제 환경을 흉내 낼 수 있을수록 프로토타입 품질은 좋아지고, 전혀 다른 가상의 환경을 만들 가능성은 줄어듭니다.

흔한 실패 패턴을 경계하세요

가장 흔한 실패는 초반에 잘못된 분기를 고르는 것입니다. 프로토타입이 엉뚱한 대상을 향하면, 결과물이 아무리 그럴듯해 보여도 쓸모가 없을 수 있습니다. 애매하다면, 스킬이 먼저 전제를 상단에 명시하게 하고, 그 전제에만 좁게 맞춘 프로토타입을 만들게 하세요.

더 날카로운 제약 하나로 반복 개선하세요

첫 결과를 받은 뒤에는 한 번에 한 가지씩만 바꾸며 prototype install 결과를 개선하세요. 변형 수를 줄이거나, 더 현실적인 데이터를 쓰거나, 더 엄격한 엣지 케이스를 넣거나, 대상 화면을 더 구체적으로 지정하는 식입니다. 이 스킬은 범위를 넓히는 것보다 질문을 더 선명하게 만드는 데 맞춰져 있으므로, “더 많은 옵션”을 요청하는 것보다 대체로 효과적입니다.