prototype (mattpocock/skills)
상태 모델이나 로직이 맞는지, UI가 어떤 모습이어야 하는지 확인할 일회용 프로토타입을 만듭니다.
Matt Pocock의 prototype: 자체 UI 변형 규칙을 잘 지켰고(스킬 4.95 vs 대조군 3.71), 비용은 스킬 없이와 비슷합니다
Codex CLI · gpt-6-astra
27.2 / 30
스킬 없이 대비 향상폭: +1.23 · 추천 · 18회 실행
추천: 총점 27.2/30이 22점 이상, 출력 품질 5.0가 3.5 이상, 향상폭 +1.23가 +1.0 이상입니다.
SOTA
통과Codex로 테스트
커버 대상 Codex, Claude Code
Codex CLI 0.166 (SOTA 티어): 채점된 실행 18회. 여기서 통과하면 티어 규칙에 따라 Claude Code도 커버되지만, 두 번째 티어에 대해서는 아무것도 말해주지 않습니다.
점수
각 차원은 0~5점이며 여섯 차원을 더하면 30점 만점의 총점이 됩니다. 모든 차원에서 5가 가장 좋습니다. 비용 5는 저렴하고 빠름, 설치 5는 쉬움을 뜻합니다.
- 트리거 신뢰도
- 5.0
- 스킬 없이 대비 향상폭
- 3.2
- 출력 품질
- 5.0
- 토큰 및 시간 비용
- 5.0
- 설치 및 이식성
- 4.0
- 안전성
- 5.0
보안 리뷰
안전정적 스캔: CRITICAL 1 / HIGH 1 / MEDIUM 0. 수동 검토: 네트워크가 차단된 샌드박스에서 실행 안전(스캐너 지적 사항은 설명됨). 스캔이 깨끗하다고 해서 스킬이 안전하다는 증거는 아닙니다.
설치
npx skills@latest add mattpocock/skills --skill prototype
고정 커밋: 4ae2317ddb22b046e26455e4f9c9b3aaaf62212d
테스트일: 2026-11-02
테스트한 과제
- 구독 상태 모델 프로토타이핑 — 결제가 실패할 때 우리 구독 라이프사이클이 말이 되는지 판단이 서지 않습니다. 상태: trial, active, past_due, paused, canceled. 이벤트: 체험 종료, 결제 성공, 결제 실패, 사용자 일시정지, 사용자 재개, 사용자 취소, 사용자 재활성화. 규칙: 결제가 두 번 실패…
- 가격 페이지 변형 프로토타이핑 — 이 작은 정적 사이트(플랜 3개)의 pricing.html에서 플랜을 어떻게 제시해야 할지 모르겠습니다. 브라우저에서 비교할 수 있도록 해당 섹션의 디자인 옵션을 여러 개 만들어 주세요. 실제 가격 내용은 그대로 유지해야 합니다. 빌드 단계는 없습니다.
- 할인 중복 적용 규칙 프로토타이핑 — 할인을 중복 적용하는 방식이 자연스러운가요? 지금까지의 규칙: 쿠폰 SAVE10은 10% 할인, 쿠폰 HALF는 50% 할인, $50 초과 주문은 무료 배송, 로열티 회원는 추가 5% 할인. 어떤 순서로 적용되는지, 어떤 할인이 중복 가능한지 정하지 못했습니다. 여러 사례를 넣어 보고 어떻게…
장점
- 스킬 없이보다 평균 점수를 3.71에서 4.95로 끌어올렸습니다(+1.23).
- 스킬 이름을 언급하지 않았는데도 적용되었습니다. 스킬 사용군 실행 6/6회에서 스킬 파일을 읽었습니다.
- 토큰 오버헤드 없음: 스킬 없이의 1.02배 토큰을 사용합니다.
- 스킬 사용 시 높은 절대 품질: 4.95/5.
단점
- 과제·그룹당 n=2이며, 약 1점 미만의 차이는 노이즈입니다.
리뷰
Codex CLI 0.166 (gpt-6-astra, low reasoning)을 Mac 테스트 머신에서 실행했고, 실행마다 새 임시 프로젝트와 임시 HOME/TMPDIR/캐시를 사용했습니다. 스킬 설치(스킬 사용군), 미설치(대조군), 미설치 상태에서 스킬의 핵심 요구사항만 한 문장으로 압축해 프롬프트에 덧붙인 경우(한 문장 프롬프트군)로 나눴으며, 과제·그룹당 2회씩 실행했습니다. 네트워크는 끄고 /tmp 쓰기는 차단했습니다. 프롬프트에는 스킬 이름을 언급하지 않았습니다(아래에 적은 경우 제외). 과제는 세 가지입니다. 결제 실패가 있을 때 구독 라이프사이클이 말이 되는지 모델링하고(상태 질문), 정적 가격 섹션의 옵션을 비교하고(디자인 질문, 실제 플랜 내용은 유지해야 함), 할인 중복 적용 규칙을 코딩 전에 사용자가 직접 시험해 보게 하는 것입니다(로직 질문, prototype/에 저장). 규칙 검사 항목에는 자체 완결형 HTML, 다섯 가지 상태 표시, 이벤트별 버튼, 가이드 시나리오, 프로토타입으로 표시, 테스트 파일 없음이 포함되며, 가격 과제에서는 최소 세 가지 변형, ?variant= URL 파라미터, 고정 플로팅 전환기도 확인합니다.
3개 그룹 비교
| 그룹 | 평균 점수 (0-5) | 실행당 토큰 |
|---|---|---|
| 스킬 없음 | 3.71 | 133k |
| 한 문장 프롬프트 | 4.72 | 89k |
| 스킬 사용 | 4.95 | 136k |
Codex CLI에서 18회 실행해 측정했고, LLM 심사 없이 규칙 기반 검사로 채점했습니다. 총점 27.2 / 30, 판정 추천.
판정: 추천 (27.2 / 30). 출처: mattpocock/skills, skills/engineering/prototype, 커밋 4ae2317에 고정. 설치: npx skills@latest add mattpocock/skills --skill prototype. 라이선스: MIT (저장소 LICENSE).
어떤 스킬인가
mattpocock/skills의 prototype 스킬입니다. 설계 질문에 답하는 일회용 프로토타입을 만듭니다. 로직이나 상태 관련 질문에는 상태 패널, 자유 조작 버튼, 안내 시나리오가 있는 단일 HTML 파일을, 디자인 관련 질문에는 URL 파라미터와 하단 플로팅 바를 이용해 전환하는 서로 크게 다른 여러 변형을 한 경로에 만듭니다. 규칙: 일회용임을 분명히 표시, 실행이 간단, 영속성 없음, 다듬지 않음, 테스트 없음. SKILL.md와 LOGIC.md, UI.md로 구성되며 총 약 2,600단어이고 Markdown만 있습니다.
테스트 방법
Codex CLI 0.166(gpt-6-astra, 낮은 추론)을 Mac 테스트 머신에서 실행했고, 실행마다 새 임시 프로젝트와 임시 HOME/TMPDIR/캐시를 사용했습니다. 스킬을 설치한 경우(스킬 사용군), 설치하지 않은 경우(대조군), 스킬의 핵심 요구사항을 한 문장으로 압축해 프롬프트 끝에 붙인 경우(한 문장 프롬프트군)로 나눴고, 작업마다 각 군 2회씩 실행했습니다. 네트워크는 끄고 /tmp 쓰기는 차단했습니다. 프롬프트에는 스킬 이름을 전혀 언급하지 않았습니다(아래에 적은 표현은 예외).
작업은 세 가지입니다. 결제 실패가 있을 때의 구독 생애주기 모델링(상태 질문), 정적 가격 섹션의 옵션 비교(디자인 질문, 실제 플랜 콘텐츠 유지 필수), 할인 중첩 규칙을 코딩 전에 시험(로직 질문, prototype/에 저장). 규칙 검사에는 자체 완결형 HTML, 상태 다섯 개 표시, 이벤트별 버튼, 안내 시나리오, 프로토타입 표시, 테스트 파일 없음이 포함되고, 가격 작업에는 변형 세 개 이상, ?variant= URL 파라미터, 고정 플로팅 전환기가 포함됩니다.
- 구독 상태 모델 프로토타입 — 결제가 실패할 때 우리 구독 생애주기가 말이 되는지 모르겠습니다. 상태: trial, active, past_due, paused, canceled. 이벤트: 체험 종료, 결제 성공, 결제 실패, 사용자 일시정지, 사용자 재개, 사용자 취소, 사용자 재활성화. 규칙: 결제 두 번 실패…
- 가격 페이지 변형 프로토타입 — 이 작은 정적 사이트(플랜 세 개)의 pricing.html에서 플랜을 어떻게 제시해야 할지 모르겠습니다. 브라우저에서 비교할 수 있도록 그 섹션의 서로 다른 디자인 옵션 몇 개를 만들어 주세요. 실제 가격 콘텐츠는 유지해야 합니다. 빌드 단계는 없습니다.
- 할인 중첩 규칙 프로토타입 — 할인 중첩이 자연스럽게 느껴질까요? 지금까지의 규칙: 쿠폰 SAVE10은 10% 할인, 쿠폰 HALF는 50% 할인, $50 초과 주문은 무료 배송, 로열티 회원은 추가 5% 할인. 어떤 순서로 적용되는지, 어떤 할인이 중첩될 수 있는지 정할 수 없습니다. 경우를 시험해 보고 무엇이…
채점은 프로그램 방식(숨은 테스트, 심어 둔 문제 탐지, 제약 조건 검사, 해당되는 경우 렌더링+OCR)으로 실행당 0~5점입니다. 점수를 결정한 LLM 심사자는 없습니다.
결과
세 번째 군에 전달한 한 문장 프롬프트: "명시된 질문 하나에 답하는 일회용 프로토타입을 만드세요. 로직이나 상태 질문에는 질문을 눈에 보이게 적은 단일 자체 완결형 HTML 파일, 클릭할 때마다 다시 렌더링되는 읽기 쉬운 현재 상태 패널, 동작마다 버튼 하나, 안내 시나리오(정상 경로, 경계 사례, 잘못된 동작)를 넣으세요. 디자인 질문에는 한 페이지에 서로 크게 다른 변형 세 개를 두고 ?variant= URL 파라미터와 하단 플로팅 바로 전환하세요. 테스트도, 다듬기도 없이."
| 작업 | 대조군 점수 | 한 문장 프롬프트 | 스킬 사용 | 대조군 토큰 | 한 문장 프롬프트 토큰 | 스킬 사용 토큰 | 스킬 읽음 |
|---|---|---|---|---|---|---|---|
| t1-subscription-logic | 4.64 | 4.4 | 4.84 | 155k | 51k | 134k | 2/2 |
| t2-pricing-ui | 2.5 | 5.0 | 5.0 | 125k | 153k | 133k | 2/2 |
| t3-discount-stacking | 4.0 | 4.75 | 5.0 | 119k | 62k | 139k | 2/2 |
평균 점수: 스킬 없이 3.71, 스킬 사용 시 4.95(델타 +1.23). 실행당 토큰: 133k 대 136k(1.02배), 시간 186초 대 149초. 한 문장 프롬프트군: 4.72(한 문장 프롬프트 대비 스킬의 이득: +0.23, 스킬 없는 경우 대비 한 문장 프롬프트의 이득: +1.01). 한 문장 프롬프트는 실행당 89k 토큰을 쓰므로, 스킬은 한 문장 프롬프트의 1.52배 비용입니다.
실제로 있었던 일
- 평균 점수는 대조군 3.71, 한 문장 버전 4.72, 스킬 4.95였습니다. 스킬은 대조군보다 +1.24, 한 문장 프롬프트보다 +0.23이며, 실행당 136k 토큰으로 대조군 133k(1.02배), 한 문장 프롬프트 89k(1.5배)입니다.
- 디자인 작업에서 효과가 드러납니다. 스킬은 두 실행 모두에서 하단 플로팅 전환기와 URL로 전환 가능한 변형 세 개를 만들었고(우리 검사에서 5.0, 5.0), 대조군은 4.0과 1.0이었습니다. 두 실행 모두 플로팅 바가 없었고, 한 실행은 전환기와 URL 파라미터가 있는 레이아웃 세 개, 다른 실행은 없었으며, 한 실행에서는 플랜 가격이 페이지에서 빠져 있었습니다.
- 로직 작업 두 개에서는 대조군도 이미 상호작용 HTML을 만들었습니다(구독 모델 4.4〜4.8, 할인 중첩 4.0). 스킬이 더하는 것은 안내 시나리오와 프로토타입 라벨입니다. 시나리오는 스킬 실행 4회 중 4회, 대조군 4회 중 2회에서 나타났습니다.
- 한 문장 버전은 가격 작업에서 동등했고, 로직 작업에서는 파일을 항상 프로토타입으로 표시하지 않아(4회 중 2회) 조금 뒤졌습니다.
항목별 점수
| 항목 | 점수 | 이유 |
|---|---|---|
| 1_output_quality | 4.95 | 스킬 사용 시 평균 4.95/5점(프로그램 검사, 작업별 표 참조). |
| 2_lift_vs_no_skill | 3.23 | 스킬 없이 3.71점 대비 +1.23점(작업당 n=2, 약 1점 미만의 차이는 노이즈). |
| 3_trigger | 5.0 | 스킬 사용군 6/6 실행에서 스킬 파일이 읽힘. |
| 4_instructions_portability | 4 | 평범한 Markdown. 'capture' 단계를 위해 태스크 러너와 git을 가정하며, 이 단계는 선택 사항입니다. |
| 5_efficiency | 5 | 토큰 1.02배(실행당 136k 대 133k), 시간 0.80배(149초 대 186초). |
| 6_safety_hygiene | 5 | Markdown만 있음. 스크립트 없음. |
이 테스트의 한계
- 기능(변형, 플로팅 바, 시나리오)에 대한 규칙 기반 검사입니다. 디자인의 품질과 프로토타입이 질문에 답하는지는 사람이 평가하지 않았습니다.
- 분석 중 채점 기준을 두 번 수정했습니다. 변형이 별도 CSS/JS 파일에 있어도 되고, 레이아웃 전환도 변형으로 인정합니다. 첫 번째 패스는 이를 과소 집계했으므로 이전 수치는 사용하지 않습니다.
- 프로토타입을 일회용 브랜치에 커밋하고 이슈에 포인터를 남기라는 스킬의 조언은 임시 폴더에서 테스트할 수 없습니다.
- 작업·군당 n = 2: 약 1점 미만의 차이는 노이즈입니다.
- 규칙 기반 채점은 검사가 볼 수 있는 것만 측정합니다. 취향이나 결과가 최선인지는 판단할 수 없습니다.
보안
security.md를 참조하세요. 스캔: CRITICAL 1 / HIGH 1 / MEDIUM 0. 판정: 실행해도 안전(네트워크 비활성 샌드박스). 깨끗한 스캔 결과가 스킬의 안전성을 증명하지는 않습니다.
결론
이 스킬은 Codex가 설명한 종류의 프로토타입(URL로 전환하는 변형, 플로팅 바, 안내 시나리오)을 만들도록 분명히 이끕니다. 평범한 요청으로는 그렇게 되지 않으며, 추가 토큰 비용도 없습니다. 한 문장 요약도 같은 동작의 대부분을 얻지만, 스킬은 로직 안내와 프로토타입 라벨링의 세부를 더합니다.
트랜스크립트
실행 로그: prototype (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.) 열: 작업, 그룹-회차, 점수(0-5), 토큰, 초, 통과한 검사, 에이전트가 연 스킬 파일. t1-subscription-logic control-1: 점수 4.84, 토큰 138434, 초 186.6, 검사 6/7, 연 파일 없음 t1-subscription-logic control-2: 점수 4.44, 토큰 171950, 초 379.3, 검사 6/7, 연 파일 없음 t1-subscription-logic oneliner-1: 점수 4.68, 토큰 51299, 초 95.1, 검사 6/7, 연 파일 없음 t1-subscription-logic oneliner-2: 점수 4.13, 토큰 52046, 초 163.3, 검사 5/7, 연 파일 없음 t1-subscription-logic treatment-1: 점수 4.68, 토큰 144823, 초 163.1, 검사 6/7, 연 파일 prototype t1-subscription-logic treatment-2: 점수 5.0, 토큰 124780, 초 165.0, 검사 7/7, 연 파일 prototype t2-pricing-ui control-1: 점수 4.0, 토큰 169276, 초 134.1, 검사 5/6, 연 파일 없음 t2-pricing-ui control-2: 점수 1.0, 토큰 81988, 초 97.9, 검사 2/6, 연 파일 없음 t2-pricing-ui oneliner-1: 점수 5.0, 토큰 153260, 초 107.2, 검사 6/6, 연 파일 없음
18회 실행, 아티팩트 3개
샘플 출력
SOTA · With the skill: prototype/index.html (t1-subscription-logic, run 1, Codex)
<!doctype html> <html lang="en"><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Subscription lifecycle prototype</title> <style> *{box-sizing:border-box}body{font:16px/1.5 system-ui,sans-serif;background:#f3f6f3;color:#243b31;margin:0}main{max-width:1080px;margin:auto;padding:32px 24px}h1{font-size:32px;letter-spacing:-1px;margin:8px 0}h2{font-size:19px;margin-top:0}.eyebrow{color:#49715f;letter-spacing:2px;font-size:12px;text-transform:uppercase}.panel{background:white;border:1px solid #d8e3db;border-radius:12px;padding:24px;margin:20px 0}.buttons,.tabs,.flow{display:flex;flex-wrap:wrap;gap:8px}button,select{font:inherit;color:#245940;background:white;border:1px solid #b6ccbe;border-radius:6px;padding:9px 12px}button{cursor:pointer}button:hover{background:#edf5ef}button:focus-visible,select:focus-visible{outline:3px solid #589c7b;outline-offset:2px}button:disabled{opacity:.45;cursor:default}.current,[aria-selected=true]{background:#206d50;color:white}.flow span{padding:6px 15px;border:1px solid #d8e3db;border-radius:25px}dl{display:grid;grid-template-columns:repeat(4,1fr);gap:20px}dt,small,.muted{color:#5a7064}dt{font-size:12px}dd{margin:4px 0;font-weight:650}.notice{background:#eef6f0;border-left:3px solid #206d50;padding:12px}.columns{display:grid;grid-template-columns:1.2fr 1fr;gap:20px}.columns .panel{margin:0}.steps{display:grid;gap:8px}.steps button{text-align:left}.history{max-height:360px;overflow:auto}table{width:100%;border-collapse:collapse;font-size:13px}td,th{text-align:left;padding:10px 6px;border-bottom:1px solid #e0e8e2;vertical-align:top}li{margin:10px 0}select{max-width:100%;margin-top:10px}summary{cursor:pointer;font-weight:600}@media(max-width:700px){.columns{grid-template-columns:1fr}dl{grid-template-columns:repeat(2,1fr)}main{padding:20px 16px}} </style><main> <div class="eyebrow">Throwaway prototype · No saved data</div><h1>When payments fail, what happens next?</h1><p>Do these five subscription states behave as intended? Try events, inspect the full state, and walk through payment failures, pauses, and reactivation before implementation.</p> <section class="panel"><label for="policy"><strong>Interpret “two failed payments in a row while past_due”</strong></label><br><select id="policy"><option value="3">Two more failures while already past due (3 total)</option><option value="2">Two consecutive failures total (including entry into past due)</option></select><p><small>Default: literal “while already past due” reading. Changing the interpretation resets the simulation.</small></p><div id="snapshot"></div><div class="notice" id="notice" role="status" aria-live="polite">New trial account. No charges attempted.</div></section> <section class="panel"><h2>Try any event</h2><div class="buttons" id="events"></div><p><small>Payment buttons represent new charge attempts and their outcomes, not delayed notifications. Invalid events stay clickable so you can see why they are blocked.</small></p><div class="buttons"><button id="day">Advance 1 day</button><button id="month">Advance 30 days</button><button id="reset">Reset to trial</button></div></section> <div class="columns"><section [... excerpt: first 3200 of 13238 characters]