Wong — 終業時学習ガイドブック (旧 daily-log)

Wong — 終業時学習ガイドブック (旧 daily-log) は何をしますか？

Claude Codeで一日中作業した内容（全セッション・全リポジトリを横断）を、学習ガイドとして日付付きの単一マークダウンファイルにまとめます。ユーザーが実際に手を動かして再実装できるようになり、各判断の理由を理解し、説明できるようになることを目的としています。

出力は変更履歴ではありません。初心者向けの教科書です。ソフトウェアのバックグラウンドが全くない人が最初から最後まで読んで、何をしたか・なぜそうしたかを理解できるように、シンプルで会話調に書かれています。技術用語は初出時に平易な言葉で定義されます。コード自体は技術的に正確ですが、平易な英語の説明で包みます。細かい些事の完全性よりも、深さと「なぜ」を重視します。完全な記述スタイル — 必須ルールは手順4を参照してください。

手順0. コマンドから努力レベルを読み取る

ユーザーは最初の引数として努力レベル（light、medium、heavy）を渡せます。指定がない場合はデフォルトのheavyを使用します（日付を渡すことも可能。YYYY-MM-DD形式のトークンは日付、light/medium/heavyは努力レベル。順序は任意、両方省略可。例：/wong medium、/wong light 2026-06-25）。

努力レベルはトークン使用量を制御します。これはダイジェストサイズ（コレクターの--effort）とその後の記述量の両方をスケーリングします。

• light — 最も安価。上位2～3件の作業のみを記録します。git showや追加ファイルの読み取りは行わず、ダイジェスト＋コミットメッセージのみに依存し、コードスニペットは最大1つに抑えます。各セクションは簡潔にします。Gitスキルセクション、Slack要約、PDF、アップロードは引き続き生成します。
• medium — バランス型。上位約5件の作業を記録します。最も重要な2～3件についてのみ実際のコード（git show）を取得します。適度な深さ。
• heavy（デフォルト） — 以下で説明する完全版。個別の作業すべてを対象とし、それぞれ実際のコードを取得、完全な深さで記述します。

選択したレベルを以降の全手順で維持します。

手順

1. その日の生データを収集する

選択した努力レベルでコレクターを実行します（ディスク上のすべてのセッション文字起こしを読み込むため、このセッションだけでなくすべての同時進行/終了済みセッションを取得します）。

python3 ~/.claude/skills/wong/collect_day.py --effort heavy

heavyを手順0で選択したレベルに置き換えます。過去の日付を記録する場合は日付を追加します：python3 ~/.claude/skills/wong/collect_day.py --effort medium 2026-06-25

このコマンドはダイジェストファイルへのパス（~/Daily Log/.digest-<date>.md）を出力します。そのダイジェストを完全に読み込んでください。 リポジトリごとに、その日のGitコミットマップ、未コミット変更の統計、セッションごとのユーザープロンプト、Claudeが編集したファイル、Claudeの説明文、サブエージェントの結果が含まれています。

用語集も~/Daily Log/.glossary.mdから読み込みます（存在しない場合は空として扱います）。過去の日付で既に説明された初歩的な用語がリストされています。手順4の「初歩用語は一度だけ説明」に従い、用語集にある用語は再度説明しません。

ダイジェストにアクティブなセッションがないと記載されている場合は、ユーザーにその旨を伝えて停止します。

2. 個別の機能・タスクを特定する

一日の作業を個別の作業単位にグループ化します。セッションごとに区切るのではなく、同じ機能を進めたセッションやコミットをマージします。「作業単位」とは、ユーザーが一つの明確な作業として指し示せるもの（例：「vertoエージェントの call-delivery バグ修正」「予測ダイヤラの放棄率上限設定」）です。実際に重要だった少数の項目を目指し、些事で水増ししないでください。

3. 各作業の実際のコードを取得する

努力レベルの制限: lightの場合はこの手順を完全にスキップします（git show/ファイル読み取りは行わず、ダイジェスト＋コミットメッセージを使用し、スニペットは最大1つ）。mediumの場合は最も重要な2～3件のみでこれを行います。heavyの場合はすべての作業で行います。

ダイジェストにはコミットSHAと編集されたファイルは記載されていますが、完全な差分は含まれていません。記録する各作業について、実際のコードを取得してスニペットが言い換えではなく本物になるようにします。

git -C <リポジトリ> show <SHA>            # コミットの完全な差分
git -C <リポジトリ> show <SHA> -- <パス>  # 1ファイルの差分
git -C <リポジトリ> diff -- <パス>        # 未コミットの作業

または、関連する行の現在のファイルを読み込みます。ファイル全体をダンプするよりも、アイデアを伝える重要な行を表示することを優先します。

リポジトリのCLAUDE.mdとdocs/GOTCHAS.md（存在する場合）を参照して、作業に関連する落とし穴を確認します — 「落とし穴と教訓」セクションに役立ちます。

4. 学習ガイドを書く — 増分的に、決して上書きしない

ファイル名の形式。 ファイルは~/Daily Log/に保存され、以下のように命名されます。

<YYYY-MM> - <DD> - <その日の作業内容を一行で>.md

例：2026-06 - 26 - Fixed agent call delivery and started Yotel 3D landing page.md 一行部分はその日の作業の短く平易な見出しです（日付の区切りに既に「 - 」を使用しているため、この部分にハイフンは含めません。約12語以内に抑えます）。ファイルの先頭# 見出しは、ファイル名から.mdを除いた文字列と同じでなければなりません。

今日のファイルを見つける（追記ロジックにとって重要）。 一行のサフィックスは変動するため、正確な<日付>.mdを探してはいけません。代わりに、日付のプレフィックスで今日のファイルを見つけます — ~/Daily Log/をリストし、<YYYY-MM> - <DD> - で始まるファイル（例：ls "~/Daily Log/" で2026-06 - 26 - で始まるものを選択）をマッチさせます。一日に最大1ファイルです。

このスキルは同じ日に複数回実行される可能性があります。初回以降の実行では、まだ記録されていない作業のみを追加し、既存の内容を上書きしたり重複させたりしないでください。

手順：

1. 今日のファイルが存在しない場合（日付プレフィックスに一致するファイルがない場合）：以下の完全な構造（一日の概要＋作業単位ごとのセクション、## 1.、## 2.…と番号付け）でファイルを作成し、上記の形式で命名します。
2. 今日のファイルが既に存在する場合（日付プレフィックスで見つかった場合）：まずそのファイルを読み込みます。既存の## N. <タイトル>見出しと各References行のコミットSHAやセッションIDをスキャンして、既にカバーされている内容のセットを構築します。次に、今日のダイジェストから、そのセットにまだ含まれていないコミットやセッションの作業単位を特定します。
   • ファイル名の一行要約を一日全体に対して正確に保つ： 新しく追加された作業によってその日の見出しが変わるべき場合は、ファイル名を変更し（# 見出しもそれに合わせて更新）、一日に行われたすべての作業を反映するようにします。見出しがまだ適切であれば、名前はそのままにします。
   • 新しい内容がない場合は、ファイルは既に最新であることをユーザーに伝えて停止します（書き換えはしません）。
   • それ以外の場合は、新しい作業のみについて、既存の番号を続けて新しい## N.セクションを追加し、各機能のテンプレートを使用します。
   • Day overviewブロックをその場で更新します：コミット数/セッション数を増やし、見出しを拡張して新しく追加された作業に言及します。既存の機能セクションには触れません。
   • 完全な上書きではなく編集（ターゲットを絞った挿入）を使用して、以前のセクション（手動で編集したものを含む）がそのまま保持されるようにします。

「作業単位」は、そのコミットSHAやセッションIDがファイル内に既に出現していればカバー済みと見なします。表現ではなくこれらの識別子でマッチさせることで、再実行時にほぼ重複したセクションが生成されるのを防ぎます。

記述スタイル — 必須（これが本質です）

完全な初心者向けの教科書の章のように書いてください — 賢いがソフトウェアについては何も知らない読者を想定します。読者は事前知識なしで各セクションを最初から最後まで追える必要があります。

• 会話調でシンプルに。 短い文。平易な言葉。レポートを書くのではなく、友人に話すように説明します。ナラティブ内の専門用語は避けます。
• 各技術用語はシリーズ全体で一度だけ定義する — 一日ごとに定義しない。 用語がこれまでに初めて登場する場合、日常言語で説明を引用ボックスで示します：> **「X」の意味。** …（現実世界のアナロジーを使用）。ただし最初に用語集（~/Daily Log/.glossary.md）を確認し、既にリストにある用語は再定義しないでください。 これは初歩的で繰り返し登場する基礎用語（リポジトリ/コミット/ブランチとは何か、Yotelとは何か、基本的なGit）に最も重要です — 一度説明したら、その後は単に使用します。今日の作業に本当に中心的な全く新しい用語には引き続き説明ボックスを付けますが、以前にカバーされた基本用語には付けません。メカニズムについては「初歩用語は一度だけ説明」を参照してください。
• 技術的に正確であるべき箇所でのみ技術的に留める — 例えば実際のコード変更、正確なファイル、実際のトレードオフ。実際のコードを示しますが、その前後に平易な英語の説明を付け、スニペットには平易な言葉でコメントを付けます。コードをただダンプするだけにしてはいけません。
• 各セクションは「日常バージョン」でリードする — 何が壊れていたか/何が必要だったか、なぜそれが重要なのかの平易な言葉でのストーリーを、技術的な詳細の前に記述します。
• 先頭に短い**「この文書の読み方」** ノートと、「全体像（これを最初に読んでください）」 の概要（プロダクトは何か、誰が使うか、なぜか）を平易な言葉で記述します。
• 「説明の仕方」のポイントは、平易で自信に満ちた一文で示し、その後に一つの賢い洞察を簡単に説明します。
• 正直に：実際に出荷されたコードとセットアップ/探索を明確に区別し、平易な言葉でそう述べます。

既存の最新ファイルがあれば、~/Daily Log/内のそのファイルのトーンに合わせます（存在する場合はそれを参考例として読み込んでください）。

初歩用語は一度だけ説明（用語集）

シリーズ全体を読む読者は、「リポジトリとは何か」や「Yotelとは何か」を毎日再説明されるべきではありません。そのため：

1. 書く前に、 ~/Daily Log/.glossary.md（既に説明された用語のリスト）を読みます。リストにあるものはすべて既知として扱います — リスト上の用語に対して> **「X」の意味。**のボックスを書かないでください。 単に用語を通常通り使用します。
2. 書きながら、 シリーズで本当に新しい（用語集にない）用語にのみ定義ボックスを追加します。初歩的な基礎の再定義には強く反対し、基本用語について迷った場合はカバー済みと見なしてスキップします。
3. 書き終えた後/追記した後、 ~/Daily Log/.glossary.mdを更新します：今日初めて定義した用語を（一行につき一つ）追加します。既存のエントリは削除しないでください。ファイルが存在しない場合は作成します。

これは何よりも初歩的で繰り返し登場する用語（リポジトリ、コミット、ブランチ、ワークツリー、プロダクトとは何か、基本的なGit）に適用されます。ある日の作業の核心である複雑な用語はその日に説明できますが、一度用語集に入った後は再度説明されません。

機能ごとのテンプレートと一日の概要の構造（見出しは上記の初心者向けの声に合わせて適応してください — 以下は、厳格なラベルとしてそのままコピーするのではなく、カバーすべき内容を示しています）：

# <YYYY-MM> - <DD> - <その日の作業内容を一行で>

> **この文書の読み方。** （初心者に使用方法を伝える1～2文）

## 全体像（これを最初に読んでください）
今日行われたことの平易な言葉での概要。「プロジェクト/リポジトリ」、「コミット」、プロダクト（例：Yotel）とは何かを**用語集にまだない場合のみ**ここで定義します — つまり最初のログのみ。以降の日では、これらの基本と「このプロダクトは何か」の説明をスキップし、単に名前を挙げて進みます。

---

## 1. <作業の平易なタイトル>   （<リポジトリ>）

### 日常バージョン
専門用語なしのストーリー — 何が壊れていたか、何が必要だったか、なぜそれが現実の人間にとって重要なのか。アナロジーを使用します。

### 実際に何が起こっていたか / 修正（技術的な部分）
ここで正確な詳細：実際の原因、実際のコード変更（表示し、平易な英語で説明し、コメント付きスニペットを添える）、正確なファイルパス。新しい技術用語の前に`> **「用語」の意味。**`ボックスを置きます。

### 自分で行う方法（ステップバイステップ）
初心者が従える番号付きの具体的な手順。

### 説明の仕方（理解したら）
- 作業が何をするかの平易な一文の要約。
- 一つの賢い洞察を簡単に説明。
- 守るべきトレードオフを日常的な言葉で。

### 覚えておく価値のある教訓
平易な言葉での学び＋CLAUDE.md / docs/GOTCHAS.mdからの関連する落とし穴。

**どこで見つけられるか：** ファイル、コミットSHA、セッションID。

---

## 2. <次の作業…>

---

## 今日使ったGitスキル
（常に文書の**最後**のセクション。ダイジェストの「Claudeが実行したGitコマンド」ブロックから構築 — 以下の専用指示を参照。）

### <Git操作、例：変更のコミット>   `git commit`
**何をしたか** — 平易な言葉で、このコマンドが今日の作業で何を達成したか。
**なぜ** — なぜこの手順がその時点のワークフローで必要だったか。
**自分で行う方法** — 実際のコマンドと、各部分と重要なフラグの意味の短いメモ。読者が手動で実行できるように。

### <次のGit操作…>

「今日使ったGitスキル」セクション — 必須（常に最後のセクション）

毎日の文書を**## 今日使ったGitスキルセクションで終えます。ダイジェスト内の「Claudeが実行したGitコマンド」**ブロック（セッションごとに1ブロック）から構築します。

構築方法：

1. ダイジェスト内のすべてのセッションからすべてのGitコマンドを収集します。キャプチャされたエントリは複合コマンド（例：cd repo && git add ... && git commit ...）の場合があります。Git部分を取り出します。
2. Git操作ごとにグループ化します（例：コミット、ブランチ作成、ワークツリー作成、プッシュ、ステージング、スタッシュ、復元、リベース、log/diff/show/statusでの調査）。異なる操作ごとに1つのサブセクション — 同じ操作を何度もリストしないでください。多くのコマンドが読み取り専用の調査（git status、git log、git diff、git show）である場合は、それぞれ1つずつではなく、短い「リポジトリの確認」サブセクションにまとめます。
3. 各操作について、文書の他の部分で使われている初心者向けの声で3つのことを書きます：
   • 何をしたか — 今日の実際の作業でこれが何を達成したか。
   • なぜ — なぜその手順がその時点で必要だったか。
   • 自分で行う方法 — 実際のコマンドと、各部分と重要なフラグの意味の平易なメモ。読者が手動で実行できるように。 最初の使用前に> **「X」の意味。**ボックスを置きます