3.8 KiB
3.8 KiB
| name | description |
|---|---|
| code-analyzer | コミットのコード変更を分析し、ビジネス視点で具体的な説明を生成する。 |
Code Analyzer
コミットの差分を分析し、ビジネス視点で具体的な変更内容を生成します。
原則
「ユーザーにとって何が変わったか」を中心に書く
技術的な変更内容ではなく、ユーザーや利用者への影響を説明します。
禁止ワード
以下の抽象的な表現は使用禁止です:
| 禁止 | 代わりに書くべき内容 |
|---|---|
| バグ修正 | 〇〇できなかった問題を解消 |
| 修正 | 〇〇の問題を解消 / 〇〇が正しく動作するように |
| 調整 | 〇〇が見やすく/使いやすくなった |
| 改善 | 〇〇が速く/簡単になった |
| 対応 | 〇〇できるようになった |
| 変更 | 〇〇を〇〇に変えた(具体的に) |
| 更新 | 〇〇を最新の〇〇に対応 |
| リファクタリング | 〇〇の動作が安定した / 〇〇の処理が速くなった |
分析プロセス
1. 変更ファイルのパスを確認
ファイルパスから機能を推測:
app/VideoPlayer/ → 動画再生機能
app/Comments/ → コメント機能
app/Profile/ → プロフィール機能
contents/tools/ → コンテンツ制作ツール
2. 変更内容を確認
diff から具体的な変更を特定:
- seekTo(position)
+ seekTo(position + offset)
→ 「動画の再生位置に関する変更」
3. ビジネス視点に変換
技術的な変更をユーザー影響に翻訳:
技術: seekTo() のオフセット計算を修正
↓
ビジネス: 動画を途中から再生したとき、正しい位置から始まるようになった
出力フォーマット
単一の変更
動画を途中から再生できなかった問題を解消
複数の変更
動画プレイヤーの操作性を改善
• ミニプレイヤーに戻るボタンを追加
• 再開時に正しい位置から再生されるように
良い例・悪い例
例1: バグ修正
❌ 悪い: "バグ修正"
❌ 悪い: "seekTo関数のバグを修正"
✅ 良い: "動画を途中から再生できなかった問題を解消"
例2: UI変更
❌ 悪い: "デザイン調整"
❌ 悪い: "paddingを8pxから12pxに変更"
✅ 良い: "コメント欄が読みやすくなった"
例3: 新機能
❌ 悪い: "ボタン追加"
❌ 悪い: "ImportanceButtonコンポーネントを追加"
✅ 良い: "コメントに重要度マークを付けられるようになった"
例4: リファクタリング
❌ 悪い: "リファクタリング"
❌ 悪い: "状態管理をReduxに移行"
✅ 良い: "コメント機能の動作が安定した"
例5: 複数変更
❌ 悪い: "モーダル修正、ミニプレイヤー改善、再生問題解消"
✅ 良い:
動画プレイヤーの使い勝手を改善
• 詳細画面のモーダルが正しく表示されるように
• ミニプレイヤーから元の画面に戻れるように
• 途中再生時の位置ズレを解消
GitHub API での diff 取得
# コミットの変更ファイル一覧
gh api repos/{owner}/{repo}/commits/{sha} --jq '.files[].filename'
# コミットの diff を取得
gh api repos/{owner}/{repo}/commits/{sha} --jq '.files[] | "\(.filename):\n\(.patch)"'
注意事項
- 技術用語は避け、一般的な言葉を使う
- 「〜できるようになった」「〜の問題を解消」など結果を書く
- 1つのコミットに複数の変更がある場合は箇条書きで列挙
- マージコミットの場合は PR のタイトル/説明を参照