prototype

name	prototype
description	클릭·상태전환이 되는 자체 완결 HTML/JS 인터랙티브 프로토타입을 만들어 저장·브라우저 실행한다. "프로토타입 만들어줘 / 눌러볼 수 있게 해줘 / 바이브코딩으로 검증하고 싶어 / 인터랙션 되는 화면 / 동작하는 데모 / 실제로 클릭해보게" 할 때 트리거.

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

prototype — 눌러서 검증하는 인터랙티브 프로토타입

말로만 "이렇게 동작해요"는 못 믿는다. 직접 클릭하고 상태가 바뀌는 걸 봐야 아이디어의 구멍이 보인다. 이 스킬은 외부 리소스 없는 자체 완결 HTML/JS 한 파일을 만들어 저장하고 브라우저로 띄운다.

이건 검증용이지 프로덕션 코드가 아니다. 개발팀에 "이대로 만들어주세요"라고 넘기는 물건이 아니라, 우리끼리 "이 흐름이 말이 되나" 확인하는 도구다. 이 점을 결과물 상단 주석에도 명시한다.

공통 원칙 (모든 산출물에 적용)

1. 왜 만드는가: 이 프로토타입으로 검증하려는 가설/질문을 한 줄로 먼저 적는다. (예: "3단계 온보딩이 정말 3번 안에 끝나나?")
2. 근거/출처: 화면 흐름·문구의 근거가 스펙([[write-spec]])이나 리서치([[research-synthesis]])에 있으면 링크로 남기고, 없으면 지어내지 말고 <!-- 확인 필요: ~ --> 주석으로 표시.
3. 반자동: AI가 초안 프로토타입을 만들면 사람이 직접 눌러보고 판단한다. 자동 생성 결과를 그대로 신뢰하지 않는다.
4. 코칭(신입 성장): 신입에겐 "한 방에 완성" 대신 작은 단위부터 만들어 눌러 검증하는 습관을 가르친다.

절대 규칙

• 외부 리소스 금지. CDN, 폰트, 이미지 URL, fetch 전부 금지. CSS/JS는 전부 인라인, 데이터는 하드코딩. (오프라인·재현 가능해야 검증이 된다.)
• 상태는 JS 변수/localStorage로만. 서버 없음.

워크플로우

1. 검증할 가설 확정 → 필요한 최소 화면·인터랙션만 정한다. (전체 앱 만들지 마라.)
2. 초안 생성: AI가 단일 index.html(인라인 CSS/JS, 서버 없음)을 직접 작성해 ~/.pm-copilot/data/prototypes/<이름>/index.html에 저장한다. 시각/화면은 [[mockup]]·[[simple-design]] 참고.
3. 브라우저 실행: open ~/.pm-copilot/data/prototypes/<이름>/index.html
4. 직접 눌러 검증 (아래 체크리스트) → 구멍 발견 시 수정 → 반복.

검증 체크리스트 (무지성 방지 — 반드시 직접 눌러라)

• 핵심 클릭 흐름이 처음부터 끝까지 끊김 없이 되나?
• 빈 값/뒤로가기/두 번 클릭 같은 예외 상황도 눌러봤나?
• 상태 전환(로딩→완료, 열림→닫힘)이 실제로 눈에 보이나?
• AI가 그럴듯하게 만든 부분에 **가짜 동작(버튼만 있고 반응 없음)**은 없나?
• 검증하려던 가설에 "예/아니오"로 답할 수 있게 됐나?

예시 (최소 프로토타입 골격)

<!-- 검증 가설: 좋아요 토글이 즉각 피드백을 주는가 / 프로덕션 코드 아님 -->
<button id="like">🤍 0</button>
<script>
  let liked=false,n=0,b=document.getElementById('like');
  b.onclick=()=>{liked=!liked;n+=liked?1:-1;b.textContent=(liked?'❤️':'🤍')+' '+n;};
</script>

관련 스킬

• 흐름/화면 정의가 먼저면 → [[screen-spec]], [[write-spec]]
• 정적 화면만 필요하면 → [[mockup]], [[simple-design]]
• 판단이 막히면 → [[ask-sunbae]]