Auto Sync

---
name: auto-sync
description: 문서 동기화 — 구현 이후 SPEC, CHANGELOG, 문서를 반영합니다
compatibility: omp
---

# auto-sync — 문서 동기화 스킬

## OMP Invocation

- `/auto sync ...`
- `/auto-sync ...`
- Load detail skill `auto-sync` for either entrypoint.


**프로젝트**: autopus-adk | **모드**: full

## 설명

방금 만든 변경에 맞춰 프로젝트 문서를 갱신합니다. 단계마다 사용자에게 시작을 묻지 않고 진행하며, 리뷰나 QA hunt가 통과한 뒤 자연스럽게 이어집니다.

## 사용법

```text
auto sync
auto sync HEAD~3..HEAD
```

## 절차

1. 변경 읽기: `git diff HEAD --stat && git status --short`로 범위를 보고 바뀐 소스를 직접 읽습니다. 하네스 경로(`.autopus/`, `.omp/`, `.omp/`, `.omp/`, `.omp/`, `.omp/`, `.agents/`)는 건너뜁니다.
2. 변경이 낡게 만든 문서만 갱신합니다. 프로젝트의 표현과 언어를 따릅니다.
   - `README.md`: 바뀐 명령·flag·설정·설치·사용법
   - `ARCHITECTURE.md`: 추가·제거된 package, module, 의존성, 데이터 흐름
   - `CHANGELOG.md`: unreleased 제목 아래 항목 하나(없으면 제목을 만듭니다). 사용자에게 무엇이 왜 바뀌었는지
   - `docs/` 아래 문서, 바뀐 공개 API 옆 doc comment
   - `.autopus/project/*.md`가 있으면 그 내용. `.autopus/project/workspace.md`는 root 역할, 중첩 repo 경계, 생성·런타임 경로, 커밋 정책, QA/Journey Pack 대상 명령이 바뀌었을 때 갱신합니다
3. 기능을 지어내거나, 상관없는 절을 다시 쓰거나, 문체를 바꾸지 않습니다. 낡은 문서가 없으면 그렇게 말하고 아무것도 바꾸지 않습니다.
4. 확인: 문서에 적힌 명령·flag·경로·설정 key가 코드에 실제로 있는지 봅니다. 바뀐 명령은 가능하면 `--help`를 돌려 봅니다. 고친 문서의 링크와 파일 참조가 맞는지 봅니다.
5. 세션이 커밋하는 중이면 문서를 변경과 함께, 또는 `docs(<scope>): ...` 후속 커밋으로 프로젝트 커밋 형식(commit-msg hook이 있으면 Lore)에 맞춰 커밋합니다. push하지 않습니다.

사용자만 정할 수 있는 결정(예: 동작 변경이 breaking인지)이 필요하면 권장안을 맨 앞에 둔 번호 선택지로 묻고 멈춥니다. 그 밖에는 가정을 밝히고 진행합니다.

## Branding Formats

### Workflow Lifecycle (show after sync completes)

```
🐙 Workflow: {SPEC-ID}
  ✓ plan  →  ✓ go  →  ● sync
```

### Milestone Celebration (show when full pipeline completes)

```
╭────────────────────────────────────╮
│ 🐙 파이프라인 완료!                 │
│ {SPEC-ID}: {title}                 │
│ 태스크: N/N | 커버리지: N%          │
│ 리뷰: {verdict}                    │
╰────────────────────────────────────╯
```

Field mappings: `{title}` from spec.md, `N/N` = completed/total tasks, `{verdict}` = `APPROVE` or `N/A`.

### Next Step Auto-Detection (show after sync completes)

```
다음 단계: {recommendation}
```

Detection order:
1. SPEC status `completed` → `🐙 {SPEC-ID} 완료.`
2. Existing pending SPECs created by an approved Sibling SPEC Decision exist → recommend next SPEC to implement
3. Do not recommend or create pending SPECs from Evolution Ideas
4. Always append: `배포 후 검증: /auto qa`