guards-setup

guards-setup

답변 언어: 이 지침은 한국어로 쓰였지만, 출력은 항상 사용자가 대화에서 쓰는 언어를 따른다 (한국어→한국어, 영어→영어). 기존 문서·코드에 언어가 있으면 그쪽을 우선한다.

텍스트 규칙은 잊히지만 기계 게이트는 잊히지 않는다. 이 스킬은 규율의 절반을 린트/CI로 내려보낸다. 스니펫은 이 스킬의 templates/에 있다.

절차 (순서 엄수)

1. 감지: pyproject.toml/requirements*.txt/*.py → Python; package.json/tsconfig.json → JS/TS; 둘 다면 둘 다.

2. 기존 설정 읽기: ruff/mypy/eslint/import-linter 설정이 이미 있으면 먼저 읽는다. 절대 덮어쓰지 않는다. 이미 같은 일을 하는 도구가 있으면 그 항목을 아예 빼고 제안한다. 타입 검사는 mypy 말고도 basedpyright·pyright가 흔하다 (pyproject.toml의 [tool.basedpyright]/[tool.pyright], pyrightconfig.json, package.json의 pyright 스크립트). 있으면 mypy를 권하지 마라 — 타입체커 둘을 돌리면 서로 다른 소리를 한다. 비밀키도 gitleaks·detect-secrets 설정이 있으면 마찬가지다. 겹치는 걸 또 깔아주는 건 도움이 아니라 짐이다.

3. 묻기 (AskUserQuestion, 필수): 설치할 가드를 multiSelect로 고르게 한다. 사용자는 대개 입문자다 — 아래를 지켜라.

   • 쉬운 말로. 전문용어(complexity·max-depth·dpdm·exit 1·no-any· OAuth 등)를 앞세우지 말고, "이게 나한테 뭘 해주는지"를 한 줄로 먼저 쓴다. 정확한 규칙값은 괄호로 뒤에 짧게. 예: "코드가 너무 길고 복잡해지면 빨간불로 알려줘요 (함수 60줄·복잡도 10 넘으면)".
   • 추천 표시. 로컬에서 외부 설정 없이 바로 되는 가드(복잡도 린트 + 순환 의존 검사)를 **맨 앞에 두고 label에 "(추천)"**을 붙인다. 입문자 기본값은 이 둘이면 충분하다 — GitHub도 토큰도 필요 없는 순수 이득.
   • CI 가드는 GitHub 리모트(git remote)가 있을 때만 추천으로 올린다 — "GitHub에 올릴 때마다 자동 검문, 통과 못 하면 못 올려요 (초반엔 답답할 수 있어요)". 리모트가 없으면 목록에서 빼거나 "나중에"로.
   • 격주 구조 감사는 label에 "(고급)"을 붙이고, 켜기 전에 OAuth 토큰 등록·Actions 권한 설정이 필요하다고 설명에 미리 밝힌다. 처음이면 나중에 해도 된다고 안내.
   • "다 켜라"고 밀지 마라. 4개 전부 체크된 기본값처럼 몰아가지 말고, 입문자에겐 로컬 2종을 권하고 나머지는 필요해지면 그때 켜라고 말한다.
   • 플래그로 켜게 하지 마라. CI를 목록에 넣을지는 git remote로 직접 확인해 정한다 — 사용자가 --ci를 외워서 쳐야 보이면, 모르는 사람은 영영 못 켠다. 리모트가 없으면 목록에서 빼고 왜 뺐는지 한 줄 ("GitHub에 안 올리는 프로젝트라 CI는 돌 자리가 없어요"). 안 도는 워크플로 파일은 보호받는다는 착각만 준다.

4. 병합: 스니펫의 키를 기존 설정에 정중히 병합. 사용자가 이미 정한 값(예: 기존 max-complexity)은 유지하고 차이만 보고.

5. 실측 검증 (grounded-answers 계약): 설치 후 도구를 실제로 한 번 실행해 실제 출력을 보여준다. "될 겁니다"가 아니라 실행 결과로 보고.

6. 위반이 쏟아지면 — 하나씩 묻지 마라. 이미 다 만든 프로젝트에 켜면 위반이 수백 개 나오는 게 정상이다. 그걸 하나하나 "의도한 거예요?"라고 물으면 수백 번 묻는 것이고, 사용자도 코드를 다시 열어보기 전엔 답할 수 없다. 묻는 횟수 자체가 이 기능의 성패다.