gagip

@gagip source repo

19 skills
0 followers
6 hours ago last updated

▌
Release · gagip
플러그인 릴리즈 전 과정을 수행하는 스킬. 스킬 검증 → 버전 업데이트 → CHANGELOG 작성 → 커밋 → 태그 → push 순으로 진행. "릴리즈해줘", "배포해줘", "버전 올려줘", "release 해줘", "publish 해줘", "버전 업데이트하고 배포해줘" 등의 표현이 나오면 반드시 이 스킬을 사용할 것. 중간 확인 없이 push까지 한 번에 끝낸다 — 이 스킬을 부르는 것이 곧 push 승인이다.

0
installs
▌
Grill · gagip
사용자가 명세를 길게 쓰는 대신, Claude가 인터뷰로 의도·설계 방향을 캐내 요구사항을 확정하는 스킬. 핵심 질문 하나에 집중해 묻고, 나머지 확신 없는 지점은 잠정 판단과 함께 목록으로 보여준다. 사용자가 "grill me", "캐물어봐", "인터뷰해줘", "요구사항 뽑아줘", "질문해줘", "/grill"이라 말하면 반드시 사용한다. 명시 요청이 없어도, 기능·스크립트·스킬·문서·계획처럼 **없던 것을 새로 만드는** 요청을 받으면 첫 응답을 이 스킬로 연다 — 요청이 명확해 보여도 그렇다. 짧은 한 문장 요청일수록 캐낼 게 많다. 조회·읽기·조사, 명세가 이미 확정된 수정(버그 수정·지정된 파일 편집·리뷰 반영)에는 쓰지 않는다.

0
installs
▌
Plugin Commit · gagip bundle
변경사항을 분석해 이 프로젝트의 커밋 컨벤션에 맞는 메시지를 작성하고 커밋을 수행하는 스킬. scope는 변경된 파일 경로로 자동 감지한다 (plugins/common → common, plugins/development → development). "커밋해줘", "변경사항 정리해줘", "커밋 메시지 만들어줘", "git commit", "스테이징하고 커밋" 등의 표현이 나오면 반드시 이 스킬을 사용할 것.

0
installs
▌
Design Md · gagip bundle
프로젝트 루트에 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"라고 부르지 않아도 이 스킬을 쓴다.

0
installs
▌
Draft Plan · gagip bundle
GitHub 이슈 또는 자연어 주제를 받아 논의·QA 자료를 준비한 뒤, 현재 하네스의 Plan Mode로 진입할 수 있으면 즉시 진입해 의사결정자가 읽는 PRD 포맷(배경/문제 정의 → 목표/비목표 → 요구사항 → 성공 지표/검증 방법 → 리스크/오픈 이슈)을 적용하는 스킬. 사람은 방향성·설계·리뷰 위주로 일하고 실행 디테일은 구현 단계에서 정해지므로, 파일별 작업 순서표나 진행 추적 장치는 담지 않는다. Plan Mode를 대체하지 않고 그 위에 얹는 "계획서 포맷 애드온"이다 — 계획과 구현을 세션 단위로 분리하지 않으며, `ExitPlanMode` 승인 직후 같은 세션에서 바로 구현으로 이어간다. Plan Mode 도구가 없으면 완결 계획서를 파일에 보존하고 현재 하네스의 승인·핸드오프 방식으로 이어간다. 사용자가 "구현 계획서 작성해줘", "플랜 작성해줘", "계획서 만들어줘", "이슈 #N 계획서", "이슈 가져와서 계획", "이슈 기반 plan", "issue plan", "/draft-plan", "플랜 세워줘", "상세 계획 세우고 진행해줘" 같은 표현을 쓰면 반드시 이 스킬을 사용한다. 인자가 이슈 번호이면 gh로 본문을 가져와 분석 자료로 활용하고, 코드베이스와 이슈 내용 간 괴리가 있거나 모호한 부분이 있으면 구조화 질문 도구 또는 대화로 사용자에게 확인한 뒤 진행한다. 필요하면 현재 제공된 웹 검색·페이지 읽기 도구로 외부 근거를 적극 조사하되 출처를 반드시 남긴다.

0
installs
▌
HTML Brief · gagip bundle
근거를 읽고 판단하거나 공유하기 위한 짧은 단일 HTML 문서를 만든다. 사용자가 “내부 의사결정 문서”, “대표 전달용 HTML”, “조사 결과를 HTML 보고서로”, “나를 위한 개발 보고서”, “출처가 있는 HTML 정리”를 요청할 때 사용한다. 랜딩 페이지·제품 UI·웹앱 구현이나 단순 Markdown 변환에는 사용하지 않는다.

0
installs
▌
Build Skill · gagip bundle
새 스킬을 만들거나 기존 스킬을 반복 개선하는 메타 스킬. 의도 포착 → 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`가 다룬다.

0
installs
▌
Commit · gagip bundle
변경사항을 분석하여 커밋 메시지를 작성하고 git 커밋을 수행하는 스킬. 사용자가 "커밋해줘", "변경사항 정리해줘", "커밋 메시지 만들어줘", "git commit" 등의 표현을 사용할 때 반드시 이 스킬을 사용할 것.

0
installs
▌
Notion Write · gagip bundle
노션 MCP로 페이지·문서를 만들 때 가독성 좋은 구조로 작성하도록 안내하는 스타일 가이드. 사용자가 "노션에 정리해줘", "노션에 작성/문서화해줘", "노션 페이지 만들어줘", "이 내용 노션에 올려줘", "노션에 보고서/가이드/위키 만들어줘" 같은 표현을 쓰거나, notion-create-pages·notion-update-page로 새 페이지 본문을 작성하려 할 때 반드시 이 스킬을 참고한다. 콜아웃·토글·컬럼·표·목차·구분선·색 강조 같은 노션 네이티브 블록을 "언제 어디에" 쓸지 규칙으로 정해, AI가 만든 페이지가 텍스트 벽이 되지 않게 한다. (녹취→회의록 DB 같은 특화 워크플로우는 각 전용 스킬을 따르되, 본문 가독성은 이 규칙을 함께 적용한다.)

0
installs
▌
Retrospective · gagip
현재 대화 세션, 또는 여러 세션(지난 주·이번 주 같은 주간/기간 단위, 여러 프로젝트 포함)을 회고하여 유의미한 인사이트·피드백을 추출하고, 관련 스킬·지침 문서에 반영하는 스킬. 사용자가 "회고해줘", "회고", "이번 작업 회고", "retrospective", "오늘 대화 정리", "이번 세션 돌아봐", "지난 주 회고", "주간 회고", "지난 N일 돌아봐", "여러 세션 정리해줘", "배운 것 정리해줘", "피드백 반영해줘" 같은 표현을 쓰면 반드시 이 스킬을 사용한다. 작업 완료 후 같은 실수를 반복하지 않고 LLM이 다음 대화에서 더 잘 도울 수 있도록 맥락을 남기는 것이 목적이다. 이 스킬은 스킬 문서와 상시 로드 지침(전역/프로젝트 CLAUDE.md 등)만 갱신 대상으로 삼는다 — 메모리·볼트 회고 로그는 다루지 않는다.

0
installs
▌
Skill Metrics · gagip bundle
Claude Code 세션 로그를 집계해 "어떤 스킬·워크플로우를 얼마나 자주 쓰는지"와 "무엇을 먼저 자동화하면 좋은지"를 정량 지표로 보여주는 스킬. 다음 표현이 나오면 반드시 이 스킬을 사용할 것: "스킬 사용 지표", "스킬 사용 현황", "어떤 스킬 자주 쓰는지", "스킬 메트릭", "skill-metrics", "자동화 우선순위", "자동화할 거 찾아줘", "워크플로우 지표", "스킬 도달률", "반복 워크플로우 분석". 주간 회고에서 자동화 후보를 정량 근거로 뽑을 때, 또는 새 스킬이 실제로 채택됐는지 추적할 때 사용한다. 스킬 호출을 `Skill` 도구 사용으로 기록하지 않는 하네스에서는 관측량이 없어 미지원임을 알리고 종료한다.

0
installs
▌
Create Pr · gagip
현재 브랜치의 변경사항을 분석하여 GitHub PR을 생성하거나 기존 PR 본문을 업데이트하는 스킬. "PR 만들어줘", "풀리퀘 올려줘", "PR 생성해줘", "pull request 만들어줘", "PR 본문 업데이트해줘" 등의 표현이 나오면 반드시 이 스킬을 사용할 것.

0
installs
▌
Crash Triage · gagip
Firebase Crashlytics의 상위 크래시를 조사해 스택과 코드를 대조하고 근본 원인까지 짚은 뒤, 각 건이 이미 등록된 이슈인지·새로 올릴 후보인지·건드릴 게 없는지 판정해 표로 보고하는 스킬. 다음 표현이 나오면 반드시 이 스킬을 사용한다: "크래시 확인해줘", "크래시 분석해줘", "Crashlytics 봐줘", "상위 이슈 분석", "요즘 무슨 크래시 나?", "크래시 리포트 정리해줘", "어떤 예외가 제일 많아?", "이 크래시 원인 찾아줘", "크래시 트리아지". 조사와 판정까지만 하고 **이슈 생성과 코드 수정은 하지 않는다** — 사용자가 고른 건을 이슈 스킬로 넘기고, 수정은 구현 스킬이 맡는다. Crashlytics MCP 도구가 붙어 있어야 동작한다.

0
installs
▌
Search Sessions · gagip bundle
여러 코딩 에이전트 하네스(Claude Code·Codex)의 세션 로그를 한 번에 뒤져 과거 대화를 찾는 스킬. 다음 표현이 나오면 반드시 이 스킬을 사용할 것: "예전에 이거 얘기했었나", "과거 대화 찾아줘", "언제 그렇게 정했지", "그때 뭐라고 했지", "세션 기록 검색", "이전 세션에서 찾아줘", "대화 히스토리 뒤져줘", "search-sessions". 한 프로젝트를 두 하네스로 번갈아 작업하면 기록이 각자 폴더로 갈라지므로, 한쪽만 보고 "그런 논의 없었다"고 단정하면 이미 정한 방향을 다시 만들게 된다. 현재 대화에 근거가 없고 과거 결정 여부가 판단을 가르는 상황이면 사용자가 먼저 요청하지 않아도 이 스킬로 확인한다.

0
installs
▌
Build MCP Server · gagip bundle
외부 서비스(메일·채팅·드라이브·이슈 트래커 등)를 에이전트에 붙일 때, 범용 API 통로 대신 목적별 도구만 노출하는 작은 MCP 서버를 처음부터 끝까지 만든다. 서버·설치 스크립트·게이트 테스트 작성, 변형 주입으로 게이트 실증, 실제 응답으로 출력 검증, 자격 증명을 코드 밖에 600 권한으로 보관, 쓰는 하네스 전부에 등록하고 목록 대조까지 한 흐름으로 처리한다. 사용자가 "MCP 서버 만들어줘", "내가 직접 MCP 만들게", "슬랙/드라이브/캘린더 붙여줘", "이 API를 MCP로 감싸줘", "에이전트가 아무거나 못 하게 도구를 좁히고 싶다", "커스텀 MCP 서버" 같은 표현을 쓰면 반드시 이 스킬을 사용한다. 이미 있는 MCP 서버를 설치·등록만 하는 일(그건 각 하네스의 mcp 명령), 스킬을 만드는 일(build-skill)에는 쓰지 않는다.

0
installs
▌
Report Issue · gagip
자연어로 이슈 내용을 말하면 GitHub 이슈 초안을 작성하고 생성하는 스킬. 버그, 기능 요청, 개선, 작업 등 모든 유형의 이슈를 다룬다. 다음 표현이 나오면 반드시 이 스킬을 사용할 것: - "이슈 올려줘", "이슈 만들어줘", "이슈 생성해줘", "깃허브 이슈" - "github issue", "issue 올려줘", "report-issue" - "버그 리포트", "버그 이슈", "버그 올려줘" - "기능 요청 이슈", "개선 이슈", "작업 이슈"

0
installs
▌
Module Review · gagip bundle
모듈·패키지 단위로 공개 인터페이스와 구조를 순차 점검한다. "구조 점검", "모듈 리뷰", "인터페이스 점검", "아키텍처 리뷰", "패키지별로 하나씩 살펴보자", "공개 API 점검", "설계 검토" 같은 요청에 사용한다. 변경분(diff)이 아니라 **모듈이 밖으로 내놓는 계약**이 대상이며, 발견은 메모 파일에 모으고 코드는 수정하지 않는다.

0
installs
▌
Brand Brainstorm · gagip
브랜드 검토 에이전트 여섯을 병렬로 돌려 포지셔닝·문구·행동설계·반박·시장대조·네이밍을 한 번에 받고, 관점 간 충돌까지 정리해 종합한다. 사용자가 "브랜딩 브레인스토밍", "여러 관점으로 카피 검토해줘", "태그라인 갈림길인데 봐줘", "이 문구 괜찮은지 다각도로", "brand-brainstorm"이라고 하거나, 브랜드 문구·포지셔닝에서 방향이 갈리는 결정을 앞두고 있을 때 사용한다. 문구 한 줄만 다듬는 일이면 brand-verbal-identity 에이전트를 직접 부르는 편이 싸다.

0
installs
▌
Brand Knowledge Base · gagip bundle
브랜드 검토 에이전트들이 읽을 제품 지식베이스를 만든다. 제품의 확정 사실·쓸 수 없는 표현·이미 정한 브랜드 언어·사용자 실제 발화·현행 문구를 수집하고, 번들된 일반 브랜딩 이론을 붙여 한 파일로 만든다. 사용자가 "브랜딩 지식베이스 만들어줘", "브랜드 검토 준비", "카피 작업 재료 모아줘", "brand-knowledge-base"라고 하거나, brand-brainstorm을 돌리려는데 지식베이스가 없을 때 사용한다. 이미 지식베이스가 있으면 새로 만들지 말고 갱신한다.

0
installs

19 published skills