[awesome-claude-code] Husky CI 검증 워크플로우

📌 참고: 이 문서는 awesome Claude Code 문서의 원문 + 레퍼런스입니다.

원문 링크를 방문하셔서 복사해서 사용하셔도 됩니다

이 파일을 .claude/skills/ 하위에 복사하여 스킬로 등록할 수도 있습니다

(26.03.15 기준)

요약

이 명령의 목표는 저장소가 정상 작동 상태인지 확인하고 문제가 있으면 수정하는 것입니다.

목표

CI 검사를 실행하고 저장소가 양호한 상태가 될 때까지 문제를 수정한 다음 파일을 스테이징에 추가합니다. 모든 명령은 저장소 루트에서 실행됩니다.
0. pnpm i를 실행하여 저장소가 최신 상태인지 확인합니다

pnpm lint를 실행하여 린터가 통과하는지 확인합니다
pnpm nx run-many --targets=build:types,build:dist,build:app,generate:docs,dev:run,typecheck를 실행하여 타입과 빌드가 통과하는지 확인합니다.
특정 명령이 실패하면, 디버깅하는 동안 해당 명령만 실행하여 토큰을 절약하세요
pnpm nx run-many --target=test:coverage를 실행하여 테스트가 통과하는지 확인합니다
실행 전에 .env 파일이 있으면 먼저 소싱하세요
pnpm run sort-package-json을 실행하여 package.json이 정렬되어 있는지 확인합니다
pnpm nx run-many --targets=lint:package,lint:deps를 실행하여 패키지가 린트되어 있는지 확인합니다
이중 확인. 수정 사항이 있었다면 이전 검사를 다시 실행하세요. 예를 들어, 3단계에서 수정한 경우 1단계, 2단계, 3단계를 다시 실행하여 이전 단계에서 리그레션이 없었는지 재확인하세요.
git status와 git add로 파일을 스테이징에 추가합니다. lib/* 폴더의 git 서브모듈은 추가하지 않도록 주의하세요

명령이 성공할 때까지 다음 단계로 넘어가지 마세요. 중간에 프롬프트가 있거나 디버깅이 필요할 수 있지만, 제가 명시적으로 검사를 건너뛸 수 있는 허가를 주지 않는 한 항상 계속 진행하세요.
맨 마지막에 통과한 모든 단계 옆에 체크마크 이모지가 있는 작업 목록을 출력하세요

무언가 깨졌을 때의 프로토콜

CI가 깨지면 다음 단계를 수행하세요

1. 왜 깨졌는지 설명하기

테스트가 깨졌을 때 먼저 무엇이 깨졌는지에 대해 깊이 생각하고 완전한 설명을 제공하세요. 당신의 가설을 뒷받침하는 소스 코드와 로그를 인용하세요.
가설을 뒷받침할 소스 코드나 로그가 없다면, 깊이 생각하고 코드베이스에서 증거를 찾으세요.
가설을 확인하거나 왜 깨졌는지 파악하는 데 도움이 된다면 console.log를 추가하세요
왜 깨졌는지 모르거나 컨텍스트가 충분하지 않다면 도움을 요청하세요

2. 문제 수정하기

수정 방안을 제안하세요
왜 그 수정을 하는지, 왜 작동할 것으로 믿는지 완전히 설명하세요
수정이 작동하지 않으면 1단계로 돌아가세요

3. 같은 버그가 다른 곳에도 있는지 고려하기

같은 버그가 다른 곳에도 존재할 수 있는지, 그리고 어떻게 찾아서 수정하는 것이 가장 좋은지 깊이 생각하세요

4. 정리하기

수정 후에는 항상 추가한 console.log를 정리하세요

팁

일반적으로 createTevmNode와 같은 대부분의 함수와 타입은 createTevmNode.js라는 파일에 있으며, TevmNode.ts라는 타입과 createTevmNode.spec.ts라는 테스트가 있습니다. 일반적으로 파일당 하나의 항목이 있어서 파일을 쉽게 찾을 수 있습니다.

pnpm i

이것이 실패하면 무언가 매우 잘못된 것이므로 중단해야 합니다. 단, 문제가 쉼표 누락과 같은 단순한 구문 오류인 경우는 예외입니다.

pnpm lint

이것은 biome을 사용하여 전체 코드베이스를 린트합니다

pnpm nx-run-many --targets=build:types,typecheck

2단계의 이 명령들은 TypeScript 타입을 검사하며, 깨졌을 때는 TypeScript 오류 관련 원인일 가능성이 높습니다. 문제가 명확하다면 수정하는 것이 일반적으로 좋습니다.
TypeScript 타입이 왜 맞지 않는지에 대한 증거가 이미 컨텍스트에 있거나 명확하지 않다면, 수정을 시도하기 전에 확인을 위해 TypeScript 타입을 찾아보는 것이 좋습니다. 여기에는 node_modules에서 찾아보는 것도 포함됩니다. tevm 패키지라면 이 모노레포에 있습니다.
여기서 몇 번 이상 실패하면 문서를 확인해야 합니다

테스트 실행

테스트를 실행하려면 test:coverage에 대한 nx 명령을 실행하세요. 일반 test 명령은 타임아웃되므로 절대 실행하지 마세요. 이전 명령이 패키지를 실행한 것과 같은 순서로 개별 패키지에서 하나씩 실행하세요.

디버깅을 쉽게 하기 위해 한 번에 하나의 패키지씩 테스트를 실행하세요

모든 테스트에 vite를 사용합니다.

종종 스냅샷 테스트가 실패합니다. 스냅샷 테스트를 업데이트하기 전에 스냅샷 변경이 왜 예상된 것인지에 대한 가설을 명확히 설명해야 합니다
테스트가 실패할 때마다 무언가 깨졌을 때의 프로토콜을 따르세요
예상대로 작동하고 있다고 가정하는 것들이 실제로 그러한지 console.log를 추가하여 가정을 테스트하는 것이 종종 좋은 방법입니다

절대 커밋하지 마세요

스테이징에만 추가하고 실제로 커밋은 절대 하지 마세요

오류는 바로 수정하세요

TypeScript 타입과 테스트가 다른 것이 깨졌는지 알려줄 것이므로, 수정하는 것을 두려워하지 마세요. 위험하다고 여겨진다고 수정을 건너뛸 필요가 없습니다.

수정이 이루어졌을 때

어떤 단계에서 코드 변경이 필요한 수정이 있을 때, 해당 단계를 마친 후 항상 다음을 수행하세요.

pnpm run lint를 실행하여 파일이 포맷되어 있는지 확인합니다
먼저 파일을 스테이징에 추가할지 사용자에게 물어봅니다
커밋 메시지를 제안하되 실제로 커밋은 하지 말고 사용자가 직접 하도록 합니다