@su-record/vibe 2.9.4 → 2.9.6

package/skills/{vibe.interview → vibe-interview}/checklists/api.md

@@ -1,101 +1,101 @@
-# Discovery Checklist: API / Backend
-
-> REST, GraphQL, gRPC, 마이크로서비스 등 **UI 없는 백엔드 시스템**.
-
-## Required
-
-### R1. purpose
-**Q**: 이 API/백엔드가 해결하는 문제는 무엇인가요?
-
-### R2. consumers
-**Q**: 누가 이 API를 사용하나요?
-**힌트**: 자사 프론트엔드, 외부 개발자, 모바일 앱, 파트너 시스템, 내부 서비스.
-**follow-up**: "공개 API인가요, 내부용인가요?"
-
-### R3. core-endpoints
-**Q**: 주요 리소스/엔드포인트는?
-**힌트**: 예) Users, Products, Orders. CRUD 수준 대략.
-
-### R4. data-model
-**Q**: 주요 엔티티와 관계는?
-**힌트**: ERD 수준 불필요, 핵심만.
-
-### R5. auth-strategy
-**Q**: 인증/인가 방식은?
-**힌트**: API Key, JWT, OAuth2, mTLS, 인증 없음. Scope/Role 필요?
-
-### R6. protocol
-**Q**: API 프로토콜은?
-**힌트**: REST / GraphQL / gRPC / WebSocket / 혼합.
-
-### R7. tech-stack
-**Q**: 기술 스택은?
-**힌트**: 언어/프레임워크(Node/FastAPI/Go/Rust), DB(Postgres/Mongo/Redis), 호스팅.
-
-### R8. performance-slo
-**Q**: 성능 SLO가 있나요?
-**힌트**: 예) p95 응답 시간 < 200ms, 처리량 1000 req/s.
-
-### R9. success-metric
-**Q**: 성공 기준은?
-**힌트**: Uptime, 응답 시간, 에러율, API 사용량.
-
-## Optional
-
-### O1. versioning-strategy
-**Q**: API 버저닝 전략이 있나요?
-**힌트**: URL(/v1/), 헤더, 없음.
-
-### O2. rate-limiting
-**Q**: Rate limiting이 필요한가요?
-**힌트**: Tier별(free/paid), 전역, IP 기반.
-
-### O3. caching-strategy
-**Q**: 캐싱 전략이 있나요?
-**힌트**: HTTP 캐시, Redis, CDN, Edge.
-
-### O4. async-jobs
-**Q**: 비동기 작업/큐가 필요한가요?
-**힌트**: BullMQ, SQS, Kafka, Temporal.
-
-### O5. webhooks
-**Q**: 웹훅 지원이 필요한가요?
-
-### O6. documentation
-**Q**: API 문서 자동화는?
-**힌트**: OpenAPI/Swagger, GraphQL 스키마, Postman, Scalar.
-
-### O7. sdk-generation
-**Q**: 클라이언트 SDK 생성이 필요한가요?
-**힌트**: 언어별(TS/Python/Go), OpenAPI 기반 생성.
-
-### O8. observability
-**Q**: 관측(logging/metrics/tracing)은?
-**힌트**: OpenTelemetry, Datadog, Honeycomb, Grafana.
-
-### O9. error-handling
-**Q**: 에러 응답 포맷 표준이 있나요?
-**힌트**: RFC 7807 (Problem Details), 자체 포맷.
-
-### O10. data-retention
-**Q**: 데이터 보존/삭제 정책은?
-
-### O11. backup-recovery
-**Q**: 백업/복구 전략은?
-**힌트**: RPO/RTO 목표.
-
-### O12. compliance
-**Q**: 규제 준수 요구가 있나요?
-**힌트**: GDPR, HIPAA, PCI-DSS, SOC2.
-
-### O13. multi-tenant
-**Q**: 멀티테넌트 구조인가요?
-**힌트**: Shared DB / DB-per-tenant / Schema 분리.
-
-### O14. testing-strategy
-**Q**: 테스트 전략은?
-**힌트**: 계약 테스트(Pact), 통합 테스트, 부하 테스트(k6).
-
-### O15. deployment
-**Q**: 배포 방식은?
-**힌트**: Docker, Kubernetes, Serverless, Blue-Green, Canary.
+# Discovery Checklist: API / Backend
+
+> REST, GraphQL, gRPC, 마이크로서비스 등 **UI 없는 백엔드 시스템**.
+
+## Required
+
+### R1. purpose
+**Q**: 이 API/백엔드가 해결하는 문제는 무엇인가요?
+
+### R2. consumers
+**Q**: 누가 이 API를 사용하나요?
+**힌트**: 자사 프론트엔드, 외부 개발자, 모바일 앱, 파트너 시스템, 내부 서비스.
+**follow-up**: "공개 API인가요, 내부용인가요?"
+
+### R3. core-endpoints
+**Q**: 주요 리소스/엔드포인트는?
+**힌트**: 예) Users, Products, Orders. CRUD 수준 대략.
+
+### R4. data-model
+**Q**: 주요 엔티티와 관계는?
+**힌트**: ERD 수준 불필요, 핵심만.
+
+### R5. auth-strategy
+**Q**: 인증/인가 방식은?
+**힌트**: API Key, JWT, OAuth2, mTLS, 인증 없음. Scope/Role 필요?
+
+### R6. protocol
+**Q**: API 프로토콜은?
+**힌트**: REST / GraphQL / gRPC / WebSocket / 혼합.
+
+### R7. tech-stack
+**Q**: 기술 스택은?
+**힌트**: 언어/프레임워크(Node/FastAPI/Go/Rust), DB(Postgres/Mongo/Redis), 호스팅.
+
+### R8. performance-slo
+**Q**: 성능 SLO가 있나요?
+**힌트**: 예) p95 응답 시간 < 200ms, 처리량 1000 req/s.
+
+### R9. success-metric
+**Q**: 성공 기준은?
+**힌트**: Uptime, 응답 시간, 에러율, API 사용량.
+
+## Optional
+
+### O1. versioning-strategy
+**Q**: API 버저닝 전략이 있나요?
+**힌트**: URL(/v1/), 헤더, 없음.
+
+### O2. rate-limiting
+**Q**: Rate limiting이 필요한가요?
+**힌트**: Tier별(free/paid), 전역, IP 기반.
+
+### O3. caching-strategy
+**Q**: 캐싱 전략이 있나요?
+**힌트**: HTTP 캐시, Redis, CDN, Edge.
+
+### O4. async-jobs
+**Q**: 비동기 작업/큐가 필요한가요?
+**힌트**: BullMQ, SQS, Kafka, Temporal.
+
+### O5. webhooks
+**Q**: 웹훅 지원이 필요한가요?
+
+### O6. documentation
+**Q**: API 문서 자동화는?
+**힌트**: OpenAPI/Swagger, GraphQL 스키마, Postman, Scalar.
+
+### O7. sdk-generation
+**Q**: 클라이언트 SDK 생성이 필요한가요?
+**힌트**: 언어별(TS/Python/Go), OpenAPI 기반 생성.
+
+### O8. observability
+**Q**: 관측(logging/metrics/tracing)은?
+**힌트**: OpenTelemetry, Datadog, Honeycomb, Grafana.
+
+### O9. error-handling
+**Q**: 에러 응답 포맷 표준이 있나요?
+**힌트**: RFC 7807 (Problem Details), 자체 포맷.
+
+### O10. data-retention
+**Q**: 데이터 보존/삭제 정책은?
+
+### O11. backup-recovery
+**Q**: 백업/복구 전략은?
+**힌트**: RPO/RTO 목표.
+
+### O12. compliance
+**Q**: 규제 준수 요구가 있나요?
+**힌트**: GDPR, HIPAA, PCI-DSS, SOC2.
+
+### O13. multi-tenant
+**Q**: 멀티테넌트 구조인가요?
+**힌트**: Shared DB / DB-per-tenant / Schema 분리.
+
+### O14. testing-strategy
+**Q**: 테스트 전략은?
+**힌트**: 계약 테스트(Pact), 통합 테스트, 부하 테스트(k6).
+
+### O15. deployment
+**Q**: 배포 방식은?
+**힌트**: Docker, Kubernetes, Serverless, Blue-Green, Canary.

package/skills/{vibe.interview → vibe-interview}/checklists/feature.md

@@ -1,88 +1,88 @@
-# Discovery Checklist: Feature (기존 프로젝트에 추가)
-
-> 이미 존재하는 프로젝트에 **새 기능 추가**하거나 **기존 기능 확장**.
-> 체크리스트는 타입(website/webapp/mobile/api/library)과 겹치는 부분이 많으므로, 이 문서는 **"기존 프로젝트 컨텍스트 파악"**에 집중.
-
-## Required
-
-### R1. feature-purpose
-**Q**: 어떤 기능을 추가하려 하시나요? 왜 필요한가요?
-**힌트**: 사용자 관점에서 "무엇을 할 수 있게 되는지".
-
-### R2. existing-project-context
-**Q**: 기존 프로젝트의 기술 스택을 확인했나요?
-**힌트**: CLAUDE.md, package.json, .claude/vibe/config.json 읽어서 자동 파악.
-**follow-up**: 파악 결과를 사용자에게 요약해 확인 받기.
-
-### R3. affected-areas
-**Q**: 이 기능이 영향을 주는 영역은 어디인가요?
-**힌트**: 예) UI만, API만, DB 스키마 변경, 인증 시스템, 다수 모듈.
-**follow-up**: "기존 코드 중 건드려야 할 파일/모듈을 대략 알려주시면 좋아요."
-
-### R4. user-flow
-**Q**: 사용자가 이 기능을 쓰는 흐름은 어떻게 되나요?
-**힌트**: 1단계씩. "사용자가 X 화면에서 Y 버튼을 누르면 → Z가 일어난다."
-
-### R5. data-change
-**Q**: 새 데이터 모델이 필요한가요? 기존 모델을 변경하나요?
-**힌트**: 새 테이블/컬럼, 마이그레이션 필요 여부.
-
-### R6. integration-with-existing
-**Q**: 기존 기능과 어떻게 통합되나요?
-**힌트**: 새 기능이 기존 X 기능을 확장/대체/보완.
-
-### R7. success-metric
-**Q**: 이 기능이 "성공했다"고 판단할 기준은?
-**힌트**: 사용자 채택률, 특정 액션 수, 에러율 감소.
-
-## Optional
-
-### O1. backwards-compatibility
-**Q**: 하위 호환성을 지켜야 하나요?
-**힌트**: 기존 사용자 데이터/설정이 깨지면 안 되는 수준.
-
-### O2. feature-flag
-**Q**: 기능 플래그로 점진 출시할 건가요?
-**힌트**: 전체 / 베타 사용자만 / A/B 테스트 / 하드 스위치.
-
-### O3. migration-path
-**Q**: 기존 사용자를 위한 마이그레이션 경로가 필요한가요?
-**힌트**: 데이터 변환, 설정 이전, 공지 기간.
-
-### O4. rollback-plan
-**Q**: 롤백 계획이 있나요?
-**힌트**: DB 마이그레이션 가역성, 이전 버전 유지.
-
-### O5. existing-tests
-**Q**: 기존 테스트를 깨뜨리지 않고 추가할 수 있나요?
-**힌트**: 영향받는 테스트 파일, 새로 추가할 테스트.
-
-### O6. performance-impact
-**Q**: 성능 영향을 예상하나요?
-**힌트**: 빌드 크기, 런타임 속도, DB 쿼리 추가.
-
-### O7. security-impact
-**Q**: 보안 관점 검토가 필요한가요?
-**힌트**: 새 권한, 인증 플로우 변경, 외부 데이터 노출.
-
-### O8. documentation-update
-**Q**: 기존 문서를 업데이트해야 하나요?
-**힌트**: README, API docs, 사용자 가이드.
-
-### O9. ui-consistency
-**Q**: 기존 디자인 시스템과 일관되어야 하나요? (UI 기능)
-**힌트**: 예) 기존 컴포넌트 재사용, 새 컴포넌트 최소화.
-
-### O10. dependency-change
-**Q**: 새 의존성이 추가되나요?
-**힌트**: 번들 크기, 라이선스 호환, 유지보수 가능성.
-
-### O11. observability
-**Q**: 새 메트릭/로그가 필요한가요?
-
-### O12. notification-to-users
-**Q**: 기존 사용자에게 공지가 필요한가요?
-**힌트**: 릴리즈 노트, 인앱 배너, 이메일.
-
-### O13. training-docs
-**Q**: 팀/고객 교육 자료가 필요한가요?
+# Discovery Checklist: Feature (기존 프로젝트에 추가)
+
+> 이미 존재하는 프로젝트에 **새 기능 추가**하거나 **기존 기능 확장**.
+> 체크리스트는 타입(website/webapp/mobile/api/library)과 겹치는 부분이 많으므로, 이 문서는 **"기존 프로젝트 컨텍스트 파악"**에 집중.
+
+## Required
+
+### R1. feature-purpose
+**Q**: 어떤 기능을 추가하려 하시나요? 왜 필요한가요?
+**힌트**: 사용자 관점에서 "무엇을 할 수 있게 되는지".
+
+### R2. existing-project-context
+**Q**: 기존 프로젝트의 기술 스택을 확인했나요?
+**힌트**: CLAUDE.md, package.json, .claude/vibe/config.json 읽어서 자동 파악.
+**follow-up**: 파악 결과를 사용자에게 요약해 확인 받기.
+
+### R3. affected-areas
+**Q**: 이 기능이 영향을 주는 영역은 어디인가요?
+**힌트**: 예) UI만, API만, DB 스키마 변경, 인증 시스템, 다수 모듈.
+**follow-up**: "기존 코드 중 건드려야 할 파일/모듈을 대략 알려주시면 좋아요."
+
+### R4. user-flow
+**Q**: 사용자가 이 기능을 쓰는 흐름은 어떻게 되나요?
+**힌트**: 1단계씩. "사용자가 X 화면에서 Y 버튼을 누르면 → Z가 일어난다."
+
+### R5. data-change
+**Q**: 새 데이터 모델이 필요한가요? 기존 모델을 변경하나요?
+**힌트**: 새 테이블/컬럼, 마이그레이션 필요 여부.
+
+### R6. integration-with-existing
+**Q**: 기존 기능과 어떻게 통합되나요?
+**힌트**: 새 기능이 기존 X 기능을 확장/대체/보완.
+
+### R7. success-metric
+**Q**: 이 기능이 "성공했다"고 판단할 기준은?
+**힌트**: 사용자 채택률, 특정 액션 수, 에러율 감소.
+
+## Optional
+
+### O1. backwards-compatibility
+**Q**: 하위 호환성을 지켜야 하나요?
+**힌트**: 기존 사용자 데이터/설정이 깨지면 안 되는 수준.
+
+### O2. feature-flag
+**Q**: 기능 플래그로 점진 출시할 건가요?
+**힌트**: 전체 / 베타 사용자만 / A/B 테스트 / 하드 스위치.
+
+### O3. migration-path
+**Q**: 기존 사용자를 위한 마이그레이션 경로가 필요한가요?
+**힌트**: 데이터 변환, 설정 이전, 공지 기간.
+
+### O4. rollback-plan
+**Q**: 롤백 계획이 있나요?
+**힌트**: DB 마이그레이션 가역성, 이전 버전 유지.
+
+### O5. existing-tests
+**Q**: 기존 테스트를 깨뜨리지 않고 추가할 수 있나요?
+**힌트**: 영향받는 테스트 파일, 새로 추가할 테스트.
+
+### O6. performance-impact
+**Q**: 성능 영향을 예상하나요?
+**힌트**: 빌드 크기, 런타임 속도, DB 쿼리 추가.
+
+### O7. security-impact
+**Q**: 보안 관점 검토가 필요한가요?
+**힌트**: 새 권한, 인증 플로우 변경, 외부 데이터 노출.
+
+### O8. documentation-update
+**Q**: 기존 문서를 업데이트해야 하나요?
+**힌트**: README, API docs, 사용자 가이드.
+
+### O9. ui-consistency
+**Q**: 기존 디자인 시스템과 일관되어야 하나요? (UI 기능)
+**힌트**: 예) 기존 컴포넌트 재사용, 새 컴포넌트 최소화.
+
+### O10. dependency-change
+**Q**: 새 의존성이 추가되나요?
+**힌트**: 번들 크기, 라이선스 호환, 유지보수 가능성.
+
+### O11. observability
+**Q**: 새 메트릭/로그가 필요한가요?
+
+### O12. notification-to-users
+**Q**: 기존 사용자에게 공지가 필요한가요?
+**힌트**: 릴리즈 노트, 인앱 배너, 이메일.
+
+### O13. training-docs
+**Q**: 팀/고객 교육 자료가 필요한가요?

package/skills/{vibe.interview → vibe-interview}/checklists/library.md

@@ -1,95 +1,95 @@
-# Discovery Checklist: Library / SDK / CLI
-
-> npm 패키지, Python 라이브러리, CLI 도구, SDK 등 **재사용 가능한 코드 단위**.
-
-## Required
-
-### R1. purpose
-**Q**: 이 라이브러리/SDK/CLI가 해결하는 문제는?
-**힌트**: 한 문장으로. "X 없이 Y 하기 어려웠는데, 이게 해결."
-
-### R2. target-users
-**Q**: 누가 사용하나요?
-**힌트**: 예) 프론트엔드 개발자, Python 데이터 분석가, DevOps 엔지니어.
-**follow-up**: "사용자의 기술 수준은?"
-
-### R3. core-api
-**Q**: 핵심 API 표면은 어떻게 생겼나요?
-**힌트**: 예) `import { foo } from 'lib'; foo(x).then(...)`. 1-2줄 사용 예시.
-
-### R4. language-platform
-**Q**: 어느 언어/플랫폼 대상인가요?
-**힌트**: JS/TS (Node/Browser/Deno/Bun), Python, Go, Rust, 범용 CLI.
-
-### R5. distribution
-**Q**: 어떻게 배포하나요?
-**힌트**: npm, PyPI, crates.io, Homebrew, 직접 다운로드.
-
-### R6. license
-**Q**: 라이선스는?
-**힌트**: MIT, Apache 2.0, GPL, 독점.
-
-### R7. success-metric
-**Q**: 성공 기준은?
-**힌트**: 다운로드 수, GitHub stars, 사용자 피드백, 특정 프로젝트 적용.
-
-## Optional
-
-### O1. dependency-policy
-**Q**: 의존성 정책이 있나요?
-**힌트**: zero-dep / minimal / 자유롭게.
-
-### O2. bundle-size
-**Q**: 번들 크기 목표가 있나요? (JS 라이브러리)
-**힌트**: 예) < 10KB gzipped.
-
-### O3. tree-shaking
-**Q**: Tree-shaking 지원이 필요한가요?
-**힌트**: Named exports, ESM-first.
-
-### O4. typescript-support
-**Q**: TypeScript 타입 정의가 필요한가요?
-**힌트**: 내장, @types 패키지, 없음.
-
-### O5. ssr-browser-support
-**Q**: SSR/Browser 양쪽 지원이 필요한가요? (JS)
-
-### O6. api-stability
-**Q**: API 안정성 약속은?
-**힌트**: SemVer 엄격 준수, 실험적, pre-1.0.
-
-### O7. testing-coverage
-**Q**: 테스트 커버리지 목표는?
-**힌트**: 예) 90%+, unit only, integration 포함.
-
-### O8. documentation-style
-**Q**: 문서 스타일은?
-**힌트**: README 위주, 별도 docs site, JSDoc/TSDoc, Storybook.
-
-### O9. examples
-**Q**: 예제/템플릿을 얼마나 제공할 것인가요?
-**힌트**: Quickstart, Recipes, Playground, CodeSandbox 링크.
-
-### O10. versioning-policy
-**Q**: 버저닝 정책은?
-**힌트**: SemVer, CalVer, 수동.
-
-### O11. changelog
-**Q**: Changelog 관리 방식은?
-**힌트**: 수동, Changesets, semantic-release, Keep a Changelog.
-
-### O12. contributing
-**Q**: 외부 기여를 받을 계획인가요?
-**힌트**: 오픈 / CONTRIBUTING.md / CLA 필요 / 내부 전용.
-
-### O13. ci-tests
-**Q**: CI에서 어떤 검증을 돌리나요?
-**힌트**: 다중 Node 버전, 다중 OS, 다중 패키지 매니저.
-
-### O14. deprecation-policy
-**Q**: 기능 제거 정책이 있나요?
-**힌트**: N버전 warning 후 제거, 즉시 제거 금지.
-
-### O15. telemetry
-**Q**: 텔레메트리/사용 통계를 수집하나요?
-**힌트**: opt-in, opt-out, 없음. 프라이버시 고지 필요.
+# Discovery Checklist: Library / SDK / CLI
+
+> npm 패키지, Python 라이브러리, CLI 도구, SDK 등 **재사용 가능한 코드 단위**.
+
+## Required
+
+### R1. purpose
+**Q**: 이 라이브러리/SDK/CLI가 해결하는 문제는?
+**힌트**: 한 문장으로. "X 없이 Y 하기 어려웠는데, 이게 해결."
+
+### R2. target-users
+**Q**: 누가 사용하나요?
+**힌트**: 예) 프론트엔드 개발자, Python 데이터 분석가, DevOps 엔지니어.
+**follow-up**: "사용자의 기술 수준은?"
+
+### R3. core-api
+**Q**: 핵심 API 표면은 어떻게 생겼나요?
+**힌트**: 예) `import { foo } from 'lib'; foo(x).then(...)`. 1-2줄 사용 예시.
+
+### R4. language-platform
+**Q**: 어느 언어/플랫폼 대상인가요?
+**힌트**: JS/TS (Node/Browser/Deno/Bun), Python, Go, Rust, 범용 CLI.
+
+### R5. distribution
+**Q**: 어떻게 배포하나요?
+**힌트**: npm, PyPI, crates.io, Homebrew, 직접 다운로드.
+
+### R6. license
+**Q**: 라이선스는?
+**힌트**: MIT, Apache 2.0, GPL, 독점.
+
+### R7. success-metric
+**Q**: 성공 기준은?
+**힌트**: 다운로드 수, GitHub stars, 사용자 피드백, 특정 프로젝트 적용.
+
+## Optional
+
+### O1. dependency-policy
+**Q**: 의존성 정책이 있나요?
+**힌트**: zero-dep / minimal / 자유롭게.
+
+### O2. bundle-size
+**Q**: 번들 크기 목표가 있나요? (JS 라이브러리)
+**힌트**: 예) < 10KB gzipped.
+
+### O3. tree-shaking
+**Q**: Tree-shaking 지원이 필요한가요?
+**힌트**: Named exports, ESM-first.
+
+### O4. typescript-support
+**Q**: TypeScript 타입 정의가 필요한가요?
+**힌트**: 내장, @types 패키지, 없음.
+
+### O5. ssr-browser-support
+**Q**: SSR/Browser 양쪽 지원이 필요한가요? (JS)
+
+### O6. api-stability
+**Q**: API 안정성 약속은?
+**힌트**: SemVer 엄격 준수, 실험적, pre-1.0.
+
+### O7. testing-coverage
+**Q**: 테스트 커버리지 목표는?
+**힌트**: 예) 90%+, unit only, integration 포함.
+
+### O8. documentation-style
+**Q**: 문서 스타일은?
+**힌트**: README 위주, 별도 docs site, JSDoc/TSDoc, Storybook.
+
+### O9. examples
+**Q**: 예제/템플릿을 얼마나 제공할 것인가요?
+**힌트**: Quickstart, Recipes, Playground, CodeSandbox 링크.
+
+### O10. versioning-policy
+**Q**: 버저닝 정책은?
+**힌트**: SemVer, CalVer, 수동.
+
+### O11. changelog
+**Q**: Changelog 관리 방식은?
+**힌트**: 수동, Changesets, semantic-release, Keep a Changelog.
+
+### O12. contributing
+**Q**: 외부 기여를 받을 계획인가요?
+**힌트**: 오픈 / CONTRIBUTING.md / CLA 필요 / 내부 전용.
+
+### O13. ci-tests
+**Q**: CI에서 어떤 검증을 돌리나요?
+**힌트**: 다중 Node 버전, 다중 OS, 다중 패키지 매니저.
+
+### O14. deprecation-policy
+**Q**: 기능 제거 정책이 있나요?
+**힌트**: N버전 warning 후 제거, 즉시 제거 금지.
+
+### O15. telemetry
+**Q**: 텔레메트리/사용 통계를 수집하나요?
+**힌트**: opt-in, opt-out, 없음. 프라이버시 고지 필요.