القائمة
作成手順「tech-decision-adr」（self-evolving-agent から自動同期）: 技術判断ドキュメント（ADR）作成手順
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
全 Claude セッションをスキャンし、ユーザーが何をしているかを分析して、 スキル・MCP プラグイン・エージェント・CLAUDE.md のどれに最適化すべきかを分類し、 具体的な改善提案（優先度・実装難易度・推奨アクション付き）を生成する。 Use when the user wants to analyze their Claude usage patterns, or when asked to "scrape sessions", "what do I do with Claude", or "what should be a skill vs agent vs claude.md".
PRをレビューしてインラインコメントをGitHubに投稿する。PR descriptionで意図を把握してからdiffをレビューし、What+Why+How形式・重大度ラベル付きのコメントをgh APIで各行に直接投稿する。「PRをレビューする」「コードレビューしたい」「このPRの品質を確認したい」時に使う。
Claude Code のトークン使用量・コストの確認と分析を行う。日次・月次レポートの表示から 高コスト要因・キャッシュ効率の分析、削減提案まで（表示だけの軽量モードあり）。 Use when you need to check today's or this month's token usage and cost, or to analyze Claude Code costs and get reduction suggestions. Triggers on: "今日のコスト", "今月のコスト", "トークン使用量", "ccusage", "コスト分析", "コスト削減".
/compact の前に、圧縮の要約から抜け落ちやすい「判断構造」と「セッション状態」を tmp/compact-state/latest.md に固定フォーマットで保存する。 Use when you are about to run /compact, when the user says "compact する前に", "compact-prep", "コンテキストを圧縮したい", or when context usage is high and compaction is imminent. Do NOT use for cross-session handover documents (use handover) — compact-prep is for surviving in-session compaction, not for ending a session.
現在のセッションの作業内容を次のセッションへ引き継ぐための引き継ぎドキュメントを生成する。 Use when the user asks to summarize the session for handover, says "引き継ぎ", "次のセッションに渡して", "context をまとめて", or when a session is ending and you think it would help to create a handover document for continuity. Also use when you are about to run out of context and want to preserve progress.
作成手順「1on1-prep」（self-evolving-agent から自動同期）: 1on1 準備手順（ EM 版）
| name | tech-decision-adr |
| description | 作成手順「tech-decision-adr」（self-evolving-agent から自動同期）: 技術判断ドキュメント（ADR）作成手順 |
用途: チームの技術判断（アーキテクチャ・ライブラリ選定・設計方針・運用方式）を構造化記録するとき。workspace/adr-YYYYMMDD-[トピック略称].md に作成。所要 30〜60 分。
以下のいずれか 1 つに当てはまる → 書く。それ以外 → PR コメント・口頭で十分。
省略可: 1 ファイル・1 関数の実装詳細／ベストプラクティスが 1 つしかない当然の選択／即合意できた小さな方針変更。
| 項目 | 値 |
|---|---|
| プロジェクト/モジュール | [対象範囲] |
| 論点 | [「〇〇 vs 〇〇」で 1 行] |
| 作成日 | [今日の日付] |
| 委任度 | Andy 決定 / チーム提案・Andy 承認 / チーム決定（後報） |
| ステータス | 草案 / レビュー中 / 決定済み / 廃止 |
| 決定期限 | [YYYY-MM-DD — なぜその日までか 1 行]（Lesson C：平日確認） |
委任度の 3 分類（EM として使い分ける）: Andy 決定＝アーキ全体・チームパターン変更・外部影響あり／チーム提案・Andy 承認＝実装詳細・モジュール内設計で Andy はゲート／チーム決定（後報）＝影響限定でチーム自律、ADR は事後報告。
「何を選んだか＋なぜ＋前提が変わる条件」を冒頭に置き、長文前に判断できるようにする。
フェーズ/状況・最優先事項（犠牲にできないもの）・チームリソース・時間制約・技術スタック制約を表で明示。「なぜそこまで慎重にしたか」を後から復元可能にする。
案を評価する前に「何を基準に比べるか」を合意し、各軸に重み（⭐⭐⭐〜⭐）と重み付けの根拠 1 行を付ける。順序が逆だと「決めた後に理由を作る」になる。EM 頻出軸：本番安定性・チームスキル親和性・長期保守コスト・今期工数負荷・外部依存/ロックイン・テスト容易性。
各案を評価軸ごとに ✅/⚠️/❌＋根拠 1 行で評価し、最後に「本質的な問題/強み」を 2〜3 文で言語化（評価表の要約でなく採否の核心）。
採用案の説明より「なぜ他を選ばなかったか」の方が価値が高い。これがないと数ヶ月後に同じ議論が再燃する。各却下案について「長期的には良いが現在の制約 X のため今は採れない」等の具体的根拠を書く。
リスク／深刻度（🔴🟡🟢）／対策を表に。再検討トリガーを最低 1 件必須（例「工数が想定の 2 倍超」「2 人以上が実装困難と報告」）。制約で見送った案は、その制約が消えたときの再検討条件とセットで残す。
空欄禁止。不明は [未定] プレースホルダー。
対象（チームエンジニア／PM／外部パートナー）ごとに 共有方法・伝える内容・期限を表で明示。書いても共有されなければ決定は広まらない。
取り込み経緯: 2026-06-17 の auto-kaizen で「技術判断（ADR）が唯一 eval 例あり×手順なしの最大ギャップ」と自己診断（スコア 88）。workspace/auto-kaizen.md に作成後 procedure として昇格。
