gagip
User개발 전용 Claude Code 플러그인
Categories
Indexed Skills (33)
design-md
프로젝트 루트에 DESIGN.md — AI 코딩 에이전트가 UI를 일관되게 만들도록 브랜드의 시각 언어 (컬러·타이포·스페이싱·컴포넌트)를 실행 가능한 결정값으로 박은 "디자인 시스템 SSOT" — 를 생성하는 스킬. 기존 코드베이스를 스캔해 실제 값을 추출(현실 기술)하고, 스캔으로 못 채운 부분만 대화로 보완한다(하이브리드). 코드가 없으면 대화 중심으로 폴백한다. 산출 끝에는 프로젝트 지침 파일에 "UI 생성 전 DESIGN.md 읽기" 참조 줄 추가를 반드시 안내한다(DESIGN.md는 자동 로드되지 않기 때문). 그린필드거나 사용자가 육안검증·공유를 원하면 자기완결 preview.html(스와치·타입스케일·컴포넌트 갤러리, 라이트/다크 토글)을 조건부로 함께 생성한다. "미리보기도 만들어줘", "preview.html", "디자인 시스템 미리보기 페이지" 같은 표현에도 반응한다. 다음 표현이 나오면 반드시 이 스킬을 사용한다: "DESIGN.md 만들어줘", "design.md 생성", "디자인 시스템 문서 만들어줘", "디자인 가이드 문서 만들어줘", "디자인 토큰 문서화", "AI가 UI 일관되게 따를 문서 만들어줘", "브랜드 스타일 가이드 마크다운", "UI 컨벤션 문서", "우리 앱 디자인 규칙 문서로 박아줘". 사용자가 "AI/에이전트가 우리 앱 스타일을 일관되게 따르게 하고 싶다"거나, 프로젝트의 색·폰트·간격·컴포넌트를 문서로 고정해 매 UI 생성이 흔들리지 않게 하려 할 때는, 명시적으로 "DESIGN.md"라고 부르지 않아도 이 스킬을 쓴다.
draft-plan
GitHub 이슈 또는 자연어 주제를 받아 논의·QA 자료를 준비한 뒤, 현재 하네스의 Plan Mode로 진입할 수 있으면 즉시 진입해 의사결정자가 읽는 PRD 포맷(배경/문제 정의 → 목표/비목표 → 요구사항 → 성공 지표/검증 방법 → 리스크/오픈 이슈)을 적용하는 스킬. 사람은 방향성·설계·리뷰 위주로 일하고 실행 디테일은 구현 단계에서 정해지므로, 파일별 작업 순서표나 진행 추적 장치는 담지 않는다. Plan Mode를 대체하지 않고 그 위에 얹는 "계획서 포맷 애드온"이다 — 계획과 구현을 세션 단위로 분리하지 않으며, `ExitPlanMode` 승인 직후 같은 세션에서 바로 구현으로 이어간다. Plan Mode 도구가 없으면 완결 계획서를 파일에 보존하고 현재 하네스의 승인·핸드오프 방식으로 이어간다. 사용자가 "구현 계획서 작성해줘", "플랜 작성해줘", "계획서 만들어줘", "이슈 #N 계획서", "이슈 가져와서 계획", "이슈 기반 plan", "issue plan", "/draft-plan", "플랜 세워줘", "상세 계획 세우고 진행해줘" 같은 표현을 쓰면 반드시 이 스킬을 사용한다. 인자가 이슈 번호이면 gh로 본문을 가져와 분석 자료로 활용하고, 코드베이스와 이슈 내용 간 괴리가 있거나 모호한 부분이 있으면 구조화 질문 도구 또는 대화로 사용자에게 확인한 뒤 진행한다. 필요하면 현재 제공된 웹 검색·페이지 읽기 도구로 외부 근거를 적극 조사하되 출처를 반드시 남긴다.
release
플러그인 릴리즈 전 과정을 수행하는 스킬. 스킬 검증 → 버전 업데이트 → CHANGELOG 작성 → 커밋 → 태그 → push 순으로 진행. "릴리즈해줘", "배포해줘", "버전 올려줘", "release 해줘", "publish 해줘", "버전 업데이트하고 배포해줘" 등의 표현이 나오면 반드시 이 스킬을 사용할 것. 중간 확인 없이 push까지 한 번에 끝낸다 — 이 스킬을 부르는 것이 곧 push 승인이다.
apply-review
GitHub PR 리뷰 코멘트를 가져와 분석 보고서를 마크다운 파일로 저장한 뒤, 사용자 승인 후 코드 수정까지 수행. "PR 리뷰 반영해줘", "코드리뷰 코멘트 처리해줘", "리뷰 적용해", "리뷰 피드백 수정해줘", "review comment 처리", "리뷰 보고서 만들어줘" 같은 요청에 반드시 이 스킬을 사용할 것.
create-ppt
개발 진행 현황 브리핑용 HTML 프레젠테이션을 자동으로 생성하는 스킬. 에이전트가 HTML을 직접 쓰지 않고 번들된 Python 스크립트에 위임하므로 토큰 비용이 최소화되고 항상 동일한 미니멀 흑백 디자인이 보장된다. "PPT 만들어줘", "발표자료 만들어", "브리핑 자료 생성해", "개발 현황 PPT", "클라이언트 발표자료", "프로젝트 소개 슬라이드 만들어", "고객 브리핑 준비해줘", "진행 현황 보고서 슬라이드" 같은 표현이 나오면 반드시 이 스킬을 사용한다. 개발자가 고객/외부 파트너에게 개발 현황이나 프로그램을 브리핑하는 상황에 특히 적합하다.
finish
작업을 마무리할 때 코드 정리 → 리뷰 → 문서 점검 → 커밋 → push → PR로 이어지는 "개발 종료 체인"을 한 번에 오케스트레이션하는 스킬. 각 단계는 기존 스킬(simplify·code-review·커밋 스킬·PR 스킬)을 순서대로 이어 수행한다. 커밋·PR 스킬은 하드코딩하지 않고 그 프로젝트의 규칙을 따른다. 다음 표현이 나오면 이 스킬을 사용할 것: "마무리해줘", "정리하고 커밋", "정리하고 올려줘", "finish", "커밋하고 PR", "코드 정리하고 PR까지", "리뷰하고 커밋하고 올려줘", "마감". 단순 커밋만 원하면 이 스킬이 아니라 해당 프로젝트의 커밋 스킬을 직접 쓴다.
light-research
deep-research보다 훨씬 적은 토큰·에이전트로 빠르게 조사하는 축소판 리서치 스킬. "가볍게 조사해줘", "간단히 찾아봐줘", "라이트 리서치", "축소 리서치", "딥리서치 말고 가볍게", "토큰 아껴서 조사해줘" 같은 표현이 나오면 반드시 사용한다. deep-research 워크플로우가 방금 세션/토큰 한도(rate limit)에 걸려 실패했을 때의 대안으로도 우선 고려한다. 주장별 3-vote 반박 검증 없이 "검색 각도별 조사 → 바로 종합" 2단계로 끝내 에이전트 수를 4~7개 수준으로 제한한다. 정확한 사실검증보다 빠른 개요·배경 파악이 목적일 때 적합하다. 반대로 인용 신뢰도를 반박 검증까지 해야 하는 무거운 리서치 요청이면 이 스킬 대신 deep-research를 쓴다.
memory-curator
대화 세션에서 유의미한 정보/패턴을 메모리에 즉시 저장하고, 쌓인 메모리를 주기적으로 정리하는 스킬. 두 가지 모드로 동작한다: - 기본 모드 (`/memory-curator`): 현재 대화를 분석하고, 읽을 수 있는 세션 로그가 있으면 보강해 놓친 메모리를 추출·저장 - 리뷰 모드 (`/memory-curator review`): 전체 메모리 파일을 정리하고 상시 로드 지침 승격 후보 및 문서화 대상 제안 다음 표현이 나오면 반드시 이 스킬을 사용할 것: "메모리 정리해줘", "세션 메모리 저장해줘", "memory curator", "메모리 큐레이션", "메모리 리뷰", "memory review", "지침 정리해줘", "문서화할 거 추려줘", "이번 세션 메모리", "놓친 메모리 있어?", "메모리 업데이트해줘"
notion-write
노션 MCP로 페이지·문서를 만들 때 가독성 좋은 구조로 작성하도록 안내하는 스타일 가이드. 사용자가 "노션에 정리해줘", "노션에 작성/문서화해줘", "노션 페이지 만들어줘", "이 내용 노션에 올려줘", "노션에 보고서/가이드/위키 만들어줘" 같은 표현을 쓰거나, notion-create-pages·notion-update-page로 새 페이지 본문을 작성하려 할 때 반드시 이 스킬을 참고한다. 콜아웃·토글·컬럼·표·목차·구분선·색 강조 같은 노션 네이티브 블록을 "언제 어디에" 쓸지 규칙으로 정해, AI가 만든 페이지가 텍스트 벽이 되지 않게 한다. (녹취→회의록 DB 같은 특화 워크플로우는 각 전용 스킬을 따르되, 본문 가독성은 이 규칙을 함께 적용한다.)
report
작업 내용을 프로젝트 `.private/`에 마크다운 보고서 파일로 작성하는 스킬. 다음 표현이 나오면 반드시 이 스킬을 사용할 것: "보고서 작성해줘", "report 올려줘", "작업 보고해줘", "완료 보고해줘", "분석 보고해줘", "의사결정 요청해줘". 작업을 완료했거나, 분석 결과를 정리했거나, 사용자에게 선택을 요청해야 할 때도 자동으로 이 스킬을 사용한다. (구현 계획서는 이 스킬이 아니라 `draft-plan`이 담당한다.)
retrospective
현재 대화 세션, 또는 여러 세션(지난 주·이번 주 같은 주간/기간 단위, 여러 프로젝트 포함)을 회고하여 유의미한 인사이트·피드백을 추출하고, 관련 스킬·지침 문서에 반영하는 스킬. 사용자가 "회고해줘", "회고", "이번 작업 회고", "retrospective", "오늘 대화 정리", "이번 세션 돌아봐", "지난 주 회고", "주간 회고", "지난 N일 돌아봐", "여러 세션 정리해줘", "배운 것 정리해줘", "피드백 반영해줘" 같은 표현을 쓰면 반드시 이 스킬을 사용한다. 세션에서 띄운 서브에이전트가 어떻게 일했는지를 묻는 표현 — "에이전트 회고", "서브에이전트 어떻게 일했는지", "위임 잘 됐는지 봐줘", "에이전트 워크플로우 개선" — 에도 사용한다. 작업 완료 후 같은 실수를 반복하지 않고 LLM이 다음 대화에서 더 잘 도울 수 있도록 맥락을 남기는 것이 목적이다. 이 스킬은 스킬 문서·상시 로드 지침(전역/프로젝트 CLAUDE.md 등)·서브에이전트 정의를 갱신 대상으로 삼는다 — 메모리·볼트 회고 로그는 다루지 않는다.
setup-skills
프로젝트의 기술 원칙(principles.md)을 기반으로 프로젝트를 분석하고, 해당 프로젝트에 특화된 커스텀 스킬을 추천 및 생성하는 메타 스킬. "프로젝트에 맞는 스킬 만들어줘", "스킬 세팅해줘", "setup skills", "이 프로젝트에 필요한 스킬 추천해줘", "원칙에 맞는 스킬 만들어줘", "코드 리뷰 스킬 만들어줘", "테스트 스킬 만들어줘", "기존 스킬 점검해줘", "스킬 업데이트 필요한 거 있어?", "원칙이 바뀌었는데 스킬 갱신해야 해", "스킬 정리해줘", "스킬 좀 봐줘" 등의 표현이 나오면 반드시 이 스킬을 사용할 것.
skill-metrics
Claude Code 세션 로그를 집계해 "어떤 스킬·워크플로우를 얼마나 자주 쓰는지"와 "무엇을 먼저 자동화하면 좋은지"를 정량 지표로 보여주는 스킬. 다음 표현이 나오면 반드시 이 스킬을 사용할 것: "스킬 사용 지표", "스킬 사용 현황", "어떤 스킬 자주 쓰는지", "스킬 메트릭", "skill-metrics", "자동화 우선순위", "자동화할 거 찾아줘", "워크플로우 지표", "스킬 도달률", "반복 워크플로우 분석". 주간 회고에서 자동화 후보를 정량 근거로 뽑을 때, 또는 새 스킬이 실제로 채택됐는지 추적할 때 사용한다. 스킬 호출을 `Skill` 도구 ���용으로 기록하지 않는 하네스에서는 관측량이 없어 미지원임을 알리고 종료한다.
worktree-scaffold
레포의 환경·특이사항을 분석해 그 레포 전용 git worktree 부트스트랩 스크립트(`scripts/worktree-create.sh`)를 일관된 골격으로 생성하는 스킬. `git worktree add`가 자동으로 안 딸려오는 것 — 추적 제외된 머신·환경 설정 (`.env`·`local.properties`·keystore 등), 체크아웃마다 새로 만들어야 하는 산출물(node_modules·네이티브 생성물·git hooks), 동시 실행 시 충돌하는 자원(dev 서버 포트·임시 디렉터리) — 을 자동 감지해, 복사(A)·재생성(B)·격리(C) 3단계와 실패 롤백을 갖춘 스크립트를 만든다. 스킬 자신이 매번 세팅하는 게 아니라, 레포에 남아 재사용되는 스크립트를 짜주는 생성기다. 다음 표현이 나오면 반드시 이 스킬을 사용한다: "worktree 셋업 스크립트 만들어줘", "worktree 생성 스크립트 짜줘", "worktree bootstrap 스크립트", "새 worktree에서 바로 개발되게 해줘", "worktree 만들면 .env/설정 자동 복사되게", "병렬 작업용 worktree 스크립트", "worktree-create.sh 만들어줘". worktree를 새로 만들면 빌드가 깨지거나 설정 파일이 없어 매번 손으로 채운다고 호소할 때도, 사용자가 명시적으로 "스크립트"라 부르지 않아도 이 스킬로 해결한다.
android-test
대상 코드를 분석하고 테스트 시나리오를 함께 논의한 뒤 테스트 코드를 생성. 사용자가 "테스트 써줘", "테스트 만들어줘", "테스트 코드 짜줘", "이 클래스 테스트", "단위 테스트 추가" 등을 요청할 때 사용. 코드 분석 없이 바로 테스트 코드를 작성하려 할 때도 이 스킬을 먼저 참조할 것.
review-quality
모바일 앱 코드베이스를 플랫폼 공식 품질 기준(Android Core App Quality + Apple App Review Guidelines/HIG)에 비춰 정적 검토하고, 위반·미흡 항목을 근거와 함께 리포트한다. 사용자가 "앱 품질 검토", "출시 전 점검", "스토어 심사 전 확인", "Play/App Store 리젝 위험 봐줘", "플랫폼 가이드라인 위반 확인", "Core App Quality", "App Review Guidelines", "권한/네트워크 보안 점검", "접근성/다크모드 점검", "이 앱 심사 통과될까", "Wear OS 품질", "워치 앱 출시 점검", "Wear App Quality" 같은 요청을 하면 반드시 사용한다. 특정 코드 로직 버그를 찾는 일반 코드 리뷰가 아니라, "플랫폼이 요구하는 출시 품질 기준" 관점의 점검이다. Android·iOS 네이티브와 React Native·Flutter·Tauri·Capacitor 하이브리드, 그리고 Wear OS(워치) 앱을 모두 다룬다.
report-issue
자연어로 이슈 내용을 말하면 GitHub 이슈 초안을 작성하고 생성하는 스킬. 버그, 기능 요청, 개선, 작업 등 모든 유형의 이슈를 다룬다. 다음 표현이 나오면 반드시 이 스킬을 사용할 것: - "이슈 올려줘", "이슈 만들어줘", "이슈 생성해줘", "깃허브 이슈" - "github issue", "issue 올려줘", "report-issue" - "버그 리포트", "버그 이슈", "버그 올려줘" - "기능 요청 이슈", "개선 이슈", "작업 이슈"
android-review
코드 리뷰를 수행한다. 사용자가 "리뷰해줘", "코드 봐줘", "PR 리뷰", "변경사항 확인", "코드 점검", "코드 검토" 등 코드 품질·개선 관련 요청을 할 때 반드시 사용한다. 인자 없으면 git diff 기준, 인자 있으면 지정 파일/폴더 기준으로 가독성·정확성·보안·아키텍처·테스트를 체크한다.
create-pr
현재 브랜치의 변경사항을 분석하여 GitHub PR을 생성하거나 기존 PR 본문을 업데이트하는 스킬. "PR 만들어줘", "풀리퀘 올려줘", "PR 생성해줘", "pull request 만들어줘", "PR 본문 업데이트해줘" 등의 표현이 나오면 반드시 이 스킬을 사용할 것.
coding-philosophy
코드 품질 판정의 공통 기준이 되는 개인 코딩 철학. "코딩 철학", "리뷰 기준", "품질 기준"을 묻거나, 코드 리뷰·설계 검토·인터페이스 점검에서 무엇을 결함으로 볼지 판단해야 할 때 사용한다. 다른 스킬(`common:module-review` 등)이 판정 기준으로 이 스킬을 로드한다.
module-review
모듈·패키지 단위로 공개 인터페이스와 구조를 순차 점검한다. "구조 점검", "모듈 리뷰", "인터페이스 점검", "아키텍처 리뷰", "패키지별로 하나씩 살펴보자", "공개 API 점검", "설계 검토" 같은 요청에 사용한다. 변경분(diff)이 아니라 **모듈이 밖으로 내놓는 계약**이 대상이며, 발견은 메모 파일에 모으고 코드는 수정하지 않는다.
build-skill
새 스킬을 만들거나 기존 스킬을 반복 개선하는 메타 스킬. 의도 포착 → SKILL.md 초안 → 결정론적 테스트 케이스 작성 → 러너 실행 → 정성 피드백 → 일반화 재작성의 루프를 돈다. 테스트는 번들된 Python 러너(`scripts/run_skill_test.py`)가 `claude -p`로 스킬을 격리 실행하고 `check(ctx)` 코드로 검증한다 — LLM 심판 없이 결정론적으로. 사용자가 "스킬 만들어줘", "새 스킬 추가", "이 워크플로 스킬로 만들어줘", "스킬 개선해줘", "스킬 반복 개선", "SKILL.md 작성", "스킬 테스트 짜줘", "스킬 평가 돌려줘", "build-skill", "이 스킬 회귀 테스트", "스킬 초안 잡아줘" 같은 표현을 쓰면 반드시 이 스킬을 사용한다. 대화에 이미 반복 워크플로가 있고 사용자가 "이거 스킬화하자"고 하면 그 맥락을 추출해 시작한다. 스킬 구조·progressive disclosure의 상세 레퍼런스가 필요하면 `plugin-dev:skill-development`를 함께 참고한다. 스킬 "사용량 지표"는 이 스킬이 아니라 `skill-metrics`가 다룬다.
grill
사용자가 명세를 길게 쓰는 대신, Claude가 인터뷰로 의도·설계 방향을 캐내 요구사항을 확정하는 스킬. 핵심 질문 하나에 집중해 묻고, 나머지 확신 없는 지점은 잠정 판단과 함께 목록으로 보여준다. 사용자가 "grill me", "캐물어봐", "인터뷰해줘", "요구사항 뽑아줘", "질문해줘", "/grill"이라 말하면 반드시 사용한다. 명시 요청이 없어도, 기능·스크립트·스킬·문서·계획처럼 **없던 것을 새로 만드는** 요청을 받으면 첫 응답을 이 스킬로 연다 — 요청이 명확해 보여도 그렇다. 짧은 한 문장 요청일수록 캐낼 게 많다. 조회·읽기·조사, 명세가 이미 확정된 수정(버그 수정·지정된 파일 편집·리뷰 반영)에는 쓰지 않는다.
html-brief
근거를 읽고 판단하거나 공유하기 위한 짧은 단일 HTML 문서를 만든다. 사용자가 “내부 의사결정 문서”, “대표 전달용 HTML”, “조사 결과를 HTML 보고서로”, “나를 위한 개발 보고서”, “출처가 있는 HTML 정리”를 요청할 때 사용한다. 랜딩 페이지·제품 UI·웹앱 구현이나 단순 Markdown 변환에는 사용하지 않는다.
brand-brainstorm
브랜드 검토 에이전트 여섯을 병렬로 돌려 포지셔닝·문구·행동설계·반박·시장대조·네이밍을 한 번에 받고, 관점 간 충돌까지 정리해 종합한다. 사용자가 "브랜딩 브레인스토밍", "여러 관점으로 카피 검토해줘", "태그라인 갈림길인데 봐줘", "이 문구 괜찮은지 다각도로", "brand-brainstorm"이라고 하거나, 브랜드 문구·포지셔닝에서 방향이 갈리는 결정을 앞두고 있을 때 사용한다. 문구 한 줄만 다듬는 일이면 brand-verbal-identity 에이전트를 직접 부르는 편이 싸다.
brand-knowledge-base
브랜드 검토 에이전트들이 읽을 제품 지식베이스를 만든다. 제품의 확정 사실·쓸 수 없는 표현·이미 정한 브랜드 언어·사용자 실제 발화·현행 문구를 수집하고, 번들된 일반 브랜딩 이론을 붙여 한 파일로 만든다. 사용자가 "브랜딩 지식베이스 만들어줘", "브랜드 검토 준비", "카피 작업 재료 모아줘", "brand-knowledge-base"라고 하거나, brand-brainstorm을 돌리려는데 지식베이스가 없을 때 사용한다. 이미 지식베이스가 있으면 새로 만들지 말고 갱신한다.
crash-triage
Firebase Crashlytics의 상위 크래시를 조사해 스택과 코드를 대조하고 근본 원인까지 짚은 뒤, 각 건이 이미 등록된 이슈인지·새로 올릴 후보인지·건드릴 게 없는지 판정해 표로 보고하는 스킬. 다음 표현이 나오면 반드시 이 스킬을 사용한다: "크래시 확인해줘", "크래시 분석해줘", "Crashlytics 봐줘", "상위 이슈 분석", "요즘 무슨 크래시 나?", "크래시 리포트 정리해줘", "어떤 예외가 제일 많아?", "이 크래시 원인 찾아줘", "크래시 트리아지". 조사와 판정까지만 하고 **이슈 생성과 코드 수정은 하지 않는다** — 사용자가 고른 건을 이슈 스킬로 넘기고, 수정은 구현 스킬이 맡는다. Crashlytics MCP 도구가 붙어 있어야 동작한다.
build-mcp-server
외부 서비스(메일·채팅·드라이브·이슈 트래커 등)를 에이전트에 붙일 때, 범용 API 통로 대신 목적별 도구만 노출하는 작은 MCP 서버를 처음부터 끝까지 만든다. 서버·설치 스크립트·게이트 테스트 작성, 변형 주입으로 게이트 실증, 실제 응답으로 출력 검증, 자격 증명을 코드 밖에 600 권한으로 보관, 쓰는 하네스 전부에 등록하고 목록 대조까지 한 흐름으로 처리한다. 사용자가 "MCP 서버 만들어줘", "내가 직접 MCP 만들게", "슬랙/드라이브/캘린더 붙여줘", "이 API를 MCP로 감싸줘", "에이전트가 아무거나 못 하게 도구를 좁히고 싶다", "커스텀 MCP 서버" 같은 표현을 쓰면 반드시 이 스킬을 사용한다. 이미 있는 MCP 서버를 설치·등록만 하는 일(그건 각 하네스의 mcp 명령), 스킬을 만드는 일(build-skill)에는 쓰지 않는다.
plugin-commit
변경사항을 분석해 이 프로젝트의 커밋 컨벤션에 맞는 메시지를 작성하고 커밋을 수행하는 스킬. scope는 변경된 파일 경로로 자동 감지한다 (plugins/common → common, plugins/development → development). "커밋해줘", "변경사항 정리해줘", "커밋 메시지 만들어줘", "git commit", "스테이징하고 커밋" 등의 표현이 나오면 반드시 이 스킬을 사용할 것.
codebase-sync
코드베이스 현재 상태를 파악하고, 문서·코드 사이의 불일치를 찾아 수정한 뒤 커밋·PR까지 이어서 처리하는 스킬. 다음 표현이 나오면 반드시 이 스킬을 사용할 것: "현재 상황 파악해줘", "지금 상태 봐줘", "코드랑 문서 맞춰줘", "문서 동기화해줘", "README 최신화해줘", "정리하고 PR 올려줘", "뭐가 오래됐는지 봐줘", "뭐가 틀렸는지 봐줘", "문서 업데이트해줘", "현재 구조 파악해줘", "코드 정리해줘". 사용자가 최근 큰 변경(마이그레이션, 리팩토링, 모듈 추가)을 언급하며 문서나 코드 정리를 암시할 때도 사용할 것.
commit
변경사항을 분석하여 커밋 메시지를 작성하고 git 커밋을 수행하는 스킬. 사용자가 "커밋해줘", "변경사항 정리해줘", "커밋 메시지 만들어줘", "git commit" 등의 표현을 사용할 때 반드시 이 스킬을 사용할 것.
tauri-guideline
Tauri v2 모바일 프로젝트(Native↔Rust↔React 3-레이어 브리지)의 아키텍처·디버깅·테스트·플러그인 선택·계약 프로그래밍 가이드라인을 제공하는 스킬. "tauri 구조", "Rust랑 React 역할", "레이어 분리", "브리지 디버깅", "tauri 로그 어떻게", "mock 빌드", "e2e 전략", "tauri 테스트", "tauri 플러그인 골라줘", "공식 vs 자제작", "레이어 경계 검증", "SSOT 어디", "계약 프로그래밍", "타입 어디서 검증" 등의 표���이 나오면 반드시 이 스킬을 사용할 것.
search-sessions
여러 코딩 에이전트 하네스(Claude Code·Codex)의 세션 로그를 한 번에 뒤져 과거 대화를 찾는 스킬. 다음 표현이 나오면 반드시 이 스킬을 사용할 것: "예전에 이거 얘기했었나", "과거 대화 찾아줘", "언제 그렇게 정했지", "그때 뭐라고 했지", "세션 기록 검색", "이전 세션에서 찾아줘", "대화 히스토리 뒤져줘", "search-sessions". 한 프로젝트를 두 하네스로 번갈아 작업하면 기록이 각자 폴더로 갈라지므로, 한쪽만 보고 "그런 논의 없었다"고 단정하면 이미 정한 방향을 다시 만들게 된다. 현재 대화에 근거가 없고 과거 결정 여부가 판단을 가르는 상황이면 사용자가 먼저 요청하지 않아도 이 스킬로 확인한다.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.