refactor(atelier): trim git skill to policy + hooks, drop mechanical guides

plugins/atelier/skills/git/SKILL.md

@@ -81,7 +81,7 @@ git push origin main       # 금지
 atelier git branch feature/my-work
 atelier git commit feat "my changes"
 atelier git pr "My feature"
-# → Merge 승인 대기 → atelier git sync (CLI) → git branch -d feature/my-work
+# → Merge 승인 대기 → git checkout <base> && git pull → git branch -d feature/my-work
 ```
 
 ---
@@ -110,10 +110,7 @@ hook 의 등록·비활성화·재설정은 통합 setup 의 hook 관리 모드
 | reference | 언제 로드 | 관련 흐름 |
 |---|---|---|
 | `references/cli-reference.md` | CLI 인자 형식·출력 계약·명명 규칙이 필요할 때 | 커밋/브랜치/PR 실행 |
-| `references/conflict-resolution.md` | rebase 충돌 파일별 해결 전략 (Ours/Theirs/Manual, marker 의미, --continue/--abort/--skip) | "충돌 해결해줘" / rebase 중 |
-| `references/issue-prioritization.md` | 이슈 우선순위 가중치·의존성 그래프·코드베이스 연관성 4단계 분석 | "뭐부터 작업할까" / 이슈 우선순위 |
-| `references/review-followup.md` | 미해결 리뷰 필터링·파일별 그룹핑·추천 액션 형식 | "리뷰 정리해줘" |
-| `references/sync-strategy.md` | 브랜치 동기화 인자 파싱·stash 정책·상태별 처리 매트릭스 | "동기화" / `atelier git sync` |
+| `references/conflict-resolution.md` | rebase 충돌의 ours/theirs 반전 gotcha·파일별 분할정복 정책 (mechanical git 은 모델이 직접) | "충돌 해결해줘" / rebase 중 |
 
 > 결정적 git 연산(commit, branch, guard, PR)은 `atelier git` CLI 로 위임합니다. references 는 **판단**이 필요한 부분만 담습니다.
 > 여러 변경의 머지 조정(순서·worktree 통합)이 필요하면 `orchestrator` skill 의 `references/merge-coordinator.md` 가 canonical 입니다.

plugins/atelier/skills/git/references/cli-reference.md

@@ -83,7 +83,7 @@ atelier git reviews [pr-number]
 
 **출력 (JSON):** PR 제목, URL, 리뷰 쓰레드 목록
 
-> PR 번호 미지정 시 현재 브랜치의 PR 을 자동 감지한다. 결과 해석·후속 액션 제안은 `references/review-followup.md`.
+> PR 번호 미지정 시 현재 브랜치의 PR 을 자동 감지한다. 결과 해석·후속 액션(리뷰 정리) 제안은 git skill 이 직접 판단한다.
 
 ## 5. Tool Guard (branch 보호 · PR 중복)
 

plugins/atelier/skills/git/references/conflict-resolution.md

@@ -1,96 +1,24 @@
-# Rebase 충돌 해결 판단
+# Rebase 충돌 해결 정책
 
-`git` skill 이 rebase 충돌을 파일별로 분할정복하며 해결할 때의 판단 프로토콜. 충돌 조정(여러 변경을 어떤 순서로 통합할지)이 필요하면 `orchestrator` skill 의 `references/merge-coordinator.md` 가 canonical 이며, 이 문서는 **단일 rebase 의 파일별 해결 전략**만 다룬다.
+`git` skill 이 rebase 충돌을 해결할 때의 **판단·정책**. mechanical 한 git 사용법(`checkout --ours/--theirs`, `git add`, `--continue/--abort/--skip`, 마커 편집)은 모델이 직접 수행한다 — 여기에는 모델이 틀리기 쉬운 gotcha 와 진행 정책만 둔다. 여러 변경의 통합 순서 조정은 `orchestrator` skill 의 `references/merge-coordinator.md` 가 canonical 이며, 이 문서는 **단일 rebase 의 충돌 해결 전략**의 단일 출처다 (pr-merger·merge-coordinator 가 위임).
 
-## 인자 처리 (--continue / --abort / --skip)
+## ⚠️ rebase 의 ours/theirs 는 merge 와 반대다 (가장 자주 틀림)
 
-사용자가 rebase 진행 제어를 요청하면 먼저 인자를 처리한다.
-
-```bash
-case "$1" in
-  --continue)
-    # 미해결 충돌 가드: 남은 충돌이 있으면 rebase --continue 전에 거부 (exit 1)
-    UNRESOLVED=$(git diff --name-only --diff-filter=U)
-    if [ -n "$UNRESOLVED" ]; then
-      echo "⚠️ 아직 해결되지 않은 충돌이 있습니다:"
-      echo "$UNRESOLVED" | while read f; do echo "  - $f"; done
-      echo "충돌을 먼저 해결한 후 다시 시도하세요."
-      exit 1
-    fi
-    git rebase --continue; exit $? ;;
-  --abort)
-    git rebase --abort
-    echo "✓ Rebase aborted. Returned to original state."; exit 0 ;;
-  --skip)
-    git rebase --skip; exit $? ;;
-esac
 ```
-
-인자가 없으면 아래 대화형 해결로 진입한다. (rebase 미진행 시 안내 후 종료, 충돌 0건이면 `--continue` 안내.)
-
-## 파일별 분할정복 절차
-
-충돌 파일 목록에서 첫 번째 파일부터 하나씩 처리한다.
-
-1. **파일 선택** — AskUserQuestion 으로 충돌 파일 목록에서 처리할 파일 선택 (또는 "모두 건너뛰기" → 수동 해결 후 `--continue`).
-2. **충돌 분석** — Read 로 파일을 읽고 충돌 마커(`<<<<<<<`, `=======`, `>>>>>>>`) 영역 식별. `git diff --color=always "$FILE"` 로 표시.
-3. **해결 전략 선택** — AskUserQuestion (Ours / Theirs / Manual / Show diff).
-4. **전략별 처리** (아래).
-5. 현재 파일 해결 후 남은 충돌이 있으면 1번으로 반복. 모두 해결되면 `--continue` 안내.
-
-## 전략별 처리
-
-**Ours (Upstream/Base)** — rebase 대상(base) 브랜치 변경 유지:
-```bash
-git checkout --ours "$FILE" && git add "$FILE"
-```
-
-**Theirs (내 커밋)** — 현재 적용 중인 내 커밋 변경으로 대체:
-```bash
-git checkout --theirs "$FILE" && git add "$FILE"
-```
-
-**Manual (수동 병합)** — Read 로 전체 표시 → 충돌 섹션 설명 → Edit 로 함께 해결 → `git add "$FILE"`.
-
-**Show diff** — 양쪽 버전 비교 후 전략 선택으로 복귀:
-```bash
-echo "=== Ours: Upstream/Base version (rebase 대상) ==="
-git show :2:"$FILE" 2>/dev/null || echo "(file doesn't exist in ours)"
-echo "=== Theirs: My commit version (적용 중인 내 커밋) ==="
-git show :3:"$FILE" 2>/dev/null || echo "(file doesn't exist in theirs)"
-```
-
-## Conflict Marker 의미 (rebase 는 merge 와 반대!)
-
-```
-<<<<<<< HEAD (ours)
-Upstream/Base 브랜치의 코드 (예: origin/main)
+<<<<<<< HEAD (ours)        ← Upstream/Base 브랜치 (예: origin/main)
 =======
-내 커밋의 코드 (현재 적용 중인 feature 브랜치 커밋)
->>>>>>> commit-hash (theirs)
+>>>>>>> commit (theirs)    ← 내 커밋 (현재 적용 중인 feature 커밋)
 ```
 
-**⚠️ rebase 에서 ours/theirs 는 merge 와 반대다:**
-- `--ours`: Upstream(base) 브랜치 변경 (HEAD 가 가리키는 rebase 대상)
-- `--theirs`: 내 커밋 변경 (현재 적용 중인 feature 브랜치 커밋)
-
-이유: rebase 중에는 HEAD 가 upstream 을 가리키고 내 커밋들이 하나씩 그 위에 적용되기 때문.
-
-## 실전 시나리오
-
-**Feature 브랜치를 main 에 rebase**: `git fetch origin` → `git checkout feature/my-work` → `git rebase origin/main` → 충돌 시 이 절차로 파일별 해결 → 해결 후 `--continue` 인자 처리.
-
-**양쪽 변경 모두 필요** (예: 서로 다른 import 추가): Manual 선택 후 양쪽을 병합:
-```typescript
-import { ServiceA } from './serviceA';
-import { ServiceB } from './serviceB';   // ours
-import { ServiceC } from './serviceC';   // theirs
-```
+- `--ours` = **Upstream/base** 변경 (rebase 중 HEAD 가 base 를 가리킴)
+- `--theirs` = **내 커밋** 변경
 
-**충돌이 너무 복잡할 때**: `--skip` (현재 커밋 건너뛰기) 또는 `--abort` (전체 취소 후 merge 고려 / 더 작은 단위로 분할).
+이유: rebase 는 내 커밋들을 base 위에 하나씩 다시 얹으므로 `HEAD = base`. merge 와 정반대다.
 
-## 주의사항
+## 진행 정책
 
-- **rebase 전 브랜치 백업 고려**: `git branch backup/my-work`
-- **이미 push 한 브랜치 rebase 주의**: 히스토리 변경 → 공유 브랜치는 rebase 후 `--force-with-lease` 필요
-- **충돌이 너무 많으면**: `--abort` 후 merge 고려, 또는 더 작은 단위로 rebase
+- **파일별 분할정복**: 충돌 파일을 하나씩, 각 파일마다 사용자에게 Ours / Theirs / Manual 을 확인하고 해결한다. 한 번에 일괄 처리하지 않는다.
+- **양쪽 다 필요하면 Manual**: 서로 다른 import 추가처럼 둘 다 살려야 하면 직접 병합한다.
+- **--continue 가드**: `git diff --name-only --diff-filter=U` 에 남은 충돌이 있으면 `--continue` 하지 않는다.
+- **이미 push 한 브랜치**: 히스토리가 바뀌므로 rebase 후 `--force-with-lease` (절대 `--force` 아님).
+- **충돌이 과도하면**: `--abort` 후 merge 로 전환하거나 더 작은 단위로 분할 rebase 를 고려한다.