lggarrison/agent-skills

리포지토리 설정

새 리포지토리는 매번 동일한 기본 구성이 필요합니다: 라이선스, 보안 문제를 보고할 방법, README, PR과 이슈를 유용하게 만드는 템플릿, 그리고 기여자가 로컬에서 실행하는 것과 동일한 검사를 수행하는 CI가 필요합니다. 이 스킬은 이러한 기본 구성을 위한 체크리스트이자 작업을 진행하는 방법입니다.

먼저 리포지토리 규칙을 확인하세요

무엇을 추가하기 전에 리포지토리에 이미 무엇이 있는지 확인하세요: AGENTS.md / CLAUDE.md, CONTRIBUTING.md, 기존 .github/ 파일, 패키지 매니페스트와 그 스크립트, 모든 CI 설정 파일. 기존 파일이 특정 규칙(기본 브랜치, 라이선스, 도구, 파일 위치 등)을 설정한 경우, 그 규칙을 따르세요. 여기에 있는 템플릿과 일치시키기 위해 기존 파일을 덮어쓰지 마세요. 확장하거나 그대로 두고 갭을 언급하세요.

워크플로우

1. 요구사항 파악

• 부트스트래핑: 새 리포지토리거나 거의 비어 있는 리포지토리. 전체 체크리스트를 작업합니다.
• 갭 채우기: 기존 리포지토리에 일부 파일이 누락된 경우. 누락된 것만 추가합니다.
• 감사: 누락되거나 부족한 점을 보고하고, 아무것도 변경하지 않습니다.

2. 인벤토리 작성

체크리스트 파일 중 어떤 것이 존재하는지 나열하고, 매니페스트 (package.json, pyproject.toml, go.mod, Cargo.toml 등)를 읽어 언어, 스크립트, 프로젝트가 퍼블리시되는지 확인합니다. git remote show origin 또는 gh repo view --json defaultBranchRef로 기본 브랜치를 찾으세요. 이 방법으로 알 수 있는 내용은 사용자에게 묻지 마세요.

3. 판단이 필요한 질문을 하세요

이것은 사용자의 결정 사항입니다. 한 번에 짧은 라운드로 질문하고, 증거가 뒷받침되는 경우 추천하세요:

• 라이선스 및 저작권 보유자 이름.
• 보안 연락처: GitHub 비공개 취약점 보고, 이메일 주소, 또는 둘 다.
• 행동 강령 연락처 (추가하는 경우).
• PR 기본 브랜치 (기본 브랜치가 아닌 경우).
• 퍼블리시 여부: 패키지 레지스트리 또는 릴리스 아티팩트로.
• CI 매트릭스: 지원할 운영 체제 및 런타임 버전.

4. 파일 작성

체크리스트를 위에서 아래로 작업하고, 해당되지 않는 섹션은 건너뛰세요.

• 정식 텍스트를 가져오세요; 기억에서 작성하지 마세요. gh api licenses/<spdx-id> --jq .body(mit 또는 apache-2.0 등)로 라이선스 텍스트를 가져온 후, 연도와 보유자를 채우세요. 행동 강령은 기여자 서약(Contributor Covenant)과 같은 공식 출처에서 가져오세요.
• 템플릿을 적용하세요. templates/에서 시작하세요. 모든 <placeholder>를 교체하고, 명령어를 이 리포지토리에 존재하는 것으로 변경하세요. 없는 스크립트를 나열하는 템플릿은 템플릿이 없는 것보다 나쁩니다.
• 검사 목록을 하나로 통일하세요. PR 템플릿 체크리스트, CONTRIBUTING.md, 프리커밋 훅, CI는 모두 동일한 명령어를 나열해야 합니다. 하나가 변경되면 다른 것들도 변경하세요.
• 설정 변경 전에 물어보세요. 브랜치 보호, 규칙 세트, 비공개 취약점 보고는 리포지토리 설정이지 파일이 아닙니다. 사용자가 동의한 후에만 제안하고 적용하세요.

5. 확인

• 템플릿, 훅, 또는 CI 작업에 명명된 모든 명령어가 로컬에서 실행되고 통과합니다.
• 모든 파일에 <placeholder>가 남아 있지 않습니다.
• 이슈 양식과 워크플로우가 유효한 YAML입니다. 이슈 양식은 기본 브랜치에만 나타나므로, 병합 후 해당 브랜치에서 확인하세요.
• 링크가 정상적으로 연결됩니다 (보안 정책 URL 포함).
• 리포지토리 자체의 포맷 및 린트 검사가 새 파일에서 통과합니다.

6. 보고

추가한 내용, 건드리지 않은 이유, 제안한 리포지토리 설정, 그리고 아직 해결되지 않은 판단 사항을 말하세요.

체크리스트

R은 필수, rec은 권장, opt는 선택 사항입니다.

도구

• R git, 언어 런타임 및 패키지 매니저.
• rec 고정된 버전 파일과 일치하는 런타임 버전 매니저 (nvm, fnm, pyenv 등).
• rec 유지보수자를 위한 gh (gh auth login으로 인증).

법률 및 커뮤니티

• R LICENSE.
• R SECURITY.md: 지원되는 버전, 비공개 보고 방법, 보고 후 기대할 수 있는 사항.
• rec CONTRIBUTING.md: 설정, 실행할 검사, 브랜치 및 커밋 규칙, PR 검토 방법.
• rec CODE_OF_CONDUCT.md (실제 제재 연락처 포함).
• rec CHANGELOG.md를 Keep a Changelog 형식으로.

문서

• R README.md: 무엇인지, 설치 방법, 최소 사용 예제, CONTRIBUTING.md, SECURITY.md, 라이선스 링크.
• opt AGENTS.md: 코딩 에이전트를 위한 벤더 중립적 진입점. 실행할 명령어와 따라야 할 규칙을 제공하고, 다른 문서를 반복하지 말고 링크하세요.
• opt 퍼블리시된 프로젝트를 위한 RELEASING.md. 퍼블리싱 참조.

에디터 및 Git 위생

• R 언어, 빌드 출력, 로컬 환경 파일에 대한 .gitignore.
• rec * text=auto eol=lf가 있는 .gitattributes (운영 체제 간 줄 끝 변경 방지).
• rec 문자셋, 마지막 개행, 들여쓰기를 위한 .editorconfig.

GitHub 템플릿 및 자동화

리포지토리가 GitHub에 없으면 호스트의 동등한 기능을 사용하세요.

• rec .github/PULL_REQUEST_TEMPLATE.md. 템플릿 참조.
• rec .github/ISSUE_TEMPLATE/의 이슈 양식: bug_report.yml, feature_request.yml, 빈 이슈를 비활성화하고 보안 보고서를 비공개 채널로 안내하는 config.yml. 템플릿 참조.
• rec .github/dependabot.yml, 리포지토리가 사용하는 각 패키지 생태계에 대한 항목과 github-actions에 대한 항목 포함.
• R .github/workflows/ci.yml, 모든 PR과 기본 브랜치로의 푸시마다 PR 템플릿과 동일한 검사를 실행합니다.
• opt .github/release.yml, 레이블별로 생성된 릴리스 노트를 그룹화합니다.
• opt 퍼블리시된 프로젝트에만 해당하는 .github/workflows/release.yml.
• rec CI를 요구하는 기본 브랜치에 대한 브랜치 보호 또는 규칙 세트. 설정이므로 먼저 물어보세요.

Node.js 및 TypeScript

다른 언어의 경우 이 섹션을 건너뛰고, 해당 생태계의 도구(고정된 런타임 버전, 포맷터, 린터, 테스트 러너, 단일 "모두 확인" 명령어, CI 매트릭스)로 동일한 아이디어를 적용하세요.

런타임 및 메타데이터

• rec .nvmrc와 package.json의 engines.node가 서로 일치해야 합니다.
• R package.json의 repository, homepage, bugs, license, author.
• rec 네이티브 ESM을 위한 "type": "module".

TypeScript (TypeScript 프로젝트만 해당)

• R typescript와 tsconfig.json, 컴파일하는 npm run build 포함.
• JavaScript 프로젝트를 TypeScript로 변환하지 마세요. 새 프로젝트의 경우 TypeScript 사용 여부는 사용자의 결정입니다.

포맷 및 린트

• rec Prettier (.prettierrc.json, .prettierignore)와 ESLint 플랫 설정.
• rec 스크립트 lint, lint:fix, format, format:check.

단위 테스트

• R 단위 테스트를 실행하는 npm test.
• rec Vitest. 테스트는 코드 옆 (src/**/*.test.ts)에 두고, 공유 픽스처는 test/에 둡니다.

종단간(E2E) 테스트 (선택 사항, UI 또는 브라우저 플로우가 있는 프로젝트용)

• rec @playwright/test, playwright.config.ts, e2e/의 테스트.
• rec npm run test:e2e 스크립트.
• rec .gitignore에 playwright-report/, test-results/, blob-report/ 추가.
• rec npx playwright install --with-deps로 브라우저를 설치하고 테스트 실패 시 보고서를 업로드하는 CI 작업.
• opt 브라우저가 없는 CLI의 경우, 대신 별도의 Vitest 설정을 통해 종단간 테스트를 실행하세요.

Git 훅 (로컬 개발 전용)

• rec lint-staged를 실행하는 pre-commit 훅이 있는 Husky.
• rec CI가 설정되었거나 NODE_ENV=production일 때 Husky 설치를 건너뛰는 prepare 스크립트 (CI 및 프로덕션 설치가 실패하지 않도록).
• opt 단위 테스트를 실행하는 pre-push 훅.

품질 게이트

• rec 하나의 스크립트 (예: check)로 린트, format:check, 단위 테스트, 빌드, 종단간 테스트를 순서대로 실행합니다. CI와 기여자 모두 이 스크립트를 실행합니다.
• rec 지원되는 운영 체제 및 Node.js 버전에 대한 CI 매트릭스.

퍼블리싱

패키지 레지스트리에 릴리스되는 프로젝트용. 다른 모든 경우에는 선택 사항입니다.

• rec package.json의 "files" 허용 목록 (또는 .npmignore), npm pack --dry-run으로 확인.
• rec 빌드를 실행하는 prepublishOnly 스크립트.
• rec npm 신뢰 퍼블리싱(OIDC, id-token: write)을 사용한 CI에서의 퍼블리싱 (장기 토큰이 시크릿으로 저장되지 않도록).
• rec RELEASING.md에서 버전 선택 방법(semver), 릴리스 태그 지정 방법, 잘못된 태그를 차단하는 검사, 롤백 방법 설명.

템플릿

파일	복사 위치
templates/PULL_REQUEST_TEMPLATE.md	.github/PULL_REQUEST_TEMPLATE.md
templates/ISSUE_TEMPLATE/bug_report.yml	.github/ISSUE_TEMPLATE/bug_report.yml
templates/ISSUE_TEMPLATE/feature_request.yml	.github/ISSUE_TEMPLATE/feature_request.yml
templates/ISSUE_TEMPLATE/config.yml	.github/ISSUE_TEMPLATE/config.yml

플레이스홀더는 <like-this>로 작성됩니다. 예를 들어, <runtime-version-command>를 node --version, python --version, 또는 go version으로 교체하세요. 템플릿의 다른 명령어는 Node.js 프로젝트의 예시입니다. 리포지토리의 자체 명령어로 교체하세요.