chaeyn · Oct 1, 2026 · Oct 1, 2026 · Oct 1, 2026 · Oct 1, 2026 · Oct 1, 2026
diff --git a/.agent/skills/commit/SKILL.md b/.agent/skills/commit/SKILL.md
@@ -1,33 +1,23 @@
-# 커밋 작성
+---
+name: commit
+description: Framework 저장소의 목적별 커밋 작성 시 한국어 제목과 변경 종류에 맞는 타입 적용.
+---
 
-커밋은 한 가지 목적의 변경만 담고, 제목은 한국어로 작성해요.
+# Commit 작성
 
-## 형식
+[공통 작성 규칙](../../../docs/collaboration.md)의 커밋 타입을 따른다.
 
-```text
-<type>: <변경 내용>
-```
-
-`type`은 `feat`, `fix`, `chore`, `refactor` 중 하나이며, 이슈 및 브랜치의 유형과 맞춰요.
-
-예시:
-
-```text
-feat: 다운로드 버튼과 진행 상태 추가
-fix: 로그인 후 잘못된 경로 이동 수정
-chore: 테스트 의존성 업데이트
-refactor: 인증 토큰 검증 로직 분리
-```
-
-## 확인 후 커밋
-
-변경 파일과 테스트 결과를 확인한 뒤 커밋해요.
+- 형식은 `<type>: <한국어 변경 내용>`
+- 타입은 `feat/fix/refactor/hotfix/docs/style/remove/test/chore/comment`
+- 한 커밋에 한 가지 목적. 개별 커밋 타입은 Issue·브랜치 타입과 달라도 됨
+- 기능 브랜치에서도 오류 수정은 `fix`, 문서는 `docs`, 테스트는 `test`로 구분
+- 코드 식별자와 전문 용어는 실제 표기 유지
+- 커밋 전 변경 파일·검증 범위·`git diff --check` 확인
+- 관련 없는 파일·비밀 정보·생성물 제외
 
 ```bash
 git status --short
 git diff --check
 git add <변경한-파일>
-git commit -m "feat: 다운로드 버튼과 진행 상태 추가"
+git commit -m "fix: 얼굴 등록 카메라 세션 충돌 수정"
 ```
-
-관련 없는 파일, 비밀 정보, 생성물은 커밋하지 않아요.
diff --git a/.agent/skills/issue/SKILL.md b/.agent/skills/issue/SKILL.md
@@ -1,51 +1,22 @@
-# 이슈 생성
+---
+name: issue
+description: Framework 저장소의 Issue 생성 및 작업 체크리스트 갱신 시 공통 제목과 개조식 본문 적용.
+---
 
-작업을 시작하기 전에 GitHub 이슈를 만들어요. 이슈는 작업을 추적하는 기준점이에요.
+# Issue 작성
 
-## 작업 유형
+[공통 작성 규칙](../../../docs/collaboration.md)의 Issue 양식을 읽는다.
 
-아래 네 유형 중 하나를 선택해요.
-
-| 유형 | 사용할 때 |
-| --- | --- |
-| `feat` | 새 기능을 개발할 때 |
-| `fix` | 버그를 수정할 때 |
-| `chore` | 기타 자잘한 수정이나 설정 변경을 할 때 |
-| `refactor` | 동작은 유지하며 코드를 정리할 때 |
-
-## 제목
-
-제목은 한국어로, 아래 형식으로 작성해요.
-
-```text
-<type>: <작업 내용>
-```
-
-예시:
-
-```text
-feat: GitHub 릴리스 다운로드 기능 추가
-fix: 로그인 후 화면 전환 오류 수정
-chore: 의존성 버전 정리
-refactor: 인증 서비스 구조 개선
-```
-
-## 담당자
-
-기본 담당자는 이슈를 만든 본인이에요. 다른 사람이 실제 작업을 맡는다면 그 사람을 담당자로 지정해요.
-
-## GitHub 웹에서 만들기
-
-이슈를 만들 때 작업 유형에 맞는 양식을 선택하고, 제목과 담당자를 지정해요.
-
-## GitHub CLI에서 만들기
+- 작업 전 Issue 생성, 실제 작업자 지정
+- 제목은 `feat/fix/chore/refactor: <한국어 작업 내용>`
+- 본문은 `작업 내용 / 작업 체크리스트 / 완료 기준`, 필요한 경우 마지막에 `참고` 추가
+- 한 항목에 한 가지 내용, 명사형 종결 사용. 진행 항목은 `- [ ]`로 작성하고 수행 후 체크
+- 완료 기준은 확인 가능한 결과로 작성
+- CLI 본문은 UTF-8 Markdown 파일과 `--body-file` 사용. 빈 본문과 문자열 `\n` 사용 금지
 
 ```bash
-gh issue create \
-  --title "feat: GitHub 릴리스 다운로드 기능 추가" \
-  --label "feat" \
-  --assignee "@me" \
-  --body ""
+gh issue create --title "fix: 카메라 세션 충돌 수정" \
+  --label "fix" --assignee "@me" --body-file issue.md
 ```
 
-생성된 이슈 번호를 이후 브랜치와 PR에 사용해요.
+생성한 번호를 브랜치와 PR에 사용한다. 작업 진행에 따라 기존 Issue 체크 상태를 갱신한다.
diff --git a/.agent/skills/pull-request/SKILL.md b/.agent/skills/pull-request/SKILL.md
@@ -1,95 +1,42 @@
-# Pull Request 생성
+---
+name: pull-request
+description: Framework 저장소의 Draft PR 생성, 검증 결과와 체크리스트 갱신, merge commit 작성 시 공통 규칙 적용.
+---
 
-작업을 공유할 준비가 되면 PR을 초안(Draft)으로 먼저 만들어요. 처음부터 Open PR로 만들지 않아요.
+# PR 작성
 
-## 제목
+[공통 작성 규칙](../../../docs/collaboration.md)과 `.github/pull_request_template.md`를 읽는다.
 
-브랜치의 작업 유형은 콜론으로 구분하고, 나머지 슬러그와 이슈 번호는 브랜치와 같게 사용해요.
+## 생성과 갱신
 
-```text
-<type>: <english-slug>/#<issue-number>
-```
-
-예시:
-
-```text
-fix: preflight-dim/#67
-```
-
-## 생성
-
-변경 사항과 테스트를 확인하고 원격 브랜치를 푸시한 뒤 Draft PR을 만들어요.
-
-PR 본문은 아래 틀을 유지해요.
-
-```markdown
-## 변경 내용
-
-- 핵심 변경 사항
-- 주요 동작 또는 영향 범위
-
-## 확인 방법
-
-- 빌드·테스트 결과
-- 주요 검증 항목
-
-Closes #<issue-number>
-```
-
-본문은 구현 과정을 길게 설명하지 않고 핵심 결론만 간결한 개조식으로 작성해요.
-
-- 비슷한 변경은 한 항목으로 묶어요.
-- 세부 구현보다 사용자가 체감하는 동작과 중요한 기술적 영향만 남겨요.
-- 테스트 개수, 성공 여부, 핵심 검증 범위만 남겨요.
-- signaling 변경 없음, 물리 기기 미검증처럼 중요한 제약·미수행 항목은 유지해요.
-- 이미 본문에서 드러나는 내용을 반복하지 않아요.
+- 제목은 `<type>: <english-slug>/#<issue-number>`, head 브랜치와 일치
+- 구현 중 Draft 생성 허용. 검증 전에는 결과에 `검증 대기`, 체크리스트에는 미완료 항목 기재
+- 본문은 `변경 내용 / 검증 결과 / 머지 체크리스트 / 관련 이슈` 순서 고정
+- 명사형 종결의 최상위 개조식 사용. 변경 내용·검증 결과는 각각 1~3개 항목
+- 핵심 동작·영향·실제 결과만 기록. 구현 과정·작업 순서·시도한 방법·중첩 목록·홍보 문구 생략
+- 중요한 미검증 범위와 API 계약·배포 조건 유지. 상세 설명은 Issue 또는 문서에 기록
+- 체크리스트는 해당 변경의 필수 검증과 리뷰 확인으로 구성. 미수행 항목 체크 금지
+- 실제 검증 후 결과·체크 상태 갱신, Ready for review 전환, 리뷰 반영 후 머지
+- 이슈 전체 완료는 `Closes #번호`, 부분 완료·참고는 `Refs #번호`
+- 본문은 파일과 `--body-file`로 전달. 문자열 `\n` 사용 금지
 
 ```bash
-git status --short
 git push -u origin HEAD
-gh pr create \
-  --draft \
-  --title "feat: github-release-download/#654" \
-  --body "## 변경 내용\n\n- GitHub 릴리스 다운로드 기능 추가\n\n## 확인 방법\n\n- 관련 테스트 통과\n\nCloses #654"
-```
-
-## Open PR 전환
-
-자가 확인이 끝난 뒤에만 Ready for review로 전환해요.
-
-```bash
+gh pr create --draft --title "fix: camera-session/#123" --body-file pr.md
+gh pr edit --body-file pr.md
 gh pr ready
 ```
 
 ## 병합
 
-병합 커밋 제목은 GitHub 기본 제목을 사용하지 않고 아래 형식으로 작성해요.
-
-```text
-merge: <english-slug>/#<issue-number>
-```
-
-브랜치가 다음과 같다면:
-
-```text
-chore/readme-update/#390
-```
-
-기본 제목:
-
-```text
-Merge pull request #392 from team-framework/chore/readme-update/#390
-```
-
-대신 다음 제목을 사용해요.
-
-```text
-merge: chore/readme-update/#390
-```
-
-CLI로 병합할 때도 병합 커밋 제목을 직접 지정해요.
+사용자 요청 범위와 저장소 승인 조건을 확인한다. 공통 규칙의 필수 검사·체크리스트·리뷰 확인 후 merge commit으로 병합한다.
 
 ```bash
-gh pr merge --merge \
-  --subject "merge: chore/readme-update/#390"
+head_branch=$(gh pr view --json headRefName --jq .headRefName)
+head_sha=$(gh pr view --json headRefOid --jq .headRefOid)
+gh pr checks --required
+gh pr merge --merge --match-head-commit "$head_sha" \
+  --subject "merge: $head_branch" --body ""
 ```
+
+병합 후 실제 커밋의 제목·빈 본문·두 부모를 확인한다. 자동 동기화·배포 묶음 PR의 예외는 공통 규칙을 따른다.
diff --git a/.claude/skills/commit/SKILL.md b/.claude/skills/commit/SKILL.md
@@ -1,33 +1,23 @@
-# 커밋 작성
+---
+name: commit
+description: Framework 저장소의 목적별 커밋 작성 시 한국어 제목과 변경 종류에 맞는 타입 적용.
+---
 
-커밋은 한 가지 목적의 변경만 담고, 제목은 한국어로 작성해요.
+# Commit 작성
 
-## 형식
+[공통 작성 규칙](../../../docs/collaboration.md)의 커밋 타입을 따른다.
 
-```text
-<type>: <변경 내용>
-```
-
-`type`은 `feat`, `fix`, `chore`, `refactor` 중 하나이며, 이슈 및 브랜치의 유형과 맞춰요.
-
-예시:
-
-```text
-feat: 다운로드 버튼과 진행 상태 추가
-fix: 로그인 후 잘못된 경로 이동 수정
-chore: 테스트 의존성 업데이트
-refactor: 인증 토큰 검증 로직 분리
-```
-
-## 확인 후 커밋
-
-변경 파일과 테스트 결과를 확인한 뒤 커밋해요.
+- 형식은 `<type>: <한국어 변경 내용>`
+- 타입은 `feat/fix/refactor/hotfix/docs/style/remove/test/chore/comment`
+- 한 커밋에 한 가지 목적. 개별 커밋 타입은 Issue·브랜치 타입과 달라도 됨
+- 기능 브랜치에서도 오류 수정은 `fix`, 문서는 `docs`, 테스트는 `test`로 구분
+- 코드 식별자와 전문 용어는 실제 표기 유지
+- 커밋 전 변경 파일·검증 범위·`git diff --check` 확인
+- 관련 없는 파일·비밀 정보·생성물 제외
 
 ```bash
 git status --short
 git diff --check
 git add <변경한-파일>
-git commit -m "feat: 다운로드 버튼과 진행 상태 추가"
+git commit -m "fix: 얼굴 등록 카메라 세션 충돌 수정"
 ```
-
-관련 없는 파일, 비밀 정보, 생성물은 커밋하지 않아요.
diff --git a/.claude/skills/issue/SKILL.md b/.claude/skills/issue/SKILL.md
@@ -1,51 +1,22 @@
-# 이슈 생성
+---
+name: issue
+description: Framework 저장소의 Issue 생성 및 작업 체크리스트 갱신 시 공통 제목과 개조식 본문 적용.
+---
 
-작업을 시작하기 전에 GitHub 이슈를 만들어요. 이슈는 작업을 추적하는 기준점이에요.
+# Issue 작성
 
-## 작업 유형
+[공통 작성 규칙](../../../docs/collaboration.md)의 Issue 양식을 읽는다.
 
-아래 네 유형 중 하나를 선택해요.
-
-| 유형 | 사용할 때 |
-| --- | --- |
-| `feat` | 새 기능을 개발할 때 |
-| `fix` | 버그를 수정할 때 |
-| `chore` | 기타 자잘한 수정이나 설정 변경을 할 때 |
-| `refactor` | 동작은 유지하며 코드를 정리할 때 |
-
-## 제목
-
-제목은 한국어로, 아래 형식으로 작성해요.
-
-```text
-<type>: <작업 내용>
-```
-
-예시:
-
-```text
-feat: GitHub 릴리스 다운로드 기능 추가
-fix: 로그인 후 화면 전환 오류 수정
-chore: 의존성 버전 정리
-refactor: 인증 서비스 구조 개선
-```
-
-## 담당자
-
-기본 담당자는 이슈를 만든 본인이에요. 다른 사람이 실제 작업을 맡는다면 그 사람을 담당자로 지정해요.
-
-## GitHub 웹에서 만들기
-
-이슈를 만들 때 작업 유형에 맞는 양식을 선택하고, 제목과 담당자를 지정해요.
-
-## GitHub CLI에서 만들기
+- 작업 전 Issue 생성, 실제 작업자 지정
+- 제목은 `feat/fix/chore/refactor: <한국어 작업 내용>`
+- 본문은 `작업 내용 / 작업 체크리스트 / 완료 기준`, 필요한 경우 마지막에 `참고` 추가
+- 한 항목에 한 가지 내용, 명사형 종결 사용. 진행 항목은 `- [ ]`로 작성하고 수행 후 체크
+- 완료 기준은 확인 가능한 결과로 작성
+- CLI 본문은 UTF-8 Markdown 파일과 `--body-file` 사용. 빈 본문과 문자열 `\n` 사용 금지
 
 ```bash
-gh issue create \
-  --title "feat: GitHub 릴리스 다운로드 기능 추가" \
-  --label "feat" \
-  --assignee "@me" \
-  --body ""
+gh issue create --title "fix: 카메라 세션 충돌 수정" \
+  --label "fix" --assignee "@me" --body-file issue.md
 ```
 
-생성된 이슈 번호를 이후 브랜치와 PR에 사용해요.
+생성한 번호를 브랜치와 PR에 사용한다. 작업 진행에 따라 기존 Issue 체크 상태를 갱신한다.