commit-report-tool/.claude/skills/code-analyzer/SKILL.md
2026-04-03 19:31:32 +09:00

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 のタイトル/説明を参照