guard는 Workflow Automation을 위한 완전한 안전 모드로, 파괴적 명령 경고와 디렉터리 범위 편집 제한을 함께 제공합니다. guard 스킬은 실수 방지, 편집 잠금, 그리고 운영 환경이나 실데이터에 가까운 작업에서 `rm -rf`나 강제 푸시 같은 위험한 명령을 차단하는 데 유용합니다.

Stars0
즐겨찾기0
댓글0
추가됨2026년 5월 9일
카테고리Workflow Automation
설치 명령어
npx skills add garrytan/gstack --skill guard
큐레이션 점수

이 스킬의 점수는 68/100으로, 주의점을 함께 고려해 수록할 만한 수준입니다. 실제로 작동하는 안전 워크플로가 있지만, sibling 스킬에 의존하고 더 넓은 도입 지원 구조는 부족합니다. 디렉터리 사용자에게는 파괴적 명령과 디렉터리 범위 편집에 강제 가드레일이 필요할 때 실용적인 설치 후보입니다.

68/100
강점
  • 안전 관련 요청에 대한 트리거 범위가 분명합니다: "full safety mode", "guard against mistakes", "maximum safety".
  • 구체적인 동작 방식이 있습니다: hooks가 Bash에서 파괴적 명령을 검사하고 freeze-boundary 체크로 `Edit`/`Write` 작업을 제어합니다.
  • 안전 사용 사례가 명확합니다: 손상 전 경고와 디렉터리 범위 편집을 결합해, 일반적인 프롬프트보다 에이전트가 활용할 수 있는 제어 수단이 더 많습니다.
주의점
  • 의존성 리스크가 있습니다: 이 스킬은 /careful 및 /freeze sibling 디렉터리를 명시적으로 참조하므로 단독으로는 완전하지 않습니다.
  • 도입 판단에 필요한 정보가 제한적입니다: 사용자가 설정을 빠르게 검증할 수 있도록 돕는 지원 파일, 설치 명령, 추가 참고 자료가 없습니다.
개요

guard skill 개요

guard가 하는 일

guard skill은 Workflow Automation을 위한 완전한 안전 모드입니다. 파괴적인 명령 경고와 디렉터리 범위 편집 제한을 결합해, 에이전트가 rm -rf, 강제 푸시, 허용된 폴더 밖으로의 예기치 않은 쓰기 같은 위험한 작업을 하기 전에 멈추도록 돕습니다.

누가 설치하면 좋은가

프로덕션 시스템, 실데이터, 또는 경계가 엄격한 코드 영역을 다루고 있고, 에이전트가 기본적으로 보수적으로 동작하길 원한다면 guard를 설치하세요. 일반적인 프롬프트만으로는 부족하고, “guard mode”, “maximum safety”, “lock it down” 같은 동작을 지원하는 skill이 필요할 때 특히 유용합니다.

왜 눈에 띄는가

guard는 단순히 조심하라는 알림이 아닙니다. 훅을 사용해 도구 사용 시점에 안전 체크를 강제하므로, 제약이 대화 수준이 아니라 실제 실행 수준에서 작동합니다. 그래서 Workflow Automation에서 일회성 경고가 아니라 반복 가능한 가드레일이 필요할 때 더 적합합니다.

guard skill 사용법

설치 및 의존성 확인

상위 스택의 guard 설치 흐름을 사용한 뒤, 지원하는 skill이 모두 있는지 확인하세요. guard는 훅이 두 디렉터리의 스크립트를 호출하므로, 형제인 /careful/freeze skill 디렉터리에 의존합니다. 이들이 없으면 안전 체크가 의도한 대로 작동하지 않습니다.

에이전트에 범위가 명확한 작업을 주기

가장 좋은 guard 사용법은 범위를 분명히 하는 데서 시작합니다. 예를 들어: “services/api/ 안에서만 배포 스크립트를 업데이트하고, 파괴적인 명령을 실행하기 전에 경고해줘.” 디렉터리 경계, 변경 유형, 원하는 주의 수준을 함께 적어야 skill이 올바른 제한을 적용할 수 있습니다.

먼저 읽을 파일

SKILL.mdSKILL.md.tmpl부터 보세요. 전자는 현재 동작을 설명하고, 템플릿은 생성된 skill이 어떻게 조립되는지 이해하는 데 도움이 됩니다. 이 repo의 guard 폴더에는 추가 규칙, 참조 문서, 보조 스크립트가 없으므로, 이 두 파일이 사실상 유일한 기준입니다.

잘 작동하는 프롬프트 패턴

좋은 요청은 동작과 안전을 모두 구체적으로 적습니다. 예를 들어: “Workflow Automation에서 guard를 사용해 infra/prod/ 안의 내용만 편집하고, 파괴적인 Bash 명령을 실행하기 전에 경고하며, 그 폴더 밖으로 쓰기하려는 단계가 있으면 중단해줘.” 이것은 “조심해줘”보다 훨씬 낫습니다. 정확한 경계와 기대 동작을 정의하기 때문입니다.

guard skill FAQ

guard는 고급 사용자만 써야 하나요?

아니요. 다만 실수의 비용이 큰 상황에서 가장 가치가 큽니다. 초보자도 안전 래퍼처럼 사용할 수 있으며, 명령이나 편집이 위험한지 확신이 없을 때 특히 도움이 됩니다.

guard는 일반 프롬프트와 어떻게 다른가요?

일반 프롬프트는 주의하라고 요청할 수는 있지만, guard는 훅을 통해 강제 체크를 더합니다. 에이전트가 위험한 행동을 단지 설명만 하는 것이 아니라 실제로 차단해야 할 때 이 차이가 중요합니다.

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

여러 폴더에 걸친 넓고 탐색적인 편집이 필요하거나, 의도적으로 파괴적인 작업인데 이미 검토가 끝난 경우에는 guard를 쓰지 마세요. 디렉터리 범위가 고정되어 있어 strict boundary가 필요하지 않은 작업에서는 오히려 속도를 늦출 수 있습니다.

사용 중에는 무엇을 예상해야 하나요?

파괴적인 명령 직전 경고와, 허용된 디렉터리 밖으로 나가는 편집이나 쓰기 전에 확인 절차가 있다고 예상하면 됩니다. 작업이 설정된 경계를 벗어나면, 워크플로는 무작정 계속되지 않고 멈춰야 합니다.

guard skill 개선 방법

실행 전에 범위를 더 좁히기

가장 큰 품질 향상은 정확한 디렉터리, 파일, 원하는 결과를 지정하는 데서 나옵니다. “apps/web/src/에서만 auth migration을 고쳐줘”는 “앱을 더 안전하게 만들어줘”보다 훨씬 나은 결과를 냅니다. skill이 올바른 freeze 경계를 적용할 수 있기 때문입니다.

안전한 변경과 위험한 변경을 분리하기

워크플로에 일상적인 편집과 위험한 작업이 함께 있다면, 에이전트에게 별도로 나눠 처리하라고 요청하세요. 예를 들어 먼저 읽기 전용 점검과 계획을 요청하고, 그다음 최소한의 쓰기 범위를 승인한 뒤, 파괴적인 작업은 확인 후에만 처리하게 하면 됩니다. 이렇게 해야 guard skill의 동작을 검증하기가 훨씬 쉬워집니다.

경계 불일치를 확인하기

가장 흔한 실패는 너무 넓은 작업 설명이 freeze 범위와 충돌하는 경우입니다. 에이전트가 계속 멈춘다면 대상 경로를 더 좁히거나, 의도한 파일이 보호 영역 안에 분명히 들어가도록 요청 문구를 다시 쓰세요.

명시적인 가드레일로 반복 조정하기

첫 실행 후에는 보호해야 할 정확한 명령, 폴더, 실패 조건을 프롬프트에 반영해 다듬으세요. guard는 반복적으로 조정할수록 더 좋아집니다. 제한과 승인 규칙을 구체적으로 적을수록 skill이 추측해야 할 부분은 줄고, 자동화의 신뢰성은 더 높아집니다.

평점 및 리뷰

아직 평점이 없습니다
리뷰 남기기
이 스킬의 평점과 리뷰를 남기려면 로그인하세요.
G
0/10000
최신 리뷰
저장 중...