onovich/RepoCover

RepoCover은(는) 무엇을 하나요?

저장소별 소셜 프리뷰를 생성하여 썸네일 크기에서도 가독성을 유지합니다. 일반적인 생성형 배너 대신 결정적이고 편집 가능한 구성을 선호합니다.

제품 불변 규칙

• 정확히 1280×640 래스터(일반적으로 PNG)를 1,000,000 바이트 미만으로 제공합니다.
• 편집 가능한 소스(일반적으로 SVG)를 래스터와 함께 유지합니다.
• 눈에 보이는 주장, 지표, 스크린샷, 증거를 저장소 증거에 기반합니다.
• 저장소의 정체성을 보존하며 일괄된 하우스 스타일을 강요하지 않습니다.
• 전체 크기와 320×160 크기에서 밝은 배경과 어두운 배경 모두에서 유효성을 검증합니다.
• 이미지 생성과 GitHub 업로드를 별도의 권한 경계로 취급합니다.
• GitHub 소속 또는 보증을 암시하지 않습니다.

올바른 참조 로드

모든 커버에 대해 다음 두 파일을 읽습니다:

• references/common-quality.md — 보편적인 구성 및 거부 조건.
• references/design-ledger-template.md — 증거, 디자인 및 검증 기록.

그런 다음 해당하는 경로만 읽습니다:

• 스크린샷, 런타임 캡처, 로고, 일러스트레이션, SVG, 스프라이트, 텍스처 또는 기타 의미 있는 시각 자료가 있는 경우 references/source-material.md를 읽습니다.
• 사용 가능한 스크린샷, 런타임 캡처, 브랜드 마크 또는 저장소 소유의 주요 시각 자료가 없는 경우 references/cold-start.md를 읽습니다.
• 기존 커버를 새로 고치거나, 후보를 비교하거나, 버전별 배치를 생성하는 경우 references/version-regression.md를 읽습니다.

관련 없는 경로를 단순히 존재한다고 로드하지 마십시오. references/design-recipes.md는 이전 프롬프트와의 호환성 인덱스입니다.

워크플로우

1. 증거 검사 및 범위 설정

해당 AGENTS.md 파일, README, 패키지 메타데이터, 의미 있는 소스 경로, 시각 에셋 및 기존 소셜 프리뷰를 읽습니다. 다음을 식별합니다:

• 저장소 이름 및 주요 사용자 작업;
• 하나의 구체적인 가치 명제;
• 최대 3개의 증거 포인트;
• 가장 강력한 제품 증거;
• 확립된 시각적 정체성 및 제외할 보조 사실;
• 증거 모드: remote-static, local-static, build-tested 또는 runtime-tested.

정적 증거만 검사했는데 빌드, 런타임, 장면 또는 테스트가 실행되었다고 암시하지 마십시오. GitHub의 이미지 요구 사항이 변경되었을 수 있으면 공식 GitHub 문서와 대조하여 확인합니다.

원격 저장소의 경우, 사용 가능한 공개 또는 인증된 GitHub 증거를 사용하여 README, 트리, 매니페스트, 의미 있는 소스 파일, 현재 프리뷰 및 가장 강력한 시각 에셋을 검사합니다. 출력물을 내구성 있는 사용자 대상 디렉토리에 보관하고 소스 URL과 주장 범위를 기록합니다. 런타임 또는 대표적인 인터페이스에 도달할 수 없으면 해당 제한을 명시하고, 원격 증거가 작동하는 로컬 프리뷰와 동등한 것처럼 가장하지 마십시오. 미리보기 가능한 로컬 프로젝트, 특히 기존 인터페이스가 있는 웹 프로젝트는 일반적으로 가장 풍부한 시각 증거를 제공합니다.

2. 설계 원장 작성 및 경로 선택

그리기 전에 포함된 템플릿에서 설계 원장을 생성합니다. 최소한 다음을 기록합니다:

• 약속, 증거, 제외;
• 증거 모드 및 주장 범위;
• 소스 자료 진단 또는 콜드 스타트 의미 스켈레톤;
• 선택한 제작 및 해석 경로;
• 재료, 에셋 역할, 토폴로지 및 라인 결정;
• 해당하는 경우 출력 버전, 검증 및 승격 판정.

정체성을 보존하는 가장 작은 제작 경로를 선택합니다:

• 코드 네이티브 SVG — 선호: 개발자 도구, 다이어그램, 차트, 로고, 라이브러리 및 추론된 시각 시스템.
• 스크린샷 또는 소스 하이브리드: 진단 후 독립형 소스 아티팩트가 가장 명확한 증거로 남는 경우에만.
• 일러스트레이션 하이브리드: 일러스트레이션이 저장소 정체성의 핵심인 경우에만; 중요한 텍스트 없이 아트워크를 생성하고 SVG에 정확한 문구를 오버레이합니다.

확립된 벡터 시스템을 모방하기 위해 이미지 생성을 호출하지 마십시오.

3. 편집 가능한 소스 구축 및 버전 관리

저장소에 명확한 에셋 규칙이 있거나 사용자가 다른 대상을 지정하지 않는 한 기본적으로 docs/social-preview.svg 및 docs/social-preview.png를 사용합니다.

• 1280 640 viewBox와 전체 캔버스 배경을 사용합니다.
• 필수 콘텐츠를 대략 72px 외부 안전 영역 내에 유지합니다.
• 텍스트, 제품 증거, 캡션 및 서명을 겹치지 않는 영역으로 분할합니다.
• 저장소가 적절한 라이선스 글꼴을 제공하지 않는 한 시스템 글꼴을 사용합니다.
• 로컬 증거를 포함하거나 결정적 SVG 프리미티브로 재현합니다; 외부 런타임 종속성을 피합니다.
• 차트, 스크린샷, 반복 마크 및 파형을 해당 영역으로 클리핑합니다.
• 명시적으로 교체 요청이 없는 한 기존 커버를 보존하고 버전별 형제를 생성합니다.

4. 기계적 렌더링 및 검증

Sharp를 사용할 수 있을 때 번들 스크립트로 렌더링합니다:

node <skill-directory>/scripts/render_svg.mjs <source.svg> <output.png>

명명된 출력을 교체하는 것이 범위에 있는 경우에만 --force를 사용합니다. Codex Desktop에서는 작업 공간 종속성을 로드하고 반환된 Node 실행 파일과 패키지 경로를 NODE_PATH를 통해 사용합니다; 허가 없이 종속성을 설치하지 마십시오.

PNG 및 SVG 검증:

python <skill-directory>/scripts/validate_preview.py <output.png> --svg <source.svg>

표준 썸네일 시트 생성:

node <skill-directory>/scripts/create_review_sheet.mjs <preview.png> <review.png>

Windows 레거시 코드 페이지에서 UTF-8 소스를 읽는 도구를 위해 PYTHONUTF8=1을 설정합니다.

5. 시각적 검증

래스터를 전체 크기로 검사하고 생성된 리뷰 시트를 검사합니다. 다음을 확인합니다:

• 저장소 이름과 가치 명제가 320×160에서 읽을 수 있어야 함;
• 제품 증거가 인식 가능하고 기술적으로 충실해야 함;
• 텍스트, 마크, 크롭, 패널 및 장식 요소가 충돌하거나 잘리지 않아야 함;
• 밝은 배경과 어두운 배경 모두에서 구성이 작동해야 함;
• 모든 눈에 보이는 요소가 약속 또는 증거에 매핑되어야 함;
• 디자인이 모든 해당 경로별 거부 조건을 통과해야 함.

왼쪽에서 오른쪽, 위에서 아래로 스캔하고, 한 번에 하나의 명명된 결함을 수정하고, 다시 렌더링하고, 검증을 다시 실행합니다. 알려진 결함을 넘기지 마십시오.

배치의 경우 접촉 시트를 만들고 후보를 승격하기 전에 우발적인 공유 템플릿 드리프트가 없는지 검사합니다.

6. 요청 시에만 업로드

에셋을 생성한다고 GitHub 설정을 변경할 권한이 생기지 않습니다. 업로드가 명시적으로 요청된 경우 다음을 엽니다:

https://github.com/<owner>/<repo>/settings

**소셜 프리뷰 → 편집 → 이미지 업로드…**를 사용하고 활성 UI 확인 정책을 따릅니다. 업로드 후 공개 저장소 페이지를 가져와서 og:image가 새 1280×640 이미지로 확인되는지 확인합니다. 설정 썸네일만으로 성공을 보고하지 마십시오.

인계

최종 이미지를 표시하고 다음을 보고합니다:

• 편집 가능한 소스 경로;
• 래스터 경로, 형식, 크기 및 바이트 수;
• 한 문장의 디자인 근거;
• 검증 및 버전 승격 상태;
• 업로드 상태: 요청되지 않음, 보류 중 또는 공개적으로 확인됨.

프로젝트 출력물을 임시 또는 모델 소유 디렉토리에만 남기지 마십시오.