show-me-your-work

作業内容を記録する

正規ログを1つだけ保ちます。

形式

判断ごとに1行を記録する、単一のTSVファイルです。セルは1行に収めます。エビデンスには説明文ではなく参照先を記載します。ヘッダー行は次のとおりです。

ts	phase	decision	why	evidence	result

• ts. ISO8601形式のタイムスタンプ。
• phase. フェーズまたは作業ストリーム。
• decision. 選択または実施した内容を1行で記載します。
• why. 平易な言葉で理由を記載します。原則に基づく判断であれば、専門用語のタグではなく、明確に説明します。
• evidence. 判断の根拠となるリンクまたはパス：コミットSHA、PR番号、file:line、成果物またはスクリーンショットのパスなどです。段落は記載しません。
• result. 結果または条件の状態：tests green、reverted、INCONCLUSIVE、open。

レビュー担当者が一目で読めるよう、平易な言葉で書いた例です。

ts	phase	decision	why	evidence	result
2026-05-24T09:02:00Z	frame	counted the work first, 40 resources still on the old inventory exports	wanted to know the size before starting a long run	commit 3a9f1c2	found 3 resources that wrap the exports in their own bridge
2026-05-24T09:40:00Z	harness	wrote a script listing every call to the old exports before changing anything	so we can compare old against new and catch a missed call	scripts/find-old-exports.sh	baseline of 212 calls saved
2026-05-24T11:15:00Z	shops	moved the shop resource to the new exports	keep each resource's change small and checkable on its own	commit 7c21e0a	0 old calls left in shops, lua-language-server --check clean
2026-05-24T12:30:00Z	garages	threw out a helper's work because it skipped two files	checked the real diff instead of trusting its summary	worktree reset	reverted, tightened the instructions for next time

行の記録

各エントリーは、同僚に実施内容を伝えるように書きます。平易な言葉で、具体的な作業を記載し、専門用語は使いません。

このスキルのディレクトリにあるヘルパー scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result> を使います。ts を付与し、初回使用時にヘッダーを書き込み、余分なタブと改行を除去します。また、スプレッドシートで数式として実行されないよう、セルが =、+、-、@ のいずれかで始まる場合は、先頭にシングルクォートを1つ付けます。printf で行を直接追加する方法も使えますが、セルに生成テキストやユーザー提供テキストを使う場合は、同じ文字に注意してください。

すべての作業ではなく、判断の節目やチェックポイントを記録します。たとえば、選択した分岐、検証結果を伴う完了済みの単位作業、きっかけを明記した方針転換や取り消し、明らかになったブロッカー、修正したゲートなどです。ループを実行する場合は、反復ごとに1行記録します。些細なことや自明なことは省きます。

1回の実行とは、その後のターンやその要約も含めた、エージェントとの1回の会話です。作業の引き継ぎ、エージェントの交代、新しいチャットは、それぞれ新しい実行として扱います。既存の行があるログに実行内容を追加する場合、その実行の最初の行のフェーズは start にします。また、別の実行の start 行の後に追加する最初の行も同様です。そのため、後のターンでログへの記録を再開する実行では、まずログの末尾を読み、別の実行による書き込みがあったかを確認します。start 行には、この実行が書き込んでいない直前の行の ts 範囲を記載し、エビデンスにはこの実行のセッションIDなどを記載します。フェーズ start はそれ以外の用途には使いません。

保存場所

デフォルトでは、ログは作業成果物であり、コミットしません。作業ディレクトリの decisions.tsv、または複数の作業を同時に進める場合は .audit/<task-slug>.tsv に保存し、Gitの対象外にします。

作業の規模が大きく、レビュー担当者が結果を信頼するために経緯を必要とする場合に限り、コミットします。

ルール

• 追記のみとします。判断を誤った場合は、それを置き換える新しい行を追加します。履歴を編集したり削除したりしてはいけません。
• principles スキルの「構造による教訓の記録」に従い、手作業で一度限り作成したものより、コミット済みスクリプトが生成したエビデンスを優先します。

トランスクリプトとログの照合

実行の最後に、作業を引き渡す前に、ログが事実を記録しているか確認します。この実行のトランスクリプトを読みます。Claude Code の場合は、~/.claude/projects/ 配下にあるセッションの .jsonl ファイルを読みます。Codex の場合は、~/.codex/sessions/ 配下のファイルを読みます。T3 Code の場合は、view: "activity" を指定して t3_thread_read を呼び出し、hasMore が false になるまで nextPosition をたどります。この実行の開始プロンプトを検索して、セッションを見つけます。この実行のセッションだけを読みます。他のセッションには、無関係な個人的なチャットが含まれています。この実行の各行を、実際に起きたことと照合します。各まとまりは、この実行の start 行、またはこの実行でログが作成された場合は最初の行から始まり、別の実行の次の start 行で終わります。

• 各行が実際の判断またはアクションに対応しているか確認します。
• 各行の根拠をたどれ、行の主張を裏付けているか確認します。
• 作業の方向を決めた分岐、方針転換、断念したアプローチが記録されていなければ、抜け漏れです。追記します。

修正するのはログであり、経緯ではありません。監査では、行の編集や削除は行いません。ある行が実際の判断もアクションも記録していない場合、または主張や根拠が誤っている場合は、実際に起きたことと解決可能な参照先を記した行を追加し、その行に優先させます。この監査では、この実行のまとまり以外の行は確認しません。この実行の作業によって、まとまり外の行に誤りがあると分かった場合は、同様に優先行を追加します。

作業履歴のクロスモデルレビュー

作業を引き渡す前に、~/.config/ox/models.md の review 行で指定されたモデルを使い、「Trail reviewer」という名前のサブエージェントを 1 つ起動します。その行に作業を行ったモデルが指定されている場合は、自己レビューでは代用できないため、別のモデルファミリーの panel エントリーを使います。異なるモデルがどちらにもない場合は、自分と同じモデルで実行し、その旨を Attention セクションに記載します。依頼文にはログの絶対パスとトランスクリプトの場所を記載し、「読み取り専用：確認のみ。書き込みや git コマンドは禁止」と「委任しない」と明記します。サブエージェントは作業履歴とトランスクリプトを読み、ユーザーが注意すべき点を指摘します。作業のやり直しではなく、最適でない点やリスクを確認します。

• 根拠が弱い、または存在しない状態で記録された判断。
• 検証手順が省略されている、またはトランスクリプトに証拠がないのに実施したと記録されている箇所。
• 後から見るとリスクがある選択（早すぎる判断、スコープの拡大、症状の取り繕いなど）。
• ざっと目を通しただけではユーザーが見落としそうな抜け漏れ。

作業履歴を作成した実行の返信には、必ず末尾に「Attention」セクションを付けます。最初の行にレビュー担当のモデルを記載します（reviewed by <model>）。続いて、該当する行や箇所を示しながら、各指摘を列挙します。「指摘なし」も有効な値ですが、モデル名は必ず記載します。

作業履歴のレビュー

上から順に読み、根拠の参照先をたどり、いくつかを抜き取り確認します。コミット済みの TSV は GitHub 上で表として表示されます。ターミナルでは column -s$'\t' -t decisions.tsv で表示できます。

このスキルの作成

他のスキルでは独自の監査ログ形式を作らず、監査ログをここに委ねます。このスキルを名前で参照し、フォーマットの定義はここに任せてください。列を重複して記載しないでください。