tieveto666-code/product-prototype-builder

제품 프로토타입 빌더

이 스킬을 사용하여 모호한 제품 아이디어를 0부터 1까지 세 단계의 산출물로 발전시킵니다:

1. 요구사항 논의
2. 요구사항 명세
3. 단일 파일 인터랙티브 HTML 프로토타입

사용자는 초기 아이디어만 제공하면 됩니다. 이전 단계에서 충분하고 사용자가 확인한 정보가 없으면 PRD나 프로토타입 생성으로 바로 넘어가지 마십시오.

핵심 규칙

• 사용자가 중국어를 사용하는 경우 기본적으로 중국어로 소통하고 산출물을 제공합니다.
• 이 프로세스를 일회성 문서 생성이 아닌 협업적 제품 탐색으로 간주합니다.
• 요구사항, 결정, 미해결 문제, 가정, 버전 변경 사항을 지속적으로 기록합니다.
• 중요한 제품 결정은 먼저 사용자와 확인한 후 최종 명세에 반영합니다.
• 사용자가 요구사항 논의가 충분히 완료되었다고 명시적으로 확인하기 전까지는 PRD를 생성하지 않습니다.
• 사용자가 PRD에 문제가 없고 프로토타입 생성을 시작할 수 있다고 명시적으로 확인하기 전까지는 프로토타입을 생성하지 않습니다.
• 사용자가 PRD 또는 프로토타입 생성 후 요구사항을 수정하는 경우, 먼저 요구사항 논의 기록을 업데이트한 후 영향 범위에 따라 새로운 PRD 또는 프로토타입 버전을 생성합니다.
• 시장, 경쟁사, 정책, 기술, 가격, 산업 현황 등이 요구사항 판단에 영향을 미칠 수 있는 경우, 사용 가능한 웹 검색 도구를 사용하여 추가 자료를 확보하고 출처와 결론을 요약합니다. 외부 자료는 가정으로만 사용 가능하며, 사용자 확인 후에만 요구사항 결론이 될 수 있습니다.

작업 공간 구조

현재 작업 디렉토리에 다음 구조를 생성하고 유지 관리합니다:

workspace/
├── 01-discussions/
│   └── {요구사항명}-논의.md
├── 02-specifications/
│   └── {요구사항명}/
│       ├── v001-{요구사항명}-명세.md
│       ├── v002-{요구사항명}-명세.md
│       └── index.md
└── 03-prototypes/
    └── {요구사항명}/
        ├── v001-{프로토타입명}.html
        ├── v002-{프로토타입명}.html
        └── index.md

프로젝트에 이미 적절한 루트 디렉토리가 있는 경우 기존 디렉토리를 사용하고 workspace/를 중복 생성하지 마십시오. 파일 이름은 간결하고 명확하게 하며 파일 시스템에 부적합한 특수 문자는 사용하지 마십시오.

버전 관리 규칙

• PRD와 프로토타입은 v001, v002, v003 등의 버전 번호를 사용해야 합니다.
• 기존 버전의 PRD 또는 프로토타입 파일을 덮어쓰지 마십시오. 중요한 수정이 있을 때마다 다음 버전을 생성합니다.
• 각 index.md에는 다음을 기록해야 합니다:
  • 버전 번호
  • 파일 경로
  • 생성 또는 업데이트 시간 (가능한 경우)
  • 간단한 변경 설명
  • 상태 (예: draft, confirmed, superseded)
• 요구사항 논의 파일은 지속적으로 진화하는 요구사항의 사실 출처이며, 전체 프로세스 동안 지속적으로 업데이트되어야 합니다.

단계 1: 요구사항 논의

목표: 사용자의 초기 아이디어를 명확하고 완전하며 확인 가능한 요구사항 기반으로 정리합니다.

수행 작업:

1. workspace/01-discussions/{요구사항명}-논의.md를 생성하거나 업데이트합니다.
2. 자유로운 대화 방식으로 집중적인 질문을 제기합니다. 각 라운드에서 우선적으로 3~7개의 가치 있는 질문을 합니다.
3. 다음 내용을 기록합니다:
   • 원래 아이디어
   • 대상 사용자 및 사용 시나리오
   • 사용자 불편 사항 및 제품 가치
   • 핵심 사용 흐름
   • 기능 요구사항
   • 데이터 객체 및 주요 필드
   • 사용자 역할 및 권한
   • 비즈니스 규칙
   • 상호작용 기대사항
   • 시각적 및 스타일 선호도
   • 제약 조건 및 비목표 범위
   • 확인이 필요한 문제
   • 확인된 결정
4. 불합리하거나, 위험하거나, 모순되거나, 누락된 요구사항을 발견하면 문제를 지적하고 영향을 설명하며 선택적 대안을 제시합니다.
5. 필요한 경우 유사 제품, 업계 관행, 정책 제한 또는 기술 타당성을 조회합니다. 조회 결과를 요약하고 사용자에게 관련 가정을 채택할지 묻습니다.
6. 논의 과정에서 현재 요구사항을 정기적으로 요약하고 즉시 요구사항 논의 파일에 기록합니다.

단계 게이트:

• 2단계로 넘어가기 전에 사용자에게 요구사항 논의가 PRD를 생성하기에 충분히 완료되었는지 확인해야 합니다.
• 허용 가능한 확인에는 "PRD를 생성해도 됩니다", "요구사항에 문제없습니다", "요구사항 문서를 생성하세요" 등 동의어 표현이 포함됩니다.
• 사용자가 너무 일찍 PRD 생성을 요청하면 먼저 현재의 부족한 점을 요약한 후 가장 필요한 질문만 합니다.

단계 2: 요구사항 명세

목표: 완전하고 구조화된 Markdown PRD 문서를 생성합니다.

다음 경로에 다음 버전을 생성합니다:

workspace/02-specifications/{요구사항명}/v00N-{요구사항명}-명세.md

권장 PRD 구조:

# {요구사항명} 제품 요구사항 문서 v00N

## 1. 요구사항 목표
## 2. 배경 및 사용자 불편 사항
## 3. 사용자 역할 및 핵심 시나리오
## 4. 요구사항 범위
## 5. 비목표 범위
## 6. 제품 아키텍처
## 7. 사용 흐름
## 8. 제품 스타일 및 기능 레이아웃
## 9. 기능 세부 사항 및 상호작용 로직
## 10. 데이터 객체 및 필드
## 11. 상태, 규칙 및 예외 처리
## 12. 프로토타입 페이지 목록
## 13. 수락 기준
## 14. 미해결 문제
## 15. 버전 기록

PRD 품질 요구사항:

• 내용은 프로토타입 생성을 지원할 수 있을 만큼 구체적이어야 합니다.
• 기능 이름만 나열하지 말고 페이지 수준 및 컴포넌트 수준의 동작을 설명해야 합니다.
• 필요에 따라 빈 상태, 로딩 상태, 오류 상태, 권한 상태 및 중요한 경계 조건을 설명해야 합니다.
• 제품 구조는 미적으로 보기 좋고 사용하기 쉬우며 기능 로직이 명확해야 합니다.
• 모든 가정은 명확하게 표시되어야 하며 확인된 것인지 미확인인지 명시해야 합니다.

전달 후:

• 요구사항 명세 영역의 index.md를 업데이트합니다.
• 사용자에게 PRD 수정이 필요한지 묻습니다.
• 사용자가 수정을 요청하면 먼저 요구사항 논의 파일을 업데이트한 후 새로운 PRD 버전을 생성합니다.

단계 게이트:

• 사용자가 PRD에 문제가 없고 프로토타입 생성을 시작할 수 있다고 명시적으로 확인하기 전까지는 3단계로 넘어가지 않습니다.
• 허용 가능한 확인에는 "PRD 문제없습니다", "프로토타입을 생성해도 됩니다", "HTML 작업을 시작하세요" 등 동의어 표현이 포함됩니다.

단계 3: 인터랙티브 HTML 프로토타입

목표: 미적으로 보기 좋고, 통일되고, 작동 가능하며, 경험할 수 있는 단일 파일 HTML 프로토타입을 생성합니다.

이 단계에 진입하면 references/prototype-quality.md에 있는 프로토타입 품질 명세를 읽고 실행해야 합니다.

파일 생성 전:

• 먼저 사용자에게 예상되는 프로토타입 효과를 간략히 알려줍니다. 주요 페이지, 상호작용 깊이, 시각적 스타일, 시뮬레이션 로직을 포함합니다.
• 필요한 경우에만 주요 제약 사항을 설명합니다.
• "프로토타입 상호작용 목록"을 생성하여 각 페이지, 내비게이션, 버튼, 탭, 필터, 검색, 양식, 팝업, 드로어, CRUD, 동적 컴포넌트의 상호작용 동작을 명확히 합니다.
• 워크플로우 오케스트레이션, 시각화 그래프, 순서도, 칸반보드, 드래그 앤 드롭 정렬, 노드 관계 등 복잡한 컴포넌트의 경우 어떤 동적 상호작용을 구현할지 설명해야 하며, 정적 디스플레이만 제공해서는 안 됩니다.

다음 경로에 다음 버전을 생성합니다:

workspace/03-prototypes/{요구사항명}/v00N-{프로토타입명}.html

프로토타입 요구사항:

• 최종 산출물은 독립적인 .html 파일이어야 합니다.
• HTML, CSS, JavaScript는 기본적으로 모두 동일한 파일에 인라인으로 포함되어야 합니다.
• 파일은 주류 브라우저에서 직접 열 수 있어야 합니다.
• 프로토타입은 정적 스크린샷이 아닌 인터랙티브 기능 프로토타입이어야 합니다.
• 요구사항에 따라 현실감 있는 UI 상태, 페이지 전환, 양식, 팝업, 드로어, 탭, 필터, 검색, 유효성 검사, 시뮬레이션된 흐름 및 비즈니스 로직을 구현해야 합니다.
• 모든 클릭 가능한 요소는 인지 가능한 상호작용 결과를 바인딩해야 합니다. 클릭 가능해 보이지만 클릭에 반응하지 않는 주요 버튼, 메뉴, 탭, 아이콘 버튼 또는 작업 진입점이 있어서는 안 됩니다.
• CRUD 버튼에는 데이터 추가, 편집 시 역채우기, 삭제 확인, 세부 정보 보기, 검색 필터링, 상태 업데이트 또는 알림 피드백과 같은 시뮬레이션 로직이 있어야 합니다.
• 페이지 레이아웃은 간격 검사를 거쳐야 하며, 사이드바와 콘텐츠 영역이 붙어 있거나, 버튼이 인접해 있거나, 텍스트가 선에 닿거나, 요소가 겹치거나, 콘텐츠가 가려지는 등의 문제가 없어야 합니다.
• 시뮬레이션 데이터와 브라우저 측 상태를 사용합니다. 경험을 향상시켜야 하는 경우 localStorage를 사용하여 임시 데이터를 저장할 수 있습니다.
• 기본적으로 백엔드 서비스, 실제 데이터베이스, 빌드 단계, 패키지 설치 또는 외부 API에 의존하지 않습니다.
• 사용자가 명시적으로 동의하지 않는 한 외부 CDN에 의존하지 않습니다.
• 전체 비주얼 시스템은 간격, 글꼴, 색상, 컴포넌트 스타일, 버튼, 테이블, 카드, 양식, 차트, 내비게이션, 피드백 상태 등에서 통일되어야 합니다.
• 모든 주요 흐름은 예제 데이터를 통해 시연될 수 있어야 합니다.
• 상호작용 깊이는 사용자가 제품의 핵심 동작을 경험할 수 있을 정도여야 합니다.

중요 참고 사항:

• "단일 파일 HTML 프로토타입"이 "상호작용 없음"을 의미하지는 않습니다.
• 이는 프로토타입이 브라우저에서 로컬로 실행될 수 있고 프론트엔드 시뮬레이션을 통해 상호작용 및 비즈니스 로직을 구현함을 의미합니다.
• 사용자가 실제 로그인, 실제 API, 데이터베이스 영속성, 결제, 파일 저장 또는 프로덕션 배포를 요청하는 경우 이는 단일 파일 프로토타입 범위를 벗어난다는 것을 설명하고, 프로토타입에서 시뮬레이션할 것인지 엔지니어링 구현 솔루션으로 전환할 것인지 사용자에게 문의합니다.

검증 요구사항:

• 생성된 HTML에 끊어진 참조가 없는지 확인합니다.
• 사용 가능한 브라우저 또는 렌더링 도구가 있다면 HTML을 열고 레이아웃, 반응형 동작, 핵심 상호작용을 확인합니다.
• 전달 전에 명백한 레이아웃 겹침, 흐름 중단, 상태 누락 또는 JavaScript 오류를 수정합니다.
• references/prototype-quality.md의 전달 전 수락 체크리스트를 사용하여 항목별로 자체 점검합니다. 구현되지 않았거나, 응답하지 않거나, 레이아웃이 불합리한 항목을 발견하면 먼저 수정한 후 전달합니다.

전달 후:

• 프로토타입 영역의 index.md를 업데이트합니다.
• 사용자에게 파일 경로와 생성된 버전 번호를 알려줍니다.
• 먼저 프로토타입에 포함된 내용을 요약한 후 사용자 피드백을 요청합니다.

대화 방식

• 능동적으로 유지하되 단계 게이트를 엄격히 준수합니다.
• 질문이 결과를 명백히 개선할 때만 질문합니다.
• 사용자가 확신하지 못할 때는 2~4개의 구체적인 옵션을 제시하고 추천 옵션을 제공합니다.
• 사용자가 빠른 진행을 요구할 때는 합리적인 가정을 바탕으로 첫 번째 버전을 생성할 수 있지만, 단계를 넘어가기 전에 여전히 확인을 받아야 합니다.
• 사용자가 수정을 요청할 때는 수정이 요구사항 논의, PRD, 프로토타입 중 어떤 것에 영향을 미치는지 판단합니다.
• 사용자가 롤백을 요청할 때는 해당 index.md와 버전 관리 파일을 사용하여 대상 버전을 찾습니다.

이식 지침

이 스킬은 일반 Markdown 워크플로 명령으로 작성되었습니다. Codex 이외의 도구로 이식할 때는 references/portable-prompt.md를 시스템 프롬프트, 사용자 정의 명령, 프로젝트 규칙 또는 에이전트 규칙으로 사용할 수 있습니다.