show-me-your-work

作業内容を記録する

正本となるログを1つだけ維持します。

形式

1つのTSVファイルに、判断ごとに1行を記録します。セルは1行のままにします。エビデンスは説明文ではなく、参照先を記載します。

references/decision-log-template.tsv（ヘッダー行）をコピーして、空のログを作成します。列は次のとおりです。

• ts. ISO8601形式のタイムスタンプ。
• phase. フェーズまたは作業ストリーム。
• decision. 選択したこと、または実行したことを1行で記載します。
• why. 理由を平易な言葉で記載します。原則が判断の根拠なら、専門用語のタグではなく、分かりやすく記載します。
• evidence. 内容を裏付けるリンクまたはパス：コミットSHA、PR番号、file:line、成果物、トレース、スクリーンショットのパスなど。段落は記載しません。
• result. 結果または判定状態：tests green、reverted、pixel-diff 0、INCONCLUSIVE、open。

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

ts	phase	decision	why	evidence	result
2026-05-24T09:02:00Z	frame	counted the work first, about 100 components and roughly 75 hours	wanted to know the size before starting a long run	commit 3a9f1c2	found 5 things to sort out before starting
2026-05-24T09:40:00Z	harness	took screenshots of the old version before changing anything	so we can compare old against new and catch any visual change	scripts/snapshot.sh, baseline/	saved 120 reference screenshots
2026-05-24T11:15:00Z	widget	moved the widget styles over without changing how it looks	keep the change small and the result identical	commit 7c21e0a, pixel-diff 0	looks identical, tests pass
2026-05-24T12:30:00Z	widget	threw out a helper's work because its screenshots were blank	checked the real files instead of trusting its summary	worktree reset	reverted, tightened the instructions for next time

行の記録方法

各項目は、実行した内容をチームメイトに伝えるように記載します。平易な言葉で、具体的な行動を記し、AIらしい表現や抽象的な専門用語は使いません（ログのテキストにも unslop スキルを適用します）。

ヘルパー scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result> を使用します。このスクリプトは ts を設定し、初回使用時にヘッダーを書き込み、余分なタブや改行を取り除き、=, +, -, @ のいずれかで始まるセルの先頭にシングルクォートを付けます。printf で行を追加してもかまいませんが、生成テキストやユーザー提供テキストをセルに使う場合は、同じ文字に注意してください。

すべての行動ではなく、判断の分岐点やチェックポイントを記録します。選択した分岐、検証結果を伴うユニットの完了、きっかけとともに記録する方針転換や取り消し、明らかになった阻害要因、修正したゲートなどです。ループを実行する場合は、反復ごとに1行記録します。些細なことや自明なことは省きます。

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

保存場所

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

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

ルール

• 追記のみです。誤った判断は、新しい行で置き換えます。履歴を編集または削除してはいけません。
• 手作業で一度限り作成したものより、コミット済みスクリプトで生成したエビデンスを優先します（encode-lessons-in-structure 原則のスキル）。

トランスクリプトと照合してログを監査する

実行の終了時に、引き継ぐ前に、ログの内容が事実に即しているか確認します。Claude Codeのプロジェクトごとのトランスクリプトディレクトリ ~/.claude/projects/<encoded-cwd>/ で、この実行のトランスクリプトを読みます。~/.claude/projects/ 全体を対象にglob検索してはいけません。無関係なプライベートチャットまで読み込んでしまいます。この実行の各行を、実際に起きたことと照らし合わせます。この実行の各記録区間は、この実行の start 行（この実行がログを新規作成した場合は最初の行）から始まり、別の実行の次の start 行で終わります。

• すべての行が、実際の判断または行動に対応していることを確認します。
• 各行のエビデンスが参照可能で、記載内容を裏付けていることを確認します。
• 作業に影響した分岐、方針転換、断念したアプローチが記録されていなければ、それは漏れです。追加します。

修正するのはログであり、ストーリーではありません。監査で行を編集または削除してはいけません。事実に反する行であっても同様です。行が実際の判断や行動を記録していない場合、またはその主張やエビデンスが誤っている場合は、実際に起きたことと、参照可能な参照先を記した行を追加して、その行を置き換えます。この監査の対象は、この実行の記録区間外の行には及びません。この実行の作業から、それらの行が誤りだと分かった場合は、誤った判断と同様に、新しい行で置き換えます。

トレイルのクロスモデルレビュー

結果を引き渡す前に、作業を行ったモデルファミリーとは異なるモデルファミリーのサブエージェントを起動してください。セルフレビューで代用することはできません。サブエージェントは監査トレイルと実行のトランスクリプトを読み、ユーザーが注意すべき点を指摘します。作業をやり直すのではなく、最適でない点やリスクのある点を確認します。サブエージェントにかける労力は、「Subagents」セクションに従って、作業に応じて選んでください。

• 根拠が乏しい、または根拠のない決定。
• 検証手順が省略されている、またはトランスクリプト内に証拠がないまま実施済みとされている箇所。
• 後から見るとリスクがあるように思える選択（時期尚早、スコープの逸脱、症状の取り繕い）。
• ざっと目を通しただけではユーザーが見落としそうな不足点。

トレイルを生成した実行のすべての返信は、末尾に「Attention」セクションを付けます。最初にレビュー担当モデル名を単独の行に記し（reviewed by <model>）、続けて該当する行や箇所を具体的に示しながら、各指摘を列挙します。「No flags」も有効な値です。モデル名は有効な値ではありません。

トレイルのレビュー

上から順に読み、根拠への参照をたどってスポットチェックします。GitHub では、コミットされた TSV がテーブルとして表示されます。column -s$'\t' -t decisions.tsv を実行すると、ターミナルに表示できます。

このスキルの作成

他のスキルでは独自の形式を考案する代わりに、監査トレイルをここにルーティングします。名前で参照し、形式はこのスキルに任せてください。列を再掲しないでください。