こんにちは、白々さじきです。
前回の記事で、Claude Code のカスタムスラッシュコマンドを使って GitHub Issue 作成を自動化しました。便利ではあったのですが、使っているうちに「バグもタスクも同じテンプレートでいいの？」という疑問が出てきました。
今回はその改善として、バグ・タスクの自動判定と .github/ISSUE_TEMPLATE/ の整備を行った話です。
はじめに：前回から見えた課題
前回作った /issue コマンドのフォーマットはこんな構成でした。
## タスク概要
## 背景
## やること
## 完了条件これはタスク向けの構成です。バグを報告するときは「背景」よりも「再現手順」「期待する動作」「実際の動作」が必要です。同じフォーマットで無理やり書くと「再現手順を背景に書く」という変なことになります。
整理するとこういう課題です。
- バグとタスクで必要な情報が違うのに、テンプレートが1種類しかない
- GitHub の
--labelも手動指定が必要で、bug / task の分類が属人的になっていた .github/ISSUE_TEMPLATE/が空で、ブラウザから Issue を作るときにもテンプレートがない
.github/ISSUE_TEMPLATE/ の整備
まず GitHub 標準のテンプレートを作りました。ブラウザから Issue を作成するときに使われます。
bug_report.md
---
name: バグ報告
about: 不具合を報告する
title: ''
labels: bug
assignees: sirajirasajiki
---
## 再現手順
## 期待する動作
## 実際の動作
## 完了条件task.md
---
name: タスク
about: 機能追加・改善・作業依頼
title: ''
labels: task
assignees: sirajirasajiki
---
## タスク概要
## 背景
## やること
## 完了条件
labels と assignees をフロントマターに書いておくと、ブラウザから Issue を作るときに自動でセットされます。ラベルは事前に GitHub 上で作成しておく必要があります（未作成だとエラーになります）。
/issue コマンドの型判定ロジック
次に /issue コマンド側を改善しました。ポイントは会話の内容からバグかタスクかを自動判定することです。
判定基準
| 判定 | キーワード例 |
|---|---|
| バグ | 「動かない」「エラーが出る」「おかしい」「壊れている」 |
| タスク | 「作りたい」「追加したい」「改善したい」「修正したい」 |
判断に迷う場合はユーザーに確認します。
バグ用テンプレート
## タスク概要
（バグの概要を1〜2文で要約）
## 再現手順
（バグを再現するための手順を箇条書き）
## 期待する動作
（本来こうなるはずという動作）
## 実際の動作
（実際に起きていること）
## 完了条件
（何ができていれば修正完了とみなすか）実行コマンド：gh issue create --assignee sirajirasajiki --label bug
タスク用テンプレート
## タスク概要
（Issue の目的を1〜2文で要約）
## 背景
（なぜこの課題が生まれたか・どんな問題が起きているか）
## やること
（具体的な対応内容を箇条書き）
## 完了条件
（何ができていれば完了とみなすか）実行コマンド：gh issue create --assignee sirajirasajiki --label task
グローバル版との差分
このプロジェクト版には --assignee sirajirasajiki が入っていますが、グローバル版には入っていません。個人プロジェクト以外ではアサインを固定するのが不適切なためです。グローバル版は --label bug / --label task だけ付与します。
実際に作成した Issue
このコマンドを使って作成した例です。
会話の内容から型を判定し、対応するテンプレートで下書きが生成されました。
つまずき：コマンド名の衝突
改善版を作るときに一度ハマりました。
元の構成はこうでした。
~/.claude/commands/issue.md ← グローバル版
.claude/commands/issue.md ← プロジェクト版同名のコマンドが両方に存在する場合、プロジェクト版が優先されるはずです。ところが、改善版のプロジェクト版コマンドを呼び出しても、実行されているのがグローバル版の古い動作になっていました。また、Issue コマンドが一つしか表示されませんでした。
原因を調べると、コマンド名が完全一致していたため、スレッドの読み込みタイミングによって挙動が変わっていたようです。
解決策として、プロジェクト版のファイル名を issue-guided-scheduler.md にリネームしました。
~/.claude/commands/issue.md ← グローバル版（そのまま）
.claude/commands/issue-guided-scheduler.md ← プロジェクト版（リネーム）
プロジェクト内では /issue-guided-scheduler を使い、他のリポジトリでは /issue を使う、という使い分けになります。
教訓：グローバル版と同名のコマンドをプロジェクト版に作ると、どちらが呼ばれるか不安定になることがある。プロジェクト固有コマンドには最初からプロジェクト名を含む名前をつける。
おまけ：/article コマンドの整備で気づいたこと
今回の作業と並行して、ブログ記事の下書きを自動化する /article コマンドも整備しました。そのときに一つ気になったことがあります。
Claude Code の EnterPlanMode 機能はプランを ~/.claude/plans/ に保存します。これはグローバルなディレクトリなので、プロジェクトのコンテキストで作ったプランがリポジトリの外に散らばります。
解決策として、このプロジェクトではプランを docs/plans/ に保存するよう、コマンドファイルとメモリの両方に明記しました。
# .claude/commands/article-guided-scheduler.md に追記
## プランファイルの保存先（このプロジェクト固有）
- EnterPlanMode で作成したプランは `docs/plans/plan-{slug}.md` に保存する
- デフォルトの `~/.claude/plans/` には保存しない教訓：Claude Code のデフォルト保存先はグローバルになっていることが多い。プロジェクト固有のルールはコマンドファイルに明示しないと毎回違う場所に置かれる。
まとめ
バグとタスクでテンプレートを分けたことで、Issue の中身が最初から整うようになりました。「再現手順が書いてない」「期待する動作が不明」といった Issue が減ります。
今回の改善で学んだことをまとめます。
- バグとタスクは最初から別テンプレートにする。後から分けるのは手間がかかる
- プロジェクト固有コマンドには最初からプロジェクト名を含む名前をつける。グローバルと同名にすると衝突リスクがある
- Claude Code のデフォルト動作（ファイル保存先など）は把握しておく。把握していないとプロジェクトのルールとズレが生じる
サポートのお願い
下記リンクからお買い物いただけると、ブログ運営のための費用が増え、有料サービスを利用した記事作成が可能になります。ご協力よろしくお願いします！
コメント