commit-review-with-log

Files (1)

• SKILL.md

SKILL.md (first lines)

> **⚠️ このスキルは廃止（RETIRED）されました。**
>
> pd `periodic-review` が本スキルを retired asset として指定しています（PR-3 canonical reference drift）。
> 後継の正本:
> - コミット後の非同期レビュー → `codex-review`（project-design `.claude/skills/codex-review/`）
> - 定期レビュー → `periodic-review`（project-design `.claude/skills/periodic-review/`）
>
> 以下は履歴参照用。**新規に本スキルを起動しないこと。**

# skills/commit-review-with-log/SKILL.md — コミット影響レビュー（廃止）

**目的**: コミットごとに変更の影響を広範囲にレビューし、参照切れ・パス不整合・副作用を検出する。

**使用タイミング**: ファイルの移動・削除・リネームを含むコミットの前後。特に cross-repo 変更時。

**担当**: 任意の LLM エージェント（Claude Code CLI, Codex, Gemini 等）

**バージョン**: 1.0
**作成日**: 2026-03-15
**移植元**: 旧 private repo skills/commit-review-with-log/SKILL.md

---

## 0. 運用モード

### モード A: 同期（作業 CLI 自身が実行）

コミット前に自分でレビューする。安全だが作業が止まる。

### モード B: 非同期（別 CLI で並行実行）

作業 CLI はコミット＆push に専念。別の LLM が非同期でレビューし、問題があれば Issue コメントで報告する。作業を止めない。

**非同期フロー:**

```
作業CLI: commit → push → 次のタスクへ
                ↓ (コミットSHA)
レビューCLI: SKILL.md を読む → git diff で変更検出 → Phase 1-3 → レポート出力
                ↓
            PASS → Issue コメントに PASS 報告
            WARN → Issue コメントに警告 + 対応 Issue 番号
            FAIL → Issue コメントに FAIL 報告 → オーナーに通知
```

### モード B の起動方法

レビュー CLI に以下を伝える：

```
あなたはレビュー専任です。作業は一切しません。

skills/commit-review-with-log/SKILL.md を読んでください。

以下のコミットの影響をレビューしてください:
- repo: {リポジトリ名}
- branch: {ブランチ名}
- コミットSHA: [SHA]（または「最新コミット」）
- 関連Issue: #{番号}

Phase 1-3 を実行し、レポートを Issue #{番号} にコメントしてください。
```

---

## 1. 入力

レビュー対象を特定するための情報。以下のいずれかを受け取る。

| 入力パターン | 取得方法 |
|---|---|
| コミットSHA | `git diff <SHA>~1 <SHA> --name-status` |
| ステージング済み | `git diff --cached --name-status` |
| 作業ツリー | `git diff --name-status` + `git status` |
| 指定ファイルリスト | 指示書に列挙されたパス |
| ブランチ差分 | `git diff develop..feature/xxx --name-status` |

**出力**: 変更ファイルの一覧と変更種別（Added / Modified / Deleted / Renamed）

---

## 2. レビュー手順

### Phase 1: 変更の分類

変更ファイルを以下に分類する。

| 分類 | 説明 | リスク |
|---|---|---|
| **パス変更**（Delete / Rename / Move） | ファイルが消えた or 場所が変わった | 参照切れの直接原因 |
| **内容変更**（Modified） | ファイルの中身が変わった | 依存先の期待値と不一致の可能性 |
| **追加**（Added） | 新規ファイル | 通常は安全。ただしルールファイルの追加は波及あり |

### Phase 2: 影響範囲の走査

**パス変更があった各ファイルについて、以下を全件実行する。**

#### 2a. ファイルパス参照の grep（最重要）

```bash
# 変更されたファイルのパス（相対パス部分）を全 repo から検索
SEARCH_TERM="変更パスの特徴的な部分"

# リポジトリ内検索
grep -rn "$SEARCH_TERM" --include='*.md' --include='*.sh' --include='*.py' --include='*.js' --include='*.json' --include='*.mjs' \
    . 2>/dev/null | grep -v '.git/' | grep -v 'node_modules/' || echo "(none)"
```

検出されたファイルごとに、該当行と修正要否を報告する。

#### 2b. スクリプトの入出力チェック

変更がスクリプト（.sh, .py, .mjs）の入出力パスに影響する場合、scripts/ 配下を検索する。

#### 2c. 管理書類の整合チェック

変更が以下の管理書類の記述と矛盾しないか確認：

| ファイル | チェック内容 |

From uminomae/creation-space, MIT.

More from uminomae/creation-space