GitHub 저장소 최적화

모든 GitHub 저장소를 고전환, SEO 최적화 랜딩 페이지로 변환하여 스타, 팔로워 및 트래픽을 유도합니다. 당신이 다루는 모든 저장소는 상위 100개 오픈 소스 프로젝트처럼 보여야 합니다.

이 스킬은 두 가지 모드가 있습니다:

최적화 — 저장소의 README, 메타데이터 및 구조를 최대 전환율로 재작성합니다.
조언 — 아래 지식 베이스를 사용하여 사용자에게 스타 성장 전략을 제공합니다.

목표 (우선 순위 순)

스타 — GitHub의 주요 사회적 증거 지표
팔로워 — 저장소 소유자의 소셜 프로필로 트래픽 유도
검색 가능성 — GitHub 검색, Google 및 LLM 답변 엔진에서 순위
트래픽 — 방문자를 사용자/팔로워로 전환
전문적 신뢰도 — 구조와 세련됨을 통해 품질 신호 전달

0단계: 사용자 구성 (자체 업데이트)

최적화를 시작하기 전에 이 저장소의 소유자가 누구인지 알아야 합니다. 이 단계는 한 번 실행되며, 이후에는 구성을 재사용합니다.

기존 구성 확인

~/.claude/skills/github-optimization/.config.yml 파일을 찾습니다. 존재하면 값을 로드하고 1단계로 건너뜁니다. 로드된 내용을 사용자에게 보여주고 변경된 사항이 있는지 묻습니다.

구성이 없으면 감지 + 질문

git config 및 GitHub API에서 자동 감지:
- gh api user — 인증된 GitHub 사용자 이름 및 프로필 URL을 가져옵니다.
- gh api repos/<소유자>/<저장소> — 저장소 소유자(조직 또는 사용자)를 가져옵니다.
- git config user.name — 로컬 git 표시 이름을 가져옵니다.
감지할 수 없는 항목은 사용자에게 질문:
- 표시 이름 — 실제 이름 또는 선호하는 귀속 이름 (예: "홍길동")
- X/Twitter 핸들 — Follow 배지용 (예: "@gildong"). 원하지 않으면 건너뜁니다.
- 회사 또는 조직 — 바닥글 귀속용 (선택 사항)
- 회사 URL — 회사 이름 링크 (선택 사항)
- 웹사이트 URL — 개인 또는 회사 사이트 (선택 사항)
구성을 ~/.claude/skills/github-optimization/.config.yml에 저장:

# GitHub Optimization Skill — 사용자 구성
# 이 파일은 자동 생성됩니다. 언제든지 수정하세요.
author_name: "홍길동"
author_github: "gildong"
x_handle: "gildong"          # Follow 배지를 건너뛰려면 빈 문자열 ""로 설정
company_name: "에이콤 주식회사"  # 건너뛰려면 빈 문자열 ""로 설정
company_url: "https://acme.com"
website_url: "https://gildong.dev"

파이프라인 전체에서 다음 변수를 사용:
- {OWNER} — GitHub 사용자 이름 또는 조직 (저장소 URL에서 저장소별로 감지)
- {REPO} — 저장소 이름 (저장소별로 감지)
- {AUTHOR_NAME} — 구성에서 가져옴
- {AUTHOR_GITHUB} — 구성에서 가져옴
- {X_HANDLE} — 구성에서 가져옴 (비어 있을 수 있음)
- {COMPANY_NAME} — 구성에서 가져옴 (비어 있을 수 있음)
- {COMPANY_URL} — 구성에서 가져옴 (비어 있을 수 있음)
- {WEBSITE_URL} — 구성에서 가져옴 (비어 있을 수 있음)

필드가 비어 있으면 출력에서 해당 요소를 완전히 생략합니다. 빈 자리 표시자나 깨진 배지가 없어야 합니다.

구성 업데이트

사용자가 "내 구성 업데이트", "X 핸들 변경" 등과 같이 말하면 .config.yml 파일을 업데이트하고 변경 사항을 확인합니다.

최적화 파이프라인

0. CONFIG       -> 사용자 구성 로드 또는 생성 (한 번 실행, 자체 업데이트)
1. AUDIT        -> 현재 README, 설명, 토픽, 저장소 구조 읽기
2. KEYWORDS     -> 이 저장소 도메인에 대한 타겟 검색어 식별
3. METADATA     -> 저장소 이름, 설명(About) 및 토픽 최적화
4. README       -> 아래 템플릿에 따라 README를 랜딩 페이지로 재작성
5. HUMANISE     -> 모든 산문에 대해 humanise-text 스킬을 실행하여 AI 패턴 제거
6. EXTRAS       -> LICENSE, CONTRIBUTING.md 누락 시 추가
7. PUBLISH      -> 커밋, 푸시, gh repo edit으로 설명/토픽 적용

스킬 체인

이 스킬은 실행 중에 다른 스킬을 호출합니다:

humanise-text — README 초안 작성 후, 모든 산문 섹션에 대해 humanise-text 스킬을 호출합니다. 이는 AI 작문 패턴을 제거하고 복사본이 실제 사람이 쓴 것처럼 들리게 만듭니다. 모든 README는 반드시 이 단계를 거쳐야 합니다.

1단계: 감사

현재 상태를 읽습니다:

README.md 내용 및 구조
저장소 설명(About 섹션)
토픽/태그
라이선스
파일 구조
기존 배지

무엇이 누락되었는지, 무엇이 약한지, 무엇이 좋은지 기록합니다.

2단계: 키워드 연구

개발자가 이 프로젝트를 찾기 위해 검색할 3-5개의 타겟 키워드를 식별합니다. 다음을 고려하세요:

이 프로젝트는 어떤 문제를 해결합니까?
어떤 기술을 사용합니까?
어떤 도메인에 속합니까?

이 키워드는 저장소 이름(가능한 경우), About 설명, README H1 및 H2 헤더, 토픽 태그에 나타나야 합니다.

3단계: 메타데이터 최적화

About 설명

120자 미만이 이상적, 최대 250자
무엇인지(what it is)보다 무엇을 하는지(what it does)로 시작
기본 키워드를 자연스럽게 포함
형식: <동작 동사> <대상> for <누구/무엇>. <핵심 차별점>.

토픽 태그

세 가지 범주에서 10-20개의 태그를 선택합니다:

목적 태그 — 프로젝트가 하는 일
기술 스택 태그 — 사용된 기술
도메인 태그 — 분야 또는 산업

다음 명령어로 적용:

gh repo edit {OWNER}/{REPO} --add-topic tag1 --add-topic tag2 ...

4단계: README 재작성

README는 문서가 아닌 랜딩 페이지입니다.

README 템플릿

구성에서 사용 가능한 사용자 정보에 따라 배지를 조정합니다:

<div align="center">

# <프로젝트 이름>

**<한 줄 피치 — 일반 영어로 무엇을 하는지>**

<br />

[![이 저장소에 스타 부여](https://img.shields.io/github/stars/{OWNER}/{REPO}?style=for-the-badge&logo=github&label=%E2%AD%90%20Star%20this%20repo&color=yellow)](https://github.com/{OWNER}/{REPO}/stargazers)

{X_HANDLE}이 설정된 경우, 스타 배지 옆에 추가:

&nbsp;&nbsp;
[![@ {X_HANDLE} 팔로우](https://img.shields.io/badge/Follow_%40{X_HANDLE}-000000?style=for-the-badge&logo=x&logoColor=white)](https://x.com/{X_HANDLE})

{X_HANDLE}이 비어 있으면 Follow 배지를 완전히 생략합니다.

그런 다음 신뢰 배지를 계속 추가합니다:

<br />

[![<배지 1>](shields-url)](<링크>)
&nbsp;
[![<배지 2>](shields-url)](<링크>)

---

<한 문단 피치. 어떤 고통을 해결하는가? 왜 누군가가 신경 써야 하는가?>

[설치](#설치) | [작동 방식](#작동-방식) | [기능](#기능) | [기여](#기여)

</div>

배지 규칙

1행 (CTA — 크고 눈에 띄게):

실시간 카운트가 있는 스타 배지 — 항상 먼저, style=for-the-badge, 노란색
X 팔로우 배지 — {X_HANDLE}이 설정된 경우에만

2행 (신뢰 배지 — 같은 크기):

모든 배지는 style=for-the-badge 사용 — 크기를 섞지 않음
2-4개 선택: 라이선스, PR 환영, 언어/프레임워크, 빌드 상태

섹션 순서

존재 이유 / 문제 — 고통 지점에 대한 2-3문장
전 vs 후 (선택 사항) — 비교 표
설치 / 빠른 시작 — 5단계 미만, 하나의 명령이 이상적
작동 방식 — 시각적 워크플로 (ASCII 다이어그램, 표 또는 번호 단계)
기능 / 사용 사례 — 표 또는 글머리 기호 목록, 훑어보기 쉬움
내부 내용 / 구조 — 관련된 경우 파일 트리
설정 / 옵션 (선택 사항)
보안 (선택 사항)
기여 — 짧고 환영하는
라이선스 — 한 줄
CTA가 있는 바닥글 — 스타 + 팔로우 배지 반복

바닥글 템플릿

구성에서 동적으로 빌드:

---

<div align="center">

귀속 라인 — 사용 가능한 구성 필드에서 빌드:

작성자 + 회사 + 웹사이트: [NAME](GITHUB)님이 [COMPANY](COMPANY_URL)에서 만듦 | [WEBSITE](WEBSITE_URL)
작성자 + 회사 (웹사이트 없음): [NAME](GITHUB)님이 [COMPANY](COMPANY_URL)에서 만듦
작성자 + 웹사이트 (회사 없음): [NAME](GITHUB)님이 만듦 | [WEBSITE](WEBSITE_URL)
작성자만: [NAME](GITHUB)님이 만듦
아무것도 없음: github-optimization 스킬로 만듦

<br />

**이것이 유용하다면:**

[![이 저장소에 스타 부여](star-badge-url)](stargazers-url)

{X_HANDLE}이 존재하면 여기에 Follow 배지도 추가합니다.

</div>

작성 규칙

절대 타협하지 않습니다. 이것이 목소리를 정의합니다.

해야 할 것:

친구에게 설명하는 것처럼 씁니다. 짧은 문장. 능동태.
모든 섹션을 메커니즘이 아닌 가치로 시작합니다.
"당신"과 "여러분"을 사용합니다 — 독자에게 직접 말을 건넵니다.
추상적보다 구체적으로.
문단은 최대 2-3문장으로 유지합니다.
비교에는 표를 사용합니다.

하지 말아야 할 것:

AI 슬롭 사용: "레버리지", "간소화", "권한 부여", "매끄럽게", "견고한", "최첨단", "혁명", "힘을 활용하다", "워크플로 향상", "슈퍼차지"
문장을 "이 프로젝트는..." 또는 "이 도구는..."으로 시작
긴 텍스트 벽
수동태 사용
채우기 단어: "기본적으로", "본질적으로", "단순히", "그냥"
느낌표 사용

헤더의 SEO:

H1에는 기본 키워드가 포함되어야 함
H2에는 자연스럽게 보조 키워드가 포함되어야 함
인간을 위해 먼저 쓰되, 배치에 신중합니다.

5단계: 추가 사항

누락된 경우 추가:

LICENSE — 사용자가 달리 지정하지 않으면 MIT
CONTRIBUTING.md — 짧고 환영하며, 3단계 프로세스

묻지 않으면 추가하지 마세요: CODE_OF_CONDUCT.md, SECURITY.md, .github/ISSUE_TEMPLATE/

6단계: 게시

설명 메시지와 함께 모든 변경 사항 커밋
원격으로 푸시
gh repo edit을 통해 저장소 메타데이터 업데이트
사용자에게 보고: 변경된 내용, 새 설명, 추가된 토픽, 라이브 URL

완료 전 체크리스트

스타 성장 지식 베이스

사용자가 "스타를 더 많이 받으려면 어떻게 해야 하나요?", "출시 전략", "내 저장소 홍보" 등과 같이 물으면 이 지식 베이스를 사용하여 조언합니다. 이 섹션은 참고 자료이며 최적화 파이프라인의 일부가 아닙니다.

채널 순위 (ROI 기준)

순위	전술	노력	예상 스타	위험
1	스택 런치 (같은 날 HN + 레딧 + X + PH)	높음 (하루 준비)	200-2,000+	없음
2	Awesome 리스트 제출	낮음 (PR)	느리지만 누적됨	없음
3	README 최적화 + 소셜 프리뷰	중간 (1시간)	다른 모든 노력의 3배 승수	없음
4	GitHub SEO (이름, 토픽, 설명)	낮음 (30분)	수동적 장기 발견	없음
5	README의 데모 GIF/비디오	중간	전환율 대폭 향상	없음
6	자체 Awesome 리스트 생성	중간	느린 연소 + 교차 홍보	없음
7	뉴스레터 제출	낮음 (이메일)	기능당 50-500	없음
8	YouTube 튜토리얼	높음	최고의 지속적 장기 동인	없음
9	X에서 상호 리스트 글	낮음	네트워크 의존	없음
10	핵토버페스트 태깅 (10월)	낮음	50-200 계절적	스팸 PR
11	디스코드/커뮤니티 구축	높음 지속	유지/옹호	없음
12	컨퍼런스 발표	높음	직접 낮음, 복합 높음	없음

해커 뉴스 플레이북

최적 시간: 화요일-목요일, 오전 8-10시 태평양. 일요일 오후 6-9시 태평양 (경쟁 낮음).

제목 형식: Show HN: [이름] — [구체적으로 하는 일]

효과적인 방법: 마케터가 아닌 동료처럼 글을 씁니다. 전문 용어 없음. 문제로 시작합니다. 첫 시간 내 모든 댓글에 응답합니다. 게시 후 5분 이내에 자신의 실질적인 첫 댓글을 게시합니다.

임계값: 첫 30분 내 8-10개의 진짜 업보트 + 2-3개의 사려 깊은 댓글로 상위 10위권 진입.

계정 요구 사항: 최고 결과를 위해 250+ 카르마와 기술적 댓글 기록 필요. 신규 계정은 중재 대상이 됩니다.

링 감지는 공격적입니다. 절대 "내 HN 게시물에 업보트해 주세요"라고 트윗하지 마세요. 비공개 채널(이메일, Slack, Discord)을 사용하여 사람들에게 알립니다.

실제 결과:

Lago: 48시간 이상 1위, 1,000 스타의 주요 동인
Encore: 단일 Show HN으로 일주일 만에 1,500 스타
평균: 24시간 내 121 스타, 일주일 내 289 스타

레딧 플레이북

게시 2주 전에 카르마를 쌓으세요. 레딧의 90/10 규칙: 90% 진짜 활동, 10% 자기 홍보.

서브레딧	참고
r/SideProject (453K)	자기 홍보 명시적 허용
r/programming (6M+)	엄격한 반홍보, "X를 구축한 방법" 형식 작동
r/selfhosted (500K+)	매우 잘 전환됨
r/webdev	"Showoff Saturday" 전용
r/opensource	링크 친화적, 낮은 볼륨
r/coolgithubprojects	GitHub 저장소 전용

예상: 성공적인 게시당 50-300 스타. 서브레딧별로 메시지 맞춤 설정.

프로덕트 헌트 플레이북

투표 재설정: 매일 오전 12:01 PST. 처음 4시간 동안 업보트 숨겨짐.

1위 업보트: 평일 600-800, 주말 400-600.

최적 요일: 화요일-목요일.

예상: 오늘의 제품 상위 5위에서 200-1,000 스타. 1위는 500-2,000+ 제공 가능.

일정:

출시 4-6주 전: 200-500 이메일 구독자 확보
출시 1주 전: 모든 에셋 준비
출시일: 오전 12:01 PST에 라이브 전환, 모든 응답, 오전 6시 PST 이메일 폭발

트위터/X 플레이북

효과적인 방법: 짧은 데모 비디오/GIF가 텍스트보다 성과가 좋습니다. 지지자의 트윗이 자체 트윗보다 더 많은 스타를 유도합니다. 평일 아침 미국 시간(오전 9-11시 ET).

예상: 트윗으로 스타 증가 7%. 바이럴 비디오 트윗은 6시간 내 1,600 스타에 도달 가능.

스택 런치 전략

모든 빠르게 성장하는 저장소가 사용한 메타 전략:

시기	조치	예상 스타
일주일 전	뉴스레터 제출 (TLDR, Console.dev, Changelog)	--
출시일 오전	HN "Show HN" 게시 (화-수, 오전 8-11시 ET)	평균 121, 최대 1,500
출시일 오후	레딧 게시 (r/programming, r/selfhosted, 도메인 서브)	50-300
출시일	데모 비디오 트윗 + 지지자 공유 유도	50-500+
출시일	프로덕트 헌트 런치 (오전 12:01 PST)	200-1,000
2-4주 후	Awesome 리스트 제출	지속적 연소
지속적	YouTube 튜토리얼 + 블로그 게시물	복합 성장

Awesome 리스트 제출

핵심 Awesome 리스트 (높은 영향): awesome-go, awesome-python, awesome selfhosted, awesome-react 등.

전문 Awesome 리스트 (더 쉬운 진입): 각 도메인에 대한 특화 리스트.

전략: 저장소를 Awesome 리스트에 제출 가능하게 만듭니다(README 좋음, 라이선스, 기여 지침). 제출은 일반적으로 각 Awesome 리스트의 CONTRIBUTING.md를 따르는 PR을 통해 이루어집니다.

타임라인: 병합까지 1-4주. 일단 병합되면 지속적인 트래픽.

프롬프트 예시

사용자: "내 GitHub 최적화해 줘" AI: "현재 저장소는 무엇인가요? 저장소 URL 또는 소유자/이름을 알려주세요. 최적화 프로세스를 시작하겠습니다."

사용자: "스타를 더 많이 받으려면 어떻게 해야 하나요?" AI: "스타 성장 전략을 알려드리겠습니다. 먼저 저장소가 무엇인지 알려주세요. 지식 베이스에서 채널 순위를 보여드리겠습니다..."

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

미리보기

문서