launchday은(는) 무엇을 하나요?
훌륭한 오픈소스 프로젝트도 대부분 출시를 망칩니다. 설명만 하고 보여주지 않는 README, 데모 없음, 설치 명령어 없음, 다른 세 개의 도구와 충돌하는 이름, 그리고 미국 시간 새벽 3시에 올리는 Show HN 게시물이 그 예입니다. 이 스킬은 이러한 모든 문제를 한 번에 해결하고, 사용자가 저녁 시간에 실행할 수 있는 출시 계획을 제공합니다.
준비 작업은 스킬이 수행합니다. 공개적인 작업(공개 저장소 생성, 태그 푸시, 소셜 프리뷰 업로드, 게시)은 사용자가 직접 수행합니다. 출시는 되돌리기 어렵고 사용자의 이름으로 이루어지므로, 스킬은 복사-붙여넣기만 하면 되는 수준까지 준비한 후 중단하고 사용자에게 넘깁니다.
실행 방법
단계를 순서대로 진행하세요. 각 단계는 저장소에 구체적인 결과물을 남깁니다. 사용자가 따라올 수 있도록 현재 진행 중인 단계를 알려주세요.
스크립트는 이 파일 옆에 있는 scripts/ 디렉토리에 있습니다. Python 표준 라이브러리만 사용하며(프리뷰에는 ffmpeg 추가 사용), 이 스킬 폴더의 경로를 인자로 받아 실행합니다. 예: python3 <skill-dir>/scripts/audit.py .
| 단계 | 결과물 | 스크립트 또는 참고 문서 |
|---|---|---|
| 1. 프로젝트 이해 | 사용자 확인을 받는 한 문단 요약 | 없음 |
| 2. 이름 확인 | 유지 또는 변경 결정 | scripts/name_check.py |
| 3. 감사 | 점수 및 수정 목록 | scripts/audit.py |
| 4. README | 랜딩 페이지 형식으로 다시 작성된 README | references/readme.md |
| 5. 데모 | GIF 또는 스크린샷 및 소셜 프리뷰 | references/demo.md, scripts/social_preview.sh |
| 6. 릴리스 | CI 및 릴리스 워크플로우 | references/release.md |
| 7. 출시 키트 | 게시물 및 일정이 포함된 LAUNCH.md | references/launch-posts.md, scripts/launch_time.py |
| 8. 인계 | 사용자가 실행할 정확한 명령어 | 없음 |
사용자가 특정 부분만 요청한 경우(예: "README만 고쳐줘", "Show HN 게시물만 작성해줘"), 해당 단계만 수행하세요. 그래도 비용이 적게 든다면 먼저 감사(audit)를 실행하는 것이 좋습니다. 실제 문제점을 드러내는 경우가 많기 때문입니다.
1단계: 프로젝트 이해
README, 패키지 매니페스트(package.json, Cargo.toml, pyproject.toml, go.mod) 및 진입점(entry point)을 읽으세요. 안전하다면 프로젝트를 실행해보세요. 그런 다음 다음 세 가지를 다루는 한 문단을 작성하세요.
- 무엇을 하는지: 비전문가도 이해할 수 있는 한 문장.
- 누가 불편을 겪는지: 구체적으로 설명하세요. "개발자"보다는 "저장소 10개 이상을 관리하는 관리자"와 같이 특정 대상을 지칭하세요.
- 인상적인 순간(proof moment): 새 사용자가 처음 보고 "아, 괜찮네"라고 느끼게 만드는 지점. README와 데모는 이 순간을 중심으로 구성됩니다.
짧은 메시지로 사용자 확인을 받으세요. 잘못된 요약은 이후 모든 작업을 망칠 수 있습니다. 또한 스스로 찾을 수 없는 정보(저장소를 호스팅할 GitHub 계정, 출시 일정을 위한 시간대)도 함께 물어보세요.
2단계: 이름 확인
python3 <skill-dir>/scripts/name_check.py <name> [alternative ...]
이 스크립트는 crates.io, npm, PyPI, Homebrew 및 GitHub에서 이름을 확인합니다. 이름이 겹치면 검색 결과가 분산되어 프로젝트를 찾기 어려워지고, 이미 등록된 패키지 관리자 이름은 게시를 막습니다. 결과가 AVOID 또는 CROWDED이면 3~4개의 대안을 제안하고 같은 실행에서 확인하세요. 좋은 이름은 도구의 기능을 설명하거나 연상시키며, 한 번 들으면 철자를 쉽게 떠올릴 수 있어야 합니다.
이름 변경은 사용자의 결정입니다. 이름을 변경하는 경우 매니페스트, 바이너리 이름, README, 링크, CI, 설정 경로, User-Agent 문자열 등 모든 곳에서 변경하세요. 파일을 순회하는 스크립트를 사용하여 경로에 공백이 있을 때 문제가 될 수 있는 셸의 단어 분할을 피하세요. 그런 다음 다시 빌드하고 테스트를 실행하세요.
3단계: 감사(Audit)
python3 <skill-dir>/scripts/audit.py <repo-path>
100점 만점의 점수와 가중치 순으로 정렬된 수정 목록을 얻을 수 있습니다. README 후크, 상단 근처의 시각적 요소와 설치 명령어, 라이선스 및 커뮤니티 파일, CI 및 릴리스 워크플로우, 유출된 비밀, 개인 커밋 이메일, 그리고 gh가 로그인된 경우 GitHub 설명, 주제, 소셜 프리뷰 및 릴리스를 확인합니다.
다음 두 가지는 공개 푸시 후 되돌릴 수 없으므로 다른 어떤 것보다 먼저 처리해야 합니다.
- 추적된 파일의 비밀(secret). 제거하고 사용자에게 비밀을 교체하도록 알리세요. 이미 git 기록에 남아 있습니다.
- 개인 커밋 이메일(Gmail 등). 모든 공개 커밋에 표시됩니다. 저장소의 이메일을 사용자의 GitHub noreply 주소(
[email protected])로 설정하세요. ID는gh api user --jq .id로 가져옵니다.
6단계가 끝나면 감사를 다시 실행하세요. 점수가 오르는 것은 사용자의 진행 상황을 보여주므로 표시하세요.
4단계: README를 랜딩 페이지로
references/readme.md를 읽고 해당 구조로 README를 다시 작성하세요. 핵심 아이디어: 방문자는 첫 화면만 보고 약 10초 안에 결정을 내립니다. 따라서 첫 화면에는 불편함, 증명(GIF) 및 설치 명령어가 포함되어야 합니다. 설명은 그 다음에 옵니다.
README의 모든 주장은 현재 코드에 대해 사실이어야 합니다. 작성하기 전에 각 기능, 플래그 및 숫자를 소스 코드나 실제 실행 결과와 확인하세요. 과장된 주장은 HN 첫 댓글에서 지적되고, 얻는 신뢰보다 더 많은 손해를 입힙니다. 향후 작업은 명확하게 표시된 '로드맵' 섹션에 넣으세요.
5단계: 데모 및 소셜 프리뷰
references/demo.md를 읽으세요. 프로젝트 유형에 따라 형식을 선택하세요.
- CLI 또는 TUI: VHS로 GIF를 녹화하고, 테이프 파일을
docs/demo.tape에 커밋하여 누구나 다시 녹화할 수 있도록 하세요. - 웹 앱: 스크린샷 또는 짧은 화면 녹화.
- 라이브러리: 실제 출력이 포함된 전/후 코드 조각.
그런 다음 소셜 프리뷰를 만드세요.
sh <skill-dir>/scripts/social_preview.sh docs/demo.gif docs/social-preview.png
다음 단계로 넘어가기 전에 프레임을 직접 확인하세요. ffmpeg로 2~3개의 프레임을 추출하여 확인하세요. 녹화는 조용히 실패할 수 있습니다. 환경에 NO_COLOR가 설정되어 색상이 사라지거나, 토큰이 화면에 입력되거나, 선택한 행에서 텍스트를 읽을 수 없거나, 로딩 스피너가 보이는 프레임을 캡처하는 등의 문제가 발생할 수 있습니다. 문제를 수정하고 다시 녹화하세요. 프레임을 확인하는 것은 저렴하지만, README 상단의 깨진 GIF는 그렇지 않습니다.
6단계: 릴리스 및 CI
프로젝트의 생태계에 맞게 references/release.md를 읽으세요. 목표는 도구 체인이 없는 사람들을 위한 설치 경로(태그 푸시로부터의 사전 빌드된 바이너리 또는 게시된 패키지)를 제공하는 것입니다. 게시 단계는 해당 시크릿이 설정되지 않았을 때 깔끔하게 건너뛰도록 하여, 사용자의 첫 번째 릴리스가 빨간색 실패를 보여주지 않도록 하세요. 로컬에서 프로젝트의 린트, 포맷 및 테스트 명령어를 실행하고 통과시키세요. 첫 번째 푸시에서 CI가 이를 실행하기 때문입니다.
7단계: 출시 키트
python3 <skill-dir>/scripts/launch_time.py --tz <사용자의 IANA 시간대>
이 명령어는 다음 화요일, 수요일 또는 목요일 오전 8시 30분(미국 동부 시간)을 선택하고, 서머타임 규칙을 따라 사용자의 시간대로 변환합니다. 미국 선거 주, 추수감사절 주, 크리스마스부터 새해까지, 7월 4일을 건너뛰고 그 이유를 설명합니다. 머리로 변환하지 마세요. 미국/유럽의 서머타임 변경은 오프셋을 1년에 두 번 한 시간씩 바꿉니다. 웹 검색이 가능하다면 선택한 주에 기술 뉴스를 장악할 만한 큰 이벤트(주요 Apple, Google 또는 OpenAI 이벤트, 대규모 장애)가 있는지 확인하고 필요시 하루를 조정하세요.
그런 다음 references/launch-posts.md를 읽고 저장소의 상위 폴더(또는 사용자가 선호하는 경우 docs/ 폴더)에 LAUNCH.md를 작성하세요. 이 파일에는 일정, 출시 전 체크리스트, Show HN 제목 및 첫 번째 댓글, 가장 적합한 서브레딧을 위한 2~3개의 Reddit 게시물, X 스레드, 그리고 다음 날 계획이 포함됩니다.
게시물의 이야기는 실제여야 합니다. 프로젝트가 존재하는 이유 또는 구축하면서 배운 점에 대해 실제로 사실인 내용을 사용하세요. 모르는 경우 사용자에게 실제 동기를 한 문장으로 물어보세요. 배경 이야기, 사용자 수 또는 벤치마크를 절대 만들어내지 마세요.
8단계: 인계
다음 내용을 포함한 짧은 메시지로 마무리하세요.
- 감사 점수: 전과 후.
- 저장소에 추가된 파일 목록.
- 사용자가 게시하기 위해 실행해야 하는 정확한 명령어: 공개 저장소 생성, 푸시, CI 대기, 릴리스 태그.
- API로는 할 수 없는 수동 단계: 소셜 프리뷰 업로드(설정 > 소셜 프리뷰), 저장소 고정, 프로필 세부 정보 수정.
- 사용자 시간대의 출시 날짜와 시간, 그리고
LAUNCH.md의 위치.
게시했다고 사용자가 말하면 확인을 제안하세요. 저장소가 공개되어 있는지, CI가 통과했는지, 릴리스에 자산이 있는지, 설치 명령어가 깨끗한 디렉토리에서 작동하는지, 소셜 프리뷰가 설정되었는지(gh api graphql -f query='{repository(owner:"o",name:"r"){usesCustomOpenGraphImage}}') 확인하세요.
출시를 성공으로 이끄는 요소
다음은 각 단계가 제공하는 아이디어입니다. 단계에서 다루지 않는 결정을 내릴 때 사용하세요.
- 설명보다는 보여주세요. 작동하는 GIF 하나가 세 문단의 설명보다 낫습니다.
- 한 줄로 시도해보세요. 첫 번째 "아, 괜찮네"라는 반응 전에 추가 단계가 있으면 사람들이 떠납니다.
- 정직하고 구체적으로 말하세요. "이번 주에 얻은 별점으로 저장소 순위를 매깁니다"는 "AI 기반 분석 플랫폼"보다 낫습니다. HN 사용자는 과장된 마케팅을 싫어하고 진짜 이야기를 좋아합니다.
- 타이밍과 답글은 게시물 자체만큼 중요합니다. 대상 청중이 깨어 있을 때 게시하고, 처음 3시간 동안 모든 댓글에 답하세요.
- 추천(upvote)이나 별(star)을 요청하지 마세요. HN에서는 게시물이 신고 처리됩니다. 다른 곳에서는 스팸으로 읽힙니다.