LaunchRepoCLI를 사용하세요: 최상의 결과를 얻으려면 데스크톱 앱 대신 항상 Claude Code CLI 또는 Codex CLI를 사용하세요.
워크스페이스와 대시보드가 준비되면 에이전트는 ONBOARDING.md를 따라, 검증된 출처를 바탕으로 파일을 채우고 이미 있는 답은 다시 활용합니다. 세션이 중간에 멈추더라도 onboarding.json과 SESSION.md에 다음 할 일이 남아 있습니다.
1–2단계: 오리엔테이션과 데이터를 둘 비공개 공간
에이전트는 먼저 계획을 설명합니다. 제품을 이해하고, 브라우저와 인증용 메일함을 연결하고, 등록 페이지와 웹사이트 배지를 어떤 방식으로 게시해도 되는지 합의하고, 이후 세션을 위해 설정을 보존한다는 계획입니다. 그런 다음 첫 제품의 이름, URL, 로컬 코드 폴더를 묻고, 다른 질문을 하기 전에 그것부터 읽습니다. 또한 이번 세션에서 실제로 무엇을 할 수 있는지 확인합니다. 터미널이 있다고 해서 브라우저를 제어할 수 있는 것은 아니며, 툴킷은 세션에서 호출할 수 없는 도구를 쓸 수 있다고 주장하는 것을 금지합니다.
2단계에서는 데이터를 둘 비공개 공간을 마련합니다. 에이전트가 아직 구매한 전달용 저장소 안에 있다면, 세 단계 시작 가이드에서 만드는 독립 워크스페이스를 초기화하고 내 비공개 원격 저장소를 설정하도록 돕습니다. 이때 에이전트는 분명하게 알려 줍니다. 로그인 정보 저장에 동의하면 그 정보는 비공개 저장소에 저장되고, 저장소에 접근할 수 있는 사람이라면 누구나 커밋 기록까지 포함해 읽을 수 있으며, 전달용 저장소에는 절대 저장되지 않는다는 점입니다. 소유자, 저장소, 공개 범위 확인 결과, 자격 증명 방식은 workspace.json에 기록되며, 시크릿 매니저를 쓰는 경우에는 참조만 저장됩니다.
3단계: 제품 브리프와 출시일
에이전트는 짧은 소문자 슬러그로 scripts/new-product.py를 실행하고, 내 답변을 바탕으로 모든 플레이북이 읽는 제품 컨텍스트 파일인 product.json을 채웁니다. 대상 사용자, 해결하는 문제, 차별점, 실제 기능, 가격 또는 체험판, 출시 단계, 실제 스크린샷과 로고가 들어갑니다. 이렇게 만든 문구는 수정할 수 있도록 내게 보여 줍니다. 민망한 등록 페이지를 막아 주는 규칙이 두 가지 있습니다. 경쟁 제품에서 기능을 끌어오지 않고, 계획 중인 기능을 이미 있는 것처럼 설명하지 않습니다. 모르는 항목은 비워 둡니다.
이 단계에서는 첫 출시가 언제 공개되어야 하는지, 그리고 그 전에는 아무것도 게시되면 안 되는 날짜가 있는지도 묻습니다. 무료 플랜 디렉터리는 제출물을 검토 대기열에 넣기 때문에 게시까지 며칠이 아니라 몇 주가 걸릴 수 있다는 경고도 분명히 전합니다. 내 답은 product.json의 earliest_launch_date가 되며, 이것이 나중에 record.py가 적용하는 출시일 하한선입니다.
다음으로 identity.json에 내가 허락한 공개 이름, 연락용 이메일, 닉네임, 조직 정보를 기록합니다. 비공개 계정 이메일은 공개 연락처 주소와 분리해 둡니다. 이 정보가 등록 페이지에 들어가기 전에 에이전트는 짧은 대외 소개 브리핑을 진행합니다.
4단계: Chrome과 메일함
에이전트는 Chrome 연결 가이드에 따라 Chrome의 원격 디버깅 페이지와 필요한 macOS 권한 설정을 안내한 뒤, 공개 페이지에서 내가 눈으로 볼 수 있는 스모크 체크를 수행합니다. 연결된 브라우저에서 웹 메일함에는 직접 로그인하세요. 에이전트는 메시지를 복사하지 않고 의도한 계정인지만 확인합니다. 가입과 등록은 인증 메일로 마무리되므로, 메일함 접근 범위는 authorizations.json에 기록됩니다. 인증 코드를 직접 전달해 주는 방식도 지원되는 대안이며, 이 경우 자동 접근이 아니라 사람에게 넘긴 작업으로 기록됩니다.
5단계: 제품마다 한 번 합의하는 권한
에이전트는 제품 웹사이트의 코드가 어디에 있는지, 어떻게 배포하는지, 어느 브랜치가 프로덕션인지, 정식(canonical) URL이 무엇인지 묻습니다. 그리고 나중에 가장 많은 번거로움을 덜어 주는 질문을 합니다. 그 제품의 푸터에 공식 디렉터리 배지를 추가하고, 커밋하고, 푸시하고, 다시 배포해도 될까요? 범위, 답변, 날짜, 허용된 저장소와 브랜치는 authorizations.json에 기록됩니다. “아니요”라고 답해도 배지가 필요 없는 디렉터리는 막히지 않습니다. 같은 파일에 무료 가입, 무료 최종 제출, 특정 인증 메일 작업을 허용하는지도 기록됩니다. 지출은 0으로 유지되며, 한 제품에 준 허가가 다른 제품으로 넘어가는 일은 없습니다.
6–7단계: 실행을 계획하고 진행 상황 이어 가기
설정이 끝나면 에이전트는 doctor.py를 실행해, 빠진 설정과 내가 일부러 거절한 권한을 구분합니다. 실행 플래너를 열고 새로 확인된 제출 10건, 동시 진행 최대 2건으로 시작하세요. 로컬 하드웨어를 기준으로 한 권장값은 출발점일 뿐입니다. 메모리가 부족하거나, 컴퓨터가 바쁘거나, 브라우저를 따로 제어할 수 없다면 워커 하나만 쓰세요. 에이전트는 병렬 작업 전에 워커마다 배정된 플랫폼과 격리된 브라우저 작업 공간이 따로 있는지 확인합니다. 관련 있는 플레이북을 고르고 왜 맞는지 설명한 뒤, 이용 가능한 무료 경로부터 시작합니다. 기존 등록이 있는지 검색하고, 제출 대상을 확인하고, 정확한 문구를 준비하고, 요금이 청구되지 않는지 확인하고, 허락된 범위 안에서 제출하고, 실제 결과를 기록합니다. 좋은 첫 결과는 게시된 페이지가 아니라 검토 대기 중인 제출인 경우가 많습니다. 결과 기록 가이드를 참고하세요.
에이전트가 지원한다면 저장된 실행 프롬프트와 함께 /goal을 사용하고, 지원하지 않는다면 프롬프트를 일반 메시지로 붙여 넣으세요. 목적은 첫 결과가 나온 뒤 멈추지 않고 합의한 실행을 끝까지 진행하는 것입니다. 검토 대기, 대기열 등록, 예약, 게시 상태인 새 제출은 확인되면 플랫폼당 한 번 집계됩니다. 초안, 기존 등록, 유료 경로, 사람에게 넘긴 작업은 집계되지 않습니다. 에이전트는 결과를 하나씩 기록하고, 증거를 저장한 뒤 해당 제출에 배정된 창만 닫고, 적합한 대안으로 계속 진행합니다. 저장되지 않은 폼과 사람에게 넘긴 작업은 그대로 둡니다.
세션을 잠시 멈추거나 끝낼 때 에이전트는 실제로 관찰한 확인 항목만 onboarding.json에 반영하고, 민감하지 않은 증거와 남은 단계는 SESSION.md에, 후속 확인 날짜는 FOLLOW-UP.md에 기록한 뒤, 완료된 일, 대기 중인 일, 내 조치를 기다리는 일, 다음 할 일을 요약합니다. 푸시하기 전에는 매번 Git 개인정보 점검이 실행됩니다. 좋은 첫 세션인지 판단하는 기준은 하나입니다. 다음 에이전트가 아무것도 다시 가입하지 않고, 이미 받은 권한을 다시 묻지 않고도 이어서 작업할 수 있는가. 이 과정이 전체 흐름의 어디에 있는지는 작동 방식 페이지에서 볼 수 있습니다.