Claude Skills by tigu77

앱(웹·서버·스크립트 등)에 AI/LLM 을 연결할 때 사용. tiguclaw 에 붙이는 두 방식 — (A) tiguclaw 직결 커스텀 엔드포인트(비서의 도구·스킬·메모리까지 쓰는 에이전틱 호출, 규약 자유) vs (B) OpenAI 호환 LLM 게이트웨이(OpenRouter·OpenAI 와 baseURL 만 바꿔 스왑 가능한 표준 규약) — 의 선택 기준·규약·배선 절차·검증을 담는다. 트리거: '앱에 AI 붙여줘', '이 앱에서 LLM 쓰게 해줘', 'tiguclaw 를 백엔드로', '오픈라우터처럼 연결', 'API 로 비서 호출', '게이트웨이 켜줘', 앱 개발 중 LLM 연결 지점에 도달했을 때. 사용자가 방식을 안 정했으면 §1 기준으로 추천하고 확인받은 뒤 배선한다.

Claude Code 프로젝트의 서브에이전트·스킬·슬래시커맨드(.claude/)를 tiguclaw 로 가져와(래핑/동기화) 그대로 쓸 수 있게 한다. (1) '클로드 코드에서 쓰던 에이전트/스킬 가져와', '.claude 래핑/동기화', 'claude-wrapper-sync' 요청 시, (2) Claude Code 로 작업한 폴더의 능력을 tiguclaw 비서가 재사용하고 싶을 때. 포맷이 거의 동일해 검증+복사가 핵심.

코드 리뷰·버그 진단·diff/브랜치/PR 리뷰 방법론. (1) '이 버그 왜 나지', '이거 왜 안 돼', '원인 찾아줘' 류 디버깅, (2) '코드 리뷰해줘', '이 수정 괜찮아?', '더 나은 방법 있어?' 류 단건 리뷰, (3) '이 diff 리뷰해줘', '브랜치 리뷰', 'PR 리뷰해줘', '이 커밋들 봐줘', '변경 전체 체계적으로 리뷰' 류 diff/브랜치 전체 리뷰, (4) '꼼꼼히/딥하게/멀티에이전트로 리뷰' 류 고강도 적대적 검증 리뷰. 단건 버그는 솔로로 근본 원인→인접 확장→최소 수정을 짚고, 넓은 diff/브랜치는 correctness·simplification·efficiency·test-coverage 4차원을 서브에이전트 팬아웃으로 리뷰한 뒤 회의론자 서브가 각 발견을 반증(다수 반증이면 폐기)해 심각도 순으로 구조화 보고한다. --fix/--comment/--commit 액션 지원.

Codex 의 스킬(~/.codex/skills, 프로젝트 AGENTS.md·프롬프트)을 tiguclaw 로 가져와(래핑/동기화) 그대로 쓸 수 있게 한다. (1) '코덱스에서 쓰던 스킬 가져와', 'codex 래핑/동기화', 'codex-wrapper-sync' 요청 시, (2) Codex 로 쓰던 능력을 tiguclaw 비서가 재사용하고 싶을 때. Codex 스킬도 SKILL.md 포맷이라 검증+복사가 핵심(단 Codex 는 서브에이전트 없음).

tiguclaw 데이터베이스(대화·기억·세션)의 백업·용량·아카이브를 다룬다. "백업 해줘·백업 되고 있어?·DB 가 너무 커·용량·디스크·오래된 대화 정리·데이터 옮기기·복구·날아가면" 류 요청, 그리고 데이터가 걸린 유지보수를 시작하기 전에 사용한다. ★백업은 v0.27.0 부터 **자동**이다(스케줄이 아니라 데몬 유지보수 루프) — 스케줄 목록에 없다고 '백업이 없다'고 결론내지 말고 `/status` 나 `<home>/data/backup/` 을 보라. 정리 ≠ 삭제: 콜드 레코드는 옮기되 지우지 않는다.

서브에이전트 팀(하네스)을 만들지 말지 정하고, 만들기로 했으면 구성·확장·정리하는 메타 스킬. (1) '팀 만들어줘'·'하네스 구성/구축/확장/점검' 요청 시, (2) 한 작업이 서로 **독립·비중첩**인 하위작업 3개 이상으로 갈리고 각각 상당한 시간이 걸릴 때, (3) 기존 팀에 에이전트·스킬을 추가하거나 역할이 겹쳐 정리가 필요할 때. ★팀은 공짜가 아니다 — 에이전트마다 컨텍스트를 새로 싣고, 비싸지는 건 **N**이다. **하위작업이 3개 미만이거나 서로 얽혀 있으면 이 스킬을 쓰지 말고 직접 하거나 1명에게 위임하라.** 서브에이전트 정의(.md)와 오케스트레이션 스킬(SKILL.md)을 `Write` 로 만들고 `spawn_agent` 으로 기동한다.

tiguclaw scheduler/file-watch 등 trigger plugin 의 add_schedule·add_watch MCP 도구 호출 전 prompt 자체 위험성 평가 + gray/danger 시 사용자 명시 승인 요청. 자연어 trigger 등록 요청(예 — "매일 8시", "재시작될 때마다", "cron", "주기적으로", "/schedule add", "스케줄 등록", "자동으로 ~", "정기적으로", "매분", "매시간", "watch", "파일 변경", "폴더 감시", "감시", "파일 추적") 시 sysprompt 진입점에서 자동 호출. trigger plugin bypassPermissions 가 발화 시점에 사용자 부재로 위험 도구를 자동 실행할 수 있는 회색지대 가드.

티구클로 스킬을 제대로 만들고 고치는 메타 스킬 (필요하면 정량 eval 로 개선을 증명). (1) '스킬 만들어줘/추가해줘', 새 스킬을 처음부터 작성할 때, (2) 기존 스킬을 개선·수정·최적화할 때, (3) 스킬이 정말 효과 있는지 eval(테스트 프롬프트 배치)로 벤치·측정하고 싶을 때, (4) 스킬 description 을 고쳐 트리거 정확도를 올릴 때, (5) self-growth 가 제안한 스킬 신규/개선을 실제로 만들 때 사용. harness 스킬(전문 에이전트 팀+오케스트레이션을 통째로 구성)과 구분 — 이건 *개별 스킬 하나*를 제대로 만드는 스킬이다. 대부분 초안+빠른 정성 확인이면 충분하고, 정량 증명은 중요·논쟁적일 때만 옵션. 스킬 실제 반영은 항상 사람 승인(human-gate).

변경이 실제로 배포·동작하는지 구동으로 확인하는 검증 스킬 (결함 탐지가 아니라 '진짜 도는가'). (1) '배포/반영/라이브 적용 다 됐어?', '이거 실제로 돌아?' 확인, (2) 코드 수정·리팩터·교체를 '완료' 보고하기 직전 DoD 점검, (3) 빌드·배포가 필요한 런타임에서 도는 산출물이 실제로 갱신됐는지 실측(반영 누락·스테일 산출물 방지), (4) 새 조건분기를 만든 뒤 그 분기가 실제로 타지는지 확인, (5) 함수·포맷터·모듈 교체 후 옛 동작 회귀 여부 대조. 코드의 '결함'을 찾는 code-review 와 구분 — 이건 변경이 *실제로 반영되고 의도대로 도는지*를 grep·프로세스·실행으로 구동 확인하는 스킬이다. 재빌드·재배포 후 마커 실측, 분기별 실입력 1개, 교체 시 옛 행동 인벤토리 대조, 완료 보고 전 체크리스트.