---

name: commit description: 변경된 파일을 기능별로 그룹화하여 커밋 생성

Commit Skill

지금 즉시 아래 워크플로우를 실행하라. 질문하지 말고 바로 실행하라.

현재 상태 수집

git status
git diff --stat
git log --oneline -3

실행 지시

위 상태를 분석하여 다음을 수행하라:

1. 변경 파일 분석: 위의 git status와 git diff 결과를 기반으로 변경된 파일들을 파악한다.
2. 기능별 그룹화: 변경 파일들을 아래 기준으로 그룹으로 나눈다:
   • feat - 새로운 기능 추가
   • fix - 버그 수정
   • docs - 문서 업데이트
   • style - 코드 스타일 수정 (동작 변경 없음)
   • refactor - 코드 리팩토링
   • test - 테스트 추가/수정
   • chore - 유지보수 작업
3. 그룹별 커밋 생성: 각 그룹마다 관련 파일만 git add로 스테이징한 뒤 커밋한다.
4. 커밋 내역 검증: git log --oneline -5로 결과를 확인한다.

커밋 메시지 규칙

• 형식: <type>(<scope>): <subject>
• 커밋 메시지는 반드시 한글로 작성
• 명령형 현재 시제 사용: "추가", "수정", "삭제"
• subject는 50자 이내, 끝에 마침표 없음
• 필요시 body에 상세 설명 추가

한글 커밋 메시지 깨짐 방지

git commit -m "한글" 사용 시 터미널 환경에 따라 한글이 깨질 수 있다. 반드시 HEREDOC 또는 임시 파일 방식을 사용하라.

macOS/Linux (HEREDOC 방식 - 권장)

git commit -m "$(cat <<'EOF'
feat(auth): JWT 로그인 및 미들웨어 추가

- JWT 토큰 생성 구현
- 보호된 라우트용 인증 미들웨어 추가

Co-Authored-By: Codex
EOF
)"

Windows PowerShell (임시 파일 방식)

PowerShell에서는 -m 옵션으로 한글 전달 시 인코딩 문제가 발생한다. UTF-8 임시 파일을 사용하라:

chcp 65001
# commit_msg.txt에 UTF-8로 메시지 작성 후:
git commit -F commit_msg.txt
Remove-Item commit_msg.txt

사용자 힌트: $ARGUMENTS

Skills Store

Codex와 Claude Code에서 같이 쓰는 스킬, agent, 명령, 프로젝트 룰을 모아 둔 저장소입니다.

자주 쓰는 순서는 issue-create → issue-start → issue-end → issue-merge, visual-companion, kill-process, install-skill, migrate-skill-agent, irasutoya-search, E2E 계열 스킬, loop/schedule, 문서/프롬프트/agent 순입니다.

빠른 사용 순서

1. 이슈 기반 작업은 issue-create로 등록하고, issue-start로 분석·구현·커밋·증거를 남기고, issue-end로 증거를 재확인해 PR을 만든 뒤, issue-merge로 여러 워크트리를 통합·재검증합니다. gh가 준비되지 않았으면 gh-setup이 먼저 끼어듭니다.
2. 시각적 선택지나 와이어프레임이 필요하면 visual-companion을 씁니다.
3. 로컬 개발 서버 포트가 막히면 kill-process로 포트를 비웁니다.
4. 외부 GitHub 스킬을 가져와야 하면 install-skill을 씁니다.
5. 이 저장소의 특정 skill이나 agent를 홈 또는 현재 프로젝트로 동기화해야 하면 migrate-skill-agent를 씁니다.
6. 발표자료나 문서에 넣을 이라스토야 일러스트가 필요하면 irasutoya-search를 씁니다.
7. E2E 계획, 생성, 치유, 하네스 작업은 E2E 그룹에서 고릅니다.
8. 영어 원문 기반 한국어 발표자료를 다듬을 때는 slide-ko-polish로 번역체와 줄바꿈을 같이 봅니다.
9. 문서 AI-feel 점검, 프롬프트 설계, agent 호출은 작업 성격에 맞춰 선택합니다.
10. Codex 프롬프트를 정해진 간격으로 반복하려면 loop, cron이나 특정 시각에 예약하려면 schedule을 씁니다.

저장소 구조

.
├── AGENTS.md
├── CLAUDE.md
├── LICENSE
├── README.md
├── assets/
│   └── images/
├── scripts/
├── tools/
│   └── issue-common.mjs
├── .claude/
│   ├── agents/
│   ├── commands/
│   ├── rules/
│   └── skills/
└── .codex/
    ├── agents/
    ├── config.toml
    ├── rules/
    └── skills/

사용법 가이드

먼저 설치하기

네 스킬은 하나의 흐름으로 움직입니다. 스킬 네 개와 판정·통합용 보조 에이전트 세 개를 함께 설치해야 중간 단계에서 빠지는 기능이 없습니다.

설치 대상:

skills   issue-create, issue-start, issue-end, issue-merge
agents   issue-verifier, issue-merge-analyst, issue-merge-critic

설치 위치는 둘 중 하나를 고릅니다.

• 홈 설치: 모든 저장소에서 반복해서 쓸 때 권장합니다. Codex는 ~/.codex/, Claude Code는 ~/.claude/ 아래에 설치합니다.
• 프로젝트 설치: 특정 저장소에서만 쓰거나 팀과 같은 버전을 고정할 때 적합합니다. 현재 저장소의 .codex/ 또는 .claude/ 아래에 설치합니다.

아래 코드 블록 전체를 사용 중인 AI의 프롬프트 입력란에 복사하세요. 설치 위치를 적지 않으면 AI가 홈 또는 프로젝트 중 하나를 먼저 물어봅니다.

Codex용 설치 프롬프트

Mineru98/skills-store의 issue 워크플로를 Codex에 설치해 주세요.

원본 저장소:
https://github.com/Mineru98/skills-store

설치할 Codex 스킬:
- .codex/skills/issue-create
- .codex/skills/issue-start
- .codex/skills/issue-end
- .codex/skills/issue-merge

설치할 Codex 에이전트:
- .codex/agents/issue-verifier.toml
- .codex/agents/issue-merge-analyst.toml
- .codex/agents/issue-merge-critic.toml

먼저 홈 설치(~/.codex)와 현재 프로젝트 설치(.codex) 중 어디에 설치할지 확인해 주세요.
migrate-skill-agent 스킬이 있으면 각 항목을 --flavor codex로 설치하고, 없으면 저장소를 안정적인 경로에 clone한 뒤 위 폴더와 파일을 대상 위치로 복사해 주세요.
SKILL.md 하나만 복사하지 말고 references, scripts, agents/openai.yaml을 포함한 스킬 폴더 전체를 설치해 주세요.
기존 대상이 있으면 경로와 덮어쓸 내용을 보여 주고 명시적으로 승인받은 뒤 설치해 주세요. 백업과 롤백이 없다는 점도 먼저 알려 주세요.
설치 후 일곱 항목의 존재 여부와 git, Node 18+, curl, gh 로그인 상태를 검증해 주세요. 프론트엔드 증거를 캡처할 저장소라면 Playwright와 webp 변환 도구(sharp, cwebp, ffmpeg 중 하나)도 확인해 주세요.
gh 인증이 안 되어 있으면 gh-setup 스킬로 설치와 로그인을 이어서 진행해 주세요. gh-setup이 없으면 공식 gh 설치 방법과 gh auth login 명령을 안내해 주세요.

Claude Code용 설치 프롬프트

Mineru98/skills-store의 issue 워크플로를 Claude Code에 설치해 주세요.

원본 저장소:
https://github.com/Mineru98/skills-store

설치할 Claude Code 스킬:
- .claude/skills/issue-create
- .claude/skills/issue-start
- .claude/skills/issue-end
- .claude/skills/issue-merge

설치할 Claude Code 에이전트:
- .claude/agents/issue-verifier.md
- .claude/agents/issue-merge-analyst.md
- .claude/agents/issue-merge-critic.md

먼저 홈 설치(~/.claude)와 현재 프로젝트 설치(.claude) 중 어디에 설치할지 확인해 주세요.
migrate-skill-agent 스킬이 있으면 각 항목을 --flavor claude로 설치하고, 없으면 저장소를 안정적인 경로에 clone한 뒤 위 폴더와 파일을 대상 위치로 복사해 주세요.
SKILL.md 하나만 복사하지 말고 references와 scripts를 포함한 스킬 폴더 전체를 설치해 주세요.
기존 대상이 있으면 경로와 덮어쓸 내용을 보여 주고 명시적으로 승인받은 뒤 설치해 주세요. 백업과 롤백이 없다는 점도 먼저 알려 주세요.
설치 후 일곱 항목의 존재 여부와 git, Node 18+, curl, gh 로그인 상태를 검증해 주세요. 프론트엔드 증거를 캡처할 저장소라면 Playwright와 webp 변환 도구(sharp, cwebp, ffmpeg 중 하나)도 확인해 주세요.
gh 인증이 안 되어 있으면 gh-setup 스킬로 설치와 로그인을 이어서 진행해 주세요. gh-setup이 없으면 공식 gh 설치 방법과 gh auth login 명령을 안내해 주세요.

공통 전제와 이슈 백엔드

• 공통 도구는 git, Node 18+, curl, 로그인된 GitHub CLI(gh)입니다.
• GitHub 이슈를 쓰면 별도 provider 설정 없이 시작할 수 있습니다.
• Jira를 쓰면 ~/.issue/settings.json의 provider.jira와 토큰 환경변수를 설정합니다.
• Jira를 이슈 백엔드로 써도 PR 생성과 merge는 GitHub에서 하므로 gh 로그인이 필요합니다.

권장 사용 흐름

변경 요청
  → issue-create  이슈 분리·중복 확인·등록
  → issue-start   이슈 분석·구현·증거와 리포트 게시
  → 사람 검토·승인
  → issue-end     게시 상태 재확인·PR 생성
  → issue-merge   여러 PR 통합·재검증·이슈 종료

단일 작업은 issue-create → issue-start → 검토·승인 → issue-end로 진행하고, 준비된 PR의 merge·재검증·이슈 종료는 issue-merge로 마칩니다.

여러 작업은 이슈마다 별도 세션과 워크트리에서 issue-start → issue-end를 실행합니다. 모든 PR이 준비된 뒤 한 세션에서 issue-merge를 호출해 충돌과 통합 동작을 함께 검증합니다. 같은 워크트리에서 여러 이슈를 동시에 시작하지 않습니다.

Best use case

issue-create의 목표는 하나입니다. 사용자의 변경 요청이 기본 브랜치에서 바로 시작되지 않게 막고 이슈로 먼저 등록하는 것.

"이거 고쳐줘 / 이 기능 추가해줘 / 이거 지워줘"로 작업이 시작되면 이슈 없이 바로 코드로 들어가기 쉽습니다. 그러면 착수 분석도, 이슈 번호 기반 브랜치도, 증거 코멘트도 붙일 곳이 없어집니다.

이 스킬은 변경성 요청을 받았는데 연결된 이슈가 없을 때 발동합니다. 먼저 저장소가 이슈를 만들 만큼 자리 잡았는지 신호로 판정하고, 요청 안에 독립 작업이 여러 개면 그만큼 이슈를 나눈 뒤, 항목마다 유사한 열린 이슈를 검색하고, issue-start가 그대로 읽을 수 있는 형식으로 초안을 만들어 승인을 받고 등록합니다.

이슈 하나 = 워크트리 하나 = PR 하나가 뒤 단계의 전제입니다. 여러 작업을 이슈 하나에 뭉치면 issue-start가 브랜치 하나로 여러 가지를 건드리고, issue-end의 증거가 무엇을 증명하는지 흐려지고, issue-merge가 되돌릴 단위를 잃습니다.

Codex 호출 예시

$issue-create 탭 활성 상태가 새로고침 후 초기화되는 문제

Claude Code 호출 예시

/issue-create 탭 활성 상태가 새로고침 후 초기화되는 문제

복합 요청도 그대로 넘기면 됩니다.

대시보드에 기간 필터 넣고, 주문 목록 가끔 비는 것도 고치고, 안 쓰는 export 스크립트도 지워줘
→ 이슈 3건으로 분할안 제시 → 승인 → 초안 3건 일괄 승인 → 순차 등록

명시적으로 부르지 않아도, 운영 중인 저장소에서 이슈 번호 없이 코드 변경 요청이 들어오면 작업 크기와 관계없이 먼저 발동합니다. 빈 폴더나 막 git init한 프로젝트의 초기 뼈대를 만드는 요청은 이슈 없이 그대로 진행합니다.

자동 개입이 너무 강하면 ~/.issue/settings.json에서 암묵 호출만 끌 수 있습니다.

{
  "issue": {
    "createMode": "direct"
  }
}

issue-first가 기본값이며 기존처럼 이슈부터 만듭니다. direct는 암묵적으로 발동한 issue-create가 조용히 빠지고 원래 변경 요청을 계속하게 합니다. $issue-create, /issue-create, "이슈 만들어줘"처럼 명시적으로 호출하면 direct에서도 이슈를 만듭니다. 알 수 없는 값은 경고 후 issue-first로 돌아갑니다.

라벨 체계

라벨은 두 축입니다. 한 이슈에 성격 라벨 하나와 진행 상태 라벨 하나가 함께 붙습니다.

성격 라벨         의미                issue-start 브랜치 prefix
bug              동작이 잘못됨        fix/
enhancement      기능 추가·개선       feat/
documentation    문서                docs/
chore            정리·설정·의존성      chore/

진행 상태 라벨      전환 시점                              전환 주체
status:open        이슈 등록 직후                          issue-create  (자동)
status:plan        이슈 수집 직후 — 분석·계획 시작           issue-start   (자동)
status:in-process  워크트리 생성 직후 — 구현 시작            issue-start   (자동)
status:review      PR 생성 직후                            issue-end     (수동 호출)
status:close       이슈 close 직전                         issue-merge   (자동)

동작

1. 암묵 호출이면 mode로 issue.createMode를 확인하고, direct면 원래 요청으로 복귀
2. gate로 커밋 수, 원격, 이슈/PR 이력, 빌드 설정, 소스 규모를 확인해 READY / ASK / SKIP 판정
3. 요청에서 원자 후보를 추출하고 API/UI 계약, 공통 완료 기준·근본 원인, 배포·마이그레이션 결합만 그룹화한 뒤, 별도 배포·검증·취소·되돌리기가 가능한 그룹을 분리해 제목·요약·예상 라벨 목록만 먼저 보여줘 분할안 승인 (상한 5건)
4. 항목마다 search로 유사한 열린 이슈를 찾고, 걸린 항목만 건너뛴 채 나머지는 계속 진행
5. 항목마다 frontend / backend / both를 판정해 본문 항목과 라벨을 결정
6. 초안 전문을 한 번에 보여주고 일괄 승인받은 뒤, 설정된 GitHub 또는 Jira 이슈 백엔드에 항목별로 등록하고 status:open 자동 부착 (한 건이 실패해도 나머지는 계속)
7. unlabeled로 성격·진행 상태 라벨이 빠진 기존 이슈를 찾아 제안 목록을 만들고, 승인받아 일괄 보정
8. .issue/<번호>/request.md에 원본 요청과 그 이슈가 맡는 범위를 남기고, .gitignore에 .issue 블록을 자동 등록한 뒤 첫 번호로 issue-start 인계 (나머지 번호는 안내만)

전제 확인·중복 검사·성격 판정은 issue-verifier 서브에이전트에 맡깁니다 (Claude는 haiku, Codex는 gpt-5.6-luna).

하지 않는 일

• 코드 수정. 이슈 생성까지만 합니다
• 승인 없는 등록, 승인 없는 라벨 생성, status:open 자동 부착 외의 상태 변경, 코멘트·PR 생성
• 이미 성격 라벨이 있는 이슈의 라벨 변경·제거 (추가만 합니다. status:*는 상호배타라 예외적으로 교체합니다)
• 게이트가 SKIP이면 아무 말 없이 빠집니다
• 억지 분할이나 억지 병합. 라벨이 같아도 독립 작업이면 나누고, 강결합된 후보만 이슈 하나의 체크리스트로 묶습니다
• 형제 이슈 간 #N 상호 참조. 등록 시점에 서로의 번호를 모르고, 등록 후 본문 수정은 이 스킬의 권한 밖입니다
• 여러 이슈 동시 착수. 워크트리가 충돌하므로 첫 번호로만 인계합니다

관련 파일

.claude/skills/issue-create/SKILL.md
.claude/skills/issue-create/references/{provider-settings,maturity-gate,split-requests,issue-draft,label-audit,create-and-handoff,next-actions}.md
.claude/skills/issue-create/scripts/issue-create.mjs   # mode / gate / search / labels / create / unlabeled / label / ensure-label / status
.claude/skills/issue-create/scripts/issue-common.mjs   # 공용 모듈 (vendored)
.codex/skills/issue-create/  (같은 구성 + agents/openai.yaml)
scripts/test-issue-create.sh                           # gh 를 부르지 않는 경로의 회귀 테스트
evals/issue-create/trigger-eval.json                   # description 트리거 회귀 셋 (30문항, 튜닝용)
evals/issue-create/holdout-eval.json                   # 튜닝에 쓰지 않은 검증 셋 (10문항)
evals/issue-create/run-trigger-eval.mjs                # 위 두 셋을 실제로 돌려 recall/specificity 를 재는 실행기
evals/issue-create/split-eval.json                     # 원자 분해 개선용 데이터 (400문항)
evals/issue-create/split-holdout.json                  # 원자 분해 검증 셋 (100문항)
evals/issue-create/{generate,validate}-split-dataset.mjs
evals/issue-create/run-split-eval.mjs                  # 분할 경계·라벨·상한 처리 평가

요구사항은 git, 로그인된 gh, Node 18 이상입니다.

description과 분해 프롬프트를 고칠 때

이 스킬은 명시 호출 없이도 발동해야 하므로 frontmatter 의 description 이 곧 기능입니다. 감으로 고치지 말고 실측하세요.

node evals/issue-create/run-trigger-eval.mjs --set tuning     # 문구를 다듬는 동안 돌리는 회귀 셋
node evals/issue-create/run-trigger-eval.mjs --set holdout    # 문구를 확정한 뒤 마지막에 한 번만
node evals/issue-create/validate-split-dataset.mjs             # 500문항 스키마·중복·분포 검사
node evals/issue-create/run-split-eval.mjs --set tuning --sample 50 --repeat 2 --out /tmp/split-tuning.json
node evals/issue-create/run-split-eval.mjs --set holdout --sample 100 --out /tmp/split-holdout.json

트리거 평가는 스킬이 호출됐는지 측정하고, 분해 평가는 호출된 뒤 요청을 어떻게 나눴는지 측정합니다. 둘은 목적이 달라 기존 트리거 셋을 분해 데이터로 재사용하지 않습니다.

분해 데이터는 개선용 400문항과 홀드아웃 100문항으로 나뉩니다. 25개 산업, 네 가지 문체, 단일·전체 분리·부분 결합·5개 초과 사례를 포함합니다. 모든 문항에는 원자 요구사항, 기대 그룹, 라벨, 의존 관계, 판정 근거가 들어 있습니다. generate-split-dataset.mjs --check는 커밋된 데이터가 고정 생성 규칙과 같은지 확인하고, validator는 두 셋 사이 ID·문장 중복과 분포 편중을 막습니다.

run-split-eval.mjs는 루브릭과 요청을 모델에 주고 JSON-only 응답을 받아 원자 요구 F1, 이슈 수 정확도, 그룹 완전일치, 쌍별 그룹 F1, 라벨 정확도, 과소·과대 분할률, 5개 상한 처리 정확도를 계산합니다. --sample, --repeat, --concurrency, --cache로 호출 비용을 조절하고, --responses로 저장된 응답을 모델 호출 없이 다시 채점할 수 있습니다. 기존 루브릭은 baseline-split-rubric.md에 보존돼 있어 --rubric으로 같은 데이터에서 전후를 비교할 수 있습니다.

실행기는 커밋 35개짜리 픽스처 저장소를 임시로 만들어 이 저장소의 스킬을 전부 설치한 뒤, 질의를 헤드리스 claude 에 던져 Skill 도구가 issue-create 를 부르는지 셉니다. 홈(~/.claude/skills) 의 스킬은 --setting-sources project 로 배제하므로 경쟁 상대는 저장소에 든 스킬뿐입니다. 기본값은 sonnet 모델에 질의당 3회, 동시 3개이며 --repeat / --model / --concurrency 로 바꿉니다. 개선 전 문구를 같은 조건에서 다시 재려면 --description @<파일> 로 갈아끼우세요. --out <파일> 을 주면 질의별 결과까지 JSON 으로 남습니다.

측정 조건이 결과를 크게 흔듭니다. 두 가지를 실제 환경과 맞춰야 합니다.

• 도구셋 — 기본값 --tools default. Edit / Write / Bash 를 빼면 모델이 코드로 직행할 길이 막혀 Skill 쪽으로 쏠립니다. 정작 이 스킬이 겪는 미발동은 "스킬을 건너뛰고 코드로 직행"하는 상황이라, 도구를 좁히면 문제 자체가 재현되지 않습니다
• 경쟁 스킬 — 기본값 --skills all. issue-* 만 깔면 스킬 목록 자체가 "이 저장소는 이슈 워크플로를 쓴다" 는 힌트가 되어 recall 이 부풀려집니다. 같은 문구가 스킬 5개 조건에서 recall 1.000, 13개 조건에서 0.933 으로 갈렸습니다

동시 실행을 6 이상으로 올리면 API 가 요청을 거절해 전 시행이 실패할 수 있습니다. 실패는 백오프 후 두 번까지 다시 시도하고, 그래도 실패하면 집계에서 빼고 사유를 출력합니다.

• trigger-eval.json — 발동해야 하는 15문항 + 발동하면 안 되는 15문항. 발동하면 안 되는 쪽은 issue-start / issue-end / issue-merge / gh-setup 과 헷갈리기 쉬운 근접 사례입니다
• holdout-eval.json — 문구를 다듬을 때 보지 않고 마지막에만 돌리는 검증 셋 10문항. 튜닝 셋에서만 오르는 과적합을 걸러냅니다
• 채택 기준은 검증 셋 recall 상승 + specificity 가 개선 전 이상입니다. 튜닝 셋 점수만 오르면 채택하지 않습니다

현재 문구의 측정값은 아래와 같습니다. 위 기본 조건에서 질의당 3회씩 돌려 잰 값입니다.

                  recall   specificity   accuracy
개선 전 (30문항)    0.933      0.933        0.933
개선 후 (30문항)    1.000      0.933        0.967
개선 전 (검증 10)   0.933      1.000        0.967
개선 후 (검증 10)   1.000      1.000        1.000

개선 전 문구가 놓친 것은 삭제 요청이었습니다. scripts/export-legacy.mjs 이거 안 쓰는 것 같은데 지워도 될까? 처럼 물음표로 끝나는 정리 요청과 legacy 결제 어댑터 걷어내자 같은 코드 제거 요청에서 발동하지 않았습니다. 새 문구가 "안 쓰는 코드·플래그·스크립트 삭제"와 "물음표로 끝나는 정리 요청"을 명시해 이 사각지대를 메웠습니다.

남은 오발동은 두 가지입니다. 빈 폴더에서 시작하는 중입니다 류의 스캐폴딩 요청이 3회 중 1회, 이슈들 라벨이 엉망이야 류의 라벨 정리 요청이 3회 중 2회 발동합니다. 뒤쪽은 개선 전에도 3회 중 3회 발동하던 항목으로, 이 스킬이 실제로 라벨 보정 기능을 갖고 있어 경계가 본질적으로 흐립니다.

한계도 남습니다. Claude 는 스스로 처리 가능한 단순 요청에는 스킬 목록을 조회하지 않습니다. description 으로 끌어올릴 수 있는 상한이 있고, 위 수치는 그 상한 안에서의 값입니다.

Best use case

issue-start는 이슈 하나를 받아 계획 → 워크트리 → 구현 → 커밋 → 증거 → 이슈 리포트까지 끝냅니다.

이슈 본문만 훑고 바로 브랜치를 파면 스크린샷에 있던 조건이나 라벨이 가리키는 영역을 놓치기 쉽습니다. 반대로 구현만 하고 끝내면 이슈에는 "고쳤습니다"라는 말만 남아 나중에 누구도 검증할 수 없습니다.

이 스킬은 설정된 provider에서 이슈 본문·코멘트·라벨을 받아오고 첨부 이미지까지 실제로 열어봅니다. GitHub는 gh, Jira는 REST API를 사용합니다. 코드베이스와 대조해 계획을 세우고, 워크트리를 만들고, 파일을 고치기 전에 before를 찍고, 구현하고, 커밋하고, after를 바운딩 박스와 함께 찍습니다. 증거는 기본 브랜치 미러를 우선하고, 보호된 저장소에서는 evidence/issue-<번호> 브랜치로 올린 뒤 이슈에 렌더링되는 전후 리포트를 남깁니다.

적합한 작업:

• 스크린샷이 붙은 버그 이슈 착수
• 이슈 하나당 워크트리 하나로 병렬 작업하는 흐름
• 전후 비교가 남아야 하는 UI 변경이나 성능 개선

부적합한 작업:

• 이미 워크트리가 있고 마무리만 남은 상태 (→ issue-end)
• 여러 워크트리를 합치는 단계 (→ issue-merge)

Codex 호출 예시

$issue-start #59

Claude Code 호출 예시

/issue-start #59

이슈 번호 대신 작업 설명을 넣어도 됩니다. 그러면 plan 모드로 전환한 뒤 이슈로 먼저 등록할지 묻고, issue-create가 설치돼 있지 않으면 자동으로 설치합니다.

/issue-start 로그인 후 리디렉트가 안 되는 문제

동작

1. 인자가 이슈 번호인지 작업 설명인지 판별. 설명이면 plan 모드 → issue-create 위임
2. 설정된 provider에서 본문·코멘트·라벨·첨부 이미지를 .issue/<번호>/에 수집 (GitHub는 gh, Jira는 REST API)
3. frontend / backend / both 판정 후 코드베이스와 대조 분석 → plan.md
4. <prefix>/<번호>-<slug> 브랜치와 워크트리 생성 (배치는 설정으로 고정)
5. 파일을 고치기 전에 before 캡처
6. 구현 → 검증 → guard 통과 시 사용자 확인 없이 커밋
7. after 캡처 (변경 구간에 바운딩 박스 필수)
8. 증거 커밋 → 브랜치 push → 기본 브랜치 미러 우선, 보호 시 evidence/issue-<번호>로 fallback → 이슈 코멘트
9. 게시된 증거와 리포트의 사람 검토·승인을 기다린 뒤 issue-end로 인계

6번의 무확인 커밋은 3중 가드를 전부 통과할 때만 합니다 — 링크된 워크트리이고, 기본 브랜치가 아니고, 브랜치에 이슈 번호가 있을 것. 하나라도 어긋나면 커밋하지 않고 확인을 받습니다.

이슈 백엔드는 GitHub 또는 Jira

~/.issue/settings.json의 provider가 정합니다. 설정하지 않으면 GitHub으로 동작하므로 기존 사용자는 아무것도 바꿀 필요가 없습니다.

{
  "provider": {
    "type": "jira",
    "jira": {
      "baseUrl": "https://acme.atlassian.net",
      "projectKey": "ACME",
      "email": "me@acme.com",
      "tokenEnv": "JIRA_API_TOKEN"
    }
  }
}

토큰 값은 설정 파일에 넣지 않고 환경변수 이름만 적습니다.

축은 둘로 나뉩니다. 이슈는 provider가 정하지만 PR은 항상 GitHub입니다 — Jira에는 PR이라는 개념이 없고, Jira로 이슈를 관리하는 팀도 코드는 GitHub에 두기 때문입니다. 그래서 Jira를 쓰더라도 gh 로그인은 여전히 필요합니다.

브랜치 이름과 .issue/<번호>/ 경로는 트래커와 무관하게 항상 숫자를 씁니다. 프로젝트 키는 설정에 있으므로 12에서 ACME-12를 언제든 다시 만들 수 있습니다.

자세한 내용은 issue-create/references/provider-settings.md를 보세요.

리포트 게시 대상: Confluence

~/.issue/settings.json의 docs가 이슈 리포트와 webp 증거의 추가 게시 대상을 정합니다. 설정이 없거나 none이면 기존 GitHub 이슈 코멘트 흐름만 실행합니다.

{
  "docs": {
    "type": "confluence",
    "confluence": {
      "baseUrl": "https://acme.atlassian.net/wiki",
      "spaceKey": "ENG",
      "parentPageId": "123456",
      "email": "me@acme.com",
      "tokenEnv": "CONFLUENCE_API_TOKEN"
    }
  }
}

토큰 값은 설정 파일에 넣지 않고 CONFLUENCE_API_TOKEN 환경변수로 둡니다. 증거 커밋 단계가 {이슈키} {제목} 페이지를 만들거나 같은 제목의 기존 페이지를 갱신하고, webp를 첨부해 본문에서 참조합니다. 성공한 페이지 URL은 GitHub 리포트에도 함께 기록됩니다.

Confluence 권한·공간 정책·네트워크 오류는 경고로만 남깁니다. 이 오류 때문에 커밋·PR 흐름이 멈추지는 않습니다.

워크트리 배치는 한 번만 묻습니다

처음 실행할 때 ~/.issue/settings.json에 배치 방식을 고정하고, 이후 issue-create / issue-start / issue-end / issue-merge 어디서 들어오든 같은 값을 씁니다.

layout	경로
sibling	../<repo>-issue-<번호>
children	<repo>/.issue/worktrees/<번호>-<slug>

children은 워크트리가 프로젝트 안에 생기므로, 스크립트가 git check-ignore로 실제 무시 여부를 확인하고 안 걸리면 생성을 중단합니다. 예전 설정의 nested는 더 이상 유효하지 않아 처음 한 번 배치를 다시 선택합니다.

증거 이미지는 webp + 바운딩 박스

캡처는 Playwright로 하고 sharp → cwebp → ffmpeg 순으로 webp 변환합니다. 바운딩 박스는 sharp 합성이 아니라 브라우저 DOM 오버레이로 그리므로 변환 폴백 경로에서도 남습니다.

node capture.mjs --url http://localhost:3000/orders --out .issue/59/evidence/after/orders.webp \
  --full --box ".order-row:first-child .status" --box-label "상태 배지"

before에도 같은 셀렉터로 박스를 그려 같은 눈높이에서 비교되게 합니다.

하지 않는 일

• PR 생성과 merge — 각각 issue-end와 issue-merge의 몫입니다. 상태는 수집 시 status:plan, 워크트리 생성 시 status:in-process로만 자동 전환합니다
• 기본 브랜치에서의 구현. 워크트리 밖이면 커밋 자체를 막습니다

관련 파일

.claude/skills/issue-start/SKILL.md
.claude/skills/issue-start/references/{intake,issue-collection,frontend-analysis,backend-analysis,worktree,implementation,evidence-capture,next-actions}.md
.claude/skills/issue-start/scripts/issue-start.mjs   # fetch / worktree / guard / evidence-* / migrate
.claude/skills/issue-start/scripts/capture.mjs       # Playwright → webp + 바운딩 박스
.claude/skills/issue-start/scripts/issue-common.mjs  # 공용 모듈 (vendored)
.codex/skills/issue-start/  (같은 구성 + agents/openai.yaml)

요구사항은 git, 로그인된 gh, curl, Node 18 이상이고, 프론트 캡처에는 Playwright와 webp 변환 도구가 필요합니다.

Best use case

issue-end는 issue-start가 증거와 리포트를 게시하고 사람이 승인한 작업을 PR로 마무리합니다.

기존 증거의 완결성과 원격 게시 상태를 다시 봅니다. 게시본이 로컬 증거와 같으면 반복 게시하지 않고 PR을 준비합니다. 부족하거나 바뀐 경우에만 before/after와 리포트를 보강해 재게시한 뒤 PR을 만듭니다.

context의 evidencePublished가 게시본과 로컬 증거의 일치 여부를 알려 줍니다. false면 PR 전에 기본 브랜치 또는 evidence/issue-<번호> 브랜치로 재게시하고 이슈 코멘트를 갱신합니다.

Codex 호출 예시

$issue-end

Claude Code 호출 예시

/issue-end

동작

1. context로 워크트리·브랜치·이슈·PR·증거 완결성과 게시 상태를 판단
2. 증거가 부족하면 pure-tree로 변경 직전 상태를 만들어 before 재캡처
3. 게시본과 로컬 증거가 다를 때만 after·comment.md 보강
4. 필요 시 증거 커밋 → 브랜치 push → 기본/폴백 브랜치 재게시 → 이슈 코멘트 갱신
5. issue-start에서 받은 검토 승인을 확인
6. 자동 close 키워드 없이 관련 이슈 #N을 참조해 PR 생성
7. 다음 행동 4지선다

issue-start가 게시한 증거와 같으면 다시 미러하지 않습니다. 승인 뒤 증거가 바뀌었다면 게시본도 함께 갱신한 뒤 다시 승인을 확인합니다.

before 재캡처는 stash가 아니라 워크트리로

git stash는 실패하면 사용자의 작업이 stash에 갇히고, 실행 중인 dev server 발밑에서 파일이 바뀌어 캡처가 오염됩니다. 대신 git merge-base origin/<base> HEAD 기준의 detached 워크트리를 만듭니다. 순수 추가 연산이라 실패해도 원복이 필요 없습니다.

merge는 하지 않습니다

여러 워크트리를 동시에 굴리는 것이 이 스킬군의 전제라, 하나를 먼저 merge하면 나머지의 기준선이 흔들립니다. 마지막 단계에서 다음 행동을 묻고, merge를 고르면 issue-merge로 넘깁니다.

1. 다른 이슈 착수 (권장)   → /issue-start
2. 워크트리 전부 merge      → /issue-merge
3. 새 이슈 등록            → /issue-create
4. 종료

워크트리와 브랜치도 지우지 않습니다. 정리는 issue-merge가 통합을 마친 뒤에 합니다.

워크트리가 아니거나 이슈가 없어도 동작

• 워크트리가 아니면 현재 브랜치에서 진행할지 먼저 묻습니다
• 이슈가 없으면 no-issue-<브랜치> 키를 쓰고 코멘트 단계만 건너뜁니다 (기본 브랜치 증거 커밋은 그대로)
• 증거가 아예 없으면 issue-start로 돌아갈지 묻습니다. 증거 없이 PR을 만드는 선택지는 제시하지 않습니다

관련 파일

.claude/skills/issue-end/SKILL.md
.claude/skills/issue-end/references/{context-triage,evidence-recheck,report-and-pr,next-actions}.md
.claude/skills/issue-end/scripts/issue-end.mjs   # context / init / commit / mirror / urls / pure-tree
.claude/skills/issue-end/scripts/capture.mjs     # Playwright → webp + 바운딩 박스
.claude/skills/issue-end/scripts/issue-common.mjs
.codex/skills/issue-end/  (같은 구성 + agents/openai.yaml)

요구사항은 git, 로그인된 gh, Node 18 이상이고, 재캡처에는 Playwright와 webp 변환 도구(sharp / cwebp / ffmpeg 중 하나)가 필요합니다.

Best use case

issue-merge는 동시에 굴리던 워크트리들을 한 번에 합칩니다.

개별 PR을 하나씩 merge하는 것과 다른 점은, 합친 뒤 서로 깨지지 않았는지 각 이슈의 증거 기준으로 재검증한다는 것입니다. 개별로는 통과했는데 합치니 깨지는 경우를 잡아냅니다.

Codex 호출 예시

$issue-merge

Claude Code 호출 예시

/issue-merge

issue-end의 마지막 단계에서 merge를 고르면 자동으로 여기로 넘어옵니다.

동작

0. base-tree로 기본 브랜치 전용 임시 워크트리 생성 — 사용자의 작업 트리는 건드리지 않습니다
1. inventory로 워크트리·이슈·PR·증거 상태 수집
2. 각 이슈의 완료 기준을 실제로 읽음
3. 증거로 해결 여부를 판정해 merge 후보 확정 (커밋 메시지는 근거가 아닙니다)
4. 워크트리 개수만큼 issue-merge-analyst를 병렬로 띄워 .issue/merge/16-21-53-64/plan.md 작성
5. issue-merge-critic으로 모호성·검증되지 않은 전제·되돌릴 수 없는 순서를 검토
6. 계획 승인 후 각 PR마다 별도 merge 승인을 받고 순서대로 merge → 각 이슈의 증거 조건으로 통합 테스트
7. 재검증을 통과한 것만 이슈 close

비판 에이전트가 block을 내면 계획을 고치기 전에는 merge하지 않습니다. 같은 계획으로 두 번 연속 block이면 자동 수정을 멈추고 사용자에게 넘깁니다.

하지 않는 일

• CI가 실패한 PR의 merge
• 통합 테스트 전의 이슈 close
• evidence/issue-* 브랜치 삭제 — 증거 URL이 의존합니다
• 여러 PR을 묶어서 한 번에 승인받기

관련 파일

.claude/skills/issue-merge/SKILL.md
.claude/skills/issue-merge/references/{inventory,merge-plan,verify-and-close,next-actions}.md
.claude/skills/issue-merge/scripts/issue-merge.mjs   # inventory / base-tree / plan-dir / merge / close / cleanup
.claude/skills/issue-merge/scripts/issue-common.mjs
.claude/agents/{issue-merge-analyst,issue-merge-critic}.md
.codex/skills/issue-merge/  (같은 구성 + agents/openai.yaml)
.codex/agents/{issue-merge-analyst,issue-merge-critic}.toml

요구사항은 git, 로그인된 gh, Node 18 이상입니다.

Best use case

visual-companion은 기획 문서, 요구사항, 인터뷰 중 말로만 설명하기 어려운 선택지를 브라우저 화면으로 보여줄 때 씁니다.

텍스트 질문만으로는 서로 같은 장면을 떠올리고 있는지 확인하기 어렵습니다. 특히 화면 구성, 플로우, 정보 구조, 비교안처럼 시각적 판단이 필요한 주제는 말로만 좁히면 오해가 생기기 쉽습니다.

이 스킬은 그런 순간에 선택지, 와이어프레임, 다이어그램, 비교안을 브라우저에 띄웁니다. 사용자가 고른 값이나 짧은 입력을 다시 세션으로 가져와 다음 인터뷰나 기획 문서에 씁니다.

적합한 작업:

• ouroboros interview 중 시각 선택지가 필요한 요구사항 정리
• oh-my-claudecode deep-interview에서 사용자가 브라우저로 고른 값을 Claude Code가 이어받는 흐름
• 기획 문서 작성 중 레이아웃, 정보 구조, 사용자 흐름, 다이어그램을 눈으로 보고 골라야 하는 순간

부적합한 작업:

• 단순 텍스트 질문
• API 설계, 데이터 모델링처럼 표나 문장으로 충분한 결정
• 시각 자료 없이 가능한 요구사항 정리

Hermes Agent 호출 예시

ooo interview "결제 플로우 요구사항이 말로만 정리되어 애매합니다" UI/UX 에 대한 결정을 해야하는 질문에서는 visual-companion 스킬을 사용해서 인터뷰를 이어서 진행하세요.

Codex 호출 예시

$ouroboros interview "결제 플로우 요구사항이 말로만 정리되어 애매합니다" UI/UX 에 대한 결정을 해야하는 질문에서는 $visual-companion 스킬을 사용해서 인터뷰를 이어서 진행하세요.

$deep-interview "결제 플로우 요구사항이 말로만 정리되어 애매합니다" UI/UX 에 대한 결정을 해야하는 질문에서는 $visual-companion 스킬을 사용해서 인터뷰를 이어서 진행하세요.

Claude Code 호출 예시

/ouroboros interview "랜딩 페이지 방향을 정해야 해." UI/UX 에 대한 결정을 해야하는 질문에서는 $visual-companion 스킬을 사용해서 인터뷰를 이어서 진행하세요.

/deep-interview "랜딩 페이지 방향을 정해야 해." UI/UX 에 대한 결정을 해야하는 질문에서는 $visual-companion 스킬을 사용해서 인터뷰를 이어서 진행하세요.

Best use case

개발 서버를 다시 띄우려는데 3000, 5173, 8080 같은 포트가 이미 사용 중일 때 씁니다.

Codex 호출 예시

$kill-process 3000

kill-process 스킬로 3000번과 5173번 포트를 비우고, 종료 후 포트가 비었는지 확인해줘.

Claude Code 호출 예시

/kill-process 3000

/kill-process 3000 5173

동작

1. lsof -ti :<port>로 PID를 찾습니다.
2. PID가 있으면 프로세스를 종료합니다.
3. 같은 포트를 다시 확인해 비워졌는지 검증합니다.

Best use case

GitHub 저장소의 특정 스킬 폴더를 현재 프로젝트의 .codex/skills/ 또는 .claude/skills/로 내려받을 때 씁니다.

Codex 호출 예시

$install-skill https://github.com/Mineru98/skills-store/tree/main/.codex/skills/visual-companion

install-skill로 아래 Codex 스킬을 전역 스킬 폴더에 설치해줘.
https://github.com/Mineru98/skills-store/tree/main/.codex/skills/kill-process

Claude Code 호출 예시

install-skill 스킬로 아래 Claude Code 스킬을 설치해줘.
https://github.com/Mineru98/skills-store/tree/main/.claude/skills/visual-companion

GitHub의 .claude/skills/premium-korean-aesthetic 폴더를 현재 프로젝트 Claude 스킬로 설치해줘.
https://github.com/Mineru98/skills-store/tree/main/.claude/skills/premium-korean-aesthetic

포함 파일

.codex/skills/install-skill/script/install-skill.js
.claude/skills/install-skill/script/install-skill.js

Best use case

skills-store에 있는 특정 skill 또는 agent를 홈 디렉터리나 현재 프로젝트의 .codex/와 .claude/ 자산으로 가져올 때 씁니다.

외부 GitHub URL을 직접 내려받는 install-skill과 달리, 이 스킬은 로컬 skills-store 저장소를 찾아 git pull로 최신화한 뒤 지정한 항목만 복사합니다.

Codex 호출 예시

$migrate-skill-agent --skill slide-ko-polish --target home

$migrate-skill-agent --agent songcopy --target project

Claude Code 호출 예시

migrate-skill-agent 스킬로 slide-ko-polish를 홈 디렉터리에 설치해줘.

migrate-skill-agent 스킬로 songcopy agent를 현재 프로젝트에 설치해줘.

옵션

• --skill <name>: skill만 검색해서 설치
• --agent <name>: agent만 검색해서 설치
• --target home: ~/.codex와 ~/.claude 아래에 설치
• --target project: 현재 프로젝트의 .codex와 .claude 아래에 설치

포함 파일

.codex/skills/migrate-skill-agent/scripts/migrate-skill-agent.sh
.claude/skills/migrate-skill-agent/scripts/migrate-skill-agent.sh

Best use case

발표자료, 블로그, 문서, 채팅에 넣을 귀여운 무료 일러스트가 필요할 때 씁니다.

사용자의 한국어/영어 설명을 일본어 검색어로 줄여 irasutoya CLI를 실행하고, 제목, 페이지 URL, 이미지 URL, 매칭 이유를 보고합니다. 새 이미지를 생성하지 않고 이라스토야 기존 카탈로그만 검색합니다.

Codex 호출 예시

$irasutoya-search
발표 자료에 쓸 건데, 뭔가 신기한 걸 발견하고 궁금해하는 남자아이 일러스트 하나 찾아줘.

irasutoya search "不思議 男の子"
irasutoya random

Claude Code 호출 예시

irasutoya-search 스킬로 컴퓨터 앞에서 곤란해하는 회사원 이미지를 찾아줘.

irasutoya search "困った 会社員"

포함 파일

.codex/skills/irasutoya-search/SKILL.md
.codex/skills/irasutoya-search/agents/openai.yaml
.claude/skills/irasutoya-search/SKILL.md
.claude/skills/irasutoya-search/evals/evals.json

추천 순서

1. e2e-flow-planner - Critical User Flow 기반 E2E 계획서 작성
2. e2e-harness-setup - E2E 테스트 하네스와 운영 규칙 부트스트랩
3. e2e-test-generator - 검토된 계획서를 Playwright 테스트로 구현
4. e2e-test-hardener - 생성된 테스트의 독립성, 모킹, 플래키 예방 보강
5. e2e-test-healer - 실패한 Playwright 테스트를 trace 기반으로 진단하고 수정
6. e2e-ci-trace-debug - GitHub Actions E2E 실패 trace를 내려받아 원인 추적

Codex 호출 예시

$e2e-flow-planner
결제 플로우의 Critical User Flow를 기준으로 E2E 테스트 계획서를 작성해줘.

$e2e-test-healer
실패한 Playwright 테스트 trace를 보고 원인을 찾아 통과하게 수정해줘.

Claude Code 호출 예시

e2e-harness-setup 스킬로 이 프로젝트의 Playwright 테스트 하네스를 온보딩해줘.

e2e-ci-trace-debug 스킬로 PR의 실패한 E2E 체크 trace를 받아 원인을 찾아줘.

스킬별 요약

• e2e-flow-planner: 코드베이스와 요구사항을 읽고 E2E 테스트 계획서 작성
• e2e-harness-setup: AGENTS.md 안내, E2E 운영 규칙, fixture/helper, MCP 배선 준비
• e2e-test-generator: 계획서를 Playwright 코드로 구현하고 실제 브라우저로 확인
• e2e-test-hardener: 테스트 독립성, 외부 의존성 모킹, 플래키 예방 원칙 적용
• e2e-test-healer: 실패한 Playwright 테스트의 trace를 근거로 자동 치유 루프 수행
• e2e-ci-trace-debug: PR 또는 GitHub Actions 실패에서 trace와 로그를 추적해 수정

Best use case

영어 원문을 한국어로 옮긴 HTML/Markdown 발표자료에서 번역체 표현, 무거운 명사문, 한국어 어절 줄바꿈 문제를 같이 점검할 때 씁니다.

검증 스크립트는 regex/HTML 구조 검사와 LLM fresh review를 묶어서 실행합니다. LLM CLI는 claude, codex, gemini 순으로 자동 감지하며, LLM_CLI 환경변수로 고정할 수 있습니다.

Codex 호출 예시

$slide-ko-polish
slides.html의 한국어가 번역체인지 점검하고, 어색한 문장과 줄바꿈을 다듬어줘.
검증은 verify.sh까지 실행해줘.

.codex/skills/slide-ko-polish/verify.sh slides.html
.codex/skills/slide-ko-polish/polish-loop.sh slides.html

Claude Code 호출 예시

/slide-ko-polish slides.html의 한국어 번역체와 CJK 줄바꿈을 다듬어줘.

.claude/skills/slide-ko-polish/verify.sh slides.html
.claude/skills/slide-ko-polish/polish-loop.sh slides.html

Gemini CLI에서 직접 실행

LLM_CLI=gemini .codex/skills/slide-ko-polish/verify.sh slides.html
LLM_CLI=gemini .codex/skills/slide-ko-polish/polish-loop.sh slides.html

라이선스 인용

이 스킬은 hackertaco/skill-forge의 slide-ko-polish를 프로젝트용 Codex/Claude 스킬로 등록한 것입니다.

원본 라이선스는 MIT License이며 저작권 표기는 Copyright (c) 2026 hackertaco입니다. 전체 라이선스 전문은 각 플랫폼 스킬 폴더의 LICENSE에 포함했습니다.

Best use case

Codex 프롬프트를 정해진 주기로 반복하거나(loop) cron·특정 시각에 예약해서(schedule) 비대화식으로 실행할 때 씁니다. 두 스킬은 서로 독립이며 상태·데몬·락을 각자 관리합니다.

• loop - 고정 간격 반복. 예: /loop 10m check CI status. 상태는 .codex/loop/.
• schedule - cron 또는 특정 시각 1회. 예: /schedule --cron "0 9 * * 1" summarize open PRs, --at <ISO-8601>. 상태는 .codex/schedule/.

상시 durable 스케줄이 필요하면 Codex 앱 Automations를 먼저 권장하고, 이 스킬은 터미널 로컬 폴백입니다. daemon이 떠 있어야만 작업이 발화됩니다.

schedule은 기본적으로 auto runner를 사용해 due 프롬프트를 다음 순서로 전달합니다.

1. tmux-send - --tmux-target 또는 TMUX_PANE이 실행 중인 Codex pane을 가리키면 그 pane에 붙여넣고 Enter를 입력합니다.
2. resume-command - --resume-command가 있으면 해당 로컬 hook을 실행하고 프롬프트를 stdin으로 전달합니다.
3. codex-exec - 둘 다 없으면 호환성을 위해 새 codex exec 실행으로 fallback합니다.

Codex 호출 예시

$loop 5분마다 CI 상태를 확인해줘.

$schedule 매주 월요일 오전 9시에 열린 PR을 요약해줘.

# loop: 간격 작업 등록 후 데몬 실행
node .codex/skills/loop/scripts/loop.mjs add --state-root .codex/loop --interval 10m --prompt "check CI status" --cwd "$PWD"
node .codex/skills/loop/scripts/loop.mjs daemon --state-root .codex/loop

# schedule: cron 작업 등록 후 데몬 실행
node .codex/skills/schedule/scripts/schedule.mjs add --state-root .codex/schedule --cron "0 9 * * 1" --prompt "summarize open PRs" --cwd "$PWD"
node .codex/skills/schedule/scripts/schedule.mjs daemon --state-root .codex/schedule --runner auto --tmux-target "$TMUX_PANE"

안전 기본값

• --codex-arg 통과는 기본 거부 화이트리스트로, 샌드박스·승인·설정 우회 인자를 차단합니다.
• schedule은 tmux 입력 주입, 로컬 resume hook, codex exec 순서로 선택합니다. 필요하면 --runner tmux-send, --runner resume-command, --runner codex-exec로 특정 모드를 강제할 수 있습니다.
• Codex 승인/샌드박스 기본값을 약화하지 않고 OS cron/launchd도 설치하지 않습니다.
• 실행 증거는 .codex/{loop,schedule}/runs/에 남습니다. 상태·락·runs는 로컬 전용이라 커밋하지 않습니다.

포함 파일

.codex/skills/loop/scripts/loop.mjs
.codex/skills/loop/references/loop-contract.md
.codex/skills/schedule/scripts/schedule.mjs
.codex/skills/schedule/references/schedule-contract.md

Codex 호출 예시

$ai-slop-document-auditor
proposal.pdf의 한국어 카피가 AI-feel인지 점검하고, 근거와 수정 우선순위를 알려줘.

$gpt-55-prompt-architect
기존 GPT-4용 시스템 프롬프트를 GPT-5.5용으로 마이그레이션해줘.
목표, 검증 루프, 도구 사용 규칙을 명확히 정리해줘.

$commit
현재 변경 파일을 기능별로 묶어 커밋해줘.

Claude Code 호출 예시

ai-slop-document-auditor 스킬로 deck.pptx의 제목, bullet, CTA에서 AI-feel이 나는 부분을 찾아줘.
원본 파일은 수정하지 말고 보고서만 작성해줘.

gpt-55-prompt-architect 스킬로 기존 프롬프트를 GPT-5.5용으로 재설계해줘.

스킬별 요약

• ai-slop-document-auditor: PDF, Markdown, TXT, PPT/PPTX, HTML, DOCX 한국어 문서의 AI-feel 점검
• gpt-55-prompt-architect: GPT-5.5용 프롬프트 설계, 마이그레이션, 리뷰
• commit: 변경 파일을 기능별로 묶어 커밋 작성

Codex에는 없는 Claude Code 스킬

• commands-creator: Claude Code slash command 작성과 관리 가이드
• imagine: Claude Code 이미지 생성/편집
• mcp-builder: Python 또는 Node/TypeScript MCP 서버 설계와 구현
• premium-korean-aesthetic: 한국어 랜딩의 폰트, 여백, 카드, 모션 기준 적용
• pyautogui-helper: PyAutoGUI 기반 로컬 UI 자동화 도우미
• subagents-creator: Claude subagent 정의, 위임 패턴, 디버깅

Claude Code 호출 예시

commands-creator 스킬로 /release-note 명령을 만들어줘.
인자는 버전 번호와 변경 범위를 받게 하고, 출력은 한국어 릴리즈 노트로 해줘.

사용 가능한 agent

• ai-slop-detector: 한국어 PPT 제목, bullet, CTA의 AI-feel pattern tag 판정
• ai-slop-guardrail: 짧은 한국어 비즈니스 카피에서 피할 표현과 구조 정리
• ai-slop-rewriter: 정보와 구조를 유지한 AI-feel 줄이기
• songcopy: 쓸모랩 소속 카피라이터 페르소나의 광고 카피, 슬로건, 헤드라인, 캠페인 메시지 작성

Codex 호출 예시

ai-slop-detector agent로 아래 CTA 문구의 AI-feel tag만 뽑아줘.
"혁신적인 경험을 통해 비즈니스 성장을 가속화하세요"

songcopy agent로 B2B SaaS 랜딩 페이지 헤드라인 5개를 뽑아줘.
톤은 과장 없이 날카롭고, 바로 클라이언트 데크에 붙일 수 있게 해줘.

사용 가능한 agent

• ai-slop-detector: 한국어 짧은 비즈니스 카피의 AI-feel tag 판정
• ai-slop-guardrail: AI-feel을 막기 위한 금지 표현과 구조 정리
• ai-slop-rewriter: 입력 구조와 정보를 유지한 문체 수정
• songcopy: 쓸모랩 소속 카피라이터 페르소나의 광고 카피, 슬로건, 헤드라인, 캠페인 메시지 작성

Claude Code 호출 예시

ai-slop-guardrail subagent로 이 슬라이드 카피를 작성할 때 피해야 할 표현만 정리해줘.
수정문은 만들지 말고 금지 목록만 출력해줘.

ai-slop-rewriter subagent로 PPTX의 제목과 bullet만 AI-feel 덜 나게 고쳐줘.
슬라이드 순서와 원래 정보는 유지해줘.

songcopy subagent로 B2B SaaS 랜딩 페이지 CTA 문구 5개를 만들어줘.
톤은 과장 없이 실무자가 바로 검토할 수 있게 해줘.

Best use case

gh-setup은 issue-create / issue-start / issue-end가 공통으로 요구하는 gh를 준비합니다.

gh는 OS마다 설치 방법이 다르고, 로그인은 대화형이라 에이전트가 대신 해 줄 수 없습니다. 그래서 "gh auth status 실패"에서 멈추는 일이 잦습니다.

이 스킬은 Windows / WSL / Linux / macOS와 배포판, 터미널, 다운로드 도구(curl·wget), 패키지 매니저를 감지해 ~/.issue/settings.json에 남기고, 그 조합에 맞는 설치 명령을 만듭니다. 권한이 필요 없는 명령은 자동 실행하고, sudo가 필요한 명령은 프롬프트에 그대로 붙여 쓸 수 있는 형태로 안내합니다.

Codex 호출 예시

$gh-setup

Claude Code 호출 예시

/gh-setup

동작

1. detect로 OS·배포판·터미널·다운로더·패키지 매니저를 감지해 ~/.issue/settings.json 생성·갱신
2. status로 gh 설치·인증 상태 확인
3. plan으로 설치 명령 목록 생성 ([auto] / [user] / [guide] 표시)
4. install은 [auto] 명령만 실행. sudo 필요한 건 ! sudo ... 형태로 사용자에게 전달
5. login으로 브라우저 / 토큰 / 헤드리스 상황에 맞는 로그인 명령 안내

런타임 라우팅

진입점은 항상 gh-env.sh(POSIX) 또는 gh-env.ps1(Windows)입니다. 라우터가 node → python 순으로 찾아 넘기고, 둘 다 없으면 자체 폴백으로 감지와 안내까지 처리합니다. 어느 구현이 돌았는지는 출력의 RUNTIME=으로 확인합니다.

설정 파일

{
  "platform": { "os": "macos", "family": "macos", "arch": "arm64" },
  "terminals": ["zsh", "tmux"],
  "downloaders": ["curl", "wget"],
  "gh": { "installed": true, "authenticated": true }
}

배열은 0번이 우선입니다. 재감지해도 기존 순서를 덮어쓰지 않고 새 값만 뒤에 붙입니다. 순서 변경은 config set downloaders wget,curl로 합니다.

하지 않는 일

• sudo·관리자 권한이 필요한 명령의 대리 실행 (비밀번호 프롬프트에서 멈춥니다)
• gh auth login 대리 실행, 토큰 값 출력·저장

관련 파일

.claude/skills/gh-setup/SKILL.md
.claude/skills/gh-setup/references/{settings,install-matrix,auth-login}.md
.claude/skills/gh-setup/scripts/gh-env.mjs    # 주 구현 (Node 18+)
.claude/skills/gh-setup/scripts/gh_env.py     # 동등 구현 (Python 3.8+)
.claude/skills/gh-setup/scripts/gh-env.sh     # POSIX 라우터 + 폴백
.claude/skills/gh-setup/scripts/gh-env.ps1    # Windows 라우터 + 폴백
.codex/skills/gh-setup/  (같은 구성)

Codex 자산 목록

• ai-slop-document-auditor
• commit
• design-md-validator
• e2e-ci-trace-debug
• e2e-flow-planner
• e2e-harness-setup
• e2e-test-generator
• e2e-test-hardener
• e2e-test-healer
• gh-setup
• gpt-55-prompt-architect
• install-skill
• irasutoya-search
• issue-create
• issue-end
• issue-merge
• issue-start
• kill-process
• loop
• migrate-skill-agent
• schedule
• slide-ko-polish
• visual-companion

• ai-slop-detector
• ai-slop-guardrail
• ai-slop-rewriter
• issue-merge-analyst
• issue-merge-critic
• issue-verifier
• songcopy

• frontend/README.md
• frontend/project-coding-conventions.md
• frontend/project-dev-workflow.rules
• frontend/project-safety.rules

Claude Code 자산 목록

• ai-slop-document-auditor
• commands-creator
• e2e-ci-trace-debug
• e2e-flow-planner
• e2e-harness-setup
• e2e-test-generator
• e2e-test-hardener
• e2e-test-healer
• gh-setup
• gpt-55-prompt-architect
• imagine
• install-skill
• irasutoya-search
• issue-create
• issue-end
• issue-merge
• issue-start
• mcp-builder
• migrate-skill-agent
• premium-korean-aesthetic
• pyautogui-helper
• subagents-creator
• slide-ko-polish
• visual-companion

• commit
• kill-process
• audit

• ai-slop-detector
• ai-slop-guardrail
• ai-slop-rewriter
• issue-merge-analyst
• issue-merge-critic
• issue-verifier
• songcopy

• frontend/00-index.md
• frontend/api-infrastructure.md
• frontend/architecture.md
• frontend/naming-conventions.md
• frontend/react-components.md
• frontend/state-management.md
• frontend/styling-emotion.md
• frontend/testing.md
• frontend/typescript.md
• frontend/workflow-build.md

운영 메모

• 프로젝트 안에서 쓰는 스킬은 .codex/skills/ 또는 .claude/skills/ 아래에 둡니다.
• Codex 스킬은 $skill-name 형태나 자연어 요청으로 호출합니다.
• Claude Code 명령은 /command 형태로 호출합니다.
• Claude Code 스킬과 subagent는 자연어 요청의 키워드와 작업 맥락으로 호출합니다.
• 원본 문서 점검, 브라우저 캡처, 디자인 추출처럼 읽기 전용 확인이 가능한 작업은 먼저 결과를 남기고 수정합니다.

라이선스

MIT License. 자세한 내용은 LICENSE를 참고하세요.