commit-style

النجوم٨

التفرعات١

آخر تحديث٧ يوليو ٢٠٢٦ في ١٢:٣٥

Writes git commit messages and performs commits for the jungle-bell project. Use this skill whenever the user says "커밋해줘", "commit", "git commit", or otherwise asks to commit changes, so the project's Conventional Commits + Korean-subject style is followed. Also use it when the user only wants a draft message.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

المصدر

YangSiJun528

YangSiJun528/jungle-bell

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

مستكشف الملفات

2 ملفات

SKILL.md

readonly

name	commit-style
description	Writes git commit messages and performs commits for the jungle-bell project. Use this skill whenever the user says "커밋해줘", "commit", "git commit", or otherwise asks to commit changes, so the project's Conventional Commits + Korean-subject style is followed. Also use it when the user only wants a draft message.

jungle-bell commit style

This project uses Conventional Commits with the subject and body written in Korean. The goal of this skill is to produce commits consistent with the existing patterns visible in git log.

Format

<type>(<scope>): <Korean subject>

<optional Korean body, explaining the "why">

The first line is a single type(scope): subject. No trailing period.
Omit the scope when none clearly applies (e.g. ci: ...).
Subjects end in Korean noun/verb forms ("추가", "수정", "개선", "비활성화", "분리", etc.).
The body explains why the change was made. Skip it for trivial changes (formatting, version bumps, obvious commits).

type

In order of frequency in the existing log:

feat — new feature
refactor — behavior unchanged, structure improved
fix — bug fix
chore — build/release/config chores. Version bumps are always chore(release)
docs — documentation-only changes
ci — GitHub Actions / workflows

scope

Scopes actually used in the project (check if an existing one fits before inventing a new scope):

release — version bumps, changelog, release workflows
analytics — PostHog events, collection logic
tray — system tray menu/icon
updater — auto updater
analyzer, webcrack, extractor — related to jungle-campus-analyzer/
checker — attendance check logic
rust, backend — Rust/Tauri backend in general
notification — OS notifications
ui, config — frontend / configuration

Pick the narrowest scope that matches the changed paths. Omit when ambiguous.

Writing the subject

Around 30 Korean characters, stating what was done.
Tone matches existing examples:
- 개발 빌드에서 PostHog 이벤트 전송 비활성화
- PostHog 이벤트에 OS 이름 프로퍼티 추가
- 트레이 메뉴에 버전/업데이트 상태 표시
- Rust 백엔드 모듈 분리 및 버전 bump 0.2.2-beta.2
Keep English proper nouns/identifiers (PostHog, CI, OS, API 키, etc.) inline as-is.
For chore(release) version bumps the subject is always the fixed English phrase bump version to <X.Y.Z>.

Writing the body

The body focuses on why the change was needed — background, cause, effect — not an enumeration of files/functions.

Good example:

`cfg!(debug_assertions)` 게이트를 추가해 `cargo tauri dev` 등 디버그 빌드에서는
이벤트가 전송되지 않도록 한다. 릴리스 빌드에서만 활성화되므로 개발 중 테스트
이벤트가 프로덕션 대시보드를 오염시키지 않는다.

When there are multiple changes, list them as - bullets, still explaining why per item:

- attendance_check_attempted → attendance_completed: 스케줄러 틱마다 발사하던 것을
  morning/evening 상태 전이 시에만 발사하도록 변경. ...
- PostHog 클라이언트 lazy 초기화로 변경하여 init() 직후 이벤트 유실 경쟁 상태 해소.

Wrap body lines around 80 characters. For simple bumps/trivial wording changes, no body.

Workflow

When the user requests a commit:

Inspect the changes with git status and git diff --staged (or unstaged). Re-check even if the prompt already shows status — look at the state right before committing.
Skim recent git log --oneline -10 to confirm the type/scope pattern fits this change.
Check for sensitive files (.env, credentials, etc.) in staging. Warn the user if any are mixed in.
If the user only asked for a draft message, stop after returning the draft.
If the requested commit scope is ambiguous, unrelated changes are mixed in, or sensitive files are present, ask one concise question before committing. Otherwise:
- In Codex, commit directly; the user already requested a commit.
- In runtimes that require explicit confirmation and provide AskUserQuestion, use the approval loop below.
Stage only the intended files by explicit path if they are not already staged. Avoid broad staging commands.
Commit with git commit -m. Use multiple -m arguments when a body is needed:

git commit -m "<type>(<scope>): <subject>" -m "<body>"

If there is no body, use a single-line git commit -m "<type>(<scope>): <subject>".

Confirm success with git status afterward.

Legacy approval loop

Use this only in runtimes that provide AskUserQuestion and require explicit confirmation before committing.

Question setup (header: "커밋 승인", multiSelect: false):

커밋 — commit with the current draft as-is
취소 — abort without committing
(기타) — free-text feedback. If the user enters feedback, revise the draft, print the new draft, and ask again.

Use a question like "이 메시지로 커밋할까요? 고칠 점이 있으면 'Type something'에 피드백을 적어 주세요." Loop until 커밋 or 취소 is selected.

Don't

Do not use --amend, --no-verify, or --no-gpg-sign unless the user explicitly asks.
Avoid git add -A / git add . — stage changed files by name.
Do not push on your own when the user only said "커밋해줘".
Before inventing a new type/scope, check whether an existing one applies.
No throat-clearing prefaces in the body like "이 커밋은…" or "이번 변경에서는…" — get straight to the point.
Use the current runtime's user-input style only when a decision is actually required.

Examples

Simple feat:

feat(tray): 식단표 보러가기 메뉴 항목 추가

Fix needing a "why":

fix(analytics): PostHog API 키 하드코딩으로 CI 빌드에서 analytics 활성화

option_env!() 방식은 CI 환경변수 미설정 시 analytics가 비활성화되는 문제가 있었음.
Project API key는 공개 전제 설계이므로 소스에 직접 포함.

Version bump:

chore(release): bump version to 0.2.6

المزيد من هذا المستودع

نفس المستودع

bump-version

YangSiJun528/jungle-bell

Bump the app version across all config files for the jungle-bell project. Use when the user asks to bump/update the version, or says "버전 올려줘", "bump version", "/bump-version". Updates package.json, package-lock.json, src-tauri/Cargo.toml, src-tauri/tauri.conf.json, and Cargo.lock.

2026-07-238

checker-session-repro

YangSiJun528/jungle-bell

jungle-bell hidden checker WebView를 사용자 수동 로그인/로그아웃 없이 세션 파일 백업/제거/복구로 로그인 없음 상태와 세션 복구 상태를 반복 재현하고 검증한다. checker.js ready/report, 세션 백업/복구, stale tray icon, watchdog refresh/give-up, checker 세션 재현 리포트 작성이 필요할 때 사용한다.

2026-07-238

tauri

YangSiJun528/jungle-bell

Cross-platform desktop application framework combining Rust backend with web frontend, emphasizing security and performance

2026-07-078

release

YangSiJun528/jungle-bell

Create a GitHub release with a tag from the current version in src-tauri/Cargo.toml. Use when the user asks to create a release, says "릴리즈 만들어줘", "release", "/release", or otherwise wants to publish a new version. Handles branch/state checks, changelog drafting (Korean), tag push, draft release creation, and CI workflow trigger.

2026-07-078

release

YangSiJun528/jungle-bell

2026-04-308

bump-version

YangSiJun528/jungle-bell

Bump the app version across all config files for the jungle-bell project. Use when the user asks to bump/update the version, or says "버전 올려줘", "bump version", "/bump-version". Updates src-tauri/Cargo.toml, src-tauri/tauri.conf.json, and regenerates Cargo.lock.

2026-04-218

name	commit-style
description	Writes git commit messages and performs commits for the jungle-bell project. Use this skill whenever the user says "커밋해줘", "commit", "git commit", or otherwise asks to commit changes, so the project's Conventional Commits + Korean-subject style is followed. Also use it when the user only wants a draft message.

jungle-bell commit style

This project uses Conventional Commits with the subject and body written in Korean. The goal of this skill is to produce commits consistent with the existing patterns visible in git log.

Format

<type>(<scope>): <Korean subject>

<optional Korean body, explaining the "why">

The first line is a single type(scope): subject. No trailing period.
Omit the scope when none clearly applies (e.g. ci: ...).
Subjects end in Korean noun/verb forms ("추가", "수정", "개선", "비활성화", "분리", etc.).
The body explains why the change was made. Skip it for trivial changes (formatting, version bumps, obvious commits).

type

In order of frequency in the existing log:

feat — new feature
refactor — behavior unchanged, structure improved
fix — bug fix
chore — build/release/config chores. Version bumps are always chore(release)
docs — documentation-only changes
ci — GitHub Actions / workflows

scope

Scopes actually used in the project (check if an existing one fits before inventing a new scope):

release — version bumps, changelog, release workflows
analytics — PostHog events, collection logic
tray — system tray menu/icon
updater — auto updater
analyzer, webcrack, extractor — related to jungle-campus-analyzer/
checker — attendance check logic
rust, backend — Rust/Tauri backend in general
notification — OS notifications
ui, config — frontend / configuration

Pick the narrowest scope that matches the changed paths. Omit when ambiguous.

Writing the subject

Around 30 Korean characters, stating what was done.
Tone matches existing examples:
- 개발 빌드에서 PostHog 이벤트 전송 비활성화
- PostHog 이벤트에 OS 이름 프로퍼티 추가
- 트레이 메뉴에 버전/업데이트 상태 표시
- Rust 백엔드 모듈 분리 및 버전 bump 0.2.2-beta.2
Keep English proper nouns/identifiers (PostHog, CI, OS, API 키, etc.) inline as-is.
For chore(release) version bumps the subject is always the fixed English phrase bump version to <X.Y.Z>.

Writing the body

The body focuses on why the change was needed — background, cause, effect — not an enumeration of files/functions.

Good example:

`cfg!(debug_assertions)` 게이트를 추가해 `cargo tauri dev` 등 디버그 빌드에서는
이벤트가 전송되지 않도록 한다. 릴리스 빌드에서만 활성화되므로 개발 중 테스트
이벤트가 프로덕션 대시보드를 오염시키지 않는다.

When there are multiple changes, list them as - bullets, still explaining why per item:

- attendance_check_attempted → attendance_completed: 스케줄러 틱마다 발사하던 것을
  morning/evening 상태 전이 시에만 발사하도록 변경. ...
- PostHog 클라이언트 lazy 초기화로 변경하여 init() 직후 이벤트 유실 경쟁 상태 해소.

Wrap body lines around 80 characters. For simple bumps/trivial wording changes, no body.

Workflow

When the user requests a commit:

Inspect the changes with git status and git diff --staged (or unstaged). Re-check even if the prompt already shows status — look at the state right before committing.
Skim recent git log --oneline -10 to confirm the type/scope pattern fits this change.
Check for sensitive files (.env, credentials, etc.) in staging. Warn the user if any are mixed in.
If the user only asked for a draft message, stop after returning the draft.
If the requested commit scope is ambiguous, unrelated changes are mixed in, or sensitive files are present, ask one concise question before committing. Otherwise:
- In Codex, commit directly; the user already requested a commit.
- In runtimes that require explicit confirmation and provide AskUserQuestion, use the approval loop below.
Stage only the intended files by explicit path if they are not already staged. Avoid broad staging commands.
Commit with git commit -m. Use multiple -m arguments when a body is needed:

git commit -m "<type>(<scope>): <subject>" -m "<body>"

If there is no body, use a single-line git commit -m "<type>(<scope>): <subject>".

Confirm success with git status afterward.

Legacy approval loop

Use this only in runtimes that provide AskUserQuestion and require explicit confirmation before committing.

Question setup (header: "커밋 승인", multiSelect: false):

커밋 — commit with the current draft as-is
취소 — abort without committing
(기타) — free-text feedback. If the user enters feedback, revise the draft, print the new draft, and ask again.

Use a question like "이 메시지로 커밋할까요? 고칠 점이 있으면 'Type something'에 피드백을 적어 주세요." Loop until 커밋 or 취소 is selected.

Don't

Do not use --amend, --no-verify, or --no-gpg-sign unless the user explicitly asks.
Avoid git add -A / git add . — stage changed files by name.
Do not push on your own when the user only said "커밋해줘".
Before inventing a new type/scope, check whether an existing one applies.
No throat-clearing prefaces in the body like "이 커밋은…" or "이번 변경에서는…" — get straight to the point.
Use the current runtime's user-input style only when a decision is actually required.

Examples

Simple feat:

feat(tray): 식단표 보러가기 메뉴 항목 추가

Fix needing a "why":

fix(analytics): PostHog API 키 하드코딩으로 CI 빌드에서 analytics 활성화

option_env!() 방식은 CI 환경변수 미설정 시 analytics가 비활성화되는 문제가 있었음.
Project API key는 공개 전제 설계이므로 소스에 직접 포함.

Version bump:

chore(release): bump version to 0.2.6