Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:45:43 +08:00
commit 0d21da1040
11 changed files with 453 additions and 0 deletions

209
commands/commit.md Normal file
View File

@@ -0,0 +1,209 @@
---
description: 分割commit
model: haiku
---
大きな変更を論理的な単位に分割してコミットします。LLMがgit diffを分析して意味のある最小単位を提案し、`git-sequential-stage`ツールによる自動化された逐次ステージングでコミットします。
#### git-sequential-stage
`git-sequential-stage`は、hunk単位の部分的なステージングを自動化するためのGoで実装された専用ツールです。
```bash
# hunk番号を指定して部分的にステージング
git-sequential-stage -patch="path/to/changes.patch" -hunk="src/main.go:1,3,5"
# ファイル全体をステージング(ワイルドカード使用)
git-sequential-stage -patch="path/to/changes.patch" -hunk="src/logger.go:*"
# 複数ファイルの場合(ワイルドカードと番号指定の混在も可能)
git-sequential-stage -patch="path/to/changes.patch" \
-hunk="src/main.go:1,3" \
-hunk="src/utils.go:*" \
-hunk="docs/README.md:*"
```
#### ワイルドカード使用の判断基準
ワイルドカード(`*`)を使用すべきケース
- ファイル内のすべての変更が意味的に一体である場合
- 新規ファイルの追加
- ファイル全体のリファクタリング(すべての変更が同じ目的)
- ドキュメントファイルの更新
hunk番号で分割すべきケース
- 異なる目的の変更が混在している場合
- バグ修正とリファクタリングが同じファイルに混在
- 機能追加と既存コードの改善が混在
⚠️ 注意点
- 「hunkを数えるのが面倒」という理由で使用するものではない。
- 意味のある最小単位でのコミットという本来の目的を必ず守ること。
## 実行手順
### Step 0: リポジトリルートに移動
```bash
# リポジトリルートを確認
REPO_ROOT=$(git rev-parse --show-toplevel)
echo "リポジトリルート: $REPO_ROOT"
# リポジトリルートに移動
cd "$REPO_ROOT"
```
### Step 1: 差分を取得
```bash
# .claude/tmpディレクトリは既に存在するため、直接ファイルを作成可能
# 新規ファイルuntracked filesをintent-to-addで追加
git ls-files --others --exclude-standard | xargs git add -N
# コンテキスト付きの差分を取得(より安定した位置特定のため)
# 新規ファイルも含めて取得される
git diff HEAD > .claude/tmp/current_changes.patch
```
### Step 2: LLM分析
LLMがhunk単位で変更を分析し、最初のコミットに含めるhunkを決定
- hunkの内容を読み取る: 各hunkが何を変更しているか理解
- 意味的グループ化: 同じ目的の変更(バグ修正、リファクタリング等)をグループ化
- コミット計画: どのhunkをどのコミットに含めるか決定
必要に応じて、hunk数を確認
```bash
# 全体のhunk数
grep -c "^@@" .claude/tmp/current_changes.patch
# 各ファイルのhunk数
git diff HEAD --name-only | xargs -I {} sh -c 'printf "%s: " "{}"; git diff HEAD {} | grep -c "^@@"'
```
例:
```bash
# LLMの分析結果
# - コミット1fix:
# - src/calculator.py: hunk 1, 3, 5ゼロ除算エラーの修正
# - src/utils.py: hunk 2関連するユーティリティ関数の修正
# - コミット2refactor:
# - src/calculator.py: hunk 2, 4計算ロジックの最適化
# 最初のコミット用の設定
COMMIT_MSG="fix: ゼロ除算エラーを修正
計算処理で分母が0の場合の適切なエラーハンドリングを追加"
```
### Step 3: 自動ステージング
選択したhunkを`git-sequential-stage`で自動的にステージング:
```bash
# git-sequential-stageを実行内部で逐次ステージングを安全に処理
# 部分的な変更をステージングhunk番号指定
git-sequential-stage -patch=".claude/tmp/current_changes.patch" -hunk="src/calculator.py:1,3,5"
# ファイル全体をステージング(意味的に一体の変更の場合)
git-sequential-stage -patch=".claude/tmp/current_changes.patch" -hunk="tests/test_calculator.py:*"
# 複数ファイルの場合(混在使用)
git-sequential-stage -patch=".claude/tmp/current_changes.patch" \
-hunk="src/calculator.py:1,3,5" \
-hunk="src/utils.py:2" \
-hunk="docs/CHANGELOG.md:*"
# コミット実行
git commit -m "$COMMIT_MSG"
```
### Step 4: 繰り返し
残りの変更に対して同じプロセスを繰り返し:
```bash
# 残りの差分を確認
if [ $(git diff HEAD | wc -l) -gt 0 ]; then
echo "残りの変更を処理します..."
# Step 1差分取得から再開
fi
```
### Step 5: 最終確認
```bash
# すべての変更がコミットされたか確認
if [ $(git diff HEAD | wc -l) -eq 0 ]; then
echo "すべての変更がコミットされました"
else
echo "警告: まだコミットされていない変更があります"
git status
fi
```
## 例
### ファイル内の意味的分割
```
変更内容: src/calculator.py
- hunk 1: 10行目のゼロ除算チェック追加
- hunk 2: 25-30行目の計算アルゴリズム最適化
- hunk 3: 45行目の別のゼロ除算エラー修正
- hunk 4: 60-80行目の内部構造リファクタリング
- hunk 5: 95行目のゼロ除算時のログ出力追加
↓ 分割結果
コミット1: fix: ゼロ除算エラーを修正
# バグ修正のhunkのみを選択他の変更と混在しているため番号指定
git-sequential-stage -patch=".claude/tmp/current_changes.patch" -hunk="src/calculator.py:1,3,5"
コミット2: refactor: 計算ロジックの最適化
# リファクタリングのhunkのみを選択
git-sequential-stage -patch=".claude/tmp/current_changes.patch" -hunk="src/calculator.py:2,4"
```
### 複雑な変更パターン
```
変更内容:
- src/auth.py: 認証ロジックの修正hunk 1,3,5とリファクタリングhunk 2,4
- src/models.py: ユーザーモデルの拡張hunk 1,2
- tests/test_auth.py: 新規テストhunk 1,2,3
↓ 分割結果
コミット1: fix: 既存認証のセキュリティ脆弱性修正
# セキュリティ修正のhunkのみを選択他の変更と混在
git-sequential-stage -patch=".claude/tmp/current_changes.patch" -hunk="src/auth.py:1,3,5"
コミット2: feat: JWT認証機能の実装
# 新機能実装に関連する変更を選択
git-sequential-stage -patch=".claude/tmp/current_changes.patch" \
-hunk="src/auth.py:2,4" \
-hunk="src/models.py:*" # モデルの変更はすべてJWT関連のため*を使用
コミット3: test: 認証機能のテスト追加
# 新規テストファイルは意味的に一体のため*を使用
git-sequential-stage -patch=".claude/tmp/current_changes.patch" -hunk="tests/test_auth.py:*"
```
# ベストプラクティス
1. 事前確認: `git status`で現在の状態を確認
2. 適切な指定方法の選択:
- 部分的な変更: `file.go:1,3,5` hunk番号を指定
- ファイル全体: `file.go:*` (意味的に一体の場合のみ)
3. 意味的一貫性: 同じ目的の変更は同じコミットに
4. Conventional Commits: 適切なプレフィックスを使用, 1行にまとめる
- `feat:` 新機能
- `fix:` バグ修正
- `refactor:` リファクタリング
- `docs:` ドキュメント
- `test:` テスト
- `style:` フォーマット
- `chore:` その他

1
commands/current-pr.md Normal file
View File

@@ -0,0 +1 @@
現在のPRを引き継いでください。

10
commands/pr-simple.md Normal file
View File

@@ -0,0 +1,10 @@
---
description: create pr
model: haiku
---
- create branch(if current branch in default) and pr
- following pr template
- description in japanese
- create create pr subtask
- 提出後は gh pr view --web で差分を共有して完了してください

13
commands/pr.md Normal file
View File

@@ -0,0 +1,13 @@
---
description: create pr
model: haiku
---
parallelで以下を進めます。
- create create pr subtask
- create branch and pr
- following pr template
- description in japanese
提出後は gh pr checks --watch で CI 成功を確認し、必要に応じて gh pr view --web で差分を共有します。
- comment-cleaner subagent diffに含まれる不要なコメントを削除します
- code-reviewer subagent を使用してレビューを進めてその結果を出力します

30
commands/review-pr.md Normal file
View File

@@ -0,0 +1,30 @@
---
description: review pr
argument-hint: [url]
model: haiku
---
PR $1 について理解しPR authorの身になってペアプロセッションを開始します。
レビュワーにわかりやすいように解説をしてください。
gh pr checkoutを実行して現在のブランチに切り替えるもしも異なるリポジトリにいる場合は ~/ghq/githtub.com/{owner}/{repo} に移動してください。
parallelに以下のsubagentsを実行します
- code-reviewer subagent を使用して初期レビューを実行します。
- explorer subagent を使用してPRの変更点を整理します。
- 追加した処理
- 変更した処理
- 削除した処理
- 影響のある他コンポネント
- dynamic-test subagent を使用してPRの対象となる機能を実際にBash Toolを用いて動作確認します。
- 動作確認手順
- 期待される結果
- 実際の結果
- もしも問題があればその詳細
以下の項目を報告してください
- コードの解説
- code-reviewerのフィードバック内容/動作確認結果を元にした代理質問を提案してください
そこからペアプロセッションを開始します。
- 〇〇のような入力があった場合、どのような挙動になりますか?
- この処理のパフォーマンスが気になりますが、どの程度の負荷がかかりますか?

23
commands/watch-pr.md Normal file
View File

@@ -0,0 +1,23 @@
---
description: watch pr
argument-hint: [url]
model: haiku
---
PR $1 がマージ可能になるまで監視し続けます。
gh pr checkoutを実行して現在のブランチに切り替えるもしも異なるリポジトリにいる場合は ~/ghq/githtub.com/{owner}/{repo} に移動してください。
code-reviewer subagent を使用して1次レビューを実行します。
CIが通過しているかどうか確認します。
以下の場合はマージ可能ではないため1分後に再度確認します
- CIが失敗している
- まだバグが残っている
- 変更がPR Descriptionで達成したいこと満たしていない
- Bash(sleep 60)で1分待機し、再度PRの状態を確認します
- マージ可能になるまでこの操作を繰り返します
マージ可能な場合以下を報告してください。
- コードの解説
- code-reviewerのフィードバック概要