القائمة
Gitの変更をステージしてコミットする。「コミットして」「コミットしたい」「変更をコミット」といったリクエストで使用。差分を分析し、whatとwhyを含む適切なコミットメッセージを自動生成する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | create-commit |
| description | Gitの変更をステージしてコミットする。「コミットして」「コミットしたい」「変更をコミット」といったリクエストで使用。差分を分析し、whatとwhyを含む適切なコミットメッセージを自動生成する。 |
現在のブランチで変更をステージし、適切なコミットメッセージでコミットする。
良いコミットメッセージには**what（何を変更したか）とwhy（なぜ変更したか）**の両方が含まれる。
git status で現在の状態を確認git diff と git diff --cached で変更内容を把握git add <ファイル>）
b. コミットメッセージを生成
c. コミットを実行1つのコミットには1つの目的（why）のみを含めるべき。複数の目的が混在すると:
以下の観点で変更を分類する:
| 観点 | 説明 |
|---|---|
| why（理由） | 同じ理由・目的の変更は同じコミットへ |
| 機能的な関連性 | 同じ機能に対する変更は同じコミットへ |
| 変更の種類 | 新機能、バグ修正、リファクタリング、ドキュメント更新など |
1つの作業セッションで以下の変更があった場合:
UserProfileView.swift に編集機能を追加LegacyUserManager.swift を削除（不要になったレガシーコード）README.md にセットアップ手順を追加→ 3つの別コミットに分ける:
feat: UserProfileViewに編集機能を追加refactor: LegacyUserManagerを削除docs: READMEにセットアップ手順を追加prefix: 概要説明（what）
why:
なぜこの変更が必要だったかの説明
what:
- 具体的な変更点1
- 具体的な変更点2
- ...
Info.plistにATTの設定を追加変更の理由・背景・意図を説明する。以下のような観点で記述:
具体的に何を変更したかをリスト形式で記述:
| Prefix | 用途 |
|---|---|
feat | 新機能の追加 |
fix | バグ修正 |
docs | ドキュメントのみの変更 |
style | コードの動作に影響しない変更（空白、フォーマット等） |
refactor | バグ修正でも機能追加でもないコード変更 |
perf | パフォーマンス改善 |
test | テストの追加・修正 |
chore | ビルドプロセスや補助ツールの変更 |
build | ビルドシステムや外部依存関係の変更 |
ci | CI設定ファイルやスクリプトの変更 |
revert | 以前のコミットを取り消し |
feat: UserProfileViewに編集機能を追加
why:
ユーザーからプロフィールを変更したいという要望が多く寄せられていた。
現状では設定画面からしか変更できず、導線がわかりにくかった。
プロフィール画面から直接編集できるようにすることでUXを改善する。
what:
- EditProfileSheetを新規作成
- プロフィール画像の変更機能を実装（PhotosPickerを使用）
- ユーザー名のバリデーションを追加（3-20文字、英数字のみ）
- 保存時のローディング表示とエラーハンドリングを追加
fix: ログイン画面でクラッシュする問題を修正
why:
ユーザーがパスワードを空欄のままログインボタンを押すとクラッシュしていた。
原因はpassword.countを直接参照しており、nilの場合に強制アンラップで落ちていた。
App Store Connectのクラッシュレポートで週100件以上報告されていた。
what:
- LoginViewModelにpasswordのnilチェックを追加
- 空欄の場合はバリデーションエラーを表示するように変更
- 関連する単体テストを追加
refactor: APIクライアントをasync/awaitに移行
why:
既存のAPIクライアントはコールバックベースで実装されており、
ネストが深くなりがちでコードの可読性が低下していた。
Swift Concurrencyに統一することで、エラーハンドリングも簡潔になり、
今後の機能追加時の開発効率が向上する。
what:
- APIClientのすべてのメソッドをasync throwsに変更
- completionハンドラを削除
- 呼び出し元のViewModelをTaskでラップするよう修正
- レガシーなDispatchQueue.main.asyncを@MainActorに置換
chore: Info.plistにATT設定を追加
why:
AdMob広告を導入するにあたり、iOS 14.5以降で必須となる
App Tracking Transparency（ATT）の許可ダイアログを表示する必要がある。
これがないとApp Store審査でリジェクトされる。
what:
- NSUserTrackingUsageDescriptionを追加（日本語の説明文）
- SKAdNetworkItemsにGoogleの広告ネットワークIDを追加
docs: READMEにセットアップ手順を追加
why:
新しいチームメンバーがプロジェクトに参加した際、
環境構築に時間がかかっていた。
手順が口頭伝達に頼っていたため、ドキュメント化する。
what:
- 必要な開発環境（Xcode、CocoaPods等）の記載
- APIキーの取得・設定方法を追加
- よくあるエラーとその解決方法を追加
以下のような変更がある場合の実行フロー:
Changes not staged for commit:
modified: UserProfileView.swift # 編集機能追加
modified: UserProfileViewModel.swift # 編集機能追加
deleted: LegacyUserManager.swift # レガシーコード削除
modified: README.md # セットアップ手順追加
| グループ | ファイル | 目的 |
|---|---|---|
| 1 | UserProfileView.swift, UserProfileViewModel.swift | 編集機能追加 |
| 2 | LegacyUserManager.swift | レガシーコード削除 |
| 3 | README.md | ドキュメント更新 |
# グループ1: 新機能
git add UserProfileView.swift UserProfileViewModel.swift
git commit -m "feat: UserProfileViewに編集機能を追加..."
# グループ2: リファクタリング
git add LegacyUserManager.swift
git commit -m "refactor: LegacyUserManagerを削除..."
# グループ3: ドキュメント
git add README.md
git commit -m "docs: READMEにセットアップ手順を追加..."
コミット完了後、以下の形式で報告:
3件のコミットを作成しました:
1. feat: UserProfileViewに編集機能を追加
- UserProfileView.swift
- UserProfileViewModel.swift
2. refactor: LegacyUserManagerを削除
- LegacyUserManager.swift
3. docs: READMEにセットアップ手順を追加
- README.md
6ヶ月後に同じコードを見たとき、「なぜこう実装したのか」は覚えていない。 whatはgit diffで確認できるが、whyはコミットメッセージにしか残らない。 将来の自分や他のメンバーのために、必ずwhyを記録する。
GitHub Pull Request を作成するときに使う。ユーザーが PR を作りたい、PR本文やタイトルのドラフトを差分から作りたい、既存の PR テンプレートに沿って内容を埋めたいと言ったときに適用する。実行時に新規ブランチや add/commit が必要な場合もこのスキル内で行う。カレントが main または release/* または epic/* のときは、新規ブランチを作る必要があるか必ずユーザーに聞く。それ以外は普段は質問せず、必要ならブランチ作成・コミット・プッシュしてから PR を作成する。ベースブランチは origin のリモートブランチから候補を推定してユーザー確認を取る。
現在の変更内容を確認し、適切なブランチ名を提案してブランチを作成するときに使う。ユーザーが「ブランチ作って」「作業用ブランチ切りたい」「変更に合わせてブランチ名を決めて」と言ったとき、または新規作業を始める前にブランチを作りたいときに適用する。git status / diff を確認し、プレフィックス規則（feat/fix/release/epic）に従ってブランチ名を提案し、ユーザー確認後に git checkout -b で作成する。
Create and iteratively improve Cursor Agent Skills using the Anthropic skill-creator workflow. Use when the user wants to create a skill from scratch, refine an existing skill with test prompts and feedback, or follow a structured draft→test→review→improve loop for skills.
Use CodeRabbit CLI to receive external code review feedback and address identified issues. Invoke this skill when the user requests CodeRabbit review, or proactively after implementing significant code changes to get feedback and improve code quality.