setup-pre-commit

setup-pre-commit 개요

setup-pre-commit skill은 실용적인 Git hook 워크플로를 쉽게 붙이도록 도와줍니다. 즉, Husky pre-commit 검사, lint-staged를 이용한 Prettier 포맷팅, 그리고 필요에 따라 커밋이 반영되기 전에 typecheck/test를 돌리는 구성을 한 번에 정리해 줍니다. 이미 Node 기반 툴체인이 있는 저장소에서, 손으로 훅을 조립하는 대신 빠르고 반복 가능한 설정이 필요할 때 가장 잘 맞습니다.

setup-pre-commit은 어떤 용도인가

setup-pre-commit skill은 커밋 시점에 안전장치를 두어 포맷을 표준화하고, 눈에 띄는 오류를 초기에 잡고 싶을 때 사용합니다. 핵심은 “Husky만 따로 설치”하는 데 있지 않습니다. 저장소 구조를 새로 뜯어고치지 않으면서 로컬 커밋을 더 안전하게 만드는 데 있습니다.

어떤 경우에 특히 잘 맞는가

저장소가 이미 Prettier, typecheck, test 스크립트를 쓰고 있거나 쓸 수 있고, npm·pnpm·Yarn·Bun 전반에서 통하는 간단한 규칙이 필요하다면 잘 맞습니다. 기존 프로젝트에 정책 논쟁을 크게 일으키지 않으면서 빠르게 적용할 수 있는 설정이 필요할 때도 유용합니다.

어디에서 한계가 있는가

프로젝트가 Node 기반이 아니거나, pre-commit 대신 commit-msg나 pre-push 로직이 필요하거나, 단순한 훅보다 더 복잡한 오케스트레이션이 필요한 경우에는 이 skill의 효용이 떨어집니다. 또한 어떤 스크립트가 실제로 존재하는지 확인한 뒤 훅에 넣는 과정에 익숙하다는 전제도 있습니다.

setup-pre-commit skill 사용 방법

설치하고 올바른 파일부터 열기

npx skills add mattpocock/skills --skill setup-pre-commit로 설치합니다. 그다음에는 먼저 SKILL.md를 읽으세요. 실제 워크플로와 판단 포인트가 거기에 들어 있습니다. 디렉터리 보기에서 파일이 하나만 보이더라도 설정을 따라가는 데는 충분하지만, 그래도 repository tree에서 package manager와 스크립트 단서를 확인하는 것이 좋습니다.

저장소 문맥을 제대로 전달하기

가장 좋은 결과를 내려면, 어떤 lockfile이 있는지, package.json에 이미 typecheck와 test가 있는지, Prettier가 이미 설정되어 있는지 알려줘야 합니다. 예를 들면 “이 저장소에서 pnpm을 사용해 setup-pre-commit을 설정해 줘. 기존 Prettier 설정은 유지하고, 이미 존재하는 스크립트만 추가해 줘.”처럼 요청하는 것이 좋습니다. 이렇게 하면 package manager와 훅 내용에 대한 추측을 줄일 수 있습니다.

올바른 순서로 워크플로 따르기

이 skill은 단순한 순서로 동작하도록 설계되어 있습니다. package manager를 감지하고, dev dependency를 설치하고, Husky를 초기화하고, .husky/pre-commit을 작성하고, lint-staged를 추가하고, Prettier 설정을 만들거나 재사용하는 흐름입니다. 실제로 중요한 판단은 npm run typecheck와 npm run test를 넣을지, 아니면 해당 스크립트가 없을 때는 빼야 할지입니다. 이 선택이 훅을 유용하면서도 깨지지 않게 만듭니다.

실전용 프롬프트 패턴

저장소 상태와 원하는 정책을 함께 적으세요. 예를 들면, “이 monorepo에 setup-pre-commit을 써서 Husky, lint-staged, Prettier를 추가해 줘. lockfile은 pnpm-lock.yaml이고, typecheck는 있지만 test는 없으며, 이미 .prettierrc가 있어.” 같은 식입니다. 이렇게 하면 skill이 존재하지 않는 스크립트를 지어내거나 설정을 덮어쓰지 않고 올바른 구성을 만들 수 있습니다.

setup-pre-commit skill FAQ

setup-pre-commit은 새 저장소 전용인가?

아닙니다. 오히려 기존 저장소에서 더 유용한 경우가 많습니다. 파일을 하나하나 수작업으로 복원하지 않고도 일관된 훅 정책을 붙일 수 있기 때문입니다. 어떤 스크립트와 설정이 이미 있는지 알고 있을 때 가장 잘 작동합니다.

Husky와 lint-staged를 둘 다 써야 하나요?

이 워크플로에서는 그렇습니다. 그 조합이 목적이기 때문입니다. Husky는 훅을 실행하고, lint-staged는 포맷 적용 범위를 staged file로 제한해 커밋 속도를 유지합니다. 둘 중 하나만 원한다면, setup-pre-commit skill보다 일반적인 프롬프트가 더 간단할 수 있습니다.

Prettier 설정을 덮어쓰나요?

주의해서 사용하면 그래서는 안 됩니다. 이 skill은 .prettierrc가 없을 때만 새로 만들고, 핵심 판단은 저장소에 이미 보존해야 할 formatter 설정이 있는지 여부입니다. 기존 스타일 정책이 있다면 명시적으로 알려 주세요.

CI용인가요, 아니면 로컬 커밋용인가요?

주요 가치는 로컬 pre-commit 강제에 있지만, 같은 검사들이 CI 기대치와 맞물리는 경우가 많습니다. CI가 다른 명령을 쓴다면 훅을 그대로 복사하지 말고, 실제 파이프라인에서 돌리는 스크립트에 맞추세요. 이것이 setup-pre-commit for CI Troubleshooting에서 가장 중요한 부분입니다.

setup-pre-commit skill 개선 방법

저장소의 실제 제약을 알려 주기

가장 큰 품질 향상은 setup-pre-commit에 package manager, 스크립트, 이미 존재하는 설정 파일을 정확히 알려 주는 데서 나옵니다. 이 맥락이 빠지면 잘못된 command prefix를 쓰거나, 불필요한 스크립트를 만들거나, 첫 커밋에서 바로 실패하는 훅 단계가 생길 수 있습니다.

흔한 훅 실패를 피하기

가장 흔한 실패는 .husky/pre-commit에 존재하지도 않는 typecheck나 test를 넣는 경우입니다. 또 다른 흔한 문제는 staged file만이 아니라 모든 파일을 포맷하는 것입니다. 그러면 커밋 속도가 불필요하게 느려집니다. 훅을 안정적으로 만들고 싶다면, 어떤 스크립트가 없을 때 어떻게 할지도 명시하세요.

명시적인 결과를 요청해서 첫 출력 개선하기

설치만 말하지 말고, 구체적인 결과를 요청하세요. 예를 들어 “staged file에 대해 lint-staged를 실행하는 Husky pre-commit hook을 추가하고, 기존 Prettier 설정은 유지하며, package.json에 이미 정의된 경우에만 typecheck를 포함해 줘.”라고 하면, 모호한 요청보다 훨씬 쓸모 있는 setup-pre-commit guide 결과를 얻을 수 있습니다.

첫 적용 후 다시 다듬기

초기 설정을 끝낸 뒤에는 훅이 팀의 속도와 엄격성 기준에 맞는지 확인하세요. 너무 무겁다면 pre-commit에서 비용이 큰 검사를 빼고 CI로 옮기면 됩니다. 너무 느슨하다면 빠진 스크립트를 추가하거나 lint-staged 범위를 더 좁히세요. 가장 좋은 setup-pre-commit install 결과는 팀이 실제로 계속 사용할 구성입니다.