finish

작업 끝의 반복 체인 정리 → 리뷰 → 커밋 → push → PR을 한 호출로 묶는다. 세션 로그 분석 결과 이 체인(특히 commit → create-pr, simplify → code-review)이 가장 빈번한 수동 반복이었다 — 단계마다 다음 스킬을 손으로 부르던 것을 한 번에 잇는다.

핵심 원칙: 커밋 스킬을 하드코딩하지 않는다. syai-commit은 회사 환경 전용이라 개인/다른 환경엔 없다. 커밋 단계는 항상 그 프로젝트에 적용되는 커밋 스킬을 감지해서 호출한다(아래 Step 3).

실행 절차

$ARGUMENTS에서 스킵 옵션을 먼저 파싱한다(no-simplify/no-review/no-pr).

Step 0: 변경 확인

git status --short && git diff --stat

변경이 없으면 즉시 중단하고 사용자에게 알린다(커밋할 것 없음). 현재 브랜치가 main/master/develop이면 경고한다 — 전역 브랜치 원칙상 작업 브랜치에서 진행해야 하므로, 계속할지 사용자에게 확인한다.

이 빈 변경 체크는 "정리·리뷰 전" 기준이다 — Step 1·2(simplify·code-review --fix)가 새 변경을 만들 수 있으므로, 그 단계 후 변경이 생기면 정상 진행한다.

Step 1: 코드 정리 (no-simplify면 생략)

simplify 스킬을 호출해 reuse·중복·불필요 코드를 정리한다.

Step 2: 코드 리뷰 (no-review면 생략)

code-review 스킬을 effort `medium`, 위험 지적만 수정(--fix)으로 호출한다.

effort 정규화: code-review에 넘기는 effort는 항상 유효값(low/medium/high/max/ultra) 중 하나로 명시 전달한다. 오타(meduim)나 미지정이면 기본값 medium으로 교정해서 넘긴다 — 인식 못 한 값을 넘기면 의도와 다른 강도로 실행될 수 있으므로 추측에 맡기지 않는다.

리뷰가 🔴 위험(버그·보안·데이터 손상)을 지적하면 그것만 반영하고, 스타일/취향은 건너뛴다.

Step 3: 커밋 — 프로젝트 규칙 자동 감지

커밋 스킬을 다음 우선순위로 감지해서 호출한다(하드코딩 금지):

1. 현재 위치에서 가장 가까운 CLAUDE.md/CLAUDE.local.md에 커밋 스킬이 명시돼 있으면 그것

(예: gagip-dev → plugin-commit)

1. 없으면 전역 ~/.claude/CLAUDE.md에 명시된 커밋 스킬 (회사 환경 → syai-commit)
2. 둘 다 없으면 폴백 common:commit

호출 전 가용성 확인(사전조건): 감지한 커밋 스킬이 현재 세션에 실제 로드돼 있는지 확인한다. plugin-commit·syai-commit은 특정 환경(gagip-dev·회사) 전용이라 다른 레포에선 없을 수 있다 (이 스킬 자신은 common 플러그인이라 어디든 따라가지만, 부품은 아니다). 감지한 스킬이 없으면 조용히 넘기지 말고 "감지된 <X> 스킬이 이 환경에 없어 common:commit으로 폴백합니다"라고 사용자에게 알린 뒤 폴백한다.

판단 기준: "이 프로젝트에서 커밋은 무슨 스킬로 하라고 적혀 있는가". 적혀 있으면(그리고 로드돼 있으면) 그걸 따르고, 없을 때만 범용 common:commit을 쓴다. 절대 syai-commit을 가정하지 않는다.

작은 단위로 나눠 커밋하는 게 적절하면 그렇게 한다(커밋 시점 컴파일 가능 상태 유지).

Step 4: push — 사용자 확인 게이트 (no-pr면 Step 5와 함께 생략)

push는 반드시 사용자 확인을 받고 진행한다(커밋 원칙: 원격 push 전 확인 필수). 사용자가 이미 "push까지" 명시했으면 바로 진행한다.

• gagip-dev 등 release 스킬을 쓰는 레포에서는 git push를 직접 호출하지 말고

그 레포 규칙대로 release 스킬을 거친다(프로젝트 CLAUDE.md 따름). 단 `release` 스킬이 현재 로드돼 있을 때만 — 없으면 사용자에게 알리고 git push(확인 후)로 폴백한다.

• 그 외는 push 후 Step 5.

Step 5: PR 생성/갱신 (no-pr면 생략)

create-pr 스킬을 호출한다(없으면 common:create-pr). PR 본문에 private 경로·내부 코드명·개인 메모를 넣지 않는다(반복 교정 지점이었음). base 브랜치가 기본값(develop)이 아닐 수 있으니, 작업 맥락상 다른 base가 맞으면 사용자에게 확인한다.

Step 6: 요약 보고

수행한 단계와 결과(커밋 해시·PR URL)를 한눈에 보고한다. 건너뛴 단계도 명시한다.

설계 원칙

• 기존 스킬 재사용: finish는 새 로직을 만들지 않고 검증된 스킬을 순서대로 엮는 얇은 오케스트레이터다.
• 프로젝트 중립: 커밋·push·PR 스킬은 모두 프로젝트 규칙을 따른다. 회사/개인 어디서나 동작.
• 안전 게이트 유지: push 전 사용자 확인, base 브랜치 확인, main/develop 직접 작업 경고는 생략하지 않는다.
• 이슈→PR 오케스트레이터의 부품: 상위 파이프라인 스킬이 구현 후 단계로 finish를 재사용한다.