kf-git-commit-japanese-commit-message

5-character-prefix Japanese commit message

Use this skill when creating commit messages with the following template.

<type_>: <subject (日本語)>

- 概要:
  - <何を変えたかを記載>
  - <必要なら追加項目を記載>
- Why:
  - <なぜこの対応を行なったかを記載>
  - <必要なら背景や意図を記載>

• type_: fixed 5-character prefix
• subject: concise Japanese description of the change
• Line 2: blank line
• Line 3 onward: body briefly separating the change summary and reason

When to use this skill

Use this skill for requests such as the following.

• Please commit
• I want you to think of a commit message
• I want you to choose an appropriate prefix from the changes
• I want to format an existing commit message to match these rules
• I want to apply the commit message convention for Japanese subjects
• feat_ fix__ docs_ style refa_ perf_ test_ chore need to be used properly

Basic rules

1. The output format consists of a subject line and a body

Always output commit messages in the following multi-line format.概要 と Why If it fits on one line, write it on one line; if it gets long, split it into bullet points below.

<type_>: <subject (日本語)>

- 概要:
  - <何を変えたかを記載>
  - <必要なら追加項目を記載>
- Why:
  - <なぜこの対応を行なったかを記載>
  - <必要なら背景や意図を記載>

Structure rules:

• Line 1 is type_: subject format
• Line 2 must be a blank line
• Write the body from line 3 onward
• Write the body as bullet points
• Include at least - 概要 と - Why include
• 概要 と Why If it fits on one line, - 概要: ... - Why: ... format is also acceptable
• If a sentence gets long or there are multiple points, split them into bullet points under the heading

2. The prefix is fixed at 5 characters

Only the following 8 prefixes can be used.

Prefix	Meaning	Usage example
feat_	Adding a new feature	feat_: Implement user login feature
fix__	Bug fix	fix__: Fix display breakage of the search modal
docs_	Documentation-only change	docs_: Update setup instructions in README.md
style	Change that does not affect the meaning of the code	style: Unify indentation to 4 spaces
refa_	Refactoring	refa_: Extract methods from the User class
perf_	Performance improvement	perf_: Support lazy loading of images
test_	Adding/fixing tests	test_: Add unit tests for payment processing
chore	Changes to the build process or tools	chore: Update dependency library versions

Use the prefixes exactly as written, without changing the notation. Even if similar in meaning, do not use prefixes not in the list.

3. Write the subject concisely in Japanese

The subject should briefly describe the core of the change.

• Write in Japanese
• Narrow down to a single main purpose of the change
• Do not include redundant preamble
• Do not add a period at the end of sentences
• Prefer noun-ending style
• Do not use honorific language
• If a sentence becomes long, move details to the body
• Rather than vague expressions like "fix handling" or "implement handling," write specifically what was changed

Good example:

• fix__: 検索結果0件時のローディング終了不備を修正
• refa_: 認証処理のサービス層分離
• docs_: 開発環境構築の前提条件を追記

Example to avoid:

• fix__: いろいろ修正
• chore: 対応
• feat_: 機能を追加しました

4. Keep the writing style concise

For the commit message as a whole, prioritize a short, easy-to-read form.

• If a sentence is likely to become long, split it into the next bullet point
• Write only one point per bullet
• Use noun-ending style frequently
• Do not use honorific language
• Keep conjunctions and preamble to a minimum

5. State the summary and reason in the body

In the body from the third line onward, write at least the following two items.

• - 概要
• - Why: なぜこの対応を行なったか

Writing rules:

• Start with bullet points
• 概要 と Why If it can be written briefly in one line, it may be left as one line
• If there are multiple points or a sentence becomes long, split them into subordinate bullet points
• 概要 Write briefly what was changed in
• Why Write the background, problem, intent, and necessity in
• Why The label for is Why: state explicitly
• Write the body concisely in Japanese as well
• Prefer short bullet points over long text
• Use noun-ending style frequently

Example:

feat_: ユーザーログイン機能を追加

- 概要:
  - メールアドレスとパスワードによるログイン機能の追加
  - 認証エラー表示の追加
- Why:
  - マイページ利用に必要な認証導線
  - 失敗時の再試行可否が分からない状態の解消

Prefix selection guide

Look at the changes and choose the single closest one according to the following criteria.

feat_

Use this when adding a new feature, screen, API, or behavior that has user value.

• When newly adding an operation flow, supported platform, input method, or setting item that did not exist before, prioritize feat_ prioritize
• Expanding the available scope, such as adding an operation that exists on PC but not on smartphones, is also considered feat_ is also considered
• Changes that add new user experiences or operation paths, rather than fixing existing defects, should lean toward feat_ should lean toward

fix__

Use this when fixing a bug, malfunction, display breakage, exception, or discrepancy from expectations.

• Only when behavior that should already be provided is broken, diverges from the specification, has regressed, or results in an error, select fix__ select
• Adding new flows or supporting unsupported platforms should, in principle, even if there is a problem-resolution context, be fix__ not feat_ prioritize

docs_

Use this when only documentation is changed, such as README, design documents, or comment cleanup.

style

Use this for changes that do not affect meaning or behavior, such as formatting, whitespace, lint fixes, or reordering.

refa_

Use this for changes that do not include feature additions or bug fixes, such as internal structure cleanup, responsibility separation, naming improvements, or deduplication.

perf_

Used for improvements such as speed, memory efficiency, rendering performance, and I/O efficiency.

test_

Used for adding or modifying unit tests, integration tests, and E2E tests.

chore

Used for changes that do not directly alter the behavior of the source code itself, such as dependencies, CI, build settings, development tools, and scripts.

Decision rules

1. When there are multiple changes, prioritize the main purpose

Even if a single commit contains multiple elements, choose one prefix that matches the most important change intent.

Example:

• If tests were also added along with a new feature, and the main purpose is the new feature, then feat_
• If refactoring was done to fix a bug, and the main purpose is the bug fix, then fix__

2. When unsure, prioritize externally visible effects

Even if it is internal cleanup, if there is new value or a bug fix from the user's perspective,feat_ や fix__ should be prioritized.

Additional criteria:

• If the user gains new things they can do, then feat_
• If it restores something the user should have been able to do, then fix__
• "Support for operations or environments that were not previously supported" should prioritize fix__ rather than feat_ prioritize

3. When information is insufficient

When the changes are ambiguous and it is hard to determine the prefix, do not invent details on your own; provide the most reasonable option within what is known. If the user is not asking for an explanation either, do not add excessive annotations. Only in situations where an explanation is needed, briefly note which assumptions you used to choose.

Generation procedure

When creating a commit message, think in the following order.

1. Summarize the main purpose from the changes into one.
2. Choose the most appropriate one from the 8 types of prefixes.
3. Distinguish whether the main purpose is "enabling something new" or "fixing something broken."
4. Make the changes into a concise subject in Japanese.
5. In the body, write 概要 と Why in Japanese.
6. Break long parts into the following bullet points.
7. Organize mainly with noun-ending style and avoid honorific language.
8. Format the first line as <type_>: <subject (日本語)> .
9. Make the second line a blank line.
10. Check that the prefix is fixed at 5 characters.

Body template

If unsure, base it on the following format. Only items that fit on one line should be summarized in - 概要: ... - Why: ... .

<type_>: <subject (日本語)>

- 概要:
  - 何を変えたか
  - 必要なら次の要点
- Why:
  - なぜこの対応を行なったか
  - 必要なら背景や制約

Output examples

Example 1: Input: Fix the bug where an error message is not displayed when login fails Output:

fix__: ログイン失敗時のエラーメッセージ表示を修正

- 概要: 認証失敗時にエラートーストを表示
- Why: 失敗理由が分からず再試行しづらい状態の解消

Example 2: Input: Add local development steps to the README Output:

docs_: READMEにローカル開発手順を追記

- 概要:
  - 初回セットアップ手順を追記
  - 起動確認手順を追記
- Why:
  - 新規参加者が環境構築で詰まりやすい状況
  - 参照先分散の解消

Example 3: Input: Make it possible to open a menu equivalent to a PC right-click by long-pressing a video card on a smartphone Output:

feat_: スマホ長押しで動画カード操作メニューを追加

- 概要:
  - タッチ長押しで動画カードの操作ポップアップを表示
  - 長押し後の誤タップ抑止と関連テストを追加
- Why:
  - スマホでは右クリック導線が存在しないため
  - モバイルでもPCと同じ操作を使えるようにするため

Input: Improve API response caching to speed up list display Output:

perf_: 一覧APIレスポンスのキャッシュ処理を改善

- 概要:
  - 一覧APIのキャッシュ利用条件を見直し
  - 不要な再取得回数を削減
- Why:
  - 画面遷移ごとの再フェッチ発生
  - 表示完了までの待ち時間短縮

Full commit message sample

Write the full commit message as follows.

feat_: ユーザー招待メール再送機能を追加

- 概要:
  - 管理画面に再送操作を追加
  - 招待メール再送 API を追加
- Why:
  - 期限切れや未達時の再招待手段が必要
  - 手動対応負荷の軽減

Final check

Before returning, check the following.

• The first line is <type_>: <subject> is present
• The second line is blank
• There is a body on the third line onward
• The prefix is one of the 8 allowed types and is fixed at 5 characters
• The subject is written concisely in Japanese
• The subject expresses the main purpose of the change
• The body contains - 概要 と - Why: is included
• 概要 と Why but is split into multiple bullet lines as needed
• The whole thing is concise, and long text is split into bullet points
• It frequently uses noun-ending style and does not use honorific language
• The body is written concisely in Japanese