공개로 빌드하기

개요

이 스킬은 프로젝트가 이미 작동하고 있으며, 공개적으로 제공할 수 있도록 프레젠테이션, 안전성 및 사용성을 개선하는 작업을 할 때 사용합니다. 기본 대상은 ~/.codex/workspaces/default/repos/ 또는 ~/.codex/workspaces/default/labs/ 아래의 샌드박스 리포지토리이지만, 동일한 워크플로는 모든 로컬 저장소에서 작동합니다.

리소스

references/public-release-checklist.md 공개 출시 게이트 및 최종 완료 패스에 사용합니다.
references/readme-template.md README.md를 작성하거나 재구성할 때 사용합니다.
scripts/create_release_zip.sh 리포지토리가 준비된 후 현재 HEAD에서 깔끔한 ZIP 파일을 만드는 데 사용합니다.

네이티브 Codex 기능

호스트가 네이티브 Codex 앱 또는 CLI 기능을 제공하는 경우, 이를 필수 종속성으로 만들지 않고 가속기로 사용하세요:

변경될 수 있는 현재 게시 플랫폼 사실, 패키지 관리자 동작, 보안 권고 또는 문서에 대해 웹 검색을 사용하세요. 기본 출처를 선호하고 최종 보고서에 인용하세요.
리포지토리 맵, 아키텍처 다이어그램, 배너 또는 설명 자산이 프로젝트를 이해하기 쉽게 만들 때 README 시각 자료를 위해 내장 이미지 생성 기능을 사용하세요. 이미지를 생성하고, 검사하고, 최종 선택된 파일을 리포지토리의 assets/ 아래에 복사하고, 적절한 내러티브 위치에 있는 README에 삽입하고, 설명적인 대체 텍스트를 사용하고, 생성된 텍스트가 완벽하지 않은 경우 중요한 기술 레이블을 Markdown, Mermaid, SVG 또는 근처 산문에 유지하세요.
앱 내 브라우저를 사용하여 로컬 웹 미리보기, 파일 기반 미리보기 및 로그인이 필요하지 않은 공개 페이지의 시각적 검토를 수행하세요.
프로젝트가 데스크탑 앱, 시뮬레이터 흐름, 스프레드시트, 문서, 프레젠테이션 또는 일반 셸/브라우저 도구로 확인할 수 없는 다른 표면인 경우에만 좁은 GUI 확인에 컴퓨터 사용을 사용하세요.
Codex 앱 워크트리를 사용하여 격리된 탐색 또는 병렬 릴리스 준비 작업을 수행한 다음 의도된 파일만 게시 경로로 승격하세요.
네이티브 Git 검토, 스테이징, 커밋, 푸시 및 PR 지원을 사용할 수 있는 경우 사용하지만, 여전히 diff를 검사하고 작업 트리를 관련 없는 로컬 상태로부터 자유롭게 유지하세요.
반복되는 릴리스 상태 확인, 예약된 유지 관리 보고서 또는 후속 모니터링에만 자동화를 사용하고, 일회성 게시 결정을 반복적인 백그라운드 작업으로 바꾸지 마세요.
네이티브 하위 에이전트는 사용자 또는 호스트 정책이 병렬 위임을 허용하는 경우에만 사용하고, 파일 소유권이 겹치지 않도록 위험 감사, 문서 검토 및 확인과 같은 독립적인 작업을 분할하세요.

기본 결과

이 스킬이 완료되면 리포지토리에는 다음이 포함되어야 합니다:

문제, 빌드 이유, 기능 및 사용 방법을 명확하게 설명하는 README
콜드 리더 방향 설정을 실질적으로 개선하는 경우 선택적 프로젝트별 다이어그램 또는 시각 자산
깔끔한 공개 설명 및 제안된 GitHub 주제
설정, 오류, 무시된 파일 및 사용자 대상 기본값에 대한 기본적인 강화
주요 경로와 최소한 하나의 에지 또는 실패 사례를 입증하는 테스트 또는 스모크 검사
필요한 경우 라이선스 및 예제 구성
커밋된 코드에서 생성된 깔끔한 ZIP 아티팩트
사용자의 개인 프로필에 있는 공개 GitHub 리포지토리 또는 게시를 기다려야 하는 정확한 차단기 설명

릴리스 전략

편집하기 전에 더 안전한 경로를 선택하세요:

기존 리포지토리의 Git 기록, 파일 세트 및 명명이 이미 공개하기에 안전한 경우 이를 재사용합니다.
작업 중인 프로젝트는 좋지만 기존 리포지토리에 임시 기록, 개인 메모, 실험 잔해 또는 기록에 비밀이 있는 경우 깔끔한 공개 내보내기 리포지토리를 만듭니다.

규칙:

샌드박스 프로젝트의 경우, 공개 기록이 의심스러운 경우 ~/.codex/workspaces/default/repos/<slug>-public 아래의 형제 공개 리포지토리를 선호합니다.
간단한 메모로 출처를 보존하지만, 개인 경로, 내부 프로젝트 이름 또는 개인 머신 세부 정보를 유출하지 마십시오.
현재 리포지토리를 안전하게 만들기 위해 기록 재작성이 필요한 경우, 사용자가 명시적으로 기록 보존을 원하지 않는 한 깔끔한 공개 내보내기를 선호합니다.
리포지토리를 콜드 클론한 낯선 사람이 이해할 수 있을 때까지 아무것도 게시하지 마십시오.

워크플로

1. 사전 점검

대상 리포지토리, 원격 저장소, Git 상태, 빌드 시스템, 테스트 명령 및 범위 내의 모든 AGENTS.md를 검사합니다.
references/public-release-checklist.md를 읽습니다.
README를 생성하거나 재작성해야 하는 경우 references/readme-template.md를 읽습니다.
현재 위치에서 강화할지 아니면 깔끔한 공개 내보내기 리포지토리를 만들지 결정합니다.
리포지토리 자체에서 예상되는 공개 이름, 한 줄 설명, 설치 흐름 및 대상 사용자를 도출합니다. 진정으로 모호한 경우에만 질문합니다.
공개로 빌드하라는 요청이 있을 때 게시 대상을 사용자의 개인 GitHub(공개 가시성)로 기본 설정합니다.
현재 환경에서 사용 가능한 네이티브 Codex 기능을 확인한 다음, 가장 가벼운 유용한 경로를 선택합니다: 결정적인 리포지토리 작업을 위한 로컬 셸, 현재 외부 사실을 위한 웹 검색, UI 확인을 위한 브라우저/컴퓨터 사용, 도움이 되는 시각 자료를 위한 이미지 생성, 그리고 안전하게 처리량을 향상시키는 경우에만 워크트리/하위 에이전트.
발상을 물어보세요. 아무것도 쓰기 전에 코드를 충분히 깊이 읽어 이것이 만들어진 이유에 대한 세 가지 그럴듯한 가설을 세웁니다. 그런 다음 사용자에게 질문하세요 — 세 가지 최선의 추측을 옵션으로 제시하고 완전히 다른 내용을 위한 자유 텍스트 필드를 함께 제시하세요:
이것을 만들게 된 순간은 무엇인가요?
1. [코드에서 도출한 첫 번째 가설]
2. [두 번째 가설]
3. [세 번째 가설]
4. 다른 것 — 자신의 말로 알려주세요
이 패턴은 이 스킬의 모든 AskUserQuestion 호출에 적용됩니다: 항상 이미 읽은 내용을 기반으로 세 가지 구체적인 옵션을 제안한 다음 사용자가 재정의할 수 있도록 여지를 남겨둡니다. 개방형 질문보다 빠르며, 사용자의 가설은 종종 고려하지 못했던 프레임을 표면화합니다.

답변을 맥락으로 취급하고 절대적인 진리로 취급하지 마십시오. 사용자는 자신의 동기를 알고 있지만 기술적 관심을 과소평가하거나, 디자인에서 실제로 매력적인 점을 놓치거나, 너무 좁게 프레이밍할 수 있습니다. 당신의 임무는 코드를 읽고 진정으로 이야기할 가치가 있는 것을 찾은 다음, 그들의 답변을 렌즈로 사용하는 것입니다. 코드가 기본 출처입니다. 그들의 답변은 힌트입니다.

2. 공개 위험 감사

공개되어서는 안 되는 항목이 있는지 리포지토리를 검사합니다:

비밀, .env 파일, 토큰, API 키, 개인 자격 증명 또는 복사된 셸 기록
내부 URL, 개인 이메일, 절대 로컬 경로, 머신별 지침 또는 개인 스크린샷
재배포할 수 없는 개인 데이터 세트, 벤더 자산 또는 샘플 파일
캐시, 로그, 생성된 데이터베이스, 디버그 출력 및 로컬 전용 아티팩트
잘못된 이야기를 전하거나 개인 컨텍스트를 노출하는 임시 커밋 기록

지침:

먼저 빠른 로컬 검사(rg, git status, git log, git ls-files 및 대상 파일 읽기)를 사용하세요.
위험이 작업 트리에 있는 경우 정리하세요.
위험이 기록에만 있는 경우, 위험한 기록 수술보다 깔끔한 내보내기 리포지토리를 선호하세요.

3. 리포지토리 강화

프로젝트를 다른 사람이 사용할 수 있게 만드는 가장 작은 신뢰할 수 있는 패스를 수행하세요:

설치 및 실행 단계를 결정적으로 만듭니다.
필요한 경우 env.example, 샘플 구성 및 무시 규칙을 추가하거나 강화합니다.
기본 진입점을 개선하여 오류를 읽기 쉽게 하고 기본값을 합리적으로 만듭니다.
첫 번째 사용자를 혼란스럽게 하는 죽은 실험용 클러터를 제거합니다.
주요 경로와 최소한 하나의 실패 또는 에지 케이스를 포함하도록 테스트를 추가하거나 개선합니다.
증명을 제품 형태에 맞춥니다:
- CLI: 명령 도움말 및 실제 명령 스모크 테스트
- 라이브러리: 공개 API 주변의 단위 테스트
- 웹 앱: 주요 흐름에 대한 브라우저 또는 요청 수준 스모크 테스트
- API/서비스: 요청-응답 증명 및 오류 처리 확인
리포지토리에 이미 자동화할 가치가 있는 간단한 명령이 있는 경우에만 경량 CI를 추가합니다.
리포지토리나 사용자가 명확하게 다른 곳을 가리키지 않는 한 라이선스를 MIT로 기본 설정합니다.

이것을 대규모 재작성으로 바꾸지 마십시오. "공개 준비"는 처음부터 다시 빌드하는 것이 아니라 정직하게 공유할 수 있을 만큼 세련된 것을 의미합니다.

4. 공개 문서 작성

낯선 사람이 빠르게 방향을 잡을 수 있도록 공개 문서를 만들거나 다시 작성하세요:

README 구조에 references/readme-template.md를 사용합니다.
먼저 문제를 설명하고, 그 다음 이 리포지토리가 존재하는 이유, 그 다음 실행 방법을 설명합니다.
새로운 클론에서 작동하는 하나의 구체적인 빠른 시작 경로를 포함합니다.
테스트 명령 및 필요한 모든 로컬 종속성을 문서화합니다.
현재 제한 사항, 플랫폼 가정 또는 미흡한 부분에 대해 명시적으로 설명합니다.
내부 컨텍스트를 과도하게 공유하지 않고 프로젝트의 기원을 설명하는 짧은 공개 빌드 노트를 포함합니다.
콜드 리더가 파일 레이아웃, 데이터 흐름 또는 사용자 워크플로를 이해하는 데 도움이 되는 경우 시각적 리포지토리 맵 또는 아키텍처 다이어그램을 포함합니다. 정확한 레이블을 위해 Mermaid 또는 리포지토리 네이티브 다이어그램을 선호합니다. 세련된 다크 모드 일러스트레이션, 배너 또는 지원 시각 자료에는 네이티브 이미지 생성을 사용합니다.
준비:
- 한 줄 GitHub 설명
- 짧은 주제 목록
- 사용자가 초기 릴리스를 원하는 경우 선택적 릴리스 노트

ASCII 배너를 생성하세요. 모든 README는 맨 위, 다른 모든 것 위에 figlet 배너가 있어야 합니다. rectangles 글꼴을 사용하세요 — 기울어진 문자는 사용하지 마십시오. 다음을 실행하세요:

figlet -f rectangles -w 200 "<배너 텍스트>"

배너 텍스트 규칙:

리포지토리 슬러그가 아닌 프로젝트의 표시 이름을 사용하세요.
하이픈을 공백으로 바꾸세요(build-in-public → build in public).
모든 것을 소문자로 유지하세요(Mock Pop → mock pop).
표시 이름이 리포지토리 슬러그와 다른 경우(예: 리포지토리 superwhisperer-lab, 표시 이름 superwhisper lab), 표시 이름을 사용하세요.

출력을 펜스 코드 블록으로 감싸세요. figlet이 설치되지 않은 경우: brew install figlet. 이것은 누군가가 가장 먼저 보는 것입니다. 프로젝트가 실제 정체성을 가지고 있음을 알립니다.

README 시각 자료를 생성하고 배치하세요. 생성된 이미지가 README에 속하는 경우, 임시 미리보기가 아닌 커밋된 프로젝트 아티팩트로 취급하세요:

이미지를 생성하기 전에 이미지의 역할과 배치를 결정하세요:
- 리포지토리 전체 개요, 아키텍처 맵 또는 히어로 시각 자료: README.md 상단, 제목과 한 줄 요약 바로 뒤 또는 짧은 시작 단락 뒤에 배치하세요.
- 기능 스크린샷 또는 워크플로 이미지: 설명하는 섹션, 상세한 산문 또는 지원 예제 앞에 배치하세요.
- 보충 이미지: README 하단에 배치하거나 아무것도 명확히 하지 않으면 생략하세요.
가능한 경우 네이티브 Codex 이미지 생성으로 이미지를 생성하거나, 정확한 텍스트 또는 결정적 구조가 더 중요한 경우 Mermaid/SVG/리포지토리 네이티브 출력을 사용하세요.
가독성, 왜곡된 레이블, 개인 정보 및 프로젝트를 실제로 명확히 하는지 결과를 검사하세요.
최종 선택된 이미지를 리포지토리에 복사합니다(일반적으로 assets/<설명적-이름>.<확장자> 또는 docs/assets/<설명적-이름>.<확장자>). README에서 참조하는 자산을 생성된 이미지, 다운로드, temp 또는 로컬 캐시 디렉토리에만 남겨두지 마십시오.
상대 경로와 의미 있는 대체 텍스트를 사용하여 이미지를 README.md에 삽입하세요:
```
![다크 모드 리포지토리 구조 다이어그램](assets/repo-structure-dark.png)
```
클론, 포크, GitHub 렌더링 및 릴리스 ZIP에서 경로가 유효하도록 이미지와 README 업데이트를 함께 커밋하세요.
시각 자료가 다시 생성될 경우, README가 항상 최신 이미지를 표시해야 하는 경우 안정적인 파일 이름을 사용하고, 이전 출력을 보존하는 것이 중요한 경우 버전이 지정된 파일 이름을 사용하세요. 반복성이 중요한 경우 생성 프롬프트, 소스 다이어그램 또는 스크립트를 리포지토리에 보관하세요.

코드에서 내러티브를 구축하고 사용자에게 정보를 얻으세요. 사용자의 발상 답변은 컨텍스트입니다 — 이를 사용하여 의도를 이해하고 그들의 이야기를 그대로 쓰지 마십시오. 실제 내러티브는 코드를 면밀히 읽는 데서 나옵니다: 디자인이 실제로 해결하는 문제는 무엇인가, 명확하지 않은 결정은 무엇인가, 동료 개발자가 흥미롭거나 가져갈 가치가 있다고 생각할 것은 무엇인가?

내레이터로서의 임무:

코드에서 실제로 흥미로운 것을 찾으세요 — 디자인을 형성한 제약 조건, 명백한 솔루션과 다른 접근 방식, 의도적으로 이루어진 트레이드오프.
문제를 적절한 수준의 구체성으로 프레이밍하세요: 같은 좌절감을 겪은 사람이 인식할 수 있을 만큼 구체적이면서, 사용자의 정확한 머신에만 국한되지 않을 만큼 일반적이어야 합니다.
목소리를 부여하세요 — 과장된 광고 카피가 아니라, 실제로 annoying한 문제를 해결하고 그 방법을 알려주고 싶어하는 개발자의 명확하고 약간은 흥분된 어조로.

사용자의 설명이 얕은 경우("그냥 작동하게 하려고 했어요"), 코드를 파고들어 직접 진짜 이야기를 찾으세요. 사용자의 설명이 코드가 보장하는 것보다 기술적으로 더 풍부한 경우, 끌어내리세요. README는 프로젝트가 무엇인지에 대해 정직해야 합니다 — 작고, 유용하며, 잘 만들어진 도구 — 과대평가되지 않아야 합니다.

어조는: "여기 실제 문제가 있고, 여기 내가 만든 것이 있으며, 여기 작동 방식에 대해 흥미로운 점이 있습니다." 작은 도구도 좋은 이야기를 가질 수 있습니다. 평평하게 만들지 말고 부풀리지도 마세요.

문서 확산을 피하세요. 강력한 README, 라이선스 및 최소한의 지원 파일은 의식적인 문서 더미보다 낫습니다.

5. 확인 및 패키징

리포지토리가 합리적으로 지원할 수 있는 가장 강력한 확인을 실행하세요:

관련 설치, 빌드, 린트, 테스트 및 스모크 명령을 실행합니다.
실제 코드에 대해 빠른 시작 지침을 확인합니다.
실용적이라면 현재 머신 상태를 신뢰하는 대신 콜드 클론 경로를 시뮬레이션합니다.
웹 또는 시각적 표면의 경우, 가능한 경우 앱 내 브라우저를 사용하고 확인 결과를 보고서에 캡처합니다.
GUI 전용 표면의 경우, 컴퓨터 사용을 좁게 사용하고 확인된 내용을 기록합니다.
커밋된 코드에서 공개 ZIP 아티팩트를 생성합니다:

bash "$(dirname "$0")/scripts/create_release_zip.sh" <리포지토리-경로>
# 또는 설치된 스킬에서:
#   bash ~/.claude/skills/build-in-public/scripts/create_release_zip.sh <리포지토리-경로>   # Claude Code
#   bash ~/.codex/skills/build-in-public/scripts/create_release_zip.sh <리포지토리-경로>    # Codex

헬퍼는 ZIP을 ~/.codex/workspaces/default/artifacts/ 아래에 <slug>-<version>.zip으로 씁니다. 릴리스 아티팩트는 항상 커밋된 코드에서 생성하십시오 — 그렇지 않으면 ZIP이 클론 가능한 상태를 나타내지 않습니다.

아티팩트를 검사하고(압축 풀기, 빠른 ls, README가 있는지 확인) 결과를 요약합니다.

6. GitHub에 게시

리포지토리를 GitHub에 게시합니다. 사용 가능한 경우 네이티브 Git 원격 관리 및 푸시 지원을 사용하거나, 사용 가능한 셸 명령어를 사용합니다:

게시 시기를 결정하기 위해 공개 릴리스 체크리스트를 다시 확인합니다.
사용 가능한 경우 네이티브 GitHub 지원을 사용하거나, GitHub CLI(gh)를 통해 GitHub 리포지토리를 생성합니다:
- 계정 확인: gh auth status
- 리포지토리 생성: gh repo create <소유자>/<이름> --public --source=. --remote=origin --push
공개 리포지토리에 게시하는 동안 실패하지 않도록 Git 원격이 SSH 또는 HTTPS를 통해 연결되는지 확인합니다.
각 사전 릴리스 파일이 로컬에 커밋되고 푸시되었는지 확인합니다.
지연을 피하기 위해 완벽을 추구하지 마십시오: README.md가 합리적이고, 라이선스가 정확하고, 리포지토리가 깔끔하면 게시하십시오.
게시 결정을 지연시키는 정확한 차단기를 요약하십시오.

기본 게시 정책: 사용자가 요청하는 경우가 아니면 GitHub Actions, CI/CD, 브랜치 보호, 추가 공동 작업자 또는 웹후크를 설정하지 마십시오. 모든 것이 커밋되고 푸시되면 GitHub 리포지토리는 공개이며, 명시적 동의가 없으면 추가 구성을 수정하지 마십시오.

7. 최종 보고

다음을 포함하는 최종 요약을 제공합니다:

공개 URL 또는 게시를 차단하는 정확한 차단기
주요 파일(README, 라이선스, 구성, 테스트) 요약
릴리스 ZIP 위치
감사 결과
의도적으로 해결되지 않은 모든 위험 또는 알려진 미흡한 부분에 대한 정직한 메모
이 스킬의 모든 기능(웹 검색, 이미지 생성, 브라우저, 컴퓨터 사용, 워크트리, Git 도구, 자동화, 하위 에이전트) 중 사용된 것과 그 이유에 대한 간략한 설명

마지막 메시지는 간결하고 정중하게 종료되어야 하며, "무엇을 도와드릴까요?"라는 일반적인 열린 질문이 아닙니다. 완료되었거나, 차단되었거나, 사용자 입력이 필요하다는 명확한 언급으로 종료하십시오.

설치

Claude Code

# ~/.claude/skills/ 아래에 복제하거나 심볼릭 링크 생성
git clone https://github.com/davidvictor/build-in-public ~/.claude/skills/build-in-public
# 또는: ln -s $(pwd)/build-in-public ~/.claude/skills/build-in-public

Codex

# ~/.codex/skills/ 아래에 복제하거나 심볼릭 링크 생성
git clone https://github.com/davidvictor/build-in-public ~/.codex/skills/build-in-public
# 또는: ln -s $(pwd)/build-in-public ~/.codex/skills/build-in-public

그런 다음 에이전트에게 "이 프로젝트를 공개로 빌드"하거나 "공개할 준비를 해줘"라고 요청하세요.

요구 사항

bash, git, gh(GitHub CLI)
figlet (선택 사항이지만 권장 — 배너 생성용)
로컬 저장소(모든 언어/프레임워크)

davidvictor/build-in-public

build-in-public란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

미리보기

문서

공개로 빌드하기

개요

리소스

네이티브 Codex 기능

기본 결과

릴리스 전략

워크플로

1. 사전 점검

2. 공개 위험 감사

3. 리포지토리 강화

4. 공개 문서 작성

5. 확인 및 패키징

6. GitHub에 게시

7. 최종 보고

설치

Claude Code

Codex

요구 사항

관련 스킬

steipete/sag

steipete/oracle

steipete/peekaboo

mattpocock/design-an-interface

mattpocock/prototype

mattpocock/grill-me