코드 리뷰 스킬

WCAG 2.2 지침에 따라 웹 접근성을 감사하고 개선합니다. "접근성 개선", "a11y 감사", "WCAG 준수", "스크린 리더 지원", "키보드 탐색", "접근 가능하게 만들기"와 같은 요청이 있을 때 사용하세요.

딥러닝 연구 저장소를 위한 Rigor Analyze / Rigor Audit 읽기 전용 스킬입니다. 사용자가 저장소를 읽고 이해하거나, 모델 구조 및 학습/추론 진입점을 검사하거나, 설정 및 삽입 지점을 검토하거나, 코드 수정이나 무거운 작업 실행 없이 의심스러운 구현 패턴을 식별하려 할 때 사용하세요. 활성 명령 실행, 광범위한 리팩토링, 추측성 코드 적용, 자동 버그 수정에는 사용하지 마십시오.

Angular 코드를 생성하고 아키텍처 지침을 제공합니다. 프로젝트, 컴포넌트 또는 서비스를 생성할 때, 또는 반응성(시그널, linkedSignal, resource), 폼, 의존성 주입, 라우팅, SSR, 접근성(ARIA), 애니메이션, 스타일링(컴포넌트 스타일, Tailwind CSS), 테스팅, CLI 도구 사용에 대한 모범 사례를 다룰 때 트리거됩니다.

최신 웹 개발 모범 사례를 보안, 호환성 및 코드 품질에 적용합니다. "모범 사례 적용", "보안 감사", "코드 현대화", "코드 품질 검토" 또는 "취약점 확인"을 요청받을 때 사용하세요.

We need to translate the given text from English to Korean. The text describes a decision guide for delegating to caveman-style subagents. It mentions specific names: cavecrew-investigator, cavecrew-builder, cavecrew-reviewer, and cavecrew. Also mentions "Explore" (likely a tool or function). The instruction says to preserve product names, protocol names, URLs, numbers, and technical terms. So we keep "cavecrew", "cavecrew-investigator", "cavecrew-builder", "cavecrew-reviewer", "Explore", "~60%", and "delegate to subagent", "use cavecrew", "spawn..." as is. The rest should be translated naturally. We need to output only the translated text, no extra commentary or labels. The source text is inside <text> tags, but we only output the translation. Let's translate: "Decision guide for delegating to caveman-style subagents." -> "원시인 스타일의 하위 에이전트에 위임하기 위한 결정 가

초압축 커밋 메시지 생성기. 커밋 메시지에서 노이즈를 줄이면서 의도와 이유를 보존합니다. Conventional Commits 형식. 제목 50자 이내, "이유"가 명확하지 않을 때만 본문 포함. 사용자가 "커밋 작성", "커밋 메시지", "커밋 생성", "/commit"을 말하거나 /caveman-commit을 호출할 때 사용. 변경 사항을 스테이징할 때 자동 트리거됩니다.

초압축 코드 리뷰 코멘트. PR 피드백에서 잡음을 줄이고 실행 가능한 신호를 유지합니다. 각 코멘트는 한 줄로 구성: 위치, 문제, 수정. 사용자가 "이 PR 리뷰해줘", "코드 리뷰", "diff 리뷰", "/review"라고 말하거나 /caveman-review를 호출할 때 사용됩니다. 풀 리퀘스트를 리뷰할 때 자동으로 트리거됩니다.

코드 diff, PR, 이슈 큐, 릴리스 준비 상태, 커밋, 푸시, 퍼블리싱 및 프로젝트 감사를 검토합니다. 사용자가 review/看看代码/合并前/看看issue/PR/release/push를 요청하거나 승인된 계획을 실행할 때 사용하며, 더티 및 추적되지 않은 작업 트리에 대한 안전 장치가 포함됩니다. 아이디어 탐색, 근본 원인 디버깅 또는 산문 검토에는 사용하지 않습니다.

PR의 구현을 spec_context.md에 있는 사양 컨텍스트와 비교하고, 중요한 불일치 사항을 review.json에 반영합니다. 승인되었거나 저장소 사양 컨텍스트를 사용할 수 있는 PR 리뷰 시 사용하세요.

고정된 지점(커밋, 브랜치, 태그, 또는 머지 베이스) 이후의 변경 사항을 두 가지 축(Standards: 코드가 이 저장소의 문서화된 코딩 표준을 따르는가? Spec: 코드가 원래 이슈/PRD에서 요청한 내용과 일치하는가?)을 따라 검토합니다. 두 검토를 병렬 하위 에이전트에서 실행하고 나란히 보고합니다. 사용자가 브랜치, PR, 작업 중인 변경 사항을 검토하거나 "X 이후 검토"를 요청할 때 사용하세요.

다축 코드 리뷰를 수행합니다. 변경 사항을 병합하기 전에 사용하세요. 자신, 다른 에이전트 또는 사람이 작성한 코드를 검토할 때 사용하세요. 코드가 메인 브랜치에 들어가기 전에 여러 차원에서 코드 품질을 평가해야 할 때 사용하세요.

코드를 명확하게 단순화합니다. 동작을 변경하지 않고 코드를 명확하게 리팩토링할 때 사용합니다. 코드가 작동하지만 읽기, 유지보수 또는 확장이 어려울 때 사용합니다. 불필요한 복잡성이 축적된 코드를 검토할 때 사용합니다.

깊은 모듈 설계를 위한 공유 어휘입니다. 사용자가 모듈의 인터페이스를 설계하거나 개선하고, 심화 기회를 찾고, 분할 지점을 결정하며, 코드를 더 테스트 가능하거나 AI가 탐색하기 쉽게 만들고자 할 때, 또는 다른 스킬이 깊은 모듈 어휘를 필요로 할 때 사용합니다.

Conventional Commits v1.0.0 브랜치 명명, 워크트리 명명, GitHub 및 GitLab 프로젝트를 위한 커밋 메시지 표준입니다. 브랜치 생성, 워크트리 명명, 커밋 작성, 커밋 메시지 생성, 브랜치 규칙 검토, 체인지로그 자동화 설정 시 사용합니다. 프로젝트에 일관된 Git 히스토리, SemVer 기반 릴리스, 파싱 가능한 체인지로그 생성, 자동 이슈 종료가 필요할 때 적용합니다. 사용자가 워크트리 명명 방법, Git 워크트리 생성 방법 등을 물을 때 트리거됩니다.

현재 브랜치를 warp 저장소에 풀 리퀘스트로 생성합니다. 사용자가 PR 열기, 풀 리퀘스트 생성, 리뷰를 위한 변경 제출, 또는 병합을 위한 코드 준비를 언급할 때 사용하세요.

체계적인 근본 원인 디버깅을 안내합니다. 테스트가 실패하거나, 빌드가 깨지거나, 동작이 예상과 다르거나, 예상치 못한 오류가 발생할 때 사용하세요. 추측보다는 근본 원인을 찾고 수정하는 체계적인 접근 방식이 필요할 때 사용하세요.

사용 중단 및 마이그레이션을 관리합니다. 오래된 시스템, API 또는 기능을 제거할 때 사용합니다. 사용자를 한 구현에서 다른 구현으로 마이그레이션할 때 사용합니다. 기존 코드를 유지할지 중단할지 결정할 때 사용합니다.

어려운 버그와 성능 회귀를 위한 체계적인 진단 루프입니다. 재현 → 최소화 → 가설 수립 → 계측 → 수정 → 회귀 테스트 순서로 진행됩니다. 사용자가 "이것을 진단해줘" / "이것을 디버깅해줘"라고 말하거나, 버그를 보고하거나, 무언가 고장났다/예외를 던진다/실패한다고 말하거나, 성능 회귀를 설명할 때 사용합니다.

하드 버그 및 성능 회귀를 위한 진단 루프입니다. 사용자가 "진단해줘"/"디버그해줘"라고 말하거나, 무언가 고장/예외/실패/느림을 보고할 때 사용하세요.

별도 세션에서 검토 체크포인트와 함께 실행할 서면 구현 계획이 있을 때 사용합니다.

We need to translate the given English text into Korean, preserving the name 'explore-code' if it appears. The text is a description of a skill. The instruction says: "Translate only the text inside <text>. Do not include the name unless it appears in the source text." The name 'explore-code' does not appear in the source text. So we just translate the description. Also, preserve product names, protocol names, URLs, numbers, technical terms. The text has terms like 'leaf skill', 'auditable candidate implementation', 'deep learning research repositories', 'LoRA', 'adapter layers', 'explore_outputs/', 'end-to-end exploration orchestration', 'current_research'. These should be preserved as is or translated appropriately? The instruction says "preserve product names, protocol names, URLs, numbers, and technical terms." So technical terms like 'LoRA', 'adapter layers', 'backbone', 'head' should be kept as is or maybe translated if common? But 'LoRA' is a proper name, keep. 'ad

Fastify Node.js 백엔드 서버 및 REST API를 TypeScript 또는 JavaScript로 개발하는 방법을 안내합니다. Fastify 애플리케이션을 구축, 구성 또는 디버깅할 때 사용하세요. 여기에는 라우트 정의, 플러그인 구현, JSON Schema 검증 설정, 오류 처리, 성능 최적화, 인증 관리, CORS 및 보안 헤더 구성, 데이터베이스 통합, WebSocket 작업, 프로덕션 배포가 포함됩니다. Fastify의 전체 요청 수명 주기(훅,...)를 다룹니다.

구현이 완료되고 모든 테스트가 통과했을 때, 작업을 통합할 방법을 결정해야 하는 경우 사용 - 병합, PR, 정리 중 구조화된 옵션을 제시하여 개발 작업 완료를 안내합니다.

warp Rust 코드베이스의 컴파일 오류, 린팅 문제, 테스트 실패를 수정합니다. presubmit 검사, WASM 관련 오류, 특정 테스트 실행을 포함합니다. 사용자가 빌드 오류, clippy 또는 fmt 실패, 테스트 실패를 겪거나 PR 전에 presubmit을 실행하거나 해석해야 할 때 사용하세요.

기본 LLM 잘림 동작을 재정의합니다. 완전한 코드 생성을 강제하고, 플레이스홀더 패턴을 금지하며, 토큰 제한 분할을 깔끔하게 처리합니다. 철저하고 축약되지 않은 출력이 필요한 모든 작업에 적용하십시오.

git 워크플로우 관행을 구조화합니다. 코드 변경 시 사용합니다. 커밋, 브랜칭, 충돌 해결 시 또는 여러 병렬 스트림에서 작업을 구성해야 할 때 사용합니다. 릴리스를 생성하거나, 시맨틱 버전 범프를 선택하거나, 태깅하거나, 체인지로그를 작성할 때 사용합니다.

Golang 벤치마킹, 프로파일링 및 성능 측정. Go 벤치마크를 작성, 실행 또는 비교하거나, pprof로 핫 경로를 프로파일링하고, CPU/메모리/트레이스 프로파일을 해석하며, benchstat로 결과를 분석하고, CI 벤치마크 회귀 탐지를 설정하거나, Prometheus 런타임 메트릭으로 프로덕션 성능을 조사할 때 사용합니다. 또한 개발자가 특정 성능 지표에 대한 심층 분석이 필요할 때 사용합니다 - 이 스킬은 측정 방법론을 제공하며...

We need to translate the given text from English to Korean, preserving the specified name "golang-code-style" and other technical terms. The instruction says to translate only the text inside <text>, and not include the name unless it appears in the source text. The name "golang-code-style" appears in the source? Actually, the source text does not contain "golang-code-style" explicitly; it's the directory item name. The instruction says "Do not include the name unless it appears in the source text." So we should not add it. The source text has references to other skills like "samber/cc-skills-golang@golang-naming" etc. Those should be preserved as is. We need to translate the description of the skill. The text describes what the skill is about: Go code style conventions, line length, variable declarations, etc. And it says when to use it and what it's not for, with cross-references. We'll produce a natural Korean translation. Keep technical terms like "Go", "linter", "doc comments" as is

Go 언어 동시성 패턴. 고루틴, 채널, select, 락, 동기화 기본 요소, errgroup, singleflight, 워커 풀, 팬아웃/팬인 파이프라인을 포함한 동시성 Go 코드를 작성하거나 검토할 때 사용합니다. 또한 고루틴 누수, 경쟁 조건, 채널 소유권 문제를 감지하거나 채널과 뮤텍스 중에서 선택해야 할 때도 활성화됩니다.

Golang에서 의존성 주입(DI)에 대한 종합 가이드입니다. DI가 중요한 이유(테스트 용이성, 느슨한 결합, 관심사 분리, 생명주기 관리), 수동 생성자 주입, DI 라이브러리 비교(google/wire, uber-go/dig, uber-go/fx, samber/do)를 다룹니다. 서비스 아키텍처 설계, 의존성 주입 설정, 강하게 결합된 코드 리팩토링, 싱글톤 또는 서비스 팩토리 관리 시, 또는 사용자가 제어 역전, 서비스...에 대해 질문할 때 이 스킬을 사용하세요.

관용적인 Golang 디자인 패턴 — 함수형 옵션, 생성자, 오류 흐름 및 연쇄, 리소스 관리 및 생명주기, 정상 종료, 복원력, 아키텍처, 의존성 주입, 데이터 처리, 스트리밍 등. 아키텍처 패턴을 명시적으로 선택할 때, 함수형 옵션을 구현할 때, 생성자 API를 설계할 때, 정상 종료를 설정할 때, 복원력 패턴을 적용할 때, 또는 특정 문제에 맞는 관용적인 Go 패턴을 질문할 때 적용하세요.

Golang 프로젝트를 위한 포괄적인 문서 가이드로, godoc 주석, README, CONTRIBUTING, CHANGELOG, Go Playground, Example 테스트, API 문서, llms.txt를 다룹니다. 문서 주석이나 문서를 작성하거나 검토할 때, 코드 예제를 추가할 때, 문서 사이트를 설정할 때, 또는 문서 모범 사례에 대해 논의할 때 사용합니다. 라이브러리와 애플리케이션/CLI 모두에 적용됩니다.

관용적인 Golang 오류 처리 — 생성, %w를 사용한 래핑, errors.Is/As, errors.Join, 사용자 정의 오류 타입, 센티널 오류

We need to translate the given English text into Korean, preserving specific terms like "golang-google-wire" (but it's not in the text, only in the instruction). The text is about compile-time dependency injection in Golang using google/wire. We must not include the name unless it appears in the source text. The source text includes "google/wire", "wire.NewSet", etc. We need to translate the description naturally while keeping technical terms like "wire.NewSet", "wire.Build", etc. as they are. Also preserve URLs? There is no URL. Numbers? None. Technical terms: "compile-time dependency injection", "Golang", "google/wire", "wire.NewSet", "wire.Build", "wire.Bind", "interface→concrete", "wire.Struct", "wire.Value", "wire.InterfaceValue", "wire.FieldsOf", "cleanup functions", "//go:build wireinject injector files", "generated wire_gen.go", "runtime DI with reflection". Also the last part "see

gRPC 사용 지침, protobuf 구성, Golang 마이크로서비스를 위한 프로덕션 준비 패턴을 제공합니다. gRPC 서버/클라이언트 구현, 검토, 디버깅, proto 파일 작성, 인터셉터 설정, 상태 코드로 gRPC 오류 처리, TLS/mTLS 구성, bufconn으로 테스트, 스트리밍 RPC 작업 시 사용하세요.

Golang 스킬 오케스트레이터 — 모든 Golang 코딩, 리뷰, 디버그 또는 설정 작업에서 항상 활성화됩니다. 작업 컨텍스트를 읽고 samber/cc-skills-golang에서 가장 관련성 높은 스킬을 로드하며, 종종 여러 개를 동시에 로드합니다: gRPC 서비스 작성 시 golang-grpc + golang-testing + golang-error-handling 로드; 패닉 디버깅 시 golang-troubleshooting + golang-safety 로드; 보안 감사 시 golang-security + golang-lint + golang-safety 로드. 또한: 두 스킬이 겹치는 것으로 보일 때 경쟁 클러스터를 명확히 구분합니다...

Golang 프로젝트를 위한 린팅 모범 사례와 golangci-lint 설정 — 린터 실행, .golangci.yml 구성, nolint 지시어로 경고 억제, 린트 출력 해석, 린터 선택. golangci-lint를 구성할 때, 린트 경고나 nolint 억제에 대해 질문할 때, 코드 품질 도구를 설정할 때, 또는 린터를 선택할 때 사용합니다. 또한 사용자가 golangci-lint, go vet, staticcheck, revive를 언급할 때 사용합니다.

golang-linter — AI 에이전트를 위한 설치 가능한 스킬입니다.

Go 코드를 최신 언어 기능, 표준 라이브러리 개선 사항, 관용적 패턴을 사용하도록 현대화합니다. Go 코드를 작성하거나 검토할 때 구식 패턴이 감지되거나, 사용 중단 경고가 발생하면 사전에 트리거됩니다. 또한 사용자가 명시적으로 현대화, Go 버전 업그레이드, 또는 CI/도구 새로고침을 요청할 때도 사용됩니다.

Go (Golang) 네이밍 규칙 — 패키지, 생성자, 구조체, 인터페이스, 상수, 열거형, 오류, 불리언, 리시버, 게터/세터, 함수형 옵션, 약어, 테스트 함수, 서브테스트 이름을 다룹니다. 새 Go 코드를 작성하거나, 코드 리뷰 또는 리팩토링 시, 네이밍 대안(New vs NewTypeName, isConnected vs connected, ErrNotFound vs NotFoundError, iota 0에서 StatusReady vs StatusUnknown) 중 선택하거나, Go 패키지 이름(utils/helpers 안티패턴)을 논의할 때 이 스킬을 사용하세요.

Golang 성능 최적화 패턴 및 방법론 - X 병목이 발생하면 Y를 적용. 할당 감소, CPU 효율성, 메모리 레이아웃, GC 튜닝, 풀링, 캐싱, 핫패스 최적화를 다룹니다. 프로파일링이나 벤치마크에서 병목이 확인되어 이를 해결할 적절한 최적화 패턴이 필요할 때 사용합니다. 또한 성능 코드 리뷰 시 개선 사항이나 빠른 성능 향상을 식별하는 데 도움이 될 벤치마크를 제안할 때 사용합니다. 측정 방법론에는 해당하지 않습니다(→...

프로덕션에 적합한 Golang 라이브러리와 프레임워크를 추천합니다. 사용자가 명시적으로 라이브러리 제안을 요청하거나, 대안을 비교하려 하거나, 특정 작업에 맞는 라이브러리를 선택해야 하거나, 프로젝트에 새 종속성을 추가할 때 적용하세요.

방어적 Golang 코딩으로 패닉, 무음 데이터 손상, 미묘한 런타임 버그를 방지합니다. nil 패닉, append 앨리어싱, 맵 동시 접근, 부동소수점 비교 함정, 제로값 설계 질문을 마주할 때 사용합니다. 또한 nil 안전성, 숫자 변환 오버플로우, 리소스 생명주기 문제(루프 내 defer), 슬라이스와 맵의 방어적 복사를 위해 코드를 검토할 때도 사용합니다.

Golang에서 samber/do를 사용한 의존성 주입 — 서비스 컨테이너, 생명주기 관리, 스코프, 헬스 체크, 정상 종료, 모듈 구성. samber/do를 사용하거나 도입할 때, 코드베이스가 github.com/samber/do 또는 github.com/samber/do/v2를 임포트할 때, 또는 수동 생성자 주입을 DI 컨테이너로 리팩토링할 때 적용하십시오.

Golang에서 samber/mo

Golang의 보안 모범 사례와 취약점 방지. 인젝션(SQL, 명령어, XSS), 암호화, 파일 시스템 안전, 네트워크 보안, 쿠키, 비밀 관리, 메모리 안전, 로깅을 다룹니다. 보안을 위해 Go 코드를 작성, 검토 또는 감사할 때, 또는 암호화, I/O, 비밀 관리, 사용자 입력 처리, 인증과 관련된 위험한 코드 작업 시 적용하세요. 보안 도구 구성도 포함됩니다.

Golang 설정 라이브러리로 spf13/viper 사용 — 계층적 우선순위 (플래그 > 환경변수 >

stretchr/testify를 사용한 Golang 테스트에 대한 종합 가이드입니다. assert, require, mock, suite 패키지를 심층적으로 다룹니다. testify로 테스트를 작성하거나, 모킹을 생성하거나, 테스트 스위트를 설정하거나, assert와 require 중에서 선택할 때 사용하세요. testify 어서션, 모크 기대값, 인자 매처, 호출 검증, 스위트 생명주기, Eventually, JSONEq, 사용자 정의 매처와 같은 고급 패턴을 다룹니다. 코드베이스가 github.com/stretchr/testify를 임포트할 때 적용하세요.

Golang 구조체와 인터페이스 디자인 패턴 — 컴포지션, 임베딩, 타입 어서션, 타입 스위치, 인터페이스 분리, 인터페이스를 통한 의존성 주입, 구조체 필드 태그, 포인터 리시버와 값 리시버. Go 타입을 설계하거나, 인터페이스를 정의 또는 구현하거나, 구조체나 인터페이스를 임베딩하거나, 타입 어서션이나 타입 스위치를 작성하거나, JSON/YAML/DB 직렬화를 위한 구조체 필드 태그를 추가하거나, 포인터 리시버와 값 리시버 중 선택할 때 이 스킬을 사용하세요. 또한 사용자가...

We need to translate the given text from English to Korean, preserving the name "golang-testing" if it appears. The text is a description of a skill for Go testing. The instruction says to translate only the text inside <text>, and not include the name unless it appears in the source text. The name "golang-testing" does not appear in the source text, so we don't include it. We must preserve product names, protocol names, URLs, numbers, technical terms. So terms like "table-driven tests", "testify suites", "mocks", "parallel tests", "fuzzing", "fixtures", "goroutine leak detection", "goleak", "snapshot testing", "code coverage", "integration tests", "idiomatic test naming", "Go test CI", "flaky/slow tests", "samber/cc-skills-golang@golang-stretchr-testify", "measurement methodology" should be kept as is or translated appropriately? The instruction says "preserve product names, protocol names, URLs, numbers,

이 스킬은 사용자가 "에이전트 코드 작성", "ADK로 에이전트 구축", "도구 추가", "콜백 생성", "에이전트 정의", "상태 관리 사용"을 원하거나 ADK(Agent Development Kit) Python API 패턴 및 코드 예제가 필요할 때 사용해야 합니다. Google ADK 스킬 제품군의 일부입니다. 에이전트 유형, 도구 정의, 오케스트레이션 패턴, 콜백 및 상태 관리에 대한 빠른 참조를 제공합니다. 새 프로젝트 생성(google-agents-cli-scaffold 사용) 또는 배포에는 사용하지 마십시오...

예산을 고려한 에이전트 지원 엔지니어링 상태 점검을 실행하여 명령어/설정 드리프트, 후크/MCP, 검증기 표면, AI 유지보수성을 확인합니다. 사용자가 클로드 확인/코덱스 확인/파이 확인/설정 확인/상태 점검을 요청하거나 에이전트가 명령어를 무시하거나 검증이 누락되거나 코드 유지보수가 어려워진다고 보고할 때 사용합니다. 코드 디버깅이나 PR 검토에는 사용하지 않습니다.

오류, 크래시, 회귀, 실패하는 테스트, 비정상 동작, 스크린샷으로 보고된 결함에 대해 수정을 적용하기 전에 근본 원인을 찾습니다. 사용자가 排查/报错/崩溃/不工作/回归/判断为什么报错를 요청하거나, 예전에는 작동했는데 지금은 실패한다고 말할 때 사용하세요. 코드 리뷰나 새로운 기능에는 적합하지 않습니다.

레지스트리 블록과 컴포넌트를 HyperFrames 구성에 설치하고 연결합니다. hyperframes add 실행 시, 블록이나 컴포넌트 설치 시, 설치된 항목을 index.html에 연결할 때, 또는 hyperframes.json 작업 시 사용합니다. add 명령어, 설치 위치, 블록 하위 구성 연결, 컴포넌트 스니펫 병합, 레지스트리 검색, 그리고 업스트림에 기여할 새 블록이나 컴포넌트 작성(아이디어 → 스캐폴드 → 검증 → PR)을 다룹니다.

PRD 또는 이슈 세트를 기반으로 작업을 구현합니다.

승인된 PRODUCT.md와 TECH.md의 기능을 구현하며, 구현이 진행됨에 따라 사양과 코드를 동일한 PR에서 일관되게 유지합니다. 제품 및 기술 사양이 승인되고 다음 단계가 기능 구축일 때 사용하세요.

시니어 어드바이저로서 모든 코드베이스를 조사하고, 다른 모델/에이전트가 실행할 수 있도록 우선순위가 지정된 독립적인 구현 계획을 생성합니다. 소스 코드에 대해 엄격히 읽기 전용이며, 스스로 구현, 수정, 리팩터링하지 않습니다. 코드베이스를 감사하거나, 개선 기회(버그, 보안, 성능, 테스트 커버리지, 기술 부채, 마이그레이션, 개발자 경험)를 찾거나, 기능을 제안하거나, 프로젝트의 다음 방향(로드맵, 제품 방향)을 제시하거나, 다른 에이전트를 위한 핸드오프 계획을 생성하도록 요청받을 때 사용합니다.

코드베이스에서 심화 개선 기회를 찾되, CONTEXT.md의 도메인 언어와 docs/adr/의 결정 사항을 참고합니다. 사용자가 아키텍처를 개선하거나, 리팩토링 기회를 찾거나, 강하게 결합된 모듈을 통합하거나, 코드베이스를 더 테스트 가능하고 AI가 탐색하기 쉽게 만들고자 할 때 사용합니다.

React 프로젝트와 컴포넌트를 Radix UI에서 Base UI로 마이그레이션합니다. radix에서 마이그레이션, base-ui로 이동, radix 프리미티브 변환, 또는 shadcn 프로젝트의 기본 라이브러리 전환 요청 시 사용합니다. 단일 컴포넌트("accordion 마이그레이션")와 전체 프로젝트를 처리합니다.

Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

We need to translate the given English text into Korean. The instruction says: "Translate only the text inside <text>. Do not include the name unless it appears in the source text." The name "minimal-run-and-audit" is not inside the <text> tag, so we should not include it. The text inside <text> is a description of a skill. We need to preserve product names, protocol names, URLs, numbers, technical terms. The text includes "Rigor Run skill", "README-first deep learning repo reproduction", "smoke test", "inference", "evaluation command", "repro_outputs/", "patch notes", etc. These should be preserved as is or translated appropriately? The instruction says "preserve product names, protocol names, URLs, numbers, and technical terms." "Rigor Run" might be a product name? It says "Rigor Run skill" - likely a proper name. "README-first" is a concept. "deep learning" is a technical term. "repo reproduction" - repo is short for repository

Nx 워크스페이스를 탐색하고 이해합니다. 워크스페이스, 프로젝트 또는 작업에 대한 질문에 답할 때 사용하세요. nx 명령이 실패하거나 작업을 실행하기 전에 사용 가능한 대상/구성을 확인해야 할 때도 사용하세요. 예: '이 워크스페이스에 어떤 프로젝트가 있나요?', '프로젝트 X는 어떻게 구성되어 있나요?', '라이브러리 Y에 의존하는 것은 무엇인가요?', '실행할 수 있는 대상은 무엇인가요?', '작업 구성을 찾을 수 없음', 'nx 작업 실패 디버깅'.

실제로 작동하는 가장 게으른 해결책을 강제하며, 가장 단순하고, 가장 짧고, 가장 최소한으로 만듭니다. 모든 것을 경험한 시니어 개발자의 사고방식을 따릅니다: 작업 자체가 존재해야 하는지 의문을 제기하고(YAGNI), 커스텀 코드보다 표준 라이브러리를 먼저 사용하며, 의존성보다 네이티브 플랫폼 기능을 우선시하고, 50줄보다 한 줄을 선택합니다. 강도 수준을 지원합니다: 라이트, 풀(기본값), 울트라. 사용자가 "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less" 등을 말할 때마다 사용합니다.

전체 저장소를 대상으로 과도한 엔지니어링을 감사합니다. ponytail-review와 유사하지만, diff 대신 전체 코드베이스를 스캔하여 삭제, 단순화 또는 표준 라이브러리/네이티브 대체가 가능한 항목을 순위별로 제시합니다. 사용자가 "이 코드베이스 감사", "과도한 엔지니어링 감사", "이 저장소에서 삭제할 항목", "블로트 찾기", "ponytail-audit", 또는 "/ponytail-audit"이라고 말할 때 사용합니다. 일회성 보고서를 생성하며, 수정 사항을 적용하지는 않습니다.

Harvest every `ponytail:` comment in the codebase into a debt ledger, so the deliberate shortcuts and deferrals ponytail leaves behind get tracked instead of rotting into "later means never". Use when the user says "ponytail debt", "/ponytail-debt", "what did ponytail defer", "list the shortcuts", "ponytail ledger", or "what did we mark to do later". One-shot report, changes nothing.

코드 리뷰가 과도한 엔지니어링에만 집중합니다. 삭제할 항목을 찾습니다: 재발명된 표준 라이브러리, 불필요한 의존성, 추측성 추상화, 죽은 유연성. 발견 항목당 한 줄: 위치, 삭제할 내용, 대체할 내용. 사용자가 "과도한 엔지니어링 리뷰", "무엇을 삭제할 수 있나요", "이건 과도하게 엔지니어링되었나요", "간소화 리뷰"라고 말하거나 /ponytail-review를 호출할 때 사용합니다. 정확성 중심 리뷰를 보완하며, 이 리뷰는 복잡성만 추적합니다.

pr-to-video 워크플로우 - GitHub 풀 리퀘스트 (github.com/ / /pull/ 또는 / # 형식의 URL, 또는 체크아웃된 저장소의 "this PR") -> 수집된 PR 정보 (제목, 본문, diff, 커밋, 파일, +/- 통계) -> narrator_scripts.json + 오디오 (음성 + 배경음악) + section_plan.md -> 코드 diff / 변경 전후 / 영향 설명 영상. 입력은 코드 변경입니다. URL은 PR 링크이며, 마케팅 사이트를 스크래핑하는 대상이 아닙니다. 텍스트 브리핑이나 제품 웹사이트도 아닙니다. PR이 아닌 입력(제품 사이트, 일반 웹사이트, 주제 텍스트)의 경우...

정적 인터랙티브 D3 워크스루를 생성하여 풀 리퀘스트를 시각화합니다. 사용자가 확대/축소 가능한 PR 맵, 그래프/캔버스 PR 오리엔테이션, 또는 PR 시스템 구성 요소, 데이터 흐름, 코드 종속성, 사용자 액션의 대체 시각화를 원할 때 사용합니다.

사용자가 대화형으로 버그나 문제를 보고하면 에이전트가 GitHub 이슈를 등록하는 대화형 QA 세션입니다. 배경에서 코드베이스를 탐색하여 맥락과 도메인 언어를 파악합니다. 사용자가 버그를 보고하거나, QA를 수행하거나, 대화형으로 이슈를 등록하거나, "QA 세션"을 언급할 때 사용하세요.

코드 리뷰 피드백을 받고 제안을 구현하기 전에 사용하며, 특히 피드백이 불명확하거나 기술적으로 의심스러운 경우에 적합합니다. 기술적 엄격함과 검증이 필요하며, 형식적인 동의나 맹목적인 구현이 아닌 실제 검토를 요구합니다.

기존 웹사이트와 앱을 프리미엄 품질로 업그레이드합니다. 현재 디자인을 감사하고, 일반적인 AI 패턴을 식별하며, 기능을 손상시키지 않으면서 고급 디자인 표준을 적용합니다. 모든 CSS 프레임워크 또는 바닐라 CSS와 함께 작동합니다.

사용자 인터뷰를 통해 작은 커밋 단위의 상세한 리팩터 계획을 수립한 후, 이를 GitHub 이슈로 등록합니다. 사용자가 리팩터를 계획하거나, 리팩터링 RFC를 작성하거나, 리팩터를 안전한 점진적 단계로 나누고자 할 때 사용하세요.

작업 완료, 주요 기능 구현 시, 또는 병합 전에 요구 사항을 충족하는지 확인할 때 사용합니다.

Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context. Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts, when `git status` shows unmerged paths, or when files contain conflict markers.

진행 중인 git 병합/리베이스 충돌을 해결해야 할 때 사용합니다.

고정된 시점(커밋, 브랜치, 태그, 또는 병합 기준) 이후의 변경 사항을 두 가지 축(표준: 코드가 이 저장소의 문서화된 코딩 표준을 따르는가?, 사양: 코드가 원래 이슈/PRD에서 요청한 내용과 일치하는가?)을 따라 검토합니다. 두 검토를 병렬 하위 에이전트에서 실행하고 나란히 보고합니다. 사용자가 브랜치, PR, 작업 중인 변경 사항을 검토하거나 "X 이후 검토"를 요청할 때 사용하세요.

풀 리퀘스트 diff를 검토하고, 워크플로우가 게시할 수 있도록 구조화된 피드백을 review.json에 작성합니다. 로컬 아티팩트(예: pr_diff.txt, pr_description.txt)에서 체크아웃된 PR을 검토하고, GitHub에 직접 게시하는 대신 기계가 읽을 수 있는 리뷰 출력을 생성할 때 사용합니다.

딥러닝 연구 작업을 위한 엄격한 디버그/엄격한 감사 스킬입니다. 사용자가 트레이스백, 터미널 오류, CUDA OOM, 체크포인트 로드 실패, 형태 불일치, NaN 손실 증상 또는 훈련 실패를 붙여넣고 패치 전에 보수적인 진단을 원하며 디버그 수정이 연구 기여와 명확히 분리되어야 할 때 사용하세요. 광범위한 리팩토링, 추측성 적응, 자동 탐색적 패치 또는 일반적인 저장소 숙지에는 사용하지 마십시오.

현재 리포지토리에 Husky pre-commit 훅을 lint-staged(Prettier), 타입 체크, 테스트와 함께 설정합니다. 사용자가 pre-commit 훅을 추가하거나, Husky를 설정하거나, lint-staged를 구성하거나, 커밋 시 포맷팅/타입체크/테스트를 추가하려 할 때 사용하세요.

snyk-agent-scan — 에이전트 스킬 파일 스캐너 — 의 규정 준수 전문가입니다. 다른 Snyk CLI 도구(snyk test, snyk code SAST, snyk iac, snyk container)에는 해당되지 않습니다. 정보를 억제하거나 삭제하지 않고 콘텐츠 재구성을 통해 알림을 수정합니다. 스킬 디렉토리의 모든 파일(SKILL.md, references/, assets/, 모든 보조 마크다운)을 다룹니다. 새 스킬을 작성하거나, 기존 스킬을 편집하거나, 로컬 또는 CI에서 실패한 snyk-agent-scan 실행을 분류하거나, 에이전트에 의해 보류된 PR을 해제할 때 적용하세요...

모든 구현 결정을 공식 문서에 근거합니다. 권위 있는 출처가 인용된 코드로, 구식 패턴 없이 작업하려 할 때 사용하세요. 정확성이 중요한 프레임워크나 라이브러리로 구축할 때 사용하세요.

버그, 테스트 실패, 예상치 못한 동작을 발견했을 때, 수정을 제안하기 전에 사용하세요

기능 구현이나 버그 수정 시, 구현 코드를 작성하기 전에 사용

TypeScript의 고급 타입 시스템을 마스터하세요. 제네릭, 조건부 타입, 매핑된 타입, 템플릿 리터럴, 유틸리티 타입을 포함하여 타입 안전한 애플리케이션을 구축할 수 있습니다. 복잡한 타입 로직을 구현하거나, 재사용 가능한 타입 유틸리티를 만들거나, TypeScript 프로젝트에서 컴파일 타임 타입 안전성을 보장할 때 사용하세요.

브랜치나 풀 리퀘스트 구현이 도입된 제품, 기술, 보안 및 관련 사양과 일치하는지 검증합니다. 사양 기반 변경 사항을 검토하거나 완료할 때, 그리고 체크인된 사양과 구현 간의 불일치를 해결할 때 사용합니다.

작업 완료, 수정 완료, 또는 통과를 주장하기 전, 커밋이나 PR을 생성하기 전에 사용 - 성공을 주장하기 전에 검증 명령을 실행하고 출력을 확인해야 함; 주장보다 항상 증거가 우선