ワンクリックでManusで任意のスキルを実行

high-quality-commit

スター1

フォーク0

更新日2025年12月13日 19:06

코드 변경 사항을 적절한 git 커밋 전략으로 git commit한다. 기본적으로는 기존 git 커밋에 squash 전략을 적용하며, 필요에 따라 브랜치 전체의 git 커밋 히스토리를 재구성한다. 구현 완료 시점이나 사용자가 git commit을 요청했을 때 사용한다.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

gaebalai

gaebalai/claude-code-marketplace

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

High Quality Commit

이 스킬은 코드 변경 사항을 고품질 git 커밋으로 기록하기 위한 포괄적인 가이드를 제공한다.

Instructions

Step 1: 브랜치 및 git 커밋 히스토리 확인

아래 명령어로 현재 상태를 확인한다:

git status
git log --oneline --graph origin/main..HEAD

확인 사항:

현재 브랜치 이름
main 브랜치 기준으로 몇 개의 git 커밋이 쌓여 있는지
각 git 커밋의 내용과 커밋 단위(그레인)

Step 2: git 커밋 전략 판단

아래 기준에 따라 git 커밋 전략을 선택한다:

전략 A: Squash (기본 전략)

다음 조건을 만족하는 경우 기존 git 커밋에 squash 한다:

브랜치에 이미 git 커밋이 존재한다
변경 내용이 기존 git 커밋과 동일한 주제 또는 기능에 속한다
git 커밋을 분리해야 할 합리적인 이유가 없다

실행 방법:

git add -A
git commit --amend

git 커밋 메시지를 적절히 수정한다.

전략 B: 신규 git 커밋

다음에 해당하는 경우 신규 git 커밋을 생성한다:

브랜치에서 첫 번째 git 커밋인 경우
기존 git 커밋과 명확히 구분되는 독립적인 변경
git 커밋을 분리하는 것이 히스토리 이해에 도움이 되는 경우

실행 방법:

git add -A
git commit

전략 C: Interactive Rebase (git 커밋 재구성)

다음의 경우 브랜치 전체 git 커밋을 재구성한다:

여러 개의 작은 git 커밋을 논리적인 단위로 정리하고 싶은 경우
git 커밋 순서를 변경하고 싶은 경우
불필요한 git 커밋을 제거하고 싶은 경우
git 커밋 히스토리를 의미 있는 단위로 재편성하고 싶은 경우

실행 방법:

git rebase -i origin/main

에디터에서 다음 작업을 수행한다:

pick: git 커밋을 그대로 유지
squash 또는 s: 이전 git 커밋과 병합
reword 또는 r: git 커밋 메시지 수정
줄 순서를 변경해 git 커밋 순서 변경

Step 3: git 커밋 메시지 가이드라인

git 커밋 메시지는 아래 형식을 따른다:

<type>: <subject>

<body>

<footer>

Type:

feat: 신규 기능
fix: 버그 수정
refactor: 리팩토링
test: 테스트 추가 또는 수정
docs: 문서 변경
chore: 빌드 프로세스, 도구 변경 등

Subject:

50자 이내
명령형으로 작성 (예: "Added"가 아닌 "Add")
문장 끝에 마침표를 붙이지 않는다

Body(선택):

변경의 이유와 배경을 설명
무엇을 바꿨는지가 아니라 왜 바꿨는지를 기술
한 줄당 72자 기준으로 줄바꿈

Footer(선택):

Issue 번호 참조 (예: Closes #123)
Breaking changes 설명

Step 4: git commit 이후 확인

git commit 후 아래를 확인한다:

git log -1 --stat
git status

git 커밋이 올바르게 생성되었는지
의도한 파일이 모두 포함되었는지
git 커밋 메시지가 적절한지

중요 주의 사항

main 브랜치에서 실행 금지: main 브랜치에 직접 git commit 하지 않는다.
주석 금지: 코드 내 설명용 주석은 남기지 않는다.
원자적 git 커밋: 각 git 커밋은 독립적으로 의미를 가져야 한다.
일관성 유지: 프로젝트의 기존 git 커밋 스타일을 따른다.

전략 선택 플로우차트

브랜치에 git 커밋이 있는가?
  ├─ No → 신규 git 커밋 생성
  └─ Yes → 변경 내용이 기존 git 커밋과 같은 주제인가?
      ├─ Yes → Squash（git commit --amend）
      └─ No → git 커밋을 분리할 합리성이 있는가?
          ├─ Yes → 신규 git 커밋 생성
          └─ 히스토리를 정리하고 싶다 → Interactive Rebase

このリポジトリの他の Skills

同じリポジトリ

check-library

gaebalai/claude-code-marketplace

라이브러리 정보를 확인하기 위한 스킬이다. Next.js, shadcn, 기타 라이브러리에 대해 적절한 MCP 서버를 사용해 최신 문서와 사용 방법을 조회한다.

2025-12-131

create-git-worktree

gaebalai/claude-code-marketplace

git worktree를 활용해 분리된 작업 환경을 자동으로 구축한다. 기본 브랜치에서 최신 코드를 가져와 `.git-worktrees/` 디렉터리에 새로운 worktree를 생성하고, `.env`, Serena memories, npm 의존성을 자동으로 설정한다. 브랜치명에 포함된 `/`는 자동으로 `-`로 변환된다. 이미 존재하는 worktree가 있을 경우 재사용한다.

2025-12-131

read-unresolved-pr-comments

gaebalai/claude-code-marketplace

GitHub PR에서 아직 대응되지 않은 코멘트를 조회한다. GraphQL API를 사용해 (1) 코드의 특정 라인에 연결된 미해결 Review thread(Resolve 가능)와 (2) 코드 블록을 포함한 Issue comment(대화 탭, Resolve 불가)를 모두 가져와 JSON 형식으로 출력한다. PR 정보(번호, 제목, URL, 상태, 작성자, 리뷰어)도 함께 포함된다.

2025-12-131

resolve-pr-comments

gaebalai/claude-code-marketplace

GitHub PR의 미해결 Review thread를 일괄 Resolve한다. GraphQL API를 사용해 미해결 Review thread(코드 특정 라인에 대한 코멘트)를 조회한 뒤, resolveReviewThread mutation으로 모두 자동 Resolve한다. Issue comment(대화 탭)는 원래 Resolve 기능이 없으므로 대상에서 제외된다. 각 스레드의 Resolve 결과를 출력한다.

2025-12-131

web-search

gaebalai/claude-code-marketplace

gemini 명령어를 사용한 고급 Web 검색 스킬이다. Web 검색을 수행할 때는 Claude Code의 기본 Web Search 도구보다 이 스킬을 우선적으로 사용한다.

2025-12-131

name	high-quality-commit
description	코드 변경 사항을 적절한 git 커밋 전략으로 git commit한다. 기본적으로는 기존 git 커밋에 squash 전략을 적용하며, 필요에 따라 브랜치 전체의 git 커밋 히스토리를 재구성한다. 구현 완료 시점이나 사용자가 git commit을 요청했을 때 사용한다.

High Quality Commit

이 스킬은 코드 변경 사항을 고품질 git 커밋으로 기록하기 위한 포괄적인 가이드를 제공한다.

Instructions

Step 1: 브랜치 및 git 커밋 히스토리 확인

아래 명령어로 현재 상태를 확인한다:

git status
git log --oneline --graph origin/main..HEAD

확인 사항:

현재 브랜치 이름
main 브랜치 기준으로 몇 개의 git 커밋이 쌓여 있는지
각 git 커밋의 내용과 커밋 단위(그레인)

Step 2: git 커밋 전략 판단

아래 기준에 따라 git 커밋 전략을 선택한다:

전략 A: Squash (기본 전략)

다음 조건을 만족하는 경우 기존 git 커밋에 squash 한다:

브랜치에 이미 git 커밋이 존재한다
변경 내용이 기존 git 커밋과 동일한 주제 또는 기능에 속한다
git 커밋을 분리해야 할 합리적인 이유가 없다

실행 방법:

git add -A
git commit --amend

git 커밋 메시지를 적절히 수정한다.

전략 B: 신규 git 커밋

다음에 해당하는 경우 신규 git 커밋을 생성한다:

브랜치에서 첫 번째 git 커밋인 경우
기존 git 커밋과 명확히 구분되는 독립적인 변경
git 커밋을 분리하는 것이 히스토리 이해에 도움이 되는 경우

실행 방법:

git add -A
git commit

전략 C: Interactive Rebase (git 커밋 재구성)

다음의 경우 브랜치 전체 git 커밋을 재구성한다:

여러 개의 작은 git 커밋을 논리적인 단위로 정리하고 싶은 경우
git 커밋 순서를 변경하고 싶은 경우
불필요한 git 커밋을 제거하고 싶은 경우
git 커밋 히스토리를 의미 있는 단위로 재편성하고 싶은 경우

실행 방법:

git rebase -i origin/main

에디터에서 다음 작업을 수행한다:

pick: git 커밋을 그대로 유지
squash 또는 s: 이전 git 커밋과 병합
reword 또는 r: git 커밋 메시지 수정
줄 순서를 변경해 git 커밋 순서 변경

Step 3: git 커밋 메시지 가이드라인

git 커밋 메시지는 아래 형식을 따른다:

<type>: <subject>

<body>

<footer>

Type:

feat: 신규 기능
fix: 버그 수정
refactor: 리팩토링
test: 테스트 추가 또는 수정
docs: 문서 변경
chore: 빌드 프로세스, 도구 변경 등

Subject:

50자 이내
명령형으로 작성 (예: "Added"가 아닌 "Add")
문장 끝에 마침표를 붙이지 않는다

Body(선택):

변경의 이유와 배경을 설명
무엇을 바꿨는지가 아니라 왜 바꿨는지를 기술
한 줄당 72자 기준으로 줄바꿈

Footer(선택):

Issue 번호 참조 (예: Closes #123)
Breaking changes 설명

Step 4: git commit 이후 확인

git commit 후 아래를 확인한다:

git log -1 --stat
git status

git 커밋이 올바르게 생성되었는지
의도한 파일이 모두 포함되었는지
git 커밋 메시지가 적절한지

중요 주의 사항

main 브랜치에서 실행 금지: main 브랜치에 직접 git commit 하지 않는다.
주석 금지: 코드 내 설명용 주석은 남기지 않는다.
원자적 git 커밋: 각 git 커밋은 독립적으로 의미를 가져야 한다.
일관성 유지: 프로젝트의 기존 git 커밋 스타일을 따른다.

전략 선택 플로우차트

브랜치에 git 커밋이 있는가?
  ├─ No → 신규 git 커밋 생성
  └─ Yes → 변경 내용이 기존 git 커밋과 같은 주제인가?
      ├─ Yes → Squash（git commit --amend）
      └─ No → git 커밋을 분리할 합리성이 있는가?
          ├─ Yes → 신규 git 커밋 생성
          └─ 히스토리를 정리하고 싶다 → Interactive Rebase