指示更新スキル

Claude の間違いの再発防止、または作業で得た知見の恒久化のため、user-level（AGENTS.md）・PJ-level（CLAUDE.md）の指示・context・スキルを更新する。書く前に ~/.claude/context/claude-customization-guide.md を Read し、置き場所の判定・公開リポジトリに書く内容・書き方に従う。

モード

引数	対象
間違い・知見を指定	指定された1件を直す（下の「手順」）
retro	現在のセッション全体から恒久化すべき知見を洗い出す（下の「retro モード」→ 残った項目ごとに「手順」の Phase 2 以降）

手順

Phase 1: 関連ファイルを特定する

ファイル	確認観点
~/.claude/AGENTS.md（実体。CLAUDE.md は互換 symlink）	全 PJ 共通の作業フロー、基本ルール
~/.claude/context/*.md	詳細ルール、フォーマット定義
~/.claude/skills/*/SKILL.md	スキル固有のルール（user-level）
./CLAUDE.md	PJ 固有ルール・コマンド・環境情報
./.claude/skills/*/SKILL.md	PJ 固有スキル（運用手順・ドメイン知識）
./.claude/context/*.md	PJ 固有の詳細ルール

Phase 2: 修正方針を決める

タイプ	対応	例
指示の追加	新しいルールを追記	「〇〇の場合は△△する」
指示の明確化	曖昧な表現を具体化	「yymmdd」→「システムプロンプトの Today's date から取る」
例示の修正	誤解を招く例を修正	固定値の例示 → 動的な説明
機械強制への移管	hook・permissions.deny に移す	決定論的に判定できる禁止事項

• 繰り返し破られた規則なら、文面を足す前に hook・deny を先に検討する（claude-customization-guide.md §7(b)）
• user-level（全 PJ 共通）か PJ-level（特定 PJ のみ）かを決める。真実源を1か所にし、既存の記述があればそこを直す

Phase 3: 修正を提案して適用する

1. 修正案を示す

## 修正提案

### ファイル: <パス>

**変更前:**

<現在の内容>

**変更後:**

<修正後の内容>

**理由:** <なぜこの修正が必要か>

2. ユーザーの承認を得る（Claude Code: AskUserQuestion）。包括的な改修依頼（「見直して」「全部対応して」等）を受けているときは個別の承認を省き、完了報告でまとめて示す
3. 適用する

Phase 4: コミット

• user-level（~/.claude/）に適用したら、そのターンで /commit --push を実行する（AGENTS.md「コミット・ブランチ・PR」）
• project-level（<project>/.claude/・PJ CLAUDE.md）に適用したら、/commit の直コミット可否の判定に従う

retro モード（セッション全体から洗い出す）

1. 候補の収集: 会話全体から次を列挙し、各候補にセッション内の根拠を1行付ける
   • ユーザーからの訂正・好みの表明
   • Claude の間違いと修正（指示があれば防げたもの）
   • 発見した非自明な事実（環境のクセ・コマンドの落とし穴・仕様の実挙動）
   • 2回以上繰り返された手動指示
   • スキルの発火漏れ・誤発火・手順不足
2. フィルタ: 次を全部満たしたものだけ残す。除外した候補は理由付きで報告に載せる
   • このセッションで実際に起きた（仮想のルールを足さない）
   • デフォルト挙動を変える（no-op でない）
   • 追記先の候補を Grep して未記載（既存記述の不足なら「明確化」扱い）
   • 恒久的（今回限りの情報はメモリディレクトリへ）
3. 適用範囲: 「追加」と「明確化」は Phase 3 の個別承認を省いて適用し、報告でまとめて示す。既存ルールの削除・弱体化・矛盾する変更・settings.json の変更・好みの推測に基づく変更は適用せず提案に回す
4. 候補ゼロは正常: 無理に変更を作らず「恒久化すべき知見なし」と報告する

書き方

強調・命令形・理由の添え方・肯定形は claude-customization-guide.md「書き方」に従う。加えて次を守る。

• 例示に固定値（日付・ID）を使わず、「システムプロンプトから取る」等の動的な説明にする
• 繰り返し起きる間違いは、望ましい動きの記述として足す（禁止形の列挙は代替の行動を伝えず、本体の方針と衝突したときに抜け道ができる）。不可逆な操作・secret・承認ゲートは禁止形のまま残してよい
• 発火条件は着手前に確認できる事実で書く（「重要な変更のとき」「複雑な場合」等のモデルの自己分類に依存させない）
• 本体 system prompt と逆を言う追記は、原文を引用して名指しで優先を宣言する（一般論の追記は原文と並ぶと原文が優先される）。本体が既に言っていることは足さない

出力フォーマット

# 指示更新レポート

## 問題
- 間違い: <何が間違っていたか>
- 原因: <なぜ間違いが発生したか>

## 修正内容

### 1. <ファイルパス>
- 修正タイプ: <追加/明確化/例示修正/機械強制への移管>
- 変更内容: <概要>

## 適用状態
- [ ] ユーザー承認済み
- [ ] 修正適用済み