Menu
staged git 변경사항을 분석하여 프로젝트 커밋 컨벤션에 맞는 커밋 메시지 2-3개를 추천합니다. "커밋 메시지 추천", "commit 메시지", "어떻게 커밋할까", "커밋 어떻게 써", "git commit 도움" 등의 요청에 응답합니다. 커밋을 직접 실행하지 않습니다.
This skill should be used when the user asks to "Preview 만들어줘", "Preview 추가해줘", "composable preview 생성", "@Preview 함수 만들어줘", "compose preview 붙여줘", or wants to generate @Preview functions for a Composable file or function. Takes a file path or composable function name as $ARGUMENTS.
현재 브랜치와 develop의 차이를 분석하여 코드 리뷰를 수행한 뒤, 프로젝트 PR 템플릿에 맞는 설명을 작성하고 Pull Request를 생성합니다. "PR 만들어줘", "pull request 생성", "PR 올려줘", "PR 작성" 등의 요청에 응답합니다.
API 명세를 기반으로 Domain Layer(Model, UseCase, Repository Interface)와 Data Layer(RepositoryImpl, Retrofit API, Hilt 바인딩, Remote Model, Mapper)를 일관된 프로젝트 패턴에 맞춰 생성합니다.
프로젝트에서 Compose 디자인 시스템 컴포넌트를 설계하고 구현합니다. 기존 컴포넌트 패턴(네이밍, 파라미터 설계, 모델 분리)을 준수하며, 디자인 시스템은 Layout과 Action에 대해서만 알아야 하고 Presentation 고유의 비즈니스 로직 사용은 지양합니다.
| name | recommend-commit-message |
| description | staged git 변경사항을 분석하여 프로젝트 커밋 컨벤션에 맞는 커밋 메시지 2-3개를 추천합니다. "커밋 메시지 추천", "commit 메시지", "어떻게 커밋할까", "커밋 어떻게 써", "git commit 도움" 등의 요청에 응답합니다. 커밋을 직접 실행하지 않습니다. |
staged 변경사항을 분석하여 프로젝트 커밋 컨벤션에 맞는 커밋 메시지 후보 2-3개를 추천한다. 커밋을 직접 실행하지 않는다. 최종 선택과 실행은 사용자가 한다.
매 요청마다 아래 5단계를 순서대로 수행한다.
git diff --staged
출력이 비어있으면 즉시 종료하고 다음 메시지를 출력한다:
staged 변경사항이 없습니다.
git add <파일>로 먼저 파일을 staging 해주세요.
git diff
unstaged 변경사항이 있으면 출력 마지막에 경고를 추가한다 (커밋 메시지 생성은 계속 진행).
git log --pretty=format:"%h %s%n%b" -10
scope 사용 패턴, body 유무·스타일, 자주 쓰이는 type을 파악한다.
--oneline은 제목만 노출되어 body 스타일을 확인할 수 없으므로 이 포맷을 사용한다.
아래 커밋 컨벤션을 적용하여 후보 2-3개를 생성한다. 후보 1은 가장 권장하는 메시지로 선정하고 이유를 간단히 설명한다.
[type]([scope]): [한 줄 요약]
- [항목]: [상세 내용]
- [항목]: [상세 내용]
- [항목]: [상세])는 변경이 복잡하거나 이유가 필요할 때만 추가한다.| type | 사용 상황 |
|---|---|
feat | 새로운 기능 추가 |
fix | 버그 수정 |
refactor | 동작 변경 없는 코드 구조 개선 |
style | 포매팅, 세미콜론 등 코드 의미 변경 없는 수정 |
test | 테스트 코드 추가/수정 |
docs | 문서, 주석 변경 |
chore | 빌드 스크립트, 패키지 설정, CI 등 |
perf | 성능 개선 |
build | 빌드 시스템, 외부 의존성 변경 |
ci | CI/CD 파이프라인 설정 변경 |
revert | 이전 커밋 되돌리기 |
hotfix | 프로덕션 긴급 수정 |
design | UI/UX 디자인 변경 (로직 무관) |
move | 파일/디렉토리 이동 또는 이름 변경 |
remove | 파일/코드 삭제 |
init | 프로젝트/모듈 초기 설정 |
wip | 진행 중인 작업 (완료되지 않은 커밋) |
feat, fix)refactormovebuildci### 분석 요약
[변경된 파일 수, 주요 변경 내용 2-3줄 요약]
---
### 후보 1 ✅ (추천)
```
[type]([scope]): [요약]
- [항목]: [상세]
```
> 추천 이유: [한 줄]
---
### 후보 2
```
[type]([scope]): [요약]
```
---
### 후보 3 (선택)
```
[type]([scope]): [요약]
```
---
> ⚠️ unstaged 변경사항이 있습니다. 포함할 파일이 있다면 `git add` 후 다시 요청해주세요.
(unstaged가 없으면 이 경고는 생략)
커밋 분리가 필요한 경우 아래 형식으로 출력한다.
### 분석 요약
변경사항이 [N]개의 독립적인 목적을 포함합니다. 커밋을 분리하는 것을 권장합니다.
---
### 커밋 1 — [목적 요약]
**후보 1 ✅ (추천)**
```
[type]([scope]): [요약]
```
> 추천 이유: [한 줄]
**후보 2**
```
[type]([scope]): [요약]
```
---
### 커밋 2 — [목적 요약]
**후보 1 ✅ (추천)**
```
[type]([scope]): [요약]
```
> 추천 이유: [한 줄]
**후보 2**
```
[type]([scope]): [요약]
```
파일 경로 패턴으로 type을 1차 판단한다. 실제 diff 내용이 우선이며, 아래 표는 참고용이다.
| 경로 패턴 | 우선 고려 type |
|---|---|
*/designsystem/** | design, feat, refactor |
*/presentation/** (ViewModel, State) | feat, fix, refactor |
*/presentation/** (Composable, Screen) | feat, design |
*/domain/usecase/** | feat, refactor |
*/domain/model/** | feat, refactor, move |
*/domain/repository/** (interface) | feat, refactor |
*/data/repository/** (impl) | feat, fix, refactor |
*/data/remote/** (API, DTO) | feat, fix |
*/di/** (Hilt module) | feat, refactor, chore |
*.gradle, *.gradle.kts, libs.versions.toml | build, chore |
.github/workflows/** | ci |
*.md, *.txt | docs |
*Test.kt, *Spec.kt | test |