freeze

freeze skill 개요

freeze가 하는 일

freeze는 세션 동안 파일 편집을 하나의 디렉터리로만 제한하는 가드레일 skill입니다. 허용된 경로 밖에서는 Edit과 Write를 막기 때문에, 워크플로 자동화 agent가 모듈 하나, 기능 폴더 하나, 또는 디버깅 샌드박스 안에 머물게 하고 싶을 때 유용합니다. 실수로 넓은 범위를 건드리는 것을 막기 위해 freeze skill이 필요하다면, 바로 이런 상황에 맞는 선택입니다.

누가 설치하면 좋은가

agent에게 좁은 범위에서 디버그, 리팩터링, 패치 작업을 자주 맡기지만, 관련 없는 파일까지 “도와준답시고” 건드리는 것은 원치 않는다면 freeze를 설치하세요. 특히 유지보수 담당자, 리뷰어, 그리고 편집 경계가 넓은 자율성보다 중요한 혼합형 또는 위험한 코드베이스에서 일하는 사람에게 가장 가치가 큽니다.

무엇이 다른가

핵심 차별점은 안내가 아니라 강제력입니다. freeze는 pre-tool hook을 사용해 선택한 디렉터리 밖의 편집을 거부하므로, 모델에게 단지 집중하라고 요청하는 프롬프트보다 훨씬 강합니다. 그래서 freeze guide는 실제 격리에 유용하며, 특히 조금만 벗어나도 비용이 커지는 세션에서 효과적입니다.

freeze skill 사용 방법

설치하고 경계를 초기화하기

freeze install을 하려면, 리포지토리의 skill manager로 환경에 skill을 추가한 뒤 잠글 디렉터리를 선택하세요. 허용 경로가 세션마다 달라지므로, 설정 흐름은 인터랙티브하게 진행됩니다. 실무에서는 “어느 디렉터리를 freeze할까요?”라는 질문에, “backend 쪽” 같은 모호한 답이 아니라 정확한 경로로 답할 준비를 해두는 것이 좋습니다.

먼저 이 파일들을 읽기

먼저 SKILL.md를 읽어 제어 흐름을 이해하고, 그다음 bin/check-freeze.sh를 살펴 경계가 어떻게 강제되는지 확인하세요. skill을 수정하거나 맞춤화하는 경우에는 SKILL.md.tmpl도 함께 검토해 생성되는 구조를 파악하는 것이 좋습니다. 이 파일들을 보면 freeze usage가 실제로 무엇을 허용하는지, 무엇이 차단되는지, 그리고 경로 파싱이 어디서 실패하거나 느슨하게 동작할 수 있는지 알 수 있습니다.

skill에 정확한 프롬프트를 주기

가장 좋은 입력은 명확한 경계가 있는 집중형 작업입니다. 예를 들어: “apps/payments의 편집만 freeze하고, 공유 라이브러리는 건드리지 말고 그 안의 실패하는 unit tests를 고쳐줘.” 같은 식입니다. 이것은 “이 앱 디버그해줘”보다 훨씬 낫습니다. freeze는 디렉터리 대상과 그 안에 수용 가능한 작업이 필요하기 때문입니다. 범위가 정확할수록 agent가 예외를 요청할 가능성도 줄어듭니다.

실무 워크플로 팁

freeze는 첫 패스를 외과적으로 처리해야 할 때 가장 잘 맞습니다. 버그를 찾고, 한 폴더 안에서 패치하고, 범위를 넓히지 않은 채 검증하는 식입니다. 작업이 정말로 여러 디렉터리를 넘나드는 변경을 필요로 한다면, 억지로 freeze에 맞추지 마세요. 허용 경로를 넓히거나 다른 워크플로를 쓰는 편이 낫습니다. 요청된 변경 집합이 본래부터 경계가 뚜렷하고, repository layout도 분명할 때 이 skill이 가장 잘 작동합니다.

freeze skill FAQ

freeze는 디버깅에만 쓰이나요?

아닙니다. 디버깅이 흔한 용도이긴 하지만, freeze skill은 경계가 있는 refactor, feature isolation, review-safe 편집에도 도움이 됩니다. 핵심은 작업 중 agent를 한 디렉터리 안에 머물게 하고 싶은지 여부입니다.

일반 프롬프트와 무엇이 다른가요?

일반 프롬프트는 모델이 지시를 따를 것이라는 기대에 의존합니다. freeze는 hook을 통해 강제력을 더하므로, 모델이 범위를 벗어난 편집을 시도해도 차단됩니다. 그래서 guardrail이 중요한 Workflow Automation 작업에서 더 신뢰할 수 있습니다.

freeze는 초보자에게도 친화적인가요?

디렉터리를 자신 있게 지정할 수 있다면 그렇습니다. 초보자가 가장 흔히 하는 실수는 경계를 너무 넓히거나 너무 좁게 잡는 것입니다. 디렉터리가 모호하면 범위를 다시 설명하느라 세션이 멈출 수 있습니다.

언제는 freeze를 쓰지 말아야 하나요?

작업이 여러 모듈, 공유 설정, 또는 repo 전체 포맷팅까지 이어질 것으로 예상된다면 쓰지 마세요. 그런 경우에는 제한이 오히려 작업 속도를 떨어뜨리거나 불필요한 차단을 만들 수 있습니다. freeze는 단순한 선호가 아니라 실제 결정 경계가 있을 때 가장 적합합니다.

freeze skill 개선 방법

경계를 명확하게 지정하기

가장 큰 품질 향상은 정확한 디렉터리와 기대 결과를 함께 명시하는 데서 나옵니다. 좋은 입력의 예는 이렇습니다: “services/auth의 편집만 freeze하고, shared/는 건드리지 말고 token refresh flow를 업데이트해줘.” 반대로 “auth 고쳐줘”처럼 약한 입력은 추측을 부르고, 차단되거나 미완성된 편집이 나올 가능성을 높입니다.

파일, 증상, 제한 사항을 함께 주기

freeze를 더 잘 쓰려면 실패한 파일, 관찰된 동작, 그리고 손대면 안 되는 파일을 함께 적으세요. 예: “apps/admin만 편집하고, 버그는 src/table.ts에 있으며, API contract는 바꾸지 마세요.” 이렇게 하면 agent가 frozen zone 안에 머물면서도 실제 문제를 해결하기가 쉬워집니다.

경계 불일치를 주의하기

가장 흔한 실패 패턴은 작업에 실제로는 frozen 디렉터리보다 넓은 범위가 필요한데, 그 사실이 뒤늦게 드러나는 경우입니다. agent가 거부된 write를 계속 만나면, 보통 해법은 경계를 넓히거나 작업을 단계로 나누는 것입니다. 이것은 버그가 아니라 기능입니다. freeze가 계획과 범위가 맞지 않는다는 점을 알려주는 것이기 때문입니다.

첫 패스 이후 반복 개선하기

첫 결과를 받은 뒤에는, 해결책이 frozen path 밖의 가정에 의존했는지 확인하세요. 그렇다면 대상 디렉터리, 허용할 파일 유형, 건드리면 안 되는 항목을 한두 개의 구체적 제약으로 보강해 프롬프트를 다듬으세요. 가장 좋은 freeze skill 결과를 얻으려면, 창의성을 더 요구하기보다 범위를 더 명확히 하는 방식으로 반복 개선하는 것이 맞습니다.