launch

launch skill

목적

검수에 넣기 전 점검과 반려 뒤 대응을 맡는다. 검수 기준 문장은 docs MCP로 읽는 개발자센터 문서가 정본이다. 이 skill은 그 문장을 코드와 맞춰 보는 순서, 코드 스캔, 원인을 코드에서 못 찾았을 때 고치지 않고 멈추는 지점을 더한다. 화면 수정은 /ait:design, 문구는 /ait:ux-writing, 폰 확인은 /ait:test-on-device, 기획은 /ait:plan이 맡는다.

판단 규약

1. 작업 디렉터리부터 읽는다. 읽기 전에 "비어 있다", "소스가 없다"고 말하지 않는다.
2. 판정 근거는 docs MCP getPage 원문이다. 검색 결과 조각이나 askQuestion 요약으로 판정하지 않는다.
3. 설치된 SDK부터 본다(web-framework 버전, 설정 파일은 3.x apps-in-toss.config.ts·2.x granite.config.ts). 설치된 .d.ts에 없는 키나 API는 권하지 않고, 2.x용 문단을 3.x에 쓰지 않는다. Unity나 엔진 프로젝트는 Packages/manifest.json의 SDK 항목과 패키지 안 문서로 버전과 API를 확인한다. 스택을 가정하지 말고 프로젝트의 package.json scripts·설정 파일·README에서 읽는다. 모호하면 사용자에게 묻는다.
4. 쓰지 않는 기능의 항목은 해당 없음이다. '(선택 사항)' 항목, '~하는 경우' 항목, 기능 절(토스 로그인, 인앱 결제, 토스페이, 인앱 광고, 웹보드 게임)이 여기에 든다. '사용자 식별키 발급' 절은 조건 없이 공통 절 사이에 있으니 모든 앱에 적용한다.
5. 사용자 식별은 두 가지를 본다. 앱이 SDK 식별키 API로 값을 받아 저장하는지(API 이름은 설치된 .d.ts와 docs로 확인한다). 서버가 사용자를 확인해야 하면 클라이언트가 보낸 식별키를 그대로 믿지 않고 인증 코드 교환으로 받는지. 설치된 SDK에 인증 코드 API가 없으면 필요한 버전만 알린다. 앱 안의 사용자별 데이터만 다루면 발급과 저장으로 충분하다. 문서는 lookup-map의 사용자 식별 행이다.
6. 스캔 출력은 후보다. 파일을 열어 확인한 것만 보고한다.
7. 도구는 한 턴에 묶어 부른다. 턴이 하나 늘 때마다 앞의 내용을 전부 다시 읽는다. 파일은 Bash 한 번으로 함께 읽고, 체크리스트 밖 문서는 판정에 꼭 필요한 것만 2쪽까지 읽는다.

실행 순서

0. 범위

• 반려 사유가 함께 왔으면 1 다음 4로 간다. 검수 요청을 원하면 바로 5로 간다. 그 밖에는 1~3을 하고 6으로 보고한다.
• 게임인지 비게임인지 정한다. 코드로 알 수 없으면 한 번 묻는다.

1. 첫 턴: 프로젝트 읽기와 스캔

아래 둘을 같은 턴에 부른다.

• ToolSearch 한 번으로 docs MCP getPage를 불러온다. 콘솔을 읽을 거면 3의 도구도 같은 호출에 넣는다.
• Bash 한 번. base directory는 이 skill을 로드할 때 표시된 문자열을 그대로 쓴다. 반려 대응이면 사유에 나온 낱말(API 이름, 문자열, 설정 키)을 찾는 grep을 덧붙인다.

ls -la; cat package.json apps-in-toss.config.ts granite.config.ts Packages/manifest.json 2>/dev/null
grep '"version"' node_modules/@apps-in-toss/web-framework/package.json 2>/dev/null
find . \( -name node_modules -o -name .git -o -name dist -o -name build -o -name Library -o -name Temp \) -prune -o -type f -print | head -100
bash "<이 skill의 base directory>/scripts/launch-scan.sh" .