tupacalypse187/tupacalypse187-claude-skills

Gitワークフロー自動化

機能開発ライフサイクルにおける、ブランチ作成からマージまでの完全なGitワークフロー自動化。

---

概要

このスキルは、機能開発ワークフロー全体を自動化します：

1. 機能ブランチを作成（デフォルトブランチから）
2. 変更をコミット（絵文字Conventional Commitsを使用）
3. リモートにプッシュ
4. PRを作成（構造化マークダウンテンプレート使用）
5. レビューを待機 — コードレビューコメントを取得
6. 評価と修正 — 各コメントを分類し修正
7. 修正をプッシュし返信 — 変更をプッシュし、すべてのコメントに応答
8. ループ — 修正に対する新しいフィードバックを再チェック
9. ステータスを監視（UNSTABLE -> CLEAN）
10. PRをマージ（スカッシュ＋ブランチ削除）
11. クリーンアップ（ローカルおよびリモートブランチ）

⚠️ 必須： 完全なワークフローを実行する場合、11ステップすべてを順番に実行する必要があります。PR作成（ステップ4）で停止しないでください。ステップ5～11（レビュー、修正、マージ、クリーンアップ）はフローの必須部分であり、オプションのフォローアップではありません。各ステップから次のステップへ中断せずに続行してください。

---

スキルのトリガー

自然言語を使用してワークフローの任意の部分を呼び出します：

完全ワークフロー

• 「機能XのGitワークフローを完了して」
• 「機能ブランチを作成し、コミット、PR作成、マージまでやって」
• 「完全なPRサイクルを実行して」

個別ステップ

• 「Xの機能ブランチを作成して」
• 「変更を絵文字Conventional Commitsでコミットして」
• 「構造化テンプレートでPRを作成して」
• 「PRのステータスを監視して」
• 「PRをマージしてクリーンアップして」

レビュー対応

• 「PRのコメントを確認して対応して」
• 「PR #123のレビューコメントを修正して」
• 「現在のPRのフィードバックに対応して」

---

ステップ1：機能ブランチを作成

# デフォルトブランチを検出（main、masterなど）
DEFAULT_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | sed 's/.*: //' || echo "main")
git checkout "$DEFAULT_BRANCH"
git pull origin "$DEFAULT_BRANCH"
git checkout -b feat/descriptive-name

ブランチ命名規則：

• feat/ - 新機能
• fix/ - バグ修正
• docs/ - ドキュメント変更
• refactor/ - コードリファクタリング
• perf/ - パフォーマンス改善
• test/ - テスト追加・変更
• chore/ - メンテナンスタスク
• ci/ - CI/CD変更

---

ステップ2：絵文字Conventional Commitsでコミット

ステージングとコミット

git add <ファイル>
git commit -m "<絵文字> <タイプ>[オプションスコープ]: <説明>"

コミットタイプと絵文字

タイプ	絵文字	説明	例
feat	✨	新機能	✨ feat(auth): add JWT token validation
fix	🐛	バグ修正	🐛 fix(api): resolve memory leak in handler
docs	📝	ドキュメント	📝 docs: update API endpoints documentation
style	🎨	コードスタイル	🎨 style: format code with prettier
refactor	♻️	コードリファクタリング	♻️ refactor: simplify authentication logic
perf	⚡️	パフォーマンス	⚡️ perf: optimize database query performance
test	✅	テスト	✅ test: add unit tests for user service
chore	🔧	メンテナンス	🔧 chore: update build dependencies
ci	👷	CI/CD	👷 ci: add github actions workflow
build	📦	ビルドシステム	📦 build: upgrade to webpack 5
revert	⏪	元に戻す	⏪ revert: rollback payment integration

コミットメッセージ形式

シンプル（デフォルト）：

✨ feat(auth): add JWT token validation

フル（本文あり）：

✨ feat(auth): add JWT token validation

JWTトークンバリデーションミドルウェアを実装：
- トークンの署名と有効期限を検証
- ペイロードからユーザークレームを抽出
- リクエストオブジェクトにユーザーコンテキストを追加

これにより、保護されたすべてのルートで認証トークンが適切に検証されるようになり、セキュリティが向上します。

Co-authored-by: Claude <[email protected]>

ベストプラクティス

• ✅ 現在形、命令形を使用（「added」ではなく「add」）
• ✅ 1行目は50文字以内（最大72文字）
• ✅ 先頭は大文字
• ✅ 件名行の末尾にピリオドなし
• ✅ コンテキストを示すスコープを使用（例：feat(auth):）
• ✅ AI支援コミットには Co-authored-by: フッターを含める

---

ステップ3：リモートにプッシュ

git push -u origin feat/descriptive-name

---

ステップ4：構造化テンプレートでPRを作成

PRを作成する前に、実際の変更内容を分析：

# デフォルトブランチとの差分をすべて表示
git diff "$DEFAULT_BRANCH"...HEAD

# コミットメッセージを表示
git log "$DEFAULT_BRANCH"..HEAD --pretty=format:"%s"

PRのタイトルと本文は、実際の差分から生成する必要があります。プレースホルダーテキストは決して使用しないでください。

• タイトル： 主要コミットの絵文字とタイプを使用（例：✨ feat:、🐛 fix:）。絵文字を含めます。
• 本文： すべてのセクションを差分から導出された実際の内容で埋めてください。[One-line summary] や [First change] とは書かず、実際の変更の説明を記述します。

gh pr create \
  --title "<絵文字> <タイプ>: <簡単な説明>" \
  --body "$(cat <<EOF
## 📝 概要

[実際の差分に基づいた、1文の要約を記述]

## 🔄 変更内容

[意味のある各変更を、絵文字プレフィックス付きの箇条書きでリストアップ。git diffの出力に基づく]

## ✅ 検証方法

[実際に変更された内容に基づいた、具体的で実行可能な検証手順を提供]

## 🔗 関連情報

[関連リンクを含める：Issue参照（Closes #N）、ドキュメント、関連PRなど。存在しない場合はセクションを省略]

---

🤖 [Claude Code](https://claude.com/claude-code) で生成
EOF
)"

PRテンプレート例

機能PR：

## 📝 概要

GoogleとGitHubプロバイダーをサポートするOAuth2認証フローを追加。

## 🔄 変更内容

- ✨ PKCEを使用したOAuth2認可コードフローを追加
- 🔐 暗号化クッキーによる安全なトークンストレージを実装
- 📝 初回ログイン時のユーザープロファイル同期を追加
- 🎨 プロバイダーボタン付きのログインUIを更新

## ✅ 検証方法

1. ローカルで実行：`npm run dev`
2. `/login` にアクセスし「Sign in with Google」をクリック
3. OAuthフローを完了
4. ユーザープロファイルが正しく作成されることを確認
5. ページリロード時にトークン更新が機能することを確認

```bash
# テストスイート
npm run test:auth

🔗 関連情報

• Closes #456
• OAuth 2.1 RFC：https://datatracker.ietf.org/doc/html/rfc6749
• デザインドキュメント：docs/design/oauth2-integration.md

**バグ修正PR：**
```markdown
## 📝 概要

長期間のメモリ使用量増加を引き起こすイベントハンドラーのメモリリークを修正。

## 🔄 変更内容

- 🐛 イベントリスナーが適切に削除されていなかった問題を修正
- ✅ componentWillUnmountでのクリーンアップを追加
- 📝 イベントハンドラーのライフサイクルに関するドキュメントを追加

## ✅ 検証方法

1. ブラウザのDevTools → メモリを開く
2. ヒープスナップショットを取得
3. アプリを10回ナビゲート
4. 別のスナップショットを取得
5. デタッチされたDOMノードがないことを確認

## 🔗 関連情報

- Fixes #789
- 関連Issue：#123

---

ステップ5：コードレビューを待機

コメントを確認する前に、コードレビューが完了するのを待ちます：

echo "⏳ コードレビューを待っています..."
sleep 180

レビューコメントを取得

# リポジトリスラッグを解決
REPO_SLUG=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')

# PRを一覧表示
gh pr list

# PR詳細を表示
gh pr view <PR_NUMBER>

# インラインコードレビューコメントを取得（返信をフィルタリングしてオリジナルのみ）
gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments --jq '.[] | select(.in_reply_to_id == null) | {id: .id, path: .path, line: .line, body: .body}'

# Issueレベルのコメントを取得（一般的なPRコメント）
gh api repos/$REPO_SLUG/issues/$PR_NUMBER/comments --jq '.[] | {id: .id, body: .body}'

# レビューステータスを取得
gh pr view $PR_NUMBER --json reviews --jq '.reviews[] | {state: .state, body: .body, author: .author.login}'

---

ステップ6：レビューコメントを評価して修正

各コメントを分類

カテゴリ	アクション	例
Must fix	コード変更が必要	バグ、セキュリティ問題、ロジックエラー、テスト失敗
Should fix	コード変更を推奨	コードスタイル、命名、エラーハンドリング不足
Suggestion	オプション、判断に委ねる	代替アプローチ、より良いパターン
Question	返信のみ、コード変更不要	レビュアーが説明を求めている
Already addressed	返信のみ	コメントは既に修正済みのコードを参照している

各コメントの処理手順

1. 指定されたファイルの指定行番号を読む
2. フィードバックに対応する最小限の修正を行う
3. 適切な絵文字コミットでステージングしてコミット
4. コメントIDを記録（後で返信するため）

# 修正を行う
# ... コード変更 ...

# 修正をコミット
git add <変更ファイル>
git commit -m "🐛 fix: review feedbackに対応 - エッジケースを処理"

---

ステップ7：修正をプッシュし、すべてのコメントに返信

すべての修正がコミットされたら：

# すべての修正コミットをプッシュ
git push

返信する前に、修正ハッシュを計算：

FIX_HASH=$(git rev-parse --short HEAD)

次に、各コメントに対して、シェル変数 $FIX_HASH と、ステップ5で取得した数値の id を使用して返信：

# インラインレビューコメントに返信
gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments \
  --method POST \
  --field body="✅ $FIX_HASH で修正。 <実際に変更した内容を記述>" \
  --field in_reply_to=$COMMENT_ID

# 一般的なPRコメントに返信（注：GitHub APIはスレッド化された返信ではなく、新しいトップレベルコメントを作成します。これはAPIの制限です）
gh api repos/$REPO_SLUG/issues/$PR_NUMBER/comments \
  --method POST \
  --field body="✅ $FIX_HASH で対応。 <実際に変更した内容を記述>"

返信形式：

• 修正：✅ <short_hash> で修正 — <変更内容>
• 質問：💡 <回答>
• 適用しなかった提案：🙏 良い提案ですが、<理由>。必要であれば再度検討します。

---

ステップ8：ループ — 新しいフィードバックを再チェック

修正をプッシュした後：

# コメントを再取得し、既に処理済みのIDと比較
gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments --jq '.[] | select(.in_reply_to_id == null) | .id'

• 新しいコメントIDが見つかった場合 → ステップ6から繰り返し
• 新しいコメントがない場合 → ステップ9に進む

よくあるレビュー応答

コメントタイプ	応答方法
コードスタイル	修正 + 🎨 style: コミット
バグ報告	修正 + 🐛 fix: コミット
テスト不足	テスト追加 + ✅ test: コミット
ドキュメント	ドキュメント更新 + 📝 docs: コミット
パフォーマンス	最適化 + ⚡️ perf: コミット
リファクタリング	リファクタリング + ♻️ refactor: コミット

---

ステップ9：PRステータスを監視（UNSTABLE -> CLEAN）

この監視ループを使用して、すべてのCIチェックが通過するのを待ちます：

#!/bin/bash
PR_NUMBER="<PR_NUMBER>"

for i in {1..60}; do
  pr_status=$(gh pr view $PR_NUMBER --json mergeStateStatus --jq '.mergeStateStatus')

  if [ "$pr_status" = "CLEAN" ]; then
    echo "✅ すべてのチェックが通過しました！マージ準備完了。"
    exit 0
  fi

  echo "⏳ 待機中... ($i/60) - ステータス: $pr_status"
  sleep 10
done

echo "❌ タイムアウト - 10分以内にチェックが通過しませんでした"
exit 1

可能なステータス：

• UNKNOWN - ステータスが未決定
• BEHIND - ブランチがベースブランチより遅れている
• BLOCKED - 失敗したチェックによりブロックされている
• DIRTY - マージコンフリクト
• DRAFT - PRがドラフト状態
• UNSTABLE - チェックがまだ通過していない
• CLEAN - すべてのチェックが通過、マージ準備完了

---

ステップ10：PRをマージ（スカッシュ＋ブランチ削除）

gh pr merge <PR_NUMBER> --squash --delete-branch

注： --subject を省略すると、GitHubはPRタイトルをデフォルトとして使用します。これには正しい絵文字/タイプのプレフィックスが既に含まれています。

マージオプション：

• --squash - すべてのコミットを1つにまとめる（推奨）
• --merge - 完全なコミット履歴でマージ
• --rebase - コミットをベースブランチにリベース
• --delete-branch - マージ後にブランチを削除

---

ステップ11：ローカルおよびリモートブランチをクリーンアップ

# デフォルトブランチに戻る
git checkout "$DEFAULT_BRANCH"

# 最新の変更をプル
git pull origin "$DEFAULT_BRANCH"

# ローカルブランチを削除
git branch -d feat/descriptive-name

# 必要に応じて強制削除
git branch -D feat/descriptive-name

# リモートブランチを削除（まだ削除されていない場合）
git push origin --delete feat/descriptive-name

---

完全なワークフロースクリプト

以下は、完全なワークフロー（監視、修正、マージ、クリーンアップ）を組み合わせた完全なスクリプトです：

#!/bin/bash
set -e

PR_NUMBER="<PR_NUMBER>"
REPO_SLUG=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')

# ステップ5：レビューを待機
echo "⏳ コードレビューを120秒間待っています..."
sleep 180

# ステップ6-8：修正ループ（最大5回反復）
PROCESSED_IDS=""
MAX_ITERATIONS=5
iteration=0
while [ $iteration -lt $MAX_ITERATIONS ]; do
  iteration=$((iteration + 1))
  COMMENT_IDS=$(gh api repos/$REPO_SLUG/pulls/$PR_NUMBER/comments --jq '.[] | select(.in_reply_to_id == null) | .id')
  NEW_IDS=$(comm -23 <(echo "$COMMENT_IDS" | sort) <(echo "$PROCESSED_IDS" | sort) || true)

  if [ -z "$NEW_IDS" ]; then
    echo "✅ 新しいレビューコメントはありません。"
    break
  fi

  echo "📝 新しいレビューコメントが見つかりました。対応中..."
  # （Claude Codeが各コメントを評価し修正します）

  git push
  PROCESSED_IDS="${PROCESSED_IDS}
${NEW_IDS}"

  echo "⏳ CIと再レビューを待っています..."
  sleep 60
done

if [ $iteration -ge $MAX_ITERATIONS ]; then
  echo "⚠️ 最大修正反復回数に達しました。手動レビューが必要になる場合があります。"
fi

# ステップ9：PRステータスを監視
echo "🔍 PR #$PR_NUMBER のステータスを監視中..."
HEAD_BRANCH=$(gh pr view $PR_NUMBER --json headRefName --jq '.headRefName')
for i in {1..60}; do
  pr_status=$(gh pr view $PR_NUMBER --json mergeStateStatus --jq '.mergeStateStatus')

  if [ "$pr_status" = "CLEAN" ]; then
    echo "✅ すべてのチェックが通過しました！"
    break
  fi

  echo "⏳ 待機中... ($i/60) - ステータス: $pr_status"
  sleep 10
done

# ステップ10：PRをマージ
echo "🔀 PR #$PR_NUMBER をマージ中..."
gh pr merge $PR_NUMBER --squash --delete-branch

# ステップ11：クリーンアップ
echo "🧹 クリーンアップ中..."
git checkout "$DEFAULT_BRANCH"
git pull origin "$DEFAULT_BRANCH"
git branch -D "$HEAD_BRANCH" 2>/dev/null || true
echo "✅ 完了！次の機能の準備ができました。"

---

クイックリファレンスコマンド

ブランチ操作

git checkout -b feat/feature-name    # 機能ブランチを作成
git checkout "$DEFAULT_BRANCH" && git pull  # デフォルトブランチと同期
git b