version: 3
updated: '2026-06-25'
policy: config/skill-policy.yaml
skills:
  - id: g-director-02
    name: 코어루프 설계
    category: game
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-01(핵심 재미와 타깃, 차별점을 정한 뒤 이를 반복 가능한 코어루프로 구체화하는 단계와 맞닿아 있다.); g-client-02(플레이 가능한 최소 루프 구현 전에 무엇을 구현할지 정의하는 설계 입력으로 연결된다.); g-director-03(첫 30초 목표 이해, 즉시 피드백, 첫 선택은 첫인상과 온보딩 훅 설계와 겹친다.); g-director-04(프로토타입 작업 패킷, 수용 기준, 비목표 정의가 기능 명세화와 겹친다.); g-director-05(메타 루프와 장기 복귀 이유를 다루므로 성장, 수집, 랭킹 같은 장기 동기 설계와 일부 겹친다.); g-director-06(보상 타입, 획득량, 소모량, 난이도 증가를 스프레드시트로 검토하는 부분이 경제·보상 곡선 설계와 겹친다.); g-director-09(MVP를 핵심 동사 1개와 제한된 보상·메타 루프로 자르는 방식이 Prototype/MVP/V1 범위 나누기와 연결된다.); g-qa-01(킬 기준과 관찰 지표를 통해 무엇을 어떻게 검증할지 정의한다.); g-ux-04(즉시 피드백으로 사운드, 이펙트, 흔들림, 상태 변화를 요구해 타격감·연출 설계와 접점이 있다.); g-ux-05(첫 30초 안에 목표가 이해되는지 보는 기준은 튜토리얼과 첫 동선 설계와 맞닿아 있다.)'
    value: 가장 작은 행동-보상-진행 루프를 잡을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 코어루프를 실행 가능한 설계 산출물로 바꾸는 절차와 검증 기준이 탄탄해 바로 승격할 만하다.  리스크: 핵심 동사 1개 원칙은 MVP 축소에는 좋지만, 장르에 따라 이동+공격, 선택+배치처럼 결합 동사가 본질인 경우 과도하게 단순화할 수 있다.; 킬 기준 중 ''개발자가 10분 반복 테스트하고 싶지 않다''는 유용하지만 주관성이 커서 외부 플레이어 관찰 지표와 함께 써야 한다.; 수익화/운영 제약을 입력으로 받지만 절차에서는 광고, IAP, 에너지, 시즌제 등이 코어루프를 어떻게 왜곡하거나 제한하는지 점검하는 항목이 약하다.; 종이/스프레드시트 시뮬레이션은 액션성, 조작감, 물리감 중심 게임에서는 검증력이 제한될 수 있다는 전제가 필요하다.'
    action: use
    path: 40_Skills/candidate/g-director-02.md
    ecosystem: 'delegate:sprint-game'
  - id: a-dev-01
    name: Flutter 앱 셸·라우팅
    category: app
    engine: flutter
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-03(인증 상태와 refreshListenable, 로그인/로그아웃에 따른 redirect 재평가가 앱 상태·DI 구조와 맞물린다.); a-dev-06(딥링크, 푸시 payload, 웹 URL을 라우트 path로 매핑하는 부분이 외부 진입 구현과 직접 연결된다.); a-pm-02(화면 목록, 탭/스택/모달 구분, 내비게이션 스택 정의를 입력으로 받아 라우트 트리로 번역한다.); a-pm-01(로그인 후 복귀, 온보딩 강제, 보호 라우트 차단 같은 사용자 흐름의 증명 요건과 접점이 있다.); a-qa-01(Android back, iOS swipe back, OS별 딥링크 검증처럼 기기/OS 검증 범위와 연결된다.); a-qa-02(권한 화면은 라우트가 아니라 화면 내 다이얼로그로 처리하라는 경계 설정이 권한 검증 영역과 맞닿아 있다.)'
    value: MaterialApp·go_router·테마를 세울 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · Flutter 앱의 라우팅 셸을 코드와 검증 게이트까지 고정하는 고품질 실무형 스킬이므로 promote가 적절하다.  리스크: go_router 버전별 API와 권장 패턴이 바뀔 수 있어 14.x 기준이라는 전제가 실제 프로젝트 버전과 다르면 보정이 필요하다.; redirect 우선순위가 온보딩, 강제 업데이트, 인증, 공개 라우트 사이에서 꼬이면 무한 루프나 의도치 않은 차단이 생길 수 있다.; 딥링크 검증은 라우트 트리만으로 끝나지 않고 Android intent-filter, iOS associated domains, 앱 스킴 설정이 별도로 맞아야 한다.; StatefulShellRoute 내부에서 go, push, goBranch 사용 기준은 화면 전환 의도에 따라 세밀하게 달라질 수 있어 팀 내 규칙으로 더 구체화할 필요가 있다.; 위젯 테스트 예시는 방향이 좋지만 실제 location 관찰 방법과 router test harness 구성은 프로젝트 구조에 맞게 추가 정의가 필요하다.'
    action: review
    path: 40_Skills/candidate/a-dev-01.md
    ecosystem: 'partial:sprint-app'
  - id: a-dev-02
    name: 위젯·화면 구현
    category: app
    engine: flutter
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-01(라우팅·테마·앱 셸 이후 개별 화면 위젯을 구현하므로 ThemeData와 Material 구조 사용 지점이 맞닿는다.); a-dev-03(Provider/Riverpod/Bloc 등 기존 상태관리 결과를 화면에서 구독하고 상태 분기하는 부분이 겹친다.); a-dev-07(리빌드 범위 축소, RenderFlex overflow 확인, 렌더 성능과 관련된 위젯 구조 판단이 일부 겹친다.); a-pm-01(로딩·빈·에러·정상 상태와 테스트 통과 기준은 사용자 흐름의 성공/실패 기준 정의와 연결된다.); a-pm-02(개별 화면 구현은 필요한 화면 목록과 내비 스택이 정해진 뒤 이어지는 작업이다.); a-qa-04(터치 타깃, Semantics, 스크린리더 라벨 검증이 접근성 QA와 직접 겹친다.)'
    value: Stateless/Stateful·커스텀 위젯으로 화면을 만들 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · Flutter 단일 화면 구현 역할에 매우 적합하며, 상태·위젯 구조·접근성·검증까지 실무적으로 잘 닫힌 고품질 스킬이다.  리스크: 80줄 기준은 리뷰 가이드로는 유용하지만 화면 복잡도에 따라 기계적으로 적용하면 파일/클래스가 과도하게 쪼개질 수 있다.; `ListView(children: [...])` 전면 금지는 짧고 정적인 목록에는 과한 규칙일 수 있어 ''긴 목록'' 조건을 더 명확히 해야 한다.; Riverpod `AsyncValue` 예시가 중심이라 Bloc, Provider, FutureBuilder/StreamBuilder 프로젝트에 그대로 적용하려면 상태 분기 예시를 변환해야 한다.; 리터럴 `fontSize` 전면 금지는 프로젝트에 디자인 토큰이 충분히 없는 초기 앱에서 적용 난도가 높을 수 있다.; Semantics 테스트는 Flutter 버전과 위젯 구조에 따라 취약할 수 있어 수동 TalkBack/VoiceOver 확인 기준을 더 구체화하면 좋다.; 참고의 ''Flutter docs — AsyncValue''는 부정확할 수 있다. AsyncValue는 Riverpod 문서로 분리하는 편이 정확하다.'
    action: review
    path: 40_Skills/candidate/a-dev-02.md
    ecosystem: 'partial:sprint-app'
  - id: a-dev-03
    name: 상태관리 (Riverpod/Bloc)
    category: app
    engine: flutter
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-02(Ephemeral 상태, StatefulWidget, 위젯 트리 내 상태 위치 결정에서 화면 구현 스킬과 맞닿는다.); a-dev-04(Shared/App 상태가 영속 저장·캐싱으로 확장될 때 repository 캐싱과 저장 정책 경계가 겹친다.); a-dev-07(불필요 리빌드, autoDispose, 위젯 렌더 검증, 누수 스모크 점검이 성능·리빌드 점검과 연결된다.); a-dev-01(App/Session provider를 루트에 두는 결정은 MaterialApp, go_router, 루트 앱 구성과 접점이 있다.); a-pm-02(화면 간 공유 상태와 화면 복귀 후 유지 여부는 필요한 화면·내비 스택 정의와 함께 결정되어야 한다.); a-qa-02(타이머, 스트림, 백그라운드, 화면 이탈 후 콜백 검증은 권한·끊김·백그라운드 검증 관점과 일부 겹친다.)'
    value: 앱 상태·DI를 구조화할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 상태 소유권과 생명주기를 빠르게 결정해 구현 산출물로 연결하는 고품질 app 개발 스킬이다.  리스크: 프로젝트당 Riverpod/Bloc 하나로 통일한다는 규칙은 신규·소규모 앱에는 좋지만, 이미 혼용된 레거시나 점진 마이그레이션 상황에서는 과도하게 경직될 수 있다.; Screen 상태 기본 autoDispose는 신선도에는 유리하지만 목록 복귀 시 스크롤 위치·데이터 유지가 중요한 UX에서는 캐시 전략과 충돌할 수 있다.; freezed 권장은 좋지만 코드 생성 도구 도입 비용이 있어 아주 작은 기능이나 기존 non-freezed 코드베이스에서는 선택지로 완화할 필요가 있다.; dispose 검증을 로그 관찰에 의존하면 자동화 수준이 낮아 회귀 방지력이 약할 수 있다.; Riverpod/Bloc API는 버전별 차이가 있으므로 Flutter와 패키지 버전 확인 후 AsyncNotifier, ref.listen, keepAlive 사용법을 맞춰야 한다.'
    action: review
    path: 40_Skills/candidate/a-dev-03.md
    ecosystem: 'partial:sprint-app'
  - id: a-dev-04
    name: 오프라인·로컬 영속
    category: app
    engine: flutter
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-03(상태·DI와 영속 저장소 책임 분리, repository/data layer 경계 설정에서 맞닿는다.); a-qa-01(마이그레이션·재설치·OS별 secure storage 잔존 여부 검증은 기기/OS 매트릭스 선정과 연결된다.); a-qa-02(비행기 모드, 재연결 동기화, 백그라운드 종료 후 복구 같은 끊김·상태 전환 검증과 겹친다.); a-pm-03(오프라인 쓰기, 양방향 충돌 해결, 동기화 범위를 MVP에 포함할지 자르는 판단과 연결된다.); a-dev-07(대량 로컬 데이터, 인덱스, 캐시 파일, cold start 로딩은 앱 성능 점검과 일부 맞닿는다.)'
    value: Isar/Drift·SharedPreferences로 저장·동기화할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · Flutter 로컬 영속 계층을 1인 개발자가 안전하게 결정·구현·검증하도록 만드는 고품질 스킬이다.  리스크: 패키지 API와 플랫폼 보안 옵션은 버전별로 바뀔 수 있으므로 flutter_secure_storage, Isar, Drift의 현재 문서 확인을 강제해야 한다.; ''엔진은 2개까지'' 규칙은 1인 개발 가드로 유용하지만, shared_preferences와 파일 캐시까지 포함하면 실제 예시처럼 예외 해석이 필요하다. 본문 도메인 DB 1개라는 표현을 더 명확히 하면 좋다.; 캐시와 도메인 데이터를 절대 같은 store에 섞지 말라는 표현은 안전하지만, 동일 DB 내 별도 테이블/namespace와 삭제 정책으로 관리하는 설계를 과도하게 배제할 수 있다.; OS 백업 제외, iOS Keychain 잔존, Android Auto Backup 정책은 앱 정책·인증 모델에 따라 달라지므로 기본값을 맹목 적용하면 UX나 계정 복구 흐름과 충돌할 수 있다.; LWW 기본값은 단순하지만 협업 데이터나 금전·재고·의료 기록처럼 손실 허용이 낮은 도메인에는 부적절할 수 있다.'
    action: review
    path: 40_Skills/candidate/a-dev-04.md
    ecosystem: 'partial:sprint-app'
  - id: a-dev-05
    name: 플랫폼 채널·네이티브 연동
    category: app
    engine: flutter
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-04(KeyStore/Keychain, SharedPreferences류 저장 연동 사례에서 로컬 저장·동기화 판단과 맞닿는다.); a-dev-06(FCM, 딥링크, 외부 SDK처럼 네이티브 설정과 채널·플러그인 연동이 필요한 영역에서 일부 구현 관점이 겹친다.); a-dev-07(AndroidManifest, Info.plist, minSdkVersion, Podfile, iOS Deployment Target 등 빌드·플랫폼 설정 확인 지점이 겹친다.); a-pm-03(네이티브 직접 구현을 줄이고 플러그인으로 대체할지 판단하는 범위 축소 관점이 닿는다.); a-qa-01(실기기와 OS 버전별 검증 매트릭스를 요구하므로 기기/OS 선정과 연결된다.); a-qa-02(권한 거부, 영구 거부, 백그라운드, 끊김 검증 케이스가 직접적으로 겹친다.); a-qa-03(네이티브 작업의 메인 스레드 블로킹, 백그라운드 제한, 발열·성능 이슈 점검과 일부 연결된다.)'
    value: 카메라·위치·생체인증 등 기능을 붙일 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · Flutter 네이티브 연동의 선택·계약·양면 구현·검증을 1인 개발자 관점에서 실행 가능하게 고정한 고품질 스킬이다.  리스크: Pigeon 적용 기준을 메서드 3개 이상으로 고정한 것은 실무 판단 기준으로 유용하지만, 팀·프로젝트에 따라 타입 안정성이 중요한 1~2개 메서드에도 Pigeon이 적절할 수 있다.; 플러그인 직접 작성 시 Flutter embedding v2의 ActivityAware, lifecycle, permission result 콜백 처리 같은 플러그인 구조 세부가 부족하다.; Android 런타임 권한 예시가 ActivityCompat 중심이라 최신 Activity Result API나 Flutter plugin lifecycle과 혼용할 때 구현자가 헷갈릴 수 있다.; 권한 상태를 permission_handler 기준 4상태로 단순화했지만 iOS limited/provisional, Android 13+ 알림 권한, Android 14+ foreground service 타입처럼 기능별 예외가 추가로 필요할 수 있다.; iOS 심사 거절 원인을 Info.plist 누락에 강하게 둔 표현은 실무적으로 유용하지만, 실제 거절은 사용 목적 문구의 구체성·데이터 사용 설명까지 함께 봐야 한다.; 백그라운드 위치·블루투스·NFC처럼 OS 정책이 복잡한 기능은 이 스킬만으로 충분하지 않고 기능별 공식 문서 확인 게이트가 필요하다.'
    action: review
    path: 40_Skills/candidate/a-dev-05.md
    ecosystem: 'partial:sprint-app'
  - id: a-dev-06
    name: 푸시·딥링크
    category: app
    engine: flutter
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-01(딥링크 라우팅, 초기 경로 처리, 네비게이션 스택 복원은 go_router·라우팅 설정과 직접 연결된다.); a-dev-05(푸시 권한, 네이티브 OS 기능, 플랫폼별 설정 연결 절차가 카메라·위치 등 네이티브 기능 연동과 유사하다.); a-pm-01(알림 클릭 후 사용자 흐름과 성공 증명 요건을 정의하는 의사결정 절차가 겹친다.); a-pm-02(딥링크 도착 화면, fallback 화면, 내비게이션 스택 정의가 화면·내비 목록화와 겹친다.); a-pm-03(Android/iOS 플랫폼 범위와 1인 개발자가 감당 가능한 네이티브 범위를 자르는 판단이 겹친다.); a-qa-01(기기, OS, 빌드 타입, 네트워크 상태별 검증 환경 선정이 겹친다.); a-qa-02(권한, 백그라운드, 종료 상태, 네트워크 실패 상황 검증이 푸시·딥링크 품질 확인과 겹친다.)'
    value: FCM·앱 링크로 알림·외부 진입을 구현할 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 전문 영역의 필수 실패 모드와 검증 게이트가 잘 잡혀 있어 승격 가능하되, 최종본에서는 메타 문구와 플랫폼별 구체 예시를 정리해야 한다.  리스크: 푸시와 딥링크를 함께 다루므로 실제 작업자가 둘 중 하나만 필요한 경우 산출물이 과해질 수 있다.; 서버 발송 책임, payload 스키마, 토큰 저장·폐기 정책이 별도 산출물로 충분히 강제되지 않으면 클라이언트 체크리스트에 머물 위험이 있다.; 플랫폼별 실제 파일명과 콘솔 설정 위치가 템플릿에 부족해 초보 구현자가 공식 문서 확인 없이 추상 체크만 완료할 수 있다.; 마케팅 수신 동의, 개인정보 로그 노출, 스토어 정책 같은 운영·법무성 리스크의 통과 기준이 아직 구체적인 증거 형태로 덜 고정되어 있다.; 초안에 재심사 기대 개선점과 Tier-2 지적 문구가 남아 있어 최종 스킬로 배포 전 편집 품질을 낮출 수 있다.'
    action: review
    path: 40_Skills/candidate/a-dev-06.md
    ecosystem: 'partial:sprint-app'
  - id: a-dev-07
    name: Flutter 빌드·성능
    category: app
    engine: flutter
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-qa-03(앱 크기, 시작 시간, 발열·성능성 지표를 측정하고 합격 여부를 보는 영역이 겹친다. 이 초안은 개발자가 원인을 고치고 재측정하는 관점이다.); a-qa-01(실기기 모델, OS 버전, 보급형 기기 기준 등 검증 환경 선정과 일부 겹친다.); a-qa-02(권한 선언, 백그라운드·플랫폼 동작, 네이티브 채널 릴리스 크래시 같은 앱 검증 항목과 접점이 있다.); a-dev-05(카메라·위치·생체인증 등 네이티브 기능 플러그인의 권한, ProGuard/R8 keep, 플랫폼 채널 문제와 겹친다.); a-dev-06(FCM·앱 링크 같은 외부 진입 기능은 릴리스 빌드, 권한, entitlements, ProGuard/R8 설정의 영향을 받으므로 일부 겹친다.); a-pm-03(플랫폼별 네이티브 범위와 출시 리스크를 분리해 보는 부분이 겹치지만, 이 스킬은 구현·성능 수정 관점이다.)'
    value: Android/iOS 빌드·위젯 리빌드·렌더 성능을 잡을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 측정 기반으로 Flutter 빌드·성능 문제를 좁히고 고치는 절차가 선명해 바로 승격 가능한 고품질 스킬이다.  리스크: 임계값이 앱 유형에 따라 다를 수 있다. 게임, 미디어 편집, 지도, AR 앱에는 크기·프레임·메모리 기준을 별도 조정해야 한다.; T1 빌드 최적화와 T2~T5 성능 튜닝이 한 문서에 함께 있어 초보자가 여러 트랙을 동시에 잡으려 할 수 있다. 체크리스트는 1개 트랙 고정을 강조하지만 운영 시 재확인이 필요하다.; iOS 성능 측정 절차가 Android보다 상대적으로 덜 구체적이다. Instruments, Xcode Organizer, TestFlight 조건 같은 보조 절차가 있으면 더 완전하다.; 메모리 리크 판정은 DevTools Memory만으로 확정하기 어려운 경우가 있다. 네이티브 메모리, 이미지 디코딩, 플러그인 리소스는 플랫폼 도구가 추가로 필요할 수 있다.; 앱 크기 기준인 30MB/50MB는 유용한 출발점이지만 스토어 정책, 국가 네트워크 환경, 앱 카테고리에 따라 오판 가능성이 있다.'
    action: review
    path: 40_Skills/candidate/a-dev-07.md
    ecosystem: 'partial:sprint-app'
  - id: a-pm-01
    name: 모바일 워크플로우 정의
    category: app
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-pm-02(핵심 단계열이 이후 화면 흐름과 내비 스택 정의의 직접 입력이 되므로 사용자 흐름 영역이 맞닿아 있다.); a-pm-03(MVP 직전 핵심 흐름 1개를 고정하고 부 워크플로우를 배제하므로 범위 절단 판단과 연결된다.); a-qa-02(권한 거부, 네트워크 끊김, 백그라운드 복귀 등 실패 경로를 정의해 QA 검증 케이스의 입력을 만든다.); a-dev-05(카메라, 위치, 생체인증 등 모바일 권한 기능이 워크플로우 단계와 게이트로 명시된다.); a-dev-06(푸시와 딥링크 중간 진입을 핵심 흐름의 실패/분기 조건으로 다룬다.); a-dev-04(오프라인 저장, 큐 적재, 동기화 복구 조건이 워크플로우 증명 조건에 포함된다.); a-qa-01(타깃 OS와 최소 버전이 권한·백그라운드 제약의 근거가 되어 검증 기기/OS 선정과 연결된다.)'
    value: 주요 사용자 흐름·증명 요건을 정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 모바일 MVP의 핵심 사용자 흐름을 검증 가능한 단일 워크플로우로 고정하는 고품질 PM 스킬이다.  리스크: 모든 단계마다 6개 실패 경로를 채우는 방식은 단순 앱에서는 과도한 문서 작업이 될 수 있어, 매우 짧은 흐름에는 N/A가 많아질 수 있다.; 스토어 정책과 OS 권한 규칙은 자주 바뀌므로 참고 조항을 최신 공식 문서로 재확인해야 한다.; Android 알림 권한 설명은 Android 13(API 33)부터의 런타임 권한이라는 점을 더 정확히 쓰는 편이 좋다.; 앱 첫 실행 권한 일괄 요청을 iOS 심사 리젝으로 단정하는 표현은 상황에 따라 과할 수 있어 ‘리젝 또는 거부율 상승 위험’ 정도가 더 안전하다.; GPS는 네트워크 없이도 가능하지만 기기·환경에 따라 초기 위치 획득이 느리거나 실패할 수 있으므로 오프라인 예시의 표현은 보완 여지가 있다.'
    action: review
    path: 40_Skills/candidate/a-pm-01.md
    ecosystem: 'delegate:sprint-app'
  - id: a-pm-02
    name: 화면 인벤토리
    category: app
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-01(라우트 경로, go_router 설정, 인증 redirect 전 단계의 화면 목록 정의와 맞닿아 있다.); a-dev-05(카메라·위치·알림 등 권한 의존 화면과 권한 거부 상태를 사전에 정의한다.); a-dev-06(푸시·딥링크·앱링크로 직접 진입 가능한 화면과 콜드스타트 가드를 다룬다.); a-pm-01(주요 사용자 흐름의 각 단계를 화면 후보로 변환하므로 입력 영역이 연결된다.); a-pm-03(MVP 범위 안에 포함할 화면과 백로그로 미룰 화면을 구분한다.); a-qa-01(화면 재고표가 QA 기기·OS 매트릭스의 기준 목록으로 활용될 수 있다.); a-qa-02(권한 거부, 오프라인, 백그라운드 복귀, 콜드스타트 같은 검증 조건을 화면별로 정의한다.); a-qa-04(화면 단위 인벤토리는 접근성 검증 대상 화면 목록을 만드는 데 연결된다.)'
    value: 필요한 화면·내비 스택을 나열할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 모바일 MVP 구현 전 화면 수·라우트·상태·권한·외부 진입을 누락 없이 고정하는 고품질 PM 스킬이다.  리스크: 라우트 스택에 push 되면 화면이라는 규칙은 실무적으로 유용하지만, Flutter의 modal route, nested navigation, shell route, bottom tab 내부 스택처럼 라우트와 화면 경계가 1:1이 아닌 구조에서는 보정이 필요하다.; 표의 빈 칸 0개 원칙이 좋지만 초기 탐색 단계에서 과도하게 완결성을 요구하면 빠른 프로토타이핑을 늦출 수 있다.; 접근성, 분석 이벤트, 에러 로깅, 국제화처럼 화면별로 자주 필요한 비기능 항목은 기본 표에 없어 별도 스킬이나 확장 칼럼이 필요할 수 있다.; 권한 거부 처리 설명에서 iOS 중심 전제가 강하므로 Android의 권한 재요청·영구 거부·버전별 동작 차이를 별도로 확인해야 한다.; 외부 진입 경로가 많은 앱에서는 모든 딥링크 목적지를 화면 단위로만 관리하면 파라미터 검증, 만료 링크, 리소스 삭제 상태 같은 케이스가 누락될 수 있다.'
    action: review
    path: 40_Skills/candidate/a-pm-02.md
    ecosystem: 'delegate:gatecraft'
  - id: a-pm-03
    name: MVP 범위 컷
    category: app
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-pm-01(MVP 범위 결정은 주요 사용자 흐름과 증명 요건을 먼저 고정해야 하므로 사용자 가치와 검증 조건 설정 영역이 겹친다.); a-pm-02(MVP에서 포함할 화면과 미룰 화면을 나누는 과정이 필요한 화면·내비 스택 나열과 직접 연결된다.); a-qa-01(MVP 검증 게이트에서 어떤 기기와 OS를 대상으로 통과 기준을 볼지 정해야 하므로 QA 범위 설정과 맞닿는다.); a-qa-02(모바일 MVP 범위 컷에서 권한, 네트워크 끊김, 백그라운드 동작을 포함하거나 제외할지 판단해야 하므로 겹친다.)'
    value: 플랫폼·네이티브 범위 과잉을 자를 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 기본 구조는 좋지만 실제 모바일 MVP 범위를 자르는 판단표와 현실적인 예시를 보강하면 promote 수준이다.  리스크: 비교 기준은 제시되어 있지만 점수화나 우선순위 산정 방식이 없어 사용자가 다시 감으로 결정할 수 있다.; 예시가 현실적인 앱 시나리오가 아니라 메타 설명에 가까워 초보 1인 개발자가 산출물 수준을 가늠하기 어렵다.; 모바일 특유의 컷 기준인 앱스토어 심사, 권한 요청 타이밍, 오프라인 최소 대응, 푸시/로그인/결제 같은 고위험 기능의 포함 여부 판단이 더 구체화될 필요가 있다.; 작업 패킷에 예상 소요 시간, 릴리즈 단위, 분석 이벤트 같은 MVP 검증 실행 요소가 부족하다.'
    action: use
    path: 40_Skills/candidate/a-pm-03.md
    ecosystem: 'delegate:sprint-app'
  - id: a-qa-01
    name: 디바이스 매트릭스
    category: app
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-05(카메라·센서·생체인증 같은 기기 의존 기능을 어떤 기기에서 검증할지와 구현 리스크가 맞닿아 있다.); a-dev-06(FCM·앱 링크·푸시·딥링크 기능은 구현 스킬과 검증 대상 기기 선정이 연결된다.); a-dev-07(Android/iOS 빌드, 렌더 성능, 플랫폼별 동작 차이를 검증할 기기 선정과 관련된다.); a-pm-01(주요 사용자 흐름과 증명 요건을 정한 뒤 어떤 기기에서 증명할지 매트릭스로 구체화한다.); a-pm-03(플랫폼·네이티브 범위 과잉을 자르는 판단과 QA 대상 기기 범위를 자르는 판단이 맞닿아 있다.); a-qa-02(같은 기기 목록 위에서 권한·네트워크 끊김·백그라운드 시나리오를 실행하므로 검증 무대가 겹친다.); a-qa-03(성능·발열·앱 크기 검증을 어떤 실기기에서 수행할지 선정한다.); a-qa-04(화면 크기·해상도·접근성 검증을 올릴 대표 기기 선정과 관련된다.)'
    value: 어떤 기기/OS를 검증할지 정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 제한된 시간 안에 모바일 앱 검증 기기 매트릭스를 만들 수 있게 해주는 고품질 QA 스킬이다.  리스크: 점유율 기준이 모델 점유율인지 OS 버전 점유율인지 혼동될 수 있어, 실제 사용 시 행별로 어떤 통계를 썼는지 명확히 적어야 한다.; ''최저 OS'' 강제 슬롯이 Android와 iOS 모두를 지원하는 앱에서는 플랫폼별 최저 OS 각각 1대가 필요하다는 점을 더 명시하면 좋다.; IAP·푸시를 항상 실기기 필수로 둔 판단은 안전하지만, 자동화·사전 스모크에서는 제한적 에뮬 검증도 가능하므로 비용이 매우 낮은 팀에는 다소 보수적으로 느껴질 수 있다.; 클라우드 실기기 서비스의 지원 모델·OS 버전·iOS 제약은 시점마다 바뀌므로 실행 직전에 확인해야 한다.'
    action: review
    path: 40_Skills/candidate/a-qa-01.md
    ecosystem: 'delegate:sprint-app'
  - id: a-qa-02
    name: 권한·오프라인 테스트
    category: app
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-04(오프라인 저장, 쓰기 큐, 동기화 충돌 정책과 데이터 유실 검증이 저장·동기화 구현 영역과 맞닿아 있다.); a-dev-05(카메라·위치·사진·알림·생체인증 등 네이티브 권한 요청과 거부 분기 검증이 네이티브 기능 구현과 겹친다.); a-dev-06(알림 권한의 provisional 상태와 외부 진입·푸시 흐름 검증 일부가 알림 구현 영역과 연결된다.); a-qa-01(실기기, OS 버전, 빌드타입 등 검증 환경 선정이 기기/OS 매트릭스 QA와 직접 연결된다.); a-pm-01(주요 사용자 흐름별 증명 요건과 출시 차단 기준을 정의하는 방식이 PM의 증명 요건 설정과 일부 겹친다.)'
    value: 권한·끊김·백그라운드를 검증할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 권한 거부와 오프라인 실패 경로를 출시 게이트로 전환하는 실전성 높은 QA 스킬이다.  리스크: Android의 permanently denied 판정은 shouldShowRequestPermissionRationale=false만으로 단순화하면 최초 요청 전 상태와 혼동될 수 있어, ''요청한 적 있음'' 플래그가 필요하다.; iOS 권한별 재요청 가능 여부와 설정 이동 동작은 권한 종류마다 차이가 있어 표를 그대로 일반화하면 일부 권한에서 부정확할 수 있다.; MUST의 ''L2/L3 데이터 끊김 중 유실 0건''은 앱 성격에 따라 검증 비용이 커질 수 있어 최소 샘플 데이터와 허용 범위를 정해야 한다.; 느린 네트워크 도구와 release 빌드 검증은 환경 준비 비용이 있어 1인 개발자가 실행할 수 있는 대체 절차가 있으면 더 안정적이다.'
    action: review
    path: 40_Skills/candidate/a-qa-02.md
    ecosystem: 'delegate:sprint-app'
  - id: a-qa-03
    name: 성능 예산
    category: app
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-07(렌더링 성능, jank, 위젯 리빌드, 프레임 드롭 원인 분석과 맞닿아 있다. 이 스킬은 판정 게이트, a-dev-07은 개선 실행 관점이다.); a-qa-01(성능 판정의 기준이 되는 바닥 기기·OS 매트릭스를 입력으로 사용하므로 검증 대상 기기 선정과 연결된다.); a-qa-02(백그라운드 복귀, 네트워크 끊김, wake, 배터리 같은 수명주기 시나리오에서 성능 수치를 재는 부분이 겹친다.); a-pm-01(주요 사용자 흐름의 증명 요건을 성능 예산이라는 출시 차단 조건으로 바꾸는 부분이 일부 맞닿아 있다.)'
    value: 앱 크기·구동·발열을 점검할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실전성 높은 성능 게이트 스킬이지만 정책값·측정 정의·스크립트 견고성을 보정하면 카탈로그 품질이 더 안정된다.  리스크: 스토어 크기 한도, iOS 셀룰러 다운로드 경고선, Google Play 정책값은 바뀔 수 있어 고정 숫자로 박으면 오래된 기준이 될 수 있다.; `adb shell am start -W`의 `TotalTime`은 유용하지만 TTID/TTFD 전체 정의와 1:1로 같지 않을 수 있어 Android 버전과 앱 구조별 해석 주의가 필요하다.; jank 측정 스크립트가 `grep -oP`와 정수 퍼센트 추출에 의존해 macOS 기본 환경이나 소수점 출력에서 깨질 수 있다.; 발열을 ''손 체감 + 온도 앱''으로 두면 재현성이 낮다. 실내 온도, 케이스, 충전 상태, 배터리 잔량 같은 전제 고정이 필요하다.; 메모리 상한을 RAM의 35%로 잡는 규칙은 앱 종류에 따라 너무 관대하거나 과도할 수 있어 카테고리별 보정 기준이 필요하다.; CI에서 실제 기기 성능 측정을 돌릴 경우 기기 상태, 열 스로틀링, 백그라운드 프로세스, USB 연결 안정성 때문에 flake가 생길 수 있다.'
    action: review
    path: 40_Skills/candidate/a-qa-03.md
    ecosystem: 'partial:sprint-app'
  - id: a-qa-04
    name: 접근성
    category: app
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): a-dev-02(위젯 구현 단계에서 라벨, 역할, 터치 영역, 동적 글씨 대응을 반영해야 하므로 접근성 QA 결과가 구현 수정으로 이어진다.); a-qa-01(접근성 검증도 실제 기기·OS·시뮬레이터 매트릭스 위에서 수행되므로 검증 환경 선정과 맞닿아 있다.); a-pm-01(핵심 사용자 흐름과 증명 요건을 정해야 어떤 화면의 접근성 결함을 차단으로 볼지 판단할 수 있다.); a-pm-02(점검 대상 화면 목록과 내비게이션 흐름이 있어야 스크린리더 순회, 모달 포커스, 화면별 판정표를 구성할 수 있다.)'
    value: 터치 타깃·스크린리더를 점검할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 모바일 접근성 QA 역할에 매우 적합한 고품질 스킬이며 바로 승격 가능하다.  리스크: WCAG 2.5.5 타깃 크기는 AAA 기준에 가까워 플랫폼 HIG 기준과 혼동될 수 있으므로, 규제 대상에서 요구되는 정확한 WCAG 버전과 성공 기준을 별도 확인해야 한다.; 외부 키보드, 스위치 제어, 음성 제어, 가로모드 같은 접근성 항목은 범위 밖이므로 이 스킬만으로 전체 접근성 적합성을 보장한다고 오해하면 안 된다.; 디자인 hex와 실제 렌더링 색상이 다를 수 있어 반투명, disabled 상태, 이미지 위 텍스트는 추가 확인이 필요하다.; AX5나 Android 200% 설정 경로·최대값은 OS 버전에 따라 표현이 달라질 수 있어 환경 기록이 중요하다.'
    action: review
    path: 40_Skills/candidate/a-qa-04.md
    ecosystem: 'partial:sprint-app'
  - id: c-architect-01
    name: 기술 스택 선택
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-architect-05(확장성, 비용, 유지보수, 실패 조건을 기준으로 기술적 대안을 비교하고 선택하는 핵심 판단 영역이 겹친다.); c-architect-04(리포 구조, CI, 배포 타깃, 호스팅 같은 실행 환경 선택이 기술 스택 결정과 함께 정해지는 경우가 많다.); c-planner-02(포함 범위, 제외 범위, 수용 기준, 실패 기준, 다음 작업 패킷으로 구현 전 명세를 만드는 형식이 겹친다.); c-planner-05(가치, 노력, 리스크를 비교해 우선 선택지를 정하는 의사결정 구조가 유사하다.); c-researcher-04(라이브러리 유지 상태, 보안 이슈, 가격 정책, 플랫폼 제약처럼 최신 정보 확인과 출처 검증이 필요한 부분이 겹친다.)'
    value: '엔진·언어·프레임워크·호스팅을 고를 때 (1차 기본: 게임=Unity · 앱=Flutter · 웹=Next.js/Cloudflare)'
    risk: 'Tier-2 품질 4/5 · 권고 revise · 구조와 검증 게이트는 좋지만 실제 스택 비교 평가표, 최신성 확인 절차, 완성 예시를 보강해야 승격하기 좋다.  리스크: 게임=Unity, 앱=Flutter, 웹=Next.js/Cloudflare라는 기본값이 프로젝트 맥락 없이 강하게 보일 수 있어 잘못된 앵커링을 만들 수 있다.; 선택 기준에 비용, 러닝커브, 생태계, 배포 난이도, 데이터 소유권, 벤더 락인, 오프라인 지원 같은 평가 축이 명시되지 않아 결과 품질이 사용자 역량에 크게 의존한다.; 최신성 검증 절차가 구체 명령이나 확인 주기, 최소 출처 수로 고정되어 있지 않아 오래된 정보로 결정할 위험이 남는다.; 실제 작성 예시가 없어 산출물의 적정 상세도와 합격선을 학습시키기 어렵다.; 운영 부담 항목이 실패 모드에는 있지만 체크리스트와 출력 템플릿의 필수 평가 항목으로 충분히 들어가 있지 않다.'
    action: review
    path: 40_Skills/candidate/c-architect-01.md
    ecosystem: 'partial:product-spec'
  - id: c-architect-02
    name: 모듈 경계 설계
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-architect-03(클라-서버-DB 경계와 상태 소유권 결정 이후 이를 코드 모듈 경계와 의존 방향으로 번역하는 부분에서 접점이 있다.); c-architect-04(리포 구조, 패키지 분리, CI 검증 게이트와 모듈 강제 수단이 연결된다.); c-architect-05(asmdef/패키지 분리/DI 같은 선택에서 비용·유지보수 트레이드오프 판단과 만난다.); c-architect-06(금지 import, public 표면적, 리뷰 체크 항목 등 코드 표준과 리뷰 게이트로 이어진다.); c-planner-07(구현에 넘기기 전 모듈 책임, 인터페이스, 검증 조건을 준비도 기준으로 점검하는 데 겹친다.); klv:first-packet(Phase-0 구현 계획에 포함될 모듈 맵과 의존 그래프 산출물로 활용될 수 있다.); workflow-translator(막연한 리팩터링 요청을 구체적인 모듈 경계 설계 작업으로 변환하는 과정과 접점이 있다.)'
    value: 의존 방향·인터페이스로 결합도를 관리할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 모듈 경계 설계를 실제 산출물과 검증 게이트까지 끌고 가는 고품질 스킬이므로 promote가 적절하다.  리스크: 결합도 ≤3, 표면적 ≤5 같은 숫자는 좋은 휴리스틱이지만 도메인 규모에 따라 예외가 필요할 수 있다.; 안정 의존 원칙을 ''자주 바뀜 → 안 바뀜''으로만 단순화하면, 추상화의 안정성이나 정책/세부사항 구분을 놓칠 수 있다.; 예시와 검증 명령이 Unity/grep 중심이라 Windows PowerShell 또는 비Unity 프로젝트에서는 명령을 바꿔야 한다.; 여러 동기가 동시에 강한 프로젝트에서 ''하나만 고정'' 규칙이 지나치게 좁게 작동할 수 있다.; 인터페이스를 너무 일찍 만들면 실제 변경축이 검증되기 전에 추상화가 과해질 수 있다.'
    action: review
    path: 40_Skills/candidate/c-architect-02.md
    ecosystem: 'partial:product-spec'
  - id: c-architect-03
    name: 데이터 흐름 설계
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-architect-02(데이터 소유권과 API 경계를 정하면서 모듈 간 책임·인터페이스 방향과 일부 맞닿는다.); c-architect-05(실시간 푸시, 오프라인 큐잉, 서버 권위 여부처럼 비용·확장성·유지보수 판단을 포함한다.); c-planner-02(기능 구현 전 수용 가능 상태를 체크리스트와 게이트로 정의한다는 점에서 일부 겹친다.); c-planner-03(화면·데이터·플로우 전체 설계 중 데이터와 이벤트 흐름 부분을 깊게 다룬다.); c-planner-06(오프라인, 중복 이벤트, 재시도, 보안 경계 등 실패 모드와 위험을 식별한다.); c-planner-07(구현에 넘기기 전 데이터/API/운영 게이트를 점검하는 준비도 확인 역할을 한다.); klv:first-packet(구현 전 서버 책임, 클라 책임, do-not-touch를 정리해 구현 패킷 형태로 넘긴다.); workflow-translator(막연한 기능 요청을 데이터 항목, API, 이벤트 흐름, 구현 책임으로 구체화한다.)'
    value: 클라-서버-DB 경계와 상태 소유권을 정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 데이터 소유권·API·동기화·운영 게이트를 실전적으로 고정하는 고품질 설계 스킬이다.  리스크: 서버가 없는 제품이나 완전 로컬 앱에서는 권위 데이터=서버라는 기본값을 그대로 적용하기 어렵고, 로컬 신뢰 모델을 별도로 정의해야 한다.; 파생 데이터 ''저장 금지'' 규칙은 대체로 맞지만 검색 인덱스, 캐시, 분석용 스냅샷처럼 의도적으로 비정규화하는 경우에는 예외 기준이 필요하다.; 오프라인 우선 제품에서 큐잉/충돌 해결이 핵심인 경우 현재 절차는 1인 개발 기본값 중심이라 CRDT, merge policy, conflict UI 같은 고급 설계가 부족할 수 있다.; 보안·개인정보 게이트는 실무적으로 유용하지만 지역별 법규, 삭제 요청, 동의, 아동 데이터 같은 컴플라이언스 전제는 별도 확인이 필요하다.; 멱등키와 dedup 저장 기간, 재사용 범위, 응답 재현 정책까지는 명시하지 않아 결제/외부 API에서는 추가 설계가 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/c-architect-03.md
    ecosystem: 'partial:sprint-web'
  - id: c-architect-04
    name: 빌드·환경 전략
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-architect-01(엔진·호스팅 선택 이후 해당 타깃에 맞는 빌드·배포 배선을 다루므로 호스팅 판단 영역과 인접하다.); c-architect-05(비용·운영 부담·롤백 가능성 등 확장성·유지보수 관점의 결정 근거와 일부 맞닿아 있다.); c-planner-06(환경 장애, 비밀 누출, 롤백 실패 같은 실패 모드와 리스크 게이트를 구체화한다.); c-planner-07(구현·배포 전 준비도 점검 항목으로 빌드, 환경변수, CI, 롤백 검증을 제공한다.); klv:first-packet(구현 전 Phase-0 패킷의 빌드·환경 섹션에 들어갈 산출물을 만든다.); workflow-translator(막연한 배포·환경 요구를 실행 가능한 명령, 표, 체크리스트로 구체화하는 역할이 일부 겹친다.)'
    value: 리포 구조·CI·배포 타깃을 잡을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자의 빌드·환경·비밀·CI·롤백 사고를 줄이는 매우 구체적이고 검증 가능한 고품질 스킬이다.  리스크: 스택별 명령과 도구명은 빠르게 바뀔 수 있어 사용 시 공식 문서 확인이 필수다.; `git log --all -p | grep` 같은 예시는 Windows PowerShell 환경에서는 그대로 동작하지 않을 수 있어 대체 명령 안내가 있으면 더 안전하다.; Next.js, Cloudflare, Flutter, Unity 중심이라 다른 스택에서는 표를 그대로 적용하기보다 원칙만 가져가야 한다.; 비밀 누출 점검은 키 이름 패턴만으로는 부족할 수 있어 실제 토큰 패턴, secret scanning, 키 회전 절차가 필요할 수 있다.; DB 마이그레이션의 down 스크립트가 항상 현실적인 것은 아니므로 백업·포워드 픽스 전략 구분이 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/c-architect-04.md
    ecosystem: 'partial:sprint-web'
  - id: c-architect-05
    name: 기술 리스크·트레이드오프
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-architect-01(엔진·언어·프레임워크·호스팅 같은 기술 선택 상황에서 후보 비교와 결정 근거를 다룬다.); c-architect-02(벤더 종속을 줄이기 위한 인터페이스·격리 코드·의존 경계 설정이 겹친다.); c-architect-03(클라-서버-DB 경계, 상태 소유권, 백엔드 선택처럼 구조적 기술 결정에서 함께 쓰일 수 있다.); c-architect-04(호스팅·배포 타깃·CI 구조 선택처럼 장기 운영 비용과 되돌리기 비용이 큰 결정과 맞닿는다.); c-planner-05(가치·노력·리스크로 우선순위를 비교하는 방식과 점수화 사고가 유사하지만, 이 스킬은 기술 선택 내부의 트레이드오프에 집중한다.); c-planner-06(불확실성, 의존성, 실패 모드, 재검토 조건을 명시한다는 점에서 리스크 식별 영역이 겹친다.); c-researcher-04(가격·한도·SLA 같은 수치를 공식 출처와 실측으로 검증하도록 요구한다.); c-planner-07(구현 전에 결정 근거, 검증 결과, 실패 조건, 파일 경계를 준비 상태로 점검한다.)'
    value: 확장성·비용·유지보수를 저울질해 결정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 기술 선택을 정량 비교, 실패 조건, 탈출 경로, 실측 검증까지 연결하는 고품질 아키텍트 스킬이다.  리스크: 점수 기준의 1/2/3 임계값이 예시 중심이라 도메인별로 조정하지 않으면 잘못된 정밀감을 줄 수 있다.; 가중치를 가장 빡센 축 하나에만 2로 주는 규칙은 단순하고 실용적이지만, 비용과 법규·성능이 동시에 빡센 결정에서는 왜곡될 수 있다.; Type 2를 30분 안에 결정하도록 권장하는 부분은 작은 선택에는 좋지만, 보안·개인정보·결제처럼 되돌리기 비용은 낮아 보여도 사고 비용이 큰 영역에서는 과소분석 위험이 있다.; spike를 0.5~1 man-day로 제한하는 기준은 1인 개발자에게 현실적이지만, 데이터 마이그레이션·규모 추정·벤더 과금 모델이 복잡한 경우 검증 범위가 부족할 수 있다.; 예시의 일부 서비스 한도·가격 수치는 시간이 지나면 바뀔 수 있으므로 실제 사용 시 반드시 최신 공식 문서 확인이 필요하다.'
    action: review
    path: 40_Skills/candidate/c-architect-05.md
    ecosystem: 'delegate:product-spec'
  - id: c-planner-01
    name: 비전 원페이저
    category: common
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-02(기능을 명세하고 수용기준, 비목표, 완료 기준을 남기는 부분이 겹친다.); c-planner-03(화면, 데이터, 플로우 등 구현 전 전체 설계로 넘기는 실행 패킷 작성과 연결된다.); c-planner-04(이번 범위와 나중 범위를 나누고 MVP가 커지지 않게 제한하는 절차가 겹친다.); c-planner-05(가치, 노력, 리스크 기준으로 대안을 비교하고 권장안을 선택하는 부분이 겹친다.); c-planner-06(리스크, 불확실성, 실패 기준, 재설계 조건을 명시하는 부분이 겹친다.); c-planner-07(구현에 넘기기 전 산출물이 실행 가능한지 게이트로 점검하는 목적이 겹친다.); c-researcher-03(누구의 어떤 상황에서 무엇을 정하는지 한 문장으로 고정하는 문제 정의가 겹친다.); workflow-translator(막연한 제품/개발 요청을 구현 가능한 계획과 체크리스트로 변환하는 흐름이 겹친다.); klv:first-packet(구현 전에 Phase-0 성격의 계획 패킷을 만들고 파일, 화면, 테스트, 완료 기준으로 넘기는 점이 겹친다.)'
    value: 무엇을·왜·누구에게를 한 장으로 정리할 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 1인 개발자의 제품 기획 결정을 짧은 실행 패킷으로 바꾸는 실용적인 스킬이며, 예시와 단계별 깊이만 보강하면 더 강해진다.  리스크: 비전, 전략, 기능 명세, 실행 계획이 한 문서에 섞일 수 있어 초점이 흐려질 수 있다.; 예시가 구체 제품 사례가 아니라 메타 설명이라 사용자가 실제 산출물의 깊이와 형태를 판단하기 어렵다.; 평가 기준의 가중치나 선택 방식이 없어 대안 비교가 형식적으로 끝날 수 있다.; 검증 지표를 정하라고는 하지만 정량 지표, 사용자 피드백, 기술 검증 중 무엇을 택할지 안내가 부족하다.; 현재 단계별로 아이디어/MVP/운영 중에서 산출물 깊이를 어떻게 달리할지 기준이 약하다.'
    action: use
    path: 40_Skills/candidate/c-planner-01.md
    ecosystem: 'delegate:gatecraft'
  - id: c-planner-02
    name: PRD 작성
    category: common
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-01(제품의 무엇을·왜·누구에게 제공할지 정리하는 초기 기획 산출물 영역이 PRD Context/Goal과 겹친다.); c-planner-03(화면, 데이터, 플로우 설계를 PRD 실행 패킷으로 넘기는 부분이 전체 설계 작업과 맞닿아 있다.); c-planner-04(Prototype/MVP/V1/Later로 범위를 자르는 작업이 PRD의 범위 결정 및 비목표 설정과 겹친다.); c-planner-05(가치·노력·리스크 기준으로 대안을 비교하고 권장안을 선택하는 절차가 우선순위 결정과 겹친다.); c-planner-06(리스크, 불확실성, 실패 기준을 정리하는 게이트가 실패 모드 목록화와 겹친다.); c-planner-07(구현에 넘기기 전 준비도와 완료 기준을 점검하는 성격이 PRD의 Execution Packet/Gate와 겹친다.); c-researcher-03(누구의 어떤 문제인지 한 문장으로 고정하는 부분이 목표 정의 단계와 겹친다.); workflow-translator(막연한 개발 요청을 구현 가능한 계획과 작업 패킷으로 바꾸는 기능이 PRD 작성 산출물과 겹친다.); klv:first-packet(구현 전 Phase-0 계획 패킷을 만드는 흐름이 PRD의 실행 패킷 작성과 겹친다.)'
    value: 기능을 수용기준·비목표와 함께 명세할 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 절차와 게이트가 실용적인 1인 개발자용 PRD 스킬이며, 실제 예시와 PRD 핵심 항목을 보강하면 더 강해진다.  리스크: PRD라는 이름에 비해 기능 요구사항, 비기능 요구사항, 사용자 시나리오, 성공 지표 항목이 약해 산출물이 결정 메모 수준에 머물 수 있다.; 예시가 너무 일반적이라 초보 사용자가 실제 프로젝트에 어떻게 채워야 하는지 감을 잡기 어렵다.; 검증 게이트가 지표·테스트·리뷰 방법을 요구하지만, 정량 지표를 못 잡는 초기 아이디어 단계에서 대체 증거를 어떻게 둘지 안내가 부족하다.; 관련 자료가 부족한 상황에서 대안 2~3개 생성을 강제하면 억지 비교표가 될 수 있다.'
    action: use
    path: 40_Skills/candidate/c-planner-02.md
    ecosystem: 'delegate:product-spec'
  - id: c-planner-03
    name: 전체 블루프린트
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-01(무엇을·왜·누구에게를 한 장으로 정리하는 비전 고정 영역이 겹친다.); c-planner-04(V1 경계와 IN/OUT/LATER 범위 설정이 Prototype/MVP/V1/Later 범위 컷과 맞닿아 있다.); c-planner-05(마일스톤과 우선순위 판단에서 가치·노력·리스크 기반 선택과 일부 접점이 있다.); c-planner-06(최상위 리스크 3개, 조기 신호, 첫 대응을 정리하는 부분이 실패 모드 목록화와 겹친다.); c-planner-07(구현 전 기준점과 준비 상태를 만드는 측면에서 핸드오프 전 점검과 연결된다.); klv:first-packet(프로젝트 전체 헌장과 구현 전 Phase-0 계획 패킷이 모두 후속 실행의 기준 문서를 만든다.); klv:ssot-index(흩어진 방향성을 단일 기준점으로 압축한다는 SSoT 성격이 겹친다.); workflow-translator(막연한 요청을 구현 가능한 계획으로 바꾸는 과정 중 상위 기획 고정 단계와 접점이 있다.); c-researcher-03(누구의 어떤 문제인지 한 문장으로 못박는 비전 문장 구성과 겹친다.)'
    value: 화면·데이터·플로우 전체 설계를 세울 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발 프로젝트의 상위 방향을 한 장으로 고정하는 목적에 매우 잘 맞는 고품질 스킬이다.  리스크: 8주 제한은 1인 개발 가드로 유용하지만, 플랫폼 심사·하드웨어·콘텐츠 제작이 큰 프로젝트에서는 과도하게 단순화될 수 있다.; 80_Decisions 경로가 내부 규칙에 의존하므로 해당 구조가 없는 프로젝트에서는 대체 기록 위치를 정해야 한다.; A4 1장 강제가 강점이지만 법규·보안·의료·금융처럼 필수 제약이 많은 프로젝트에서는 별도 부록 전제가 필요하다.; 경쟁 제품이 선택 입력이라 시장 검증이 약한 상태에서도 블루프린트가 확정된 것처럼 보일 수 있다.'
    action: review
    path: 40_Skills/candidate/c-planner-03.md
    ecosystem: 'delegate:gatecraft'
  - id: c-planner-04
    name: MVP 범위 컷
    category: common
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-01(무엇을 왜 누구에게 제공할지 한 장으로 정리하는 초기 제품 정의와 MVP 목표 고정 단계가 겹친다.); c-planner-02(기능 범위, 수용기준, 비목표를 명세하는 부분이 MVP 컷 이후 실행 패킷과 직접 연결된다.); c-planner-03(화면·데이터·플로우 전체 설계를 세우기 전에 MVP에 포함할 범위를 정하는 단계에서 맞닿는다.); c-planner-05(가치·노력·리스크 기준으로 선택지를 비교해 무엇부터 할지 정하는 판단 구조가 겹친다.); c-planner-06(리스크, 불확실성, 실패 기준을 명시하는 검증 게이트 부분이 겹친다.); c-planner-07(구현에 넘기기 전 준비도와 완료 기준을 점검하는 실행 가능성 확인 단계가 겹친다.); klv:first-packet(구현 전 Phase-0 계획 패킷으로 넘길 산출물을 만드는 목적과 실행 패킷 구성이 유사하다.); workflow-translator(막연한 제품 요청을 구현 가능한 계획과 체크리스트로 바꾸는 역할이 일부 겹친다.); c-researcher-03(누구의 어떤 문제인지 한 문장으로 고정하는 문제 정의 단계가 겹친다.); c-researcher-05(여러 아이디어를 가치와 실현성으로 줄 세워 좁히는 의사결정 방식이 겹친다.)'
    value: Prototype/MVP/V1/Later로 범위를 자를 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 절차와 산출물 구조는 좋지만, 실제 범위 컷을 재현할 수 있는 평가 규칙과 현실적인 예시를 보강하면 승격 가능한 스킬이다.  리스크: 평가 기준은 있으나 점수화 방식이나 선택 규칙이 없어 사용자에 따라 결론이 임의적으로 달라질 수 있다.; MVP 컷에서 흔한 핵심 질문인 ''반드시 학습해야 하는 가설''과 ''없어도 되는 기능''의 구분이 더 명시되면 좋다.; 예시가 일반론 수준이라 실제 제품 사례, 기능 목록, 버린 범위, 통과 지표가 포함된 샘플이 부족하다.; 기술 부채나 운영 비용 같은 1인 개발자의 지속 가능성 기준이 체크리스트에 약하게 반영되어 있다.'
    action: use
    path: 40_Skills/candidate/c-planner-04.md
    ecosystem: 'delegate:gatecraft'
  - id: c-planner-05
    name: 우선순위 결정
    category: common
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-04(Prototype/MVP/V1/Later 범위 자르기와 이번 사이클 컷라인 결정이 연결된다.); c-planner-06(Risk와 Confidence를 통해 불확실성·실패 가능성을 우선순위 산정에 반영한다.); c-researcher-05(여러 아이디어를 가치·실현성 기준으로 줄세우는 목적이 유사하되, 이 초안은 실행 사이클 우선순위에 더 가깝다.); c-architect-05(확장성·비용·유지보수 트레이드오프가 Effort와 Risk 판단에 일부 들어간다.); c-planner-07(구현에 넘기기 전 무엇을 이번 사이클에 넣을지 준비도와 실행 가능성을 점검하는 흐름과 맞닿아 있다.)'
    value: 가치·노력·리스크로 무엇부터 할지 정할 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 1인 개발자가 후보 기능을 같은 기준으로 줄세우고 사이클 범위를 자르기에 충분히 구체적인 우선순위 스킬이다.  리스크: Reach 척도가 사용자 수, 비율, 배수로 혼용될 수 있어 프로젝트마다 점수 비교가 흔들릴 수 있다.; 기능 간 의존성이나 선후관계가 있는 경우 단순 Score 내림차순만으로는 잘못된 실행 순서가 나올 수 있다.; 강제 항목을 0순위로 고정하는 기준이 넓게 해석되면 모든 이해관계자가 자기 항목을 강제로 올릴 위험이 있다.; 운영 중 지표 기반이라고 해도 해당 기능이 실제로 전환·리텐션·매출에 미치는 인과 추정 방법은 별도로 필요하다.; Risk를 나눗셈 가중치로만 처리하면 보안·법규·데이터 손실처럼 낮은 확률의 치명 리스크를 과소평가할 수 있다.'
    action: use
    path: 40_Skills/candidate/c-planner-05.md
    ecosystem: 'delegate:superpowers'
  - id: c-planner-06
    name: 리스크 등록부
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-04(범위(scope) 리스크와 MVP 경계, 범위 축소 컨틴전시가 겹친다.); c-planner-05(가치·노력·리스크 기반 우선순위 판단에서 식별된 리스크가 이 등록부의 입력으로 이어진다.); c-planner-07(구현 전 준비도 점검 과정에서 남은 리스크와 외부 의존성을 확인하는 영역이 겹친다.); c-architect-05(확장성·비용·유지보수 결정의 실패 가능성과 영향 평가가 리스크 등록부의 기술/운영 리스크와 맞닿아 있다.); klv:first-packet(구현 전 Phase-0 계획 패킷에서 위험·의존성·차단 요소를 정리하는 부분과 연결된다.)'
    value: 불확실성·의존성·실패 모드를 목록화할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 운영 가능한 리스크 등록부 스킬로 완성도가 높지만, 등급 기준의 13~14점 누락은 수정이 필요하다.  리스크: 등급 기준이 High 15~25, Medium 6~12, Low 1~5로 되어 있어 13~14점의 등급이 정의되지 않았다.; 리스크 최소 5개 권장은 작은 작업에서 형식 채우기식 가짜 리스크를 만들 수 있다.; 카테고리별 최소 1개 강제는 유용하지만, 특정 프로젝트에 외부의존이 거의 없을 때 품질보다 균형을 우선하게 만들 수 있다.; 가능성 확률값을 5단계로 고정하면 근거 없는 정밀함이 생길 수 있어 추정 근거 필드가 있으면 더 안전하다.; 예시의 검토일이 월일만 있어 연도·타임존이 필요한 장기 프로젝트에서는 모호할 수 있다.; 1인 개발자의 에스컬레이션 대상이 무엇인지 모호할 수 있어 일정 연기, 범위 절단, 출시 보류 같은 자기 결정 기준을 더 명시하면 좋다.'
    action: review
    path: 40_Skills/candidate/c-planner-06.md
    ecosystem: 'delegate:gatecraft'
  - id: c-researcher-01
    name: 시장 신호 리서치
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-01(시장 신호를 바탕으로 무엇을 왜 누구에게 만들지 정리하는 단계와 이어지며 일부 문제 정의 영역이 맞닿는다.); c-planner-05(기회 가설을 만든 뒤 가치·노력·리스크로 우선순위를 정하는 후속 판단과 연결된다.); c-planner-06(반증 조건, 실패 가능성, 불확실성 식별 방식이 일부 겹친다.); c-researcher-02(리뷰 통증, 경쟁 출시, 스토어 차트 신호를 볼 때 유사 제품 분석과 접점이 있다.); c-researcher-03(강신호를 타깃·상황·통증 문장으로 바꾸는 과정이 문제 정의와 연결된다.); c-researcher-04(검색량, 리뷰 수, 차트 등 수치 신호를 다루며 후속 다출처 검증으로 자연스럽게 이어진다.); c-researcher-05(여러 기회 가설을 만들지만 최종 줄세우기는 넘기는 구조라 입력·출력 경계가 맞닿는다.)'
    value: 트렌드·수요·경쟁 신호로 기회를 포착할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 시장 신호를 기회 가설로 압축하는 리서처 절차로서 구체성·검증가능성·역할 경계가 모두 우수하다.  리스크: 점수 곱 모델의 임계값이 경험적 기준이라 분야별로 과대·과소평가될 수 있다.; 무료 도구의 지역별 접근성, 검색 개인화, 스토어 랭킹 노출 방식 차이가 결과를 왜곡할 수 있다.; 커뮤니티·리뷰 데이터를 수집할 때 표본 수와 독립성 기준이 더 엄격하지 않으면 같은 사용자군의 반복 의견을 독립 신호로 착각할 수 있다.; 디스코드, 카페, 갤러리 등 폐쇄·반폐쇄 커뮤니티는 접근 권한과 인용 가능성 문제가 생길 수 있다.; 정량값이 부족한 초기 시장이나 신생 장르에서는 강신호 기준을 통과하기 어려워 탐색적 기회를 놓칠 수 있다.'
    action: review
    path: 40_Skills/candidate/c-researcher-01.md
    ecosystem: 'delegate:signalcraft'
  - id: c-researcher-02
    name: 경쟁·벤치마크 분석
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-researcher-01(시장·경쟁 신호를 보며 제품 기회를 찾는 단계와 인접하지만, 이 초안은 이미 정해진 카테고리 안에서 현존 대안의 비교 매트릭스와 빈틈을 도출하는 데 초점이 있다.); c-researcher-04(가격·기능·리뷰 출처 확인과 수집일 기록이 포함되어 일부 검증 활동과 맞닿지만, 본 스킬은 엄밀한 다출처 검증 자체보다 경쟁 해부 산출물 작성이 중심이다.); c-researcher-05(도출한 빈틈을 차별화 가설 1~3개로 압축하는 부분이 아이디어 선별과 닿아 있으나, 가치·실현성으로 여러 아이디어를 줄세우는 절차와는 목적이 다르다.); c-planner-01(왜 우리를 써야 하는지와 포지셔닝 한 줄을 만드는 데 도움이 되어 제품 정의와 연결된다.); c-planner-05(빈틈 중 6개월 내 만들 수 있고 사용자가 돈이나 시간을 바꿀 만한 것을 남기는 단계가 우선순위 판단과 인접하다.); c-researcher-03(사용자가 같은 문제를 어떤 대체재로 해결하는지 보는 JTBD 관점이 문제 정의와 맞닿아 있다.)'
    value: 유사 제품의 강약점·포지셔닝을 비교할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 경쟁 제품을 사용자 대체성 기준으로 구조화하고 차별화 빈틈까지 뽑아내는 고품질 리서처 스킬이다.  리스크: 온보딩 시간이나 1인 운용 난이도처럼 직접 써봐야 정확한 항목은 공개 정보만으로는 추정이 섞일 수 있어, 체험 여부와 추정 근거를 별도 표시하는 규칙이 있으면 더 안전하다.; 경쟁자 3~5개 제한은 0.5~1일 조사에는 적절하지만, 카테고리가 넓으면 표본 편향이 생길 수 있다.; 공식 홈페이지의 포지셔닝 문구만 보면 실제 사용자 인식과 괴리가 있을 수 있으므로 리뷰·커뮤니티 신호를 보조 근거로 분리해 다루는 기준이 필요하다.; 가격 비교에서 지역별 가격, 연간 할인, 사용량 제한, 팀/개인 플랜 차이를 단순 진입가로만 보면 오판할 수 있다.'
    action: review
    path: 40_Skills/candidate/c-researcher-02.md
    ecosystem: 'delegate:signalcraft'
  - id: c-researcher-03
    name: 사용자 문제 정의
    category: common
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-01(무엇을·왜·누구에게를 한 장으로 정리하는 문제 정의와 직접 맞닿아 있다.); c-planner-02(수용기준, 비목표, 완료 기준을 포함해 구현 전 명세로 넘기는 부분이 겹친다.); c-planner-04(이번 범위와 나중 범위를 자르고 MVP 크기를 제한하는 절차가 겹친다.); c-planner-05(가치·노력·리스크 기준으로 대안을 비교하고 선택하는 부분이 겹친다.); c-planner-06(가정, 리스크, 실패 조건, 검증 게이트를 목록화하는 방식이 겹친다.); c-researcher-01(사용자 문제와 시장·수요 신호를 바탕으로 기회를 정의하는 리서치 흐름과 연결된다.); c-researcher-02(경쟁 사례를 입력으로 삼고 대안을 비교하는 부분이 유사 제품 분석과 맞닿아 있다.); c-researcher-05(여러 선택지를 가치·실현성 기준으로 줄세우는 절차가 겹친다.); c-planner-07(구현에 넘기기 전 실행 가능성, 완료 기준, 테스트 준비도를 점검하는 게이트가 겹친다.); workflow-translator(막연한 요청을 구현 가능한 작업 패킷으로 변환하는 산출물 방향이 유사하다.)'
    value: 누구의 어떤 문제인지 한 문장으로 못박을 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 실행 가능한 사용자 문제 정의 절차로 충분히 좋지만, 현실 예시와 문제 탐색 질문을 보강하면 더 강해진다.  리스크: 실제 사용자 문제를 정의하는 방법, 예를 들어 사용자 세그먼트, 상황, 고통, 현재 대안, 빈도, 심각도 등을 끌어내는 질문이 부족하다.; 예시가 너무 일반적이라 초보자가 좋은 산출물과 나쁜 산출물을 구분하기 어렵다.; 검증 지표를 요구하지만 정성 인터뷰, 로그 지표, 랜딩 테스트, 수동 운영 검증 등 상황별 검증 방법 선택 기준은 약하다.; 대안 비교가 기능/해결책 중심으로 흐를 수 있고, 문제 자체를 재정의하거나 폐기하는 선택지가 명시되어 있지 않다.; References가 구체 문서나 적용 포인트 없이 제목 수준이라 재현 가능한 근거로 쓰기 어렵다.'
    action: use
    path: 40_Skills/candidate/c-researcher-03.md
    ecosystem: 'delegate:gatecraft'
  - id: c-researcher-04
    name: 딥 팩트체크 리서치
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-researcher-01(트렌드·수요·경쟁 신호를 조사할 때 외부 주장과 수치의 사실 여부를 검증하는 보조 단계로 겹친다.); c-researcher-02(경쟁 제품 기능·가격·스펙 비교표의 각 셀 값이 사실인지 확인하는 단계에서 겹친다.); c-planner-05(우선순위 판단의 입력값이 되는 가치·노력·리스크 주장들을 검증할 때 접점이 있다.); c-planner-06(불확실성과 실패 모드를 목록화할 때, 특정 전제가 사실인지 라벨링하는 방식이 일부 겹친다.); c-planner-07(구현 전 준비도 점검에서 근거 자료와 외부 전제의 신뢰성을 확인하는 데 연결된다.)'
    value: 주장·수치를 다출처·인용으로 검증할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 사실 검증 전용 역할로 목적·절차·라벨·출력물이 탄탄해 바로 카탈로그에 올릴 만하다.  리스크: 1차 출처 1개로 충분한 경우와 독립 2차 출처 2개 이상으로 충분한 경우의 경계가 실제로는 애매할 수 있다.; ''6개월 넘은 정책 주장은 자동 한 단계 하향'' 규칙은 보수적이지만, 안정적인 표준·법령·문서에는 과도하게 적용될 수 있다.; 원문 접근 불가를 항상 미확인으로 두는 원칙은 엄격하지만, 유료 리포트나 폐쇄형 데이터가 업계 표준 출처인 분야에서는 별도 판단 기준이 필요할 수 있다.; 검색 방법, 쿼리 작성, 아카이브 확인 같은 실무 탐색 요령은 상대적으로 적어 초보자는 1차 출처 도달에서 막힐 수 있다.'
    action: review
    path: 40_Skills/candidate/c-researcher-04.md
    ecosystem: 'delegate:deep-research'
  - id: c-researcher-05
    name: 컨셉 후보 점수화
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-researcher-01(트렌드·수요·경쟁 신호를 바탕으로 제품 기회를 판단하는 전단계 리서치와 겹친다.); c-researcher-02(유사 제품의 강약점·포지셔닝 비교가 Market·Edge·Money 점수의 핵심 입력으로 쓰인다.); c-researcher-03(각 후보를 ''누구의 어떤 문제를 어떻게 푼다'' 형식으로 정리하는 문제 정의 산출물과 연결된다.); c-researcher-04(검색량·리뷰·매출 추정 등 점수 근거의 신뢰도 검증이 Confidence 산정에 직접 필요하다.); c-planner-01(선정된 컨셉을 무엇·왜·누구에게 만들지 한 장으로 정리하는 단계와 이어진다.); c-planner-04(선정 후 Prototype/MVP/V1 범위 자르기로 넘어가며, 실현 가능성 판단 기준 일부가 맞닿아 있다.); c-planner-05(가중 점수화와 Confidence 개념을 공유하지만, 기능 우선순위가 아니라 제품 컨셉 선택에 적용한다.); c-planner-06(최저 축 리스크와 실패 가능성을 식별해 다음 단계 리스크 목록화로 넘긴다.); c-architect-05(확장성·비용·유지보수 판단이 Feasibility와 컷오프 조건에 영향을 준다.)'
    value: 여러 아이디어를 가치·실현성으로 줄세울 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자의 제품 컨셉 선택을 근거 기반으로 좁히는 절차가 구체적이고 실전성이 높아 승격 권장.  리스크: Market·Edge·Money의 1~5점 기준이 여전히 해석자마다 달라질 수 있어, 실제 사용 시 점수 보정 예시가 더 필요할 수 있다.; Confidence를 곱하면 근거 부족 후보가 강하게 깎이는 장점이 있지만, 근거를 얻기 쉬운 익숙한 시장에 과도하게 유리해질 수 있다.; 후보당 30분 데스크 리서치는 초기 필터로는 좋지만, 고비용·고위험 컨셉을 최종 확정하기에는 부족할 수 있다.; SteamDB·Sensor Tower 같은 데이터 소스는 접근성·정확도·유료 여부가 달라 Money와 Market 점수의 재현성이 흔들릴 수 있다.; 컷오프 조건을 사전에 충분히 구체화하지 않으면 점수 결과를 본 뒤 탈락 기준을 사후 조정하는 편향이 생길 수 있다.'
    action: review
    path: 40_Skills/candidate/c-researcher-05.md
    ecosystem: 'delegate:signalcraft'
  - id: g-client-01
    name: Unity 프로젝트 스켈레톤
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-02(Boot→Main 흐름과 GameManager 상태 enum이 최소 루프 구현 직전의 기반을 제공한다.); g-client-03(UIRoot Canvas, EventSystem, TMP Essentials, BootView 같은 UI 초기 구조를 일부 만든다.); g-client-04(GameSettings ScriptableObject와 Settings SO 패턴을 초기 스켈레톤에 포함한다.); g-client-05(Input System 패키지 설치와 빈 inputactions 자산 생성까지 다룬다.); g-client-08(대상 플랫폼 1순위 빌드 게이트와 Build Settings, URP/플랫폼 설정 일부를 다룬다.); g-qa-01(스켈레톤 완료 조건을 빌드 로그와 체크리스트로 검증하게 한다.); g-qa-05(대상 플랫폼과 기준 해상도, 1회 플랫폼 빌드 확인이 기기·해상도 검증의 초기 전제와 맞닿는다.); g-ux-01(Boot 씬과 Main 씬의 초기 화면 흐름을 최소 수준으로 정의한다.); g-ux-03(UIRoot와 EventSystem을 표준화해 이후 HUD·패널 규칙의 기반이 된다.); g-director-10(구현 넘기기 전 준비도 점검처럼 g-client-02로 넘길 준비 상태를 고정한다.)'
    value: 씬·매니저·폴더·플레이스홀더 뼈대를 세울 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · Unity 초기 프로젝트를 플레이 가능한 최소 루프 직전까지 안정적으로 세우는 고품질 g-client 스켈레톤 스킬이다.  리스크: MonoSingleton과 R3를 프로젝트 관행으로 전제하지만, 신규 프로젝트에서 해당 기반이 없을 때 ''만들지 말고 확인'' 이후 어떻게 진행할지 결정 규칙이 약간 비어 있다.; BootView가 Boot 씬용 로딩 표시인지 Main 씬 생존 확인용인지 표현이 혼재되어 실제 배치 시 혼동될 수 있다.; Unity 6000.x와 2022.3.x, URP 버전 차이에 따른 구체 작업 경로가 달라질 수 있어 버전별 예외 처리 지침이 더 있으면 좋다.; 기존 프로젝트 정리에서 unity_asset_move 같은 도구가 없는 환경을 위한 대체 절차가 Unity 에디터 수동 이동 정도로만 제시되어 자동화 작업자에게는 애매할 수 있다.; Input System을 ''g-client-05가 채택했으면'' 설치한다고 되어 있어, 이 스킬 단독 적용 시 채택 여부를 누가 어떻게 결정하는지 전제가 필요하다.'
    action: review
    path: 40_Skills/candidate/g-client-01.md
    ecosystem: 'delegate:sprint-game'
  - id: g-client-02
    name: 코어루프 구현
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-02(코어루프 정의를 입력으로 받아 행동→보상→진행 루프를 실제 구현으로 옮긴다.); g-client-01(씬, 매니저, 폴더, 플레이스홀더 프리팹 구조 위에 코어루프 파일과 오브젝트를 배치한다.); g-client-04(CoreLoopSettings ScriptableObject로 보상량, 판정창, 딜레이 같은 튜닝값을 구조화한다.); g-client-05(입력 진입점과 플레이어 조작, 뷰 반응이 CoreLoopManager.Tick으로 연결된다.); g-client-06(루프 말미에 진행 저장 호출과 SaveManager 연동을 포함한다.); g-qa-01(Play 검증, 로그 순서, 2바퀴 반복 같은 테스트 관점을 산출물에 요구한다.); g-director-04(비목표(do-not-touch)와 수용기준을 구현 범위 통제로 사용한다.)'
    value: 플레이 가능한 최소 루프를 구현할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실행 가능한 코어루프 구현 스킬로 품질은 높지만, 구현 강제성과 예시 코드의 수명·전이 문제를 다듬은 뒤 승격하는 것이 좋다.  리스크: MonoSingleton, EventBus, R3, switch식 등을 프로젝트 관행이 아닌 필수처럼 강제하면 다른 Unity 구조와 맞지 않을 수 있다.; 예시 코드 첫 블록에서 Resolve가 LoopState.Resolve를 반환해 다음 Tick에서 보상으로 넘어가는 구조라 입력 1회에 한 바퀴가 돈다는 설명과 혼동된다. 아래 실예시는 Reward 반환이라 일관성 보완이 필요하다.; EventBus.Subscribe와 SaveAsObservable().Subscribe() 예시에 구독 해제·Dispose 수명 관리가 없어 Play 반복, 씬 전환, 도메인 리로드에서 중복 호출이나 누수가 생길 수 있다.; 직접 호출 금지라고 하면서 구독자 예시는 RewardManager.instance와 SaveManager.instance를 직접 호출하므로 의존성 규칙을 더 정확히 정의해야 한다.; 상태머신을 한 매니저에 몰아 넣으라는 지침은 초기 루프에는 좋지만, 비동기 연출·애니메이션·네트워크 판정이 들어가는 장르에서는 전이 완료 조건과 코루틴/Observable 경계가 추가로 필요하다.; 컴파일되는 스크립트와 실제 .unity/.asset 산출을 요구하지만, 새 Unity 프로젝트나 기존 컨벤션이 없는 경우 최소 대체 구조가 부족하다.'
    action: review
    path: 40_Skills/candidate/g-client-02.md
    ecosystem: 'delegate:sprint-game'
  - id: g-client-03
    name: Unity UI 구현
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-01(씬·매니저·폴더·프리팹 골격을 세우는 부분이 클라이언트 기본 구조화와 맞닿아 있다.); g-client-07(Canvas rebuild, batch, GC alloc, UI 성능 측정 기준이 최적화 스킬과 영역을 공유한다.); g-qa-05(해상도, safe area, 기기 빌드 측정, 다기기 UI 깨짐 확인이 기기 검증과 겹친다.); g-ux-01(화면 목록과 이동 흐름 산출물을 입력으로 받아 모달 스택과 화면 전환 구현으로 이어진다.); g-ux-02(레이아웃·상태·해상도 대응 명세를 실제 RectTransform과 LayoutGroup 설정으로 변환한다.); g-ux-03(버튼, 패널, HUD, 폰트, spacing 같은 UI 표준을 구현 단계에서 준수한다.); g-client-05(뒤로가기, ESC, 전환 중 입력 차단 등 UI 입력 처리에서 Input System 구현과 접점이 있다.)'
    value: uGUI·UI Toolkit·TextMeshPro로 화면을 만들 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · Unity UI 구현 역할에 맞는 절차성과 검증성이 매우 높아 바로 승격 가능한 스킬이다.  리스크: R3와 MonoSingleton 사용을 전제로 한 예시가 있어 해당 라이브러리나 프로젝트 패턴이 없는 팀은 대체 구현 기준이 필요하다.; UI Toolkit의 런타임/월드스페이스 한계와 uGUI 기본값 판단은 Unity 버전에 따라 달라질 수 있어 프로젝트 Unity 버전 기준 재확인이 필요하다.; UI 0B/frame 기준은 좋은 게이트지만 일부 TMP 동적 글리프 생성, 최초 로딩, 주소 지정 에셋 로딩 구간에서는 예외 구간을 분리해야 한다.; SafeAreaFitter는 핵심 컴포넌트로 언급되지만 구현 코드나 검증 방식이 없어 초보자가 잘못 매핑할 여지가 있다.; CanvasScaler Match 값 0.5 기본 제안은 출발점으로는 좋지만 특정 UI가 폭/높이 기준으로 설계된 경우 화면별 조정 근거가 필요하다.; TMP fallback 예시에서 기본 라틴/한글 순서가 프로젝트 주언어와 폰트 커버리지에 따라 달라질 수 있어 실제 글리프 포함 여부 확인이 필요하다.'
    action: review
    path: 40_Skills/candidate/g-client-03.md
    ecosystem: 'partial:unity-mcp'
  - id: g-client-04
    name: ScriptableObject 데이터 아키텍처
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-01(폴더 구조, 매니저, 데이터 접근 경로 등 프로젝트 뼈대와 일부 맞닿는다.); g-client-06(세이브 상태 분리, Addressables 사용 여부, 빌드 포함 데이터 로딩과 연결된다.); g-client-08(IL2CPP, Managed Stripping, 빌드 포함 여부, 플랫폼별 검증 게이트가 겹친다.); g-qa-01(데이터 무결성, Missing Reference, 범위 검증 등 검증 계획 수립과 겹친다.); g-qa-03(임포트 전후 git diff와 회귀 검증이 변경 안정성 점검과 연결된다.); g-director-06(밸런스 테이블과 보상·난이도 수치 관리에서 설계 데이터와 맞닿는다.)'
    value: 설정·밸런스·콘텐츠를 SO로 구조화할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · Unity SO 데이터 아키텍처를 판단·구현·검증까지 닫힌 절차로 제시한 고품질 스킬이다.  리스크: 예시 코드의 DB 조회에서 items가 null이거나 id가 비어 있거나 중복이면 ToDictionary 예외가 발생하므로 실제 템플릿에는 방어 로직이나 검증 전제 표시가 필요하다.; CSV 예시가 단순 Split('','')라 쉼표 포함 문자열, 따옴표, 빈 칸 처리에는 취약하다. 실사용 임포터는 CSV 파서 사용을 권장해야 한다.; CreateAssetMenu의 menuName이 특정 프로젝트명(NetcodeFramework)에 고정되어 있어 범용 스킬로는 ''프로젝트 컨벤션으로 치환'' 전제가 더 선명해야 한다.; Resources/StreamingAssets/Addressables 선택 기준이 일부 섞여 있어, Resources 사용의 메모리·빌드 관리 리스크를 조금 더 명시하면 좋다.'
    action: review
    path: 40_Skills/candidate/g-client-04.md
    ecosystem: 'partial:unity-mcp'
  - id: g-client-06
    name: Addressables·세이브
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-04(SO 기반 콘텐츠 정의와 세이브에 저장할 address/GUID 경계가 겹친다. 저장할 데이터의 의미와 에셋 참조 방식에서 토론 상대가 된다.); g-client-07(Addressables 로드/언로드, 번들 메모리 회수, Memory Profiler 검증은 메모리 최적화 영역과 겹친다.); g-client-08(원격 카탈로그, 플랫폼별 persistentDataPath, Android/iOS 빌드·배포 제약이 모바일 빌드 설정 영역과 맞닿는다.); g-qa-01(로드 성공률, 저장 손상 복구, 마이그레이션 검증 게이트를 정의하므로 테스트 설계와 겹친다.); g-qa-03(세이브 마이그레이션과 기존 저장 파일 호환성 확인은 회귀 검증 영역과 겹친다.); g-client-01(AssetLoader, SaveManager, 폴더 네이밍과 매니저 배치가 클라이언트 뼈대 구성과 접점이 있다.)'
    value: 에셋 로딩·진행 저장/복원을 다룰 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 절차와 검증은 강하지만 샘플 코드와 플랫폼/Addressables 정확도 보강 후 promote가 적절하다.  리스크: A3 샘플의 ReleaseByLabel(string label)은 label 파라미터를 사용하지 않고 모든 핸들을 Release하므로 실제 적용 시 다른 씬/공용 에셋까지 해제될 수 있다.; 동일 address를 동시에 LoadAsync로 요청하면 캐시 등록 전 중복 로드가 발생할 수 있어 동시성 처리 또는 in-flight task 캐시가 필요하다.; Addressables의 그룹, 라벨, 번들, 로드/언로드 단위를 1:1로 단순화해 설명해 실제 Bundle Mode와 의존성 번들 구성에서 오해가 생길 수 있다.; File.Delete 후 File.Move를 원자적 교체라고 단정하기 어렵고 플랫폼별 파일 시스템 동작 차이, flush/fsync 부재, File.Replace 지원 여부를 명시해야 한다.; Load에서 save.json이 아예 없을 때 ReadAllText 예외를 catch로 처리하는 흐름은 동작은 하지만 정상 첫 실행과 손상 케이스가 로그상 구분되지 않는다.; JsonUtility는 Dictionary, 프로퍼티, 다형성 등 제약이 크므로 세이브 모델이 복잡해질 때 대안이나 제한을 안내해야 한다.; HMAC을 언급하지만 키 관리, 서명 필드 분리, 검증 실패 정책이 없어 리더보드용으로 적용할 때 설계 공백이 있다.; iOS 백업 대상 설명은 단순화되어 있으며 iCloud 백업 제외가 필요한 캐시성 데이터와 영구 세이브를 구분해야 한다.'
    action: review
    path: 40_Skills/candidate/g-client-06.md
    ecosystem: 'partial:unity-mcp'
  - id: g-client-07
    name: Unity 프로파일러 최적화
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-08(실기기 Development Build, IL2CPP, Autoconnect Profiler, VSync 등 성능 측정 전제와 빌드 설정이 맞닿아 있다.); g-qa-01(최적화 결과를 통과/실패 기준과 수치 게이트로 넘기는 부분이 검증 설계와 겹친다.); g-qa-05(기준 기기 외 여러 모바일 기기에서 성능을 확인하는 매트릭스 검증과 이어진다.); g-client-06(메모리 병목, 중복 로드, 텍스처·에셋 관리 처방이 에셋 로딩 및 저장/복원 영역과 일부 만난다.); g-client-03(TMP 텍스트 갱신, HUD 문자열 할당 등 UI 구현 성능 문제를 다루는 부분이 일부 겹친다.)'
    value: 드로콜·GC·배칭·메모리를 줄일 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 매우 실전적인 Unity 성능 진단 스킬이며, 몇 가지 API·지표 해석 주의만 보완하면 바로 카탈로그에 올릴 수 있다.  리스크: `QApplication.targetFrameRate`는 Unity C# API가 아니므로 `Application.targetFrameRate`로 고쳐야 한다.; `Gfx.WaitForPresent`가 크다는 신호는 GPU 병목뿐 아니라 VSync, 프레임 제한, 드라이버 대기 등과도 섞일 수 있어 해석 주의가 필요하다.; Development Build 자체 오버헤드가 있어 최종 성능 판단에는 Release 빌드 또는 비개발 빌드 재확인이 필요할 수 있다.; SetPass, Batches, 메모리 예산은 URP/Built-in/HDRP, 2D/3D, 기기 등급에 따라 달라져 절대 기준처럼 쓰면 오판할 수 있다.; GC 핫패스 0 B/frame 원칙은 좋지만 예시의 0.4KB를 ‘거의 O’로 처리해 게이트 기준이 흐려질 수 있다.; Frame Debugger와 Memory Profiler 사용법은 패키지 설치, Unity 버전, 모바일 연결 상태에 따라 추가 전제가 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/g-client-07.md
    ecosystem: 'delegate:unity-mcp'
  - id: g-client-08
    name: Unity 모바일 빌드
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-qa-01(빌드 산출물의 통과 기준과 검증 게이트를 정의하는 부분이 QA 검증 계획과 맞닿아 있다.); g-qa-05(실기기 설치, 첫 실행, 여러 단말/해상도 검증 전 단계와 일부 겹친다.); g-client-07(빌드 크기와 cold start 측정은 성능 프로파일링 영역과 부분적으로 만난다.); g-director-04(스토어 제출 전 수용기준과 실패조건을 명시하는 방식이 기능 수용기준 정의와 연결된다.); g-director-10(출시 직전 준비도 점검, do-not-touch, 리스크/롤백 정리가 마일스톤 준비도 점검과 겹친다.)'
    value: Android/iOS·IL2CPP·플레이어 설정·빌드 자동화
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실전성이 높은 우수한 Unity 모바일 빌드 스킬이지만, 최신 정책 의존값과 몇몇 명령·코드 단정을 보정하면 promote 수준이다.  리스크: Google Play target SDK, Android Gradle/NDK, App Store 요구사항은 매년 바뀌므로 예시 값(targetSdk 34, Xcode 15.x 등)을 고정 지침처럼 쓰면 낡을 수 있다.; `.aab`는 `adb install`로 직접 설치할 수 없고 `bundletool` 또는 Play 내부 테스트 경로가 필요하므로 검증 명령을 더 명확히 분리해야 한다.; Android에서 Mono가 항상 스토어 불가라는 식의 단정은 Unity 버전과 아키텍처 지원에 따라 부정확할 수 있어 IL2CPP 권장 사유로 완화하는 편이 안전하다.; 제공된 `MobileBuildScript.cs` 예시는 `using UnityEditor`, `UnityEditor.Build.Reporting`, `System.Linq`, `UnityEngine` 등이 빠져 있어 그대로 붙이면 컴파일 실패할 수 있다.; `bundleVersionCode` 자동 증가를 함정에서 권하지만 실제 절차/스크립트에는 구현돼 있지 않아 반복 업로드 자동화 품질이 살짝 떨어진다.; iOS 서명, 프로비저닝, Privacy Manifest/권한 설명 등은 최신 Apple 요구사항 확인 단계가 더 명시돼야 한다.'
    action: review
    path: 40_Skills/candidate/g-client-08.md
    ecosystem: 'delegate:unity-mcp'
  - id: g-director-01
    name: 게임 컨셉 원페이저
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-02(핵심 조작과 재미 가설이 행동-보상-진행 루프 정의의 전 단계와 맞닿아 있다.); g-director-03(한 줄 핏치, 감정 목표, 첫 재미 신호는 첫인상과 훅 설계와 일부 연결된다.); g-director-04(기능은 아니지만 차별점과 비목표를 단일 문서로 못박는 방식이 수용기준 정의와 유사하다.); g-director-09(1인 개발 현실선과 차별점 1개로 깎는 절차가 범위 절단 판단과 연결된다.); g-qa-01(재미 가설을 질문과 관찰 지표로 바꾸는 부분이 검증 계획의 최소 형태와 겹친다.); g-qa-02(친구 2~3명에게 프로토타입을 주고 질문·관찰로 피드백을 받는 방식이 실사용 피드백 수집과 맞닿아 있다.); g-ux-04(감정 목표를 특정 조작 순간에 묶는 부분은 타격감·연출·사운드 큐 설계의 상위 기획과 연결된다.); g-ux-05(세션 길이, 핵심 조작, 감정 순간은 튜토리얼과 첫 동선 설계의 입력으로 쓰일 수 있다.)'
    value: 핵심 재미·타깃·차별점을 한 장으로
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 게임 컨셉을 빠르게 고정하고 최소 재미 가설까지 확인하게 만드는 매우 완성도 높은 director 스킬이다.  리스크: 핵심 조작을 반드시 동사 1개로 압축하라는 규칙이 일부 하이브리드 장르에서는 중요한 복합 재미를 과도하게 단순화할 수 있다.; 25자 이내 한 줄 핏치 기준은 한국어 표현 방식이나 장르명 길이에 따라 다소 기계적으로 적용될 수 있다.; 친구 2~3명 테스트는 초기 신호로는 충분하지만 타깃 유저와 다른 사람일 경우 잘못된 긍정·부정 판단을 만들 수 있다.; A4 한 장 제한은 도구, 폰트, 언어에 따라 달라지므로 실제 사용 시 분량 기준이 약간 흔들릴 수 있다.'
    action: review
    path: 40_Skills/candidate/g-director-01.md
    ecosystem: 'partial:sprint-game'
  - id: g-director-03
    name: FTUE·첫 5분 설계
    category: game
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-02(코어 루프와 행동-보상-진행 구조를 첫 세션 안에서 증명한다는 점에서 맞닿아 있다.); g-director-05(첫 세션 종료 지점의 재방문 이유와 장기 동기의 초입 설계가 연결된다.); g-director-06(첫 보상, 첫 성장, 초반 난이도와 보상 체감 설계가 일부 겹친다.); g-director-07(첫 행동 시간, 이탈 지점, 첫 성공 여부 같은 플레이 데이터 기반 개선 관점이 겹친다.); g-director-08(첫 스테이지, 첫 보스 조우, 첫 이벤트 흐름 등 초기 레벨/스테이지 설계와 연결된다.); g-director-09(첫 5분에 무엇을 보여주고 무엇을 나중으로 미룰지 자르는 판단이 MVP/V1 범위 결정과 닿아 있다.); g-qa-01(관찰 지표와 체크리스트를 통해 무엇을 검증할지 정의한다.); g-qa-02(실사용자 첫 세션 관찰과 피드백 수집에 직접 연결된다.); g-ux-01(첫 동선과 화면 흐름을 정의하는 부분이 UX 플로우 설계와 겹친다.); g-ux-02(첫 10초 화면에서 무엇이 보이고 조작 가능한지 정하는 부분이 화면 상태 설계와 맞닿아 있다.); g-ux-04(첫 조작 피드백, 보상 연출, 사운드와 이펙트 설계가 일부 겹친다.); g-ux-05(튜토리얼과 첫 동선 설계라는 주제가 직접적으로 겹친다.)'
    value: 첫인상(훅·첫 승리·첫 선택)을 짤 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · FTUE 설계 목적, 절차, 체크리스트, 산출물이 모두 실무적으로 잘 맞물린 고품질 스킬이다.  리스크: 장르별 예외가 더 명시되면 좋다. 예를 들어 퍼즐, 로그라이크, 내러티브 게임, 멀티플레이 게임은 첫 실패 허용과 첫 선택의 의미가 다를 수 있다.; 첫 5분 목표를 하나로 제한하는 원칙은 좋지만, 라이브 서비스형 게임에서 계정/저장/권한 요청이 필요한 경우의 예외 처리 기준이 부족하다.; 관찰 로그는 제시되어 있으나 표본 수, 성공 기준, 개선 판단 기준 같은 의사결정 문턱값은 없다.; 12~18자 문구 제한은 한국어 기준으로 실용적이지만 영어/다국어 로컬라이징 상황에서는 별도 기준이 필요하다.'
    action: use
    path: 40_Skills/candidate/g-director-03.md
    ecosystem: 'delegate:sprint-game'
  - id: g-director-04
    name: 기능 PRD
    category: game
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-09(Prototype/MVP/V1/Later로 범위를 자르는 결정과 기능 PRD의 범위 절단·비목표 정의가 겹친다.); g-director-10(구현으로 넘기기 전 준비도 점검과 실행 패킷·게이트 작성이 겹친다.); g-qa-01(무엇을 어떻게 검증할지 정하는 절차와 PRD의 통과/실패 기준, 증거 수집 항목이 겹친다.); g-director-01(핵심 재미, 타깃, 차별점을 정리하는 맥락이 기능 PRD의 목표·사용자·가치 판단에 연결된다.); g-director-02(가장 작은 행동-보상-진행 루프를 기능 단위로 정의하고 검증하는 부분과 겹친다.); g-ux-01(기능 PRD가 화면·흐름·사용자 상황을 결정해야 할 때 UX 흐름 정의와 맞닿는다.)'
    value: 기능 하나를 수용기준·비목표로 못박을 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 기능 PRD 절차의 뼈대는 좋지만 실제 게임 기능 예시와 게임 특화 수용 기준을 보강하면 promote 수준이 된다.  리스크: 템플릿이 기능 PRD라고 하기에는 플레이어 시나리오, 핵심 상호작용, 수용 기준, 엣지 케이스 항목이 부족하다.; 예시가 실제 기능 사례가 아니라 메타 설명에 가까워 사용자가 어느 정도 구체성으로 작성해야 하는지 감을 잡기 어렵다.; 평가 기준은 제시되어 있으나 점수화 방식이나 선택 근거 기록 형식이 없어 대안 비교가 주관적으로 흐를 수 있다.; 게임 특화 요소인 재미 가설, 보상 피드백, 난이도 영향, 지표 이벤트 설계가 본문에는 언급되지만 산출물 템플릿에는 약하게 반영되어 있다.'
    action: use
    path: 40_Skills/candidate/g-director-04.md
    ecosystem: 'delegate:product-spec'
  - id: g-director-05
    name: 진행·메타 설계
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-02(코어 루프의 행동-보상-진행과 메타 진행이 연결되므로 입력 전제와 보상 구조에서 맞닿는다.); g-director-03(D1 첫 메타 보상과 다음날 갈고리는 첫인상·첫 승리 설계와 일부 겹친다.); g-director-06(진행 곡선, 비용 함수, 게이트 위치가 경제·보상 곡선의 수치 밸런스와 인접하다.); g-director-07(리텐션 가설과 D1/D7/D30 구조는 출시 후 지표 기반 튜닝의 초기 가설로 이어진다.); g-director-08(스테이지·층·보스·이벤트 게이트가 개별 콘텐츠 배치와 연결된다.); g-director-09(Prototype/MVP/V1 범위 구분이 구현 범위 컷과 직접 맞닿는다.); g-director-10(진행 구조 산출물이 구현 넘기기 전 준비도 점검의 입력물이 된다.); g-client-04(ProgressionSettings ScriptableObject로 곡선·해금 설정을 구조화하는 부분이 겹친다.); g-client-06(진행 상태 저장·복원과 세이브 스키마 전제가 진행 시스템 구현에 필요하다.); g-ux-05(D1~D7 세션 맵과 첫 해금 노출은 튜토리얼·첫 동선 설계와 만난다.)'
    value: 장기 동기(레벨·수집·랭킹)를 설계할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 장기 진행 구조를 1인 개발자가 바로 산출물로 만들 수 있게 하는 고품질 메타 설계 스킬이다.  리스크: D1~D7 세션 맵 체크리스트는 빈 일차가 없어야 한다고 하지만 예시는 D2~3, D4~7로 묶어 실제 일별 검증이 약해질 수 있다.; 진행 곡선의 ±20% 검산은 유용하지만 실제 플레이타임은 실패, 반복, 실력 차, 세션 이탈을 포함하므로 단독 기준으로 쓰면 과신할 수 있다.; 장르별 게이트 표가 방치형·로그라이크·퍼즐·RPG 중심이라 하이브리드 장르나 샌드박스, 소셜, 시뮬레이션 게임에는 추가 해석이 필요하다.; Unity 노트의 MonoSingleton 권장은 프로젝트 아키텍처에 따라 부적절할 수 있어 기존 구조 우선 원칙을 더 명시하면 좋다.; 리텐션 목표가 없으면 장르 벤치마크로 임시 설정한다고 하지만 벤치마크 출처나 보정 기준이 없어 숫자 권위가 과장될 수 있다.'
    action: review
    path: 40_Skills/candidate/g-director-05.md
    ecosystem: 'partial:sprint-game'
  - id: g-director-06
    name: 경제·밸런스 설계
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-02(행동-보상 루프와 보상 수급이 맞물리므로 경제 수치가 루프의 체감 보상에 영향을 준다.); g-director-05(레벨·수집·랭킹 같은 장기 동기 구조 위에서 재화 sink와 성장 곡선을 수치화한다.); g-director-07(경제 곡선과 보상 수치를 다루지만, 이 초안은 출시 전 모델링이고 07은 출시 후 실데이터 기반 재튜닝이다.); g-director-08(스테이지 보상량과 이벤트 보상 배치가 source 설계와 연결된다.); g-client-04(확정된 밸런스 수치를 ScriptableObject 등 데이터 구조로 넘기는 구현 경계와 접점이 있다.); g-qa-01(TTU, 순유입, 콘텐츠 소진일 같은 수치 기준으로 무엇을 검증할지 정의한다.); g-director-09(MVP/소프트런칭/라이브 단계별로 이번 패스에서 할 일과 하지 않을 일을 자른다.)'
    value: 획득·소비·난이도/보상 곡선을 잡을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 출시 전 게임 경제를 숫자로 설계하고 검증하게 만드는 고품질 밸런스 설계 스킬이므로 promote가 적절하다.  리스크: 순유입 +5~15%, TTU +20~50% 같은 권장값은 장르·세션 구조·플랫폼에 따라 크게 달라질 수 있어 절대 기준처럼 쓰면 오판할 수 있다.; 부분유료 게임에서 뽑기·하드재화 sink를 언급하지만 확률 공개, 미성년자 보호, 지역별 규제 같은 운영·법무 전제가 빠져 있다.; 전투 난이도, 스킬 숙련, 실패 보상처럼 경제 외 변수가 TTU와 체감 벽에 영향을 주는 경우 산식만으로 원인을 단정할 위험이 있다.; 1인 개발 기준으로 30일 시뮬레이션을 필수화하는 것은 적절하지만, 매우 짧은 잼/프리미엄 게임에는 과한 절차가 될 수 있다.'
    action: review
    path: 40_Skills/candidate/g-director-06.md
    ecosystem: 'partial:sprint-game'
  - id: g-director-07
    name: 라이브 밸런스 튜닝
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-06(획득·소비·난이도/보상 곡선 자체를 다루지만, 후보 스킬은 출시 후 실데이터 기반 재조정에 초점이 있다.); g-qa-01(KPI, 표본, 통과/실패 기준을 숫자로 정의하는 검증 설계 영역이 겹친다.); g-qa-02(유저 항의·피드백 신호를 운영 판단 입력으로 삼는 부분이 겹친다.); g-qa-03(단계 배포, 가드레일 지표, 롤백 조건 등 변경 안전성 검증 절차가 겹친다.); g-client-04(밸런스 값을 ScriptableObject나 원격 설정 키로 구조화하고 위치를 추적하는 부분이 겹친다.); g-director-05(장기 동기, 보상, 랭킹, 경제 격차에 대한 운영 판단이 일부 겹친다.)'
    value: 출시 후 지표·플레이 데이터를 보고 보상·난이도·경제 곡선을 다시 조정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 라이브 밸런스 튜닝을 실데이터, 제한된 변경, 단계 배포, 공정성, 롤백까지 연결한 매우 실전적인 디렉터 스킬이다.  리스크: 표본 100명 기준은 간단한 가드로는 좋지만, 효과 크기·분산·세그먼트별 편향에 따라 충분하지 않을 수 있다.; D7 같은 지표는 관찰에 최소 7일이 필요하므로 24h 단계 배포 판단과 최종 KPI 검증을 혼동할 위험이 있다.; 여러 값을 3개 이하로 제한해도 A/B 설계나 대조군이 없으면 인과 귀속이 약할 수 있다.; 가챠·확률형 상품 정책은 국가·스토어·시점별로 달라질 수 있어 실제 적용 전 최신 정책 확인이 필요하다.; Remote Config로 가격·확률·보상 값을 바꿀 때 클라이언트 신뢰 모델이나 서버 권위 검증이 없으면 악용 가능성이 생길 수 있다.'
    action: review
    path: 40_Skills/candidate/g-director-07.md
    ecosystem: 'delegate:sprint-game'
  - id: g-director-08
    name: 콘텐츠 설계
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-05(이벤트·반복 콘텐츠가 장기 동기와 리텐션 루프에 공급될 콘텐츠 단위를 설계하므로 토론 접점이 있다.); g-director-06(난이도·보상 배치와 반복 보상 위치를 다루며, 보상 수치 곡선과 경계가 맞닿아 있다.); g-director-09(콘텐츠를 실제로 만들기 전 범위와 우선순위를 자르는 결정과 연결된다.); g-qa-01(완료 기준과 관찰 가능한 통과 조건을 넘겨주므로 테스트 설계와 접점이 있다.); g-client-04(콘텐츠 데이터를 ScriptableObject로 구조화하는 산출물 경계가 겹친다.); g-client-01(씬, 프리팹, 매니저, 폴더 같은 구현 뼈대 산출물과 연결된다.); g-ux-05(튜토리얼 흐름이나 첫 동선이 퀘스트·체인 설계와 맞닿아 있다.); g-ux-04(보스, 피크 구간, 내러티브 비트의 연출·사운드 큐 설계와 토론 접점이 있다.)'
    value: 레벨·스테이지·이벤트를 기획할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 구체적 표, 숫자 기준, 구현 산출물까지 닫혀 있어 1인 개발 콘텐츠 설계 스킬로 바로 승격 가능한 수준이다.  리스크: Unity, ScriptableObject, R3, MonoSingleton, additive scene loading을 전제로 한 예시가 강해 비Unity 프로젝트나 다른 아키텍처에서는 변환 규칙이 필요하다.; 피크 ≥ 도입×3, 신규 메커닉 1개 이하 같은 규칙은 좋은 기본값이지만 장르에 따라 예외가 필요할 수 있다.; 내러티브 설계 분기는 레벨·이벤트 분기보다 필수 필드가 상대적으로 얕아, 대사량·분기·로컬라이징 비용 같은 항목이 빠질 수 있다.; 반복 콘텐츠의 0소모를 위험으로 보는 기준은 프리플레이·광고 기반·스킬 기반 게임에서는 보상 구조에 따라 다르게 판단해야 한다.'
    action: review
    path: 40_Skills/candidate/g-director-08.md
    ecosystem: 'delegate:sprint-game'
  - id: g-director-09
    name: MVP 우선순위·범위
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-02(코어 루프 한 문장을 전제로 하며, 루프가 비어 있으면 선행해야 하는 영역이 맞닿아 있다.); g-client-02(MVP에 남긴 항목을 실제 플레이 가능한 최소 루프로 구현하는 단계와 이어진다.); g-director-04(IN으로 확정된 기능을 수용 기준과 비목표로 더 잘게 못박는 작업과 연결된다.); g-qa-01(MVP가 증명할 가설과 통과 지표를 정하는 검증 게이트와 의미적으로 이어진다.); g-director-10(MVP 범위 확정 후 마일스톤과 구현 전달 준비도를 점검하는 단계와 후속 관계가 있다.); g-director-08(퍼즐 레벨, 스테이지, 이벤트 등 콘텐츠량을 자르는 판단에서 일부 접점이 있다.)'
    value: Prototype/MVP/V1/Later로 자를 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 게임 MVP 범위를 코어 루프 검증 중심으로 자르는 데 매우 실용적이고 검증 가능한 고품질 스킬이다.  리스크: 지원 장르가 6개로 제한되어 하이브리드, 내러티브, 공포, 멀티플레이, 샌드박스 게임에는 별도 해석이 필요하다.; 숫자 컷이 강하게 제시되어 특정 장르나 시장 검증 방식에서는 과소 범위가 될 수 있다.; ''예외 없음'' 표현이 강제 항목, 접근성, 플랫폼 필수 요건, 법적/스토어 필수 요건과 충돌할 수 있다.; 코어 루프가 재미있는지보다 첫 진입 이해가 중요한 게임에서는 튜토리얼·UX 최소치가 과도하게 잘릴 위험이 있다.; 검증 지표 한 줄만 남기고 g-qa-01로 넘기므로, 실제 테스트 설계 없이 범위 컷만 완료했다고 오해할 수 있다.'
    action: review
    path: 40_Skills/candidate/g-director-09.md
    ecosystem: 'delegate:sprint-game'
  - id: g-qa-01
    name: 테스트 계획
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-qa-03(회귀 핫스팟과 변경분 스모크를 테스트 계획에 포함하므로 회귀 검증 영역과 맞닿아 있다.); g-qa-05(실기기 필요 여부와 fps·해상도·플랫폼 차 검증 판단을 포함하므로 멀티 디바이스 검증과 연결된다.); g-qa-04(테스트 후 발견된 결함을 릴리스 리스크나 우선 처리 대상으로 넘기는 흐름에서 버그 분류와 이어진다.); g-qa-02(튜토리얼 이탈, 반복 피로도처럼 실제 플레이 관찰이 필요한 항목은 피드백 구조화와 접점이 있다.); g-director-04(기능별 수용기준과 통과 게이트를 숫자·증거로 명확히 한다는 점에서 기능 정의 관점과 겹친다.); g-director-10(마일스톤이나 구현 인계 전 출시 가능 여부를 게이트로 점검하는 흐름과 맞닿아 있다.); g-client-06(세이브 무결성, 저장/복원, 버전 마이그레이션 테스트 항목이 저장 시스템 구현 영역과 연결된다.); g-client-07(fps, 1% low, 메모리 증가, 누수 등 성능 검증 항목이 최적화 영역과 겹친다.); g-client-08(Android API, 실기기, 빌드 환경, 플랫폼 차 검증 판단이 모바일 빌드 설정 영역과 연결된다.); g-ux-05(첫 5분 튜토리얼 이탈 검증은 튜토리얼·첫 동선 설계와 관찰 대상이 겹친다.)'
    value: 무엇을 어떻게 검증할지 정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 게임 개발 QA 계획 스킬로 매우 구체적이고 실행 가능한 고품질 초안이다.  리스크: 각 항목에 정확히 하나의 방식만 배정하라는 규칙은 일부 고위험 항목에서 자동 테스트와 실기기 확인이 모두 필요한 경우를 과도하게 제한할 수 있다.; 33ms 입력 지연, 1% low 45fps, 메모리 20MB 같은 기준은 장르·타깃 기기·프레임 목표에 따라 조정 전제가 필요하다.; 자동화 가능한 항목은 절대 수동으로 돌리지 않는다는 표현은 초기 자동화 비용이 매우 큰 소규모 프로토타입에서는 예외 판단이 필요하다.; 시간 0일 때도 보존한다는 표현은 실제 실행 시간이 없다는 뜻이 아니라 컷 라인에서 절대 제거하지 않는다는 의미로 해석해야 한다.; 결제·세이브·크래시를 모두 강제 0순위로 두면 가용 시간이 극히 적은 빌드에서 나머지 변경분 검증이 거의 사라질 수 있어 릴리스 판단 기준이 함께 필요하다.'
    action: review
    path: 40_Skills/candidate/g-qa-01.md
    ecosystem: 'delegate:sprint-game'
  - id: g-qa-02
    name: 플레이테스트 설계
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-qa-01(빌드를 검증한다는 큰 영역은 겹치지만, 이 스킬은 기능 통과 여부가 아니라 플레이어 행동·이해·감정 관찰에 초점을 둔다.); g-qa-04(발견 사항을 심각도와 우선순위로 분류하는 부분이 겹친다. 다만 여기서는 버그가 아니라 플레이 경험 문제의 빈도·치명도 트리아지다.); g-ux-05(튜토리얼·첫 동선에서 플레이어가 막히는 지점을 찾고 수정 패킷으로 넘기는 부분이 맞닿아 있다.); g-director-03(첫인상, 첫 승리, 첫 선택이 실제 플레이어에게 의도대로 전달되는지 검증하는 데 쓰일 수 있다.); g-director-04(기능·설계 가설을 수용 기준처럼 명시하고 검증/기각하는 구조가 일부 겹친다.); g-director-10(마일스톤 빌드가 다음 단계로 넘어갈 준비가 되었는지 사람 대상 검증 자료로 판단하는 데 연결된다.)'
    value: 실사용 피드백을 구조적으로 받을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 실제 플레이어 관찰을 설계·운영·판정까지 연결하기에 충분히 구체적인 고품질 플레이테스트 스킬이다.  리스크: 5명 테스트 원칙이 모든 문제에 적용되는 것처럼 오해될 수 있다. 밸런스, 경제, 유지율, 경쟁 메타처럼 분산이 큰 문제는 더 많은 표본이나 telemetry가 필요하다.; 녹화·음성·미성년자 동의는 언급되어 있으나 파일 보관 기간, 접근 권한, 삭제 요청 처리 같은 개인정보 운영 전제가 빠져 있다.; 참가자 절반을 비친숙자로 두는 기본값은 장르에 따라 왜곡될 수 있다. 하드코어 장르나 전문 조작 게임은 실제 타깃 숙련도를 더 엄격히 맞춰야 한다.; think-aloud는 유용하지만 몰입·반응 시간에 영향을 줄 수 있다. 액션성·공포·리듬 게임에서는 관찰 방식 선택이 결과를 흔들 수 있다.; P0 또는 3명 이상은 수정이라는 규칙이 강력하나, 의도된 난이도·장르 문법·튜토리얼 철학과 충돌할 때 예외 판단 기준이 조금 더 필요하다.'
    action: review
    path: 40_Skills/candidate/g-qa-02.md
    ecosystem: 'delegate:sprint-game'
  - id: g-qa-03
    name: 회귀 테스트
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-qa-01(검증 대상과 통과 기준을 정하는 일반 QA 설계와 맞닿지만, 이 스킬은 신규 기능 검증이 아니라 기존 동작 회귀 방지에 초점을 둔다.); g-qa-04(실패한 회귀를 위험도에 따라 릴리즈 차단 또는 known-issue로 분류하는 부분이 버그 심각도·우선순위 분류와 겹친다.); g-qa-05(실기기·해상도·플랫폼별 회귀 확인이 일부 포함되어 다기기 검증과 영역이 닿는다.); g-client-08(엔진 버전 업, IL2CPP, 플레이어 설정, 빌드 타입 변경 후 검증이라는 맥락이 빌드 자동화·플레이어 설정 검증과 겹친다.); g-client-06(세이브 파일 호환성, 마이그레이션, 저장/복원 회귀 케이스가 저장 시스템 구현·운영과 직접 맞닿는다.); g-client-07(soak 테스트에서 메모리·FPS·핸들 누수 추세를 보는 부분이 성능 최적화 검증과 일부 겹친다.)'
    value: 변경이 기존을 깨지 않았는지 볼 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 게임 회귀 테스트의 우선순위화와 기준선 관리, 실패 대응까지 실전적으로 잘 갖춘 고품질 스킬이다.  리스크: Unity 중심 용어(EditMode, PlayMode, Resources, IL2CPP)가 강해 Godot, Unreal, 웹 게임에는 변환 지침이 추가로 필요하다.; 픽셀 diff 99% 같은 기준은 렌더링 백엔드, 해상도, 안티앨리어싱, 폰트 차이에 따라 쉽게 플레이키해질 수 있어 프로젝트별 허용오차 보정이 필요하다.; 골든값 갱신 승인 절차가 약하면 의도치 않은 변경을 ''정답''으로 받아들이는 위험이 남는다.; 1인 개발자에게 풀 회귀 30~60분과 실기기 검증은 현실적이지만, 자동화 기반이 없는 초기 프로젝트에는 초기 구축 비용이 부담될 수 있다.; 결제 mock 통과만으로 스토어 샌드박스·영수증 서버 검증까지 보장되지는 않는다는 전제가 명시되면 더 안전하다.'
    action: review
    path: 40_Skills/candidate/g-qa-03.md
    ecosystem: 'delegate:sprint-game'
  - id: g-qa-04
    name: 버그 트리아지
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-qa-01(검증 기준과 증거 요구가 연결된다. 이 스킬은 트리아지 입력으로 재현 가능성과 기대/실제 결과를 요구한다.); g-qa-02(테스터·스토어 리뷰·크래시 로그 등 실사용 피드백을 버그 카드로 정규화하는 부분이 맞닿는다.); g-qa-03(수정 후 재현 0%, 회귀 케이스 통과 등 핫픽스 승인 조건에서 회귀 검증 결과를 입력으로 사용한다.); g-qa-05(Reach 판정과 특정 기기/플랫폼 조건 분류가 환경별 검증 결과와 연결된다.); g-director-09(이번 패치와 백로그를 나누고 가용 작업일 기준으로 컷 라인을 긋는 점이 범위 자르기와 겹친다.); g-client-08(Android/iOS 빌드, Logcat, 플레이어 설정, 핫픽스 빌드 운영과 일부 접점이 있다.); g-client-06(세이브 손상, 진행 저장/복원, 재화 손실 같은 결함 유형이 우선순위 판단에서 중요하게 다뤄진다.)'
    value: 버그를 심각도·우선순위로 분류할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 겹침과 무관하게, 1인 게임 개발자의 버그 우선순위·핫픽스 판단을 실무적으로 표준화한 고품질 QA 트리아지 스킬이다.  리스크: Priority Score의 곱셈 모델은 간단하고 일관적이지만, 보안·결제·법적 이슈처럼 빈도와 무관하게 즉시 대응해야 하는 예외 규칙이 더 필요할 수 있다.; S1이라도 라이브가 아니고 Score가 낮으면 P0가 아닐 수 있는데, 출시 직전 release blocker 판정 기준은 별도 예외로 조금 더 명시하면 좋다.; 핫픽스 승인 조건의 ''수정 범위 1~2 파일''은 현실적인 가드레일이지만, 데이터/서버 설정/에셋 번들 수정처럼 파일 수로 위험도를 판단하기 어려운 경우가 있다.; 재현 불가 3회 기준은 유용하지만, 희귀 크래시처럼 로그 증거가 강한 경우 닫지 않고 관찰/추적 상태로 두는 분기가 있으면 더 안전하다.'
    action: review
    path: 40_Skills/candidate/g-qa-04.md
    ecosystem: 'delegate:sprint-game'
  - id: g-qa-05
    name: 디바이스 호환
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-qa-01(QA 범위, 통과 기준, 증거 기반 판정이라는 일반 QA 설계와 겹치지만 이 초안은 모바일 기기 매트릭스에 특화되어 있다.); g-qa-03(빌드 변경 후 여러 기기에서 기존 동작이 깨졌는지 확인하는 회귀 검증 흐름과 겹친다.); g-client-07(프레임레이트, 메모리, 발열, 배터리 같은 성능 지표를 다루며 탈락 원인 분석을 성능 스킬로 넘긴다.); g-client-08(Release, IL2CPP, ARM64, Android/iOS 빌드 조건과 스토어 제출 전 검증 맥락이 빌드/배포 설정과 맞닿아 있다.); g-ux-03(노치, 세이프에어리어, 터치 타깃, HUD 잘림 여부를 실기기에서 검증한다.); g-client-03(uGUI/UI Toolkit 화면이 다양한 해상도와 화면비에서 깨지는지 확인하는 영역이 일부 겹친다.)'
    value: 여러 기기·해상도에서 검증할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 모바일 Unity 출시 전 실기기 호환성 QA를 1인 개발자 규모에 맞게 숫자와 증거 중심으로 잘 고정한 고품질 스킬이다.  리스크: GameBench, Firebase Test Lab, TestFlight 외부 테스터 등은 계정·비용·지원 범위·지역 정책에 따라 즉시 사용이 어려울 수 있다.; 발열 기준에 ''손에 뜨겁지 않음'' 같은 주관 기준이 섞여 있어, 가능하면 표면온도계나 OS 경고·스로틀링 로그 같은 객관 증거를 병행해야 한다.; 피크 메모리 ''기기 RAM의 50% 이하''는 장르와 OS 메모리 정책에 따라 과하거나 느슨할 수 있어 프로젝트별 보정이 필요하다.; Unity Profiler와 Xcode/Android Studio 도구를 Release 빌드에 붙이는 방식은 설정에 따라 제한될 수 있으므로 측정 가능한 구성과 원인분석용 Development 빌드를 명확히 분리해야 한다.; MonoSingleton `.instance`, switch식 분기, SO 노출 방식은 특정 프로젝트 코딩 규약을 전제하므로 QA 스킬 본문에서는 예시 또는 내부 규약 의존 항목으로 표시하는 편이 안전하다.; iOS 배터리 설정 기반 측정은 해상도가 낮고 반복 측정 편차가 커서 짧은 세션의 정량 판정에는 보조 지표로만 쓰는 것이 좋다.'
    action: review
    path: 40_Skills/candidate/g-qa-05.md
    ecosystem: 'delegate:sprint-app'
  - id: g-ux-01
    name: 화면 인벤토리·플로우
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-ux-02(화면 목록과 플로우를 정한 뒤 각 화면 내부 레이아웃·상태 설계로 이어진다.); g-ux-05(튜토리얼/온보딩 화면의 존재와 진입 경로를 다루며, 내부 단계 설계와 연결된다.); g-client-03(인벤토리 산출물이 uGUI/UI Toolkit 구현 대상 화면 목록과 prefab/View 후보로 직접 이어진다.); g-client-06(강제종료 후 복귀, 세이브 정책, 로딩 실패 경로가 저장/복원 설계와 맞닿아 있다.); g-qa-01(화면별 검증 조건과 통과 기준을 정의해 테스트 계획의 입력이 된다.); g-qa-05(해상도, 노치, 입력 장치, 접근성 등 기기·화면 조건 검증을 포함한다.); g-director-09(Prototype/MVP/V1/Later 범위 표기가 화면 구현 우선순위 자르기와 연결된다.); g-client-01(Scene, Popup, HUD, 구현 파일 후보를 잡아 씬·폴더·플레이스홀더 구조화와 이어진다.)'
    value: 필요한 화면과 이동 흐름을 정의할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 화면 누락과 막다른 플로우를 예방하는 절차·체크리스트·예시가 매우 구체적인 고품질 UX 플로우 스킬이다.  리스크: Unity/uGUI/UI Toolkit 기준이 강해 다른 엔진이나 웹 게임에 적용할 때 용어와 산출물 경로를 치환해야 한다.; 13종 표준 화면 유형은 좋은 출발점이지만 멀티플레이 매칭, 캐릭터 선택, 레벨 에디터, 일일 보상, 시즌패스 등 장르별 특수 화면이 빠질 수 있다.; ''모든 화면을 한 번에 고정''이라는 표현은 초기 탐색 단계에서 과도한 고정으로 해석될 수 있어, 변경 관리 전제를 명시하면 더 안전하다.; 검증 매트릭스의 스크린샷·영상 증거 요구가 Prototype 단계에는 다소 무거울 수 있어 범위별 최소 증거 수준을 구분하면 좋다.; 예시의 do-not-touch에서 상점·인벤토리를 V1로 미루면서 인벤토리 표에는 없다고 쓰는 부분은 ''전체 인벤토리에는 Later/V1로 기록'' 원칙과 약간 충돌한다.'
    action: review
    path: 40_Skills/candidate/g-ux-01.md
    ecosystem: 'delegate:sprint-game'
  - id: g-ux-02
    name: 와이어프레임·목업
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-ux-01(화면 목록·상태 정의와 연결되며, 이 스킬은 그 결과를 받아 개별 화면 목업으로 구체화한다.); g-ux-03(색, 폰트, 버튼, 패널, HUD 규칙을 F1 목업에 적용하므로 컴포넌트 스타일 표준과 맞닿아 있다.); g-client-03(uGUI/UI Toolkit 구현 전달을 위해 앵커, 피벗, 여백, Inspector 노출값을 명세한다.); g-qa-05(해상도, 화면비, 안전 영역, 기기별 UI 깨짐 점검과 의미적으로 연결된다.); g-ux-04(전환 타이밍, 피드백 루프, 데미지 숫자, 사운드 큐 등 게임 감각을 좌우하는 연출 명세가 일부 겹친다.); g-client-05(터치, 게임패드, D패드 포커스 이동 등 입력 장치별 UX 명세가 신 Input System 구현과 이어진다.); klv:image-plan(목업 PNG나 시각 샘플 산출물을 만들고 승인 추적하는 흐름에서 이미지 생성·에셋 계획과 접점이 있다.)'
    value: 화면별 레이아웃·상태를 그릴 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 개별 게임 화면을 구현 가능한 목업 명세로 바꾸는 절차가 구체적이고 검증 가능해 바로 승격할 만하다.  리스크: F1에서 색·폰트·아이콘을 채우라고 하지만 g-ux-03의 디자인 규칙이 아직 없을 경우 임시 스타일과 확정 스타일이 섞일 수 있다.; F2 상태 변형을 ''반드시'' 그린다는 표현이 화면 규모가 큰 프로젝트에서는 과도한 산출물로 번질 수 있어 핵심 상태 우선순위 기준이 추가되면 더 안전하다.; Unity URP, R3, uGUI/UI Toolkit 언급이 특정 기술 스택을 전제로 하므로 다른 엔진이나 아키텍처에서는 용어 치환 가이드가 필요하다.; 접근성은 대비와 최장 텍스트 중심으로 다루지만 컬러블라인드, 폰트 크기, 터치 타깃 최소 크기 같은 기준은 별도 스킬 의존성이 크다.; PNG와 spec.md가 불일치할 때 어느 쪽을 기준으로 삼을지에 대한 버전 관리 규칙이 부족하다.'
    action: review
    path: 40_Skills/candidate/g-ux-02.md
    ecosystem: 'delegate:gatecraft'
  - id: g-ux-03
    name: UI 컴포넌트 시스템
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-03(uGUI/UI Toolkit/TMP 구현 산출물과 프리팹 전달 형식이 맞닿아 있다.); g-ux-02(화면 와이어프레임에서 반복 UI 조각을 추출하므로 화면 레이아웃 설계와 입력 산출물이 연결된다.); g-ux-06(색·폰트·대비·터치 타깃 같은 접근성/가독성 토큰 기준을 공유한다.); g-qa-05(해상도, 세이프존, 노치, 컨트롤러 포커스 등 다기기 검증 게이트가 겹친다.); g-client-04(UIThemeSettings를 ScriptableObject로 구조화하는 부분이 설정 데이터 구조화와 맞닿아 있다.); g-client-05(컨트롤러 포커스 이동과 입력 방식 대응 기준이 조작/입력 구현과 연결된다.)'
    value: 버튼·패널·HUD 규칙을 표준화할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 게임 UI 컴포넌트 시스템을 설계 산출물과 Unity 전달 패킷까지 안정적으로 표준화하는 고품질 스킬이다.  리스크: R3 Observable과 MVVM을 전제로 삼아, 해당 아키텍처를 쓰지 않는 프로젝트에서는 절차 일부를 바꿔야 한다.; `unity_validate_prefabOverrides` 같은 검증 도구가 실제 프로젝트에 없으면 별도 구현 또는 수동 검사가 필요하다.; 88px 터치 타깃 기준은 기준 해상도와 Canvas Scaler 설정에 따라 물리 크기 해석이 달라질 수 있다.; UI Toolkit과 uGUI를 모두 다루지만 예시 코드는 uGUI 중심이라 UI Toolkit 프로젝트에서는 추가 구체화가 필요하다.; Atom은 무조건 프리팹화라는 규칙은 아주 작은 텍스트/아이콘 요소가 많은 프로젝트에서 오히려 프리팹 수를 과도하게 늘릴 수 있다.'
    action: review
    path: 40_Skills/candidate/g-ux-03.md
    ecosystem: 'partial:sprint-game'
  - id: g-ux-04
    name: 피드백·게임필 설계
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-01(GameFeelManager, 폴더 구조, 매니저 뼈대 구성과 일부 겹친다.); g-client-02(플레이 가능한 액션 루프의 타격·점프·획득 반응 구현과 맞닿아 있다.); g-client-04(GameFeelSettings SO로 액션별 프리셋을 구조화하는 부분이 겹친다.); g-client-05(입력 반응 지연과 조작 즉시성 측정이 Input System 설계와 연결된다.); g-client-07(모바일 파티클, 드로우콜, GC, fps 유지 기준이 성능 최적화와 겹친다.); g-qa-01(입력 지연, fps, timeScale 복원 등 통과/실패 게이트를 정의한다.); g-qa-02(손맛·멀미·A/B 확인처럼 플레이어 체감 피드백을 구조화한다.); g-qa-05(모바일 실기기, 패드 햅틱, 플랫폼별 검증 항목이 기기 검증과 겹친다.); g-ux-02(카메라 셰이크, 플래시, 사운드 타이밍 등 순간 UX 연출과 일부 인접한다.); g-director-02(행동의 보상감과 즉각 피드백이 작은 행동-보상 루프 체감에 영향을 준다.); klv:image-plan(VFX, 임팩트 플래시, 파편 에셋을 샘플로 만들고 승인받는 흐름과 접점이 있다.)'
    value: 타격감·연출·사운드 큐를 설계할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 수치화·체크리스트·예시가 강한 고품질 스킬이지만, Unity 구현 골격의 timeScale·취소·셰이크 타이밍 안전성을 보완해야 한다.  리스크: 예시 코드에서 본문은 셰이크를 히트스톱 종료 후 시작하라고 하지만 PlayHit은 ShakeCamera를 즉시 호출해 규칙과 충돌한다.; Time.timeScale을 0으로 바꾸는 코드는 try/finally 없이 예외·취소·오브젝트 파괴가 발생하면 1로 복원되지 않을 위험이 있다.; 이전 히트스톱 CTS를 취소할 때 이전 작업의 복원 로직과 새 작업의 복원 로직이 경합할 수 있어 전역 timeScale 관리가 불안정할 수 있다.; R3 Observable.Timer가 Unity 환경에서 unscaled 시간 기준인지 명확히 지정하지 않으면 timeScale=0에서 타이머가 진행되지 않을 수 있다.; GameFeelManager를 전역 MonoSingleton으로 고정하면 컷신, 일시정지, 슬로모션, 멀티 카메라 등 다른 시스템과 timeScale 소유권 충돌이 날 수 있다.; 햅틱 API는 플랫폼별 권한·지원 범위·Input System 패키지 설정 차이가 있어 더 구체적인 fallback 규칙이 필요하다.; 셰이크 멀미 점수는 자가평가라 검증성이 낮으므로 최소 테스트 인원이나 반복 조건을 보강하면 더 좋다.'
    action: review
    path: 40_Skills/candidate/g-ux-04.md
    ecosystem: 'partial:sprint-game'
  - id: g-ux-05
    name: 온보딩 UX
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-03(첫 플레이 경험, 첫 승리, 잔존 동기와 온보딩 초반 설계가 같은 구간을 다루지만 감정 훅과 학습 게이트로 관점이 다르다.); g-ux-01(온보딩 단계가 화면 흐름 위에서 작동하므로 화면 순서와 진입 지점 정의가 맞물린다.); g-ux-02(툴팁, 팝업, dim, 강조 상태 같은 안내 표현을 참조하고 노출 조건을 정의한다.); g-qa-01(skill-gate와 퍼널 이벤트가 QA 검증 항목과 직접 연결된다.); g-qa-02(온보딩 이탈 지점과 실사용 피드백을 바탕으로 개선 액션을 정하는 부분이 겹친다.); g-qa-05(모바일/PC/콘솔, 재진입, 해상도·입력 방식 차이에 따른 검증 필요가 있다.); g-client-05(플랫폼별 입력 안내와 조작 학습 게이트가 Input System 구현과 맞물린다.); g-client-06(STEP 저장, 재개, PlayerPrefs 키, 도중 종료 복원이 진행 저장/복원 영역과 연결된다.); g-director-07(퍼널 지표를 보고 온보딩 단계와 보상 도달 시간을 조정하는 데이터 기반 개선이 겹친다.)'
    value: 튜토리얼·첫 동선을 설계할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 학습 단계, 행동 게이트, 트리거, 퍼널 검증까지 닫힌 루프로 설계된 고품질 온보딩 UX 스킬이다.  리스크: hard gate 3개 이하, STEP 완료율 80%, 첫 루프 도달 60% 같은 임계값은 장르·플랫폼·획득 채널에 따라 달라질 수 있으므로 절대 기준처럼 쓰면 오판할 수 있다.; ''동사 하나 = STEP 하나'' 원칙이 지나치게 엄격하면 조작과 보상이 자연스럽게 결합된 장르에서 튜토리얼이 잘게 끊겨 흐름을 해칠 수 있다.; 예시가 Unity, PlayerPrefs, MonoSingleton, R3에 치우쳐 있어 다른 엔진이나 서버 저장 기반 프로젝트에서는 저장·분석 구현부를 번역해야 한다.; 재설치/시즌2 숙련자 감지는 플랫폼 정책, 계정 로그인, 개인정보·식별자 제약에 따라 불가능하거나 부정확할 수 있다.; 분석 인프라가 없는 1인 개발 프로젝트에서 이벤트 설계는 좋지만 실제 계측·대시보드 확인 루틴이 없으면 문서 산출물로만 끝날 위험이 있다.; 스킵 제공이 필수처럼 제시되지만 일부 경쟁/멀티플레이 게임에서는 최소 조작 검증이나 공정성 확인 때문에 스킵 범위를 더 제한해야 할 수 있다.'
    action: review
    path: 40_Skills/candidate/g-ux-05.md
    ecosystem: 'delegate:sprint-game'
  - id: g-ux-06
    name: 접근성·가독성
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-03(uGUI·UI Toolkit·TextMeshPro로 실제 화면을 만들 때 폰트 크기, 아웃라인, RectTransform, 포커스 표현 수정과 맞닿는다.); g-client-05(터치·게임패드 입력, 리매핑, 포커스 가시성 등 조작 접근성 항목이 입력 구현과 겹친다.); g-qa-05(모바일·PC·콘솔·Switch 등 여러 해상도와 기기에서 실측 검증하는 절차가 다기기 QA와 겹친다.); g-ux-02(전투 HUD·옵션·튜토리얼 화면의 레이아웃 상태를 점검하고 수정안을 내는 부분이 화면 설계와 겹친다.); g-ux-03(버튼, 패널, HUD, 게이지, 포커스 하이라이트 같은 UI 컴포넌트 규칙을 수치화한다.); g-ux-04(피격 효과, 플래시, 카메라 셰이크, 사운드 자막처럼 연출 접근성 항목이 타격감·연출 설계와 닿는다.); g-ux-05(튜토리얼 텍스트, 대화 표시 속도, 자막 가독성은 첫 동선과 튜토리얼 UX에도 영향을 준다.); g-qa-01(접근성 항목을 무엇으로 검증할지 수치 기준과 증거 형식으로 정의한다.)'
    value: 대비·폰트·컬러블라인드를 점검할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 게임 접근성·가독성을 수치로 판정하고 수정·재측정까지 연결하는 매우 실전적인 고품질 스킬이다.  리스크: 모바일 폰트 28px, 콘솔 28~32px 같은 기준은 장르·시청 거리·UI 스케일 정책에 따라 과하거나 부족할 수 있어 프로젝트별 예외 규칙이 필요하다.; 동적 HUD의 0.5초 내 인지는 좋은 목표지만 측정 방법이 육안 확인에 머물 수 있어, 실제 플레이 테스트나 반응 시간 기준을 보조로 정의하면 더 견고하다.; 색맹 검사를 육안 확인만으로 처리하면 판정자 편차가 생길 수 있으므로 동일 캡처·동일 필터·동일 판정 기준을 고정해야 한다.; 스크린리더를 비목표로 둘 수 있다는 설명은 현실적이지만, 접근성 요구가 강한 플랫폼·퍼블리셔·지역 규정이 있는 프로젝트에서는 별도 검토가 필요하다.; 예시의 터치 타깃 px→dp 환산 설명이 약간 혼재되어 보여 실제 적용 시 기기 배율과 Unity Canvas Scaler 기준을 명확히 잡아야 한다.'
    action: review
    path: 40_Skills/candidate/g-ux-06.md
    ecosystem: 'partial:unity-mcp'
  - id: w-frontend-01
    name: Next.js 앱 셸·라우팅
    category: web
    engine: web
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-04(라우트별 정적/동적 판단과 fetch 캐시·revalidate 정책의 접점이 있다.); w-frontend-05(라우트 트리 위에 loading/error/not-found와 권한 상태 UI를 배치하는 후속 작업과 맞닿아 있다.); w-frontend-07(앱 셸 구조가 반응형 레이아웃과 Core Web Vitals 검증의 기반이 된다.); w-pm-02(PM이 정의한 화면·경로 목록을 실제 app/ 파일 트리로 번역한다.); w-ux-01(내비게이션·페이지 계층 결정이 route group과 셸 분리에 영향을 준다.); w-qa-01(빌드, 라우트 접근, 인증 경계 등 검증 게이트를 정의한다.); w-qa-04(보호 라우트, 에러, 권한 부족 상태의 회귀 확인과 연결된다.)'
    value: App Router·레이아웃·서버/클라 경계를 세울 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · Next.js App Router 앱 셸을 실제 파일 트리와 인증 경계까지 고정하게 만드는 고품질 실무형 스킬이다.  리스크: Auth.js, Clerk, 자체 JWT 등 인증 방식별 middleware에서 확인 가능한 토큰 형태와 서버 세션 조회 방식이 다르므로 그대로 복붙하면 안 된다.; Next.js 프로젝트가 src/app 구조를 쓰는 경우 middleware와 app 디렉터리 위치 설명을 프로젝트 구조에 맞게 조정해야 한다.; 권한 부족을 항상 notFound()로 숨기는 전략은 관리자 도구나 B2B 앱에서는 감사성·사용자 안내 측면에서 부적절할 수 있다.; 동적 공개 예시인 /blog/[slug]는 generateStaticParams나 ISR로 정적화할 수도 있어, 표의 예시는 판단 기준으로만 써야 한다.; 루트 layout에 클라이언트 Provider를 직접 넣는 예시는 별도 client wrapper가 필요할 수 있어 RSC 경계 설명을 보강하면 더 안전하다.'
    action: review
    path: 40_Skills/candidate/w-frontend-01.md
    ecosystem: 'partial:sprint-web'
  - id: w-frontend-02
    name: React 컴포넌트 구현
    category: web
    engine: web
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-01(App Router의 서버/클라이언트 경계 판단과 leaf client 분리 기준이 겹친다.); w-frontend-03(재사용 컴포넌트의 props API, 합성 패턴, 디자인 시스템 컴포넌트 구현 판단과 맞닿아 있다.); w-frontend-05(loading/error/empty/ready 같은 상태 모델링과 boolean 대신 유니온을 쓰는 규칙이 겹친다.); w-frontend-06(입력 컴포넌트의 controlled/uncontrolled 판단과 value/onChange 계약이 겹친다.); w-frontend-07(컴포넌트 단위 a11y 필수 속성, 렌더 비용, Core Web Vitals 전 단계 판단과 연결된다.); w-qa-03(라벨, role, 키보드 작동 같은 접근성 확인 항목이 일부 겹친다.); w-ux-03(토큰·컴포넌트·패턴 표준화 과정에서 컴포넌트 API와 슬롯/합성 설계가 겹친다.); w-ux-04(상태 전이와 마이크로인터랙션이 있는 컴포넌트의 상태 위치 결정과 겹친다.); frontend-polish(완성도 점검 과정의 상태, 접근성, 미세인터랙션, 렌더 품질 확인과 일부 겹친다.)'
    value: 재사용 컴포넌트를 만들 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실무성이 높은 우수한 컴포넌트 설계 스킬이지만 Next.js 직렬화·Server Action 경계와 몇 가지 예외 규칙을 보강해야 한다.  리스크: Next.js App Router에서 서버 컴포넌트가 일반 이벤트 핸들러 함수를 props로 넘길 수 없다는 직렬화 제약이 예시에 충분히 반영되지 않았다. Server Action인지, 클라이언트 핸들러인지 구분이 필요하다.; 호출처 2곳 이상 규칙은 일반 재사용 컴포넌트에는 좋지만, 디자인 시스템 primitive나 향후 공개 API로 의도된 컴포넌트에는 너무 늦게 추상화하게 만들 수 있다.; Context Provider 소비/제공을 모두 클라이언트로 단순화했는데, 서버 컴포넌트와 클라이언트 Provider 조합의 composition 패턴을 조금 더 정확히 설명해야 한다.; Profiler로 확인한 뒤에만 memo를 허용하는 규칙은 원칙적으로 좋지만, 매우 큰 리스트나 안정성이 명확한 public component boundary에서는 사전 구조 설계가 필요한 경우가 있다.; a11y를 필수 속성만 다룬다고 했지만 role을 불필요하게 추가할 위험이 있어 native semantic element 우선 원칙이 보강되면 좋다.'
    action: review
    path: 40_Skills/candidate/w-frontend-02.md
    ecosystem: 'partial:sprint-web'
  - id: w-frontend-03
    name: shadcn/ui·Tailwind 구성
    category: web
    engine: web
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-01(Next.js App Router, layout.tsx, 서버/클라 경계와 ThemeProvider 배치에서 일부 겹친다.); w-frontend-02(shadcn 컴포넌트 직접 수정, variant 추가, 래핑 컴포넌트 소유권 규칙이 재사용 컴포넌트 설계와 맞닿아 있다.); w-frontend-07(다크모드 렌더링, 빌드 확인, 반응형/a11y로 넘기는 경계가 화면 품질 게이트와 일부 겹친다.); w-qa-01(tsc, build, 스모크 페이지로 배선 완료 여부를 검증하는 절차가 QA 계획과 접점이 있다.); w-ux-03(CSS 변수, 색 토큰, radius, 컴포넌트 패턴의 적용 위치가 디자인 토큰 표준화와 겹친다.); frontend-polish(작동하는 UI의 테마, 상태, 컴포넌트 정돈을 다루므로 후속 다듬기 관점에서 연결된다.)'
    value: 디자인 시스템을 컴포넌트로 구현할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 배선 역할에 매우 적합한 고품질 스킬이며, 최신 버전 drift와 next-themes 세부만 보완하면 바로 카탈로그에 올릴 수 있다.  리스크: Tailwind v4와 최신 shadcn 설정 흐름은 계속 변하므로, 2026년 기준 프로젝트에서는 공식 문서 확인 없이 v3 전제를 고정하면 역으로 낡은 구성이 될 수 있다.; tailwind.config.ts 예시에 `import type { Config } from "tailwindcss"`가 빠져 있어 그대로 복사하면 타입 오류가 날 수 있다.; next-themes Provider는 보통 클라이언트 컴포넌트 래퍼가 필요하지만, 그 파일 구조와 `suppressHydrationWarning` 같은 실무 세부가 생략되어 초보자가 hydration 경고를 만날 수 있다.; content glob이 `src/` 디렉터리 구조나 `pages/` 혼재 프로젝트를 충분히 포괄하지 않아 brown-field 적용 시 누락 위험이 있다.; `npx`와 `npm run build` 예시가 기본으로 깔려 있어 pnpm/yarn 프로젝트에서는 명령 변환을 명시적으로 해야 한다.'
    action: review
    path: 40_Skills/candidate/w-frontend-03.md
    ecosystem: 'partial:sprint-web'
  - id: w-frontend-04
    name: 서버/클라 상태관리
    category: web
    engine: web
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-01(App Router의 RSC/client boundary와 fetch 위치 결정이 상태 소유권 판단과 직접 맞닿아 있다.); w-frontend-05(mutation 후 로딩·성공·에러·빈 상태 전이가 상태 갱신 경로와 함께 설계되어야 한다.); w-frontend-06(폼 제출 mutation, optimistic 처리, 서버 액션 후 검증 UI가 폼 상태와 연결된다.); w-qa-01(검증 게이트, grep, 수동 확인 기준 등 테스트·검증 계획을 포함한다.); w-qa-04(로딩/빈/에러 및 변경 후 회귀 확인과 mutation 갱신 검증이 겹친다.); w-ux-04(optimistic UI, 롤백, 상태 전이 같은 마이크로인터랙션 설계와 연결된다.)'
    value: React Query·서버액션·캐시를 다룰 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · App Router 상태 소유권과 갱신 경로를 실무적으로 고정하는 고품질 스킬이며, 일부 버전·예외 조건 보강만 있으면 충분히 카탈로그에 올릴 만하다.  리스크: Next.js 버전에 따라 fetch 캐싱 기본 동작, Server Action 이후 라우터 갱신 체감, revalidate 동작이 달라질 수 있는데 버전별 주의가 부족하다.; ''서버 데이터는 useState/store 복사 금지'' 원칙이 강하게 쓰여 있어, 편집 draft, 정렬 전 임시 클라이언트 파생값, virtualized list용 로컬 상태처럼 정당한 예외를 초보자가 과도하게 금지할 수 있다.; React Query/SWR 설치 판단이 RSC 중심으로 잘 정리되어 있지만, 실시간 협업·복잡한 클라이언트 캐시 동기화·오프라인 요구 같은 예외 조건이 더 명시되면 좋다.; 검증 게이트가 수동 확인 중심이라, Playwright나 테스트 코드로 자동화할 항목과 사람이 보는 항목의 구분이 약하다.; 권한/비밀 데이터 캐시 위험 설명은 중요하지만 실제 누수 여부는 Next.js의 per-request memoization, Data Cache, fetch 옵션, 쿠키/헤더 사용 여부에 따라 달라져 더 엄밀한 표현이 필요하다.'
    action: review
    path: 40_Skills/candidate/w-frontend-04.md
    ecosystem: 'partial:sprint-web'
  - id: w-frontend-05
    name: UX 상태 커버
    category: web
    engine: web
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-01(Next.js App Router의 loading.tsx, error.tsx, not-found.tsx 및 라우트/레이아웃 권한 분기와 맞닿아 있다.); w-frontend-04(React Query의 isPending/isError/isSuccess, refetch, mutation 상태와 캐시 롤백 패턴을 화면 상태로 매핑한다.); w-frontend-06(폼 제출중, 클라이언트 검증 실패, 서버 422 응답 표시 등 폼 상태 표현과 겹친다.); w-frontend-07(로딩·에러·폼 상태의 aria 속성, 포커스 이동, CLS 방지 Skeleton 등 접근성과 성능 고려가 포함된다.); w-qa-03(role=status, role=alert, aria-invalid, 포커스 이동 같은 a11y 검증 항목과 연결된다.); w-qa-04(로딩·빈·에러·권한·회귀 상태를 재현하고 검증할 상태 매트릭스를 제공한다.); w-qa-05(API 상태코드와 폼 유효성 실패를 UI 상태로 구분하는 부분이 API/폼 검증과 맞닿아 있다.); w-ux-04(상태 전이 자체보다는 상태 존재와 트리거에 초점이 있지만, 로딩·에러·성공 등 사용자 상태 경험 설계와 영역이 겹친다.); frontend-polish(작동하는 UI의 빈 상태, 에러 상태, 접근성, 미세한 완성도 점검과 일부 같은 화면 품질 문제를 다룬다.)'
    value: 로딩·빈·에러·성공·권한 상태를 채울 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 상태 누락을 코드 조건·우선순위·재현법까지 고정하는 실전성이 높은 프론트엔드 상태 커버 스킬이다.  리스크: 예시 코드에서 `refetch()`를 사용하지만 `useQuery` 반환값에서 destructuring하지 않아 그대로 복사하면 컴파일 오류가 난다.; `data.length` 전제는 배열 응답에만 맞으므로 단일 리소스·페이지네이션·nullable 응답에는 별도 판정 규칙이 필요하다.; `navigator.onLine`은 SSR/RSC 환경에서 직접 접근하면 깨질 수 있어 클라이언트 컴포넌트 경계가 필요하다.; 권한을 항상 fetch보다 위에서 처리하라는 지침은 소유권 확인이 리소스 조회 후에만 가능한 경우에는 단순 적용하기 어렵다.; React Query error에서 HTTP status를 얻으려면 프로젝트의 fetcher/error 타입 표준화가 선행되어야 한다.; `role="alert"`를 Forbidden/NotFound 등 모든 비정상 상태에 쓰면 과도하게 공격적인 라이브 리전이 될 수 있어 상태별 조정이 필요하다.'
    action: review
    path: 40_Skills/candidate/w-frontend-05.md
    ecosystem: 'delegate:sprint-web'
  - id: w-frontend-06
    name: 폼·검증
    category: web
    engine: web
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-05(폼 제출 중 로딩, 에러, 성공 상태와 일부 겹치지만 이 스킬은 필드 검증과 제출 상태에 한정된다.); w-frontend-07(폼 접근성, 포커스 이동, aria 연결, 키보드 검증이 반응형·a11y 보장 영역과 겹친다.); w-qa-01(정상/실패/경계/a11y 게이트를 정의해 검증 계획 일부와 겹친다.); w-qa-03(스크린리더 낭독, aria-invalid/describedby, 포커스 검증이 접근성 QA와 겹친다.); w-qa-05(API 응답, 서버 검증 실패, 필드별 에러 매핑 확인이 API·폼 유효성 QA와 직접 겹친다.); w-frontend-04(Server Action, Route Handler, 제출 API, 서버 응답 처리 흐름이 데이터 제출·서버 상태 처리와 일부 겹친다.); klv:ui-review(폼 UI의 에러 표시, 접근성, 상태 표시 점검 항목이 UI 리뷰 관점과 겹친다.); frontend-polish(폼의 에러 상태, 포커스, 미세 상호작용, 접근성 마감 품질과 겹친다.)'
    value: React Hook Form·Zod로 입력·유효성을 구현할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 폼 구현자가 RHF+Zod 폼을 안전하고 검증 가능하게 만들기에 충분히 구체적인 고품질 스킬이다.  리스크: 공유 Zod 스키마를 클라이언트에서 import할 때 서버 전용 코드나 민감한 로직이 함께 번들되지 않도록 파일 경계를 주의해야 한다.; `z.coerce.date()`는 브라우저 입력값, 타임존, invalid date 처리에서 예상과 다를 수 있어 날짜 정책을 별도로 명시할 필요가 있다.; async validation을 Zod refine로 넣으면 resolver 동작, 디바운스, 중복 요청 관리가 복잡해질 수 있어 서버 제출 시 검증으로 단순화할 기준이 더 있으면 좋다.; 모든 필드 에러에 `role="alert"`를 과하게 쓰면 스크린리더 알림이 noisy해질 수 있어 에러 요약과 필드 에러의 알림 전략을 상황별로 조정해야 한다.; `lib/schemas/` 단일 위치를 강하게 전제하지만 프로젝트 구조가 monorepo, package 분리, 서버 전용 validation 레이어인 경우 경로 규칙은 조정이 필요하다.'
    action: review
    path: 40_Skills/candidate/w-frontend-06.md
    ecosystem: 'partial:sprint-web'
  - id: w-frontend-07
    name: 반응형·접근성·성능
    category: web
    engine: web
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-qa-01(검증 기준과 게이트를 정의한다는 점에서 QA 계획 수립과 맞닿아 있다.); w-qa-02(360/768/1280 뷰포트와 해상도별 레이아웃 깨짐 확인 영역이 겹친다.); w-qa-03(WCAG 2.2 AA, axe, 키보드 탐색, 폼 오류 연결 등 접근성 확인 기준이 겹친다.); w-frontend-02(재사용 컴포넌트의 시맨틱, 터치 타깃, 포커스 가능성 기준과 연결된다.); w-frontend-03(디자인 시스템의 색 대비, 터치 타깃, 토큰 기반 접근성 기준과 겹친다.); w-frontend-05(로딩·에러 상태가 CLS, 접근성 오류 메시지, 반응형 깨짐과 함께 검토될 수 있다.); w-frontend-06(폼 label, aria-describedby, aria-invalid 등 입력 접근성 기준이 겹친다.); klv:ui-review(웹 UI를 반응형·접근성·시각 완성도 관점에서 점검하는 영역이 일부 겹친다.); frontend-polish(작동하는 UI를 접근성, 간격, 상태, 모바일 대응까지 다듬는 후반 품질 점검과 맞닿아 있다.)'
    value: 화면크기·a11y·Core Web Vitals를 보장할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 반응형·접근성·성능 기준을 숫자 게이트로 고정하는 데 매우 실용적인 고품질 프론트엔드 스킬이다.  리스크: 스킬 본문은 기준 저작이 역할이라고 설명하지만 체크리스트와 예시는 실제 측정·교체·실측 판정까지 포함해 QA 또는 구현 역할과 경계가 약간 흐려질 수 있다.; 터치 타깃 24px은 WCAG 최소 기준으로는 의미가 있으나 모바일 앱 수준의 실사용성 기준으로는 44px 권장이 더 안전하므로, 어느 기준을 게이트로 삼는지 혼동될 수 있다.; JS 번들 200KB gzip은 좋은 기본값이지만 제품 성격, 인증 대시보드, 에디터, 지도 등 무거운 화면에서는 예외 기준을 정하는 절차가 추가되면 더 견고하다.; INP는 현장 데이터가 없으면 단일 Lighthouse 실행만으로 확정하기 어렵기 때문에 실험실 대체 지표나 React Profiler 해석 기준을 더 명시하면 오판을 줄일 수 있다.'
    action: review
    path: 40_Skills/candidate/w-frontend-07.md
    ecosystem: 'partial:sprint-web'
  - id: w-pm-01
    name: 핵심 워크플로우 정의
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-pm-02(정의된 흐름을 바탕으로 화면·라우트·API 목록을 도출하는 다음 단계와 직접 연결된다.); w-pm-03(전체 흐름을 정의한 뒤 MVP/Prototype/Later로 범위를 자르는 작업과 이어진다.); w-pm-04(각 단계의 성공 조건을 식별하고 이후 측정 가능한 완료 기준으로 구체화한다.); w-ux-01(논리 흐름이 실제 내비게이션·정보구조·페이지 이동 설계의 입력이 된다.); w-ux-04(상태 전이와 예외 흐름이 마이크로인터랙션·피드백 설계와 맞닿아 있다.); w-frontend-05(로딩·에러·권한·성공 상태를 구현하기 전 어떤 상태가 필요한지 정의한다.); w-frontend-06(데이터 접점과 검증 규칙을 식별해 폼 구현의 입력이 된다.); w-qa-01(예외 경로와 성공 상태가 이후 검증 시나리오의 기반이 된다.); w-qa-04(로딩·빈·에러·권한·회귀 케이스를 흐름 단계에서 미리 드러낸다.); w-qa-05(API 응답, 폼 유효성, 중복 제출 같은 검증 포인트와 연결된다.)'
    value: 사용자가 끝내야 할 일을 정의할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 구현 전 핵심 잡의 흐름·상태·권한·데이터·예외를 한 장으로 고정하는 고품질 PM 스킬이다.  리스크: 모든 단계에 예외 경로 최소 1개를 강제하면 단순 흐름에서는 억지 예외가 생길 수 있으므로 ''해당 없음''을 허용하는 판단 기준이 있으면 더 좋다.; 행복 경로 5~9단계 규칙은 3단계 이하 작은 흐름 가드와 약간 충돌해 보일 수 있어 작은 흐름의 허용 형식을 더 명시하면 좋다.; 상태값을 모든 단계에 요구할 때 서버 엔티티 상태가 없는 순수 탐색·조회 흐름에서는 상태 정의가 과도해질 수 있다.; 참고 자료가 이름만 있고 실제 적용 기준은 본문에 충분히 흡수되어 있으나, 멱등성·상태 머신의 최소 판단 규칙을 조금 더 자급자족적으로 적으면 초보자에게 더 안정적이다.'
    action: review
    path: 40_Skills/candidate/w-pm-01.md
    ecosystem: 'delegate:gatecraft'
  - id: w-pm-02
    name: 페이지·라우트 인벤토리
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-pm-01(사용자 잡/흐름을 입력으로 받아 화면 후보를 뽑는 단계가 이어진다.); w-ux-01(내비게이션과 정보계층 결과를 URL 목록과 레이아웃 그룹으로 고정한다.); w-ux-02(페이지별 골격을 그리기 전 각 페이지의 목적·상태·데이터 의존을 정의한다.); w-frontend-01(App Router 구현 전에 app 구조, 레이아웃 중첩, 동적 세그먼트의 입력 명세를 만든다.); w-frontend-05(로딩·빈·에러·권한거부 상태를 구현하지는 않지만 라우트별 필요 여부를 정의한다.); w-qa-04(경계 라우트와 상태 누락을 사전에 체크해 로딩/빈/에러 회귀 검증 범위와 맞닿는다.)'
    value: 필요한 화면·경로를 나열할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 산출물과 절차는 매우 실용적이지만, 정적 리다이렉트로 인증을 막는 예시와 프레임워크 편향을 고치면 promote급이다.  리스크: Cloudflare/Vercel 정적 리다이렉트로 로그인 여부에 따른 조건부 접근 제어를 처리할 수 있는 것처럼 읽히는 예시가 위험하다. `/bookmarks`를 `_redirects`로 302 처리하면 로그인 사용자도 우회될 수 있다.; SSG/SSR/CSR 판정 규칙이 빠른 결정을 돕지만, 개인정보·권한·캐시 무효화·서버 미들웨어 필요성을 별도로 확인하지 않으면 보안/데이터 신선도 문제가 생길 수 있다.; Next.js 용어가 많아 React Router, Remix, SvelteKit 등에서는 필드명을 그대로 쓰기보다 대응 개념으로 번역해야 한다는 전제가 필요하다.; `/500`, `/robots.txt`, `/sitemap.xml`을 모두 라우트 테이블에 넣는 방식은 프레임워크에 따라 파일 기반 특수 엔트리와 페이지 라우트를 혼동할 수 있다.'
    action: review
    path: 40_Skills/candidate/w-pm-02.md
    ecosystem: 'delegate:sprint-web'
  - id: w-pm-03
    name: MVP 범위 컷
    category: web
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-pm-01(사용자 문제와 목표를 한 문장으로 고정하고 MVP 결정의 기준을 세우는 부분이 겹친다.); w-pm-02(MVP 범위 컷 이후 필요한 화면, 경로, 시스템 영향을 작업 패킷으로 정리하는 부분이 겹친다.); w-pm-04(완료 기준, 실패 기준, 검증 지표를 정의하는 게이트 설계가 겹친다.); w-qa-01(무엇을 어떤 증거로 검증할지 정하는 검증 게이트가 겹친다.); w-frontend-05(웹앱 MVP 범위에서 로딩·빈·오류·권한 상태를 초기 점검 대상으로 포함한다.); w-ux-01(범위 결정 과정에서 내비게이션, 페이지 구조, 사용자 흐름의 포함 여부를 판단할 수 있다.)'
    value: 대시보드·관리자 범위 과잉을 자를 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실무 절차와 산출물 구조는 좋지만, 웹앱별 구체 항목과 현실적인 예시를 보강하면 promote 수준이다.  리스크: 대안 비교 기준에 점수표나 우선순위 산식이 없어 복잡한 결정에서는 결론이 주관적으로 흐를 수 있다.; 웹앱 체크 항목인 라우트, 상태, 권한, 접근성, 빈/오류 상태가 실제 산출물 템플릿에는 충분히 드러나지 않는다.; Example이 너무 일반적이라 사용자가 어떤 수준의 구체성으로 작성해야 하는지 배우기 어렵다.; 시간 제한, 출시 목표, 핵심 사용자 행동 같은 MVP 컷의 핵심 제약을 강제로 채우게 하는 장치가 약하다.'
    action: use
    path: 40_Skills/candidate/w-pm-03.md
    ecosystem: 'delegate:sprint-web'
  - id: w-pm-04
    name: 수용 기준 정의
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-05(로딩·빈·에러·성공·권한 상태를 AC 필수 항목으로 정의한다.); w-frontend-07(breakpoint, 접근성, Core Web Vitals 같은 완료 조건을 정의한다.); w-pm-01(사용자 과업 문장으로 기능을 다시 쓰는 전제가 연결된다.); w-pm-02(라우트와 화면 범위가 정해진 뒤 각 경로의 완료 조건을 붙인다.); w-pm-03(범위가 정해진 기능에 대해 완료 기준만 다룬다는 경계가 맞닿아 있다.); w-qa-01(AC별 증거 유형과 검증 주체를 지정해 QA 검증 계획으로 이어진다.); w-qa-02(브라우저와 해상도별 수용 기준을 포함한다.); w-qa-03(키보드, 포커스, 라벨, 대비 같은 접근성 기준을 AC에 포함한다.); w-qa-04(UI 상태와 회귀 위험을 수용 기준으로 명시한다.); w-qa-05(API 오류, 폼 검증 실패, 서버 오류 조건을 AC로 다룬다.); w-ux-04(상태 전이와 실패 시 사용자 피드백을 완료 조건으로 표현한다.); klv:ui-review(대시보드·폼 등 웹 UI의 상태, 접근성, 반응형 점검 항목과 일부 기준이 겹친다.); frontend-polish(간격·상태·접근성·미세 상호작용의 완료 기준을 사전에 정의하는 부분이 맞닿아 있다.)'
    value: 완료를 측정 가능하게 만들 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 웹 기능의 완료 조건을 관찰 가능한 AC로 고정하는 PM 스킬로서 절차와 검증성이 매우 강해 승격 가치가 높다.  리스크: 모든 기능에 6개 필드를 강제하면 매우 작은 변경에도 표가 과해질 수 있어, 경량 기능용 최소 AC 기준이 있으면 더 좋다.; WCAG 2.1 AA를 핵심 4개로 축소하는 전제는 현실적이지만, 법적·공공·금융 등 고위험 서비스에서는 부족할 수 있다.; 검증주체 칸의 PM정의/QA 표기가 예시에서 다소 혼재되어, PM은 정의만 하고 QA는 실행한다는 표기 규칙을 더 엄격히 통일하면 좋다.; LCP 같은 성능 목표가 입력에는 있으나 체크리스트와 예시에서는 상대적으로 약하게 다뤄져 누락될 수 있다.'
    action: review
    path: 40_Skills/candidate/w-pm-04.md
    ecosystem: 'delegate:product-spec'
  - id: w-qa-01
    name: 테스트 계획
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-pm-04(P0/P1 게이트와 관찰 가능한 통과 기준을 세우는 부분이 완료 기준 정의와 맞닿아 있다.); w-pm-03(가용 QA 시간에 따라 컷 라인을 긋고 P2를 백로그로 보내는 범위 조정이 겹친다.); w-qa-02(브라우저·디바이스 매트릭스와 반응형 검증 우선순위를 다룬다.); w-qa-03(접근성 실패면, axe 자동 스캔, 키보드 수동 점검을 계획에 포함한다.); w-qa-04(로딩·에러 상태와 결함 수정 후 회귀 범위 산정 및 재실행 목록이 겹친다.); w-qa-05(폼 유효성, API 에러, 타임아웃, MSW 기반 자동화 판단이 API·폼 QA와 겹친다.); w-frontend-07(화면 크기, 접근성, SEO/Core Web Vitals 성격의 웹 품질 실패면을 검증 대상으로 삼는다.); w-frontend-05(빈 상태·에러 상태·권한 상태 같은 UI 상태 검증 계획과 관련된다.); klv:ui-review(웹 UI의 접근성·반응형·상태·시각 검토를 출시 전 점검한다는 면에서 접점이 있다.); frontend-polish(레이아웃 어색함, 미세한 시각 문제, 접근성 보완을 수동 점검 대상으로 다룬다.)'
    value: 무엇을 어떻게 검증할지 정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 웹앱 출시 전 테스트 범위와 게이트를 1인 개발자가 실행 가능한 수준으로 구조화한 고품질 QA 계획 스킬이다.  리스크: 리스크 점수 기준은 명확하지만 실제 프로젝트에서 사용자 분석이나 트래픽 데이터가 없으면 빈도 1~3 판정이 주관적으로 흐를 수 있다.; P0는 자동화 1개라도 깐다는 기본선은 작은 1회성 릴리스나 자동화 인프라가 전혀 없는 프로젝트에서는 부담이 될 수 있다.; SEO/메타와 Core Web Vitals가 실패면에 포함되지만 성능 예산이나 측정 도구 기준은 상대적으로 얕아 별도 기준이 없으면 누락될 수 있다.; 계정 3등급·데이터 4종 시드 전제를 모든 기능에 적용하면 매우 작은 기능 검증에서는 준비 비용이 과해질 수 있다.; 브라우저 기본 매트릭스가 미국/한국 일반 웹앱에는 무난하지만 제품의 실제 사용자 브라우저 분포와 다를 경우 조정 지침이 더 필요하다.'
    action: review
    path: 40_Skills/candidate/w-qa-01.md
    ecosystem: 'delegate:sprint-web'
  - id: w-qa-02
    name: 반응형·브라우저 호환
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-qa-01(전체 테스트 계획 중 반응형·브라우저 호환 영역의 세부 검증 계획과 겹친다.); w-qa-03(텍스트 확대, 터치 타깃, 렌더링에 영향을 주는 사용자 설정 등 일부 접근성 검증과 접점이 있다.); w-qa-04(로딩·빈·에러 등 상태 화면이 각 뷰포트에서 깨지는지 확인하는 회귀 검증과 겹친다.); w-frontend-07(반응형, 접근성, Core Web Vitals 구현 품질을 다루는 스킬과 같은 화면 품질 영역을 검증 관점에서 다룬다.); klv:ui-review(웹 UI가 대시보드·폼·랜딩에서 깨지지 않는지 시각적으로 점검하는 활동과 일부 겹친다.); frontend-polish(간격, 정렬, 상태, 미세인터랙션 등 UI 완성도를 다듬은 뒤 브라우저·뷰포트별로 검증하는 영역과 접점이 있다.)'
    value: 해상도·크로스브라우저를 검증할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 반응형·브라우저 호환을 배포 게이트로 만들기에 충분히 구체적이고 실전성이 높은 고품질 QA 스킬이다.  리스크: Statcounter·브라우저 버전·점유율 기본값은 시간이 지나면 낡으므로 사용 시점의 데이터 날짜를 명시해야 한다.; 실제 iOS 기기 또는 BrowserStack 확인은 1인 개발자에게 비용·장비 부담이 될 수 있어 최소 대체 경로가 필요할 수 있다.; 시각 회귀 테스트는 폰트 로딩, 애니메이션, 날짜·랜덤 데이터 때문에 flaky해질 수 있으므로 안정화 조건이 빠지면 운영 부담이 생긴다.; 지원 매트릭스가 너무 넓어지면 작은 PR에도 검증 비용이 과해질 수 있어 P0/P1/P2 실행 빈도 구분이 필요할 수 있다.; caniuse 확인만으로 부분 구현·브라우저 버그를 완전히 판정할 수 없으므로 실제 재현 테스트와 항상 연결해야 한다.'
    action: review
    path: 40_Skills/candidate/w-qa-02.md
    ecosystem: 'delegate:sprint-web'
  - id: w-qa-03
    name: 접근성·WCAG 점검
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-07(화면 크기, 접근성, Core Web Vitals를 구현 단계에서 보장하는 영역과 접근성 기준이 겹친다.); w-qa-01(검증 범위와 방법을 정하는 일반 QA 흐름과 감사 절차·증거 수집 방식이 겹친다.); w-qa-02(해상도·브라우저·확대 등 환경별 검증과 200% 확대, 키보드 흐름 점검 일부가 겹친다.); w-qa-05(폼 유효성, 오류 메시지, aria-describedby, aria-invalid 확인이 API·폼 QA와 겹친다.); w-frontend-06(React Hook Form·Zod 기반 입력 구현에서 라벨, 오류 연결, 접근 가능한 폼 패턴과 겹친다.); w-ux-03(디자인 토큰·컴포넌트 표준화에서 대비, 포커스 링, 타깃 크기 같은 접근성 토큰 기준과 겹친다.); klv:ui-review(폼·대시보드·랜딩 화면의 시각 품질 점검 중 대비, 포커스, 라벨 등 측정 가능한 접근성 항목이 겹친다.); frontend-polish(완성도 개선 과정에서 상태, 미세인터랙션, 접근성 보정이 겹친다.)'
    value: a11y 기준 충족을 확인할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실무성이 높은 감사 스킬이지만 WCAG SC·법적 요구 표현을 공식 기준에 맞게 보정하면 promote 수준이다.  리스크: Section 508, EN 301 549, ADA 적용 범위를 ''AA 강제''처럼 단정하면 관할·계약·시점별 차이를 놓칠 수 있다.; WCAG 2.2 AA와 AAA 기준이 일부 섞여 있어 SC 번호와 실패 기준을 공식 Quick Reference 기준으로 재검증해야 한다.; 포커스 표시에서 2px·3:1을 SC 2.4.7로 단정하는 부분은 실제 WCAG 기준과 어긋날 수 있어 감사 문서 신뢰도를 낮출 수 있다.; 자동 도구가 30~40%만 잡는다는 수치는 유용한 경고지만 출처 없는 고정 수치로 쓰면 논쟁 소지가 있다.; 스크린리더 점검은 NVDA와 VoiceOver의 브라우저 조합별 차이가 커서 지원 브라우저·OS 매트릭스를 함께 고정해야 한다.; 내부 도구는 WCAG 2.1 A로 낮춰도 된다는 기본값은 실제 사용자·고용·조직 정책에 따라 부적절할 수 있다.'
    action: review
    path: 40_Skills/candidate/w-qa-03.md
    ecosystem: 'partial:sprint-web'
  - id: w-qa-04
    name: UX 상태·회귀 검증
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-05(로딩·빈·에러·성공·권한 상태를 다루지만, 해당 스킬은 상태 구현·채우기이고 이 스킬은 구현된 상태의 재현과 회귀 검증에 초점이 있다.); w-ux-04(상태 전이와 마이크로인터랙션 영역을 공유하지만, 이 스킬은 설계 판단이 아니라 정의된 상태의 검증 증거 생산을 담당한다.); w-pm-04(완료 기준의 측정 가능성과 연결되지만, 이 스킬은 출시 판단 자체가 아니라 상태별 테스트·스크린샷·diff 증거를 제공한다.); w-qa-01(검증 전략 수립과 겹치며, 이 스킬은 그중 웹 UI 상태와 시각 회귀에 특화된 하위 QA 절차다.); w-qa-02(해상도와 크로스브라우저 검증 중 뷰포트 고정·시각 스냅샷과 일부 겹친다.); w-qa-03(role/text 기반 검증과 접근 가능한 셀렉터 사용에서 일부 접점이 있다.); w-qa-05(API mock, 실패 응답, 폼·API 상태 검증과 일부 겹치지만 이 스킬은 화면 상태 회귀 판정에 초점이 있다.); klv:ui-review(웹 UI 점검 과정에서 상태·레이아웃·회귀 확인이 겹칠 수 있다.); frontend-polish(UI 완성도 점검 중 상태, 간격, 미세 변화 확인과 접점이 있으나 이 스킬은 회귀 검증 절차 중심이다.)'
    value: 로딩/빈/에러 + 변경 회귀를 볼 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 웹 상태 회귀 검증에 필요한 절차와 산출물이 구체적이고 1인 개발 현실에도 잘 맞아 승격할 만하다.  리스크: Playwright 시각 회귀 허용 오차 값은 프로젝트·OS·폰트 렌더링·CI 환경에 따라 조정이 필요하다.; baseline 이미지를 git에 커밋하는 방식은 저장소 크기 증가와 리뷰 노이즈를 만들 수 있어 보존 범위 정책이 필요하다.; 첫 baseline 생성 시 무엇이 ‘정상 기준’인지 사람의 승인 절차가 없으면 결함 상태를 기준으로 고정할 위험이 있다.; 상태 존재 검증을 ‘항상 자동화’로 강하게 표현했지만, 레거시 앱이나 테스트 환경 부재 프로젝트에서는 초기 세팅 비용이 과소평가될 수 있다.; mock이 실제 백엔드 계약과 어긋나면 상태 재현은 통과하지만 실제 장애를 놓칠 수 있다.'
    action: review
    path: 40_Skills/candidate/w-qa-04.md
    ecosystem: 'delegate:sprint-web'
  - id: w-qa-05
    name: 데이터 계약 준수 검증
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-qa-01(무엇을 검증할지 정하는 범용 QA 절차와 겹치지만, 이 스킬은 데이터 타입·형태·계약 불일치에 특화되어 있다.); w-qa-04(변경 회귀와 화면 깨짐 방지 관점에서 일부 겹치지만, 이 스킬은 렌더 전 데이터 계약 검증에 집중한다.); w-frontend-06(Zod와 폼 입력 유효성 도구를 공유하지만, 이 스킬은 구현보다 계약 검증과 회귀 게이트로 재사용하는 관점이다.); w-frontend-04(API 응답 소비, 서버 데이터 처리, 캐시 계층과 접점이 있으나, 이 스킬은 데이터 shape 검증 자체를 다룬다.); w-frontend-05(권한·빈 값·에러 상태가 화면에 드러나는 문제와 연결되지만, 이 스킬은 그 원인인 응답 계약 위반을 사전에 잡는다.)'
    value: API 응답·폼 유효성을 확인할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 데이터 계약 표류를 렌더 전과 CI에서 잡는 절차가 매우 구체적이고 1인 개발 SaaS에도 실전 적용성이 높다.  리스크: 모든 SSoT를 Zod로 번역하라고 요구하므로 OpenAPI/GraphQL에서 자동 변환 도구를 쓰지 않으면 수동 스키마와 원본 계약이 다시 표류할 수 있다.; 형태 diff를 키 추가까지 무조건 실패시키면 하위 호환 가능한 확장도 불필요하게 막을 수 있어 허용 정책이 필요하다.; fixture에 실제 운영 응답을 저장할 때 개인정보·토큰·상업 민감 데이터 마스킹 절차가 더 강하게 필요하다.; 권한별 스키마 분리는 좋지만 역할 조합이나 feature flag별 응답 차이가 많은 제품에서는 케이스 폭발이 생길 수 있다.; 날짜·숫자 포맷 판정은 타임존, currency, locale, decimal precision 같은 도메인 규칙을 별도로 명시하지 않으면 놓칠 수 있다.'
    action: review
    path: 40_Skills/candidate/w-qa-05.md
    ecosystem: 'delegate:sprint-web'
  - id: w-ux-01
    name: 정보 구조 설계
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-pm-01(핵심 사용자 과업을 입력으로 받아 IA 워크스루에서 과업 흐름을 검증한다.); w-pm-02(화면·경로 목록을 받아 계층, 라벨, URL, 권한 구조로 변환한다.); w-pm-03(페이지 수와 내비 항목을 줄이고 later 태그로 범위를 자르는 판단이 대시보드·관리자 과잉 컷과 맞닿아 있다.); w-frontend-01(URL/라우트 규칙과 인증 요구가 App Router 구조 설계와 연결된다.); w-frontend-05(각 노드에 로딩·빈·오류·권한없음 상태 존재 여부를 표시한다.); w-ux-02(사이트맵 노드가 이후 페이지별 와이어프레임의 입력이 된다.); w-qa-01(IA 산출물의 검증 기준과 과업 워크스루를 정의한다.); w-qa-04(로딩·빈·오류·권한 상태의 존재 여부를 IA 단계에서 누락 방지 플래그로 다룬다.); klv:ui-review(대시보드·폼·랜딩의 구조적 점검과 일부 접점이 있으나 이 스킬은 화면 내부가 아니라 IA 뼈대에 집중한다.)'
    value: 내비·계층·페이지 구조를 잡을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · IA 역할에 매우 잘 맞는 고품질 스킬이며, 구체적 절차와 검증 가능한 산출물이 충분해 승격 권고.  리스크: 1차 내비 7개 이하와 깊이 3 이하 규칙이 유용한 휴리스틱이지만, 복잡한 B2B·관리자·문서형 서비스에서는 과도하게 경직될 수 있다.; URL 세그먼트 3 이하 규칙은 SEO와 단순성에는 좋지만 조직/프로젝트/리소스처럼 자연스러운 계층이 필요한 앱에서는 예외 기준이 필요하다.; 권한 매트릭스가 역할 중심이라 소유자 여부, 조직 멤버십, 리소스별 ACL 같은 동적 권한 모델은 별도 보강이 필요하다.; SEO 항목이 title/description/slug 중심이라 canonical, noindex, pagination, locale 같은 공개 콘텐츠 IA 이슈는 빠질 수 있다.; 예시의 `/new` 재사용 같은 평탄화 전략은 구현 비용을 줄이지만 리소스별 생성/편집 의미가 흐려질 수 있어 프로젝트별 판단이 필요하다.'
    action: review
    path: 40_Skills/candidate/w-ux-01.md
    ecosystem: 'delegate:sprint-web'
  - id: w-ux-02
    name: 와이어프레임
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-ux-01(페이지 목록, 내비 계층, 들어오고 나가는 경로가 와이어프레임 입력 전제로 연결된다.); w-pm-02(필요한 화면·경로를 먼저 나열한 뒤 특정 한 화면의 배치를 확정하는 후속 작업이다.); w-frontend-05(로딩·빈·에러·권한없음 상태가 와이어프레임 주석에 등장하지만 상세 화면 설계는 해당 스킬로 넘긴다.); w-qa-02(모바일 360과 데스크톱 1280 등 반응형 변형을 정의하며, 실제 검증은 해상도·크로스브라우저 QA와 이어진다.); w-frontend-07(화면 크기, 반응형 배치, 텍스트 줄바꿈 같은 구현 품질 조건과 의미적으로 맞닿아 있다.); w-ux-04(클릭 동작, 인라인 변화, 화면 전환 화살표 등 상태 전이·마이크로인터랙션의 초기 단서를 포함한다.); klv:ui-review(대시보드·폼·랜딩 화면의 배치와 정보 우선순위를 점검한다는 점에서 리뷰 관점과 겹친다.); frontend-polish(간격·정렬·상태·접근성 다듬기 전 단계에서 UI 골격과 우선순위를 확정한다.)'
    value: 페이지별 골격을 그릴 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 한 페이지 웹앱 와이어프레임을 1인 개발자가 실행 가능한 산출물로 만들기에 충분히 구체적이므로 승격 권고.  리스크: 모바일 글자 수 18~20자, 폼 5~7필드 같은 숫자 기준은 제품 도메인·폰트·언어·입력 복잡도에 따라 과도하게 고정적으로 해석될 수 있다.; ''1순위 요소는 딱 하나'' 원칙은 가입·결제 같은 목표형 화면에는 강하지만, 모니터링 대시보드나 운영툴처럼 동시 비교가 핵심인 화면에는 보완 설명이 필요하다.; fold 기준은 기기 높이, 브라우저 UI, 접근성 글자 크기 설정에 따라 달라지므로 절대 위치처럼 다루면 오판할 수 있다.; 상태별 화면 설계를 w-frontend-05로 위임하는 경계는 좋지만, 와이어프레임 단계에서 필요한 상태 공간 확보와 상세 설계의 분기점이 일부 팀에서는 애매할 수 있다.'
    action: review
    path: 40_Skills/candidate/w-ux-02.md
    ecosystem: 'delegate:gatecraft'
  - id: w-ux-03
    name: 디자인 시스템
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-02(재사용 컴포넌트 목록화와 variant/state 정의가 컴포넌트 설계와 맞닿아 있다.); w-frontend-03(디자인 시스템을 실제 컴포넌트와 토큰으로 구현하는 단계의 앞단 계약서를 다룬다.); w-frontend-07(접근성, 반응형 품질, Core Web Vitals 검증 기준 일부가 겹친다.); w-qa-01(검증 게이트와 통과 기준을 정의해 QA 계획 수립과 연결된다.); w-qa-03(WCAG 대비, 포커스, 키보드 접근성 검증 기준이 직접 겹친다.); w-ux-02(페이지별 UI 골격 이후 반복 패턴과 컴포넌트 사용 규칙을 정하는 흐름이 이어진다.); w-ux-04(컴포넌트 상태, focus, loading, disabled 등 인터랙션 상태 정의가 일부 겹친다.); klv:ui-review(UI 일관성, 상태, 접근성 점검 관점에서 리뷰 항목이 겹친다.); frontend-polish(간격, 정렬, 상태, 접근성, 미세한 UI 완성도 기준과 일부 겹친다.)'
    value: 토큰·컴포넌트·패턴을 표준화할 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 디자인 시스템을 UX 계약서로 만드는 절차와 검증 기준이 매우 실용적이며, 일부 예시 일관성만 다듬으면 바로 승격 가능한 스킬이다.  리스크: grep 예시는 HEX만 잡기 때문에 Tailwind arbitrary class, rgb/hsl/oklch, CSS 변수, 인라인 클래스 문자열은 놓칠 수 있다.; semantic 층 외 HEX 0건 기준은 외부 라이브러리, 로고, 차트 색상처럼 예외가 필요한 영역까지 과도하게 막을 수 있다.; 모든 fg/bg 조합 실측은 토큰 수가 늘면 비용이 커지므로 핵심 조합 우선순위가 없으면 1인 개발자에게 부담이 될 수 있다.; shadcn/ui 우선 원칙은 생산성에는 좋지만, 제품 도메인에 특화된 복잡한 컴포넌트까지 무리하게 맞추면 사용성 설계가 제한될 수 있다.; 예시의 variant/state 표가 semantic 토큰 원칙을 일부 위반해 초보 사용자가 primitive 직접 참조를 따라 할 위험이 있다.'
    action: review
    path: 40_Skills/candidate/w-ux-03.md
    ecosystem: 'partial:sprint-web'
  - id: w-ux-04
    name: 인터랙션 설계
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-02(재사용 컴포넌트의 상태와 동작을 설계할 때 행동 사양이 맞닿는다.); w-frontend-03(디자인 시스템 컴포넌트 구현 시 hover/focus/disabled/motion 같은 상호작용 규칙을 함께 다룬다.); w-frontend-05(로딩·성공·에러 상태 자체와 그 사이의 전이/피드백 타이밍이 인접한다.); w-frontend-07(키보드 접근성, 포커스 가시성, reduced-motion 등 a11y 요구가 겹친다.); w-qa-01(전이표와 즉시 피드백 기준이 QA 검증 항목으로 이어진다.); w-qa-03(스크린리더, 키보드 조작, 포커스 링 등 접근성 검증 대상이 겹친다.); w-ux-03(컴포넌트 토큰·모션 토큰을 행동 사양에서 재사용한다.); frontend-polish(미세인터랙션, 상태 피드백, 접근성 마감 점검과 영역이 맞닿는다.)'
    value: 상태 전이·마이크로인터랙션을 설계할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 컴포넌트 단위 인터랙션 행동을 실무적으로 명세하게 만드는 고품질 스킬이며 바로 승격 가능하다.  리스크: 모든 요소에 default/hover/focus/active/disabled 및 idle/pending/success/error를 기계적으로 요구하면 단순 링크나 정적 컨트롤에는 과도한 문서화가 될 수 있다.; pending 시 실제 disabled 속성을 쓰면 포커스를 잃거나 스크린리더 흐름이 끊길 수 있어, 상황에 따라 aria-disabled와 이벤트 가드의 선택 기준이 더 필요하다.; error는 assertive라고 단정하면 알림이 과도하게 끼어들 수 있으므로 치명도별 polite/assertive 판단 기준이 있으면 더 안전하다.; ''APG 키 표를 그대로 복사'' 표현은 커스텀 위젯의 실제 맥락에 맞춘 조정 없이 형식만 붙이는 오용을 부를 수 있다.; 스피너 무한 회전은 reduced-motion에서 정지한다고 해도 진행 상태가 장시간 지속될 때 타임아웃·취소·재시도 정책이 별도로 필요하다.'
    action: review
    path: 40_Skills/candidate/w-ux-04.md
    ecosystem: 'delegate:sprint-web'
  - id: x-analytics-01
    name: 이벤트 택소노미 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-02(이벤트 사전은 KPI·대시보드 설계의 입력이 되며 측정 질문과 이벤트 매핑이 일부 맞닿는다.); x-analytics-03(튜토리얼·결제 전환 같은 이탈 구간 분석을 위해 필요한 이벤트 정의와 퍼널 이벤트가 겹친다.); x-analytics-05(Amplitude/Firebase/Metabase에서 매일 볼 데이터의 원천 이벤트 품질과 검증 기준이 연결된다.); x-analytics-06(UI·가격·보상·온보딩 실험 검증에 필요한 행동 이벤트 설계가 일부 겹친다.); x-analytics-08(클라 로그와 서버 원장 불일치, 중복 수집, dedupe 키 같은 사후 원인 분석 주제와 직접 연결된다.); x-analytics-09(PII 금지 속성, 동의 조건부 속성, 익명화·가명 ID 처리 전제가 맞닿는다.); x-server-02(서버 이벤트 엔티티와 주문·결제 데이터 모델이 이벤트 사전의 서버 발사 이벤트와 연결된다.); x-server-09(결제 이벤트의 멱등성, transaction_id, 정산 데이터와 매출 이벤트 설계가 겹친다.); x-platform-10(핵심 플로우 자동 검증에서 이벤트 발사 여부와 샘플 쿼리 검증을 테스트 대상으로 삼을 수 있다.)'
    value: 분석 로그 처음 설계 (네이밍 규칙)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 이벤트 택소노미를 실제 코드 투입 전 명세와 검증으로 고정하게 해주는 완성도 높은 스킬이다.  리스크: GA4/Firebase/Amplitude의 이벤트명·파라미터 한도와 예약어는 시간이 지나며 바뀔 수 있으므로 실제 적용 시 최신 공식 문서 확인이 필요하다.; `user_id` 머지 규칙은 스택별 구현 차이가 커서 Firebase `setUserId` 예시를 그대로 일반화하면 일부 도구에서 식별자 병합이 기대와 다를 수 있다.; `schema_version`을 모든 이벤트 공통 속성으로 둘지 이벤트별 버전으로 둘지 대형 변경 시 혼선이 생길 수 있어 버전 범위를 명시하면 더 좋다.; 동사 사전을 너무 좁게 닫으면 제품 도메인별 핵심 행동을 억지로 끼워 맞출 위험이 있으므로 신규 동사 승인 기준이 있으면 더 안전하다.; 서버 발사 이벤트의 재시도·멱등성·전송 실패 처리까지는 범위 밖이라 실제 구현 단계에서 별도 보완이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-analytics-01.md
    ecosystem: 'partial:sprint-web'
  - id: x-analytics-02
    name: 핵심 지표 정의
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-01(이벤트명·속성 네이밍과 계측 직전 지표 정의가 맞물린다.); x-analytics-03(리텐션·전환·핵심행동 지표 정의가 이탈 구간 분석의 입력이 된다.); x-analytics-04(채널·결제여부·가입주차 등 세그먼트 기반 사용자 품질 평가와 겹친다.); x-analytics-05(정의된 지표를 Metabase·Amplitude 대시보드로 매일 보는 흐름과 직접 연결된다.); x-analytics-08(클라 이벤트와 서버 원장 불일치, 매출 원천 신뢰 판단을 일부 다룬다.); x-analytics-09(PII 제외, 동의 범위, 익명 집계 등 분석 개인정보 처리와 겹친다.); x-monetization-05(ARPU·LTV·CAC 등 수익성 판단 지표 정의와 일부 연결된다.); x-compliance-02(동의, 추적, 쿠키·앱 추적 권한 관련 전제가 일부 겹친다.); x-compliance-05(아동 대상 서비스의 COPPA 및 데이터 수집 제한을 언급한다.)'
    value: 목표·대시보드 (DAU·retention·ARPU·LTV·churn)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 품질이 매우 높고 즉시 실행 가능한 핵심 지표 정의 스킬이므로 promote가 적절하다.  리스크: 북극성 지표를 항상 매출이 아닌 가치 전달량으로 제한하는 원칙은 대체로 좋지만, 거래소·핀테크·마켓플레이스처럼 매출 또는 거래액이 가치 전달량과 강하게 결합된 제품에서는 보정 설명이 필요하다.; Amplitude·Mixpanel·GA4 등의 UI와 무료 플랜 제한은 바뀔 수 있어 도구별 절차는 주기적 갱신이 필요하다.; 도구 차트와 SQL/손계산 오차 ±5% 기준은 실무적으로 유용하지만 이벤트 규모가 작거나 샘플링·지연 적재가 있는 경우에는 별도 판정 기준이 필요하다.; 개인정보·COPPA 언급은 체크리스트 수준이므로 법률 판단이나 지역별 규정 대응으로 오해하면 안 된다.; 출시 전 단계에서는 현재값·임계치가 가정 기반일 수밖에 없는데, 이를 어떻게 초기 베이스라인으로 갱신할지 절차가 조금 더 있으면 좋다.'
    action: review
    path: 40_Skills/candidate/x-analytics-02.md
    ecosystem: 'partial:sprint-web'
  - id: x-analytics-03
    name: 퍼널 분석 구성
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-01(퍼널 단계별 이벤트명, 속성, 수집 위치, 이벤트 택소노미 설계가 필수라 분석 로그 초기 설계와 직접 겹친다.); x-analytics-02(퍼널 전환율, KPI, 대시보드 기준, 중단 기준을 정의하므로 목표·대시보드 설계와 겹친다.); x-analytics-06(온보딩, UI, 가격, 보상 검증에서 전환 단계와 실패 기준을 잡는 흐름이 퍼널 검증 게이트와 겹친다.); x-analytics-08(클라이언트 로그와 서버 원장 중 신뢰 기준을 정하고 수치 불일치를 다루는 부분이 겹친다.); x-analytics-09(개인정보, 동의, 추적 권한, 로그 노출 여부 확인이 분석 규정 처리와 겹친다.); x-compliance-02(쿠키, 앱 추적 권한, GDPR 등 분석 추적 전제 확인이 필요해 규정 대응 영역과 맞닿는다.)'
    value: 이탈 구간 찾기 (가입·튜토리얼·결제 전환)
    risk: 'Tier-2 품질 4/5 · 권고 promote · 퍼널 분석 독립 스킬로 승인 가능한 품질이지만, 도구별 예시와 산식 템플릿을 추가하면 더 강해진다.  리스크: 출력 템플릿에 퍼널 단계 표, 이벤트 택소노미 표, 전환율 산식 표가 별도 섹션으로 고정되어 있지 않아 중요한 보강 항목이 실행 중 누락될 수 있다.; 도구별 구현 차이, 예를 들어 GA4 이벤트 파라미터 제한이나 Mixpanel identity merge 같은 현실적 제약이 없다.; 전환율 계산 기준을 지적하지만 실제 기본 산식, 관측 윈도우, 중복 이벤트 처리 기본값을 제안하지 않아 작업자 판단 부담이 남는다.; 예시가 없어서 스킬 심사 기준인 현실적 예시 측면이 약하다.; 초반의 흡수/병합 판단 문구가 많아 실제 퍼널 분석 스킬보다 카탈로그 운영 메타 지침처럼 보이는 부분이 있다.'
    action: review
    path: 40_Skills/candidate/x-analytics-03.md
    ecosystem: 'partial:sprint-web'
  - id: x-analytics-04
    name: 코호트 분석
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-02(retention, ARPU, churn 같은 핵심 지표를 코호트 축으로 쪼개 해석하므로 목표·대시보드 스킬과 지표 정의 영역이 맞닿는다.); x-analytics-03(가입, 튜토리얼, 결제 전환을 시간/코호트별로 비교하므로 퍼널 이탈 분석의 결과 지표와 연결된다.); x-analytics-05(Metabase·Amplitude로 재현 가능한 분석 테이블을 만들고 운영 관찰에 넘기는 흐름이 겹친다.); x-analytics-07(채널·캠페인별 신규 사용자 잔존 비교가 마케팅 효율 판단의 입력 자료가 된다.); x-analytics-08(로그 누락, 클라이언트 이벤트 신뢰성, 서버 원장과의 정합성 확인이 코호트 집계 검증에 필요하다.); x-analytics-09(raw user_id/PII 제외, 소표본 마스킹 등 개인정보 보호 전제가 분석 수행 과정에 포함된다.); x-monetization-05(코호트별 누적 ARPU/LTV 곡선을 산출해 CAC 회수 판단으로 넘기는 경계가 있다.); x-release-04(업데이트나 점진 출시 후 코호트별 잔존·전환 변화를 비교해 중단/확대 판단에 쓰일 수 있다.)'
    value: 사용자 품질 평가 (가입일·채널·결제별)
    risk: 'Tier-2 품질 4/5 · 권고 revise · 매우 실전적인 코호트 분석 스킬이지만 exact-day retention과 D0/단조성 검증 규칙이 틀릴 수 있어 수정 후 승격이 적절하다.  리스크: exact-day retention은 날짜별 재방문율이므로 단조 감소가 보장되지 않는다. 단조성 검사는 rolling retention 또는 cumulative conversion/매출에서만 조건을 바꿔 적용해야 한다.; D0=100% 검증은 outcome_event가 cohort_event와 동일하거나 D0 행을 분모로 별도 생성할 때만 맞다. signup 코호트에 app_open outcome을 쓰면 D0가 100%가 아닐 수 있다.; SQL 문법이 BigQuery, Postgres, Snowflake 사이에서 호환되지 않는다. DATE_DIFF와 AT TIME ZONE 사용 예시의 대상 DB를 명시하거나 DB별 변형이 필요하다.; 우측 검열을 설명하지만 표준 SQL에는 미성숙 셀을 빈칸 처리하는 조건이 직접 구현되어 있지 않다.; 전환율, 누적매출, 잔존율을 같은 검증 규칙으로 다루면 오류가 난다. 전환/누적매출은 시간이 지나며 증가할 수 있다.; 코호트 크기 <100 기준은 실무적 가이드로는 좋지만 통계적 유의성 판단으로 오해될 수 있다. 신뢰구간이나 최소 검출 효과를 별도 안내하면 더 안전하다.'
    action: review
    path: 40_Skills/candidate/x-analytics-04.md
    ecosystem: 'partial:sprint-web'
  - id: x-analytics-05
    name: 대시보드 제작
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-01(이벤트 이름과 속성을 전제로 Amplitude 차트와 퍼널을 구성하므로 로그 설계와 접점이 있다.); x-analytics-02(DAU, 리텐션, ARPDAU 등 핵심 지표 정의를 입력으로 받아 대시보드에 배치한다.); x-analytics-03(설치→튜토리얼→첫결제 퍼널과 drop-off를 상시 뷰로 고정한다.); x-analytics-04(채널·코호트·사용자 품질 세그먼트를 필터와 비교 기준으로 다룬다.); x-analytics-07(유입 채널별 신규 가입과 광고 유입 필터 등 마케팅 효율 지표를 화면에 포함한다.); x-analytics-08(Amplitude와 Metabase의 동일 지표 오차 검증을 신뢰성 게이트로 호출한다.); x-marketing-07(설치단가·전환 개선에 쓰이는 채널/캠페인 성과 지표가 대시보드 입력으로 들어올 수 있다.); x-monetization-05(매출, ARPDAU, 결제 전환율 등 수익성 판단 지표를 운영 타일로 구성한다.); x-platform-07(크래시율, 에러 Top 5, 알림 등 운영 관측과 장애 탐지 성격의 타일이 포함된다.)'
    value: 매일 상태 보기 (Metabase·Amplitude)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 대시보드 제작 역할에 매우 잘 맞는 구체적이고 실행 가능한 스킬이므로 승격 권고.  리스크: Amplitude와 Metabase를 전제로 하므로 다른 분석 스택을 쓰는 팀은 절차 변환이 필요하다.; SQL 예시가 PostgreSQL 문법(date_trunc, INTERVAL)에 가깝기 때문에 BigQuery, MySQL, SQLite 등에서는 그대로 동작하지 않을 수 있다.; `app_install`, `session_start`, `purchase` 같은 이벤트명이 예시로 고정되어 있어 실제 스키마와 매핑하지 않으면 잘못된 차트를 만들 수 있다.; DAU 오차 ≤ 3%, D1 리텐션 < 25%, 매출 -30% 같은 기준은 제품 규모와 변동성에 따라 조정 전제가 필요하다.; 개인정보, 권한 관리, 외부 공유 시 익명화·접근통제에 대한 언급이 약하다.; 일배치/실시간 갱신 주기에 따른 지연, 타임존, 환불/취소 매출 반영 같은 운영 회계 세부 전제가 추가되면 더 안전하다.'
    action: review
    path: 40_Skills/candidate/x-analytics-05.md
    ecosystem: 'partial:sprint-web'
  - id: x-analytics-06
    name: A/B 테스트 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-01(실험 지표 측정을 위해 exposure 이벤트와 primary/guardrail 이벤트 목록을 요구하므로 로그 설계와 접점이 있다.); x-analytics-02(primary 지표와 guardrail, DAU·retention·ARPU 같은 KPI 정의를 실험 판정에 사용한다.); x-analytics-03(온보딩·결제 전환 같은 이탈 구간 개선안을 A/B 테스트 대상으로 삼을 수 있다.); x-analytics-08(SRM, 배정/로그 버그, 데이터 품질 이상 시 판정 중단 규칙이 데이터 검증 영역과 맞닿아 있다.); x-monetization-01(가격 변경 실험을 설계할 수 있어 가격 전략 검증과 영역이 만난다.); x-monetization-03(결제 노출 위치·타이밍 변경을 실험 대상으로 삼을 수 있다.); x-liveops-01(출석·보상·시즌 등 리텐션 개선 운영안을 실험으로 검증할 수 있다.); x-liveops-02(운영값 조정의 효과를 실험군/대조군으로 검증하는 상황과 겹친다.); x-release-04(코호트·canary·중단 기준 등 점진 배포와 실험 배정/중단 규칙이 접점이 있다.); x-platform-08(feature flag나 canary 인프라를 통해 실험 배정과 롤백을 구현할 수 있다.); x-marketing-03(스토어 스크린샷·미리보기 영상 등 설치 전환 개선안을 A/B 테스트 관점으로 평가할 수 있다.); x-marketing-07(광고 소재·CTA·썸네일 전환 개선 실험과 방법론이 겹친다.)'
    value: UI·가격·보상·온보딩 검증
    risk: 'Tier-2 품질 5/5 · 권고 promote · 사전등록·표본수·배정·판정 규칙이 숫자로 고정된, 1인 개발자에게 매우 실용적인 A/B 테스트 설계 스킬이다.  리스크: 베이지안 판정에서 사용할 사전분포, 모델, 계산 도구가 명시되지 않아 실행자가 임의로 해석할 수 있다.; 순차 테스트를 대안으로 언급하지만 구체적인 중단 경계나 알파 소비 방식은 제공하지 않는다.; 빈도주의 판정의 ''CI가 0을 포함하지 않고 MDE 이상'' 표현은 하한이 MDE를 넘는지, 관측 효과가 MDE 이상이면 되는지 모호할 수 있다.; DAU 기준표는 실무 휴리스틱으로 유용하지만 전환율, 진입률, 실험 eligible 비율에 따라 필요한 표본이 크게 달라질 수 있다.; guardrail 여러 개를 둘 때 각 guardrail의 검정력·노이즈·판정 기준이 부족하면 과도한 기각 또는 무시가 발생할 수 있다.; uid 배정 기본값은 로그인 전 퍼널이나 멀티디바이스 환경에서는 별도 식별 전략이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-analytics-06.md
    ecosystem: 'partial:sprint-web'
  - id: x-analytics-07
    name: 어트리뷰션 분석
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-01(install/signup/purchase 이벤트와 campaign_id, click_id, consent_state 같은 분석 로그 스키마 정의가 겹친다.); x-analytics-04(채널별 가입, 결제, ROAS로 유저 품질과 수익성을 비교하는 부분이 일부 겹친다.); x-analytics-08(광고 플랫폼, 스토어, MMP, 서버 원장 간 수치 불일치를 대조하고 원인을 찾는 절차가 겹친다.); x-analytics-09(ATT, 쿠키 동의, consent_state별 집계와 개인정보 기반 추적 제한 대응이 겹친다.); x-compliance-02(GDPR, 쿠키, 앱 추적 권한과 관련된 동의 상태 처리 및 추적 제한 전제가 겹친다.); x-marketing-06(유입 캠페인의 성과 판단과 채널별 예산 조정 근거를 제공하는 영역이 맞닿아 있다.); x-marketing-07(설치단가와 전환 개선 판단에 필요한 CPI/CAC/ROAS 분석이 겹친다.); x-monetization-05(CAC, LTV, ROAS를 이용해 유료 획득이 경제적으로 성립하는지 판단하는 부분이 겹친다.); klv:gtm(채널별 scale/hold/kill 판단과 유통 경로 의사결정에 필요한 근거 산출이 겹친다.); x-server-02(서버 이벤트 원장과 결제·이벤트 엔티티 설계 전제가 일부 겹친다.); x-server-12(서버 원장 기반 데이터 품질 검증과 이벤트 정합성 확인이 겹친다.)'
    value: 마케팅 효율 판단 (광고·스토어·바이럴)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 어트리뷰션 수치를 검증하고 채널별 scale/kill 근거를 만들기에 충분히 구체적인 고품질 스킬이다.  리스크: 서버 원장을 단일 진실로 두는 접근은 합리적이지만, 서버 자체의 first_open 누락이나 이벤트 중복 제거 실패가 있으면 기준값이 틀릴 수 있다.; 식별자 부재율 30%, 소스 차이 10%·25%, D7/D30 ROAS 임계값은 기본값으로는 유용하지만 업종, 가격 모델, 결제 지연, 표본 크기에 따라 조정이 필요하다.; SKAN과 ATT 설명이 실무 방향으로는 맞지만, SKAN 버전별 conversion value·coarse value·postback 지연 차이를 다루지 않아 iOS 캠페인에서는 추가 세부 설계가 필요할 수 있다.; geo-holdout은 소규모 1인 서비스에서 트래픽 편향, 지역별 채널 믹스 차이, 계절성 때문에 통계력이 부족할 수 있다.; click_id, device_id, 해시 식별자 사용은 개인정보·플랫폼 정책 검토가 필요하며, 동의 없이 수집 가능한 범위를 별도로 확인해야 한다.; organic 누락분을 유료 채널에 비례 재배분하는 예시는 실용적이지만, 실제로는 채널별 추적 누락률이 다를 수 있어 보정 방식의 가정이 결과를 크게 바꿀 수 있다.'
    action: review
    path: 40_Skills/candidate/x-analytics-07.md
    ecosystem: 'partial:signalcraft'
  - id: x-analytics-08
    name: 데이터 검증 쿼리
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-02(이미 있는 지표와 대시보드 수치의 신뢰성을 검증하므로 대시보드 설계·지표 정의와 맞닿아 있다.); x-analytics-05(매일 상태 보기에서 발견한 이상 지표를 후속으로 깊게 파는 검증 흐름과 연결된다.); x-analytics-06(실험 결과 판단 전에 원천 이벤트와 서버 데이터가 맞는지 확인해야 하는 경우가 있어 데이터 신뢰성 영역이 겹친다.); x-analytics-09(삭제·탈퇴 사용자를 검증 쿼리에서 양쪽 모두 제외하는 규칙이 개인정보·삭제 처리 원칙과 직접 연결된다.); x-server-12(서버 변경 이후 데이터 품질 회귀를 확인할 때 클라 로그와 서버 원장 대조 방식이 겹친다.); x-server-09(결제·정산 데이터의 멱등성, transaction_id, captured/refunded 상태 검증이 유료화 서버 데이터 설계와 겹친다.); x-liveops-07(데이터 오류나 장애로 운영 대응이 필요할 때 원인 판정과 사후보고의 근거 자료가 된다.); x-platform-10(핵심 플로우 자동 검증에서 결제·가입 등 주요 데이터의 자동 정합성 체크로 확장될 수 있다.)'
    value: 지표 이상할 때 (클라로그 vs 서버원장)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 쿼리로 데이터 불일치 원인을 재현 가능하게 판정하는 고품질 분석 검증 스킬이다.  리스크: 예시 SQL의 `event_time AT TIME ZONE` 동작은 컬럼 타입이 `timestamp`인지 `timestamptz`인지에 따라 결과가 달라질 수 있어 실제 DB 타입 확인이 필요하다.; `WHERE user_id NOT IN (deleted_users)` 같은 표현은 NULL 포함 시 오동작할 수 있으므로 실제 구현에서는 `NOT EXISTS`나 명시적 조인이 더 안전하다.; Amplitude/Firebase export 스키마는 도구·버전마다 시간 컬럼과 수집 시간 컬럼명이 달라 그대로 복붙하면 실패할 수 있다.; 클라 로그와 서버 원장을 직접 조인하려면 개인정보·권한·데이터 보존 정책상 접근 가능한 환경인지가 전제되어야 한다.; 허용 오차 기본값은 유용하지만 서비스 규모, 이벤트 중요도, 수집 파이프라인 특성에 따라 별도 보정이 필요할 수 있다.; 서버 원장을 SoT로 둔다고 해도 원장 자체의 누락·중복 가능성을 검증하는 감사 로그나 결제 PG 대조 절차는 별도로 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-analytics-08.md
    ecosystem: 'partial:sprint-web'
  - id: x-analytics-09
    name: 프라이버시 준수 분석
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-01(분석 이벤트와 속성 설계 단계에서 개인정보 등급 분류와 수집 가능 여부 판단이 맞물린다.); x-compliance-01(처리방침 고지 항목과 개인정보 처리 목적·항목 표기가 연결된다.); x-compliance-02(GDPR, 쿠키, ATT, Consent Mode, 광고식별자 동의 판단과 직접 맞닿는다.); x-compliance-03(App Privacy, Google Play Data safety 등 스토어 개인정보 라벨 제출 전 점검과 관련된다.); x-compliance-05(COPPA, 미성년 데이터, 아동 대상 서비스 여부 판단과 일부 겹친다.); x-compliance-06(DSAR 삭제·열람 요청 대응을 위해 분석 도구와 자체 DB의 삭제 위치를 매핑한다.); x-platform-05(PII 보호, 최소권한, 개인정보 접근 통제와 운영 보안 관점에서 연결된다.); x-server-11(탈퇴, PII 익명화, 규정 준수형 데이터 보존·삭제 설계와 겹친다.); x-release-01(출시 전 정책·QA 통합 점검에서 개인정보 라벨, 동의 흐름, 분석 SDK 설정 확인이 포함될 수 있다.); x-release-03(스토어 심사 정책 대응과 개인정보·추적 관련 리젝 예방에 연결된다.)'
    value: 개인정보 규정+분석 (동의·익명화·삭제)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 분석 데이터 레이어에서 개인정보 준수를 검증 가능한 산출물로 만드는 매우 구체적이고 실무성이 높은 스킬이다.  리스크: 법령과 도구 설정은 자주 바뀌므로 GA4, Firebase, Amplitude, Mixpanel, PostHog의 구체 메뉴·API·기본값은 실행 시점의 공식 문서로 재확인해야 한다.; 동의 거부 시 분석 도메인 요청 0건 기준은 일부 Consent Mode 구현이나 필수 진단 로그가 있는 환경에서는 과도하거나 도구 정책과 충돌할 수 있어 예외 기준을 명시해야 한다.; P0/P1/P2/P3 분류는 실무에 유용하지만 법적 정의와 1:1로 대응하지 않으므로 등급명을 법적 결론처럼 사용하면 위험하다.; 결제 상세, 미성년 여부, 위치정보 등 민감정보 예시는 국가별 법적 민감정보 범주와 차이가 있을 수 있어 지역별 확인이 필요하다.; DSAR 삭제 검증에서 ''30일 내 소멸'' 같은 기준은 규정·도구·계약에 따라 달라질 수 있으므로 프로젝트별 SLA로 확정해야 한다.'
    action: review
    path: 40_Skills/candidate/x-analytics-09.md
    ecosystem: 'partial:sprint-web'
  - id: x-compliance-01
    name: 약관·개인정보처리방침 작성
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-09(분석 SDK, 동의, 익명화, 삭제 요청 등 개인정보 규정과 분석 데이터 운용 영역이 겹친다.); x-compliance-02(GDPR, 쿠키, 앱 추적 권한, 동의 UI와 개인정보 고지 영역이 직접 겹친다.); x-compliance-03(Apple/Google 스토어 심사에서 개인정보처리방침 URL, Privacy Label, Data Safety 불일치 방지와 겹친다.); x-compliance-05(아동 데이터, 연령 제한, COPPA 및 만 14세 미만 처리 판단이 겹친다.); x-compliance-06(열람·삭제·이동권 등 정보주체 권리 고지와 처리 프로세스가 겹친다.); x-monetization-04(구독·환불 규칙과 결제 고지가 이용약관 작성 항목과 겹친다.); x-release-03(출시 메타데이터, 심사 정책 대응, 리젝 예방 과정에서 약관·개인정보 문서 확인이 겹친다.); x-release-01(배포 전 정책·QA 통합 체크리스트 중 개인정보방침과 약관 준비가 겹친다.); x-server-11(PII 익명화, 탈퇴, 규정 준수와 개인정보 보유·파기 항목이 겹친다.)'
    value: ToS·Privacy Policy가 필요할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 실무 절차와 게이트가 매우 구체적인 고품질 스킬이며, 일부 법적 조건부 표현만 보강하면 바로 카탈로그에 올릴 만하다.  리스크: 법령·스토어 정책은 자주 바뀌므로 참고 문헌과 체크리스트의 최신성 확인 절차가 별도로 필요하다.; 미국 CCPA/CPRA는 사업 규모·매출·처리 건수 등 적용 요건이 있어 ''미국 포함''만으로 일괄 적용하면 과고지 또는 잘못된 설계가 될 수 있다.; GDPR의 DPO나 EU 대표 연락처는 모든 서비스에 필수는 아니므로 조건부 항목으로 표시하는 편이 더 정확하다.; ''YES 0개면 출시 가능'' 표현은 법률 검토 없이 안전하다는 인상을 줄 수 있어 ''표준 리스크 기준 자가 초안 가능'' 정도로 완화하는 것이 좋다.; 한국 위치정보, 통신판매업, 개인정보 국외이전 고지는 서비스 구조와 사업자 상태에 따라 세부 의무가 달라질 수 있다.'
    action: review
    path: 40_Skills/candidate/x-compliance-01.md
    ecosystem: 'partial:deep-research'
  - id: x-compliance-02
    name: 동의·추적 고지
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-09(분석 SDK, 익명화·삭제·동의 근거 등 개인정보 규정과 분석 데이터 처리 영역이 만난다.); x-compliance-01(Privacy Policy에 고지해야 할 수집 항목과 처리 근거를 제공하므로 정책 문서 작성과 연결된다.); x-compliance-03(Apple Privacy Label, Google Play Data Safety, 심사 리젝 예방을 위한 데이터 수집 근거와 겹친다.); x-release-03(스토어 메타데이터·정책 대응에서 필요한 데이터 안전 폼과 개인정보 라벨 입력 근거를 제공한다.); x-compliance-06(동의 철회, 삭제 요청 경로, 데이터 주체 권리 처리 흐름 일부와 맞닿아 있다.); x-server-11(PII 익명화, 탈퇴, 규정 준수 관점에서 서버 로그·식별자 보관과 연결된다.); x-platform-05(PII 보호와 최소권한 관점에서 동의 기록 및 식별 가능 데이터 처리와 관련된다.)'
    value: GDPR·쿠키·앱 추적 권한을 처리할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 추적 동의 실무를 인벤토리부터 UX·기록·검증까지 연결하는 고품질 출시 전 체크 스킬이다.  리스크: 법률·규제 설명이 실무용으로 단순화되어 있어 국가별 세부 예외나 최신 해석을 그대로 대체하면 위험하다.; EU 분석 SDK에 대해 보수적으로 동의 필수를 기본값으로 두는 접근은 안전하지만, 제품에 따라 불필요한 동의 장벽이나 데이터 손실을 만들 수 있다.; Crashlytics 같은 안정성 도구를 동의 뒤로 미루면 초기 크래시 관측이 약해질 수 있어 SDK별 비식별 설정과 필수성 판단이 추가로 필요하다.; 지역 판별을 어떻게 할지, 사용자가 VPN·여행·미확인 지역일 때 어떤 기본값을 쓸지에 대한 운영 기준이 부족하다.; 동의 기록의 user_or_device_id 자체가 개인정보 또는 식별자로 취급될 수 있으므로 보관 기간, 암호화, 접근권한, 삭제 정책이 별도 정의되어야 한다.; SDK별 예시 플래그나 플랫폼 정책은 자주 바뀌므로 구현 단계에서 최신 공식 문서 확인이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-compliance-02.md
    ecosystem: 'partial:sprint-web'
  - id: x-compliance-03
    name: 스토어 정책 사전 검토
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-compliance-01(개인정보처리방침·약관 필요 여부와 App Privacy/Data safety 선언 검토가 맞닿아 있다.); x-compliance-02(ATT, 추적, GDPR, 쿠키·동의 처리와 스토어 개인정보 심사 항목이 겹친다.); x-compliance-05(연령 등급, 아동 대상, Families 정책, 결제 제한 검토가 겹친다.); x-marketing-01(스토어 등록 전 이름·카테고리·키워드·스크린샷 카피가 정책 위반인지 확인하는 지점이 겹친다.); x-marketing-04(출시 직전 심사·가격·지역 설정 확인과 제출 전 정책 게이트가 겹친다.); x-release-01(빌드·QA·자산·정책을 통합 제출 체크리스트로 점검하는 흐름과 겹친다.); x-release-03(메타데이터·심사·정책 대응 및 리젝 대응 영역과 가장 직접적으로 겹친다.); x-platform-10(핵심 플로우 자동 검증과 C1 스모크 테스트·로그인 통과 확인이 일부 맞닿아 있다.); x-platform-12(배포 전 자동 통과 기준과 제출 금지 게이트를 세우는 관점이 겹친다.); x-monetization-02(구독 티어·IAP 구성과 스토어 결제·구독 고지 요건 확인이 겹친다.); x-monetization-03(결제 노출 위치와 외부결제 유도·스토어 결제 준수 검토가 겹친다.)'
    value: 앱스토어·플레이 심사 리젝을 예방할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 제출 직전 스토어 리젝을 줄이기 위한 실전형 게이트로 절차·증거·분기·출력까지 매우 잘 갖춘 스킬이다.  리스크: Apple·Google 정책은 지역, 앱 카테고리, 시행일, 예외 프로그램에 따라 자주 바뀌므로 문서의 특정 조항 번호나 요건 예시는 항상 최신 공식 문서 확인이 필요하다.; 외부결제 유도 규칙을 ''미국 외''처럼 단순화한 부분은 지역별 법원 판결·entitlement·스토어 정책 변경에 따라 틀릴 수 있다.; UGC의 ''24h 내 대응 약속''처럼 운영 SLA를 명시하면 실제 운영 능력이 부족한 1인 개발자에게 과도한 약속이 될 수 있다.; 건강·의료, 금융·암호화폐, 아동 대상 앱은 스토어 심사 이전에 법적·자격·라이선스 리스크가 커서 셀프체크만으로 출시 판단을 내리면 위험하다.; SDK 수집 데이터 대조는 SDK 문서와 실제 네트워크 동작이 다를 수 있어, 고위험 앱은 런타임 점검이나 벤더 확인까지 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-compliance-03.md
    ecosystem: 'delegate:sprint-app'
  - id: x-compliance-04
    name: 라이선스·저작권 검토
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-compliance-01(ToS·Privacy Policy에서 UGC 사용권, 제3자 콘텐츠 사용 조항과 맞물린다.); x-compliance-03(앱스토어·플레이 심사에서 제3자 IP·저작권 증빙 요구와 연결된다.); x-release-01(출시 전 통합 체크리스트의 자산·정책 게이트와 직접 연결된다.); x-release-03(메타데이터·심사·정책 대응 중 저작권 리젝 대응과 겹친다.); x-platform-06(OSS 패키지 검토 과정에서 SCA, CVE, 라이선스 스캔 입력이 일부 공유된다.); x-platform-12(배포 전 자동 통과 기준에 보류 자산 차단, 라이선스 파일 존재 검사를 넣을 수 있다.)'
    value: 에셋·폰트·OSS 라이선스를 확인할 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 실무성이 높고 바로 쓸 수 있는 고품질 스킬이며, 몇몇 법적 단정 표현만 보수적으로 다듬으면 된다.  리스크: GPL/LGPL/MPL의 결합·링크·배포 의무는 언어·플랫폼·배포 방식에 따라 달라 단순 표만으로 최종 판단하면 위험하다.; CC BY-SA가 게임 전체에 전염된다는 표현은 상황별로 다툼이 있어 ''위험 가능성''으로 낮춰 쓰는 편이 안전하다.; Pixabay 등 무료 음원 사이트는 현재 약관이 CC0가 아닐 수 있으므로 예시가 사용자를 오도할 수 있다.; 증거를 repo에 저장하라는 지침은 공개 저장소에서 영수증·계정정보·구매내역 노출 위험이 있어 private 저장소 또는 접근제어 전제가 필요하다.; AI 생성물의 상업 이용권과 저작권 귀속, 학습데이터 침해 위험은 관할·모델 약관별 차이가 커 핵심 브랜드 자산에는 별도 검토 기준이 더 필요하다.; NOTICE와 attribution 문구의 실제 요구 형식은 라이선스·벤더 약관별로 달라 자동 생성만으로 충분하지 않을 수 있다.'
    action: review
    path: 40_Skills/candidate/x-compliance-04.md
    ecosystem: 'partial:deep-research'
  - id: x-compliance-05
    name: 연령·청소년 보호
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-compliance-01(약관·개인정보처리방침에 미성년자 동의, 보호자 동의, 수집 항목 고지가 반영되어야 한다.); x-compliance-02(GDPR, 쿠키, ATT, 광고 추적, 동의 관리와 아동 데이터 처리 기준이 맞닿아 있다.); x-compliance-03(스토어 연령 등급, 앱 심사, 정책 리젝 예방과 연령 게이트·확률형·광고 정책이 연결된다.); x-compliance-06(아동 또는 보호자의 삭제·열람·동의 철회 요청 처리와 후속 데이터 권리 절차가 이어진다.); x-analytics-09(분석 SDK의 개인정보 수집, 익명화, 동의, 미성년자 추적 제한과 직접 겹친다.); x-monetization-04(미성년 결제 한도, 환불, IAP 정책, 보호자 동의가 가격·환불 규칙과 연결된다.); x-monetization-06(확률형 상품, 사행성, 미성년 과금 제한, 페이투윈 위험 판단과 관련된다.); x-release-01(출시 전 QA·정책·자산 체크리스트에 연령 보호 검증 항목이 들어간다.); x-release-03(메타데이터, 심사 대응, 정책 리젝 방지에서 연령 등급·아동 보호 설정을 다룬다.); x-platform-05(미성년자 PII, 관리자 접근, 최소권한, 민감 데이터 보호 통제가 연결된다.); x-server-11(PII 익명화, 탈퇴, 규정 준수, 데이터 보존 정책과 아동 데이터 처리 제한이 맞닿아 있다.)'
    value: 등급·아동 데이터·결제 제한이 필요할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실무성이 높은 강한 초안이지만, 법령·지역·SDK 기준의 최신성 검증과 단정 표현 보정이 필요하다.  리스크: 법령·플랫폼 정책·SDK API는 자주 바뀌므로 각 항목에 확인일과 공식 URL을 강제하지 않으면 오래된 기준으로 구현할 위험이 있다.; EU GDPR 동의 연령은 회원국별로 다르므로 EU/EEA를 단일 16세 기준으로만 처리하면 지역별 예외를 놓칠 수 있다.; 일본의 청소년 과금 한도나 가챠 규제는 법령, 업계 가이드라인, 플랫폼 정책이 섞여 있어 단정적으로 쓰면 오해가 생길 수 있다.; 한국의 청소년보호법, 개인정보보호법, 게임산업법 의무가 기능별로 다르게 적용되므로 ‘본인확인’이나 ‘법정대리인 동의’ 필요성을 구체 사안 없이 확정하면 과잉 또는 과소 준수 위험이 있다.; 연령 게이트 재시도 차단은 개인정보 최소화, 계정 복구, 가족 공유 기기 상황과 충돌할 수 있어 설계상 예외 처리가 필요하다.; 광고 SDK의 아동 모드 플래그 이름과 의미가 SDK 버전별로 달라질 수 있어 예시 코드를 그대로 적용하면 잘못 설정될 수 있다.; COPPA VPC, 성인 본인인증, 확률형 사행성 판단은 자체 체크리스트만으로 충분하지 않으며 실제 출시 전 법무 또는 전문 대행 검토가 필요하다.'
    action: review
    path: 40_Skills/candidate/x-compliance-05.md
    ecosystem: 'partial:sprint-app'
  - id: x-compliance-06
    name: 데이터 삭제·열람 요청 대응
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-09(분석 이벤트의 익명화·삭제 요청 전파, GA4/Firebase 사용자 삭제와 개인정보 규정 대응 영역이 겹친다.); x-compliance-01(개인정보 처리방침과 DSAR 권리 안내·보존 근거가 연결된다.); x-compliance-02(GDPR·쿠키·추적 동의와 이용자 개인정보 권리 행사 대응이 같은 규정 체계 안에 있다.); x-compliance-05(미성년자·아동 데이터 요청 처리와 법정대리인 확인 기준이 겹친다.); x-liveops-05(사용자 지원 요청 접수, 계정 조회, 응대 흐름과 DSAR 요청 처리 채널이 겹친다.); x-liveops-10(셀프서비스 지원 폼이 DSAR 접수·본인확인·상태 안내의 입력 경로가 될 수 있다.); x-liveops-11(사용자 문제를 접수부터 종결까지 추적하고 회신하는 운영 흐름이 DSAR 대장·종결 절차와 겹친다.); x-liveops-12(거부·일부 거부·추가 확인 요청 등 표준 응대 문구와 기준 수립이 필요하다.); x-platform-05(PII 보호, 최소권한, 관리자 접근 통제는 DSAR 처리 중 데이터 열람·삭제 권한 관리와 연결된다.); x-server-11(서버 측 PII 익명화·탈퇴·백업·복원 시 재삭제 같은 구현 영역과 직접 맞닿아 있다.); x-server-02(유저·주문·결제·이벤트 엔티티 설계가 데이터 위치 지도와 보존 매트릭스 작성의 기반이 된다.)'
    value: 탈퇴·열람·이동권을 처리할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · DSAR 요청을 1인 개발자가 감사 가능하게 처리하도록 만드는 고품질 운영 스킬이다.  리스크: 관할권별 기한 표가 실무 출발점으로는 유용하지만, 실제 적용 범위와 예외가 복잡하므로 사용자가 표만 믿고 최신 법령 확인을 생략할 위험이 있다.; 한국·EU·캘리포니아 외 지역 이용자에 대한 기준은 ''가장 엄격한 기준''으로 단순화되어 있어, 실제 현지 법상 추가 권리나 형식 요건을 놓칠 수 있다.; 본인확인 기준이 서비스 위험도에 따라 조정되어야 하는데, 고위험 서비스에서는 제시된 최소 확인만으로 부족할 수 있다.; Stripe·Google·Apple·Sentry·Mailgun 등 처리자별 삭제 가능 범위와 API 명칭·동작은 변동될 수 있어 매번 공급자 문서 확인이 필요하다.; 열람 산출물 생성 시 내부 식별자, 보안 토큰, 제3자 정보가 섞이지 않도록 별도 리뷰가 필요하지만 자동 검증 방법은 구체화되어 있지 않다.'
    action: review
    path: 40_Skills/candidate/x-compliance-06.md
    ecosystem: 'partial:sprint-web'
  - id: x-liveops-01
    name: 운영 이벤트 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-02(이벤트 성과 지표, 목표값, 대시보드 전달 범위가 겹친다.); x-analytics-06(UI·가격·보상·온보딩 실험 검증과 이벤트 효과 측정 관점이 겹친다.); x-liveops-02(remote config, 운영값 토글, 이벤트 중단 스위치가 겹친다.); x-liveops-04(이벤트 안내, 세그먼트, 푸시·배너 노출 채널 설계가 겹친다.); x-liveops-05(보상 미수령, 환불 후 보상 등 CS 대응 문구와 처리 기준이 겹친다.); x-liveops-06(수동 지급, 유저 조회, 운영 로그, 보상 회수와 겹친다.); x-liveops-07(장애·데이터 오류 시 이벤트 중단, 보상, 공지 대응과 겹친다.); x-liveops-09(운영 이벤트 일정과 캘린더 충돌 방지 관점이 겹친다.); x-monetization-04(첫구매·시즌·번들·환불 규칙 등 결제형 이벤트 설계와 겹친다.); x-server-05(결제·재화·보상 지급의 원자성, 멱등성, 원장 관리와 겹친다.); x-server-09(유료화 결제의 멱등성·정산 데이터와 결제 이벤트 리스크가 겹친다.); x-server-10(푸시·정산·보상 지급의 큐, 재시도, 중복 처리와 겹친다.); x-compliance-03(앱스토어·플레이 결제, 할인, 심사 정책 확인과 겹친다.); x-compliance-02(푸시 동의, 개인정보 동의 범위, 타겟팅 데이터 사용과 겹친다.); x-platform-08(feature flag, canary, 장애 시 복구와 이벤트 중단 스위치가 겹친다.); x-release-04(코호트, 중단 기준, 점진 출시 판단과 겹친다.)'
    value: 리텐션 올릴 때 (출석·시즌·할인·보상)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 운영 이벤트를 라이브 사고 없이 닫기 위한 스펙 작성 스킬로 매우 구체적이고 실전성이 높아 promote 권고.  리스크: 플랫폼 정책과 환불 윈도우 예시는 시간이 지나면 바뀔 수 있어 실행 시 반드시 최신 공식 문서 확인이 필요하다.; iOS ATT는 광고 추적 권한이고 일반 푸시 알림 권한과는 별도라, 문구가 혼동을 만들 수 있다.; 서버 원장 전제를 강하게 두므로 완전 오프라인 게임이나 서버 없는 제품은 적용 전에 최소 백엔드 또는 운영 대체안을 별도로 정해야 한다.; total_issued 상한 자동 정지는 동시성 처리 없이 구현하면 레이스 컨디션으로 상한을 초과할 수 있다.; 보상 회수 가능 여부는 이미 소비된 재화, 유료 재화와 무료 재화 혼합 원장, 지역별 소비자보호 규정에 따라 더 복잡해질 수 있다.; 대조군이 없을 때 직전 기간 대비로 순증분을 보는 방식은 시즌성·요일 효과에 취약하다.'
    action: review
    path: 40_Skills/candidate/x-liveops-01.md
    ecosystem: 'delegate:sprint-game'
  - id: x-liveops-02
    name: 원격 설정 관리
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-08(feature flag, kill-switch, canary, 롤백 경로와 운영 중 값 전환이라는 영역이 겹친다.); x-release-04(코호트·점진 출시·중단 기준을 통한 변경 확대와 일부 실험값 운영에서 접점이 있다.); x-analytics-06(가격·보상·온보딩 값 변경이 A/B 실험이나 KPI 검증으로 이어질 때 겹친다.); x-platform-05(원격 설정 콘솔 권한, 최소권한, 관리자 기능 보호와 노출 등급 판단이 맞닿아 있다.); x-server-04(클라이언트 조작 차단, 서버 권위 검증, 지급·결제 신뢰 경계 판단과 겹친다.); x-server-08(자체 JSON 엔드포인트, CDN 캐시 TTL, 캐시 퍼지 등 설정 전파와 캐싱 관리가 겹친다.); x-liveops-07(운영 장애 시 공지·보상·사후 대응과 원격 설정 롤백·kill-switch 운용이 연결된다.); x-liveops-09(이벤트 시작 전 publish, 만료일, 운영 일정 충돌 방지와 원격값 변경 일정 관리가 겹친다.)'
    value: 앱 업데이트 없이 운영값 조정
    risk: 'Tier-2 품질 5/5 · 권고 promote · 원격 설정 변경의 실무 위험을 검증 가능한 절차로 잘 묶은 고품질 라이브옵스 스킬이다.  리스크: server-only 원격 설정을 실제로 어떻게 구현할지 백엔드 구조가 없는 프로젝트에서는 전제 확인이 필요하다.; Firebase Remote Config 같은 클라이언트 중심 도구를 server-only로 쓰려면 서버 SDK, 별도 설정 저장소, 접근 제어 방식이 명확해야 한다.; 강제 fetch를 자주 쓰면 클라이언트 성능, 요청량, 플랫폼 제한, 비용 문제가 생길 수 있는데 제한 기준은 더 명시되면 좋다.; 경제값을 client-ok로 둘 때도 서버 권위 검증이 없으면 표시용과 실제 지급값이 어긋나 악용될 수 있다.; 임시값 expires 이후 자동 청소나 만료 알림 절차가 없으면 오래된 운영값이 누적될 수 있다.'
    action: review
    path: 40_Skills/candidate/x-liveops-02.md
    ecosystem: 'partial:sprint-game'
  - id: x-liveops-03
    name: 공지 시스템 운영
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-writer-05(운영 커뮤니케이션 문구와 공지 본문 작성 영역이 맞닿아 있으며, 이 스킬은 문구 산출물을 받아 발송 운영을 결정한다.); x-liveops-04(재방문·이벤트 안내의 세그먼트, 딥링크, 푸시 캠페인 실행과 겹치며, 이 스킬은 채널 배정과 발송 검증 쪽에 초점을 둔다.); x-liveops-07(장애·데이터 오류 시 사용자 공지, 보상, 사후보고 흐름과 긴급 공지 운영이 겹친다.); x-liveops-09(운영 일정 충돌 방지와 예약·만료·빈도 제한·이벤트 기간 관리가 겹친다.); x-compliance-02(GDPR, 마케팅 수신 동의, 추적·권한 판정과 직접적으로 맞닿아 있다.); x-compliance-03(스토어 정책 위반 가능성이 있는 공지, 외부 결제 유도 금지 등 플랫폼 심사 리스크와 겹친다.); x-server-10(푸시 큐, 재시도, 토큰 만료, 전달률 오류 등 발송 인프라 운영과 접점이 있다.); x-release-06(릴리스 변경사항, 알려진 이슈, 운영 인계를 사용자 공지로 배포하는 부분이 겹친다.); x-marketing-06(이메일·푸시·SNS 등 유입 캠페인 채널 운영과 마케팅성 공지 발송 판단이 겹친다.); x-analytics-05(발송 후 전달률, 열람률, CTR, opt-out, CS 증가 등 운영 지표 모니터링과 겹친다.)'
    value: 사용자에게 변경 전달 (앱내공지·점검·노트)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 공지 운영의 분류, 발송, 중단, 롤백, 지표 판정을 실무적으로 연결한 고품질 라이브옵스 스킬이다.  리스크: 법률·플랫폼 정책 수치는 국가와 시점에 따라 바뀔 수 있으므로 실제 발송 전 최신 규정 확인이 필요하다.; 푸시 제목·본문 길이 제한은 OS, SDK, 기기 표시 방식에 따라 달라져 실제 미리보기 테스트가 필요하다.; 전달률 90%, 열람률 60%, opt-out 0.5% 같은 경보선은 초기 기본값으로는 좋지만 제품 규모·장르·채널별 기준선에 맞춰 보정해야 한다.; 서비스 공지와 마케팅 공지의 경계가 실제 법률 해석에서는 더 복잡할 수 있어 애매한 사례는 컴플라이언스 검토가 필요하다.; 1인 개발자 기준으로는 절차가 다소 무거울 수 있어 긴급 장애 상황에서는 최소 필수 게이트와 사후 기록을 분리해 운용해야 한다.'
    action: review
    path: 40_Skills/candidate/x-liveops-03.md
    ecosystem: 'partial:sprint-game'
  - id: x-liveops-04
    name: 푸시 캠페인 구성
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-06(광고·랜딩·이메일·푸시·SNS 유입 캠페인을 다루므로 푸시 캠페인의 목표, 타깃, 성과 판단과 겹친다.); x-liveops-03(앱내공지·점검·노트 등 사용자 커뮤니케이션 흐름과 푸시 알림의 공지성 운영이 겹친다.); x-liveops-08(신규·이탈위험·결제유저 등 생애주기별 개입은 푸시 캠페인의 대표 세그먼트와 트리거 설계와 겹친다.); x-liveops-01(출석·시즌·할인·보상 운영은 푸시 캠페인의 주요 목적과 발송 맥락이 된다.); x-analytics-02(DAU, retention, churn 등 푸시 캠페인의 성과 지표와 대시보드 판단이 겹친다.); x-analytics-06(UI·가격·보상·온보딩 검증과 푸시의 홀드아웃·전환 검증 방식이 겹친다.); x-compliance-02(GDPR, 쿠키, 앱 추적 권한 등 동의와 추적 전제가 푸시 발송 정책 리스크와 겹친다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방은 푸시 권한, 알림 정책, 사용자 신고 위험과 겹친다.); x-server-10(푸시 발송의 큐, 재시도, 토큰 관리, 보상 지급 연계 같은 서버 실행 영역과 겹친다.); x-writer-05(운영 커뮤니케이션 문구 작성과 푸시 메시지 카피, 톤, 공지성 문안이 겹친다.)'
    value: 재방문·이벤트 안내 (세그먼트·딥링크)
    risk: 'Tier-2 품질 4/5 · 권고 promote · 푸시 캠페인 운영에 필요한 핵심 리스크와 검증 항목을 충분히 잡았으나, 템플릿을 푸시 전용으로 더 고정하면 훨씬 강해진다.  리스크: 출력 템플릿이 푸시 전용 구조가 아니라서 실제 사용자가 세그먼트, 제외 조건, 발송 시간, 빈도 제한, 메시지 변형, 딥링크, 홀드아웃을 누락할 수 있다.; 법적 전제는 언급하지만 국가별 전자적 광고 고지, 야간 발송 제한, 수신거부 표시 방식 같은 관할권 차이를 확인하라는 요구가 약하다.; 기술 검증 항목은 많지만 FCM/APNs, Firebase, OneSignal 등 실제 스택별 확인 경로와 실패 로그 예시가 없어 실행자가 도구별로 다시 해석해야 한다.; 성과 지표가 나열되어 있으나 캠페인 목적별 1차 지표와 가드레일 지표를 분리하는 기준이 부족하다.; 실제 예시가 없어 좋은 산출물의 밀도와 구체성을 학습하기 어렵다.'
    action: review
    path: 40_Skills/candidate/x-liveops-04.md
    ecosystem: 'partial:sprint-game'
  - id: x-liveops-05
    name: CS 이슈 triage
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-06(계정조회, 지급, 차단, 보상 실행 전 지시서 작성과 권한·감사로그 기준이 맞닿아 있다.); x-liveops-07(동일 증상 다발, 결제 콜백 장애, 개인정보 노출 등 개별 티켓을 인시던트로 라우팅하는 기준이 겹친다.); x-liveops-10(단순 문의나 FAQ 가능 티켓을 셀프서비스로 디플렉트하는 판단이 포함되어 있다.); x-liveops-11(티켓 접수부터 해결까지의 전체 흐름 중 초기 분류 게이트를 담당해 라이프사이클 앞단과 겹친다.); x-liveops-12(우선순위와 리스크 플래그를 바탕으로 표준 답변 매크로를 선택하게 하므로 응대 기준과 연결된다.); x-compliance-02(GDPR, 개인정보 삭제요청, 앱 추적·동의 같은 개인정보 관련 긴급도 판단과 겹친다.); x-compliance-06(탈퇴·열람·이동권 등 사용자 데이터 요청을 T2로 분류하고 SLA를 정하는 부분이 맞닿아 있다.); x-platform-05(PII 보호, 최소권한, 관리자 조회 감사로그 원칙이 운영 triage 절차에 포함되어 있다.); x-server-05(결제 미지급, 재화 복구, 중복 지급 방지 같은 결제·보상 원자성 문제와 연결된다.)'
    value: 사용자 지원 처리 (분류·계정조회·보상)
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실전성이 높은 CS triage 스킬이지만, 심각도 상향 규칙의 모순과 법·플랫폼 전제 보강이 필요하다.  리스크: 고위험 유형 심각도 자동 상향 규칙과 예시가 모순되어 같은 티켓을 사람마다 P0/P1로 다르게 판단할 수 있다.; GDPR 30일, 구글플레이 48시간 등 기한이 국가·플랫폼·상황별로 달라질 수 있는데 최신 정책 확인 절차가 약하다.; T3 안전/미성년/협박 신고의 대응은 법적·플랫폼 신고 의무가 걸릴 수 있어 1인 개발자가 임의 판단하지 말아야 하는 경계가 더 필요하다.; 본인확인 증거 2개 규칙은 좋지만 어떤 증거가 민감정보인지, 보관/마스킹 기준이 부족하다.; ''기타 금지''는 분류 누락을 줄이지만 새로운 유형을 억지 분류하게 만들어 패턴 발견을 늦출 수 있다.; 감사 로그 OFF면 조회 보류 원칙은 타당하나 P0 결제/안전 상황에서 대체 임시 기록 절차가 없다.'
    action: review
    path: 40_Skills/candidate/x-liveops-05.md
    ecosystem: 'partial:official-mcp'
  - id: x-liveops-06
    name: 운영툴 어드민 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-02(원격 설정값 변경 자체는 해당 스킬 영역이고, 이 초안은 그 설정을 안전하게 바꾸는 어드민 화면·권한·감사 구조와 겹친다.); x-liveops-05(계정 조회, 보상 지급, 지원 처리 업무를 다루며, 이 초안은 그 업무를 실행하는 어드민 도구 설계와 겹친다.); x-liveops-10(사용자 문제를 운영자가 직접 처리하지 않도록 셀프서비스화하는 흐름과, 운영 처리 도구의 대상 업무가 일부 겹친다.); x-liveops-11(사용자 문제를 추적하고 끝까지 처리하는 운영 흐름에서 계정 조회·상태 변경·로그 확인 도구가 필요해 겹친다.); x-platform-05(최소권한, 관리자 권한 분리, PII 보호 원칙을 어드민 설계에 적용하므로 의미적으로 겹친다.); x-server-03(회원·유료·관리자 데이터 접근 정책과 어드민 권한 경계가 맞닿아 있다.); x-server-05(재화·보상 지급의 원자성, 멱등성, 중복 지급 방지와 직접 연결된다.); x-server-10(보상 지급, 큐, 재시도 같은 운영성 지급 처리와 어드민 액션 설계가 겹친다.); x-analytics-09(PII 접근, 익명화, 삭제·보존 정책을 어드민 조회와 감사 로그에 반영하므로 일부 겹친다.); x-compliance-06(탈퇴, 열람, 삭제 요청 처리와 어드민의 PII 조회·삭제·감사 기록 설계가 연결된다.)'
    value: 수동 운영 (유저검색·지급·차단·로그)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 위험한 수동 운영을 안전한 어드민 도구로 옮기기 위한 고품질 실전 스킬이다.  리스크: 감사 로그의 before/after에 PII나 민감한 결제 정보가 그대로 들어갈 수 있어 로그 자체의 마스킹·암호화·접근통제 기준을 더 명시하면 좋다.; 1인 개발자의 셀프 2단계 승인은 실제 4-eyes 통제가 아니므로 고위험 작업에서는 한계가 있다는 전제가 필요하다.; 어드민 URL 분리와 IP 허용목록만으로는 충분하지 않을 수 있어 CSRF, 세션 고정, 재인증, 권한 변경 감사 같은 웹 보안 항목이 빠질 수 있다.; 되돌리기 경로를 단순 역액션으로 표현했지만 결제·재화 원장에서는 보정 트랜잭션과 회계/정산 영향까지 고려해야 한다.; 보존 기간을 정하라고 하지만 국가·플랫폼·결제사별 법적 보존 요구를 확인해야 한다는 전제가 약하다.'
    action: review
    path: 40_Skills/candidate/x-liveops-06.md
    ecosystem: 'partial:sprint-web'
  - id: x-liveops-07
    name: 장애 커뮤니케이션
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-03(사용자 공지와 운영 변경 전달 채널이 겹치지만, 이 초안은 예정되지 않은 장애 사고 커뮤니케이션에 특화된다.); x-writer-05(운영 커뮤니케이션 문안 작성과 겹치지만, 이 초안은 장애 상황의 구조·금지어·업데이트 주기를 다룬다.); x-liveops-05(사용자 문제 처리와 보상 안내가 일부 겹치지만, 이 초안은 개별 문의가 아니라 장애 공지와 집단 커뮤니케이션 중심이다.); x-liveops-11(사용자 문제를 끝까지 처리하는 흐름과 사후 종결 관점이 겹치지만, 이 초안은 사고 발생 시 공개 커뮤니케이션 운영에 초점이 있다.); x-liveops-12(응대 기준·표준 답변과 문구 템플릿이 겹치지만, 이 초안은 장애 SEV별 공지 템플릿과 법적 표현 가드에 특화된다.); x-release-05(장애 시 롤백·핫픽스 판단 결과를 사용자에게 알리는 부분에서 접점이 있다.); x-platform-07(장애·침해 탐지 이후 인지 시각과 영향 범위가 커뮤니케이션 입력으로 연결된다.); x-platform-08(복구 경로와 상태 업데이트가 맞물리지만, 이 초안은 복구 실행이 아니라 외부 고지에 집중한다.); x-marketing-05(장애 후 평판 회복과 사용자 신뢰 관리 측면에서 겹친다.); x-compliance-01(개인정보·보안 사고 시 정책·법적 고지와 접점이 있다.); x-compliance-02(개인정보 유출 통지와 규제 대응 표현에서 일부 겹친다.)'
    value: 장애·데이터 오류 시 (공지·보상·사후보고)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 장애 중 바로 실행 가능한 수준의 SEV·채널·문안·보상·사후보고 체계를 갖춘 고품질 라이브옵스 스킬이다.  리스크: 개인정보 유출 통지 요건은 국가·서비스 규모·데이터 유형별로 달라질 수 있어, 초안의 국내법 언급만으로 법적 판단을 끝내면 위험하다.; SEV별 초동 마감과 업데이트 주기가 서비스 규모나 사용자 기대치에 따라 과하거나 부족할 수 있으므로 기본값으로만 써야 한다.; 푸시를 SEV1 해결/보상 안내에 제한하는 원칙은 합리적이지만, 안전·금전·계정 접근 문제에서는 초동 푸시가 필요한 경우도 있다.; 보상 기준이 게임·재화형 서비스에 강하게 맞춰져 있어 SaaS, 커머스, 생산성 앱에서는 보상 항목을 바꿔야 한다.; 상태페이지·인앱 배너·Remote Config가 사전에 준비되어 있지 않으면 사고 중 즉시 적용하기 어렵다.'
    action: review
    path: 40_Skills/candidate/x-liveops-07.md
    ecosystem: 'partial:sprint-web'
  - id: x-liveops-08
    name: 리텐션 캠페인 운영
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-01(출석·복귀·첫구매 보상 등 리텐션 캠페인 설계 영역과 맞닿지만, 본 스킬은 발사·측정·중단 운영에 초점을 둔다.); x-liveops-04(재방문·이벤트 안내를 세그먼트와 딥링크로 보내는 운영과 푸시/인앱 개입 영역이 겹친다.); x-liveops-06(수동 지급, 유저 검색, 차단, 로그 확인 등 보상 운영 실무와 연결된다.); x-liveops-09(여러 캠페인의 일정·빈도 충돌 방지와 사용자별 발송 상한 관리가 겹친다.); x-server-10(푸시 발송, 큐, 재시도, 보상 지급 API, 멱등성 구현 전제와 직접 연결된다.); x-server-05(재화·보상 지급의 원자성, 중복지급 방지, 경제 영향 통제와 겹친다.); x-analytics-02(D1/D7/D30 리텐션, opt-out, 오픈율, 비용/복귀유저 같은 지표를 캠페인 판정에 사용한다.); x-analytics-06(홀드아웃, 처치군/대조군, 판정선 등 실험 검증 흐름과 겹친다.); x-analytics-03(어느 생애주기 구간에서 이탈이 발생하는지 분리하고 개입 대상을 정하는 부분이 겹친다.); x-compliance-02(GDPR, ATT, 알림 권한, 마케팅 동의, 동의 철회 반영 같은 개인정보·추적 권한 전제가 겹친다.); x-compliance-03(푸시 광고 동의, 앱스토어·플레이 정책 확인 등 심사 리스크 예방과 연결된다.); x-marketing-06(푸시·이메일·SNS 등 유입/재방문 캠페인 운영과 세그먼트 캠페인 관점이 겹친다.); x-monetization-04(첫구매·시즌·번들·보상 규칙과 결제 유저 복귀 보상 운영이 맞닿는다.)'
    value: 생애주기별 개입 (이탈위험·신규·결제유저)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 운영자가 감으로 보내는 리텐션 캠페인을 세그먼트·안전가드·홀드아웃·중단조건으로 묶는 매우 실전적인 고품질 스킬이다.  리스크: iOS ATT는 추적 권한이고 푸시 수신 권한과는 별도라, 문구상 푸시 대상 조건으로 오해될 수 있다.; 법규·플랫폼 정책 번호와 요건은 변동 가능하므로 실제 발사 전 최신 원문 확인 절차가 필요하다.; 세그먼트별 군당 500명 기준과 3%p 판정선은 간단하고 실용적이지만, 베이스라인 리텐션·효과크기·비용 구조에 따라 과대/과소 판정될 수 있다.; 이탈확정 31일+ 일괄 제외는 스팸 위험을 줄이지만, 장기 휴면 복귀 캠페인을 별도 목적과 강한 동의 기반으로 실험할 여지를 닫을 수 있다.; 다계정 악용 필터로 기기/결제 핑거프린트를 언급하므로 개인정보·플랫폼 정책 검토 없이 구현하면 위험하다.; 야간 광고성 푸시, 마케팅 동의, 동의 만료 처리의 지역별 정의가 서비스 유형에 따라 달라질 수 있다.'
    action: review
    path: 40_Skills/candidate/x-liveops-08.md
    ecosystem: 'partial:sprint-game'
  - id: x-liveops-09
    name: 콘텐츠 캘린더 관리
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-01(이벤트·세일·시즌·보상 같은 운영 콘텐츠 후보를 다루지만, 이 스킬은 콘텐츠 자체가 아니라 시간표 배치와 충돌 해결을 담당한다.); x-liveops-03(공지·점검·패치 전달 일정이 캘린더에 포함되므로 운영 커뮤니케이션 타이밍에서 겹친다.); x-liveops-04(푸시와 재방문 이벤트 안내가 캘린더 슬롯과 충돌 규칙에 포함된다.); x-liveops-07(장애 보상·긴급 공지·사후 대응이 우선순위 규칙의 최상위 요소로 포함된다.); x-marketing-06(광고·푸시·SNS 캠페인의 송출 시점과 운영 캘린더의 타이밍 조율이 겹친다.); x-release-01(빌드·QA·에셋·심사 리드타임을 일정에 반영해야 하므로 출시 체크리스트와 연결된다.); x-release-03(앱 심사 리드타임과 정책 대응 일정이 콘텐츠 게시일 역산에 영향을 준다.); x-analytics-02(콘텐츠별 KPI와 회고 기준을 정의해 다음 캘린더에 반영하는 부분이 목표·대시보드와 맞닿는다.); x-monetization-03(세일과 시즌 시작의 결제 노출 타이밍을 조정하는 부분이 결제 노출 위치·시점 판단과 겹친다.)'
    value: 운영 일정 충돌 방지
    risk: 'Tier-2 품질 5/5 · 권고 promote · 실제 운영 캘린더를 만들고 충돌을 해결하는 데 바로 쓸 수 있는 고품질 라이브옵스 시간표 스킬이다.  리스크: 리드타임을 단순 합산하는 규칙은 병렬 가능한 작업과 순차 의존 작업을 구분하지 않으면 일정이 과도하게 보수적이거나 반대로 빡빡해질 수 있다.; 세일과 시즌 시작을 같은 주에 두지 않는 규칙은 장르·BM·이벤트 구조에 따라 예외가 있을 수 있으므로 프로젝트별 근거 지표로 보정해야 한다.; iOS 심사 7일 버퍼는 안전한 기본값이지만 실제 플랫폼·국가·심사 유형별 변동성이 커서 최신 정책과 경험치를 반영해야 한다.; 주당 메인 2개 제한은 1인 운영 기준으로 적절하나, 자동화 수준이 높거나 라이브옵스 규모가 큰 프로젝트에서는 슬롯 정의를 조정해야 한다.; 회고 KPI가 일부 콘텐츠 유형에 치우쳐 있어 공지·점검·보상 콘텐츠의 신뢰 회복 지표나 CS 지표가 추가되면 더 완성도가 높아진다.'
    action: review
    path: 40_Skills/candidate/x-liveops-09.md
    ecosystem: 'partial:sprint-game'
  - id: x-liveops-10
    name: 헬프센터·FAQ 구축
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-12(표준 답변을 공개 FAQ 문서의 원재료로 활용하므로 상담 답변 체계와 직접 연결된다.); x-liveops-11(사용자 문제 해결 흐름 중 셀프서비스로 문의를 줄이는 첫 관문을 설계한다.); x-liveops-05(반복 문의 분류, 지원 채널, 문의 감소라는 사용자 지원 처리 영역과 맞닿아 있다.); x-analytics-05(FAQ 조회, 검색, 문의 전환 이벤트와 자기해결률·무결과율 같은 운영 지표를 정의한다.); x-analytics-01(faq_view, faq_search, faq_to_contact 같은 분석 이벤트 설계와 네이밍이 포함된다.); x-compliance-01(환불·약관·개인정보 관련 FAQ의 승인, 최신성, 원문 링크 위임이 법적 문서 관리와 연결된다.); x-writer-05(운영성 문서를 사용자에게 보이는 도움말 문구로 가공한다.); x-marketing-05(스토어 리뷰와 반복 불만을 FAQ로 흡수해 평판 악화를 줄이는 출시 후 평판 대응과 연결된다.)'
    value: 사용자 셀프서비스 지원을 만들 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 운영자가 반복 문의를 줄이기 위한 헬프센터 구축 절차로 충분히 구체적이고 검증 가능하므로 승격 권고.  리스크: 자기해결률 계산식은 단순 FAQ방문수 대비 문의수로 계산하면 예시에서도 지적하듯 과대평가될 수 있어, FAQ 경유 문의 추적이나 세션 기준 정의가 필요하다.; Notion을 자기해결률 측정 불가로 단정하면 외부 분석 스크립트·리다이렉트·문의 링크 UTM 등 우회 측정 가능성을 놓칠 수 있다.; 정적 웹문서에 검색 로그와 이벤트를 심으려면 별도 분석 도구나 서버리스 수집 지점이 필요하므로 0원 구성의 구현 전제가 더 명확하면 좋다.; 정책 문서 원문 링크 위임은 안전하지만, 사용자가 즉시 알아야 하는 핵심 제한 조건을 너무 숨기면 문의 감소 효과가 떨어질 수 있다.; 다국어 제품에서는 검색어 동의어·오탈자·정책 링크가 언어별로 달라지는데, 현 초안에는 현지화 운영 기준이 거의 없다.'
    action: review
    path: 40_Skills/candidate/x-liveops-10.md
    ecosystem: 'partial:sprint-web'
  - id: x-liveops-11
    name: 티켓·환불·계정복구 프로세스
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-05(사용자 지원 처리, 계정조회, 보상 등 문의 접수 후 처리 흐름과 겹친다.); x-liveops-06(수동 지급, 차단, 로그 확인, 운영자 도구 사용 등 백오피스 수동 운영과 겹친다.); x-liveops-10(사용자 셀프서비스 지원과 환불·계정복구 안내 경로 설계에서 맞닿는다.); x-liveops-12(응대 기준과 표준 답변 중 환불 승인·거부, 본인확인 요청, 종결 커뮤니케이션이 겹친다.); x-monetization-04(환불 정책, 반복 환불, 게임내 재화 회수와 이중 이득 방지 영역이 겹친다.); x-compliance-06(PII 보관, 삭제, 열람·탈퇴 등 계정복구 감사 로그와 개인정보 보존 기준이 겹친다.); x-platform-05(관리자 권한, 최소권한, 유료·PII 보호 기준이 계정복구와 결제 처리 접근 통제에 연결된다.); x-server-09(결제 멱등성, 정산 데이터, 거래ID 기반 처리와 환불 로그가 겹친다.); x-server-05(결제 환불과 재화 회수, 보상 지급의 원자성 문제와 겹친다.); x-writer-05(운영 커뮤니케이션 문구와 사용자 통지 기준에서 겹친다.)'
    value: 사용자 문제를 끝까지 처리하는 흐름이 필요할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자의 티켓·환불·계정복구 운영을 실제 집행 가능한 규칙으로 잘 분해한 고품질 스킬이다.  리스크: 채널별 환불 권한과 기간은 정책 변경 가능성이 높으므로 공식 문서 확인일과 링크를 결과물에 반드시 남겨야 한다.; Google Play의 ''48시간 내 자동'' 같은 표현은 국가, 상품 유형, 콘솔 정책 변화에 따라 오해를 부를 수 있어 실제 권한 범위를 확인해야 한다.; 180일 보존은 분쟁 대응 기준으로는 실용적이나 지역별 개인정보 보관 제한과 충돌할 수 있어 법적 기준을 별도 확인해야 한다.; 계정복구에서 ''증거 2개 이상''은 좋은 기본값이지만 고위험 계정이나 고액 결제 계정에는 추가 검증 단계가 필요할 수 있다.; 재화 회수를 DB에서 수동 차감하는 절차는 음수 잔액, 이미 소비된 재화, 환불 웹훅 중복 처리 같은 예외 규칙이 보강되면 더 안전하다.'
    action: review
    path: 40_Skills/candidate/x-liveops-11.md
    ecosystem: 'partial:sprint-web'
  - id: x-liveops-12
    name: SLA·응대 매크로
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-05(사용자 지원 문의의 분류, 계정조회, 보상 처리와 맞닿아 있으며 SLA 등급과 신원확인 기준이 이 스킬의 운영 표준으로 연결된다.); x-liveops-11(접수부터 추적, 종결까지의 지원 흐름 위에서 첫응답·해결시간과 매크로 문안을 고정하므로 같은 고객지원 운영 영역을 다룬다.); x-liveops-07(P0 장애성 문의, 진행불가, 보상·공지 상황에서 장애 응대와 사후 커뮤니케이션 기준이 일부 겹친다.); x-liveops-10(반복 문의를 줄이기 위한 셀프서비스 설계와 Top 문의 매크로 작성 대상이 연결된다.); x-writer-05(운영 커뮤니케이션 문구의 톤, 사과, 다음 행동, 종결 문장 같은 응대 카피 품질 기준이 겹친다.); x-marketing-05(스토어 리뷰와 부정 평판 대응에서 답변 속도와 표준 문안이 평점 회복 운영과 연결된다.); x-compliance-01(개인정보 처리방침, 보관기간, 파기 기준 등 사용자 응대 중 수집되는 개인정보 처리 전제가 맞닿아 있다.); x-compliance-06(계정 삭제·이관 요청의 본인확인과 비가역 처리 기준이 탈퇴·열람권 처리와 연결된다.); x-monetization-04(환불 규칙과 직접 환불권 여부, 스토어 위임 경계가 결제 운영 정책과 겹친다.)'
    value: 응대 기준·표준 답변을 세울 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자용 고객지원 SLA와 응대 매크로를 즉시 운영 문서로 만들 수 있을 만큼 구체적이고 실용적인 고품질 스킬이다.  리스크: 금요일 18시 P1 접수 후 8영업시간 계산 예시가 월요일 16시로 되어 있는데, 평일 10~19시 기준이면 계산 방식에 따라 월요일 17시가 될 수 있어 혼선을 줄 수 있다.; P0 첫응답 2시간은 1인 개발자에게 현실적일 수 있지만 휴가·수면·시차·주말 운영이 있는 경우 별도 온콜 기준 없이는 지키기 어렵다.; 영수증 orderId 90일 보관은 현실적인 예시지만 국가, 스토어 정책, 개인정보 처리방침에 따라 조정이 필요하다.; 자동응답을 스토어 리뷰, 디스코드 DM, 이메일, 인게임 폼에 모두 동일하게 적용할 수 없으므로 채널별 기술 가능 여부 확인이 필요하다.; 매크로가 오래되면 환불 정책이나 보상 권한 변경을 반영하지 못해 잘못된 약속을 할 수 있으므로 정기 검토 주기가 필요하다.'
    action: review
    path: 40_Skills/candidate/x-liveops-12.md
    ecosystem: 'partial:sprint-web'
  - id: x-marketing-01
    name: ASO 키워드 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-02(스토어 페이지 메타데이터와 설명문 작성 영역이 맞닿아 있으나, 이 초안은 검색 키워드와 필드 배치에 초점을 둔다.); x-marketing-03(검색 유입 후 설치 전환율과 스크린샷 일관성 판단에서 연결된다.); x-marketing-08(키워드 선택은 포지셔닝·세그먼트와 입력 전제가 일부 겹치지만, 이 초안은 포지셔닝 결정 이후의 ASO 실행이다.); x-release-03(스토어 메타데이터 정책·리젝 리스크 점검과 일부 겹친다.); x-analytics-07(스토어 검색 유입 성과와 마케팅 효율 판단 지표가 연결된다.); x-writer-04(제목·설명·스크린샷 문구 작성과 표현 레벨에서 접점이 있다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방 중 상표권, 과장표현, 키워드 스터핑 검토와 겹친다.); klv:gtm(ASO를 유통 경로 설계와 출시 후 kill/scale 판단의 일부로 다룰 수 있다.)'
    value: 스토어 등록 전 (이름·부제·키워드·카테고리)
    risk: 'Tier-2 품질 5/5 · 권고 promote · ASO 키워드 설계 역할에 매우 적합한 고품질 실행 스킬이며, 플랫폼별 절차와 검증 가능한 산출물이 탄탄하다.  리스크: Apple Search Ads Popularity, Play Console 검색어, 자동완성 순위는 접근 권한·지역·시점에 따라 값이 달라질 수 있어 출처와 측정일을 함께 남겨야 한다.; 스토어 검색 인덱싱 알고리즘과 정책은 변경될 수 있으므로 ''긴 설명 영향 0'', ''2~4회 반복'' 같은 규칙은 주기적으로 공식 문서나 실제 데이터로 재검증해야 한다.; Android 긴 설명 반복 횟수 2~4회는 유용한 휴리스틱이지만 카테고리·문장 길이·언어별로 최적값이 다를 수 있다.; CVR 25% 재산정 트리거는 카테고리와 국가별 기준 차이가 커서 절대 기준으로 오해될 수 있다.; 상표권 판정은 일반명사와 브랜드명이 섞이는 경우가 있어 자동 체크만으로 충분하지 않고 애매하면 법무 확인이 필요하다.; iOS 로케일별 키워드 필드 운용, 현지화된 단어 조합, 문자 수 계산 방식은 언어별로 세부 확인이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-marketing-01.md
    ecosystem: 'partial:signalcraft'
  - id: x-marketing-02
    name: 스토어 카피 작성
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-01(스토어 이름·부제·키워드·카테고리와 연결되며, 이 스킬은 그 전략을 문장 카피로 전환한다.); x-marketing-03(설치 전환율 개선이라는 목표가 같고 스크린샷 캡션·첫 화면 메시지에서 만난다.); x-writer-04(제목·설명·스크린샷 문구 작성 영역이 겹치지만, 이 초안은 스토어 전환 카피에 더 좁게 특화되어 있다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방을 위해 금지 표현과 메타데이터 정확성을 다룬다.); x-release-03(메타데이터·심사·정책 대응과 연결되며, 제출 전 카피 품질과 리젝 위험을 낮추는 역할이 겹친다.); x-analytics-07(스토어·마케팅 효율 판단과 CVR 측정, A/B 결과 해석에서 접점이 있다.); x-marketing-07(CTA와 소재 문구를 통해 설치단가·전환 개선에 영향을 준다.); x-liveops-03(What''s New와 패치노트 문구는 사용자에게 변경을 전달하는 운영 커뮤니케이션과 겹친다.)'
    value: 스토어 페이지 (전환 중심 설명·노트)
    risk: 'Tier-2 품질 4/5 · 권고 revise · 스토어 전환 카피 작성 스킬로는 매우 실용적이지만, 최신 정책 확인과 근거 없는 수치·A/B 기준 보완이 필요하다.  리스크: 플랫폼 글자수·정책은 자주 바뀔 수 있는데, 초안은 표를 고정 기준으로 쓰라고 해 최신 공식 문서 확인 단계가 빠져 있다.; ''설치 결정의 90%''처럼 근거 없는 수치가 스킬 자체의 원칙과 충돌한다.; Steam은 App Store/Google Play와 필드 구조와 구매 맥락이 달라 같은 템플릿으로 처리하면 부정확할 수 있다.; A/B 합격선 1000조회 또는 14일, +10% 상대 개선은 앱 규모와 기준 CVR에 따라 통계적으로 부족할 수 있다.; 의료·금융·아동·구독 앱처럼 규제 민감도가 높은 카테고리는 별도 검토 조건이 더 필요하다.; 키워드 1~2회 삽입 규칙이 Google Play에서 키워드 스터핑으로 오해되지 않도록 자연성 기준을 더 명시할 필요가 있다.'
    action: review
    path: 40_Skills/candidate/x-marketing-02.md
    ecosystem: 'partial:sprint-app'
  - id: x-marketing-03
    name: 스토어 이미지 기획
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-01(스토어 등록 전 USP, 이름, 부제, 키워드 결과를 이미지 첫 슬롯 메시지의 입력으로 사용한다.); x-marketing-02(스토어 페이지 전환을 목표로 설명문과 시각 자산이 함께 작동하므로 메시지 구조가 맞닿는다.); x-marketing-07(설치 전환 개선을 위해 썸네일·소재·CTA를 다루는 영역과 스토어 이미지 실험이 겹친다.); x-analytics-07(스토어 방문 대비 설치 CVR, A/B 실험, 페이지뷰 기준 등 마케팅 효율 판단 지표를 사용한다.); x-compliance-03(앱스토어·플레이 심사 리젝 방지를 위해 금지 표현, 허위 UI, 정책 애매 항목 점검이 연결된다.); x-release-01(제출 전 자산 규격·정책·체크리스트 확인이 릴리즈 자산 점검과 접점이 있다.); x-release-03(스토어 메타데이터와 심사 대응 과정에서 스크린샷·피처 그래픽 제출 품질이 연결된다.); x-writer-04(스크린샷 캡션과 제목성 문구를 다루므로 카피 작성 역할과 맞닿는다.)'
    value: 설치 전환율 (스크린샷 순서·미리보기 영상)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 스토어 시각 자산을 전환 중심으로 기획·검증하게 만드는 완성도 높은 실무형 스킬이다.  리스크: 2026 기준 핵심 수치 표가 들어 있어 사용자가 공식 문서 재확인 문구를 무시하면 오래된 규격을 그대로 따를 위험이 있다.; ''스토어 방문자의 80%는 첫 2~3장만 본다'' 같은 수치는 출처나 조건이 없어 절대값처럼 오해될 수 있다.; 사회적 증거 슬롯의 평점·다운로드·수상·리뷰 인용은 지역별 표시 가능 여부와 검증 자료가 필요하며, 없을 때 대체 슬롯 지침이 약하다.; Google Play의 가격·할인 텍스트 금지 설명은 실제 정책 맥락에 따라 예외와 해석 차이가 있을 수 있어 컴플라이언스 확인이 필요하다.; Steam은 모바일 앱스토어와 구매 맥락이 달라 캡슐·스크린샷·트레일러의 우선순위가 다를 수 있는데 플랫폼별 가중치 조정 지침은 다소 짧다.'
    action: review
    path: 40_Skills/candidate/x-marketing-03.md
    ecosystem: 'partial:sprint-app'
  - id: x-marketing-05
    name: 리뷰 대응
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-05(사용자 불만·결제·버그 문의를 분류하고 지원 채널로 연결하는 부분이 겹친다.); x-liveops-11(리뷰에서 발생한 사용자 문제를 티켓으로 넘기고 해결 흐름에 연결하는 접점이 겹친다.); x-liveops-12(공개 응대 톤, 표준 답변, 금지 표현 관리가 겹친다.); x-compliance-03(앱스토어·구글플레이 정책 위반 리뷰 신고와 스토어 정책 대응 부분이 겹친다.); x-marketing-08(리뷰가 평점·포지셔닝·시장 신호로 작동한다는 점에서 일부 겹친다.); x-release-06(릴리즈 노트와 알려진 이슈, 패치 후 커뮤니케이션 갱신 루프가 겹친다.); x-writer-05(운영 커뮤니케이션 문구 작성과 공개 답변 카피 품질 관리가 겹친다.); x-monetization-04(환불 규칙과 결제 불만 대응에서 일부 접점이 있다.)'
    value: 출시 후 평판 (긍정·부정 답변·평점 회복)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 앱 리뷰 공개 대응을 1인 개발자 운영 루프로 바꾸는 고품질 실전 스킬이다.  리스크: 스토어별 답변 수정 가능 여부, 신고 경로, 사용자 알림 동작은 플랫폼 정책 변경에 취약하므로 실행 전 최신 공식 문서 확인이 필요하다.; 환불·결제 답변은 국가, 스토어, 결제 대행 구조에 따라 달라질 수 있어 법적 조언처럼 쓰이면 위험하다.; 350자 제한은 실무 기준으로 유용하지만 플랫폼별 실제 제한과 다를 수 있으므로 절대 규칙으로 고정하면 안 된다.; 별점 테러 기준인 ''한 시간에 ★1 3개 이상''은 앱 규모에 따라 과민하거나 둔감할 수 있어 baseline 조정이 필요하다.; 지원 이메일로 주문번호·기기 모델을 받는 흐름은 개인정보 보관·삭제·접근권한 기준이 함께 준비되어야 한다.'
    action: review
    path: 40_Skills/candidate/x-marketing-05.md
    ecosystem: 'partial:signalcraft'
  - id: x-marketing-06
    name: 캠페인 메시지 제작
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-07(광고 소재와 CTA, 설치단가·전환 개선 과정에서 메시지 성과 검증과 맞닿는다.); x-liveops-04(재방문·이벤트 안내의 세그먼트, 딥링크, 푸시 메시지 작성 영역과 겹친다.); x-liveops-03(앱내공지와 사용자 변경 전달 문구 작성에서 채널과 메시지 구조가 일부 겹친다.); x-writer-05(운영 커뮤니케이션 문안 작성과 톤·정책 점검 측면이 겹친다.); x-writer-04(스토어·스크린샷 문구처럼 짧은 전환 카피를 쓰는 영역과 일부 겹친다.); x-analytics-06(A/B 테스트, 최소 표본, 중단 기준을 잡아 메시지 변형을 검증하는 부분이 겹친다.); x-analytics-07(마케팅 효율 판단을 위해 광고·채널별 지표와 교체 기준을 읽는 부분이 맞닿는다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방과 광고·푸시·앱내공지 정책 리스크 점검이 겹친다.)'
    value: 유입 캠페인 (광고·랜딩·이메일·푸시·SNS)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 캠페인 카피 제작 역할에 필요한 입력, 절차, 정책 점검, 검증 기준이 잘 갖춰진 즉시 사용 가능한 고품질 스킬이다.  리스크: 채널별 글자 수와 플랫폼 정책은 자주 바뀌므로 표의 수치를 고정 규칙처럼 쓰면 최신 정책과 어긋날 수 있다.; 최소 표본과 중단선이 간단한 운영 기준으로는 좋지만 통계적 검정력이나 베이스라인 차이를 충분히 반영하지는 않는다.; 세그먼트별 변형은 훅만 바꾸라는 규칙이 명확하나, 실제로는 베네핏 자체가 세그먼트별로 달라져야 하는 캠페인도 있다.; 이메일 수신동의, 광고 표시, 푸시 야간 발송 제한은 국가·플랫폼·업종별 차이가 있어 별도 법무·정책 확인이 필요하다.; 근거로 후기나 수치를 사용할 때 출처, 표본 기간, 조작 가능성 검증 절차가 더 명확하면 좋다.'
    action: review
    path: 40_Skills/candidate/x-marketing-06.md
    ecosystem: 'partial:signalcraft'
  - id: x-marketing-07
    name: 크리에이티브 테스트
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-03(스토어 썸네일·스크린샷·미리보기 영상의 설치 전환율 개선이라는 소재/스토어 전환 영역이 겹친다.); x-marketing-06(광고 소재, 캠페인 유입, CTA 성과 측정 등 유입 캠페인 운영과 실험 영역이 겹친다.); x-analytics-06(UI·가격·보상·온보딩 검증처럼 A/B 테스트와 지표 기반 승자 판단 절차가 겹친다.); x-analytics-07(마케팅 효율 판단에서 CPI, CAC, ROAS, 채널 성과를 보는 영역과 소재 테스트의 성과 해석이 맞닿아 있다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방을 테스트 전 정책 게이트로 일부 다룬다.); x-release-03(메타데이터·심사·정책 대응 중 스토어 소재와 심사 리스크 확인 영역이 겹친다.); x-writer-04(제목·설명·스크린샷 문구 같은 테스트 대상 카피 변형과 맞닿아 있다.); klv:gtm(UA 훅, ASO, kill/scale 게이트와 소재 성과 검증 및 확장 판단의 상위 맥락이 겹친다.)'
    value: 설치단가·전환 개선 (썸네일·소재·CTA)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 단일 소재 슬롯의 승자 선정에 매우 적합한, 실행성과 검증성이 높은 크리에이티브 테스트 스킬이다.  리스크: 변형당 전환 100건과 개선폭 15% 기준은 간편하지만 베이스라인 비율, 기대효과, 비용에 따라 과소·과대 판정될 수 있다.; 순차 테스트는 시즌성, 요일효과, 캠페인 학습 상태, 경쟁 입찰 환경 변화의 영향을 크게 받을 수 있어 보정 로그가 필요하다.; 광고 플랫폼과 스토어 정책은 자주 바뀌므로 정책 게이트 문구를 최신 공식 문서로 확인해야 한다.; ATT, 동의, 어트리뷰션 윈도우, SKAN 같은 측정 제약이 빠지면 CPI/CVR 해석이 왜곡될 수 있다.; 여러 플랫폼의 자동 최적화 캠페인은 소재별 트래픽이 균등하게 배분되지 않을 수 있어 실험 설정 확인이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-marketing-07.md
    ecosystem: 'partial:signalcraft'
  - id: x-marketing-08
    name: 경쟁 앱 리서치
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-01(스토어 이름·부제·키워드·카테고리 확정 전에 경쟁 앱 키워드와 포지셔닝 근거를 넘긴다.); x-marketing-02(스토어 설명과 전환 카피에 필요한 경쟁 불만·차별점 근거를 제공한다.); x-marketing-03(경쟁 앱의 온보딩·paywall·비주얼 관찰이 스크린샷 순서와 설치 전환 판단에 연결될 수 있다.); x-marketing-07(경쟁 광고 소재나 CTA 비교가 필요할 때 현재 스킬의 리서치 결과가 소재 개선 논의의 입력이 된다.); x-monetization-01(경쟁 가격, 구독/IAP 구조, 가격 밴드를 수집해 가격·번들 결정의 근거를 만든다.); x-monetization-03(paywall 위치와 온보딩 길이의 시장 관행을 관찰해 결제 노출 타이밍 결정에 연결된다.); x-analytics-06(UI·가격·보상·온보딩 검증과 경쟁 앱 관찰 항목이 일부 겹치며, 이후 실험 설계의 근거가 될 수 있다.); x-marketing-04(출시 직전 가격·지역·스토어 준비 판단에 경쟁 앱 리서치 산출물이 직접 쓰인다.)'
    value: 시장 진입 전략 (포지셔닝·가격·리뷰)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 경쟁 앱을 과조사 없이 표준화해 관찰하고 가격·포지셔닝 입력으로 바꾸는 매우 실용적인 고품질 스킬이다.  리스크: 180일 내 업데이트와 리뷰 100건 기준은 신생 카테고리, B2B 앱, 니치 유료 앱에서는 유효 표본을 지나치게 줄일 수 있다.; 앱 내 paywall 위치, 가격 티어, 온보딩 길이는 실제 설치와 조작이 필요해 국가·기기·계정 상태에 따라 재현성이 떨어질 수 있다.; 리뷰 최신순·낮은평점순 각 10건은 빠르게 실행하기 좋지만, 리뷰 조작이나 특정 버전 이슈에 과도하게 끌릴 위험이 있다.; 가격 밴드를 중앙값 ±1티어로 단순화하면 원가 구조, CAC, LTV, 플랫폼 수수료, 구매력 차이를 충분히 반영하지 못할 수 있다.; 모방 금지 게이트의 ‘연속 8단어’ 기준은 영어에는 유용하지만 한국어·일본어처럼 띄어쓰기와 형태소가 다른 언어에서는 보조 기준이 필요하다.; 스토어 검색 순위와 카테고리 랭킹은 계정·지역·시간·광고 노출에 민감하므로, 스냅샷 한계 표기가 실제 의사결정에서 무시될 수 있다.'
    action: review
    path: 40_Skills/candidate/x-marketing-08.md
    ecosystem: 'delegate:signalcraft'
  - id: x-marketing-09
    name: 커뮤니티 초기 운영
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-06(SNS, Reddit, X 등 외부 채널을 통해 유저를 유입시키는 활동과 맞닿아 있으나, 이 초안은 캠페인 설계보다 커뮤니티 채널 운영과 정착에 초점을 둔다.); x-marketing-08(초기 타깃과 채널 선택은 시장 진입·포지셔닝 판단과 연결되지만, 이 초안은 상위 전략 이후의 30일 실행 운영 계획을 다룬다.); x-marketing-05(출시 후 평판과 커뮤니티 반응 관리가 일부 겹치지만, 이 초안은 평점 회복보다 초기 커뮤니티 생존성과 발화 유지에 집중한다.); x-liveops-03(공지와 운영 메시지 전달이 커뮤니티 운영에 포함될 수 있으나, 이 초안은 공지 작성 자체보다 채널 리듬과 운영 구조를 설계한다.); x-liveops-05(유저 문의와 개별 응대가 초기 커뮤니티에서 발생할 수 있으나, 이 초안은 지원 처리 플로우가 아니라 대화 활성화와 커뮤니티 생존 판단을 맡는다.); x-liveops-12(모더레이션 기준과 응대 톤의 일부가 겹치지만, 이 초안은 상세 표준 답변보다 최소 운영 정책과 신고·제재 구조를 둔다.); x-analytics-02(DAU, 리텐션, churn 같은 지표를 소비해 커뮤니티 건강도를 판단하므로 목표·대시보드 스킬과 접점이 있다.); x-analytics-05(매일 상태를 보는 운영 습관과 주간 활성 발화자·반응 수 확인이 맞닿아 있다.); x-compliance-01(이용규칙, 개인정보 고지, 미성년 관련 문구가 필요하므로 ToS·Privacy Policy 검토 영역과 연결된다.); x-compliance-05(미성년 보호, 연령 등급, 아동 데이터 제한 같은 전제가 커뮤니티 운영 정책에 영향을 준다.); x-writer-05(공지, 운영 안내, 유저 응대 문장과 접점이 있으나, 이 초안은 문안 작성보다 운영 계획과 채널 활성화 구조를 다룬다.); klv:gtm(초기 유통 경로와 kill/scale 게이트 판단과 연결되며, 커뮤니티 채널을 성장 자산으로 볼 때 일부 관점이 겹친다.)'
    value: 초기 유저 기반 (Discord·SNS·피드백)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자의 초기 커뮤니티 운영을 채널 선택부터 30일 생존 판정까지 실행 가능하게 만드는 고품질 스킬이다.  리스크: Reddit의 9:1 규칙, X 정책, Discord 가이드라인 등 플랫폼별 정책은 자주 바뀌므로 실행 시 최신 공식 문서를 확인해야 한다.; 13세 미만 차단 고지는 지역·플랫폼·수집 데이터 종류에 따라 충분하지 않을 수 있어 법적 문구로 그대로 쓰면 위험하다.; ''광고로 데려온 사람은 안 정착한다''는 표현은 방향성은 유용하지만 절대 명제로 받아들이면 유료 유입 후 커뮤니티 전환 실험을 과도하게 배제할 수 있다.; 주간 활성 발화자 비율 같은 건강도 기준은 소규모 표본에서는 변동성이 커서 10~20명 규모일 때는 정성 판단과 함께 봐야 한다.; X DM 그룹, 개별 DM, 베타키 제공은 플랫폼 약관·스팸 정책·개인정보 처리 방식에 따라 제한될 수 있다.; 커뮤니티를 처음 운영하는 사람이 모더레이션 공개 경고를 기계적으로 적용하면 분쟁을 키울 수 있으므로 공개/비공개 경고 기준을 더 세분화하면 좋다.'
    action: review
    path: 40_Skills/candidate/x-marketing-09.md
    ecosystem: 'partial:signalcraft'
  - id: x-monetization-01
    name: 가격·패키지 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-monetization-02(구독 티어와 IAP 구성 자체를 설계하는 스킬과 가격표·무료/유료 경계 결정 지점이 맞닿는다.); x-monetization-04(첫구매, 시즌, 번들, 환불 규칙과 패키지 가격·업그레이드·환불 정책 정의가 일부 겹친다.); x-monetization-05(후보 가격이 사업성이 있는지 LTV/CAC/ARPU로 검증하는 후속 판단과 직접 연결된다.); x-analytics-06(가격 테스트와 전환 검증, WTP 실험 설계가 UI·가격 검증 영역과 겹친다.); x-marketing-08(시장 포지셔닝과 가격 앵커, 경쟁가 비교가 연결된다.); x-marketing-04(출시 직전 가격·지역·스토어 설정 실행 단계와 맞닿는다.); x-compliance-03(앱스토어·플레이 결제 정책, 가격 티어, 환불·심사 제약 반영이 겹친다.); x-release-03(스토어 메타데이터·심사·정책 대응 과정에서 가격과 지역 설정 검증이 연결된다.); x-server-09(유료화 도입 시 결제·정산 데이터 구조와 가격·상품 식별자가 맞물린다.)'
    value: 얼마에·어떤 묶음으로 팔지 정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 가격·패키지 설계 역할에 필요한 계산, 경계 정의, 검증 게이트가 구체적이어서 바로 승격 가능한 고품질 스킬이다.  리스크: 플랫폼 수수료, 세금, 스토어 가격 티어, 소규모 사업자 프로그램 조건은 자주 바뀌므로 문서의 기준값을 고정 진실로 쓰면 오판할 수 있다.; 판매가 floor 공식이 세금 포함/별도, 스토어 대납, 결제수수료 고정액이 있는 채널을 단순화하므로 실제 정산표와 대조가 필요하다.; 목표 유료고객 수를 임의로 낮거나 높게 잡으면 floor가 왜곡되어 가격 하한선이 현실성을 잃을 수 있다.; WTP 설문 N≥30은 초기 가설에는 충분할 수 있으나 실제 결제 의사와 차이가 크므로 프리세일·클릭·구매 전환 데이터로 보정해야 한다.; ‘가격 2배면 가치도 2배’ 기준은 유용하지만 가치비 측정이 주관적일 수 있어 기능 사용량, 저장 한도, 자동화 횟수 같은 계량 기준이 필요하다.; EU 청약철회, 한국 전자상거래·콘텐츠 환불, 구독 자동갱신 고지 등 법적 요건을 가격 설계자가 직접 확정하면 법무 검토 없이 위험할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-monetization-01.md
    ecosystem: 'partial:product-spec'
  - id: x-monetization-02
    name: 구독·인앱상품 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-monetization-01(가격·티어 산출물을 인용해 상품 타입에 매핑하므로 가격 설계와 연결된다.); x-monetization-03(결제 노출 위치는 다루지 않지만 구매 화면 고지와 구매 복원 버튼 등 결제 UX 접점이 일부 맞닿는다.); x-monetization-04(무료체험·인트로 오퍼·시즌패스 구현 타입을 다뤄 첫구매·번들·시즌 오퍼 규칙과 연결된다.); x-monetization-05(purchase, renew, cancel, refund 등 유료화 성과 측정 훅을 남겨 LTV·ARPU 판단과 연결된다.); x-analytics-02(전환·churn 분석을 위한 이벤트 훅을 정의하지만 지표 정의는 해당 스킬에 위임한다.); x-compliance-03(스토어 심사 리젝을 유발하는 IAP 정책 게이트를 다룬다.); x-release-03(앱스토어·플레이 심사 제출 전 메타데이터와 정책 대응 흐름과 맞닿는다.); x-server-05(결제·재화 지급의 원자성, 중복 지급 방지, 환불 회수 정책과 연결된다.); x-server-09(유료화 결제 붙일 때 필요한 멱등성 키, 정산성 데이터, webhook 처리와 직접 겹친다.); x-server-02(상품·구매·entitlement·이벤트 엔티티가 초기 서버 데이터 모델과 연결된다.)'
    value: 구독 티어·소비/비소비 아이템을 짤 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 실제 출시 가능한 구독·IAP 운영 설계로 내리는 데 매우 강한 고품질 스킬이며, 최신 정책 확인만 전제로 하면 바로 승격 가능하다.  리스크: 스토어 정책과 Billing Library/App Store API 버전은 자주 바뀌므로, 예시의 특정 버전·기간·정책 조항을 그대로 복붙하면 최신 심사 기준과 어긋날 수 있다.; Android grace period 기간이나 기본값처럼 플랫폼·상품 설정에 따라 달라지는 값을 단정적으로 적용할 위험이 있다.; RevenueCat 같은 BaaS 사용 시 finish/acknowledge, webhook, entitlement 조회 책임 경계가 SDK 설정에 따라 달라질 수 있어 실제 문서 확인이 필요하다.; 시즌패스 구현은 플랫폼별 지원 타입과 서버 만료 처리 방식이 복잡하므로, Non-Renewing/Consumable 선택 기준을 프로젝트별로 더 구체화해야 한다.; 환불 시 이미 소비된 재화 회수 정책은 법무·CS·경제 밸런스 이슈가 있어 단순 즉시 회수만으로 충분하지 않을 수 있다.'
    action: review
    path: 40_Skills/candidate/x-monetization-02.md
    ecosystem: 'partial:product-spec'
  - id: x-monetization-03
    name: Paywall·오퍼 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-monetization-01(가격표와 SKU 목록을 입력으로 받아 paywall 표시와 오퍼 노출에 사용하므로 가격 설계와 맞닿는다.); x-monetization-02(구독 티어, 소비/비소비 아이템, trial 유무를 paywall 화면 구성과 Restore 요건에 반영한다.); x-monetization-04(첫구매, 시즌, 번들, 환불 규칙 자체는 넘기지만 오퍼 노출·환불률·grandfathering 정책에서 접점이 있다.); x-monetization-05(LTV/CAC 판정은 아니지만 전환율, ARPPU, churn, 환불률 같은 수익 KPI를 실험 기준으로 사용한다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방 중 paywall 화면 고지, Restore, 외부결제 문구, 구독 안내와 직접 겹친다.); x-release-03(메타데이터·심사·정책 대응 중 결제 화면과 구독 고지 관련 심사 리스크를 다룬다.); x-analytics-06(UI·가격·보상·온보딩 검증과 마찬가지로 paywall 변경을 실험 설계와 합격/중단 기준으로 검증한다.); x-analytics-03(결제 전환 이탈 구간과 paywall 노출 트리거·dismiss 이벤트 분석이 연결된다.); x-liveops-02(원격 설정과 AB 인프라를 전제로 paywall 노출 빈도, 트리거, 오퍼를 앱 업데이트 없이 조정할 수 있다.); x-server-09(영수증 검증과 멱등 정산은 넘기지만 구매 성공, 복원, trial 시작 이벤트 및 SKU 일관성이 결제 백엔드와 맞닿는다.); x-writer-03(paywall의 버튼, 고지, 닫기, 약관 링크 등 결제 직전 마이크로카피 품질과 접점이 있다.)'
    value: 언제·어디서 결제를 띄울지 정할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · paywall 노출·고지·실험·기존 유저 보호를 한 장 설계 패킷으로 묶은 고품질 수익화 스킬이다.  리스크: Apple·Google 정책은 자주 바뀌므로 3.1.1, 3.1.2, 외부결제 허용 지역 등은 적용 시 최신 원문 확인이 필요하다.; 첫 세션 hard paywall 금지, 24시간 2회 캡, trial-to-paid 35% 같은 기본값이 장르·B2B·전문도구·웹 SaaS에는 과도하게 일반화될 수 있다.; Steam 환불 정책을 paywall에 명시 권장한다고 했지만 제품 유형과 스토어 UI에 따라 오히려 불필요하거나 문구 검토가 필요할 수 있다.; before/after 2주 비교는 시즌성, 업데이트 효과, 유입 채널 변화에 취약하므로 작은 트래픽 환경의 대체 실험으로 쓸 때 해석 주의가 필요하다.; 구매 복원 버튼 필수 범위가 플랫폼과 상품 유형에 따라 달라질 수 있어 소비성 아이템만 있는 앱에는 체크리스트를 그대로 적용하면 과잉 요구가 될 수 있다.'
    action: review
    path: 40_Skills/candidate/x-monetization-03.md
    ecosystem: 'partial:product-spec'
  - id: x-monetization-04
    name: 프로모션·환불 정책
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-monetization-01(프로모션 혜택과 번들 가격을 다루지만, 이 스킬은 금액 설계보다 적용 조건·한도·어뷰징 정책에 초점이 있다.); x-monetization-02(구독·소비성·비소비성 아이템 분류가 환불 정책 판단에 필요해 상품 구성 영역과 맞닿는다.); x-monetization-05(프로모션이 수익성에 영향을 주지만, 이 스킬은 LTV/CAC 판정보다 운영 가능한 정책 규칙을 만든다.); x-compliance-03(App Store, Google Play, Steam 정책 확인과 심사 리스크가 연결된다.); x-compliance-01(환불 조항은 ToS·Privacy Policy 같은 법적 문서와 연결될 수 있다.); x-liveops-05(환불 요청 처리, 계정 조회, 보상/회수 등 사용자 지원 운영과 겹친다.); x-liveops-12(승인/거절 고지 문구와 응대 기준을 포함한다.); x-liveops-06(관리자 도구, 수동 SQL, 로그 캡처 등 수동 운영 절차가 겹친다.); x-server-05(결제·재화 지급과 회수의 원자성 구현이 정책 집행의 전제다.); x-server-09(환불 트랜잭션, 멱등성, 정산 데이터와 강하게 연결된다.); x-analytics-08(결제·환불·지급 로그 불일치와 증거 로그 확인이 필요하다.); x-release-03(메타데이터·심사·정책 대응 과정에서 환불/프로모션 고지가 함께 검토될 수 있다.)'
    value: 첫구매·시즌·번들·환불 규칙을 만들 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 프로모션과 환불을 실행 가능한 정책·탐지·SOP로 바꾸는 완성도 높은 스킬이므로 promote가 적절하다.  리스크: 법률·플랫폼 규정은 자주 바뀌므로 예시의 48시간, 2주/2시간, 지역별 철회권 문구를 그대로 복붙하면 오판할 수 있다.; KR/EU/US 분기는 최소선이라 판매 국가가 늘어나면 현지 소비자보호법, 세금, PG 약관, 미성년자 결제 규정이 추가로 필요하다.; device_id, IP, 스토어 국가를 어뷰징 탐지에 쓰려면 개인정보 고지·보관기간·동의·익명화 기준이 함께 정리되어야 한다.; Apple/Google/Steam처럼 플랫폼이 환불 주체인 경우 개발자 정책과 실제 환불 권한 사이의 경계를 운영자가 혼동할 수 있다.; 소비성 아이템 사용분 거절은 소진 로그의 정확성, 원장 무결성, 시간대 기준이 확보되지 않으면 분쟁에서 취약하다.; 관리자 도구가 없을 때 수동 SQL을 최소선으로 제시하지만, 권한 통제·감사 로그·실수 복구 절차가 없으면 운영 사고 위험이 있다.'
    action: review
    path: 40_Skills/candidate/x-monetization-04.md
    ecosystem: 'partial:product-spec'
  - id: x-monetization-05
    name: 수익성 모델
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-monetization-01(가격·번들 후보의 경제성을 검증할 때 직접 연결된다.); x-monetization-02(구독 티어와 아이템 구조를 ARPU·LTV·기여이익으로 환산하는 영역이 맞닿아 있다.); x-monetization-04(첫구매·시즌·번들·환불 규칙의 수익성 판단에 같은 계산 지표가 쓰인다.); x-analytics-02(ARPU·LTV·churn 같은 핵심 지표를 입력값으로 받아 판정한다.); x-analytics-07(CAC와 마케팅 효율 데이터를 사용해 회수기간과 LTV/CAC를 판단한다.); x-marketing-07(설치단가와 전환 개선 결과가 CAC·전환율 가정에 직접 영향을 준다.); klv:gtm(UA 채널의 kill/scale 게이트에 필요한 회수기간과 LTV/CAC 기준을 제공한다.); x-server-09(결제·정산 데이터가 net 매출과 환불·수수료 계산의 원천이 된다.); x-platform-09(운영비 모니터링과 변동원가·고정비 산정이 수익성 계산에 연결된다.)'
    value: LTV·CAC·ARPU로 팔 만한지 판단할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 수익성 검증 스킬로는 매우 실용적이지만 CAC 기준과 전환율 반영 오류를 고쳐야 안전하게 승격할 수 있다.  리스크: CAC가 설치자 기준인지 가입자 기준인지 유료고객 기준인지 명시하지 않으면 LTV/CAC가 크게 왜곡된다.; B2C 앱 예시에서 유료 전환율 2%가 LTV 계산에 반영되지 않아, CAC가 전체 획득 유저 기준이면 수익성이 과대평가된다.; VAT가 가격 포함인지 별도인지, B2C/B2B·국가별 세무 처리 차이가 있어 단일 공식으로 오해할 수 있다.; 월 churn 기반 LTV는 churn이 낮거나 코호트가 짧을 때 과대추정되기 쉽다.; 손익분기 사용자수 계산에 필요한 월 고정비 입력이 명시적으로 빠져 있다.; 스토어 수수료 15~30%, PG 수수료 등은 정책·매출 규모·지역에 따라 달라 최신 약관 확인이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-monetization-05.md
    ecosystem: 'delegate:product-spec'
  - id: x-monetization-06
    name: 무료↔유료 경계 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-monetization-01(무료/유료 경계 분류 이후 가격·번들 결정으로 이어지는 인접 수익화 의사결정이다.); x-monetization-02(구독 티어와 소비/비소비 아이템 구성은 이 스킬의 분류 결과를 받아 구체 상품 구조로 만든다.); x-monetization-03(결제벽과 결제 노출 타이밍은 무료 경험의 천장·D1 보호 기준과 맞물린다.); x-monetization-04(첫구매·시즌·번들·환불 규칙은 기존 사용자 처리, 환불 회수, 소비성 재화 설계와 연결된다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방과 구독 표시, 외부결제, 확률공시 정책 체크가 겹친다.); x-server-09(유료화 서버 경계, 영수증 검증, entitlement 원장 설계가 직접적으로 겹친다.); x-server-05(재화·보상·결제 권한을 원자적으로 보장해야 하는 소비성 아이템 처리와 관련된다.); x-liveops-03(무료→유료 변경 시 인앱 공지, 유예 기간, 사용자 반발 완화 커뮤니케이션이 겹친다.); x-liveops-02(feature flag와 Remote Config로 무료/유료 경계를 앱 업데이트 없이 조정하는 운영 방식이 겹친다.); x-analytics-03(결제벽 전후 이탈과 활성화 저하를 확인해 무료/유료 경계를 재조정하는 데 연결된다.); x-analytics-06(가격·보상·온보딩 검증과 D1 결제벽, 무료 천장, 유료 우위 상한의 실험 검증이 맞닿아 있다.); x-release-03(메타데이터·심사·정책 대응 과정에서 구독, IAP, 확률형 아이템 정책 검토가 겹친다.)'
    value: F2P 밸런스·페이투윈 방지를 잡을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 무료/유료 경계 설계를 실제 출시·운영 의사결정으로 끌고 갈 만큼 구체적이고 검증 가능한 고품질 스킬이다.  리스크: 30% 진행속도 우위, 첫 막힘 30분, 14일 유예 같은 기준은 장르·세션 길이·플랫폼·국가에 따라 보정이 필요하다.; ''핵심+우위있음 → 무료 강제, 예외 없음''은 페이투윈 방지에는 강하지만 싱글플레이 DLC, 프리미엄 확장팩, 데모형 게임에는 별도 해석이 필요하다.; 플랫폼 정책을 ''2026 기준''으로 적고 있어 시간이 지나면 외부결제, 구독 표시, 확률형 아이템 규정이 바뀔 수 있으므로 매 적용 시 공식 문서 확인이 필수다.; 유료 진행속도 우위를 정량화하려면 실제 플레이타임·경제 밸런스·코호트 데이터가 필요하므로 출시 전에는 추정치 품질이 낮을 수 있다.; 서버 entitlement와 영수증 검증을 전제로 하므로 완전 오프라인 게임이나 서버 없는 1인 개발 앱에는 구현 비용이 과할 수 있다.; 확률형 능력치 항목은 일부 지역 규제까지 언급하지만 국가별 법적 요구사항을 완전히 대체하지는 못한다.'
    action: review
    path: 40_Skills/candidate/x-monetization-06.md
    ecosystem: 'partial:sprint-game'
  - id: x-platform-01
    name: CI 파이프라인
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-02(CI 이후 배포 트리거, staging/prod 승인 흐름과 자연스럽게 연결된다.); x-platform-03(테스트와 빌드가 실행되는 러너·컨테이너·격리 환경 구성과 맞닿아 있다.); x-platform-04(CI 시크릿 주입, fork PR 보안, 토큰 노출 방지와 영역이 겹친다.); x-platform-06(gitleaks, audit, SCA/CVE 스캔을 CI에 포함하는 부분이 보안 정책과 연결된다.); x-platform-10(핵심 플로우 자동 검증을 CI 게이트의 test job으로 실행할 수 있다.); x-platform-11(배포 직후 기본 동작 확인과 CI build/test 통과 기준이 릴리스 안정성 측면에서 이어진다.); x-platform-12(배포 전 자동 통과 기준과 required checks 기반 CI 게이트가 의미적으로 가깝다.); x-release-01(빌드·QA·정책 체크리스트 중 자동화 가능한 항목이 CI 게이트와 겹친다.); x-release-02(버전·서명·배포 패키지 생성 전 빌드 검증과 산출물 관리가 연결된다.); x-server-12(서버 변경 회귀 테스트와 데이터 품질 검증을 CI test/build 단계에 포함할 수 있다.)'
    value: PR 품질 게이트 (lint·test·build + 보안 스캔)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자의 PR 품질 게이트를 실제로 구축·운영하게 만드는 구체적이고 검증 가능한 고품질 CI 스킬이다.  리스크: GitHub Actions 중심 예시가 강해서 GitLab CI나 셀프호스트 러너의 구체 예시는 별도 보강이 필요할 수 있다.; 모바일, Unity, Docker 이미지 빌드처럼 시간이 긴 스택에서는 5분 목표가 비현실적일 수 있어 스택별 시간 예산 조정 기준이 필요하다.; SCA를 경고로 둘 때 이슈를 추적하지 않으면 취약점이 장기간 방치될 수 있다.; gitleaks 히스토리 스캔은 기존 저장소에서 과거 누출을 대량으로 발견할 수 있어 초기 도입 시 예외·정리 절차가 필요하다.; required checks 이름이 workflow job 이름과 불일치하면 브랜치 보호가 의도대로 작동하지 않을 수 있다.; 아티팩트 path 예시가 프로젝트마다 없을 수 있어 실패 시에도 upload-artifact 단계가 불필요하게 경고를 만들 수 있다.'
    action: review
    path: 40_Skills/candidate/x-platform-01.md
    ecosystem: 'partial:sprint-web'
  - id: x-platform-02
    name: CD 배포 자동화
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-01(lint/test/build 및 보안 스캔 같은 품질 게이트를 CD 파이프라인의 선행 stage로 연결한다.); x-platform-03(dev/staging/prod 환경 분리와 실행 일관성을 CD 트리거·stage 설계의 전제로 사용한다.); x-platform-04(배포 토큰, CI 시크릿, 로그 마스킹, 토큰 scope 점검이 시크릿 관리 영역과 맞닿아 있다.); x-platform-08(배포 실패 시 롤백, feature flag, canary/promotion 같은 복구·완화 전략을 파이프라인에 반영한다.); x-platform-11(staging smoke check와 post-deploy health check를 배포 게이트로 사용한다.); x-platform-12(배포 전 자동 통과 기준을 CD stage의 품질·보안·smoke 게이트로 구체화한다.); x-release-02(tag/release 기반 prod 배포와 모바일/패키지 배포에서 버전·패키지 확정 흐름과 연결된다.); x-release-04(모바일 스토어와 위험 기능의 단계적 출시, halt 기준, feature flag 사용이 겹친다.); x-release-05(장애 시 되돌리기, 핫픽스, 롤백 불가 배포 판단을 CD 운영 리스크 처리에 포함한다.); x-server-06(DB 마이그레이션을 expand→contract로 나누고 롤백 가능성을 확보하는 서버 DB 변경 절차와 겹친다.)'
    value: 반복 배포 안정화 (staging·prod·승인)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자용 CD 자동화 스킬로 절차·게이트·검증·롤백 산출물이 충분히 구체적이어서 승격 권장.  리스크: GitHub Actions 기준 예시가 강해 GitLab CI, Bitbucket, self-hosted runner에서는 승인 게이트와 시크릿 마스킹 구현 차이를 별도로 보완해야 한다.; `git grep -nE ''TOKEN|SECRET|KEY =''`는 오탐과 누락이 많으므로 보조 점검으로만 써야 하며, 실제 기준은 gitleaks 같은 전용 도구가 더 적합하다.; 마이그레이션 stage 위치는 서비스 구조에 따라 deploy 전/후가 달라질 수 있다. 특히 expand migration은 새 코드 배포 전에 선행되어야 하는 경우가 많아, 단일 순서로 고정하면 위험할 수 있다.; 모바일과 패키지 배포는 심사, 서명, 트랙 승격, 패키지 삭제 불가 같은 특수성이 더 크므로 이 초안만으로는 세부 파이프라인을 완성하기 어렵다.; 알림의 에러율 급증 감지는 로그/메트릭 기반이 필요하므로 모니터링이 없는 프로젝트에서는 먼저 관측성 전제가 필요하다.'
    action: review
    path: 40_Skills/candidate/x-platform-02.md
    ecosystem: 'partial:official-mcp'
  - id: x-platform-03
    name: 컨테이너·환경 분리
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-01(PR/CI 품질 게이트와 보안 스캔을 배포 차단 기준으로 거는 부분이 겹친다.); x-platform-02(staging/prod 분리, 승인 흐름, 반복 배포 안정화와 환경 격리 관점이 맞닿아 있다.); x-platform-04(시크릿을 레포·이미지에 넣지 않고 외부 주입하며 유출 이력 시 폐기·재발급하는 부분이 겹친다.); x-platform-05(운영 DB, PII, prod 접근 권한을 최소화하고 dev/test와 분리하는 권한 경계가 겹친다.); x-platform-06(Trivy 취약점 스캔과 이미지 보안 기준이 SCA/CVE 대응 영역과 겹친다.); x-platform-09(재현 가능한 운영 환경과 인프라 구성 판단이라는 점에서 클라우드/Terraform 재현성과 인접하다.); x-platform-12(배포 전 자동 통과 기준을 CI에 거는 검증 게이트 설계가 겹친다.); x-server-11(PII 원본 반출 금지, 마스킹·합성 데이터, 운영 데이터 보호가 서버 데이터 보호 영역과 겹친다.)'
    value: 일관 실행 + 테스트/운영 격리
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자에게 필요한 컨테이너 재현성과 환경 격리를 과투자 없이 명령 수준까지 끌고 가는 고품질 스킬이다.  리스크: `docker run app:ci whoami`는 distroless·최소 이미지처럼 셸이나 whoami가 없는 이미지에서 실패할 수 있어 `docker inspect`로 User를 확인하는 대체 게이트가 필요할 수 있다.; `docker history`와 `git log -p`만으로 시크릿 누출을 완전히 보장하기 어렵다. gitleaks 같은 전용 스캐너를 병행하는 전제가 있으면 더 강하다.; 베이스 이미지 버전 태그 고정은 좋지만 태그는 재발행될 수 있으므로 고보안 환경에서는 digest pinning까지 요구할 수 있다.; 시크릿을 환경변수로 주입하는 방식은 간단하지만 런타임·로그·프로세스 덤프에 노출될 수 있어 Secret Manager, 파일 마운트, 단기 토큰 등과의 경계 설명이 있으면 더 안전하다.; dev에서 prod 호스트 접속 시도 게이트는 네트워크 정책·방화벽·DNS 구성에 따라 구현 방식이 달라질 수 있어 프로젝트별 구체화가 필요하다.'
    action: review
    path: 40_Skills/candidate/x-platform-03.md
    ecosystem: 'partial:sprint-web'
  - id: x-platform-04
    name: 비밀·시크릿 관리
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-01(PR 품질 게이트와 보안 스캔, gitleaks·CI 차단 기준이 겹친다.); x-platform-03(dev/staging/prod 환경 분리와 실행 환경별 설정 관리가 겹친다.); x-platform-05(최소권한, 협력자별 자격증명 분리, PII 접근 위험 판단이 겹친다.); x-platform-07(유출 후 로그 확인, 비정상 호출 탐지, 에러 트래커 마스킹이 겹친다.); x-platform-08(침해 후 복구, 키 교체, 배포 확인, 사후 재발 방지 흐름이 겹친다.); x-platform-06(OWASP 기준과 보안 취약점 대응 관점에서 시크릿 노출 방지가 일부 겹친다.); x-release-02(앱 서명 키·배포 패키지 서명 관련 시크릿 관리가 일부 겹친다.); x-server-03(관리자·유료·PII 보호와 서버 측 권한 키 관리가 일부 겹친다.)'
    value: 시크릿이 코드에 안 섞이게 (Secret Manager·Vault)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 시크릿 저장·주입·회전·폐기·사고 대응을 실제로 운영할 수 있게 만드는 고품질 스킬이다.  리스크: gitleaks 설정 예시의 특정 버전은 시간이 지나면 낡을 수 있어 최신 버전 확인 절차가 있으면 더 안전하다.; GitHub Secret Scanning과 Push Protection은 리포 유형·요금제·조직 정책에 따라 사용 가능 범위가 달라질 수 있다.; L1 90일, L2 180일 회전 주기는 좋은 기본값이지만 발급처 정책이나 키 교체 비용이 큰 시스템에서는 예외 기준이 필요하다.; `.env.*`를 전부 gitignore하면 `.env.production.example` 같은 문서용 파일까지 실수로 제외될 수 있어 예외 패턴을 명확히 관리해야 한다.; 클라이언트 노출 전제 키를 L3로 분류할 때, 도메인 제한·RLS·쿼터 제한 같은 보완 통제가 실제로 있는지 확인해야 한다.; 사고 대응에서 법적 신고, 사용자 통지, 결제사·클라우드 사업자 통보가 필요한 경우의 판단 기준은 별도 컴플라이언스 스킬과 연결해야 한다.'
    action: review
    path: 40_Skills/candidate/x-platform-04.md
    ecosystem: 'partial:sprint-web'
  - id: x-platform-05
    name: 권한·접근 정책
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-04(시크릿 저장·회전과 토큰 scope 최소화가 맞닿아 있다.); x-platform-02(배포 권한, CI 권한, 승인 게이트와 접근 정책이 연결된다.); x-platform-01(PR 보안 스캔과 토큰·권한 노출 방지가 같은 보안 운영 흐름에 있다.); x-platform-07(감사로그, 위험 동작 로그, 침해 탐지 관점이 일부 겹친다.); x-server-03(회원·관리자 역할과 데이터 접근 정책이 앱 내부 권한 모델과 연결된다.); x-liveops-06(운영자 콘솔의 지급·차단·로그 권한 정의와 수동 운영 절차가 겹친다.); x-compliance-06(PII 접근, 열람·삭제 요청 처리 시 접근 최소화와 감사 증적이 관련된다.)'
    value: 최소권한 — 관리자·유료·PII 보호
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실전성이 높은 최소권한 스킬이지만, 깨진 참조와 플랫폼별 전제 보정을 고치면 바로 승격 가능하다.  리스크: GitHub audit log, 클라우드 감사 기능, SSO/OIDC, 하드웨어 키 등은 요금제나 플랫폼에 따라 사용 가능 범위가 다르다.; ''콘솔에서만 변경'' 원칙은 IaC를 쓰는 프로젝트에서는 정책 소스와 충돌할 수 있어 예외 기준이 필요하다.; 90일 회전 주기는 모든 키에 최선은 아니며, 단기 자격증명/OIDC 전환이 가능한 경우 회전보다 폐기가 우선이다.; break-glass 계정을 잘못 분리하면 1인 개발자가 스스로 잠기는 계정 복구 리스크가 생긴다.; Firestore·Stripe·DB 예시가 플랫폼별 세부 권한 모델과 완전히 일치하지 않을 수 있어 실제 적용 시 번역 작업이 필요하다.; Step 5의 ''절차 6 참조''는 문서 오류라 수정해야 한다.'
    action: review
    path: 40_Skills/candidate/x-platform-05.md
    ecosystem: 'partial:sprint-web'
  - id: x-platform-06
    name: 취약점·의존성 점검
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-01(PR 품질 게이트에 보안 스캔이 포함될 수 있어 CI에서 취약점 검사 결과를 통과 기준으로 삼는 부분이 겹친다.); x-platform-12(배포 전 자동 통과 기준을 설정하는 맥락에서 신규 Critical/High 취약점 차단과 SLA 만료 실패 조건이 겹친다.); x-platform-04(보안 점검 영역이라는 점에서 인접하며, SAST 보조 검사에서 하드코딩 시크릿 탐지와 일부 접점이 있다.); x-platform-07(침해 탐지와 런타임 모니터링은 다르지만 공개 CVE 알림, 취약점 대응 우선순위, 보안 운영 루프 측면에서 접점이 있다.); x-release-01(출시 전 통합 체크리스트에서 취약점·의존성 점검 항목이 포함될 수 있다.); x-release-05(Critical 취약점 발견 시 핫픽스, 패치 경로, 임시 mitigation 판단과 연결된다.); x-compliance-04(OSS 구성요소를 확인한다는 점은 같지만, 이 스킬은 라이선스가 아니라 known vulnerability와 패치 SLA에 집중한다.)'
    value: OWASP·SCA·알려진 CVE 대응
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 취약점·의존성 점검을 반복 가능한 운영 절차로 만들기에 충분히 구체적이고 검증 가능하다.  리스크: CVSS만 기준으로 삼으면 실제 악용 가능성, EPSS, CISA KEV 등 위협 인텔리전스 반영이 부족할 수 있다.; 공개 서버면 +1등급, 빌드타임이면 -1등급이라는 보정 규칙은 단순해서 프로젝트별 공격 표면을 과대 또는 과소평가할 수 있다.; CI 예시가 핵심부 수준이라 실제로 신규 취약점과 기존 미해결, SLA 만료를 구분하려면 별도 스크립트나 기준 파일 설계가 필요하다.; 도구별 출력 형식과 exit code가 달라 자동 게이트를 만들 때 파싱 오류나 false fail이 생길 수 있다.; fix 버전 bump가 semver breaking change를 만들 수 있으므로 패치 후 회귀 테스트 기준이 함께 필요하다.'
    action: review
    path: 40_Skills/candidate/x-platform-06.md
    ecosystem: 'partial:sprint-web'
  - id: x-platform-07
    name: 관측성·알람
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-05(매일 상태 확인과 대시보드 운영이라는 면에서 일부 겹치지만, 이 초안은 비즈니스 KPI가 아니라 시스템 헬스 알람에 집중한다.); x-analytics-08(이상 감지와 원인 구분이라는 면에서 접점이 있으나, 이 초안은 서버·인프라 신호와 알람 임계값 정의가 중심이다.); x-liveops-07(장애 대응 흐름과 이어지지만, 이 초안은 장애 탐지와 알람 발생 전까지를 다룬다.); x-platform-08(롤백 판단 입력으로 관측성 신호를 사용하므로 연결되지만, 복구·롤백 실행 절차는 별도 영역이다.); x-platform-11(헬스체크와 스모크 확인이라는 공통점이 있으나, 이 초안은 배포 직후 1회 검증이 아니라 상시 모니터링이다.); x-platform-13(운영 장애 증거를 로그·트레이스로 넘긴다는 점에서 맞닿지만, 장애 재현 테스트 작성은 다루지 않는다.); x-platform-09(클라우드 운영과 비용 모니터링 맥락에서 일부 접점이 있으나, 이 초안은 비용 자체보다 장애 신호와 알람 설계가 핵심이다.); x-server-10(배치·큐·재시도 실패 감지와 연결되며, 이 초안은 그런 실패를 알람 대상으로 정의한다.); x-server-11(백업 실패와 데이터 유실 리스크 감지에서 접점이 있다.)'
    value: 장애·침해 탐지 (로그·메트릭·트레이스)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 겹침과 무관하게, 1인 개발자의 최소 관측성·알람 셋업을 구체적 산출물과 검증까지 끌고 가는 고품질 스킬이다.  리스크: 도구 무료 티어, 전화 알림 제공 여부, Sentry 이벤트 한도 같은 외부 서비스 조건은 시간이 지나며 바뀔 수 있어 실제 적용 시 최신 문서 확인이 필요하다.; 헬스엔드포인트가 DB와 외부 의존성을 모두 강하게 핑하면 부하 증가나 외부 장애로 인한 과잉 P1 알람이 생길 수 있으므로 경량화와 타임아웃 기준이 필요하다.; 로그·에러 수집 시 결제 정보, 토큰, 이메일, PII가 Sentry나 로그에 유출되지 않도록 마스킹·필터링 전제가 더 명시되면 좋다.; 결제 웹훅 실패율 계산은 트래픽이 적은 초기 서비스에서 표본 수가 작아 오탐이 날 수 있으므로 최소 이벤트 수 조건을 함께 두는 것이 안전하다.; 모바일 앱·클라이언트 중심 제품에서는 서버 Uptime만으로 실제 사용자 장애를 놓칠 수 있어 클라이언트 크래시/네트워크 오류 기준이 추가로 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-platform-07.md
    ecosystem: 'partial:official-mcp'
  - id: x-platform-08
    name: 롤백·인시던트 대응
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-07(알람 이후 대응을 다루지만, 탐지 지표와 로그·메트릭·트레이스 기반 판단에서 맞닿는다.); x-platform-02(배포 롤백과 staging/prod 분리, 배포 파이프라인 안정화 전제가 연결된다.); x-release-05(장애 시 롤백, hotfix, 패치 경로 판단 영역이 직접 겹친다.); x-liveops-07(장애·데이터 오류 시 사용자 공지, 보상, 사후보고 산출물이 겹친다.); x-platform-13(사후 재발 방지로 장애를 테스트로 재현하는 흐름을 넘긴다.); x-server-06(DB migration 되돌리기, 백업, 비가역 스키마 변경 위험 판단과 겹친다.); x-server-05(결제·재화 데이터 무결성, 중복결제, 보상 원자성 문제와 겹친다.); x-server-11(PITR, 개인정보 보호, 데이터 손실 대비와 침해 대응 전제가 연결된다.); x-liveops-03(상태 공지와 인앱 공지의 단계별 커뮤니케이션이 겹친다.); x-writer-05(운영 커뮤니케이션 문구 작성과 고객 안내 산출물이 겹친다.)'
    value: 배포 실패·침해 시 복구 (canary·feature flag)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 사고 중 의사결정 속도를 높이는 1인 개발자용 인시던트 runbook으로 품질이 매우 높아 승격 권고.  리스크: 개인정보 유출 신고·통지 기한을 ''확인''으로만 둬서 실제 관할별 법정 시간과 절차는 별도 확인이 필요하다.; 증거 보존 위치, 접근권한, 로그 보존기간, 체인 오브 커스터디 같은 보안 포렌식 세부가 부족해 침해 사고에서는 미흡할 수 있다.; 임계값 표가 기본값으로는 유용하지만 트래픽이 작거나 이벤트성 피크가 큰 서비스에서는 오탐·과잉 롤백 가능성이 있다.; DB 복원·down migration·데이터 보정은 스택별 절차와 권한이 크게 달라 실제 명령 runbook 없이는 실행 단계에서 막힐 수 있다.; 상태 페이지, feature flag, 백업, APM, Crashlytics/Sentry 같은 수단이 사전에 마련되어 있다는 전제가 있다.'
    action: review
    path: 40_Skills/candidate/x-platform-08.md
    ecosystem: 'partial:sprint-web'
  - id: x-platform-09
    name: 인프라 코드화·비용
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-02(staging/prod 환경 분리, 승인된 apply, 반복 가능한 배포 안정화와 맞닿는다.); x-platform-03(dev/prod 실행 환경 격리와 환경별 tfvars 구조가 일부 겹친다.); x-platform-04(tfvars 시크릿 제외, 백엔드 설정값 관리 등 시크릿 분리 전제가 필요하다.); x-platform-05(인프라를 만들 때 provider 권한, 예산·상태 백엔드 접근 권한 등 IAM 최소권한 설계가 연결된다.); x-platform-07(drift 탐지와 비용 알림은 운영 관측·알림 체계와 일부 겹친다.); x-platform-12(fmt, validate, plan, destroy/replace 차단 같은 배포 전 자동 게이트와 겹친다.); x-server-07(비용 급증 원인 분석과 관리형 서비스 선택 트레이드오프가 서버 비용 최적화와 만난다.); x-server-08(예시의 CloudFront TTL, CDN 캐시 정책은 읽기 부하·지연·비용 절감 영역과 이어진다.); x-release-05(인프라 변경 실패 시 되돌리기와 패치 경로 판단이 일부 겹친다.)'
    value: 재현 가능 클라우드(Terraform) + 운영비 모니터링
    risk: 'Tier-2 품질 5/5 · 권고 promote · IaC와 비용 게이트를 1인 개발자 관점에서 실행 가능한 절차와 검증 기준으로 잘 묶은 고품질 스킬이다.  리스크: 예산 알림은 대부분 ''차단''이 아니라 통지이므로 실제 과금 상한으로 오해하면 위험하다.; Terraform rollback을 git revert로 단순화했는데, 상태 파일·provider 동작·이미 생성된 외부 리소스 때문에 애플리케이션 코드 롤백보다 복잡할 수 있다.; S3 native lock 등 일부 기능은 Terraform/OpenTofu 버전 조건을 명시해야 한다.; *.tfvars 전체를 gitignore하면 비시크릿 환경 설정까지 빠져 재현성이 떨어질 수 있어 secret tfvars와 예시 tfvars를 분리하는 지침이 있으면 더 안전하다.; prod prevent_destroy는 유용하지만 필요한 교체 작업까지 막을 수 있으므로 예외 절차가 필요하다.'
    action: review
    path: 40_Skills/candidate/x-platform-09.md
    ecosystem: 'partial:sprint-web'
  - id: x-platform-10
    name: E2E·통합 테스트
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-01(PR 단계에서 lint·test·build를 게이트로 묶는 영역과 겹치며, 이 스킬의 테스트 결과가 PR 품질 게이트의 입력이 된다.); x-platform-03(테스트/운영 환경 격리, 일관 실행, 테스트 데이터와 외부 의존성 분리 원칙이 겹친다.); x-platform-05(관리자·유료 기능·PII 보호를 권한 음성 테스트와 PII 비노출 단언으로 일부 검증한다.); x-platform-06(SQLi/XSS 같은 OWASP 회귀 가드를 포함하므로 보안 취약점 대응 영역과 일부 겹친다.); x-platform-11(핵심 동작을 자동으로 확인한다는 점은 유사하지만, 이 스킬은 배포 전 PR/머지 회귀 묶음이고 x-platform-11은 배포 직후 스모크에 가깝다.); x-platform-12(배포 전 자동 통과 기준에 E2E·통합 테스트를 포함시키는 관계라 게이트 구성 측면에서 겹친다.); x-platform-13(장애나 버그를 테스트로 고정한다는 점에서 겹치지만, 이 스킬은 사전 회귀 범위 설계가 중심이다.); x-release-01(출시 전 QA·빌드 체크리스트 중 자동 테스트/검증 항목과 겹친다.); x-server-12(서버 변경 회귀와 데이터 품질 검증 중 API↔DB 통합 테스트 영역이 겹친다.)'
    value: 핵심 플로우를 자동으로 검증할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 핵심 회귀 테스트와 CI 증거를 실제로 만들 수 있게 하는 고품질 E2E·통합 테스트 스킬이다.  리스크: E2E 8~15개, CI 5분 같은 숫자 기준은 1인 웹 SaaS에는 유용하지만 모바일, Unity, 대형 레거시, 느린 결제 플로우에서는 조정이 필요하다.; ''외부 네트워크 호출 0'' 원칙은 이상적이지만 Stripe/IAP, OAuth, 모바일 푸시, 앱스토어 샌드박스 검증처럼 실제 샌드박스 호출이 필요한 경우 예외 정책이 필요하다.; data-testid만 권장하면 접근성 기반 셀렉터(getByRole 등)를 활용하는 현대 E2E 관행과 충돌할 수 있다.; OWASP 최소 1줄 가드는 회귀 방지용일 뿐인데, 사용자가 이를 충분한 보안 테스트로 오해할 위험이 있다.; 예시에서 점수 컷 미만 결제 플로우를 예외 채택하는데, 예외 기준이 본문 규칙보다 덜 명문화되어 있어 실무 적용 시 자의적 판단이 생길 수 있다.; 테스트 데이터 삭제 방식이 단순 DELETE 예시라 병렬 실행, 멀티테넌트 데이터, FK 관계가 복잡한 프로젝트에서는 더 강한 격리 전략이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-platform-10.md
    ecosystem: 'partial:superpowers'
  - id: x-platform-11
    name: 스모크 테스트
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-02(staging/prod 배포 안정화와 post-deploy 확인 흐름이 맞닿아 있다.); x-platform-07(로그·메트릭·알림을 통해 장애 신호를 관측한다는 점이 겹친다.); x-platform-08(canary·feature flag·배포 실패 대응의 초기 탐지 신호로 쓰인다.); x-platform-10(배포 후 핵심 동작을 자동 확인한다는 점은 유사하지만, 이 초안은 얕은 liveness 스모크에 한정한다.); x-platform-12(배포 파이프라인의 자동 통과 기준과 연결되지만, 이 초안은 배포 후 판정에 초점이 있다.); x-release-04(1%→10%→100% 코호트 진행과 중단 판단에 필요한 신호를 제공한다.); x-release-05(FAIL 판정 후 롤백·패치 판단으로 넘기는 입력을 만든다.); x-server-12(서버 변경 후 회귀와 데이터 품질 확인 중 write→read 검증이 일부 겹친다.); x-liveops-07(장애·데이터 오류 발생 시 운영 대응의 초기 감지 단계와 연결된다.)'
    value: 배포 직후 기본 동작을 확인할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 배포 직후 큰 장애를 빠르게 가르는 스모크 테스트 스킬로 범위·절차·판정 기준이 매우 실용적이다.  리스크: 프로덕션에서 더미 write→read를 수행할 경우 테스트 데이터 격리·삭제·권한 범위를 명확히 하지 않으면 실제 데이터나 지표를 오염시킬 수 있다.; 결제 확인에서 샌드박스와 실결제 환경의 차이를 과소평가하면 provider 연결·webhook·권한 문제를 놓칠 수 있다.; 강제 에러로 로그·알림을 테스트할 때 알림 피로, 온콜 오탐, 에러율 지표 오염을 막는 표식이나 필터가 필요하다.; 5분 윈도우와 기본 SLO 임계치는 트래픽이 낮은 1인 서비스나 모바일 phased rollout에서 표본이 너무 작아 오판 가능성이 있다.; 롤백 명령을 입력으로 요구하지만 실제 권한·DB 마이그레이션 역방향 가능성·스토어 배포 지연 같은 전제는 별도 확인이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-platform-11.md
    ecosystem: 'partial:superpowers'
  - id: x-platform-13
    name: 크래시·로그 재현
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-07(탐지된 장애·크래시의 로그·메트릭·트레이스를 입력으로 삼아 재현 증거를 만든다.); x-liveops-07(운영 장애 사후보고나 사용자 영향 대응에 들어갈 기술적 재현 증거 묶음과 맞닿아 있다.); x-server-12(재현 성공 후 failing repro를 회귀 테스트나 데이터 품질 검증 케이스로 넘기는 흐름이 연결된다.); x-analytics-08(로그 상관과 클라/서버 기록 대조를 사용하지만 목적은 지표 이상 분석이 아니라 크래시 입력 복원이다.); x-platform-10(핵심 플로우 자동 검증으로 전환할 수 있는 재현 케이스를 산출한다.); x-platform-12(배포 전 자동 통과 기준에 포함될 수 있는 실패 재현·회귀 기준과 이어진다.); x-release-05(장애 시 패치·롤백 판단 전에 동일 크래시 여부를 확인하는 증거로 활용될 수 있다.)'
    value: 운영 장애를 테스트로 재현할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 검증 가능한 판정 기준과 플랫폼별 증거 요건이 잘 잡힌 고품질 크래시 재현 스킬이다.  리스크: Sentry·Crashlytics·Datadog 등 도구 접근권한과 로그 보존기간이 없으면 Step 1 입력 복원이 막힐 수 있다.; 10회 반복과 80% 기준은 실용적이지만, 비용이 큰 서버 장애나 외부 결제 콜백처럼 반복 실행이 위험한 케이스에는 샌드박스·격리 조건을 별도로 명시해야 한다.; 원본 raw 로그의 로컬 보관 위치와 삭제 주기, 암호화 여부가 덜 구체적이라 PII 관리가 느슨해질 수 있다.; 서버 500 재현 시 운영 데이터 스냅샷을 사용할 경우 데이터 최소화·익명화·읽기전용 복제본 사용 전제가 더 필요하다.; 심볼·소스맵·mapping.txt가 없는 프로젝트에서 재현 판정이 막힐 때의 대체 절차가 제한적이다.'
    action: review
    path: 40_Skills/candidate/x-platform-13.md
    ecosystem: 'delegate:superpowers'
  - id: x-release-02
    name: 빌드 승인·서명
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-release-01(출시 전 통합 QA 이후의 릴리즈 게이트라는 점에서 빌드 승인 흐름과 맞닿아 있다.); x-platform-04(인증서, keystore, provisioning profile, 시크릿을 소비하고 만료를 점검한다.); x-platform-02(서명된 artifact를 배포 파이프라인에 넘기기 전 승인·배포 경계와 연결된다.); x-release-03(스토어 제출과 심사의 입력물이 되는 서명·공증 완료 artifact를 만든다.); x-platform-12(배포 전 자동 통과 기준과 해시·서명 검증 게이트가 일부 겹친다.)'
    value: 버전·서명·배포 패키지를 확정할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 승인·해시·봉인 흐름은 매우 좋지만, 플랫폼별 서명·공증 명령의 핵심 오류를 고친 뒤 승격하는 것이 적절하다.  리스크: iOS App Store/TestFlight IPA에 notarytool/stapler를 일반 필수 단계처럼 둔 것은 부정확하다. 공증은 주로 macOS Developer ID 배포 맥락이며 iOS IPA에는 그대로 적용되지 않는다.; spctl Gatekeeper 검증도 iOS가 아니라 macOS 앱 검증 맥락이다. iOS와 macOS 절차를 분리해야 한다.; Android AAB는 apksigner 검증 대상이 아니라 jarsigner 또는 bundletool 계열 검증으로 다뤄야 하며, APK와 AAB 검증 절차를 구분해야 한다.; Windows signtool 예시는 /tr만 강조하고 /td SHA256 같은 timestamp digest 지정도 명시적으로 포함하는 편이 안전하다.; 인증서 만료 30일 미만을 예시에서 ''이번 릴리즈는 통과''로 처리하는 기준이 모호하다. 체크리스트는 ≥30일을 통과 조건으로 두므로 경고/차단 정책을 일관화해야 한다.; CI 산출물과 로컬 다운로드본 해시 비교는 좋지만, 서명 전 artifact가 CI에서 이미 서명된 산출물인지 unsigned 산출물인지 플랫폼별로 명확히 해야 한다.'
    action: review
    path: 40_Skills/candidate/x-release-02.md
    ecosystem: 'partial:sprint-app'
  - id: x-release-03
    name: 스토어·플랫폼 제출
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-release-01(빌드·QA·자산·정책 통합 게이트를 제출 전 입력 조건으로 받는다.); x-release-02(버전·서명·배포 패키지 확정 이후의 스토어 업로드 산출물과 이어진다.); x-release-04(심사 통과 후 점진 출시·국가/코호트 배포 판단으로 연결된다.); x-release-05(리젝이나 출시 후 문제 발생 시 패치·되돌리기 판단과 일부 맞닿는다.); x-marketing-01(앱 이름·부제·키워드·카테고리 등 스토어 등록 메타데이터를 제출 화면에 입력한다.); x-marketing-02(스토어 설명·릴리즈 노트 등 전환 중심 카피를 검수해 제출하는 단계와 겹친다.); x-marketing-03(스크린샷·미리보기 영상 규격과 업로드 검증이 설치 전환 자산과 연결된다.); x-marketing-04(출시 직전 심사·가격·지역 설정과 직접적으로 맞닿는다.); x-compliance-02(ATT, 추적 동의, 개인정보 수집 고지 등 앱 추적 권한 처리와 겹친다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방을 제출 화면의 필드와 증거로 실행한다.); x-compliance-05(연령 등급, 아동 데이터, 결제 제한 관련 질문지와 정책 입력이 연결된다.); x-monetization-02(소비성·구독 등 인앱결제 상품 타입과 product ID 설정 검증이 겹친다.)'
    value: 메타데이터·심사·정책 대응 (리젝 포함)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 스토어 제출 마지막 구간에 필요한 필드 입력, 증거 준비, 리젝 재제출 분기가 매우 구체적인 고품질 릴리즈 스킬이다.  리스크: 스토어 제출 요건은 자주 바뀌므로 글자수, 스크린샷 사이즈, 타겟 API, 개인정보 폼 항목을 고정 사실처럼 재사용하면 위험하다.; 정책 해석을 별도 컴플라이언스 산출 없이 제출자가 임의로 판단하면 개인정보 라벨·Data safety가 실제 SDK 동작과 어긋날 수 있다.; 데이터 수집 인벤토리가 부정확하면 이 스킬의 매핑 절차가 아무리 좋아도 리젝 또는 정책 위반을 막지 못한다.; 인앱결제 샌드박스 확인은 클라이언트 흐름뿐 아니라 서버 검증·영수증 처리까지 포함되는지 명확히 해야 한다.; 무료에서 유료 전환, 스크린샷 필수 세트 같은 일부 규칙은 플랫폼·계정·시점별 차이가 있을 수 있어 제출일 확인이 필수다.'
    action: review
    path: 40_Skills/candidate/x-release-03.md
    ecosystem: 'partial:sprint-app'
  - id: x-release-05
    name: 롤백·핫픽스 결정
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-release-04(점진 출시 중단, canary 중단 기준, 배포 후 이상 감지 시 멈춤 판단과 맞닿아 있다.); x-platform-08(feature flag, kill-switch, canary, 복구 경로 선택 등 기술적 복구 수단이 겹친다.); x-liveops-07(장애·데이터 오류 상황에서 사용자 공지, 보상, 사후보고로 이어지는 후속 운영 영역과 연결된다.); x-platform-07(장애 탐지에 필요한 로그·메트릭·트레이스와 severity 판단 입력 지표가 겹친다.); x-server-06(DB 스키마 변경과 롤백 가능성 판단, 비가역 마이그레이션 처리와 관련된다.); x-server-05(결제·재화·보상 원자성 실패 시 데이터 손상, 이중 지급, 보정 판단이 연결된다.); x-analytics-08(지표 이상 원인을 클라이언트 로그와 서버 원장으로 검증하는 과정이 장애 신호 판별과 맞닿아 있다.); x-platform-11(배포 직후 기본 동작 확인과 배포 후 이상 감지, 초기 대응 판단이 이어진다.)'
    value: 장애 시 되돌리기·패치 경로를 판단할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 자기 역할의 긴급 복구 의사결정 도구로 매우 구체적이고 실행 가능하므로 promote가 적절하다.  리스크: S0~S3 임계값이 제품 특성별로 다르므로, 사전에 baseline과 임계 배수를 정하지 않으면 현장에서 숫자를 기계적으로 오용할 수 있다.; kill-switch나 서버 게이트가 이미 구현돼 있다는 전제가 강하다. 없을 경우 즉시 선택 가능한 경로가 줄어든다.; 데이터 보정은 감사 로그, 멱등성, dry-run, 백업·PITR 확인이 없으면 2차 손상을 만들 수 있다.; 모바일 심사 시간은 국가, 계정 상태, 긴급 심사 여부에 따라 달라질 수 있어 고정 SLA처럼 받아들이면 안 된다.; 보안·개인정보 노출 S0는 단순 롤백·핫픽스 외에 법적 통지, 접근키 폐기, 증거 보존 같은 별도 절차가 필요할 수 있다.; 1인 개발자 상황에서도 결제/개인정보/보안 사고는 외부 결제사, 스토어, 호스팅사 지원 채널을 즉시 확인해야 할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-release-05.md
    ecosystem: 'partial:sprint-web'
  - id: x-release-06
    name: 릴리즈 노트·핸드오프
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-03(사용자에게 변경을 전달하는 앱내공지·점검·노트 영역과 플레이어용 릴리즈 노트 본문이 겹친다.); x-liveops-07(장애·데이터 오류 시 공지·보상·사후보고와 known issue, 운영 런북, 고객지원 매크로 작성이 맞닿아 있다.); x-liveops-05(사용자 지원 처리와 known issue별 응대 매크로 작성이 겹친다.); x-liveops-12(응대 기준·표준 답변을 세우는 일과 고객지원 매크로 산출물이 겹친다.); x-marketing-02(스토어 페이지의 설명·노트 작성과 What''s New 산출물이 겹친다.); x-release-03(스토어 메타데이터·심사 대응 중 이번 버전 변경 설명 작성과 겹친다.); x-release-01(릴리즈 전 QA·자산·정책 체크 결과를 입력으로 받아 배포 문서화에 사용한다.); x-release-04(canary·코호트·중단기준과 기능 플래그, 점진 비율, 출시 후 모니터링 정보가 연결된다.); x-release-05(장애 시 되돌리기·패치 경로 판단과 롤백 가능성, 비가역 마이그레이션 런북이 겹친다.); x-platform-08(배포 실패 복구, canary, feature flag와 운영 런북의 롤백·플래그 태깅이 겹친다.); x-server-06(운영 DB 구조 변경과 마이그레이션의 롤백 가능성·비가역성 판단이 겹친다.); x-writer-05(운영 커뮤니케이션 문구 다듬기와 플레이어 노트·고객지원 문안 작성이 겹친다.)'
    value: 변경·알려진 이슈·운영 인계를 정리할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 릴리즈 후 문서화와 인계를 1인 개발자 관점에서 매우 구체적이고 검증 가능하게 구조화한 고품질 스킬이다.  리스크: GitHub CLI, 이슈 트래커, 플래그 설정, API 스펙 등 소스가 정리되어 있지 않은 프로젝트에서는 8개 수집 단계가 빈칸으로 남을 수 있다.; 모든 변경을 5종 산출물로 번역하면 소규모 핫픽스에는 작성 비용이 과할 수 있어 경량 모드 기준이 있으면 더 좋다.; known issue를 플레이어 노트에 공개하는 기준은 보안 취약점, 악용 가능성, 법적 책임 이슈에서는 별도 판단이 필요하다.; 고객지원 매크로의 예상수정 버전은 약속처럼 읽힐 수 있어 확정/목표/미정 표현 규칙이 필요하다.; 스토어 글자수와 심사 문구 기준은 플랫폼 정책 변경 가능성이 있어 작성 시 최신 공식 문서를 확인해야 한다.'
    action: review
    path: 40_Skills/candidate/x-release-06.md
    ecosystem: 'partial:sprint-game'
  - id: x-server-01
    name: API+데이터 모델 동시 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-02(엔드포인트 뒤의 테이블·컬렉션과 관계를 정의하므로 초기 엔티티/관계 모델링과 맞닿는다.); x-server-03(엔드포인트별 인증·인가 등급, 401/403, 본인 접근 제한을 다룬다.); x-server-04(클라 요청을 신뢰하지 않고 멱등성, 트랜잭션, 권한 거부, 경계값 검증을 포함한다.); x-server-05(결제·생성·보상류에서 멱등성 키와 원자적 쓰기 보장이 필요하다는 점이 겹친다.); x-server-06(스키마 변경, 무중단 마이그레이션, down 경로를 산출물에 포함한다.); x-server-07(N+1, 조인, 인덱스, 응답 행수 상한처럼 성능 리스크를 설계 단계에서 본다.); x-server-09(유료화나 결제 엔드포인트에 필요한 멱등성·정산성 데이터 설계와 일부 겹친다.); x-server-12(정상/권한거부/경계값 게이트와 데이터 품질 확인 기준을 요구한다.); x-platform-05(최소권한, 관리자·유료·PII 보호와 응답·로그 화이트리스트 항목이 겹친다.); x-platform-10(핵심 플로우 자동 검증 관점과 정상/권한거부/경계값 테스트 게이트가 맞닿는다.); x-analytics-09(PII 노출, 로그에 남기면 안 되는 필드, 개인정보 보호 설계와 일부 겹친다.)'
    value: 클라/서버 경계를 잡을 때 — 엔드포인트와 그 뒤 스키마를 같이 정한다
    risk: 'Tier-2 품질 5/5 · 권고 promote · 좁은 기능 단위에서 API 계약과 데이터 모델을 함께 고정하게 만드는 실전성이 높은 서버 설계 스킬이다.  리스크: REST와 관계형 DB 예시가 강해 GraphQL·문서형 DB 사용자는 resolver 비용, 임베드/참조 기준, 부분 업데이트 충돌 같은 추가 판단을 보강해야 한다.; 멱등성 처리에서 상태코드 예시가 409와 200을 함께 보여 프로젝트별 정책을 먼저 고정하지 않으면 구현자 간 해석이 갈릴 수 있다.; 마이그레이션 down을 항상 실질 복구로 오해할 위험이 있다. 데이터 삭제·백필 이후에는 역방향이 논리적 되돌리기인지 운영 복구인지 구분해야 한다.; 응답·로그 화이트리스트는 좋은 기준이지만, 에러 응답 포맷과 감사 로그 보존 정책까지는 별도로 정해야 한다.'
    action: review
    path: 40_Skills/candidate/x-server-01.md
    ecosystem: 'delegate:sprint-web'
  - id: x-server-02
    name: 도메인 데이터 모델링
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-01(클라/서버 경계와 엔드포인트를 정하면서 초기 스키마 방향도 함께 잡는 단계와 맞닿아 있다.); x-server-03(데이터 소유권과 PII 컬럼 지정이 이후 런타임 접근 정책·RLS 설계로 이어진다.); x-platform-05(PII 보호와 최소권한 관점에서 어떤 데이터가 민감한지 분류하는 부분이 겹친다.); x-server-06(DDL과 마이그레이션 검증을 다루지만, 이 스킬은 초기 설계이고 x-server-06은 운영 DB 변경에 가깝다.); x-server-09(결제·정산 데이터 모델, 금액 타입, PG 토큰 저장 등 유료화 데이터 구조와 관련된다.); x-server-11(PII 보존·삭제·익명화 정책을 모델에 반영하는 부분이 탈퇴/보존 운영 절차와 연결된다.); x-analytics-09(개인정보 동의·익명화·삭제가 분석 데이터 설계와 만나는 지점이 있다.); x-compliance-06(탈퇴·열람·이동권 대응을 위해 어떤 데이터가 어디에 있고 얼마나 보존되는지 정리하는 부분이 연결된다.)'
    value: 유저·주문·결제·이벤트 엔티티 초기 설계
    risk: 'Tier-2 품질 5/5 · 권고 promote · 초기 도메인 스키마를 현실적으로 확정하게 만드는 고품질 모델링 스킬이며 바로 카탈로그 승격 가능하다.  리스크: PostgreSQL 중심 표현이 강해 MySQL, SQLite, Firestore에서는 uuid v7, timestamptz, enum/check, FK 검증 방식을 별도로 치환해야 한다.; 상태 컬럼 enum/check만으로는 상태 전이 자체를 막지 못하므로 트리거, 저장 프로시저, 앱 레이어 가드 중 무엇으로 강제할지 명확히 해야 한다.; 전자상거래법 5년 등 보존기간은 국가·사업 형태·데이터 종류에 따라 달라질 수 있어 실제 적용 전 최신 법무 확인이 필요하다.; audit_log의 before/after에 PII나 민감정보가 과도하게 복제될 수 있으므로 마스킹·보존·접근권한 정책이 추가로 필요하다.; 초기 모델링 단계에서 과도하게 모든 엔티티를 고정하면 실험 중인 제품에서는 변경 비용이 커질 수 있어 핵심 원장과 실험 데이터의 엄격도를 구분해야 한다.'
    action: review
    path: 40_Skills/candidate/x-server-02.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-03
    name: 인증·권한 구현
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-04(토큰 서명 키, OAuth client secret, DB 자격증명 등 시크릿을 서버 밖으로 노출하지 않는 요구가 겹친다.); x-platform-05(관리자·유료·PII 접근 같은 최소권한 정책과 역할 경계 정의가 겹친다.); x-platform-06(OWASP ASVS, 인증 실패, 접근제어 취약점, IDOR 예방 등 보안 기준 적용 영역이 겹친다.); x-platform-07(로그인 실패, 403, 역할 변경, 세션 무효화 같은 보안 이벤트 로그와 침해 탐지 단서가 겹친다.); x-server-01(클라/서버 경계 설정 중 권한 검사를 클라이언트가 아니라 서버에서 강제한다는 API 경계가 겹친다.); x-server-02(user, role, order, paid 상태 같은 엔티티와 소유권 관계 설계가 인증·권한 매트릭스와 맞닿아 있다.); x-server-04(클라이언트 조작을 서버에서 차단하고 소유권·상태를 서버 데이터로 검증하는 흐름이 겹친다.); x-server-09(유료 기능 접근 권한, 결제 상태 기반 권한 확인, paid 역할 처리와 겹친다.); x-server-11(PII, 탈퇴, 세션 무효화, 개인정보 접근 통제와 일부 겹친다.); x-server-12(권한 정책 테스트와 서버 변경 회귀 검증이 겹친다.); x-compliance-02(쿠키, 개인정보, 추적·동의 등 인증 토큰 저장과 개인정보 처리 제약이 겹친다.); x-compliance-06(탈퇴권, 계정 삭제, 사용자 자기 데이터 접근·삭제 흐름과 겹친다.); x-liveops-06(운영자 권한, 사용자 검색, 차단, 수동 지급 등 admin 기능의 권한·감사 로그 요구가 겹친다.); x-analytics-09(개인정보 삭제·익명화와 로그에 PII를 남기지 않는 기준이 일부 겹친다.)'
    value: 회원·유료·관리자 + 데이터 접근 정책까지
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자용 인증·권한 구현 스킬로 산출물, 절차, 검증 기준이 매우 구체적이어서 바로 승격 가능하다.  리스크: refresh를 HttpOnly 쿠키로 고정하면 네이티브 모바일, 순수 API 클라이언트, 크로스도메인 배포에서는 별도 저장·CSRF·CORS 전략이 필요하다.; access 토큰을 메모리에 둔다는 규칙은 SSR 프레임워크나 서버 컴포넌트 기반 앱에서는 세션 전달 방식과 충돌할 수 있다.; bcrypt cost ≥10은 최소선으로는 유용하지만 하드웨어와 지연 예산에 맞춘 튜닝 기준이 추가되면 더 안전하다.; 계정 잠금 5회/15분 규칙은 무차별 대입 방어에 좋지만 사용자 열거, 계정 잠금 DoS, IP·디바이스 기반 rate limit과 함께 설계해야 한다.; 감사 로그 필드가 유용하지만 보존 기간, 접근권한, IP 주소의 개인정보 취급, 로그 위변조 방지 기준이 빠져 있다.; 외부 IdP 사용 시에도 JWT 검증, issuer/audience 확인, JWK rotation, webhook 서명 검증 같은 통합 세부사항은 별도 확인이 필요하다.; 권한 검사를 미들웨어 한 곳에 모으라는 지침은 좋지만 리소스별 소유권 검사가 필요한 경우 과도한 중앙화로 정책 누락이나 우회가 생길 수 있다.'
    action: review
    path: 40_Skills/candidate/x-server-03.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-04
    name: 서버 비즈니스 로직
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-01(클라가 보낸 값과 서버가 신뢰해야 할 원장 값을 나누는 클라/서버 경계 설정과 맞닿아 있다.); x-server-02(상태 컬럼, 엔티티 상태 집합, 원장 테이블 구조를 입력으로 사용하므로 엔티티 초기 설계와 연결된다.); x-server-03(세션 주체와 DB 소유 관계 기반 권한 검증을 다루므로 접근 정책과 영역이 겹친다.); x-server-05(결제·재화·보상처럼 원자성, 멱등성, 중복 지급 방지가 핵심인 쓰기 경로를 함께 다룬다.); x-server-09(유료화 결합 시 결제 상태, 정산 데이터, 멱등성 처리와 연결된다.); x-server-10(외부 부수효과 실패, 보상 트랜잭션, 재시도 큐를 위임 대상으로 명시한다.); x-server-12(정상·실패·동시성·중복 요청을 테스트 게이트로 고정하므로 서버 회귀와 데이터 품질 검증과 맞닿아 있다.); x-platform-05(최소권한과 관리자·유료 권한 보호 관점에서 서버 권한 검증과 의미적으로 연결된다.); x-platform-10(핵심 결제·구매 플로우를 자동 검증하는 테스트 관점과 겹친다.)'
    value: 클라 조작 차단 + 트랜잭션 경계 설정
    risk: 'Tier-2 품질 5/5 · 권고 promote · 상태 변경 서버 로직을 계약서와 테스트 게이트로 고정하는 고품질 실무형 스킬이므로 promote가 적절하다.  리스크: HTTP 코드 402, 422, 409의 선택은 프레임워크·API 규약에 따라 다를 수 있으므로 프로젝트 표준과 맞춰야 한다.; Idempotency-Key 저장은 요청 처리 결과 저장과 원자적으로 묶이지 않으면 중복 요청에서 빈 결과나 재실행 위험이 생길 수 있다.; 외부 PG 호출을 트랜잭션 밖으로 빼는 원칙은 맞지만, 결제 승인·캡처·DB 반영 순서와 실패 보상은 PG별 상태 모델을 별도로 확정해야 한다.; Read Committed + FOR UPDATE와 조건부 UPDATE의 선택 기준이 더 구체화되지 않으면 불필요한 락이나 성능 저하를 만들 수 있다.; 단일 엔드포인트 기준 스킬이라 여러 엔티티를 가로지르는 장기 사가나 분산 트랜잭션에는 별도 설계가 필요하다.'
    action: review
    path: 40_Skills/candidate/x-server-04.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-05
    name: 트랜잭션·정합성 설계
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-04(클라 조작 차단과 트랜잭션 경계 설정에서 결제·재화 쓰기 경로의 신뢰 경계와 일부 맞닿는다.); x-server-09(유료화, 결제 멱등성, 정산 데이터와 관련된 결제 지급·중복 방지 영역이 겹친다.); x-server-10(큐 기반 보상 지급, 재시도, 워커 멱등 처리에서 비동기 처리 영역이 겹친다.); x-liveops-07(정합성 사고 이후 데이터 오류 확인, 보상, 사후 대응으로 이어지는 운영 복구 흐름과 맞닿는다.); x-liveops-06(수동 지급·유저 조회·로그 확인 등 원장 기반 수동 운영과 일부 연결된다.); x-analytics-08(클라 로그와 서버 원장 불일치 확인, 지표 이상 원인 추적에서 서버 원장 개념이 겹친다.); x-platform-10(핵심 플로우 자동 검증과 결제·지급 경로의 장애 시나리오 테스트 게이트가 겹친다.); x-platform-13(운영 장애를 테스트로 재현하는 방식과 중복 지급·부분 실패·타임아웃 재현 테스트가 겹친다.); x-server-12(서버 변경 회귀와 데이터 품질 검증에서 DB 최종 상태 기준 검증이 겹친다.)'
    value: 결제·재화·보상을 원자적으로 보장할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 정합성 모델 선택부터 테스트 게이트까지 실전성이 높아 바로 카탈로그에 올릴 만한 고품질 스킬이다.  리스크: DB별 차이를 더 명시해야 한다. 예를 들어 SQLite는 SELECT FOR UPDATE가 없고, MySQL 버전·스토리지 엔진에 따라 CHECK 제약이나 락 동작 차이가 있다.; 외부 호출을 트랜잭션 밖으로 뺀다는 원칙은 좋지만, B 모델에서 pending 레코드 선점·상태 전이·재개 워커의 소유권 처리까지 구현하지 않으면 pending 중복 처리 경쟁이 생길 수 있다.; 불확실 오류에서 ''재시도 금지''와 ''멱등키로 재호출 허용''의 조건을 구현자가 혼동할 수 있으므로 외부 API의 멱등 보장 여부를 확인하는 게 필수다.; READ COMMITTED 기본 권고는 1인 규모에 실용적이지만, 범위 조건 재고 차감·예약·쿠폰 발급처럼 팬텀/쓰기 스큐가 문제 되는 케이스는 추가 판단이 필요하다.; append-only 원장은 강하게 권고되어 좋지만, 원장 합계와 wallet 스냅샷 간 불일치 검증 잡 또는 불변성 제약이 없으면 복구 근거가 약해질 수 있다.'
    action: review
    path: 40_Skills/candidate/x-server-05.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-06
    name: 스키마 마이그레이션
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-02(초기 스키마 설계와 이후 스키마 변경은 같은 데이터 모델 영역을 다루지만, 이 스킬은 운영 중 마이그레이션에 초점이 있다.); x-server-11(백업, PITR, 데이터 손실 대비, 탈퇴·PII 보존 같은 복구·보존 전제가 마이그레이션 안전장치와 직접 연결된다.); x-server-12(서버 변경 후 회귀와 데이터 품질 검증은 마이그레이션 전후 검증 게이트와 겹친다.); x-platform-08(롤링 배포, 앱 롤백, feature flag, canary식 전환이 expand-contract와 dual-read/write 전략에 필요하다.); x-platform-02(반복 배포 안정화와 staging/prod 승인 흐름은 DB 변경의 단계적 배포 절차와 맞닿아 있다.); x-platform-12(배포 전 자동 통과 기준은 마이그레이션 전후 검증 쿼리와 중단 조건을 게이트화하는 부분과 겹친다.); x-release-05(장애 시 되돌리기·패치 경로 판단은 마이그레이션 실패 시 앱 롤백과 contract 지연 전략과 관련된다.)'
    value: 운영 DB 구조 변경 (롤백 가능)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 운영 DB 스키마 변경을 무중단·검증 가능·복구 가능하게 쪼개는 고품질 실전 스킬이다.  리스크: 엔진별 DDL 동작 표가 유용하지만 세부 조건이 많다. MySQL INSTANT/INPLACE 가능 여부, PostgreSQL 버전별 ALTER TABLE 최적화, SQLite 제약은 실제 버전·스토리지 조건에 따라 달라 공식 문서 확인을 강제해야 한다.; 체크섬 예시의 string_agg는 대형 테이블에서 메모리·정렬 비용이 커질 수 있어 표본, 범위별 집계, DB별 해시 전략으로 바꾸는 지침이 있으면 더 안전하다.; NOT NULL 추가는 PostgreSQL에서 CHECK NOT VALID 후 VALIDATE 및 SET NOT NULL 같은 우회 패턴을 쓸 수 있는데, 현재는 위험 회피 원칙은 좋지만 고급 안전 경로가 약간 단순화되어 있다.; 백필 중 쓰기 경합, autovacuum/undo/redo 증가, replication slot 지연, lock_timeout·statement_timeout 설정, 실패한 CONCURRENTLY 인덱스 정리 같은 운영 파라미터가 체크리스트에 더 명시되면 좋다.; 마이그레이션 도구별 트랜잭션 래핑 비활성화, online DDL 옵션 적용법, dry-run/staging 리허설 요구가 출력 템플릿에 별도 항목으로 있으면 적용 실수가 줄어든다.'
    action: review
    path: 40_Skills/candidate/x-server-06.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-07
    name: 쿼리·인덱스 최적화
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-06(운영 DB 구조 변경, 마이그레이션 순서, 롤백 가능성, 무중단 DDL 절차와 맞닿아 있다.); x-server-08(읽기 지연과 부하를 줄이는 목적이 일부 겹치지만, 이 스킬은 DB 쿼리 실행 효율과 인덱스에 집중한다.); x-server-12(변경 후 회귀와 데이터 품질 검증이 일부 겹치며, 이 스킬은 쿼리 성능 전후 검증에 한정한다.); x-platform-07(APM, slow query log, pg_stat_statements, 트레이스 등 병목 관측 단계가 겹친다.); x-platform-11(배포 직후 핵심 동작과 운영 상태 확인 관점에서 인덱스 적용 후 검증 흐름이 일부 닿아 있다.)'
    value: 응답 지연·비용 클 때 (N+1 포함)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 측정→진단→엔진별 설계→운영 안전 적용→전후 검증까지 갖춘 고품질 쿼리·인덱스 최적화 스킬이다.  리스크: MySQL 온라인 DDL의 ALGORITHM=INPLACE, LOCK=NONE은 테이블·인덱스 종류·버전에 따라 거부되거나 실제 잠금 특성이 달라질 수 있어 사전 리허설이 필요하다.; PostgreSQL CREATE INDEX CONCURRENTLY는 트랜잭션 안에서 실행할 수 없으므로 일반 마이그레이션 도구의 기본 트랜잭션 래핑과 충돌할 수 있다.; EXPLAIN ANALYZE는 실제로 쿼리를 실행하므로 운영에서 무거운 SELECT를 반복 실행하거나 DML에 적용할 때 부하·부작용 관리가 필요하다.; 풀스캔이 항상 나쁜 것은 아니다. 작은 테이블, 낮은 선택도, 최신 통계 기반의 합리적 Seq Scan까지 무조건 실패로 보면 과최적화할 수 있다.; 복합 인덱스 컬럼 순서 설명은 실무용으로 좋지만, PostgreSQL에서 등치 조건 컬럼 간 순서의 영향 등 엔진별 세부 예외가 있어 절대 규칙처럼 적용하면 오판할 수 있다.; MongoDB가 포함되어 있지만 실제 절차와 검증 예시는 SQL 중심이라 MongoDB 적용자는 explain 출력 해석과 인덱스 생성 옵션을 별도로 보강해야 한다.'
    action: review
    path: 40_Skills/candidate/x-server-07.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-08
    name: 캐시 전략
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-07(응답 지연·비용 문제를 다루는 상위 병목 대응과 맞닿지만, 이 초안은 캐시로 가기로 한 뒤의 설계 결정에 집중한다.); x-server-01(캐시 무효화 책임이 어느 경계에 있어야 하는지, 엔드포인트·쓰기 경로와 함께 설계해야 한다.); x-platform-07(hit rate, p95/p99, origin QPS, 캐시 장애 탐지 등 운영 메트릭과 장애 감시가 겹친다.); x-platform-05(개인화 차원 누락, PII·권한별 캐시 키 분리, 공유 캐시 누출 위험이 최소권한·데이터 보호와 겹친다.); x-platform-08(CACHE_ENABLED 롤백 스위치, 캐시 레이어 우회, 장애 시 복구 경로가 feature flag·복구 전략과 닿는다.); x-platform-13(Redis kill, 장애 주입, origin 보호 검증처럼 운영 장애를 테스트로 재현하는 흐름이 겹친다.)'
    value: 읽기 부하·지연 줄일 때 (Redis·CDN·TTL)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 캐시 설계를 계층·키·무효화·운영 방어·롤백까지 검증 가능하게 이끄는 고품질 스킬이다.  리스크: 분산 락 예시는 유용하지만 락 만료, 락 소유권 검증, 작업 시간이 EX보다 길어지는 경우를 별도 주의하지 않으면 잘못된 락 해제나 중복 재계산이 생길 수 있다.; TTL 지터가 명시되어 있지 않아 많은 키가 같은 시점에 만료되는 패턴에서는 스탬피드 방어가 핫키 외에도 필요할 수 있다.; Redis 메모리 한도, eviction policy, 직렬화 크기, 네트워크 왕복 비용 같은 저장소 운영 한계가 체크리스트에는 약하게 드러난다.; CDN 캐시에서 Authorization, Cookie, Vary 헤더, Cache-Control 같은 HTTP 캐싱 세부 조건을 놓치면 개인화 누출이나 과소 캐싱이 발생할 수 있다.; write-through/write-behind를 언급하지만 1인 운영에서 구현 복잡도와 실패 복구 절차가 더 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-server-08.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-09
    name: 결제·웹훅 연동
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-02(결제·주문·이벤트 엔티티와 원장 스키마 설계 영역이 맞닿아 있다.); x-server-05(결제 성공 후 권한·재화 지급의 멱등성과 트랜잭션 경계가 직접 연결된다.); x-server-10(웹훅 수신 후 큐 적재, 재시도, DLQ, 정산성 작업 처리와 겹친다.); x-platform-04(웹훅 서명 시크릿, API 키 보관, 로테이션 지침이 포함된다.); x-platform-07(결제 실패·불일치·차지백 알림과 운영 관측, 경보 설계가 맞닿아 있다.); x-monetization-04(환불·부분취소·구독 실패 정책과 결제 후 권한 회수 규칙이 연결된다.); x-analytics-08(서버 원장과 외부 결제/클라이언트 신호 불일치 진단 관점이 겹친다.)'
    value: 유료화 붙일 때 (멱등성·정산 데이터)
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실전성이 높은 결제 웹훅 스킬이지만 플랫폼별 식별자·시간 검증·스키마와 경계 표현을 보정하면 promote 가능하다.  리스크: payments 스키마에 UNIQUE(provider, provider_ref)를 쓰지만 provider 컬럼이 정의되어 있지 않다.; App Store Server Notifications V2의 멱등 키를 transactionId로만 두면 동일 거래에 대한 여러 알림 유형을 구분하기 어렵고 notificationUUID 또는 notification 식별자 고려가 필요하다.; Google Play RTDN의 purchaseToken+orderId 멱등 키는 구독 갱신·취소·상태변경 이벤트에서 충분하지 않을 수 있어 eventTimeMillis, notificationType, 재조회 상태 기반 처리 원칙을 더 명확히 해야 한다.; 모든 플랫폼에 5분 타임스탬프 skew를 일괄 적용하면 지연 도착한 정상 알림 처리와 충돌할 수 있다. Stripe 서명 재전송 시간과 스토어 알림의 signedDate·event time을 구분해야 한다.; 웹훅 raw 기록이라고 설명하지만 스키마는 payload_hash만 저장한다. 감사·재처리 요구가 있으면 암호화 저장 또는 제한 보관 정책을 별도로 정해야 한다.; 경계 설명은 지급 호출 직전까지라고 하지만 의사코드와 예시는 grantEntitlement를 트랜잭션 안에서 호출한다. 이 스킬이 호출 오케스트레이션까지 책임지는지, 내부 지급 원자성만 x-server-05인지 표현을 정리해야 한다.; 영구 오류를 200+failed로 처리하는 지침은 운영 재처리 장치가 없으면 결제 누락을 고착시킬 수 있어 수동 큐·알림·재처리 절차가 필수 전제로 명시되어야 한다.'
    action: review
    path: 40_Skills/candidate/x-server-09.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-10
    name: 백그라운드 작업
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-05(결제·재화·보상 지급의 멱등성, 중복 지급 방지, 원자성 보장과 맞닿아 있다. 이 스킬은 비동기 실행·재시도·DLQ 운영 모델을 다룬다.); x-server-09(유료화·정산 데이터에서 결제 후처리, 멱등성 키, 웹훅 처리와 의미 영역이 겹친다.); x-server-07(응답 지연이 큰 작업을 요청-응답 밖으로 분리하는 판단과 성능 관점이 일부 겹친다.); x-platform-07(dead 잡 알림, queued 깊이, 처리시간 p95 등 운영 관측·장애 탐지 항목이 겹친다.); x-platform-13(좀비 회수, DLQ, 실패 재현 같은 운영 장애 시나리오를 테스트로 확인하는 부분이 겹친다.); x-liveops-07(보상 누락, 장애, 데이터 오류 발생 시 알림·수동 복구·사후 처리 흐름과 접점이 있다.); x-liveops-06(수동 지급, 재처리 SQL, 운영자가 개입하는 dead 잡 처리 도구와 겹친다.)'
    value: 푸시·정산·보상 지급 (큐·재시도)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 개발자가 백그라운드 작업을 안전하게 설계·운영하도록 이끄는 매우 실전적인 고품질 스킬이다.  리스크: Postgres 중심의 `FOR UPDATE SKIP LOCKED` 전제가 강해 SQLite·서버리스·관리형 제한 환경에서는 대체 락 전략이 필요하다.; 웹훅은 무조건 200을 먼저 반환하는 것으로 오해될 수 있다. 최소한 이벤트가 내구성 있게 저장된 뒤 200을 반환해야 한다.; `jobs.idempotency_key UNIQUE`를 전역으로 둘 경우 같은 비즈니스 키의 재처리·보정 잡까지 막을 수 있어 잡 타입과 처리 결과 테이블의 유니크 범위를 설계해야 한다.; 긴 작업을 DB 트랜잭션 안에서 계속 수행하면 락 보유 시간이 길어질 수 있으므로 claim과 실제 처리를 분리하는 구현 지침이 보강되면 더 안전하다.; `failed` 상태와 재시도용 `queued` 상태의 관계가 약간 혼재되어 있어 실제 상태 머신 정의 시 중간 실패 기록 방식이 명확해야 한다.; 시간대, DST, cron 중복 실행, 외부 API rate limit 같은 운영 전제가 프로젝트별로 추가 확인되어야 한다.'
    action: review
    path: 40_Skills/candidate/x-server-10.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-11
    name: 백업·개인정보 분리
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-09(분석 파이프라인에서 원본 식별자 제거, 익명화, 삭제 요청 반영과 맞닿아 있다.); x-compliance-06(탈퇴·열람·삭제 요청 처리 중 백업과 로그에 남은 개인정보를 어떻게 처리할지 연결된다.); x-platform-04(시크릿·키 관리, KMS, 평문 dump 금지, 키 escrow와 겹치는 운영 보안 영역이 있다.); x-platform-05(PII 접근권한, 관리자 export 금지, 권한 경계와 일부 맞닿는다.); x-platform-08(장애·침해 복구 시 사용하는 백업의 품질, 복구 절차, 복원 후 조치와 겹친다.); x-server-12(복구 후 행 수·외래키·체크섬 등 데이터 무결성 검증이 데이터 품질 회귀 검증과 연결된다.); x-server-06(DB 구조 변경과 백업·롤백·복원 가능성 점검이 운영 DB 변경 안전성 측면에서 맞닿는다.)'
    value: 손실 대비·규정 준수 (PITR·PII 익명화·탈퇴)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 운영자가 백업과 개인정보 삭제 가능성을 실제로 설계·검증하게 만드는 완성도 높은 서버/데이터 운영 스킬이다.  리스크: crypto-shred는 사용자별 또는 데이터 범위별 키 설계가 선행되지 않으면 나중에 적용하기 어렵다.; 법적 보관기간과 삭제권의 해석은 서비스 유형·국가·데이터 종류별로 달라질 수 있어 법률 자문 없이 단정하면 위험하다.; tombstone ledger 자체가 영구 원장이므로 유출·손상·삭제 방지를 위한 별도 보호와 백업 정책이 필요하다.; 매니지드 PITR, CRR, 버전관리, lifecycle 기능은 벤더·요금제별 제약이 있어 실제 스택별 확인 절차가 추가되면 더 안전하다.; 백업 암호화 키를 잃으면 복구가 불가능하므로 키 백업과 접근통제의 균형을 구체적으로 운영해야 한다.'
    action: review
    path: 40_Skills/candidate/x-server-11.md
    ecosystem: 'partial:sprint-web'
  - id: x-server-12
    name: API·데이터 테스트
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-01(PR 머지 전 자동 품질 게이트라는 흐름이 겹치지만, 이 스킬은 서버/API/데이터 회귀 검증에 특화되어 있다.); x-platform-03(테스트 DB 격리, 시드, 재현 조건이 겹치지만, 여기서는 API·데이터 게이트가 의존하는 최소 실행 조건으로 다룬다.); x-platform-10(자동 테스트 게이트라는 점이 겹치지만, x-platform-10은 핵심 사용자 플로우 E2E 중심이고 이 스킬은 서버 계약·DB·데이터 품질 중심이다.); x-platform-12(배포 전 자동 통과 기준과 겹치지만, 이 스킬은 배포 종합 체크가 아니라 API·데이터 변경의 회귀 차단 기준을 세분화한다.); x-platform-13(운영 장애를 테스트로 재현하는 관점과 맞닿아 있으며, 이 스킬의 FAIL 사례를 회귀 테스트로 고정하는 데 연결될 수 있다.); x-server-01(API 계약과 스키마를 다루지만, x-server-01은 설계 경계 설정이고 이 스킬은 이미 정해진 계약의 회귀 검증이다.); x-server-03(인증·인가와 데이터 접근 정책이 겹치며, 이 스킬은 그 정책이 깨지지 않았는지 음성 케이스로 검증한다.); x-server-05(결제·원자성·멱등성 영역과 겹치며, 이 스킬은 결제/웹훅 변경 후 중복 생성 회귀를 테스트한다.); x-server-06(DB 마이그레이션과 롤백 가능성이 겹치지만, x-server-06은 변경 운영 절차이고 이 스킬은 마이그레이션 회귀 게이트다.); x-server-07(응답 지연, N+1, 쿼리 성능과 겹치며, 이 스킬은 변경된 쿼리의 p95와 실행계획을 회귀 기준으로 둔다.); x-server-09(유료화·결제 멱등성·정산 데이터와 겹치며, 이 스킬은 결제 API 변경의 테스트 게이트로 적용된다.)'
    value: 서버 변경 회귀 + 데이터 품질 검증
    risk: 'Tier-2 품질 4/5 · 권고 revise · 매우 실전적인 API·데이터 회귀 게이트 스킬이지만, 몇몇 예시 명령과 성능 기준이 그대로 쓰기엔 오판 위험이 있어 수정 후 승격이 적절하다.  리스크: T3 예시의 `psql ... | grep -qx 0`은 여러 assertion 중 하나만 0이어도 성공할 수 있어 전체 위반 검출 게이트로는 위험하다. 모든 행이 0인지 `awk`나 SQL 집계로 확인해야 한다.; T2 명령은 up→down→up만 실행하고 실제 row count 보존이나 스키마 diff 확인 명령은 포함하지 않아 체크리스트와 명령 예시 사이에 간극이 있다.; T6의 `Seq Scan 없음`은 항상 올바른 기준이 아니다. 작은 테이블, 통계 상태, PostgreSQL 플래너 판단에 따라 Seq Scan이 정상일 수 있어 행 수와 쿼리 특성별 예외 기준이 필요하다.; p95 < 300ms 같은 기본값은 프로젝트와 환경에 따라 부적절할 수 있으며, 로컬/CI 성능 흔들림으로 flaky test가 될 수 있다.; OpenAPI 스키마가 실제 구현과 동기화되지 않은 프로젝트에서는 T1이 거짓 안정감을 줄 수 있으므로 스키마 소스 오브 트루스 전제가 필요하다.; 마이그레이션 down을 모든 프로젝트에서 요구하면 의도적으로 irreversible한 데이터 삭제·정규화 작업과 충돌할 수 있어 예외 승인 절차가 필요하다.; 외부 결제/웹훅 테스트는 테스트 키, mock, 서명 검증, 재시도 이벤트 순서까지 정하지 않으면 실제 운영 위험을 충분히 덮지 못할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-server-12.md
    ecosystem: 'partial:sprint-web'
  - id: x-writer-01
    name: 보이스·톤 가이드
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-writer-02(첫 사용 동선 카피가 이 보이스·톤 규칙표를 적용해 실제 온보딩 문구를 작성한다.); x-writer-03(버튼·에러·빈상태 문구의 길이, 금지어, 복구 안내 원칙이 직접 연결된다.); x-writer-04(스토어 제목·설명·스크린샷 문구도 동일한 보이스와 어휘 사전을 따라야 한다.); x-writer-05(점검·사과·변경 공지의 톤 모듈레이션과 강제 문구 보존 원칙이 겹친다.); x-writer-06(번역 가능성, 토큰 변수, 관용구 금지 규칙이 문자열 분리·다국어 구조와 맞닿아 있다.); x-liveops-12(고객 응대 기준과 표준 답변이 같은 호칭·높임말·금지어 사전을 참조한다.); x-liveops-03(앱내공지·점검·노트 등 운영 전달문에서 상황별 톤 원칙을 적용한다.); x-liveops-07(장애·데이터 오류 시 공지와 사과 문구에 책임·격식·복구 시점 원칙이 연결된다.); x-marketing-02(스토어 페이지 설명과 전환 중심 카피가 제품 보이스 기준을 공유한다.); x-marketing-05(리뷰 답변과 평판 회복 커뮤니케이션에서 호칭, 사과, 책임 톤이 겹친다.); x-compliance-03(앱스토어·플레이 심사 문구와 플랫폼 강제 문구를 톤 조정에서 제외하는 기준이 관련된다.)'
    value: 제품 인격·용어를 통일할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 상위 보이스·톤 기준을 만들기 위한 절차, 검증 기준, 예시가 매우 구체적이어서 바로 카탈로그에 올릴 만하다.  리스크: 글자수 기준이 한국어 중심이라 영어·일본어 등으로 확장할 때는 문자 수가 아니라 UI 폭, 줄바꿈, 현지 관용 표현 기준을 별도로 조정해야 한다.; 금지어 grep은 맥락을 보지 못해 오탐·누락이 생길 수 있으므로 최종 판단을 자동 검사에만 맡기면 안 된다.; 법적·플랫폼 강제 문구를 원문 보존하라는 원칙은 좋지만, 어떤 문구가 강제 문구인지 판단하려면 별도 정책·법무 확인이 필요하다.; 보이스 4축 점수가 숫자로 보이지만 절대 기준은 아니므로, 팀이나 후속 작성자가 점수만 보고 반례 문장을 무시하면 실효성이 떨어진다.; 문의 감소 같은 출시 후 지표는 트래픽·기능 변경·지원 채널 변화의 영향을 받으므로 카피 개선 효과로 단정하기 어렵다.'
    action: review
    path: 40_Skills/candidate/x-writer-01.md
    ecosystem: 'partial:product-spec'
  - id: x-writer-02
    name: 온보딩·튜토리얼 문구
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-writer-01(온보딩 문구의 톤·용어·제품 인격 기준을 입력으로 사용하므로 제품 문장 일관성 영역이 맞닿는다.); x-writer-03(버튼, 빈상태, 권한 안내, CTA 같은 마이크로카피를 다루지만 이 스킬은 첫 세션 흐름 안으로 범위를 제한한다.); x-writer-06(온보딩 문구 산출 시 문자열 키 이름과 번역 분리 핸드오프를 포함한다.); x-analytics-03(튜토리얼·가입 흐름 이탈 단계와 completion/activation 수치를 입력으로 삼는다.); x-analytics-06(온보딩 변경의 통과선, 검증 게이트, 활성화 지표 측정과 연결된다.); x-liveops-08(신규 사용자 생애주기 개입과 첫 세션 경험 개선이라는 운영 관점에서 일부 접점이 있다.); x-marketing-02(전환 중심 설명과 CTA 작성이라는 카피 목적은 유사하지만, 대상은 스토어 페이지가 아니라 제품 내부 온보딩이다.)'
    value: 첫 사용 동선의 카피를 쓸 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 첫 세션 온보딩 문구 작성에 필요한 입력·절차·검수·산출이 구체적이고 검증 가능해 바로 승격할 만하다.  리스크: ''헤드라인 6단어 이하''와 ''한국어 60자 이하'' 기준은 제품·도메인 복잡도에 따라 너무 빡빡할 수 있어 예외 판단 기준이 있으면 더 좋다.; 화면 설계가 아니라고 못박았지만 강제 단계 수를 줄이는 판단은 플로우 설계와 맞물려 있어 실제 적용 시 역할 경계가 흔들릴 수 있다.; 권한 요청 문구는 플랫폼 정책과 민감 권한 종류에 따라 표현 제한이 있을 수 있는데, 컴플라이언스 확인 절차는 약하다.; A/B 없이 before/after 자기검수만 하는 M 규모에서는 효과 판단이 주관적으로 흐를 수 있다.; 영어 12단어 기준은 제시됐지만 다국어·로컬라이징 시 문장 길이 팽창에 대한 운영 기준은 부족하다.'
    action: review
    path: 40_Skills/candidate/x-writer-02.md
    ecosystem: 'partial:sprint-game'
  - id: x-writer-03
    name: 마이크로카피
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-writer-01(제품 톤·용어집을 입력으로 받아 용어 일관성을 적용하므로 제품 인격·용어 통일 영역과 맞닿아 있다.); x-writer-02(온보딩 화면의 버튼, 빈상태, 권한 요청 문구를 실제 문자열 단위로 다듬을 때 겹친다.); x-writer-04(짧은 CTA, 제목, 설명 문구의 전환 중심 표현 기준 일부가 UI 마이크로카피와 겹친다.); x-writer-05(운영 공지·장애·점검 등 사용자-facing 짧은 문구에서 에러/토스트/안내 표현 기준이 일부 겹친다.); x-writer-06(i18n 키 제안, 문자열 길이, 번역 가능성 점검이 문자열 분리·번역 구조와 연결된다.); x-compliance-01(개인정보·약관 문구를 UI에 노출할 때 법무 원문과 표현 일치 여부를 확인한다.); x-compliance-02(권한 요청, 추적 동의, 개인정보 동의 문구 작성 시 정책·동의 요건과 맞닿는다.); x-compliance-03(앱스토어·플레이 결제, 구독, 권한 문구가 심사 리젝 예방 기준과 겹친다.); x-compliance-05(연령, 결제 제한, 환불 고지 문구에서 정책 문구 확인이 필요하다.); x-monetization-03(결제를 언제 어디서 띄울지 정한 뒤 실제 결제 버튼·구독 설명 문구를 작성할 때 연결된다.); x-monetization-04(첫구매, 할인, 환불 규칙이 사용자에게 보이는 결제·환불 문구로 표현될 때 겹친다.); x-liveops-03(앱내공지나 변경 전달 화면의 짧은 CTA·토스트·확인 문구 작성 기준과 일부 겹친다.); x-liveops-10(셀프서비스 지원 화면의 빈상태, 에러, 안내 문구를 다듬는 데 사용할 수 있다.); x-release-03(심사 제출 전 메타데이터·정책 대응 중 UI 내 권한·결제 문구 점검과 연결된다.)'
    value: 버튼·빈상태·에러·확인 문구를 다듬을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · UI 마이크로카피를 실제 출시 문자열 단위로 검증·수정하게 만드는 매우 구체적이고 실무적인 고품질 스킬이다.  리스크: 컴플라이언스 게이트에서 Apple·Google 정책을 다루므로 실제 적용 시 최신 정책 확인이 필요하다.; ''창작 금지, 정책 대조만''이라는 표현은 안전하지만, 어떤 경우에는 정책 원문 그대로 인용이 아니라 제품 UI에 맞춘 정확한 고지가 필요할 수 있어 법무·컴플라이언스 역할과 경계를 명확히 해야 한다.; 버튼 한글 7자, 토스트 40자 같은 숫자 기준은 플랫폼·폰트·화면 폭에 따라 달라질 수 있어 실제 UI 렌더링 검증이 필요하다.; ''탈퇴할게요'', ''삭제할게요'' 같은 1인칭 캐주얼 문구는 제품 톤이나 법적 민감도에 따라 부적절할 수 있으므로 용어집·톤 입력이 없을 때 기본값을 신중히 정해야 한다.; 금지표현 목록이 강하게 제시되어 있어 기술적 장애나 보안 경고처럼 명시적 위험 고지가 필요한 상황에서는 예외 기준이 필요하다.'
    action: review
    path: 40_Skills/candidate/x-writer-03.md
    ecosystem: 'partial:sprint-web'
  - id: x-writer-04
    name: 스토어·랜딩 카피
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-01(스토어 등록 전 이름·부제·키워드·카테고리와 맞닿지만, 이 초안은 결정된 키워드/카테고리를 받아 실제 카피 슬롯을 작성하는 쪽에 초점이 있다.); x-marketing-02(스토어 페이지 설명과 노트 작성 영역이 직접 겹친다. 이 초안은 문구 생산, 글자수 제약, 리젝 회피, 첫 노출 카피 구조를 더 세밀하게 다룬다.); x-marketing-03(스크린샷 순서·미리보기 영상의 전환 최적화와 스크린샷 캡션 작성이 맞닿는다.); x-marketing-06(랜딩·CTA·캠페인 문구와 연결된다. 이 초안은 특히 스토어와 제품 랜딩의 슬롯별 카피에 집중한다.); x-marketing-07(설치단가·전환 개선을 위한 소재·CTA 개선과 겹치며, 이 초안의 전환 검증 게이트가 해당 분석과 연결된다.); x-analytics-07(스토어·랜딩 카피의 전환 검증 지표를 사용하지만, 지표 설계 자체는 입력으로 받는 구조다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방과 금지 표현 검사 영역이 겹친다. 이 초안은 정책 전체가 아니라 문구 표현 리스크에 한정한다.); x-release-03(메타데이터·심사·정책 대응과 스토어 카피 제출 전 검증이 겹친다.); x-writer-01(보이스·용어 정의를 입력으로 받아 카피에 적용한다.); x-writer-02(첫 사용 동선 카피와 전환 중심 문구 작성 원리가 일부 겹치지만, 이 초안은 설치/가입 전 외부 페이지 카피에 초점이 있다.); x-writer-03(CTA, 가격 문구, 짧은 UI성 문구를 다듬는 영역이 일부 겹친다.); x-monetization-01(가격·구독 구조를 카피에 반영하므로 가격 패키징 결정 결과를 받아 쓰는 접점이 있다.); x-monetization-02(구독 티어·IAP 구조를 설명하는 가격 문구 작성에서 연결된다.); x-marketing-04(출시 직전 심사·가격·지역 준비 중 스토어 메타데이터 문구와 겹친다.); klv:gtm(ASO와 유통 경로 설계의 실행물로 스토어 카피와 전환 게이트가 연결된다.)'
    value: 제목·설명·스크린샷 문구를 쓸 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 스토어·랜딩 카피를 실제 제출 가능한 슬롯 단위로 생산하고 검증하게 만드는 완성도 높은 실무형 스킬이다.  리스크: App Store, Google Play, Steam의 글자수·노출 정책은 바뀔 수 있으므로 실제 제출 시점에는 콘솔/공식 문서 확인이 필요하다.; 한국어의 ''자'' 계산, 공백 포함 여부, 콘솔 표시 길이, 디바이스별 줄바꿈이 다를 수 있어 단순 문자수 카운터만으로는 부족할 수 있다.; Apple 4.3을 ''근거 없는 1위 주장''과 직접 연결하는 식의 정책 매핑은 다소 거칠 수 있어 리젝 사유 표기는 보수적으로 확인해야 한다.; 전환율 합격선 수치가 장르·국가·유입 품질·가격 모델에 따라 크게 달라질 수 있어 절대 기준처럼 쓰면 오판할 수 있다.; Steam 카피 슬롯과 태그/캡슐/짧은 설명의 실제 운영 제약은 App Store·Play보다 덜 구체화되어 있어 Steam 전용 작업에는 보강이 필요하다.; 의학·금융·아동 대상 앱처럼 고위험 카테고리는 문구 검사만으로 부족하고 별도 규정 검토가 필요하다.; 다국어 랜딩이나 현지화 카피에서는 단어 수, 톤, 금지 표현, 가격 표기 관습이 달라 추가 절차가 필요하다.'
    action: review
    path: 40_Skills/candidate/x-writer-04.md
    ecosystem: 'partial:sprint-app'
  - id: x-writer-05
    name: 공지·릴리즈·푸시 문구
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-liveops-03(앱내공지·점검·패치노트처럼 사용자에게 변경을 전달하는 운영 커뮤니케이션 영역이 겹친다.); x-liveops-04(푸시 발송, 세그먼트, 딥링크, 재방문 유도 문안에서 겹친다.); x-liveops-07(장애·보상·사후공지의 사과, 원인, 재발방지, 보상 커뮤니케이션이 겹친다.); x-compliance-03(스토어 릴리즈 노트와 심사 표현, 메타데이터 정확성 검토가 겹친다.); x-release-03(릴리즈 메타데이터·심사 대응 문구와 패치노트 표현 영역이 겹친다.); x-release-06(변경 사항, 알려진 이슈, 운영 인계 내용을 사용자용 릴리즈 노트로 정리하는 부분이 겹친다.); x-writer-01(제품 톤앤매너와 용어 일관성을 운영 문안에 적용해야 하므로 접점이 있다.); x-writer-06(현지화 길이 재측정과 숫자·버전·시각 불일치 방지에서 번역 가능 구조와 겹친다.); x-marketing-06(푸시·이메일·SNS 등 행동 유도형 캠페인 문안과 일부 겹친다.)'
    value: 운영 커뮤니케이션을 쓸 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 운영 커뮤니케이션 문안을 종류별로 안전하게 분기해 작성·검증하게 만드는 완성도 높은 스킬이다.  리스크: 플랫폼별 실제 푸시 미리보기 길이와 스토어 노출 방식은 기기·OS·언어에 따라 달라 고정 글자수만으로는 충분하지 않을 수 있다.; 고위험 공지의 2시간 또는 24시간 숙성은 이미 사실이 확정된 장애·보안·결제 사고의 1차 안내를 지연시키면 오히려 신뢰 리스크가 될 수 있어 ‘초기 공지’와 ‘상세 사후공지’를 구분하는 전제가 필요하다.; 법적 책임, 환불, 개인정보 침해, 아동 대상 서비스 같은 고위험 문안은 이 스킬만으로 확정하면 안 되고 별도 컴플라이언스 확인이 필요하다.; 릴리즈 노트에서 4섹션을 항상 요구하면 아주 작은 핫픽스나 스토어별 제한 문맥에서는 과한 형식이 될 수 있다.; ‘버그 수정 및 안정성 개선’ 반복 금지를 리젝 사유처럼 단정한 부분은 스토어 정책 변화나 심사 맥락에 따라 과장될 수 있다.'
    action: review
    path: 40_Skills/candidate/x-writer-05.md
    ecosystem: 'partial:sprint-game'
  - id: x-writer-06
    name: 현지화 준비
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-writer-01(용어집·톤 가이드가 현지화 리소스의 입력으로 연결된다.); x-writer-03(버튼·빈상태·에러 문구를 직접 쓰지는 않지만 해당 문구를 키화하고 QA하는 지점이 맞닿아 있다.); x-writer-04(제품 밖 스토어 문구 지역화와 제품 안 문자열 지역화가 출시 언어 준비라는 상위 맥락을 공유한다.); x-platform-12(키 무결성, 하드코딩 잔존, pseudo-loc 같은 자동 통과 기준을 CI 게이트로 거는 부분이 겹친다.); x-release-01(출시 전 QA 체크리스트 안에 현지화 QA 증거가 포함될 수 있다.); x-compliance-04(CJK/RTL 폰트 임베드와 글리프 확인은 폰트 라이선스 검토와 연결된다.)'
    value: 문자열 분리·번역 가능 구조로 만들 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 현지화 준비 역할에 매우 적합한 고품질 스킬이며, 몇 가지 운영 설정 주의만 보강하면 바로 카탈로그에 올릴 만하다.  리스크: React grep 예시는 JSX 문자열 탐지의 보조 수단으로는 좋지만 false positive/false negative가 많아 ESLint나 i18n extraction 도구가 주 판정이어야 한다.; i18next saveMissing는 운영 환경에서 켜면 의도치 않은 키 생성이나 원격 리소스 오염 위험이 있어 개발/CI 전용 설정을 명시하면 더 안전하다.; 동일 의미 1키 원칙은 과도하게 적용하면 문맥별 번역 차이를 막을 수 있으므로 키마다 description/context를 요구하는 보완이 필요하다.; ‘누락 키 0’ 기준과 fallback 허용이 동시에 있어, 출시 빌드에서는 누락 0을 강제하고 개발 중에만 fallback 경고를 허용한다고 구분하면 더 명확하다.; 복수형 경계값 0/1/2/11은 영어권에는 유용하지만 아랍어·슬라브어 등 복잡한 plural rule 언어에는 부족할 수 있다.; Unity의 unity_script_search는 일반 도구명이 아니어서 실제 사용 가능한 검색 명령이나 패키지 기준으로 바꾸면 재현성이 높아진다.'
    action: review
    path: 40_Skills/candidate/x-writer-06.md
    ecosystem: 'partial:superpowers'
  - id: c-architect-06
    name: 코드 표준·리뷰 게이트
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-architect-04(리포 구조, CI, 배포 타깃과 연결되는 품질 게이트·자동화 기준 설정 영역이 겹친다.); c-architect-05(비용·리스크·유지보수성을 기준으로 기술 결정을 비교하고 게이트를 세우는 부분이 겹친다.); c-planner-02(수용기준, 비목표, 완료 기준을 명세해 구현 가능 상태로 만드는 구조가 겹친다.); c-planner-07(구현 전 준비도, 완료 기준, 실패 기준, 증거를 점검하는 절차가 매우 유사하다.); klv:first-packet(구현 전에 목표, 범위, 실행 패킷, 검증 게이트를 정리해 넘기는 산출물 구조가 겹친다.); workflow-translator(거친 개발 요청을 구현 가능한 계획과 검증 기준으로 변환하는 부분이 일부 겹친다.)'
    value: 네이밍·테스트·리팩터 기준을 세울 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 코드 품질 기준과 리뷰 게이트를 실행 가능한 패킷으로 만드는 데 충분히 구체적이므로 승인 가능하나, 스택별 예시 보강이 있으면 더 강해진다.  리스크: 보강 체크리스트에 Tier-2 지적 문장이 그대로 남아 있어 최종 스킬 문서로는 미정리된 느낌을 줄 수 있다.; 언어·프레임워크별 실제 기준 예시가 없어 사용자가 포매터, 린터, 커버리지, 보안 스캔 기준을 임의로 정할 가능성이 있다.; 코드 표준과 리뷰 게이트를 동시에 다루기 때문에 작은 작업에는 산출물이 과해질 수 있다.; 통과/실패 기준을 관찰 가능한 증거로 쓰라고 하지만 최소 기준 예시가 부족해 여전히 추상적으로 작성될 위험이 있다.; 공식 문서 확인 경로가 일반 문구 수준이라 실제 링크나 프로젝트 내 규칙 파일을 강제하지 않으면 근거 추적성이 약해질 수 있다.'
    action: review
    path: 40_Skills/candidate/c-architect-06.md
    ecosystem: 'delegate:superpowers'
  - id: c-planner-07
    name: 게이트 체크
    category: common
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-01(무엇을 왜 누구에게 만들지 한 장으로 정리하는 초기 제품 판단과 목표 고정 영역이 겹친다.); c-planner-02(기능을 수용기준, 비목표, 완료 기준과 함께 명세하는 실행 전 산출물 구조가 겹친다.); c-planner-04(MVP와 이후 범위를 자르고 나중으로 미룰 것을 정하는 범위 결정 절차가 겹친다.); c-planner-05(가치, 노력, 리스크 기준으로 대안을 비교하고 우선순위를 정하는 판단 방식이 겹친다.); c-planner-06(불확실성, 리스크, 실패 조건을 명시하고 검증 게이트를 세우는 부분이 겹친다.); klv:first-packet(구현에 넘기기 전 계획 전용 패킷을 만들고 완료 기준을 정하는 목적이 유사하다.); workflow-translator(막연한 요청을 구현 가능한 계획과 체크리스트로 변환하는 산출물 지향성이 겹친다.)'
    value: 구현에 넘기기 전 준비도를 점검할 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 구현 전 의사결정을 짧은 실행 패킷과 검증 게이트로 바꾸는 품질 좋은 공통 기획 스킬이다.  리스크: 트리거가 넓어 어떤 의사결정에 반드시 이 스킬을 써야 하는지 경계가 흐릴 수 있다.; 평가 기준이 가치, 노력, 리스크처럼 일반어 중심이라 점수화 또는 판정 방식이 없으면 주관적 비교에 머물 수 있다.; 예시가 너무 추상적이어서 실제 화면 기능, API 변경, 출시 판단 같은 현실 사례를 따라 하기 어렵다.; 검증 게이트의 통과/실패 기준을 어느 정도 구체적으로 써야 하는지 기준선이 부족하다.'
    action: use
    path: 40_Skills/candidate/c-planner-07.md
    ecosystem: 'delegate:gatecraft'
  - id: g-client-05
    name: Input System·카메라
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-01(InputManager/CameraManager 같은 매니저 구조와 씬 기본 세팅을 다루므로 초기 클라이언트 뼈대 작업과 맞닿는다.); g-client-02(플레이 가능한 최소 루프에서 이동, 점프, 카메라 추적은 핵심 조작 구현에 해당한다.); g-client-03(UI 입력 맵, EventSystem, 모달 입력 차단, 프롬프트 아이콘 전환이 UI 구현 영역과 겹친다.); g-client-06(리바인딩 저장/복원과 PlayerPrefs JSON 사용이 저장/복원 기능과 일부 겹친다.); g-qa-01(입력·카메라 검증 게이트와 증거 기준을 정의하므로 테스트 설계와 겹친다.); g-qa-03(레거시 입력 마이그레이션 및 UI/게임 입력 충돌 방지 검증은 회귀 확인과 관련된다.); g-qa-05(지원 디바이스와 해상도별 검증 항목이 여러 기기·해상도 검증과 겹친다.); g-ux-01(UI 모달과 게임플레이 입력 전환, 화면 흐름 중 입력 상태 관리가 UX 흐름 정의와 맞닿는다.); g-ux-03(프롬프트 아이콘, 버튼 입력, HUD/UI 입력 규칙 표준화와 관련된다.); g-ux-04(카메라 흔들림, 연출 카메라 전환, 멀미 방지 같은 체감 연출 설계와 겹친다.); g-director-04(기능의 수용기준과 비목표를 검증 가능한 게이트로 못박는 방식이 겹친다.); g-director-09(터치/모바일, 연출 카메라 등을 이번 사이클 제외 범위로 자르는 MVP/V1 범위 결정과 관련된다.)'
    value: 신 Input System으로 조작·뷰를 짤 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 입력·카메라 구현을 실제 완료 가능한 절차와 검증 증거로 잘 묶은 고품질 클라이언트 스킬이다.  리스크: R3와 MonoSingleton을 전제로 한 예시라 프로젝트에 해당 라이브러리나 관행이 없으면 그대로 적용하기 어렵다.; Cinemachine 2.x/3.x API 차이를 경고하긴 하지만 실제 프로젝트 버전에 따라 컴포넌트명과 입력 연결 방식이 달라 추가 확인이 필요하다.; `@Game` 래퍼 클래스명은 실제 에셋 이름과 C# 생성 설정에 의존하므로 초보자가 그대로 복사하면 컴파일 오류가 날 수 있다.; 모바일 터치 입력은 가상 스틱 구현 방식, Safe Area, UI 터치 우선순위까지 추가 설계가 필요하지만 본문에서는 상대적으로 얕다.; 리바인딩 충돌 검사 기준이 개념 수준이라 복합 바인딩, 같은 액션 내 중복, 디바이스별 바인딩 그룹 처리까지는 별도 구현 판단이 필요하다.; 멀미 검증의 ''30분 플레이 시 멀미 메모 0건''은 표본이 작고 주관적이므로 보조 기준으로만 써야 한다.'
    action: review
    path: 40_Skills/candidate/g-client-05.md
    ecosystem: 'partial:unity-mcp'
  - id: g-director-10
    name: 로드맵·게이트
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-director-01(핵심 재미 한 문장을 게이트 합격 지표로 번역하므로 원페이저의 재미·타깃 정의와 맞닿아 있다.); g-director-04(기능 단위 수용기준은 아니지만, 마일스톤 단위의 통과 기준과 완료 정의를 숫자로 고정한다는 점에서 인접하다.); g-director-09(Prototype/MVP/V1/Later 범위 컷 결과를 시간축에 배치하고, 시간박스 초과 시 다시 범위 컷으로 되돌리는 흐름이 연결된다.); g-qa-01(게이트 통과 증거로 테스트 결과·로그·빌드 검증을 요구하므로 검증 계획과 영역이 겹친다.); g-qa-02(외부 테스터 모집, 녹화, 설문, 피드백 관찰을 게이트 증거로 쓰므로 플레이테스트 피드백 구조화와 겹친다.); g-qa-04(G3에서 P0/P1 버그 0을 요구하므로 버그 심각도 분류 체계에 의존한다.); g-qa-05(타깃 기기 fps와 실기기 검증을 출시 게이트에 포함하므로 기기·해상도 검증과 맞닿아 있다.); g-client-07(성능 기준과 Unity Profiler 캡처를 게이트 증거로 쓰므로 최적화·성능 점검과 연결된다.); g-client-08(스토어 빌드, 서명, 제출, 플랫폼 빌드 검증을 Ship 게이트에 포함한다.)'
    value: 마일스톤 + 구현 넘기기 전 준비도 점검
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 게임 개발의 로드맵 진행을 재미 검증 게이트로 통제하는 목적에 매우 잘 맞는, 구체적이고 실행 가능한 스킬이다.  리스크: 모든 게임에 5단계 마일스톤을 고정 적용하면 초소형 게임잼, 실험적 장난감, 라이브 서비스형 업데이트에는 다소 과할 수 있다.; G0/G1 표본 수는 1인 개발 현실에는 적절하지만, 친구·커뮤니티 표본 편향 때문에 시장성 검증으로 과대해석하면 위험하다.; G3의 평균 세션 중도이탈률은 ''측정됨''만 있고 합격 임계값이 없어 실제 출시 판단 기준으로는 약할 수 있다.; 시간박스가 아트·사운드 외주 여부, 장르 복잡도, 플랫폼 심사 난이도에 따라 크게 흔들릴 수 있으므로 보정 규칙이 필요할 수 있다.; Nielsen의 5명 근거는 UX 문제 발견에는 유용하지만 재미·구매 의향 검증의 충분조건은 아니므로 표현을 조심해야 한다.'
    action: review
    path: 40_Skills/candidate/g-director-10.md
    ecosystem: 'delegate:gatecraft'
  - id: klv:first-packet
    name: 첫 작업 패킷
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-04(MVP/V1/Later 범위 자르기와 이어지며, 큰 범위를 첫 실행 가능한 슬라이스로 더 작게 내리는 지점이 맞닿는다.); c-planner-05(이미 정해진 1순위 항목을 입력으로 받으므로 우선순위 결정 산출물과 직접 연결된다.); c-planner-07(구현에 넘기기 전 상태를 다룬다는 점에서 인접하지만, 이 초안은 준비도 점검보다 첫 작업 패킷 생성에 초점이 있다.); workflow-translator(막연한 개발 요청을 구현 가능한 형태로 바꾸는 역할과 겹치며, 특히 코딩 에이전트용 실행 지시로 변환하는 부분이 유사하다.); c-architect-04(리포 구조·CI·빌드 명령·배포 타깃 같은 실행 환경 정보가 검증 명령과 파일 범위 설정에 영향을 준다.); c-architect-06(테스트 기준과 리팩터 경계를 세우는 관점이 검증 명령 및 범위 울타리 작성과 일부 겹친다.)'
    value: 구현 넘기기 전 Phase-0 계획전용 패킷을 끊을 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 첫 구현 단위를 작고 검증 가능하게 자르는 목적에 매우 잘 맞는 고품질 Phase-0 실행 패킷 스킬이다.  리스크: 파일 5개 이하 규칙은 유용한 휴리스틱이지만, 프레임워크 보일러플레이트나 테스트 파일 포함 시 너무 기계적으로 적용될 수 있다.; 자동 검증 명령 1개를 강제하면 초기 UI·디자인 작업처럼 스크린샷이나 수동 확인이 필요한 작업에서 부자연스러운 산출물이 나올 수 있다.; 입력 게이트에서 빌드/테스트 명령을 모를 때 ''빈 슬라이스를 1순위로 강제''하는 규칙은 상위 우선순위와 충돌할 수 있으므로 예외 처리 설명이 조금 더 있으면 좋다.; DO/DON''T를 파일 경로로 박는 방식은 기존 코드 탐색이 충분히 안 된 상태에서는 잘못된 경로를 확정할 위험이 있다.; 타임박스 50% 룰은 좋지만, 실패 시 축소·스텁·스파이크 중 무엇을 고르는지 판단 기준이 더 있으면 실행 안정성이 올라간다.'
    action: review
    path: 40_Skills/candidate/klv-first-packet.md
    ecosystem: 'delegate:gatecraft'
  - id: klv:gtm
    name: GTM·유통 전략
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-analytics-07(광고·스토어·바이럴 채널의 마케팅 효율을 지표로 판단하는 영역이 직접 겹친다.); x-marketing-06(유입 캠페인을 다루지만, 이 초안은 제작보다 채널·예산·중단 판단에 초점을 둔다.); x-marketing-07(설치단가와 전환 개선 지표를 활용해 유료 유입의 성패를 판단한다.); x-marketing-08(시장 진입 전략의 결과물을 입력으로 받아 초기 유통 채널을 고르는 단계에서 연결된다.); x-marketing-09(Discord·SNS·커뮤니티 시드를 초기 유저 확보 채널로 사용한다.); x-monetization-05(LTV·CAC·ARPU 기반으로 유료 UA 가능성을 판단하는 핵심 입력과 게이트가 겹친다.); x-analytics-02(retention·ARPU·LTV 같은 목표 지표를 전제로 kill/scale 판단을 한다.); x-compliance-02(ATT와 앱 추적 권한 같은 광고·측정 관련 개인정보 제약을 입력으로 확인한다.); x-compliance-05(가족정책, 연령등급, 아동 데이터 제한이 광고 채널 운영 제약으로 등장한다.); x-marketing-04(출시 직전 스토어 준비와 사전 일정 일부가 D-day 타임라인에서 맞닿는다.)'
    value: UA훅·ASO·kill/scale 게이트로 유통 경로를 설계할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실행 가능한 GTM 의사결정 스킬로 품질은 높지만, 고정 지표 기준과 LTV 측정 전제를 보정하면 더 안전하다.  리스크: 2026 CPI 벤치마크가 지역·장르·플랫폼별 변동성이 커서 최신 리포트로 교체하지 않으면 잘못된 예산 판단을 할 수 있다.; D1 리텐션 30/40% 기준은 게임 장르, 앱 유형, 세션 구조에 따라 과도하거나 느슨할 수 있다.; D+7에 LTV/CPI를 강하게 판정하려면 LTV 산정 기간, payback window, 광고수익 지연 반영 방식이 필요하다.; 커뮤니티/Reddit처럼 CPI가 0에 가까운 채널은 점수식 분모가 깨지므로 별도 평가 규칙이 더 필요하다.; 설치 200건은 초기 판단에는 유용하지만 세그먼트가 좁거나 전환 이벤트가 희소하면 통계적 신뢰가 부족할 수 있다.; 어트리뷰션 SDK, 개인정보 동의, ATT opt-in 저하 등 측정 손실을 어떻게 보정할지 절차가 부족하다.; 인플루언서 채널은 단건 성과 변동이 커서 CPI 환산 시 추적 링크·쿠폰·기간 귀속 기준이 필요하다.'
    action: review
    path: 40_Skills/candidate/klv-gtm.md
    ecosystem: 'partial:signalcraft'
  - id: klv:image-plan
    name: 이미지 제작 계획
    category: game
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-ux-01(확정된 화면/씬 목록을 입력으로 받아 이미지 산출물을 세므로 화면 인벤토리와 인접하다.); g-ux-02(와이어프레임·목업 확정 후 화면 안에 들어갈 이미지 파일을 산정하므로 레이아웃 산출물과 연결된다.); g-ux-03(HUD, 버튼, 패널 규칙을 실제 비트맵 산출물과 9-slice 규격으로 변환한다.); g-ux-04(정적 이펙트 스프라이트시트 수량 산정은 연출/VFX 설계와 일부 맞닿는다.); g-client-07(텍스처 메모리, 아틀라스 크기, POT, 압축 포맷 같은 런타임 예산을 제작 규격의 제약으로 사용한다.); g-qa-05(해상도, 종횡비, 세이프영역, 기기별 이미지 검수 기준이 다기기 검증과 연결된다.); g-director-09(P0/P1/P2와 가용 작업일로 MVP 범위를 자르는 방식이 단계별 범위 결정과 연결된다.); g-director-10(구현 전 산출물 준비도와 게이트를 명세서로 고정한다는 점에서 마일스톤 준비도 점검과 인접하다.)'
    value: Codex 이미지·에셋을 샘플先 생성·승인 추적할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 1인 게임 개발의 이미지 제작 직전 명세화에 매우 실용적인 고품질 스킬이다.  리스크: AI 생성물의 학습데이터 출처 확인은 실제 도구·약관상 사용자가 확인하기 어려운 경우가 많아, 요구 수준을 ''확인 가능한 약관·출처·프롬프트·결과 기록 보관''으로 현실화할 필요가 있다.; 저작재산권 양도 요구는 국가·계약 유형에 따라 표현과 효력이 달라질 수 있어 법률 자문 없이 절대 규칙처럼 적용하면 위험하다.; 모바일 해상도와 @2x 제공, POT 권장, ASTC/BC7 등 기술 규격 예시는 엔진·플랫폼·파이프라인에 따라 달라질 수 있어 공식 임포트 문서 확인 단계가 필수다.; ''핵심 정체성 비주얼은 AI/마켓 의존 금지''는 품질·차별화 원칙으로는 유용하지만 프로젝트 성격에 따라 과도하게 제한적일 수 있다.; 실제 제작 매수 계산은 좋은 출발점이지만 애니메이션 프레임 수, 리비전 횟수, 엔진 임포트·테스트 시간까지 포함하지 않으면 일정이 과소산정될 수 있다.'
    action: review
    path: 40_Skills/candidate/klv-image-plan.md
    ecosystem: 'delegate:sprint-game'
  - id: klv:ssot-index
    name: SSoT 인덱싱·압축
    category: common
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-01(무엇을·왜·누구에게를 한 장으로 정리하는 결과물이 SSoT의 Brief/Goals 정리와 맞닿는다.); c-planner-02(수용기준·비목표를 명세하는 정보가 SSoT의 결정·비목표 보존 대상과 겹친다.); c-planner-05(결정의 우선순위와 확정 여부를 다루지만, 이 스킬은 새 결정보다 기존 결정의 권위 판정과 색인에 초점이 있다.); c-planner-06(불확실성·의존성·실패 모드가 후보/충돌 로그와 연결될 수 있다.); c-planner-07(구현 전 준비도 점검에 필요한 단일 권위 문서를 만드는 데 직접 기여한다.); c-researcher-04(다출처·인용으로 주장과 수치를 검증하는 방식이 출처 각주와 추적성 게이트와 겹친다.); klv:first-packet(Phase-0 계획 패킷의 권위 문서화와 연결되지만, 이 스킬은 이미 정해진 사실의 인덱싱·압축 역할이다.); workflow-translator(막연한 요청을 구현 가능한 계획으로 정리할 때 산출물이 SSoT 입력 또는 종속 문서가 될 수 있다.)'
    value: 기존 문서가 흩어졌을 때 SSoT로 압축·색인할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 실행 절차와 검증 기준이 매우 구체적인 고품질 SSoT 정리 스킬이므로 promote가 적절하다.  리스크: 모든 소스를 빠짐없이 수집해야 한다는 전제가 강해, 실제로는 누락 소스가 생겼을 때 신뢰도가 과대평가될 수 있다.; 동급이면 최신이 이긴다는 규칙은 편리하지만, 최신 메모가 임시 아이디어이거나 실수인 경우 잘못 승격될 수 있다.; 기존 SSoT 자체와 다른 A등급 소스가 충돌할 때 초기 권위 기준을 어떻게 재판정할지 조금 더 명시하면 좋다.; 모든 사실에 각주를 요구하면 작은 프로젝트에서는 유지 비용이 커져 문서 갱신이 밀릴 수 있다.; 종속 문서를 고치는 범위가 넓을 경우 자동 동기화 중 의도치 않은 의미 변경이 생길 수 있다.'
    action: review
    path: 40_Skills/candidate/klv-ssot-index.md
    ecosystem: 'partial:gatecraft'
  - id: klv:ui-review
    name: UI 휴리스틱 리뷰
    category: web
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-qa-03(WCAG 2.2 AA, 키보드 조작, 대비, 라벨, alt 등 접근성 검증 영역이 겹친다.); w-frontend-07(화면 크기, 접근성, 성능 하한을 보장하는 프론트엔드 품질 기준과 일부 겹친다.); w-qa-04(로딩·빈·에러 상태와 회귀 위험을 보는 관점이 UI 휴리스틱의 N1, N9, I4와 겹친다.); w-frontend-05(로딩·빈·에러·성공·권한 상태를 구현 대상으로 다루며, 이 스킬은 같은 상태를 진단 대상으로 본다.); w-ux-01(내비게이션, 계층, 정보구조 판단이 I1~I3의 IA 리뷰와 겹친다.); w-ux-02(페이지별 골격과 화면 흐름을 잡는 작업이 스캔 순서와 1차 액션 판단과 맞닿아 있다.); w-ux-04(상태 전이와 마이크로인터랙션 설계가 시스템 상태 가시성, 오류 복구, 중복 제출 방지 진단과 겹친다.); frontend-polish(작동하는 UI를 접근성·상태·미세인터랙션 관점에서 다듬는 영역과 맞닿지만, 이 스킬은 구현보다 진단과 우선순위화에 초점이 있다.)'
    value: web-ui 트랙으로 대시보드·폼·랜딩을 점검할 때
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실무 적용성은 높지만 점수 규칙과 예시의 불일치, 심각도와 수정 우선순위 혼합을 고치면 승격 가능하다.  리스크: 심각도 점수에 Fix-cost를 분모로 넣어 낮은 비용의 사소한 문제가 과도하게 위로 올라갈 수 있다. ''사용자 심각도''와 ''실행 우선순위''를 분리하는 편이 더 명확하다.; 본문은 W1~W3만 점수 무관 P0라고 하지만 예시는 W4를 P0(W)로 표시해 규칙 일관성이 깨진다.; WCAG 2.2 AA 기준을 간략화하면서 예외 조건이나 성공기준별 정확한 적용 범위가 빠져 있어 과잉 판정 또는 오판 가능성이 있다.; N7의 ''숙련자용 지름길''은 모든 단일 화면 과업에 필수적이지 않은데 표 안에 ''(불필요)''라고만 되어 있어 판정 기준이 모호하다.; 가용 시간 컷 라인에서 Fix-cost 단위가 표에는 Fix(d)로 되어 있으나 본문 척도는 분/시간/반나절이라 단위 해석이 흔들릴 수 있다.'
    action: review
    path: 40_Skills/candidate/klv-ui-review.md
    ecosystem: 'delegate:sprint-web'
  - id: x-marketing-04
    name: 런치 체크리스트 운영
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-release-01(빌드·QA·자산·정책을 통합 체크리스트로 점검한다는 점에서 출시 전 게이트 운영 영역이 겹친다.); x-release-03(스토어 심사, 정책 대응, 리젝 예방·재제출 항목이 겹친다.); x-release-04(phased rollout, 중단 기준, 점진 출시 운영 기준이 겹친다.); x-release-05(핫픽스·롤백 경로 판단과 출시 후 장애 대응 준비가 겹친다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방을 위한 정책 체크 항목이 겹친다.); x-compliance-02(ATT, 추적 권한, 개인정보 동의와 데이터 수집 고지 확인이 겹친다.); x-compliance-05(등급, 아동 데이터, 결제 제한 같은 출시 전 정책 확인 영역이 겹친다.); x-analytics-05(출시 후 크래시·결제·리뷰·지표 모니터링 루프가 매일 상태 보기와 겹친다.); x-analytics-08(분석 이벤트 누락이나 클라이언트 로그 확인 등 지표 신뢰성 확인이 겹친다.); x-liveops-07(출시 후 장애·데이터 오류 대응, 공지와 핫픽스 기준이 겹친다.); x-liveops-12(평점·문의 응대 기준과 표준 답변 준비가 겹친다.); x-marketing-05(출시 후 1~2성 리뷰 대응과 평판 관리 기준이 겹친다.); x-monetization-01(가격·지역·인앱상품 확정값을 출시 게이트에서 검증한다는 점이 겹친다.); x-platform-11(배포 직후 기본 동작 확인과 관찰 증거 기반 smoke check가 겹친다.); x-platform-12(배포 전 자동/수동 통과 기준을 걸어 출시 차단 여부를 판단하는 부분이 겹친다.); klv:gtm(출시 후 kill/scale 게이트와 성장 가설 기반 중단 기준 설정이 겹친다.)'
    value: 출시 직전 (사전예약·심사·가격·지역)
    risk: 'Tier-2 품질 5/5 · 권고 promote · 출시 직전 실패 비용이 큰 항목을 증거 기반으로 닫고 출시 후 운영 루프까지 준비하게 만드는, 즉시 채택 가능한 고품질 스킬이다.  리스크: Apple, Google, Steam 정책과 콘솔 UI는 자주 바뀌므로 문서에 박힌 예시 항목이나 수치가 시간이 지나면 부정확해질 수 있다.; ANR < 0.47%, 크래시율 1%, 결제 실패율 5% 같은 기준은 앱 장르·트래픽 규모·플랫폼별 정의에 맞춰 조정해야 하며 절대 기준으로 오해될 수 있다.; Steam 항목은 모바일 스토어보다 상대적으로 얕아 Steam 전용 출시 심사, 세금/지급, 데모·업적·클라우드 세이브 같은 게이트가 필요한 제품에는 보강이 필요하다.; 정책 최신성 확인을 사람이 직접 수행하는 구조라 증거 기록은 좋지만, 반복 출시가 많은 경우 자동 알림이나 캘린더 마감 관리가 없으면 누락될 수 있다.; 롤백 경로가 없는 네이티브 클라이언트 기능은 기능 플래그 전제가 없으면 대응책이 제한되므로, 이 스킬 시작 전 아키텍처 준비 여부를 더 강하게 확인할 필요가 있다.'
    action: review
    path: 40_Skills/candidate/x-marketing-04.md
    ecosystem: 'partial:sprint-app'
  - id: x-platform-12
    name: 릴리즈 자동 검증 게이트
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-01(lint·test·build·보안 스캔 같은 개별 CI 검사를 릴리즈 게이트의 입력으로 사용한다.); x-platform-02(staging/prod 배포 승인과 반복 배포 안정화 흐름에서 게이트 위치와 보호 규칙이 맞닿는다.); x-platform-04(시크릿 누출 차단과 로그 내 비밀값 노출 방지 기준이 겹친다.); x-platform-06(의존성 취약점, SCA, 알려진 CVE 검사를 OPTIONAL 또는 차단 조건으로 연결할 수 있다.); x-platform-08(롤백 ID 기록, 긴급 패치, 복구 가능성 확인이 배포 실패 대응과 연결된다.); x-platform-10(핵심 플로우 스모크 테스트를 릴리즈 전 MUST 게이트로 사용하는 부분이 겹친다.); x-platform-11(배포 직후 스모크와 릴리즈 전 스모크가 목적은 다르지만 핵심 동작 검증이라는 영역을 공유한다.); x-release-01(출시 직전 빌드·QA·정책 점검 항목을 게이트의 증거 또는 입력으로 참조한다.); x-release-02(버전·서명·배포 패키지 확정 과정에서 빌드 산출물과 배포 가능 상태 검증이 맞닿는다.); x-release-03(스토어 정책 문서 URL과 확인일을 게이트 증거로 남기는 부분이 심사·정책 대응과 연결된다.); x-release-05(장애 시 되돌리기와 핫픽스 경로를 게이트의 롤백 준비 및 긴급 패치 규칙으로 다룬다.); x-release-06(배포 증거, 변경 기록, 알려진 이슈 및 운영 인계 자료와 게이트 로그가 연결될 수 있다.)'
    value: 배포 전 자동 통과 기준을 걸 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 실행 가능한 릴리즈 차단 게이트를 1인 개발자 수준에 맞게 구체화한 고품질 스킬이다.  리스크: BYPASS_REASON을 환경변수나 secret으로만 두면 실제로 누가 언제 우회했는지 감사 추적이 약할 수 있다.; 롤백 ID를 배포 직전 파일로 기록하는 방식은 정적 호스팅 외 환경에서는 실제 현재 prod 버전과 불일치할 수 있어 플랫폼별 조회 방식이 필요하다.; 시크릿 스캔 오탐 우회가 반복되면 MUST 게이트가 사실상 약화될 수 있으므로 allowlist 관리 기준이 추가되면 더 안전하다.; 수동 QA 표식 파일을 인정하는 경우, 표식 생성 권한과 만료 기준이 없으면 오래된 QA 증거가 재사용될 위험이 있다.; npm audit 같은 도구는 생태계별 잡음이 크므로 차단/경고 기준을 프로젝트별로 조정하지 않으면 우회 습관을 만들 수 있다.'
    action: review
    path: 40_Skills/candidate/x-platform-12.md
    ecosystem: 'delegate:gatecraft'
  - id: x-release-01
    name: 출시 준비도 게이트
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-release-02(버전·서명·배포 패키지 확정 결과를 이 게이트에서 확인한다.); x-release-03(스토어 메타데이터, 심사 정책, 개인정보·결제 관련 리젝 예방 항목을 출시 가능성 판정에 포함한다.); x-release-04(점진 출시나 중단 기준 자체를 만들지는 않지만, 출시 전 관측 지표와 운영 준비 확인에서 맞닿는다.); x-release-05(롤백·핫픽스 경로 존재 여부를 BLOCK 기준으로 확인한다.); x-release-06(공지 초안, 알려진 이슈, 운영 인계성 준비물을 출시 판정서에 모은다.); x-platform-01(lint·test·build 같은 품질 게이트 결과를 출시 전 증거로 사용할 수 있다.); x-platform-02(staging/prod 배포 안정화와 승인 절차가 출시 준비도 확인 항목과 겹친다.); x-platform-07(크래시·에러 리포터, 알림 수신, 관측 가능성 확인이 장애 탐지 영역과 겹친다.); x-platform-08(배포 실패 시 복구, feature flag, rollback 경로 확인이 공통 운영 준비 항목과 겹친다.); x-platform-10(핵심 플로우 자동 검증 결과를 QA 증거로 사용할 수 있다.); x-platform-11(배포 직후 기본 동작 확인과 출시 전 최종 검문이 인접하다.); x-platform-12(자동 통과 기준과 테스트 게이트 자체를 만드는 역할과, 그 결과를 모아 PASS/FAIL 판정하는 역할이 연결된다.); x-compliance-01(개인정보 처리방침 링크와 실제 수집 항목 일치 여부를 확인한다.); x-compliance-02(GDPR, 쿠키, ATT, 추적 동의 같은 개인정보·추적 정책 확인과 겹친다.); x-compliance-03(App Store/Google Play 심사 리젝 예방 체크가 플랫폼 게이트에 포함된다.); x-compliance-04(외부 에셋·폰트·OSS 라이선스 충돌 여부를 출시 전 확인한다.); x-compliance-05(연령 등급, 아동 데이터, 결제 제한 확인 항목이 직접 포함된다.); x-analytics-02(출시 후 볼 1차 지표와 측정 경로 확인이 목표·대시보드 영역과 겹친다.); x-analytics-05(출시 후 24시간 관찰할 지표를 실제 대시보드에서 확인한다는 점이 매일 상태 보기와 연결된다.); x-analytics-09(분석·추적과 개인정보 동의·익명화 관련 확인이 일부 겹친다.); x-marketing-04(출시 직전 가격·지역·심사 준비 상태 확인과 릴리즈 게이트가 맞닿는다.)'
    value: 빌드·QA·자산·정책을 통합 체크리스트로 점검할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 출시 직전 PASS/FAIL 게이트로서 증거 기준, BLOCK 조건, 출력 형식이 매우 구체적이라 바로 승격해도 되는 수준이다.  리스크: 플랫폼 정책과 최소 SDK, 개인정보 양식 명칭은 자주 바뀌므로 출시 직전 공식 문서 확인을 강제하지 않으면 오래된 체크리스트가 될 수 있다.; 웹/서버 API까지 같은 게이트에 포함하면서 앱스토어식 항목과 서버 배포 항목의 위험도가 섞일 수 있어, 프로젝트 유형별 축소판 기준을 더 명확히 하면 좋다.; WARN의 ''24h 내 처리'' 기준은 모든 항목에 적합하지 않을 수 있다. 스토어 자산 누락, P1 버그, 공지 오타는 각각 기한과 영향도가 다를 수 있다.; P0/P1 정의가 예시에만 암시되어 있어, 실제 사용 시 심각도 분류가 흔들릴 수 있다.; ''측정 경로 없음은 무조건 BLOCK'' 원칙은 대체로 타당하지만, 단순 정적 웹페이지나 내부용 도구 같은 저위험 배포에서는 예외 기준이 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-release-01.md
    ecosystem: 'partial:gatecraft'
  - id: x-release-04
    name: 단계적 롤아웃
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-platform-02(staging/prod 승인 흐름과 배포 안정화 게이트가 단계적 롤아웃의 확대 판단과 겹친다.); x-platform-08(canary, feature flag, 실패 시 복구가 단계적 롤아웃의 주요 실행 수단과 직접 겹친다.); x-release-01(배포 전 통합 체크리스트와 출시 가능 여부 판단 게이트가 일부 겹친다.); x-release-05(롤아웃 중 장애 발생 시 롤백, 패치, 우회 판단이 필수라 대응 영역이 겹친다.); x-liveops-02(앱 업데이트 없이 운영값을 조정하는 방식이 feature flag나 서버 설정 기반 점진 출시와 맞닿아 있다.); x-analytics-05(롤아웃 중 지표 모니터링과 이상 감지를 위해 대시보드 확인 절차가 필요하다.)'
    value: canary·코호트·중단기준으로 점진 출시할 때
    risk: 'Tier-2 품질 4/5 · 권고 promote · 단계적 롤아웃 전용 판단축과 위험 인식은 충분해 승인 가능하나, 수단별 템플릿과 정량 예시를 보강하면 더 강해진다.  리스크: 중단 조건과 확대 조건을 정량화하라고 요구하지만 기본 임계값 예시가 없어 사용자가 여전히 추상적으로 작성할 수 있다.; feature flag, 서버 설정, 앱스토어 staged rollout, 강제 업데이트, DB 변경처럼 수단별로 다른 체크리스트가 분리되어 있지 않아 실제 적용 시 빠뜨릴 수 있다.; 코호트 선정 기준, 제외 대상, 샘플 크기, 관찰 기간이 구체화되어 있지 않아 작은 트래픽 서비스에서는 잘못된 판단을 할 수 있다.; 롤백 불가능 변경에 대한 사전 분리 전략은 언급되지만 expand 전 차단 게이트로 강하게 구조화되어 있지 않다.; 예시가 실제 상황 하나를 다루지 않아 좋은 산출물의 완성도를 사용자가 모방하기 어렵다.'
    action: review
    path: 40_Skills/candidate/x-release-04.md
    ecosystem: 'partial:sprint-app'
  - id: frontend-polish
    name: 프론트엔드 폴리시
    category: web
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): w-frontend-02(버튼, 카드, 입력, 모달 등 재사용 컴포넌트의 상태와 시각 품질을 다듬는 영역이 겹친다.); w-frontend-03(토큰, 컴포넌트 변형, 디자인 시스템 관례를 유지하며 polish하는 부분이 겹친다.); w-frontend-05(loading, empty, error, disabled 등 상태 표현을 채우고 점검하는 영역이 겹친다.); w-frontend-07(반응형, 접근성 기본값, Core Web Vitals와 성능 감각을 확인하는 부분이 겹친다.); w-qa-01(검증 명령, 브라우저 확인, 체크리스트 기반 품질 게이트를 정의하는 부분이 겹친다.); w-qa-02(desktop/mobile/tablet 및 해상도별 레이아웃 검증과 겹친다.); w-qa-03(focus, semantic control, alt, contrast 등 접근성 확인 항목이 겹친다.); w-qa-04(로딩/빈/에러 상태와 변경 후 회귀 확인이 겹친다.); w-ux-03(토큰, 컴포넌트, 시각 패턴의 일관성을 맞추는 작업과 겹친다.); w-ux-04(hover, focus, active, motion, microinteraction 설계와 겹친다.); klv:ui-review(대시보드·폼·랜딩 등 웹 UI의 시각 QA와 완성도 점검 범위가 넓게 겹친다.)'
    value: 작동하는 웹 UI를 간격·정렬·상태·접근성·미세인터랙션으로 다듬어 완성도를 올릴 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 출시 전 프론트엔드 완성도를 작고 검증 가능한 diff로 끌어올리는 고품질 polish 스킬이다.  리스크: Polish inventory의 판단 기준이 일부 주관적일 수 있어, 팀/사용자 기대치가 있으면 기준 예시나 참고 화면을 먼저 고정해야 한다.; 브라우저 자동화나 스크린샷 도구가 없는 환경에서는 핵심 절차의 증거 수집이 약해질 수 있다.; contrast, Core Web Vitals, reduced-motion 등은 언급되어 있지만 구체적인 측정 도구나 통과 기준이 부족해 수행자 역량에 따라 검증 깊이가 달라질 수 있다.; P3 delight 항목은 잘못 적용하면 장식 추가나 scope creep으로 번질 수 있어 낮은 우선순위라는 점을 계속 유지해야 한다.'
    action: use
    path: 40_Skills/candidate/frontend-polish.md
    ecosystem: 'delegate:sprint-web'
  - id: workflow-translator
    name: 워크플로우 트랜슬레이터
    category: common
    engine: any
    source: internal
    status: approved
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): c-planner-04(MVP/prototype 요청을 첫 실행 단위로 자르고 Prototype/MVP/V1/Later처럼 범위를 제한하는 관점이 겹친다.); c-planner-07(구현에 넘기기 전 준비도, 관련 파일, 검증 명령, 가정/리스크를 점검하는 흐름이 겹친다.); klv:first-packet(구현 전 Phase-0 계획 패킷을 만들어 작업 목표, 범위, 검증 기준을 정리한다는 점이 겹친다.); c-planner-02(기능 요청을 수용 가능한 작은 목표와 비목표, 검증 기준으로 바꾸는 부분이 겹친다.); c-planner-06(불확실성, 의존성, 실패 모드, 리스크를 명시하고 blocking ambiguity를 구분하는 부분이 겹친다.); c-architect-04(repo 구조, 실행/검증 명령, CI/build 관례를 먼저 확인하는 절차가 일부 겹친다.); c-architect-06(리팩터링 시 테스트, 네이밍, 동작 보존 기준을 세우는 부분이 겹친다.)'
    value: 막연·거친 개발 요청('대충 만들어줘')을 구현 전 구체 계획으로 변환할 때
    risk: 'Tier-2 품질 5/5 · 권고 promote · 모호한 개발 요청을 검증 가능한 첫 작업 단위로 번역하는 절차가 구체적이고 실전성이 높아 promote 권고.  리스크: 스킬이 실제 구현까지 수행하는 경우와 워크플로우 번역만 하는 경우의 경계가 약간 흐릴 수 있다.; 운영 데이터 삭제, 배포, 결제, 인증 등 위험 작업은 사용하지 말라고 되어 있지만, 그런 요청을 받았을 때 어떤 승인·중단·에스컬레이션 포맷을 쓸지는 더 구체화할 수 있다.; Design-to-code 예시에서 ''주요 화면 2개''라고 되어 있어 본문 원칙인 한 frame/screen/flow 우선과 약간 긴장이 있다.; 검증 명령이 없을 때의 수동 확인 기준은 더 구체적인 예시가 있으면 재현성이 높아진다.'
    action: use
    path: 40_Skills/candidate/workflow-translator.md
    ecosystem: 'delegate:superpowers'
  - id: g-client-09
    name: Steamworks 통합
    category: game
    engine: unity
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): g-client-01(SteamManager를 영속 매니저로 부트 체인에 붙이는 부분이 씬·매니저 뼈대 구성과 겹친다.); g-client-08(Unity 플랫폼 빌드 산출물과 steamcmd 디포 업로드가 빌드 자동화·플레이어 설정 영역과 이어진다.); g-client-06(클라우드 세이브 동기화는 로컬 저장/복원 및 에셋·세이브 흐름과 맞닿아 있다.); g-client-05(Steam Input과 게임패드/Deck 조작 검증은 신 Input System 기반 조작 구현과 겹친다.); g-qa-05(Steam Deck 1280×800, 컨트롤러, 가상 키보드 검증은 여러 기기·해상도 검증과 겹친다.); g-director-05(업적, 리더보드, 랭킹은 장기 동기와 진행 보상 설계와 관련된다.); g-qa-01(Steam 기능별 통합 검증 체크리스트와 수용 기준을 세우는 부분이 QA 계획과 겹친다.)'
    value: Steam SDK·업적·클라우드 세이브·리더보드·디포 업로드·Steam Deck 검증
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실전성이 높은 Steamworks 클라이언트 통합 스킬이지만 통계 초기화, SDK별 차이, 클라우드 충돌 세부와 관련 스킬 번호 오류를 보완해야 한다.  리스크: 초안 내부에서 g-client-07을 세이브 시스템으로 부르지만 제공된 기존 스킬 목록상 g-client-07은 성능 최적화이고, 저장/복원은 g-client-06에 더 가깝다.; SteamUserStats 사용 전에 RequestCurrentStats와 UserStatsReceived_t 처리 필요성이 빠져 업적/통계가 초기화되지 않은 상태에서 호출될 수 있다.; Steamworks.NET 예제 중심이라 Facepunch.Steamworks를 선택한 사용자는 동일 절차를 어떻게 async/API 스타일로 옮길지 추가 해석이 필요하다.; 클라우드 충돌 처리가 개념적으로는 좋지만 Auto-Cloud와 RemoteStorage API 방식별 실제 충돌 감지·해결 UX가 더 구분되어야 한다.; steam_appid.txt 비동봉 원칙은 일반 Steam 실행에는 맞지만, 비스팀 배포·QA·CI 실행 경로에서 필요한 예외 처리를 별도 명시하면 더 안전하다.; 리더보드 FindOrCreate, 핸들 캐시, 조회 경로 예제가 제출보다 약해 조회 UI 구현자는 추가 자료가 필요하다.'
    action: review
    path: 40_Skills/candidate/g-client-09.md
    ecosystem: 'partial:sprint-game'
  - id: x-marketing-10
    name: 런치 자산 제작
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-marketing-03(스토어 이미지·미리보기 영상의 메시지와 슬롯 구성을 다루며, 이 스킬은 그 산출물을 받아 실제 자산으로 제작한다.); x-marketing-07(썸네일·소재·CTA 개선과 관련되어 캡슐, 트레일러, 짧은 클립의 전환 개선 관점이 겹친다.); x-marketing-06(광고·SNS 캠페인용 소재 제작과 GIF/짧은 클립 세트 활용이 맞닿아 있다.); x-marketing-04(출시 직전 사전예약·심사·가격·지역 준비와 런치 자산 마감 관리가 인접하다.); x-release-01(출시 전 빌드·QA·자산·정책 체크리스트 중 자산 점검 영역과 겹친다.); x-release-03(스토어 메타데이터·심사·정책 대응 중 이미지·영상 제출 자산 관리가 겹친다.); x-compliance-03(앱스토어·플레이 심사 리젝 예방과 플랫폼별 영상·스크린샷 규격 확인이 겹친다.); x-compliance-04(BGM, 폰트, 이미지, 외주 에셋의 라이선스 확인이 겹친다.); x-writer-04(제목·설명·스크린샷 문구 작성과 캡슐/스크린샷 자막·카피 적용이 맞닿아 있다.); x-analytics-07(마케팅 효율 판단에서 소재별 전환·유지율을 평가할 때 트레일러와 캡슐 성과 분석이 연결된다.)'
    value: 트레일러·캡슐 이미지·스크린샷 등 스토어 전환 자산 실제 제작
    risk: 'Tier-2 품질 5/5 · 권고 promote · 런치 자산을 실제 제작물로 뽑아내는 실행 절차와 검수 기준이 매우 구체적인 고품질 스킬이다.  리스크: 플랫폼 규격 표에 2026 기준 수치가 포함되어 있어, 사용자가 재확인 지시를 무시하고 그대로 복붙하면 최신 심사 규격과 어긋날 수 있다.; Steam, Google Play, App Store의 이미지·영상 규격은 국가, 기기군, 스토어 콘솔 UI, 제출 유형에 따라 세부 조건이 달라질 수 있는데 표가 대표값 중심이다.; Content ID 클레임 위험 없음은 실제로 보장하기 어렵다. 자체 제작 또는 라이선스 보유여도 유통사 등록, 샘플 사용, 음원 라이브러리 중복 등록 때문에 오탐이 날 수 있다.; ''소셜 75% 무음'' 같은 수치는 근거와 맥락이 없으면 과도하게 일반화될 수 있다.; 트레일러 예산 범위와 외주 단가는 장르, 지역, 편집 난이도, 원화·모션그래픽 포함 여부에 따라 크게 달라질 수 있다.; 이미지 채점표가 유용하지만 장르별 예외가 있다. 공포·미스터리·미니멀 아트처럼 의도적으로 정보량을 제한하는 자산은 별도 판단 기준이 필요할 수 있다.'
    action: review
    path: 40_Skills/candidate/x-marketing-10.md
    ecosystem: 'partial:sprint-game'
  - id: x-server-13
    name: 리더보드·점수 검증·악용 방지
    category: cross
    engine: any
    source: internal
    status: candidate
    version: '0.1'
    overlap: '의미적 겹침(Tier-2): x-server-01(클라/서버 경계, 검증 엔드포인트, 서버가 신뢰할 데이터 경로를 정하는 부분이 겹친다.); x-server-04(클라이언트 조작 차단, 서버 검증, 트랜잭션 경계와 직접적으로 맞닿아 있다.); x-platform-04(서명 키와 DB 자격증명을 클라이언트·코드에 두지 않고 서버 환경변수나 시크릿 관리에 두는 경계가 겹친다.); x-liveops-06(유저 검색, 차단, 수동 운영, 운영 로그 기반 제재 절차가 겹친다.); x-analytics-08(클라 로그와 서버 원장 차이, 비정상 지표 탐지, 이상치 판단 관점이 일부 겹친다.); x-platform-07(악용 탐지를 위한 로그·메트릭·플래그 기록과 운영 감시가 겹친다.)'
    value: 온라인 랭킹/점수 제출 시 서버 검증·조작 탐지·비정상 기록 필터
    risk: 'Tier-2 품질 4/5 · 권고 revise · 실전성 높은 스킬이지만 클라이언트 HMAC 생성 구조의 보안 모순은 수정이 필요하다.  리스크: HMAC을 클라이언트가 생성하려면 키가 클라이언트에 있어야 하므로, 현재 설명은 보안 모델이 모순된다.; 물리적 상한과 이론 최소 시간이 잘못 산정되면 정상 최상위 유저를 반복적으로 보류할 수 있다.; 중앙값 5배, 기존 1위 70% 같은 시작 수치가 장르별로 부적절할 수 있어 튜닝 기준이 더 필요하다.; Steam Leaderboards에 서버가 직접 업로드할 수 있는지, 플랫폼별 API 권한과 제약을 확인해야 한다.; 익명 점수 금지는 커뮤니티형 캐주얼 게임에서는 전환율·진입장벽 문제가 될 수 있다.; 리플레이 수동 검증은 결정론 보장, 버전 차이, 물리 엔진 차이, 입력 기록 포맷 관리가 빠지면 운영 불가능해질 수 있다.'
    action: review
    path: 40_Skills/candidate/x-server-13.md
    ecosystem: 'partial:sprint-web'
