Git Worklog
リクエストされた期間の実際のGit差分と周辺コードを読み取ってプロジェクト作業ログ（個人レポートではありません）を生成し、.git-worklog/ の下に1日1つのMarkdownファイルを作成し、.git-worklog/index.md を更新します。手動で追加されたノートは保持されます。
決定的な処理（日付計算、Git収集、Markdown編集、プレビューの整合性）は git-worklog CLI と scripts/ 内のスクリプトが行います。判断を要する処理（コードを読んで実際の変更を判断し、サマリーを書くこと）は、あなたと日別サブエージェントが行います。コミットメッセージを差分を読む代わりに決して使わないでください。
python3 と git が利用可能である必要があります。インストールは不要です。CLI は python3 -m git_worklog <command> として実行し、スクリプトは python3 scripts/<name>.py として、このディレクトリから実行します。各コマンドは標準出力に1つのJSONオブジェクトを出力します。終了コード 0 は正常、1 は実行されたが問題が見つかった、2 は実行できなかったことを示します。
0. 黄金のルール
- パラメータなし → メニューを表示して停止。 ユーザーが範囲を選択するまで、Gitをスキャンしたり、サブエージェントを起動したり、何かを生成したりしないでください。
- メッセージだけでなくコードを読む。 関連するすべてのコミットの実際のパッチと周辺コードコンテキストを読む必要があります。
references/code-analysis-rules.mdを参照してください。これはレポートモードでも同様です。該当日に作業ログがない場合、コミットメッセージはその代わりにはなりません — ギャップを明らかにして質問してください。 - プロジェクト全体、すべての著者。 作業ログは常にすべての著者を保存します。
git config user.name/emailでフィルタリングしないでください。レポートモードでは、ユーザーが明示的にその人を指定した場合にのみ著者でフィルタリングできます — 「我」が誰かを推測しないでください。 - 生成とバックフィルは最大30暦日。 この上限は日別サブエージェントのコストを抑制します。レポートモードは既存の日付ファイルを読み取るのみでサブエージェントを起動しないため、最大90日（
--max-days 90）まで読み取ります。いずれの場合も、制限を超えた場合は拒否し、リクエストされた日数を表示し、ユーザーに範囲を狭めるよう依頼してください。決して黙って切り詰めないでください。 - 常に最初にドライラン。 有効なリクエストは常にプレビューのみを生成します。ユーザーが明示的に確認した後にのみ書き込みます。
- 1日1ファイル。インデックスはナビゲーション。 各日は
.git-worklog/days/<date>.mdです。ある日の再分析が別の日のファイルに影響を与えることはありません。index.mdは日付ファイルから再構築されます。 - すべての日のMANUAL領域とインデックスのMANUAL領域を永久に保持します。
- 決して
git add/commit/push/fetch/pull/checkout/switch/merge/rebaseを実行しないでください。
1. トリガーと引数なしメニュー
/git-worklog または自然言語による作業ログリクエストでトリガーされます。
使用可能な引数なしで呼び出された場合、このメニューをそのまま表示して待機します — 他には何もしません：
請選擇要整理的專案工作日誌範圍：
1. 今天
2. 指定日期
3. 最近 7 天
4. 最近 30 天
5. 自訂日期範圍
6. 今天，並包含尚未提交的異動
7. 自訂日期或範圍，並包含尚未提交的異動
日期範圍最多為 30 天。
所有操作都會先顯示 dry-run 預覽，不會直接修改專案檔案。
你可以直接輸入選項編號，或用自然語言回答，例如：
- 整理今天
- 整理 2026-07-01
- 整理最近 7 天
- 整理 2026-07-01 到 2026-07-10
- 整理今天並包含未提交異動
- 整理近 30 天
オプション番号は次のように対応します： 1→今日、2→日付を尋ねる、3→days=7、4→days=30、5→開始日と終了日を尋ねる、6→今日 + include_uncommitted、7→日付/範囲を尋ねる + include_uncommitted。
完全なメニュー、オプション、確認処理： references/interaction-flow.md。
1a. ルーティング：生成かレポートか
2つのモードがあります。他のことをする前に決定してください。
| ユーザーの希望 | モード | 遷移先 |
|---|---|---|
| 作業ログ自体の構築または補完 — 「整理今天」「整理最近 7 天」「補 7/1 的日誌」 | 生成（書き込み） | §2 以降 |
| 履歴から引き出した回答 — 「整理上一週工作摘要」「整理 v1.0.1 CHANGELOG」「Daniel 上個月做了什麼」「目前有哪些技術債」 | レポート（読み取り専用） | references/report-mode.md |
判断基準：生成モードの成果物はファイルです。レポートモードの成果物は会話内の散文です。「整理今天」は日付ファイルを求めています。「整理上一週的工作摘要」はステータス更新に貼り付けるものを求めています。真に曖昧な場合は質問してください — 推測でファイルを書き込まないでください。
レポートモードは既存の日付ファイルとGitを読み取り、何も書き込まないため、ドライランや確認ゲートはありません。唯一の書き込みパスはギャップのバックフィルであり、その場合、該当する日付について§§2–8に戻り、ドライランと確認が含まれます。
メニューは生成専用です。 レポートモードは自然言語または明示的なパラメータによって到達し、オプション番号では決して到達しません — メニューは「どの範囲を構築するか」を尋ねますが、これはレポートモードが答える質問ではありません。
2. 入力を正規化 → 標準パラメータ
あなた（モデル）は自然言語を標準パラメータに変換します。スクリプトは自由テキストを解釈しません。標準パラメータ：
date · days · from · to · include_uncommitted、およびショートカット 7d、30d、裸の YYYY-MM-DD。
- 「整理今天」 →
date=<ローカルの今日> - 「最近一週」 →
days=7；「近一個月」 →days=30（常に30、月の長さではありません） - 「7 月 1 日到 7 月 10 日」 →
from=2026-07-01 to=2026-07-10 - 「包含未提交 / 連 working tree 一起」 →
include_uncommitted=true
date / days / from+to モードは相互に排他的です。正規化ケース： references/date-parameter-contract.md。
2a. 出力言語の解決（ロードマップ §6.2）
これはあなたの仕事であり、スクリプトの仕事ではありません。 優先順位の最上位はこの会話の中にのみ存在します — ユーザーが何を求めたか、あなたがどの言語で話しているか、ホストが何に設定されているか。スクリプトはそのいずれも見ることができず、--language はあなたがそれを伝える方法です。実行ごとに1回解決し、同じタグをすべての場所にスレッドしてください。
優先順位（高い順）：
- このリクエストでユーザーが求めたもの — 「用英文整理」 →
en。常に優先されます。 .git-worklog/config.jsonのプロジェクトのlanguage。ただし、autoでない場合のみ。スクリプトはこれらを自分で読み取ります。--language autoを渡して任せてください。- このユーザーとの会話で使用している言語、つまりホストの言語。 これが通常のケースであり、実際の回答です。それを
--language-source agent-hostとともに渡してください。
次に、どのソースから解決したかを示す --language-source も渡します。これにより、マニフェストは何がだけでなくなぜかを記録します：
| 解決元 | --language-source |
|---|---|
| このリクエストでユーザーが言語を要求した場合 | user-request |
| この会話/あなたのホストの言語 | agent-host |
| 特に指定なし — config と env に任せる | 省略、--language auto を渡す |
リポジトリに選択させないでください。 英語のコミットメッセージ、英語の識別子、英語のコメント、英語のREADMEは何も決定しません。完全に英語のリポジトリでも、zh-TW の会話は zh-TW の作業ログを生成します。コードベースに「合わせよう」としないでください。また、この英語の SKILL.md をヒントとして読まないでください。
OSロケールから推測しないでください。 あなたはエージェントホストで実行されており、--language はまさに、コンテナが en_US に固定されている場合に中国語を話すユーザーを上書きしないようにするためのメカニズムです。スクリプトはあなたのためにロケールを参照しません（§6.2.5）。それは意図的であり、埋めるべきギャップではありません。
実行のマニフェストに source: "fallback" と LANGUAGE_NOT_RESOLVED 警告が返ってきた場合、言語を渡せておらず、実行は英語で書き込まれようとしています。それを受け入れるのではなく、明示的な --language で再実行してください（§6.2.14）— ただし、英語が本当に正しい場合を除きます。
レポートは作業ログと異なる場合があります。 日付ファイルは、それを生成した実行の言語で書き込まれます。レポートは、それを要求したリクエストの言語で書き込まれます（§6.2.11）。zh-TW の日付ファイルを読んで英語のリリースノートを生成することは正しく、ディスク上の何も変換する必要はありません。
翻訳しないでください： ファイルパス、コードシンボル、コミットハッシュ、API/クラス/パッケージ名、ブランチやイシューの参照、evidence[] 内のすべて。出力言語で用語を説明することは歓迎しますが、名前を変更することはしません。
3. 日付範囲の検証（常に最初）
python3 scripts/resolve_date_range.py <args> [--timezone <IANA>] [--today <YYYY-MM-DD>]
標準パラメータを渡します。例：--days 7、--date 2026-07-01、--from 2026-07-01 --to 2026-07-10、または 7d のようなショートカット。リクエスト時に --include-uncommitted を追加します。
ok:falseの場合、エラーをユーザーに報告して停止します。一般的なコード：TOO_MANY_DAYS（requested_daysを表示、範囲を狭めるよう依頼）、ARG_CONFLICT、DAYS_OUT_OF_RANGE、INVALID_DATE、FROM_AFTER_TO、TO_WITHOUT_FROM。ok:trueの場合、dates[]（各要素はdate、start、endの半開区間を持つ）、timezone、timezone_sourceを保持します。timezone_sourceがsystem-offset（IANA名なし）の場合、想定されるオフセットをユーザーに伝え、設定するよう提案します。
タイムゾーンの優先順位と半開 [00:00, 次の 00:00) の1日ルール： references/date-parameter-contract.md。
4. リポジトリ状態の検出
python3 scripts/collect_git_history.py --repo <root> --info-only
NOT_A_GIT_REPO→ このディレクトリがGitリポジトリではないことをユーザーに伝えて停止します。root、branch（detached_headの場合は null）、head/short_head、has_commits、dirty_worktreeを記録します。これらはドライランサマリーに表示されます。- 空のリポジトリ（
has_commits:false）：include_uncommitted=falseの場合、記録するものはありません — その旨を伝えます。include_uncommitted=trueの場合、ワーキングツリーのみを分析します。
5. 日別分析 — 1日1つのDay Subagent
このセクションを挟む2つのコマンドがあります。analyze prepare は何を分析すべきか、どの言語で分析すべきかを決定します。analyze collect は返された結果を信頼するかどうかを決定します。その間のすべて — パッチの読み取り、コードの理解、散文の作成 — はあなたとサブエージェントの仕事です。CLIは決してそれを行わず、モデルAPIキーも必要ありません。
5a. 実行の準備（決定的、範囲全体で1回）：
python3 -m git_worklog analyze prepare --repo <root> \
--from <最初の日付> --to <最後の日付> --timezone <tz> \
--language <タグ|auto> --language-source <ソース> \
--provider <プロバイダ> --model-json '<モデルオブジェクト>' \
[--include-uncommitted]
run_id、run_dir、tasks[] を返します。各タスクは暦日ごとに1エントリで、それぞれに manifest_path（分析対象）と result_path（分析結果の書き込み先）があります。すべてを保持します。
--language と --language-source は §2a から来ます。これらはここで1回解決され、実行内のすべてのマニフェストにスタンプされます。マニフェストの language.resolved は、各日の結果がチェックされる対象であり、これに同意しない日は実行全体をブロックします。
<provider> と <model object> は、scripts/resolve_provider_model.py --host <anthropic|openai|google> で実行全体で1回解決します（以下のモデルテーブルを参照）。model はオブジェクトです — {display_name, model_id} に加え、openai の場合は reasoning_effort。
各マニフェストは、file_groups（実際の作業領域ごとにグループ化）、required_context、analysis_rules、大規模な日の場合にCode Analysis Subagentを推奨する large_day フラグ、parts_dir（ファンアウトのパーツの格納先 — 決してその日の結果の横ではありません、以下参照）、required_commit_file_pairs（§5b）、およびその日の著作者情報 — authors[]（個別の名前、最初の出現順）と commits[].author_name を提供します。參與者 行と各 相關 commits エントリの著者をこれらから直接レンダリングします。サブエージェントは帰属を返しません。
大規模な日のファンアウトは、グループごとのパーツを parts_dir に書き込みます。決してその日の result_path の隣には書き込みません。results/ は実行の回答を保持し、collect はそこにある要求されていないファイル（unknown）に対して実行を失敗させます。したがって、result_path の兄弟を派生させるファンアウトは、扱いやすくするために作られたその日自体をブロックします。
パッチはマニフェストにありません — サブエージェントは git show でそれらを読み取ります。
5b. 各日に求められるもの。 すべてのマニフェストは required_commit_file_pairs をリストします。各 (commit, file) ペアは、その日が触れたもので、required かどうかがフラグ付けされています。Required は、その日の分析がそのファイルを扱う必要があることを意味します — ワークアイテムの files[] でファイルを指定するだけで十分です。evidence[] での引用はより強力ですが必須ではありません。ソースファイルのみが必須です。ドキュメント、設定、CI、テスト、バイナリ、削除されたファイルはリストされますが、免除されます（削除されたファイルはそのコミットのツリーから存在しないため、引用できません）。
分析が決して言及しない必須ファイルは、その日を §5d で失敗させます。これは衒学ではありません。変更されたが説明されなかったファイルは、読まれなかった可能性があり、それはそうでなければ自信があるように見える結果では見えません。
5c. 各日に1つのDay Subagentを起動し、その manifest_path と result_path を渡します。サブエージェントは実際の差分と十分なコードコンテキストを読み、その日の終わりの状態（同じ日に追加されて元に戻された機能はライブ変更ではありません）を判断し、references/subagent-contract.md の構造化JSONをそのパスに書き込み、DONE とのみ返します。結果は返信テキストとして決して返されません。これは結果をドロップまたは切り詰めるためです（references/subagent-contract.md §6a）。作業ログに書き込んではいけません。コミットのない日でも has_changes:false を書き込みます。
5d. すべての日の結果を収集（決定的）、すべてのサブエージェントが完了したら：
python3 -m git_worklog analyze collect --run-id <run_id> --repo <root>
ここでは日付や言語は指定しません。collect は実行自身のマニフェストを読み取るため、コマンドラインから日付を省略してチェックを逃れることはできません。以下を報告します：
complete/degraded/missing/invalid/unknown/failed_dates、results（日付 → オブジェクト）、partial_run、escalation_suggested_dates。missingまたはinvalidの日付は失敗した日であり、空の日ではありません — 「何も起こらなかった」として扱ったり、そのコミットメッセージにフォールバックしたりしないでください。unknownは、実行が要求しなかった結果ファイルです。マージしないでください。partial_run:trueはデフォルトで適用をブロックします（§9）。終了コードは1です。
すべての結果がチェックされる3つの事項があり、それぞれがその日を失敗させます：
- 言語 — タグはマニフェストが要求したものでなければなりません。
- 証拠の正確性 — すべてのエントリは、それが引用するコミットのツリーに対してチェックされます。コミットが存在し、そのコミットでファイルが存在し、
symbolがその中に出現し、lines範囲がその内部にあること。migrate_directoryをparse_legacyという関数に対して引用するサブエージェントは、あなたが追跡できる情報を何も提供していません（#15）。シャロークローンで到達不可能なコミットはEVIDENCE_UNVERIFIABLEを報告します...
...（翻訳のため省略）