chshzh/charlie-claude

Git コミットワークフロー

重要なルール

1. コミット前に検査する: コミットを提案または作成する前に、必ず git diff . を実行してワークツリー全体を確認します。
2. 計画してからコミット: コミット計画（ファイルのグループ、理由、推奨メッセージ）を提示し、ユーザーの明示的な承認を待ってから git commit を実行します。
3. 論理的な変更単位で分割する: コミットは関心事ごとに分離します。ユーザーが明示的に要求しない限り、無関係な修正、リファクタリング、ドキュメント、フォーマットのみの変更、生成ファイルなどを混在させないでください。
4. 対話型コマンドは使用しない: 非対話型の Git コマンドのみを使用します。
5. 決して許可を仮定しない: 「変更をコミットして」というリクエストは、検査と計画の許可と見なし、git commit の実行許可とは見なさないでください。

ワークフロー

ステップ 1 — ワークツリーの検査

git diff .
git status --short
git diff --cached   # ステージングされた変更がある場合のみ

ステップ 2 — コミット計画の提案

以下の項目を示す表またはリストを提示します。

• グループ: 各提案コミットのファイルセット
• 理由: これらのファイルが一緒に属する理由
• 推奨コミットメッセージ: リポジトリに適したスタイルを使用（下記のコミットメッセージ形式を参照）

ステップ 3 — 承認待ち

計画を提示した後、AskQuestion ツールを使用して承認を得ます。常に以下の選択肢を提供します。

Question: 「このコミット計画で進めますか？」
Options:
  - 「承認 — 計画通りコミット」
  - 「先にコミットメッセージを編集」
  - 「コミットを再グループ化」
  - 「キャンセル」

ユーザーが 承認 を選択するまで git commit を実行しないでください。他の選択は計画の修正リクエストとして扱います。

ステップ 4 — 承認されたコミットの実行

承認された各コミットについて、関連ファイルのみをステージングしてコミットします。

git add <file1> <file2> ...
git commit -s -m "type(scope): description"

複数行のメッセージには必要に応じて HEREDOC を使用します。

git commit -s -m "$(cat <<'EOF'
type(scope): short summary

- detail line 1
- detail line 2
EOF
)"

コミットメッセージ形式

まずリポジトリタイプを判別する

リポジトリ	スタイル
ユーザーアプリリポジトリ（自身のプロジェクト）	Conventional Commits
zephyr/、nrf/、nrfxlib/、modules/	Zephyr スタイル

ユーザーアプリリポジトリ — Conventional Commits

type(scope): short summary

一般的なタイプ: feat、fix、refactor、docs、chore、test、style、build。タイトルは 72 文字以内。ボディは任意ですが、重要でない変更以外には役立ちます。

NCS / Zephyr リポジトリ — Zephyr スタイル

[nrf tag] area: subarea: short summary

Body explaining what, why, assumptions, and how it was verified.

Upstream PR #: NNNNN          (if porting from upstream)
Ref: NCSDK-XXXXX              (if tracking an internal ticket)
Assisted-by: Claude:claude-sonnet-4.6   (if AI-assisted)
Signed-off-by: Full Name <email>

• タイトルは 72 文字以内；ボディは必須（空でないこと）アップストリームへのコントリビューションの場合
• ボディの各行は 75 文字以内
• Signed-off-by: 必須（DCO）— git commit -s を使用
• NRF プレフィックスタグ: [nrf fromlist]（アップストリームへ）、[nrf fromtree]（アップストリームから）、[nrf noup]（NCS のみ）、[nrf ncsdk]（SDK のみ）
• AI が実質的なコードを書いた場合は Assisted-by: を追加

例:

[nrf fromlist] drivers: nrf_wifi: add WPA3-AUTO security type

The wpa_supplicant requires a dedicated key_mgmt enum value for
WPA3-AUTO mode. Without this, stations advertising both WPA2 and
WPA3 fail key exchange.

Upstream PR #: 106674
Signed-off-by: Your Name <[email protected]>

[nrf noup] tests: my_module: add unit test for zero-length buffer

Tests the boundary condition where input buffer length equals zero,
which previously triggered an assertion in the parser.

Ref: NCSDK-12345
Signed-off-by: Your Name <[email protected]>

グループ化ガイドライン

変更タイプ	別コミットにするか
新機能コード	はい
バグ修正	はい
リファクタリング（動作変更なし）	はい
設定 / Kconfig 変更	はい（関連機能と一緒でも可）
ドキュメント / README	はい（機能と密結合している場合を除く）
フォーマット / 空白のみ	はい
生成 / 自動更新ファイル	はい
ボードオーバーレイ + 対応 prj.conf	まとめて可
Sysbuild ファイル	論理的な目的でグループ化

NCS 固有の注意点

ファイルグループ化:

• prj.conf、boards/*.conf、overlay-*.conf — 有効にする機能と一緒にグループ化
• CMakeLists.txt の変更 — 機能追加の一部として自明でない限り、別コミット
• west.yml の変更 — 常に別コミットとし、明確な理由を記載
• sysbuild/ ファイル — 論理的な目的でグループ化（例：mcuboot 設定変更はまとめる）
• 生成されたパーティションマネージャファイル（pm/、*.map）— 別の chore コミットにするか、意味がなければ省略

NCS/Zephyr リポジトリ（zephyr/、nrf/、nrfxlib/）の場合:

• Conventional Commits ではなく Zephyr スタイルを使用（上記参照）
• 常に空でないボディを含める — CI はアップストリーム PR の空ボディを拒否します
• git log -- <file> を実行して、同じサブシステムの他のコミットがどのようにフォーマットされているかを確認

単一ファイル内の変更の分割

1 つのファイルに論理的に異なる 2 つ以上の変更（例：バグ修正 + 新しいポリシーセクション）が含まれ、別々のコミットに属する場合、対話型ステージングを使わずに分割します。

1. ファイルから 後半 のセクションを一時的に削除（Python または StrReplace）
2. 最初 の変更をステージングしてコミット
3. 削除したセクションを復元
4. 2 番目 の変更をステージングしてコミット

MARKER = "\n## Self-Update Policy\n"
text = path.read_text()
path.write_text(text[:text.find(MARKER)])  # 後半セクションを削除
# → git add + commit "fix: ..."
path.write_text(text)                      # 全内容を復元
# → git add + commit "feat: ..."

理由: git log -p <file> で各論理変更がそれぞれのコミットに表示されるため、バイセクト、レビュー、個別のリバートが容易になります。

注意点: マーカーが関数/ブロックの閉じ行の 前 にあることを常に確認してください。マーカーが関数内の最後の文である場合、削除後のファイルは return や } が欠落し、expected declaration or statement at end of input エラーが発生する可能性があります。

セルフアップデートポリシー

各会話の終了時に、発見した内容を確認し、このスキルの事実に新しいもの、修正されたもの、または古くなったもの（例：新しいグループ化パターン、NCS 固有のファイル規約、コミットメッセージ規約）がないか確認します。

更新が必要な場合:

1. 各変更案とその簡単な理由を収集します。
2. 要約をユーザーに提示し、AskQuestion を使用して承認を求めます。
3. 承認された更新を直ちにこのファイルに適用します。

ユーザーが明示的に要求しない限り、会話の途中でこのスキルを変更しないでください。