GitHub に文字を書かなくなった話 - Claude Codeカスタムコマンド活用術

---
description: Issueに対応する修正を実施
argument-hint: "Issue番号 または IssueのURL"
---

# Issue対応修正

Issue番号またはURL: $ARGUMENTS

## 手順

1. **Issue内容の確認**
   - `gh issue view` でIssueの内容を取得
   - 要件、受け入れ条件、関連情報を把握

2. **ブランチ作成**
   - `git fetch origin main && git checkout main && git pull origin main` で開発ブランチを最新化
   - mainブランチをベースに新しいブランチを作成
   - ブランチ名: `feature/issue-{番号}-{簡潔な説明}`
   - 例: `feature/issue-123-add-user-validation`

3. **実装**
   - Issueの要件に基づいて修正を実施
   - 既存コードのパターンを参照して統一する

4. **コード整形**
   - formatter / lint を実行

5. **テスト**
   - テストを実行。必要に応じてテストを追加

## 注意事項

- **コミットは行わない**（ユーザーが確認後に `/02-create-pr` で実施）
- 実装完了後、変更内容のサマリーを報告する
- 不明点があれば実装前にユーザーに確認する

---
description: コミット→プッシュ→PR作成
argument-hint: "[ラベル名] (省略可、カンマ区切りで複数指定可)"
---

# PR作成

ラベル（任意）: $ARGUMENTS

## 手順

1. **変更状況の確認**
   - `git status` で未コミットの変更を確認
   - `git diff` で変更内容を確認

2. **コミット**（未コミットの変更がある場合）
   - 変更内容に基づいて適切なコミットメッセージを作成
   - コミットメッセージの形式: `{type}: {description} (#{issue番号})`
     - type: feat, fix, refactor, test, docs, chore など
   - 例: `feat: ユーザーバリデーション機能を追加 (#123)`

3. **プッシュ**
   - `git push -u origin {ブランチ名}` でリモートにプッシュ

4. **PR作成**
   - `gh pr create --draft` でドラフトPRを作成
   - ベースブランチ: main
   - **【重要】`.github/PULL_REQUEST_TEMPLATE.md` が存在する場合は必ず準拠すること**
     - テンプレートを読み取り、すべてのセクションを含める
     - テンプレートがない場合のデフォルト構成:
       - 概要: 変更内容の説明、`close #{issue番号}` を含める
       - 動作確認: 実施した確認項目
       - 確認事項: テンプレートのチェックリストを維持
       - マージ条件: 特になければ「承認後、即時でOK」
       - レビューについての検討: 「1 人以上レビュー希望」など

5. **ラベル設定**
   - 引数でラベルが指定されている場合: 指定されたラベルを付与
   - 関連Issueがある場合: Issueのラベルを引き継ぐ
   - 変更内容に応じて適切なラベルを提案:
     - `enhancement`: 機能追加
     - `bug`: バグ修正
     - `refactoring`: リファクタリング

## 出力

- 作成したPRのURLを報告

---
description: レビュー指摘対応（修正のみ、コミットなし）
argument-hint: "PR番号 または PRのURL"
---

# レビュー指摘対応

PR番号またはURL: $ARGUMENTS

## 手順

1. **レビューコメントの取得**
   - `gh pr view {番号} --comments` でPRのコメントを取得
   - `gh api repos/{owner}/{repo}/pulls/{番号}/comments` でインラインコメントを取得
   - 未解決のレビュー指摘を一覧化

2. **指摘内容の分析**
   - 各コメントの内容を理解
   - 対応が必要な項目をリストアップ
   - 不明点があればユーザーに確認

3. **修正実施**
   - 各指摘に対して修正を実施
   - 修正内容を記録

4. **コード整形**
   - formatter / lint を実行

5. **テスト**
   - インテグレーションテストを実行
   - 修正によって既存テストが壊れていないか確認

## 出力

- 対応した指摘の一覧
- 修正内容のサマリー
- 「修正が完了しました。内容を確認後、`/04-commit-review-fix {PR番号}` でコミット・プッシュを行ってください」と案内

---
description: レビュー指摘対応のコミット＆プッシュ
argument-hint: "PR番号 または PRのURL"
---

# レビュー指摘対応のコミット＆プッシュ

PR番号またはURL: $ARGUMENTS

## 前提条件

- `/03-address-review` でレビュー指摘の修正が完了していること
- 修正内容をユーザーが確認済みであること

## 手順

1. **変更状況の確認**
   - `git status` で未コミットの変更を確認
   - `git diff` で変更内容を確認

2. **コミット＆プッシュ**
   - 修正内容をコミット
   - コミットメッセージ: `fix: レビュー指摘対応 (#{PR番号})`
     - PR番号は数字のみであることを確認
     - HEREDOCを使用してコミットメッセージを安全に渡す
   - `git push` でプッシュ
   - コミットハッシュを取得: `git rev-parse --short HEAD`

3. **【必須】レビューコメントへの返信**

   **この手順は絶対にスキップしないこと。コメントがなくても必ず確認すること。**

   レビューコメントには2種類あるため、両方を確認する：

   ### 3-1. インラインレビューコメントの確認
   ```bash
   gh api repos/{owner}/{repo}/pulls/{pr番号}/comments --jq '[.[] | select(.in_reply_to_id == null) | {id, path, body}]'
   ```
   - インラインコメントがある場合、各コメントに返信:
     ```bash
     gh api repos/{owner}/{repo}/pulls/{pr番号}/comments/{comment_id}/replies -f body="{返信内容}"
     ```

   ### 3-2. PRコメント（github-actionsボットのレビュー等）の確認
   ```bash
   gh api repos/{owner}/{repo}/issues/{pr番号}/comments --jq '[.[] | {id, user: .user.login, body: .body[:500]}]'
   ```
   - レビュー指摘を含むコメント（github-actionsボットの「レビュー結果」等）がある場合、新しいコメントとして返信を追加:
     ```bash
     gh api repos/{owner}/{repo}/issues/{pr番号}/comments -f body="{返信内容}"
     ```

   ### 返信フォーマット
   ```
   Fixed in {commit_hash}:

   ### 指摘1: {指摘タイトル}
   - {対応内容}

   ### 指摘2: {指摘タイトル}
   - {対応内容}
   ```

   ### 返信内容の作成ルール
   - `/03-address-review` で分析した指摘事項を元に返信を作成
   - 修正した指摘：具体的な修正内容を記載
   - 対応不要とした指摘：理由を記載（例：「Issue対象外のため」「既存の設計方針に従い」等）

4. **PR概要の更新確認**
   - ユーザーに「PR概要も更新しますか？」と確認
   - 「はい」の場合:
     - 修正内容を反映してPR本文を更新
     - HEREDOCを使用してPR本文を安全に渡す
   - 「いいえ」の場合: スキップ

## 注意事項

- **レビュー指摘の妥当性を検討すること**: レビュー指摘をそのまま鵜呑みにせず、指摘内容が技術的に正しいか、プロジェクトの方針に合っているかを確認してから修正する
- **【重要】手順3は絶対にスキップしない**: レビュー指摘への返信は、レビュアーへのフィードバックとして必須

## 出力

- コミット内容のサマリー
- PRのURL
- 返信したコメント数（0件の場合も明記）

---
description: PRのレビューコメントからコーディングガイドを更新
argument-hint: "[#PR番号 [#PR番号2 ...] または フリーテキスト検索条件] (省略時: 前回分析日以降にマージされたPRを分析)"
---

以下の指定に基づいてPRのレビューコメントを分析し、コーディングガイドを更新してください: $ARGUMENTS

## 引数の解釈

引数が **指定なし**（デフォルト）の場合:
- `CODING_GUIDES.md`の先頭から「最終分析日」を読み取る
- その日付以降にマージされたPRを分析対象とする
- 例: 最終分析日が2025-11-13の場合、2025-11-14以降にマージされたPRを分析

引数が **PR番号形式**（`#123` や `123` 形式）の場合:
- 指定されたPR番号を直接処理

引数が **フリーテキスト**の場合:
- 自然言語での検索条件として解釈し、`gh pr list` コマンドで該当するPRを検索
- 検索条件の例:
  - 「ここ半年の私がassigneeになっているPR」
  - 「最近マージされた自分のPR」
  - 「先月レビューされたPR」
  - 「未マージで修正要求があるPR」
- 必要に応じて以下のオプションを組み合わせて使用:
  - `--assignee @me` / `--author @me` / `--reviewer @me`
  - `--state open|closed|merged|all`
  - `--limit N` (デフォルト: 20-30件程度が妥当)
  - `--search "keyword"`
  - 日付範囲は取得後にフィルタリング
- 検索結果が多い場合は、ユーザーに件数を伝えて確認を取る

## 実行手順

1. **PR番号の特定**
   - 引数なしの場合:
     - `CODING_GUIDES.md`の先頭にある「最終分析日: YYYY-MM-DD」を読み取る
       - **最終分析日が存在しない場合**: ユーザーに初回実行であることを通知し、適切な開始日（例: 直近1ヶ月）を提案
     - `gh pr list --state merged --limit 50 --json number,title,mergedAt,author`で最新のマージ済みPRを取得
       - limit 50: 通常1-2週間分のPRをカバーする想定。定期的に実行することで漏れを防ぐ
     - `mergedAt`が最終分析日より後（翌日以降）のPRのみを対象とする
       - **マージ済みPRが0件の場合**: その旨を通知して処理を終了
     - 対象PRリストをユーザーに提示して確認を取る
   - 引数がPR番号の場合: そのまま使用
   - 引数がフリーテキストの場合:
     - `gh pr list` コマンドで検索
     - 見つかったPRのリストをユーザーに提示
     - 処理対象を確認（件数が多い場合は特に重要）

2. **レビューコメントの取得**
   - 各PR番号について `gh pr view` コマンドでレビューとコメントを取得
   - 修正要求（CHANGES_REQUESTED）や具体的な指摘があるコメントを抽出
   - **バグラベルがついているPRの場合**:
     - `gh pr view --json labels` でラベルを確認
     - `bug`ラベルがついている場合は、PRの内容（修正内容、原因）を詳細に分析
     - 同じバグが再発しないための予防策をガイドラインに追加する

3. **要約の作成**
   - レビューコメントの内容を読んで要約
   - 技術的な指摘やベストプラクティスに関する内容を重点的に抽出

4. **コーディングガイドへの追記判断**
   - **修正要求や具体的な指摘がある場合**:
     - 要約結果をユーザーに提示
     - ユーザーの確認を得てから、プロジェクトの `CODING_GUIDES.md` の適切なセクションに追記
     - 追記方法:
       - 指摘内容を分類して、該当するセクション（例: レイヤー設計、例外処理等）に追記
       - 新しいルールとして簡潔に記載（DO/DO NOTフォーマット推奨）
       - **必ずPR番号を `(#123)` の形式で記載する**
       - 既存のルールと重複する場合は統合または補足
     - 追記フォーマット例:
       ```markdown
       - **DO NOT**: 具体的な禁止事項 (#123)
       - **DO**: 具体的な推奨事項 (#456)
       ```
     - 分類が難しい場合は新しいセクションを作成
   - **バグラベルがついているPRの場合**:
     - バグの原因と修正内容を分析
     - 同様のバグを防ぐための予防策をガイドラインに追記
     - 追記フォーマット例:
       ```markdown
       ### バグ予防 (#123)
       - **DO NOT**: バグの原因となった実装パターン
       - **DO**: 正しい実装パターン
       - **原因**: バグが発生した根本原因の説明
       ```
     - 既存のセクションに関連する場合はそのセクションに追記
   - **修正要求がない場合**（Copilotの自動レビューのみ等）:
     - 追記不要と判断してスキップ

5. **複数PR対応**
   - 複数のPR番号が指定された場合は、それぞれについて上記を実行
   - 関連する指摘はまとめて記録

6. **最終分析日の更新**
   - 分析完了後、`CODING_GUIDES.md`の先頭にある「最終分析日」を今回の実行日（本日の日付）に更新する
   - フォーマット: `最終分析日: YYYY-MM-DD`
   - 例: `最終分析日: 2025-11-13`
   - 注意: 今回分析したPRの最新マージ日ではなく、**実行日**を記録する（次回はこの日より後にマージされたPRを対象とするため）

## 注意事項

- GitHub CLI (`gh`) のインストールと認証が必要
  - 実行前に `gh auth status` で認証状態を確認することを推奨
  - 認証エラーが発生した場合は `gh auth login` を実行
- 大量のPR（20件以上）を処理する場合は時間がかかる可能性があります
- GitHub API rate limit: 認証済みで5000 req/hour（通常は問題なし）
- レビューコメントが存在しない場合は何も表示されない
- 必ずユーザーの確認を得てから `CODING_GUIDES.md` に追記する
- 追記先は**プロジェクトの** `CODING_GUIDES.md` の適切なセクション
- フリーテキスト検索で大量のPRが見つかった場合は、処理前に件数と対象を確認
- `CODING_GUIDES.md` はClaude Codeが自動参照するファイル
- **最終分析日の管理**:
  - CODING_GUIDES.mdの先頭（ファイル説明の直後）に「最終分析日」の行が必要
  - 初回実行時に該当行がない場合は、分析完了後に追加する
  - 引数なしで実行する場合は必ずこの行を参照する
  - マージ日ベースなので、PR番号が前後しても漏れなく分析できる