setup-pre-commit

setup-pre-commit skill 개요

setup-pre-commit가 하는 일

setup-pre-commit skill은 husky, lint-staged, Prettier, 그리고 선택적으로 typecheck, test 스크립트를 활용해 JavaScript 또는 TypeScript 저장소에 실용적인 Git 커밋 게이트를 추가하도록 에이전트를 도와줍니다. 쉽게 말해, staged 파일에 포맷팅을 연결하고 문제가 있는 커밋이 들어가기 전에 차단할 수 있게 해줍니다.

이 skill이 특히 잘 맞는 사용자

이 skill은 기존 저장소에 부담 적은 pre-commit 구성을 넣고 싶지만, 처음부터 Husky 설정을 직접 설계하고 싶지는 않은 팀이나 개인 개발자에게 가장 잘 맞습니다. 특히 이미 Node 기반 프로젝트를 쓰고 있고, 커밋 시점 포맷팅과 가벼운 품질 검사를 함께 두고 싶을 때 잘 맞습니다.

실제로 해결하려는 일

대부분의 사용자가 원하는 것은 단순히 “Husky를 설치하는 것”이 아닙니다. 진짜 필요한 것은 기여자가 안심하고 커밋할 수 있는 저장소, 즉 다음과 같은 예측 가능한 훅을 갖춘 저장소입니다.

• staged 파일을 포맷팅하고,
• 이미 있는 typecheck, test 스크립트가 있으면 이를 실행하고,
• 불필요한 추가 툴을 억지로 만들지 않고,
• 저장소의 패키지 매니저와 맞춰 동작하는 것.

이것이 바로 setup-pre-commit의 실질적인 가치입니다.

일반 프롬프트와 다른 점

일반적인 프롬프트는 여러 가지 Git hook 패턴을 두루 제안할 수 있습니다. 반면 setup-pre-commit skill은 범위를 더 좁히고, 그래서 더 실용적입니다. 흔한 사용 사례에 맞춰 Husky + lint-staged + Prettier 경로를 구체적으로 설정하고, 패키지 매니저를 감지하고, 필요한 파일을 만들며, 저장소가 실제로 지원하지 않는 typecheck나 test 명령을 함부로 추가하지 않도록 설계되어 있습니다.

기본으로 설정되는 것

skill 소스를 기준으로 보면, 기대되는 결과물은 다음과 같습니다.

• husky 초기화
• .husky/pre-commit 파일 생성
• .lintstagedrc 생성
• 기존 Prettier 설정이 없을 때만 .prettierrc 생성
• lint-staged용 hook 명령, 그리고 해당 스크립트가 이미 있을 때만 typecheck, test 추가

잘 맞는 저장소와 잘 안 맞는 저장소

잘 맞는 경우:

• Node.js 저장소
• frontend 또는 full-stack TypeScript 앱
• 이미 package.json을 사용하는 저장소
• test, typecheck 스크립트가 이미 있는 프로젝트

덜 적합한 경우:

• 커스텀 hook 오케스트레이션을 쓰는 polyglot monorepo
• 이미 다른 hook manager를 사용하는 저장소
• 기본값보다 더 빠르고 선택적이거나 언어별로 세분화된 커밋 파이프라인을 원하는 팀
• 모든 커밋마다 테스트를 돌리기에는 너무 느린 프로젝트

setup-pre-commit skill 사용 방법

setup-pre-commit skill 설치 맥락

Skills 시스템을 쓰고 있다면, 소스 저장소에서 다음처럼 skill을 추가합니다.

npx skills add mattpocock/skills --skill setup-pre-commit

그다음에는 Git hook을 추상적으로 설명해 달라고 하기보다, 현재 저장소를 실제로 수정해야 할 때 이 skill을 호출하는 것이 맞습니다.

저장소에서 필요한 입력 정보

setup-pre-commit 사용 품질은 저장소 문맥에 크게 좌우됩니다. 호출하기 전에 에이전트가 다음을 확인할 수 있어야 합니다.

• package.json
• package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lockb 같은 lockfile
• 기존 Prettier 설정 파일
• 기존 .husky/ 또는 Git hook 설정
• typecheck, test 스크립트 존재 여부

이 정보가 없으면, 에이전트가 현재 저장소의 패키지 매니저나 스크립트와 맞지 않는 명령을 만들어낼 수 있습니다.

가장 먼저 읽어야 할 저장소 파일

먼저 SKILL.md부터 보세요. 이 skill은 단순하고 자체 완결적이며, 핵심 로직이 모두 여기에 들어 있습니다.

• 패키지 매니저 감지
• husky, lint-staged, prettier 설치
• npx husky init 실행
• .husky/pre-commit 작성
• .lintstagedrc 작성
• 없을 때만 .prettierrc 추가
• 결과 검증

이 skill은 별도 helper 파일에 숨겨진 동작이 들어 있지 않습니다.

setup-pre-commit skill을 잘 프롬프트하는 방법

약한 프롬프트:

Set up pre-commit hooks.

더 좋은 프롬프트:

Use the setup-pre-commit skill in this repo. Detect the package manager from lockfiles, inspect package.json, add Husky with lint-staged and Prettier, and only include typecheck or test in .husky/pre-commit if those scripts already exist. Do not overwrite any existing Prettier config. Show me the files you changed and the exact commands you ran.

이 프롬프트가 더 나은 이유:

• 패키지 매니저 규칙을 분명히 고정해 주고,
• 존재하지 않는 스크립트를 지어내는 일을 막고,
• 기존 포맷팅 규칙을 보존하며,
• 검토 가능한 diff를 요청하기 때문입니다.

막연한 목표를 완전한 요청으로 바꾸는 방법

실제 목표가 “우리 Git 워크플로를 더 안전하게 만들기”라면, 이를 저장소 기준 제약으로 바꿔서 요청하는 편이 좋습니다.

• 사용 중인 패키지 매니저
• 테스트가 pre-commit에 넣어도 될 만큼 빠른지
• 포맷팅만 원하는지, 포맷팅+검증까지 원하는지
• 저장소에 이미 Prettier나 Husky가 있는지
• 기여자 속도를 위해 hook을 최소화하고 싶은지

예시:

Use setup-pre-commit for Git Workflows in this React TypeScript repo. We use pnpm, already have a test script, and have typecheck in package.json. Keep the hook simple and fast. Reuse existing Prettier config if present. If tests look expensive, explain whether they should stay in pre-commit or move to pre-push.

이런 프롬프트는 단순한 작업명만 던지는 것이 아니라, 실제 의사결정에 필요한 정보를 에이전트에 제공합니다.

예상되는 파일과 명령

일반적인 npm 저장소라면, 이 skill 실행 결과는 보통 다음으로 이어집니다.

• dev dependency 설치: husky, lint-staged, prettier
• npx husky init 실행
• .husky/pre-commit 생성
• .lintstagedrc 생성
• 필요 시 .prettierrc 생성

hook 내용은 패키지 매니저에 맞게 바뀌어야 합니다. 소스 skill에서도 필요한 곳에서는 npm을 감지된 패키지 매니저로 치환하라고 분명히 안내합니다.

패키지 매니저별 실제 동작

이 skill의 패키지 매니저 감지 규칙은 단순합니다.

• package-lock.json → npm
• pnpm-lock.yaml → pnpm
• yarn.lock → yarn
• bun.lockb → bun
• 애매하면 → npm

이 부분은 중요합니다. 많은 setup-pre-commit 설치 실패는 Husky 자체보다도, 문서나 생성 파일 안에서 패키지 매니저 명령이 섞여 버리는 문제에서 시작되기 때문입니다.

의도적으로 하지 않는 일

이 skill의 유용한 경계 중 하나는, 저장소가 원래 지원하지 않는 스크립트를 억지로 만들어내지 않는다는 점입니다. package.json에 typecheck나 test가 없다면 .husky/pre-commit에 해당 줄을 넣지 않아야 하고, 사용자에게도 그 이유를 명확히 알려줘야 합니다.

이 점에서, 모든 프로젝트에 TypeScript 검사와 테스트 러너가 있다고 가정하는 넓은 프롬프트보다 더 안전합니다.

skill 실행 후 권장 워크플로

에이전트가 skill을 적용한 뒤에는 다음 순서로 확인하는 것이 좋습니다.

1. package.json 확인
2. .husky/pre-commit 확인
3. .lintstagedrc 확인
4. 기존 Prettier 설정이 덮어써지지 않았는지 확인
5. 작은 staged 포맷팅 변경으로 테스트 커밋 실행
6. test가 pre-commit에 남아 있어야 하는지, 다른 단계로 옮겨야 하는지 판단

마지막 단계가 특히 중요합니다. 올바르게 동작하는 것과 쓰기 편한 것은 다릅니다. 오래 걸리는 테스트를 실행하는 hook은 기술적으로는 맞아도 실제 팀 도입에는 방해가 될 수 있습니다.

기본 검토 체크리스트

변경을 머지하기 전에 다음을 확인하세요.

• 패키지 매니저가 저장소와 일치하는지
• .husky/pre-commit이 기여자가 로컬에서 실행 가능한 명령을 쓰는지
• hook이 존재하지 않는 스크립트를 호출하지 않는지
• staged 포맷팅이 lint-staged를 통해 제한적으로 적용되는지
• Prettier 설정은 없을 때만 추가되었는지
• 일상적으로 쓰기에 커밋 지연이 감당 가능한 수준인지

setup-pre-commit skill FAQ

setup-pre-commit skill은 초보자에게도 괜찮을까?

네, 저장소가 표준적인 Node 프로젝트라면 괜찮습니다. 이 skill은 어느 정도 방향성이 분명하지만 복잡하지 않고, Husky 초기화나 기본 lint-staged 연결에서 처음 많이 겪는 마찰을 꽤 줄여 줍니다.

setup-pre-commit skill이 다루지 않는 범위는?

이 skill은 전체 코드 품질 전략을 설계하려는 도구가 아닙니다. ESLint 규칙을 고르지 않고, monorepo hook 실행을 최적화하지 않으며, 파일 타입별로 정교한 lint-staged 명령을 만들지도 않습니다. 범위는 초기 commit-hook 설정에 맞춰져 있습니다.

언제 setup-pre-commit skill을 쓰지 않는 편이 좋을까?

다음 경우에는 건너뛰는 편이 낫습니다.

• 저장소에 이미 성숙한 Git hook 시스템이 있는 경우
• Node 툴링 바깥에서 언어별 다단계 hook이 필요한 경우
• staged 파일 패턴을 아주 세밀하게 커스터마이즈해야 하는 경우
• 모든 커밋마다 테스트를 돌리면 개발 속도가 분명히 느려지는 경우

이럴 때는 더 맞춤형인 프롬프트나 기존 사내 표준이 더 적합할 수 있습니다.

AI에게 그냥 “set up Husky”라고 하는 것보다 나은가?

이 정확한 사용 사례라면 대체로 그렇습니다. setup-pre-commit의 가치는 새로움이 아니라 제약된 실행에 있습니다. 합리적인 기본 경로를 코드화해 두었고, lockfile 감지, 누락된 스크립트, Prettier 설정 생성 시점 같은 부분의 추측을 줄여 줍니다.

setup-pre-commit skill은 monorepo에서도 동작할까?

가끔은 되지만, 주의가 필요합니다. 최상위에 명확한 package.json 하나가 있고 hook 전략도 하나로 정리되어 있다면 여전히 도움이 될 수 있습니다. 하지만 패키지마다 스크립트가 따로 있거나, 포맷팅 정책이 다르거나, workspace별 테스트 명령이 분리되어 있다면 신뢰도가 떨어집니다.

저장소에 이미 포맷팅 설정이 있어도 Prettier를 강제로 넣나?

아니요. 소스 지침은 기존 Prettier 설정이 전혀 없을 때만 .prettierrc를 만들라고 되어 있습니다. 실제 도입 장벽을 낮추는 중요한 동작입니다.

포맷팅 외의 Git Workflows에도 setup-pre-commit skill을 쓸 수 있을까?

어느 정도는 가능합니다. 이 skill은 해당 스크립트가 이미 있을 때 typecheck, test를 커밋 워크플로에 추가하는 정도까지는 지원합니다. 다만 전체 branch protection이나 CI 설계 도구는 아닙니다.

setup-pre-commit skill 개선 방법

처음부터 저장소 사실관계를 더 강하게 제공하기

setup-pre-commit 사용 품질을 가장 빠르게 높이는 방법은 프롬프트에 저장소의 구체적 신호를 넣는 것입니다.

• 패키지 매니저
• typecheck 존재 여부
• test 존재 여부
• 테스트 속도
• 기존 Prettier 설정 존재 여부
• .husky/ 존재 여부

가정에 의존하지 않고 검증된 사실을 바탕으로 동작할 수 있을 때, 이 skill의 신뢰도는 훨씬 올라갑니다.

diff 중심 구현을 요청하기

개선된 프롬프트 예시는 다음과 같습니다.

Use the setup-pre-commit skill, but minimize changes. Reuse existing config where possible, avoid replacing current hook behavior, and show the exact file diff before writing anything risky.

이 방식은 이미 일부 툴링이 들어 있는 저장소에서 특히 유용합니다.

가장 흔한 실패를 막기

가장 흔한 실패는 저장소에서 실행할 수 없는 명령을 추가하는 것입니다. 결과를 개선하려면 에이전트에게 이렇게 분명히 말하세요.

Only add typecheck and test to the hook if those scripts already exist in package.json. Otherwise omit them and explain why.

이 지시는 소스 skill의 의도와도 맞고, 커밋이 깨지는 상황을 예방해 줍니다.

정합성뿐 아니라 개발 속도까지 조정하기

많은 팀이 pre-commit에서 npm run test를 돌리면 너무 무겁다고 느낍니다. 속도가 중요하다면, 에이전트에게 hook 비용을 평가하게 하세요.

Use setup-pre-commit, but if tests appear slow or broad, explain whether they should move to pre-push or CI instead of pre-commit.

이렇게 하면 skill이 단순한 “툴 설치”에서 “워크플로에 맞춘 적용”으로 바뀝니다.

패키지 매니저에 안전한 명령을 요청하기

팀이 pnpm, yarn, bun을 쓴다면 lockfile이 있더라도 이를 명시적으로 적어 주세요. 그러면 생성되는 hook 파일과 후속 안내에서 명령 일관성이 더 좋아지고 애매함도 줄어듭니다.

기존 기준을 보존하도록 요청하기

저장소에 이미 포맷팅 파일이나 hook 파일이 있다면, 다음과 같이 덧붙이세요.

Do not overwrite existing Prettier or Husky config without comparing and explaining the merge strategy.

이건 생각보다 중요합니다. pre-commit 툴링은 기존 로컬 관례를 너무 공격적으로 대체할 때 기술적으로보다 사회적으로 실패하는 경우가 많습니다.

검증 단계를 넣어 출력 품질 높이기

더 좋은 최종 프롬프트에는 이런 요구가 들어갑니다.

After applying setup-pre-commit, verify that the hook files exist, dependencies are in devDependencies, and the hook references only valid scripts. Then tell me how to test it with one staged file.

이렇게 하면 에이전트가 단순히 파일만 만드는 데서 그치지 않고, 실제 사용 가능성까지 확인하게 됩니다.

첫 결과 후 한 번 더 다듬기

첫 결과가 기술적으로는 맞지만 어딘가 어색하다면, 처음부터 다시 넓은 프롬프트로 시작하기보다 아래 같은 후속 지시로 다듬는 편이 보통 더 효과적입니다.

• “Make the hook faster.”
• “Adapt this for pnpm.”
• “Remove test from pre-commit but keep typecheck.”
• “Keep existing Prettier settings and only add missing pieces.”
• “Adjust for a monorepo root package.”

사용자가 가장 중요하게 보는 것

대부분의 도입자에게 최고의 setup-pre-commit 가이드는 “몇 개의 툴을 설치하느냐”가 아니라, 다음을 만족하느냐입니다.

• 현재 저장소에서 바로 동작하는지
• 커밋을 깨뜨리지 않는지
• 기존 설정을 존중하는지
• 개발자가 계속 켜 둘 수 있을 만큼 충분히 빠른지

이 결과를 염두에 두고 setup-pre-commit skill을 쓰면, 일회성 설정이 아니라 오래 남는 가치로 이어질 가능성이 훨씬 높아집니다.