Qiaomu GitHub Publisher
작업 중인 프로젝트를 사람들이 이해하고, 시도하고, 스타를 누르고, 설치하고, 신뢰할 수 있는 GitHub 저장소로 만듭니다.
Copyright (c) 向阳乔木
- X: https://x.com/vista8
- GitHub: https://github.com/joeseesun/
- 프로필 소스:
~/.agents/skills/qiaomu-profile
핵심 워크플로우
- 작성 전에 저장소 검사:
README.md,package.json/ 프로젝트 메타데이터, 스크린샷, 예제, 문서, 라이선스, 배포 스크립트, 테스트 스크립트.- GitHub 및 커뮤니티 표면: About 설명, 홈페이지, 주제, 소셜 프리뷰, 라이선스,
SECURITY.md,CONTRIBUTING.md,CODE_OF_CONDUCT.md, 이슈 템플릿, PR 템플릿, 릴리스/변경 로그(있는 경우). gh repo view --json name,description,homepageUrl,repositoryTopics,url,defaultBranchRef,isPrivate,licenseInfo를 통한 GitHub 원격 상태.
- 공개 포지셔닝 결정:
- 중국어와 영어로 된 한 줄짜리 훅, 중국어 버전이 먼저 와야 합니다.
- 대상 사용자와 그들이 지금 시도해야 하는 이유.
- 제품 가치, 기술 아키텍처, 개인/로컬 설정 간의 명확한 경계.
- 의도된 릴리스 자세: 전용 공개, 사용자 설치 가능 도구, 외부 기여자 프로젝트, 라이브러리/패키지, 또는 배포된 제품.
- README를 제품 페이지로 다시 작성 또는 패치:
README.md는 GitHub의 정문입니다. Qiaomu 소유 저장소의 경우 기본적으로 중국어 우선 및 이중 언어여야 합니다.- 중국어를 먼저 쓰고 그 다음 영어를 쓰세요. 사용자가 명시적으로 영어 전용을 요청하거나 저장소에 문서화된 비 Qiaomu 상류 요구 사항이 없는 한 이렇게 하세요.
- 별도의
README.zh-CN.md는 허용되지만 이 자체로는 요구 사항을 충족하지 않습니다. 기본README.md는 중국어를 먼저 표시해야 합니다. - 영어는
# English로 고정된 전체 하위 섹션, 연결된README.en.md, 또는 간결한 미러링된 섹션일 수 있지만 설치/시도, 검증, 제한 사항 및 라이선스/액세스 기대 사항은 영어 사용자가 이해할 수 있어야 합니다. - 스캔 친화적인 구성을 만드세요: 언어 전환, 실제 히어로 미디어, 짧은 스토리 훅, 증명 스트립, 간결한 배지, "무엇을/왜", 기능 매트릭스, 가장 빠른 빠른 시작, 확장 가능한 수동 설정, 사용법, 제품 둘러보기, 호환성/생태계 카탈로그, 워크플로우/아키텍처, 검증, 제한 사항 및 신뢰 링크.
- 가능하면 실제 스크린샷이나 출력 샘플을 사용하고 스크린샷을 만들어내지 마세요.
- GitHub About 설정:
- Qiaomu 소유 공개 저장소의 경우 기본적으로 간결한 이중 언어 설명을 사용하며 중국어가 먼저이고 영어가 그 다음입니다.
- 라이브 데모가 있을 때 홈페이지 URL을 추가하세요.
- 집중된 주제를 추가하고 주제 스팸을 피하세요.
- 공개 출시 다듬기를 위해 소셜 프리뷰 이미지를 만들거나 요청하세요. 자동화할 수 없으면 설정된 척하지 않고 후속 조치로 수동 GitHub 설정 단계를 기록하세요.
- 릴리스 자세에 따라 신뢰 표면 개선:
- 오픈 소스 저장소의 라이선스 상태를 항상 확인하세요.
- 외부 기여자 프로젝트의 경우 누락되었거나 오래된 경우
CONTRIBUTING.md,CODE_OF_CONDUCT.md,SECURITY.md, 이슈 템플릿 및 PR 템플릿을 추가하거나 업데이트하세요. - 전용 공개 저장소의 경우 기여/커뮤니티 파일이 의도적으로 생략된 경우 설명하세요.
- README가 약속하는 내용 확인:
- 관련이 있을 때 프로젝트 제공 린트/빌드/테스트 명령을 실행하세요.
- 스킬의 경우
npx skills add검색 가능성/설치 가능성을 확인하세요. - 웹사이트의 경우 해당되는 경우 배포 후 라이브 URL/API/상태를 확인하세요.
- 깔끔한 GitHub 흐름을 통해 게시:
- 기능 브랜치와 PR을 사용하세요.
main에 직접 푸시하지 마세요.- 검증이 통과되고 사용자가 명시적으로 보류를 요청하지 않은 경우 PR을
main에 병합하세요. - 최종 응답에 PR URL과 병합 커밋을 포함하세요.
소스 기반 프레젠테이션 모델
이 스킬은 GitHub 자체의 저장소 프레젠테이션 표면에 기반을 두고 있습니다:
- README: GitHub는 저장소 README가 프로젝트의 기능, 유용성, 시작 방법, 도움말 위치, 유지 관리자를 설명해야 한다고 말합니다. GitHub는 방문자에게 인식된 README를 자동으로 표시합니다.
- 주제: GitHub 주제는 사람들이 목적, 주제 영역, 커뮤니티, 언어 또는 기타 중요한 특성으로 저장소를 발견하는 데 도움이 됩니다.
- 라이선스: GitHub의 라이선스 지침에 따르면 공개 저장소는 다른 사람이 명확하게 자유롭게 사용, 변경 및 배포할 수 있기 전에 오픈 소스 라이선스가 필요합니다.
- 커뮤니티 프로필: GitHub의 공개 저장소 체크리스트는 README, 라이선스, 행동 강령, 기여 가이드, 보안 정책 및 이슈/PR 템플릿을 찾습니다.
- 보안 정책:
SECURITY.md는 취약점을 보고하는 방법을 알려줍니다. - 이슈 및 PR 템플릿: 템플릿은 기여자가 이슈를 열거나 풀 리퀘스트를 제출할 때 제공하는 정보를 표준화합니다.
- 소셜 프리뷰: GitHub는 저장소 관리자가 저장소 설정에서 소셜 프리뷰 이미지를 설정할 수 있도록 합니다. 투명도가 예측할 수 없게 렌더링될 수 있는 경우 단색 배경을 사용하세요.
이 지침이 블로그 체크리스트와 충돌할 때는 공식 문서를 먼저 사용하세요.
맹목적으로 복사하지 말고 배울 참고 사례: santifer/career-ops는 README를 간결한 런칭 페이지로 제시합니다. 언어 접근, 실제 히어로 이미지, 3줄 기원 이야기, 획득한 외부 증거, 데모, 정량화된 결과, 집중된 배지를 먼저 보여준 다음, 그것이 무엇인지, 기능, 빠른 시작, 사용법, 워크플로우, 구조, 스택, 면책 조항 및 연락처로 이동합니다. Qiaomu 저장소에 적합할 때 그 순서 논리를 재사용하되 언론, 커뮤니티, 다운로드, 스타, 사용자 성공 또는 사용량 주장을 절대 만들어내지 마세요.
복잡한 제품에 대한 참고 사례: nexu-io/open-design는 README를 대규모 생태계를 위한 제품 맵으로 취급합니다. 릴리스/CTA 공지, 강력한 제품 둘러보기 섹션, 그룹화된 데모 갤러리, 플랫폼 호환성 테이블, 다중 경로 빠른 시작, 에이전트/MCP 사용법, 스킬/디자인 시스템/플러그인 카탈로그, 아키텍처 및 보안 노트, 로드맵, 커뮤니티/기여 테이블, 관리자, 저장소 활동 및 계통/출처를 사용합니다. 많은 표면을 가진 Qiaomu 저장소를 위한 모듈식 체크리스트로 이것을 재사용하되 현재 저장소에서 확인되지 않는 한 규모 숫자, 지원 매트릭스, 유료 서비스 주장, 커뮤니티 주장, 보안 보장 또는 타사 계통을 절대 복사하지 마세요.
README 표준
언어 게이트
Qiaomu 소유 공개 저장소의 경우 README.md는 릴리스 전에 중국어 우선 이중 언어여야 합니다:
- 첫 번째 뷰포트: 프로젝트 이름, 중국어 가치 제안, 영어 가치 제안, 배지/링크 및
**中文** | [English](#english)와 같은 눈에 띄는 언어 전환. - 본문: 기본 독자 경험으로 작성된 중국어 섹션이 먼저 옵니다.
- 영어 접근: 실질적인 영어 섹션 또는 연결된 영어 README를 제공하세요. 최소한 영어 사용자는 그것이 무엇을 하는지, 시도/설치하는 방법, 확인된 사항 및 주요 제한 사항/전제 조건을 이해할 수 있어야 합니다.
README.zh-CN.md및README.en.md와 같은 번역 파일이 존재할 수 있지만 GitHub 기본README.md는 사용자가 명시적으로 다른 대상을 승인하지 않는 한 여전히 중국어를 먼저 열어야 합니다.README.md가 영어 전용, 영어 우선이거나 중국어 경험을 위해 별도의 중국어 파일에 의존하는 경우 릴리스 PR을 열거나 병합하기 전에 중지하고 수정하세요.
첫 번째 뷰포트 게이트
README.md의 상단은 60초 낯선 사람 테스트를 통과해야 합니다:
- 이것은 하나의 구체적인 문장으로 무엇입니까?
- 누구를 위한 것이며 어떤 고통을 제거합니까?
- 즉시 클릭, 설치 또는 시도할 수 있는 것은 무엇입니까?
- 어떤 증거를 볼 수 있습니까: 스크린샷, 데모, 샘플 출력, CI 배지 또는 확인된 명령?
- 무엇을 신뢰해야 합니까: 라이선스, 관리자, 보안/개인 정보 경계 및 마지막 확인 상태?
배지 벽, 추상적인 태그라인 및 아키텍처 우선 오프닝을 피하세요. 아키텍처는 사용자가 제품 가치를 이해한 후에 옵니다.
공개 README는 다섯 가지 질문에 빠르게 답해야 합니다:
- 이것은 어떤 고통을 해결합니까?
- 설치/실행 후 무엇을 얻습니까?
- 스크린샷, 데모 또는 예제 출력에서 증거를 볼 수 있습니까?
- 5분 안에 어떻게 시도합니까?
- 제한 사항, 비용 또는 전제 조건은 무엇입니까?
구성 게이트
제품 페이지이자 기술 문서로 작동하는 README 레이아웃을 사용하세요:
- 내부보다 결과와 증거로 시작: 프로젝트 이름, 언어 전환, 실제 제품 미디어, 하나 또는 두 개의 구체적인 가치 라인, 기본 작업 링크 및 하나의 신뢰할 수 있는 증거 라인.
- 증거를 구체적이고 확인 가능하게 만드세요: 라이브 데모, 설치 명령, 패키지/릴리스 배지, CI 결과, 스크린샷, 샘플 출력, 벤치마크, 사례 연구, 사용자 결과, 언급 또는 스타 차트. 확인되거나 획득되지 않은 경우 생략하세요.
- 4개 이상의 기능이 있을 때 기능 테이블을 사용하세요. 각 행은 명명된 기능을 사용자에게 보이는 결과에 매핑해야 하며, 단순히 모듈을 나열하지 않아야 합니다.
- 수동 설정보다 가장 빠른 성공 경로를 먼저 배치하세요. 하나의 명령 또는 가장 짧은 입증된 경로를 먼저 사용한 다음, 페이지를 압도할 경우
<details>에 더 긴 수동 설정을 숨기세요. - 빠른 시작 후 사용법 명령, 워크플로우/작동 방식, 프로젝트 구조 및 기술 스택을 추가하세요. 이 섹션은 진지한 사용자가 첫 번째 시도를 지연시키지 않고 시스템을 검사하는 데 도움이 되어야 합니다.
- 개인 정보, 데이터 소유권, 비용, 타사 약관, "호스팅 서비스 아님" 및 "X를 하지 않음" 경계를 관련성이 있을 때 눈에 띄는 제한 사항/면책 조항 섹션에 배치하세요.
- 시각적 자산을 목적에 맞게 유지하세요. 히어로 이미지, 데모 GIF, 로고, 배지 및 차트는 제품 또는 상태를 증명해야 하며 장식이나 차용된 권위가 되어서는 안 됩니다.
복잡한 제품 카탈로그 게이트
저장소가 단일 앱/라이브러리보다 더 클 때 사용: 다중 플랫폼 앱, 에이전트 생태계, 플러그인/템플릿 카탈로그, 디자인 시스템, 미디어 파이프라인, MCP 서버, 자체 호스팅 스택 또는 상당한 커뮤니티/기여 표면이 있는 프로젝트.
- 깊은 내부 전에 제품 둘러보기를 추가하세요. 사용자 표면 또는 아티팩트 유형별로 스크린샷/데모를 그룹화하고 각 항목에 한 줄 결과를 제공하세요: 진입 앱, 스튜디오/편집기, 대시보드, 플러그인 마켓플레이스, 생성된 출력, API, CLI, MCP, 모바일/데스크톱 보기 등.
- 제품이 플랫폼, 에이전트, 제공자, 운영 체제, 배포 모드 또는 패키지 관리자에서 실행될 때 호환성 매트릭스를 추가하세요. 열은 구체적이어야 합니다: 대상, 상태, 설치 명령, 확인 명령 및 알려진 제한 사항.
- 스킬, 플러그인, 템플릿, 디자인 시스템, 제공자, 예제 또는 통합에 대한 생태계 카탈로그를 추가하세요. 저장소에서 생성되거나 새로 확인된 경우에만 카운트를 사용하고 그렇지 않으면 "many"라고 말하거나 디렉토리에 연결하세요. 좋은 열: 항목, 카테고리/모드, 대상, 출력, 소스 경로.
- 페르소나/경로별 빠른 시작 제공: 데스크톱 또는 호스팅 앱, CLI/에이전트 전용, Docker/자체 호스팅, 소스 개발자 경로. 권장 경로를 먼저 배치하고 각 경로에 성공 확인을 제공하세요.
- 저장소에 데몬, MCP 서버, 프록시, 로컬 데이터베이스, 자격 증명, 생성된 아티팩트 또는 네트워크 경계가 있을 때 아키텍처와 보안을 함께 표시하세요. 간결한 다이어그램/테이블을 선호하고 권위 있는 심층 문서에 연결하며 드리프트하기 쉬운 저장소 또는 비밀 처리 세부 정보를 복제하지 마세요.
- 저장소가 외부 작업을 초대하거나 타사 자산을 번들할 때 로드맵, 커뮤니티, 기여, 관리자 및 출처 섹션을 포함하세요. 출처는 상류 프로젝트, 라이선스 경계 및 적응되거나 번들된 것을 명명해야 합니다.
- 카탈로그 밀도를 제어하세요: 스캔을 위해 테이블을 사용하고 긴 목록을 위해
<details>를 사용하며 철저한 목록을 위해 심층 문서를 사용하세요. README는 신규 이민자를 안내해야 하며 전체 매뉴얼이 되어서는 안 됩니다.
권장 구조:
# 프로젝트 이름
**中文** | [English](#english)
> 중국어 가치 제안
> 영어 가치 제안
[라이브 데모] [설치] [문서] [라이선스] [CI]
**확인됨:** `npm test` / `npx skills add ...` / 라이브 상태 확인 / 샘플 출력
## 이것은 무엇입니까
## 왜 가치가 있습니까
## 핵심 기능
| 기능 | 사용자가 얻는 것 |
|---|---|
| ... | ... |
## 샘플 출력
## 빠른 시작
### 가장 빠른 경로
```bash
...
...
사용 방법
제품 둘러보기 / 데모
플랫폼 호환성 / 생태계 카탈로그
워크플로우 / 원리
아키텍처 및 보안 모델
프로젝트 구조
배포 / API / 스킬
로드맵 / 커뮤니티 / 기여
출처 계통 / 라이선스 경계
실측 검증
제한 사항, 개인 정보 및 경계
문제 해결
向阳乔木 소개
English section
### 증거 및 미디어
- 상단 근처에 하나의 실제 스크린샷, 데모 GIF, 터미널 기록, API 응답, 생성된 아티팩트 또는 호스팅된 데모를 선호하세요.
- 모든 스크린샷 또는 샘플은 현재 확인된 상태와 일치해야 합니다. 디자인 목업으로 명확하게 표시되지 않는 한 모의 이미지를 사용하지 마세요.
- 정량화된 주장은 최신이고 출처가 있어야 합니다: 예는 처리된 항목 수, 생성된 아티팩트, 설치된 버전, 호환성 대상, 카탈로그 카운트, 벤치마크 결과 또는 게시된 사례 연구를 포함합니다. 저장소가 코드, 생성된 메타데이터, 테스트, 릴리스 아티팩트 또는 문서에서 숫자를 증명할 수 없으면 확인된 명령/출력을 대신 사용하세요.
- CLI/도구의 경우 짧은 성공적인 명령 기록과 실패/문제 해결 예제를 포함하세요.
- 웹사이트/앱의 경우 가능할 때 라이브 URL, 배포 대상, 상태/API 확인 및 데스크톱/모바일 스크린샷을 포함하세요.
- README를 GitHub의 500 KiB 렌더링 잘림 제한보다 편안하게 낮게 유지하고 문서가 커지면 더 깊은 자료를 `docs/`로 분할하고 링크하세요.
## GitHub 표면 표준
### GitHub About 표준
Qiaomu 소유 공개 저장소의 경우 기본적으로 간결한 이중 언어 형식을 사용하세요:
```text
중국어 짧은 설명 | English short description.
구체적으로 유지하세요. 좋은 예:
把 App Store 评价变成产品研究证据，发现痛点、机会和版本风险 | Turn App Store reviews into product research evidence: pain points, opportunities, and version risks.把任意资料整理成 NotebookLM 可用知识包 | Turn messy sources into NotebookLM-ready knowledge packs.
주제는 좁고 유용해야 합니다:
- 도메인:
app-store,app-reviews,notebooklm,geo - 스택:
nextjs,agent-skill,deepseek - 대상/워크플로우:
product-management,ai-workflow
검색 가능성을 추가하지 않는 한 tool, website, ai와 같은 일반적인 주제는 피하세요.
홈페이지, 배지 및 소셜 프리뷰
- 홈페이지를 라이브 데모, 문서, 설치 페이지 또는 제품 홈으로 설정하세요. 없으면 관련 없는 페이지를 가리키는 대신 비워 두세요.
- 작은 배지 행 사용: CI/빌드, 라이선스, 패키지 ...
…
[번역을 위해 잘림]