diff --git a/plugins/atelier/skills/git/SKILL.md b/plugins/atelier/skills/git/SKILL.md
index db032e8a..518f8947 100644
--- a/plugins/atelier/skills/git/SKILL.md
+++ b/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 입니다.
diff --git a/plugins/atelier/skills/git/references/cli-reference.md b/plugins/atelier/skills/git/references/cli-reference.md
index d5004ae4..3f328084 100644
--- a/plugins/atelier/skills/git/references/cli-reference.md
+++ b/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 중복)
 
diff --git a/plugins/atelier/skills/git/references/conflict-resolution.md b/plugins/atelier/skills/git/references/conflict-resolution.md
index c36ba5f0..b1e1815d 100644
--- a/plugins/atelier/skills/git/references/conflict-resolution.md
+++ b/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 를 고려한다.
diff --git a/plugins/atelier/skills/git/references/issue-prioritization.md b/plugins/atelier/skills/git/references/issue-prioritization.md
deleted file mode 100644
index 162cc52f..00000000
--- a/plugins/atelier/skills/git/references/issue-prioritization.md
+++ /dev/null
@@ -1,119 +0,0 @@
-# 이슈 우선순위 판단
-
-"뭐부터 작업할까" / 이슈 우선순위 요청 시 열린 GitHub issue 를 분석해 다음 작업을 추천하는 판단 로직 (`git` skill 이 로드). tool result 크기 폭발을 막기 위해 메타데이터 → 필터링 → 후보 압축 → 본문 조회 → 분석 순으로 진행한다.
-
-## 실행 흐름
-
-```
-Step 1a: 메타데이터 수집 (body 제외)
-   ↓ Step 1b: 머지/PR 상태로 필터링
-   ↓ Step 1c: 상위 N개 후보 선정 후 body 조회
-   ↓ Step 2: 우선순위 분석 + 의존성 그래프
-   ↓ Step 3: 코드베이스 연관성 분석 (4단계)
-   ↓ Step 4: 결과 출력 → Step 5: 다음 액션 제안
-```
-
-## Step 1a: 메타데이터 수집 (body 제외)
-
-body 는 issue 당 수 KB 라 50개 이상이면 tool result 가 잘린다. body 제외 메타데이터만 먼저:
-
-```bash
-gh issue list --state open --json number,title,labels,createdAt,comments --limit 50
-```
-
-## Step 1b: 머지/PR 상태 필터링
-
-**(1) 최근 머지 자동 감지 (단축 필터)** — per-issue API 비용 절감 위해 로컬 git log 로 먼저:
-
-```bash
-git log --oneline -100 | grep -oE '#[0-9]+' | sort -u
-```
-
-매칭 issue 는 `[머지됨]` 마커 + close 제안 + 후보·per-issue 조회 대상에서 제외.
-
-**(2) 연결 PR 상태 체크** — (1)에서 안 걸린 후보만:
-
-```bash
-gh issue view ${NUM} --json closedByPullRequests,number,title
-# 폴백: gh pr list --state all --search "${NUM} in:body"
-```
-
-| 상태 | 마커 | 처리 |
-|------|------|------|
-| PR open 존재 | `[PR 진행 중 #<pr>]` | 우선순위 제외 |
-| PR closed/merged | `[머지됨]` | 제외 + close 제안 |
-| 작업 브랜치만 (PR 없음) | `[작업 시작됨 #<branch>]` | 유지 (가중치 감점) |
-| 연결 없음 | (없음) | 유지 |
-
-> N개 후보 × 1회 = N회 호출. 50개 이상이면 `gh api graphql` 의 `closingIssuesReferences` 일괄 조회로 N+1 회피. "작업 브랜치만 존재"는 `gh issue develop --list ${NUM}` 로 확인하되, 레포 컨벤션상 issue 번호가 브랜치명에 없을 수 있어 false negative 가능.
-
-## Step 1c: 상위 N개 후보 body 조회
-
-Step 2 가중치 기준 **상위 10개**(또는 `--limit N`)로 압축한 뒤 body 조회 — body 총량을 50개분 → 10개분으로 축소:
-
-```bash
-for num in $CANDIDATE_NUMBERS; do
-  gh issue view "$num" --json number,title,body,labels
-done
-```
-
-## Step 2: 우선순위 가중치
-
-| 기준 | 가중치 | 설명 |
-|------|--------|------|
-| 긴급도 | 높음 | bug > enhancement > documentation |
-| 영향 범위 | 높음 | 핵심 기능 영향 여부 |
-| 의존성(피의존) | 중간 | 다른 issue 가 이 issue 참조 → 가산 |
-| 의존성(선행) | 중간 | 이 issue 가 미해결 issue 에 의존 → 감점 |
-| 난이도 | 중간 | 구현 복잡도 (낮을수록 우선) |
-| 오래된 정도 | 낮음 | 오래 방치 가점 |
-| 댓글 수 | 낮음 | 관심도 |
-| 작업 진행 흔적 | 낮음 | `[작업 시작됨]` 마커 감점 |
-
-**의존성 그래프**: 각 body 에서 `#\d+` 추출 (`echo "$BODY" | grep -oE '#[0-9]+' | sort -u`) → `references` / `referenced_by` 맵 구축. `referenced_by` 많을수록 가산, 열린 `references` 있으면 감점. 출력 시 `← #526이 의존 / → #634 선행 요구` 형태로 시각화.
-
-## Step 3: 코드베이스 연관성 분석 (4단계)
-
-1. **경로 패턴 추출** — body 에서 코드 경로 토큰. 디렉토리 후보는 실제 최상위에서 동적 수집(정규식 메타문자 escape):
-   ```bash
-   ROOTS=$(ls -d */ 2>/dev/null | tr -d '/' | sed 's/[][\\.^$*+?()|]/\\&/g' | paste -sd '|' -)
-   echo "$BODY" | grep -oE "(${ROOTS})/[A-Za-z0-9_./-]+" | sort -u
-   ```
-2. **존재 검증** — `ls -d <path>` / Glob 으로 거짓 양성 제거.
-3. **활동 빈도** — 단일 git log 로 최근 변경 파일 카운트 맵 (per-path 반복 호출 회피):
-   ```bash
-   git log --since='3 months ago' --name-only --pretty=format: | grep -v '^$' | sort | uniq -c | sort -rn
-   ```
-   후보 경로(또는 prefix) 카운트 합산 → 활동 점수.
-4. **현재 작업 교차** — default 브랜치 동적 조회 후 `git diff "${DEFAULT_BRANCH}...HEAD" --name-only` 와 issue 경로 교집합 → 연속성 가산.
-
-산출물: issue 별 관련 파일/모듈, 활동 빈도 점수, 현재 작업 연관성 점수, 난이도 추정.
-
-## Step 4: 결과 출력
-
-상위 5개를 추천 순위로, 머지/PR-진행 중은 "정리 권장" 별도 섹션으로 분리:
-
-```
-## 추천 작업 순위
-### 1위: #{번호} {제목}
-- 긴급도/영향범위/난이도: ★ 표기
-- 관련 파일 / 최근 활동 / 현재 작업 연관성
-- 의존성: ← 피의존 / → 선행 요구
-- 추천 이유: ...
-
-## 참고: 정리 권장 issue
-### [머지됨] #NNN — close 권장
-### [PR 진행 중 #MMM] #NNN — 우선순위 제외
-### [작업 시작됨 #<branch>] #NNN — 브랜치 존재, PR 미생성
-```
-
-## Step 5: 다음 액션 제안 (AskUserQuestion)
-
-특정 issue 작업 시작(브랜치 생성) / `[머지됨]` 일괄 close / `[작업 시작됨]` 브랜치 전환 / 코멘트 추가 / 라벨 업데이트.
-
-## 에러 처리
-
-- gh 인증 실패 → `gh auth login` 안내
-- issue 0개 → "열린 issue 없음" 후 종료
-- Step 1a 결과 truncation → `--limit` 절반으로 재시도 + 사용자 알림
-- `closedByPullRequests` 미지원 gh → `gh pr list --search` 폴백 자동 전환
diff --git a/plugins/atelier/skills/git/references/review-followup.md b/plugins/atelier/skills/git/references/review-followup.md
deleted file mode 100644
index 5d48f819..00000000
--- a/plugins/atelier/skills/git/references/review-followup.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# 미해결 리뷰 정리 (review followup)
-
-"리뷰 정리해줘", "미해결 코멘트 봐줘" 같은 요청 시 수행하는 절차. 조회는 CLI(결정적), 그룹핑·액션 제안은 이 reference 의 판단 규칙을 따른다.
-
-## Step 1: 미해결 리뷰 조회
-
-`atelier git reviews` CLI 를 실행하여 리뷰 쓰레드를 가져온다.
-
-```bash
-atelier git reviews [PR_NUMBER]
-```
-
-> PR 번호 미지정 시 현재 브랜치의 PR 을 자동 감지한다.
-
-## Step 2: 결과 분석
-
-JSON 결과에서 `isResolved: false`인 쓰레드만 필터링한다.
-
-각 미해결 쓰레드에 대해 다음 정보를 정리하여 출력한다:
-
-| 항목 | 설명 |
-|------|------|
-| 파일 경로 | `path` 필드 |
-| 라인 번호 | `line` 필드 |
-| 리뷰어 | 첫 번째 코멘트의 `author.login` |
-| 코멘트 내용 | 쓰레드의 모든 코멘트 `body` |
-| 링크 | 첫 번째 코멘트의 `url` |
-
-## Step 3: 결과 출력
-
-- **미해결 항목이 없으면**: "모든 리뷰가 해결되었습니다" 메시지 출력
-- **미해결 항목이 있으면**: 각 항목을 파일별로 그룹핑하여 출력하고, 다음 액션을 제안한다:
-  - 해당 파일 수정이 필요한 경우 → 수정 제안
-  - 답변이 필요한 경우 → 답변 작성 제안
-
-## 출력 형식 예시
-
-```
-## PR #123: Feature title
-총 3개의 미해결 리뷰
-
-### src/auth/login.ts (2건)
-
-1. **Line 42** - @reviewer1
-   > 이 부분에서 에러 핸들링이 필요합니다
-   🔗 [링크](https://github.com/...)
-
-2. **Line 78** - @reviewer2
-   > 타입 체크를 추가해주세요
-   🔗 [링크](https://github.com/...)
-
-### src/utils/validate.ts (1건)
-
-1. **Line 15** - @reviewer1
-   > 유틸리티 함수로 분리하는 게 좋겠습니다
-   🔗 [링크](https://github.com/...)
-
----
-**추천 액션:**
-- [ ] src/auth/login.ts: 에러 핸들링 추가 (Line 42)
-- [ ] src/auth/login.ts: 타입 체크 추가 (Line 78)
-- [ ] src/utils/validate.ts: 유틸리티 함수 분리 (Line 15)
-```
-
-## 에러 처리
-
-- gh 인증 실패 → `gh auth login` 안내
-- 현재 브랜치에 PR 없음 → PR 번호를 명시하도록 안내
diff --git a/plugins/atelier/skills/git/references/sync-strategy.md b/plugins/atelier/skills/git/references/sync-strategy.md
deleted file mode 100644
index 696a39cd..00000000
--- a/plugins/atelier/skills/git/references/sync-strategy.md
+++ /dev/null
@@ -1,89 +0,0 @@
-# 브랜치 동기화 전략
-
-`git` skill(또는 `atelier git sync` CLI)이 지정 브랜치(또는 기본 브랜치)로 전환 후 원격 최신 상태로 동기화하는 절차와 판단.
-
-## 인자 파싱
-
-`--force` 와 브랜치 이름은 **순서 무관**. 인자 순회로 `--force` → FORCE=true, 그 외 → TARGET_BRANCH:
-
-```bash
-FORCE=false; TARGET_BRANCH=""
-for arg in "$@"; do
-  case "$arg" in
-    --force) FORCE=true ;;
-    *) TARGET_BRANCH="$arg" ;;
-  esac
-done
-CURRENT_BRANCH=$(git branch --show-current)
-CHANGES=$(git status --porcelain)
-# 브랜치 미지정 시 기본 브랜치 자동 감지
-if [ -z "$TARGET_BRANCH" ]; then
-  TARGET_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||' || echo 'main')
-fi
-```
-
-## 변경사항 처리 (stash 정책)
-
-```bash
-# --force 없이 변경사항 있으면 중단
-if [ -n "$CHANGES" ] && [ "$FORCE" != "true" ]; then
-  echo "⚠️ Uncommitted changes detected. Use --force to stash and continue."
-  exit 1
-fi
-# --force 면 stash (버리지 않음)
-if [ -n "$CHANGES" ] && [ "$FORCE" = "true" ]; then
-  git stash push -m "auto-stash before git-sync"
-  STASHED=true
-fi
-```
-
-## 브랜치 존재 여부 → 처리 매트릭스
-
-```bash
-LOCAL_EXISTS=$(git show-ref --verify --quiet "refs/heads/$TARGET_BRANCH" && echo yes || echo no)
-git fetch origin --prune 2>/dev/null
-REMOTE_EXISTS=$(git show-ref --verify --quiet "refs/remotes/origin/$TARGET_BRANCH" && echo yes || echo no)
-```
-
-| 로컬 | 원격 | 처리 |
-|------|------|------|
-| 있음 | - | `git checkout $TARGET_BRANCH && git pull origin $TARGET_BRANCH` |
-| 없음 | 있음 | `git checkout -b $TARGET_BRANCH --track origin/$TARGET_BRANCH` (CREATED_TRACKING) |
-| 없음 | 없음 | AskUserQuestion 으로 확인 (아래) |
-
-**둘 다 없을 때** AskUserQuestion: "Branch '{TARGET_BRANCH}' 이 로컬·원격 모두 없습니다. 어떻게 처리할까요?" → Create new branch (`git checkout -b $TARGET_BRANCH`, CREATED_NEW) / Cancel (중단).
-
-## 결과 보고
-
-```bash
-echo "✓ Synced to $TARGET_BRANCH"
-echo "  Previous branch: $CURRENT_BRANCH"
-[ "$STASHED" = true ] && echo "  ⚠️ Changes were stashed. Use 'git stash pop' to restore."
-[ "$CREATED_TRACKING" = true ] && echo "  ℹ️ Created local branch tracking origin/$TARGET_BRANCH"
-[ "$CREATED_NEW" = true ] && echo "  ℹ️ New branch created from $CURRENT_BRANCH"
-```
-
-## Output Examples
-
-```
-✓ Synced to main
-  Previous branch: feat/wad-0212
-```
-```
-✓ Synced to feat/shared
-  Previous branch: main
-  ℹ️ Created local branch tracking origin/feat/shared
-```
-```
-✓ Synced to develop
-  Previous branch: feat/wad-0212
-  ⚠️ Changes were stashed. Use 'git stash pop' to restore.
-```
-
-## Notes
-
-- 브랜치 미지정 시 기본 브랜치(main/master 등) 자동 감지
-- `--force` 와 브랜치 이름은 순서 무관
-- `--force` 는 stash 만 하고 변경사항을 버리지 않음 (`git stash list` 로 확인)
-- 원격에만 있는 브랜치 지정 시 자동 tracking 브랜치 생성
-- 존재하지 않는 브랜치 지정 시 AskUserQuestion 으로 새 브랜치 생성 여부 확인
diff --git a/tools/validate/extraction-invariants.json b/tools/validate/extraction-invariants.json
index e8dc0a45..4310fd40 100644
--- a/tools/validate/extraction-invariants.json
+++ b/tools/validate/extraction-invariants.json
@@ -17,8 +17,6 @@
     {"domain": "spec/annotate", "token": "## 에러 처리", "reason": "annotate 에러 처리 (매칭 0건/retry)"},
     {"domain": "git/resolve", "token": "diff-filter=U", "reason": "rebase --continue 미해결 충돌 가드"},
     {"domain": "git/resolve", "token": "rebase --abort", "reason": "resolve --abort 인자 처리"},
-    {"domain": "git/sync", "token": "auto-stash before git-sync", "reason": "sync --force stash 정책"},
-    {"domain": "git/prioritize", "token": "closedByPullRequests", "reason": "이슈 우선순위 PR 상태 필터"},
     {"domain": "autopilot/merge", "token": "#643", "reason": "머지 종료코드 가드 (실패 시 이슈 오close 방지)"},
     {"domain": "autopilot/merge", "token": "--squash --delete-branch", "reason": "PR squash merge 실행"},
     {"domain": "autopilot/build", "token": "max_consecutive_failures", "reason": "build 에스컬레이션 임계값"},