Menú
作成手順「kaizen-report」（self-evolving-agent から自動同期）: Procedure: kaizen-report
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional 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 | kaizen-report |
| description | 作成手順「kaizen-report」（self-evolving-agent から自動同期）: Procedure: kaizen-report |
用途: 2 週間スプリントの終わりに Keep/Problem/Try 構造のレトロ文書を
workspace/kaizen-report-SprintXX.md として作成するとき。目標: Try が
「仮説 → 指標 → 計測 → 次レトロで検証」のループを確実に閉じる品質にする。
発言から観察を洗い出すのではなく、先にデータを用意する。
| データソース | 何を見るか |
|---|---|
| GitHub PR（前スプリント期間） | マージ日時の曜日分布・レビュー待ち時間・reverts の有無 |
| Jira / GitHub Issues | rework ラベル件数・ブロッカー起票件数・未完了チケット |
| 1on1 メモ（直近 2 回分） | 複数メンバーが同じ不満・詰まりを言及していないか |
| 前スプリントの Try（M の実測値） | M1・M2 の目標達成 / 未達の実数（「体感」不可） |
| インシデント / P1 バグ | 発生件数・復旧時間 |
「体感 50%」を「実測 52%（全 25 PR 中 13 件が金曜マージ）」に変えるだけで Try の仮説設定精度が大きく上がる。計測できなかったなら「計測できなかった」と 明記し、次スプリントでの計測方法を Try に含める。
レトロの最初の 10 分で必ず実施する。後回しにしない。
前スプリントの T1/T2 それぞれについて確認する:
| 確認項目 | 問い |
|---|---|
| M の実測値 | M1 / M2 の数値は何だったか？ |
| 判定 | 達成 → Keep 格上げ候補 / 未達 → 根本原因の再分析 / 計測不能 → なぜか |
| 次のアクション | 継続 / 中止 / 修正して再設計 |
アンチパターン: 「なんとなくうまくいった気がします」で終わる。 数値で判断する。数値がなければそれ自体が問題（Try の設計ミス）。
| ステップ | 問い |
|---|---|
| 具体事実 | 今スプリントで何が起きたか？ |
| 行動特性 | その行動に表れている思考・習慣は何か？ |
| インパクト | チームや成果物にどう効いたか？ |
絞り込み基準: 「来スプリントも同じ環境で再現できるか？」→ Yes なら Keep。 偶発的な好成果は Keep にしない。
全部書くフェーズと絞るフェーズを分ける。
| 軸 | 基準 |
|---|---|
| 再発性 | 2 スプリント以上繰り返されているか |
| ビジネス影響 | KPI・スループット・チーム健康に大きく影響するか |
なぜ 1〜2 件か: Problem を 3 件以上あげると Try も 3 件になり、 「何を変えたから何が改善したか」が分からなくなる。
| 層 | 説明 |
|---|---|
| 直接原因 | 何が引き金になったか（症状に近い面） |
| 根本原因 | なぜそれが起きる構造になっているか |
| 寄与因子 | 問題を悪化・検知遅延させた要因 |
| 条件 | 要件 |
|---|---|
| 1. 仮説文 | 「もし [具体的アクション] をすれば、[M] が [方向] に変化するはずだ」の形式 |
| 2. 指標 M | 数値で客観的に測れるものが 1 つ。「体感で判断」は不可 |
| 3. 担当 1 名 | 「チーム全員」ではなく最終責任者が 1 名明記 |
| 4. 計測期日 | いつ M を測るか。「次スプリント中」は不可。日付まで書く |
Q1. スプリント終了時に「Try が成功したかどうか」を誰でも客観的に判断できるか？
→ Yes なら合格 / No なら M を再定義
Q2. 仮説が証明されたとき、もとの Problem が解決するか？
→ Yes なら合格 / No なら根本原因の分析が浅い
Q3. 1 スプリント内（2 週間）で実施・計測できるか？
→ Yes なら合格 / No なら Try を分割
### T[n]：[タイトル]（P[n] 対策）
| 項目 | 内容 |
|---|---|
| **仮説** | もし [具体的アクション] をすれば、[M の値] が [目標値] に近づくはずだ |
| **実施内容** | 1. [手順1]<br>2. [手順2] |
| **担当** | [1名の名前] |
| **期日（計測日）** | [YYYY-MM-DD（曜日）] |
Try 1 件につき M は 1 つ。
| 要素 | 要件 |
|---|---|
| ベースライン | 今スプリントの実測値（Step 0 で取得。「体感」不可） |
| 目標値 | 実測の 20〜40% 改善が目安。非現実的な目標は諦められる |
| 測定方法 | 誰が・いつ・何から計測するか（具体的なツール・手順） |
| 判定ルール | 目標達成 → Keep 格上げ候補 / 未達 → P を再分析 |
# Kaizen レポート — Sprint [番号]
> **スプリント期間:** YYYY-MM-DD（曜日）〜 YYYY-MM-DD（曜日）
> **レトロ実施日:** [素材から読み取れる日付、不明なら プレースホルダー]
> **作成者:** Andy
## 前スプリント Try の振り返り
| # | Try 内容 | M の実測値 | 目標達成？ | 判定・次のアクション |
|---|---|---|---|---|
| T1 | … | [実測値] | ✅/❌/計測不能 | 継続 / 中止 / 再設計 |
## Keep — 続けること
### K[n]：[タイトル]
- **具体事実:** …
- **行動特性:** …
- **インパクト:** … + 次スプリントでの継続方針
## Problem — 改善すべき問題
### P[n]：[タイトル]
| 項目 | 内容 |
|---|---|
| 現象 | … |
| 直接原因 | … |
| 根本原因 | … |
| 寄与因子 | … |
| 対策 | ① … |
| 担当 | [1名] |
| 期日 | [YYYY-MM-DD（曜日）] |
## Try — 次スプリントで試す実験
### T[n]：[タイトル]（P[n] 対策）
| 項目 | 内容 |
|---|---|
| 仮説 | もし … をすれば、[M] が [目標] に変わるはずだ |
| 実施内容 | 1. … |
| 担当 | [1名] |
| 期日（計測日）| [YYYY-MM-DD（曜日）] |
## 次スプリントで検証する指標
| # | 指標 | 実績 | 目標値 | 測定方法 | 判定ルール |
|---|---|---|---|---|---|
| M1 | … | [実測] | [目標] | … | 達成 → 継続 / 未達 → 再分析 |
## 次回シード
- M1 / M2 の実測値を次レトロ冒頭のアジェンダ 1 番目に追加する
- [持ち越した議論・次レトロで確認したいこと]
取り込み経緯: 2026-06-22 の auto-kaizen セッションで「kaizen-report が 10 ドメイン中
唯一 Procedure ゼロかつ Try 品質がテンプレートによって不統一」と自己診断。
workspace/kaizen-report.md（旧）と workspace/eval-kaizen.md（新）の Try 構造の差異が
「やりっぱなし Try」の原因と特定。「良い Try の 4 条件」を核心として Procedure 化。