GitHub Pull Request を作成するときに使う。ユーザーが PR を作りたい、PR本文やタイトルのドラフトを差分から作りたい、既存の PR テンプレートに沿って内容を埋めたいと言ったときに適用する。実行時に新規ブランチや add/commit が必要な場合もこのスキル内で行う。カレントが main または release/* または epic/* のときは、新規ブランチを作る必要があるか必ずユーザーに聞く。それ以外は普段は質問せず、必要ならブランチ作成・コミット・プッシュしてから PR を作成する。ベースブランチは origin のリモートブランチから候補を推定してユーザー確認を取る。

2026-03-194

create-branch

showcase-gig-platform/scg-ai-playbook

現在の変更内容を確認し、適切なブランチ名を提案してブランチを作成するときに使う。ユーザーが「ブランチ作って」「作業用ブランチ切りたい」「変更に合わせてブランチ名を決めて」と言ったとき、または新規作業を始める前にブランチを作りたいときに適用する。git status / diff を確認し、プレフィックス規則（feat/fix/release/epic）に従ってブランチ名を提案し、ユーザー確認後に git checkout -b で作成する。

2026-03-184

anthropic-skill-creator

showcase-gig-platform/scg-ai-playbook

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.

2026-03-164

coderabbit-review

showcase-gig-platform/scg-ai-playbook

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.

2026-03-164

name	create-commit
description	Gitの変更をステージしてコミットする。「コミットして」「コミットしたい」「変更をコミット」といったリクエストで使用。差分を分析し、whatとwhyを含む適切なコミットメッセージを自動生成する。

Git Commit Skill

現在のブランチで変更をステージし、適切なコミットメッセージでコミットする。

コミットメッセージの原則

良いコミットメッセージには**what（何を変更したか）とwhy（なぜ変更したか）**の両方が含まれる。

what: コードを見ればわかることもあるが、概要として明記することで理解を助ける
why: コードを見ただけでは絶対にわからない。変更の意図、背景、理由を説明することが最も重要

ワークフロー

git status で現在の状態を確認
git diff と git diff --cached で変更内容を把握
変更を意味的なグループに分類（複数の目的が混在している場合）
グループごとに: a. 対象ファイルをステージ（git add <ファイル>） b. コミットメッセージを生成 c. コミットを実行
単一の目的の変更のみの場合は従来通り一括コミット

変更のグループ分類

なぜ分割するか

1つのコミットには1つの目的（why）のみを含めるべき。複数の目的が混在すると:

コミット履歴が追いにくくなる
特定の変更だけを revert したい場合に困る
コードレビューで変更の意図が伝わりにくい

分類の基準

以下の観点で変更を分類する:

観点	説明
why（理由）	同じ理由・目的の変更は同じコミットへ
機能的な関連性	同じ機能に対する変更は同じコミットへ
変更の種類	新機能、バグ修正、リファクタリング、ドキュメント更新など

分類の例

1つの作業セッションで以下の変更があった場合:

UserProfileView.swift に編集機能を追加
LegacyUserManager.swift を削除（不要になったレガシーコード）
README.md にセットアップ手順を追加

→ 3つの別コミットに分ける:

feat: UserProfileViewに編集機能を追加
refactor: LegacyUserManagerを削除
docs: READMEにセットアップ手順を追加

判断のガイドライン

1つの変更が複数の目的を持つ場合: 主要な目的でまとめる
依存関係がある場合: 例えばリファクタリング→機能追加の順序で依存がある場合、その順序でコミット
迷った場合: 「この変更だけを revert したくなることがあるか？」と考える。あるなら分ける
Claudeが自動判断: ユーザー確認なしで適切に分割し、結果を報告する

コミットメッセージフォーマット

prefix: 概要説明（what）

why:
なぜこの変更が必要だったかの説明

what:
- 具体的な変更点1
- 具体的な変更点2
- ...

各セクションの説明

1行目: 概要（what の要約）

prefix: 英語で記述（Conventional Commits形式）
概要説明: 日本語で簡潔に記述
- ファイル名、クラス名、関数名、システム用語は英語のまま維持
- 例: Info.plistにATTの設定を追加

why セクション

変更の理由・背景・意図を説明する。以下のような観点で記述:

問題: どんな問題があったか（バグ修正の場合）
目的: 何を達成したかったか（新機能の場合）
背景: なぜ今この変更が必要か
制約: 技術的な制約や考慮事項

what セクション

具体的に何を変更したかをリスト形式で記述:

追加・削除・変更したファイルや機能
実装の詳細（必要に応じて）

Prefix一覧

Prefix	用途
`feat`	新機能の追加
`fix`	バグ修正
`docs`	ドキュメントのみの変更
`style`	コードの動作に影響しない変更（空白、フォーマット等）
`refactor`	バグ修正でも機能追加でもないコード変更
`perf`	パフォーマンス改善
`test`	テストの追加・修正
`chore`	ビルドプロセスや補助ツールの変更
`build`	ビルドシステムや外部依存関係の変更
`ci`	CI設定ファイルやスクリプトの変更
`revert`	以前のコミットを取り消し

例

例1: 新機能追加

feat: UserProfileViewに編集機能を追加

why:
ユーザーからプロフィールを変更したいという要望が多く寄せられていた。
現状では設定画面からしか変更できず、導線がわかりにくかった。
プロフィール画面から直接編集できるようにすることでUXを改善する。

what:
- EditProfileSheetを新規作成
- プロフィール画像の変更機能を実装（PhotosPickerを使用）
- ユーザー名のバリデーションを追加（3-20文字、英数字のみ）
- 保存時のローディング表示とエラーハンドリングを追加

例2: バグ修正

fix: ログイン画面でクラッシュする問題を修正

why:
ユーザーがパスワードを空欄のままログインボタンを押すとクラッシュしていた。
原因はpassword.countを直接参照しており、nilの場合に強制アンラップで落ちていた。
App Store Connectのクラッシュレポートで週100件以上報告されていた。

what:
- LoginViewModelにpasswordのnilチェックを追加
- 空欄の場合はバリデーションエラーを表示するように変更
- 関連する単体テストを追加

例3: リファクタリング

refactor: APIクライアントをasync/awaitに移行

why:
既存のAPIクライアントはコールバックベースで実装されており、
ネストが深くなりがちでコードの可読性が低下していた。
Swift Concurrencyに統一することで、エラーハンドリングも簡潔になり、
今後の機能追加時の開発効率が向上する。

what:
- APIClientのすべてのメソッドをasync throwsに変更
- completionハンドラを削除
- 呼び出し元のViewModelをTaskでラップするよう修正
- レガシーなDispatchQueue.main.asyncを@MainActorに置換

例4: 設定変更

chore: Info.plistにATT設定を追加

why:
AdMob広告を導入するにあたり、iOS 14.5以降で必須となる
App Tracking Transparency（ATT）の許可ダイアログを表示する必要がある。
これがないとApp Store審査でリジェクトされる。

what:
- NSUserTrackingUsageDescriptionを追加（日本語の説明文）
- SKAdNetworkItemsにGoogleの広告ネットワークIDを追加

例5: ドキュメント更新

docs: READMEにセットアップ手順を追加

why:
新しいチームメンバーがプロジェクトに参加した際、
環境構築に時間がかかっていた。
手順が口頭伝達に頼っていたため、ドキュメント化する。

what:
- 必要な開発環境（Xcode、CocoaPods等）の記載
- APIキーの取得・設定方法を追加
- よくあるエラーとその解決方法を追加

複数コミットの実行例

以下のような変更がある場合の実行フロー:

Changes not staged for commit:
  modified:   UserProfileView.swift    # 編集機能追加
  modified:   UserProfileViewModel.swift # 編集機能追加
  deleted:    LegacyUserManager.swift  # レガシーコード削除
  modified:   README.md                # セットアップ手順追加

Step 1: グループ分類

グループ	ファイル	目的
1	UserProfileView.swift, UserProfileViewModel.swift	編集機能追加
2	LegacyUserManager.swift	レガシーコード削除
3	README.md	ドキュメント更新

Step 2: 順次コミット

# グループ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

補足

なぜwhyが重要か

6ヶ月後に同じコードを見たとき、「なぜこう実装したのか」は覚えていない。 whatはgit diffで確認できるが、whyはコミットメッセージにしか残らない。将来の自分や他のメンバーのために、必ずwhyを記録する。

whyが思い浮かばない場合

そもそも本当に必要な変更か再考する
変更のきっかけ（Issue、PRコメント、ユーザー報告）を思い出す
「この変更がなかったらどうなるか」を考える