check

check skill 개요

check skill이 하는 일

check skill은 코드 diff, PR, 이슈 트리아지, 릴리스 준비 상태, push, 프로젝트 감사까지 아우르는 리뷰·게이트 워크플로입니다. “이걸 안전하게 배포해도 되는가, 무엇이 깨졌는가, 병합 전에 무엇을 고쳐야 하는가?”에 대해 빠르지만 엄격한 답이 필요한 사용자에게 가장 잘 맞습니다.

check skill에 가장 잘 맞는 경우

check skill은 병합 전, 릴리스 전, 생성된 산출물 검증, 후속 작업 확인처럼 구체적인 변경 집합에 대한 코드 리뷰가 필요할 때 쓰면 좋습니다. 특히 에이전트가 먼저 worktree를 살펴보고, 숨은 로컬 변경을 피하며, 수정 가능한 이슈와 사람의 확인이 필요한 항목을 분리해 주길 원할 때 유용합니다.

check가 다른 점

check skill은 단순한 “이 코드 좀 봐줘” 프롬프트가 아닙니다. 더러운 worktree나 추적되지 않은 worktree에 대한 명시적 안전 게이트, 리뷰 우선의 분명한 워크플로, 아키텍처나 보안 리스크가 보일 때 전문 리뷰로 넘기는 라우팅이 들어 있습니다. 그래서 check for Code Review용 일회성 프롬프트보다 언제 살펴봐야 하는지, 무엇을 살펴봐야 하는지, 언제 멈춰야 하는지에 대한 추측을 줄여 줍니다.

check skill 사용 방법

check 설치와 실행

다음으로 설치합니다:

npx skills add tw93/Waza --skill check

그다음 구체적인 리뷰 대상이 있을 때 실행하세요. 예를 들면 diff, 브랜치, PR, 릴리스 후보, 커밋 범위, 또는 저장소 감사 요청입니다. check usage를 요청할 때는 “최근 3개 커밋을 리뷰해줘”, “머지 전에 이 PR을 확인해줘”, “의존성 업데이트 후 릴리스 준비 상태를 감사해줘”처럼 범위를 분명히 적어 주는 것이 좋습니다.

skill에 맞는 입력을 주기

check에 가장 좋은 입력은 “이거 괜찮아?” 같은 막연한 질문이 아니라, 맥락이 붙은 경계 있는 작업입니다. 좋은 예시는 다음과 같습니다.

• “병합 전에 이 PR에서 보안 및 아키텍처 회귀가 있는지 확인해줘.”
• “현재 worktree를 검토하고 릴리스를 막는 요소가 무엇인지 알려줘.”
• “생성된 파일을 감사하고 소스 변경과 일치하는지 판단해줘.”

브랜치, 커밋 범위, 목표 릴리스, 그리고 “파일은 수정하지 말 것” 또는 “public repo 맥락만 볼 것” 같은 제약도 함께 적어 주세요. 그래야 skill이 지나치게 넓고 모호한 리뷰로 흐르지 않습니다.

먼저 읽어야 할 파일

먼저 SKILL.md를 읽고, 그다음 리뷰 깊이, 전문 라우팅, 릴리스 기대치를 파악하기 위해 references/project-context.md와 references/persona-catalog.md를 확인하세요. diff가 신뢰 경계, API, import, 모듈 구조를 건드린다면 agents/reviewer-security.md와 agents/reviewer-architecture.md를 사용합니다. 이슈나 PR에 대해 유지보수자 후속 응답이 포함되는 워크플로라면 references/public-reply.md도 중요합니다.

실무 워크플로 팁

리뷰 전에 skill은 git status --short --branch -uall로 worktree 안전성 점검을 기대합니다. 더럽거나 추적되지 않은 변경은 리뷰의 의미 자체를 바꿀 수 있기 때문입니다. 더 좋은 check guide 결과를 원한다면, 에이전트가 발견 사항만 보고하면 되는지, 안전한 문제는 직접 고쳐도 되는지, 변경 후 어떤 검증 명령을 써야 하는지도 분명히 알려 주세요.

check skill FAQ

check는 코드 리뷰에만 쓰이나요?

아니요. check skill은 릴리스 준비 상태, push, 배포된 산출물, 이슈 및 PR 트리아지, 저장소 전반 감사까지 다룹니다. 단순히 코드를 읽는 것보다 “배포 직전 판단”이 필요한 작업에 더 잘 맞습니다.

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

열린형 아이디어 탐색, 근본 원인 디버깅, 문장/문체 편집에는 check를 쓰지 마세요. 이 skill은 브레인스토밍이나 서사적 피드백용이 아니라, 구체적인 diff와 운영 리뷰용으로 설계되었습니다.

check는 초보자도 쓰기 쉬운가요?

네, 대상과 결과를 말할 수 있다면 그렇습니다. 초보자는 무엇이 바뀌었는지, 무엇을 리뷰받고 싶은지, 그리고 발견 사항만 원하는지 안전한 수정도 원하는지 정확히 적을 때 가장 좋은 결과를 얻습니다. 그렇지 않으면 check install은 쉬워도 check usage는 너무 넓어져 신뢰하기 어려워집니다.

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

일반 프롬프트는 보통 주관적인 리뷰를 요청합니다. check는 안전 사전 점검, 범위 통제, 검증 기대치, 그리고 보안 또는 아키텍처에 대한 전문 라우팅을 더한 체계적인 경로를 제공합니다. 그래서 즉흥적인 리뷰 요청보다 check for Code Review에 더 안정적으로 쓸 수 있습니다.

check skill 개선 방법

더 촘촘한 리뷰 브리프를 주기

가장 유용한 입력은 무엇이 바뀌었는지, 왜 바뀌었는지, 무엇이 깨지면 안 되는지, 어떤 종류의 리뷰를 원하는지입니다. 예를 들어 “인증 경로만 리뷰해줘”, “릴리스 산출물에 집중해줘”, “이 리팩터링이 public API를 바꾸는지 확인해줘”처럼 적으면 검색 범위가 좁아지고 신호가 좋아집니다.

까다로운 제약을 드러내기

패키징 규칙, 생성 파일, 보호 경로, 필수 검증 명령을 skill에 알려 주세요. 저장소에 빌드나 릴리스의 단일 기준(source of truth)이 있다면 처음부터 명시하는 것이 좋습니다. 그래야 잘못된 자신감을 줄이고, check skill이 드리프트, 누락된 산출물, 위험한 후속 조치를 더 잘 잡아낼 수 있습니다.

칭찬보다 발견 사항을 바탕으로 반복하기

첫 번째 검토 후에는 다시 확인받고 싶은 정확한 발견 사항이나 적용한 패치를 보내세요. 보안, 아키텍처, 릴리스 준비 상태처럼 한 번에 한 가지 위험 영역씩 두고 두 번째 점검을 요청할 때 skill이 더 좋아집니다. 출력이 너무 넓게 느껴진다면 “더 자세히”를 요구하기보다 범위를 좁히는 편이 낫습니다.