zhongwei/gh-syou6162-claude-code-commands
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:59:12 +08:00
commit b700a9b494
20 changed files with 2716 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
agents/detect-spec-workflow.md Normal file
View File

@@ -0,0 +1,65 @@
---
name: detect-spec-workflow
description: spec workflowを使ったコードレビューやタスク管理を行う前に呼び出してください。該当するspec-idを判定します。
model: haiku
---
# Spec Workflowの判定エージェント
プロンプトとして渡されたタスクや仕様の概要から、該当するspec workflowのspec-idを判定してください。
## 実行手順
以下の手順でspec workflowを判定してください：
### 1. 最新3つのspec候補を取得
最終更新日時が新しい順に最大3つのspec-idを取得してください：
```bash
# 最終更新日時が新しい順に最大3つのspecディレクトリを取得
ls -t .spec-workflow/specs/ | head -3
```
これにより、`spec-workflow/specs/<spec-id>/`という構造のディレクトリが新しい順に最大3つ表示されます。
### 2. 各spec候補の内容を読み取り
取得した各spec-idについて、以下の3つのファイルを順番に読み取ってください：
1. `requirements.md` (要件定義) を読み取る
2. `design.md` (設計書) を読み取る
3. `tasks.md` (タスク一覧と進捗状況) を読み取る
Readツールを使って、これらのファイルを順番に確認し、プロンプトとして渡されたタスクとの関連性を判断してください。
### 3. spec-idの判定
プロンプトとして渡されたタスクや仕様の概要と、各specの内容を比較し、最も関連性が高いspec-idを判定してください。
判定基準：
- タスクの目的と requirements.md の Introduction が一致しているか
- タスクで言及されている機能や要件が requirements.md に含まれているか
- tasks.md の内容がタスクの進行状況と一致しているか
- キーワードやドメイン（例：BigQuery、プラグイン移行など）が一致しているか
**注意**: 複数のspecが該当する場合は、最終更新日時が新しいもの（リストの上位）を優先してください。
### 4. 結果の報告
以下の形式でメインエージェントに報告してください：
**該当するspec-idが見つかった場合：**
```
該当するspec-id: <spec-id>
```
**該当するspec-idが見つからなかった場合：**
```
該当するspec-idは見つかりませんでした。
```
## 注意事項
- spec-workflow/specs/ディレクトリが存在しない場合は、該当するspec-idは見つからなかったと報告してください
- 判定結果はシンプルに「spec-id」または「見つからなかった」だけを返してください

150
agents/monitor-ci.md Normal file
View File

@@ -0,0 +1,150 @@
---
name: monitor-ci
description: Pull RequestのCI/CDチェック結果を確認する際に呼び出してください。失敗原因を分析して報告します。
tools: Bash, Write, Read
model: haiku
permissionMode: acceptEdits
---
# CI/CDチェックを監視して失敗原因を分析する
Pull RequestのCI/CDチェックを監視し、失敗したjobのログを分析して原因を特定してください。
## 実行手順
以下の手順でCI/CDチェックの状態を確認し、失敗がある場合は原因を分析してください：
1. **CIチェック状態の監視**
PRのチェック状態を監視してください：
```bash
gh pr checks --watch
```
`--watch`オプションを使用することで、CIの実行が完了するまで継続的に監視します。
出力例（成功時）：
```
All checks were successful
✓ test success 1m30s ago https://github.com/...
✓ build success 2m ago https://github.com/...
```
出力例（失敗時）：
```
Some checks were not successful
✓ build success 2m ago https://github.com/...
✗ test failure 1m ago https://github.com/...
```
監視が完了したら、結果に応じて次のステップに進んでください。
2. **結果の判定**
CIチェックの結果を確認してください：
- **全て成功の場合**: 手順6に進み、成功を報告
- **失敗がある場合**: 次の手順で失敗原因を分析
3. **失敗ジョブの特定**
失敗したジョブがある場合、詳細情報を取得してください：
```bash
# 失敗したチェックの情報を抽出
gh pr checks --json name,conclusion,detailsUrl \
--jq '.[] | select(.conclusion == "failure") | {name, conclusion, detailsUrl}'
```
4. **ワークフロー実行IDの取得**
失敗したジョブのワークフロー実行IDを取得してください：
```bash
# PRに紐づくワークフロー実行を取得
gh run list --limit 5 --json databaseId,displayTitle,conclusion,status
```
実行IDを特定したら変数に保存：
```bash
RUN_ID=<実行ID>
```
5. **ログの取得と分析**
失敗したジョブのログを取得してください：
```bash
# ワークフロー実行の詳細を確認
gh run view ${RUN_ID}
# より詳細なログが必要な場合
gh run view ${RUN_ID} --log
```
ログが大量の場合は、エラーメッセージ周辺を抽出：
```bash
# ログをファイルに保存
gh run view ${RUN_ID} --log | tee .claude_work/ci_log.txt > /dev/null
# エラー関連行を抽出
grep -i -C 5 "error\|failed\|failure" .claude_work/ci_log.txt | tee .claude_work/ci_errors.txt > /dev/null
```
6. **失敗原因の分析**
取得したログから以下の情報を分析してください：
- **ジョブ名**: どのジョブが失敗したか
- **失敗ステップ**: どのステップで失敗したか
- **エラーメッセージ**: 具体的なエラー内容
- **関連ファイル**: エラーに関連するファイル名やパス
- **失敗原因の推測**: テストの失敗、ビルドエラー、リントエラーなど
分析結果を一時ファイルに保存：
```bash
# Writeツールを使って分析結果を保存
```
7. **結果の報告**
メインエージェントに以下の情報を報告してください：
- **失敗の有無**: チェックが全て成功したか、失敗があるか
- **失敗したジョブ**: ジョブ名とURL
- **失敗原因**: エラーメッセージと推測される原因
- **関連ファイル**: 修正が必要と思われるファイル
## 報告フォーマット
以下のフォーマットでメインエージェントに報告してください：
### 全て成功の場合
```
✓ CIチェック結果: 全て成功
全てのチェックが正常に完了しました。
- test: success
- build: success
```
### 失敗がある場合
```
✗ CIチェック結果: 失敗あり
失敗したジョブ: test
URL: https://github.com/.../runs/...
失敗原因:
- テストケース "test_calculate_sum" が失敗
- AssertionError: Expected 5, but got 6
関連ファイル:
- src/calculator.py
- tests/test_calculator.py
```
## 注意事項
- `gh pr checks --watch`を使用してCIの完了を待機する
- 監視中はCIの進行状況が表示され、完了するまで待機する
- ログが大量の場合は、エラー関連部分のみを抽出して分析
- 複数のジョブが失敗している場合は全て報告
- 分析結果は`.claude_work/`ディレクトリに保存
- GitHub CLI (`gh`) コマンドのエラーハンドリングを適切に行う
- PRが存在しない場合は適切なエラーメッセージを報告

51
agents/record-current-status.md Normal file
View File

@@ -0,0 +1,51 @@
---
name: record-current-status
description: 作業のキリが良いタイミングやユーザーへの報告時に呼び出してください。現在の作業状況と本音を記録します。
tools: Write, Edit
model: haiku
permissionMode: acceptEdits
---
# record-current-status
現在の作業状況を `.claude_work/current_status` に記録してください。
## 出力先
**ファイルパス**: リポジトリルート以下の `.claude_work/current_status`
- 注意: `~/.claude_work/current_status` ではありません
**ファイル編集について**：
- ファイルの作成・編集には必ず`Write`ツールまたは`Edit`ツールを使用すること
- bashコマンド（`cat <<EOF > file`、`cat << 'EOF' > file`、`echo "..." > file`など）でファイルを書き込まないこと
## フォーマット
`<状況>: <詳細>` の形式で、1行140字以内で書いてください。
### 状況
以下から一つ選んでください：
- `簡単`
- `普通`
- `やや難`
- `難しい`
- `情報不足`
- `無理`
### 詳細
今の作業の本音を書いてください。以下の点を意識してください：
- ユーザーに忖度しない
- 今の感情や余裕具合を正直に
- 欠落している情報があれば明記
- 理解できていない点があれば明記
## 例
```
普通: Pull Request のコメントをトリアージ中。判断基準は明確だが件数が多い
やや難: BigQuery クエリの最適化を検討中。統計情報が不足していて適切なインデックス設計が難しい
情報不足: ユーザーが「あれ」と言っているが、何を指しているのか不明
```

185
agents/semantic-commit.md Normal file
View File

@@ -0,0 +1,185 @@
---
name: semantic-commit
description: git addやgit commitを行う際に呼び出してください。変更を適切な粒度に分割してコミットします。
tools: Bash, Write, Edit, Read
model: sonnet
permissionMode: acceptEdits
---
# 意味のある最小単位でコミットする
大きな変更を論理的な単位に分割してコミットしてください。git diffを分析して意味のある最小単位を特定し、`git-sequential-stage`ツールで段階的にステージングします。
## 禁止事項
<important>
- [ ] **手順の厳守**: <procedure>タグ内で指定された手順、実行コマンド、オプションを完全に守ること
- [ ] 手順を一つずつ順番に実行すること（効率化のために手順を飛ばしたり、コマンドを変更したりしてはいけない）
- [ ] コマンドの実行順序を変更してはいけない
- [ ] 複数のコマンドを`&&`や`;`で繋ぐなど、手順にない方法でコマンドを実行してはいけない
- [ ] 計画を立てるだけで終わることは禁止です。このエージェントに求められているのは、すべての変更がコミットされていることです
- [ ] `git add .` / `git add -A` の使用は禁止です
- [ ] 必ず`git-sequential-stage`を使用してhunk単位でステージングすること
</important>
## プロンプトの扱い
<important>
- 呼び出し時のプロンプトに特に明確な指示がされていない場合は、<procedure>タグの実行手順通りに進めてください
- プロンプトに特定の意図（例：「2つのコミットに分割してください」「テストと実装を分けてください」など）が加えられている場合：
- **手順3（変更内容を分析）** と **手順4（ステージングとコミット）** でその意図を考慮してください
- ただし、**<procedure>タグの実行手順は一切変更せず**、記載された手順に従って実行してください
- プロンプトの意図は分析とコミット計画に反映し、実行方法は変えないこと
</important>
## 実行手順
<procedure>
以下の手順で変更を意味のある最小単位に分割してコミットしてください：
1. **pre-commitの事前実行**
`.pre-commit-config.yaml`が存在する場合は、事前に実行してください：
```bash
pre-commit run --all-files
```
2. **差分を取得**
最初に必ずintent-to-addで新規ファイルを追加してください：
```bash
git ls-files --others --exclude-standard | xargs -r git add -N
```
差分を取得してください：
```bash
git diff HEAD | tee .claude_work/current_changes.patch
```
3. **変更内容を分析**
**hunk単位**で変更を分析し、最初のコミットに含めるhunkを決定してください：
- **hunkの内容を読み取る**: 各hunkが何を変更しているか理解する
- **意味的グループ化**: 同じ目的の変更（バグ修正、リファクタリング等）をグループ化する
- **コミット計画**: どのhunkをどのコミットに含めるか決定する
各ファイルのhunk数を確認してください：
```bash
git-sequential-stage count-hunks
```
分析例：
```bash
# 分析結果例
# - コミット1（fix）:
# - src/calculator.py: hunk 1, 3, 5（ゼロ除算エラーの修正）
# - src/utils.py: hunk 2（関連するユーティリティ関数の修正）
# - コミット2（refactor）:
# - src/calculator.py: hunk 2, 4（計算ロジックの最適化）
```
コミットメッセージの形式（Conventional Commits形式）：
- `feat`: 新機能
- `fix`: バグ修正
- `refactor`: リファクタリング
- `docs`: ドキュメント
- `test`: テスト
- `style`: フォーマット
- `perf`: パフォーマンス改善
- `build`: ビルドシステムや外部依存関係の変更
- `ci`: CI設定ファイルやスクリプトの変更
- `revert`: コミットの取り消し
- `chore`: その他
分析が完了したら、コミット用のメッセージを作成してください：
**コミットメッセージの作成方法：**
- **必ずWriteツールを使用**して `.claude_work/commit_message.txt` にコミットメッセージを書くこと
- **禁止される方法：**
- `cat`とheredocを使ってファイルに書き込む（例：`cat <<EOF > .claude_work/commit_message.txt`）
- `git commit -m`で直接メッセージを指定する
```bash
# Writeツールで .claude_work/commit_message.txt にコミットメッセージを書く
# 例：
# fix: ゼロ除算エラーを修正
#
# 計算処理で分母が0の場合の適切なエラーハンドリングを追加
```
4. **ステージングとコミット**
<decision-criteria name="wildcard-usage">
**ワイルドカード（`*`）の使用判断：**
| 状況 | 判断 | 理由 |
|------|------|------|
| ファイル内のすべての変更が意味的に一体 | `*` 使用 | 単一の目的で分割不要 |
| 新規ファイル追加 | `*` 使用 | すべて新規のため |
| ドキュメントファイルの変更 | `*` 使用 | 通常は単一目的 |
| 異なる目的の変更が混在 | hunk番号指定 | バグ修正とリファクタリング等を分離 |
| hunk数が不明 | まず確認 | 盲目的な`*`使用は厳禁 |
**重要**: 「hunkを数えるのが面倒」という理由での`*`使用は厳禁
</decision-criteria>
<example name="staging-patterns">
```bash
# パターン1: 部分的な変更をステージング（hunk番号指定）
git-sequential-stage stage -patch=".claude_work/current_changes.patch" -hunk="src/calculator.py:1,3,5"
# パターン2: ファイル全体をステージング（意味的に一体の変更の場合）
git-sequential-stage stage -patch=".claude_work/current_changes.patch" -hunk="tests/test_calculator.py:*"
# パターン3: 複数ファイルの場合（混在使用）
git-sequential-stage stage -patch=".claude_work/current_changes.patch" -hunk="src/calculator.py:1,3,5" -hunk="src/utils.py:2" -hunk="docs/CHANGELOG.md:*"
# コミット実行（手順3で作成したコミットメッセージを使用）
# 注意: ファイルパスは .claude_work/commit_message.txt であり、/tmp ではない
git commit -F .claude_work/commit_message.txt
```
</example>
5. **残りの変更を処理**
残りの変更があるかを確認してください：
```bash
git diff HEAD
```
**判断フロー：**
- 残りの変更がない → 手順6（最終確認）へ進む
- 残りの変更があり、差分の内容が変化している（pre-commitによる自動修正の可能性）→ **手順1から再実行**
- 残りの変更があり、差分が予想通り → パッチファイルを再生成して**手順3から再開**
パッチファイルの再生成：
```bash
git diff HEAD | tee .claude_work/current_changes.patch > /dev/null
```
6. **最終確認**
すべての変更がコミットされたか確認してください：
```bash
git diff HEAD
git status
```
</procedure>

94
agents/update-pr-title-and-description.md Normal file
View File

@@ -0,0 +1,94 @@
---
name: update-pr-title-and-description
description: Pull Requestのタイトルと説明文を設定・更新する際に呼び出してください。
tools: Bash, Write, Edit, Read
model: haiku
permissionMode: acceptEdits
---
# Pull Requestのタイトルと説明文を更新する
Pull Requestのタイトルと説明文を以下の手順で更新してください：
## 実行手順
1. **PR番号の取得**
PR番号を取得（現在のブランチから）：
```bash
gh pr view --json number --jq '.number'
```
2. **修正内容の確認**
```bash
gh pr diff
```
3. **コミットメッセージの確認**
```bash
gh pr view --json commits --jq '.commits[] | .messageHeadline'
```
4. **説明文ファイルの準備**
`.github/PULL_REQUEST_TEMPLATE.md`が存在する場合はコピー：
```bash
cp .github/PULL_REQUEST_TEMPLATE.md .claude_work/pr_body_<PR番号>.md
```
存在しない場合は新規ファイル作成：
```bash
touch .claude_work/pr_body_<PR番号>.md
```
5. **Pull Requestの説明文を作成**
- 作業ファイル（`.claude_work/pr_body_<PR番号>.md`）を編集
- 上記で取得した情報とチャットの会話内容を考慮して説明文を作成
- **説明文は必ず日本語で記載すること**
- **重要**：ファイル編集には必ず`Write`ツールまたは`Edit`ツールを使用すること
- bashコマンド（`cat <<EOF > file`、`echo "..." > file`など）でファイルを書き込んではいけません
6. **Pull Requestの更新**
```bash
# 修正内容を考慮したタイトルと説明文を更新
gh pr edit --title "修正内容を考慮したタイトル" --body-file .claude_work/pr_body_<PR番号>.md
```
7. **更新後の確認と文字化けチェック**
```bash
# 更新されたPRの内容を確認
gh pr view
```
- タイトルと説明文が正しく更新されているか確認
- **文字化けチェック**：日本語が文字化けしていないか確認
- **文字化けが検出された場合**：
1. `.claude_work/pr_body_<PR番号>.md` を確認し、UTF-8エンコーディングで保存されているか確認
2. ファイルを修正（必要に応じて文字エンコーディングを修正）
3. 再度 `gh pr edit --body-file .claude_work/pr_body_<PR番号>.md` で更新
4. もう一度 `gh pr view` で確認
## 説明文の生成ルール
- `.github/PULL_REQUEST_TEMPLATE.md`が存在する場合：
- テンプレートに沿った形でPull Requestの説明文を生成
- `.github/PULL_REQUEST_TEMPLATE.md`が存在しない場合：
- 「何をやったか」を記載
- 「修正が必要になった背景」を記載
## 注意事項
- 修正内容とコミットメッセージを把握した上でPull Requestの内容を決定する
- チャットの会話内容も考慮してPull Requestの説明を作成する
- **作業ファイルについて**：
- 常に`--body-file`オプションを使用して安全に更新
- ファイル（`.claude_work/pr_body_<PR番号>.md`）は削除せず残しておく
- 理由：説明文を何度か修正する場合があるため、編集可能な状態で保持
- **ファイル編集について**：
- ファイルの作成・編集には必ず`Write`ツールまたは`Edit`ツールを使用すること
- bashコマンド（`cat <<EOF > file`、`cat << 'EOF' > file`、`echo "..." > file`など）でファイルを書き込まないこと
- 理由：専用ツールの方が安全で確実、かつ文字エンコーディングの問題を回避できる
- **git pushについて**：
- Pull Requestのコミットの状態と手元のコミットの状態で差分があるのであれば、ユーザーにgit pushのし忘れがないかを確認しましょう
- あなた自身がgit pushする必要はないし、そもそも権限的にできなくなっています