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 を記録し、初回使用時にヘッダーを書き込み、余分なタブや改行を取り除き、=, +, -, @ で始まるセルの先頭にシングルクォートを1つ付けます。行を追加するために printf を直接使うこともできますが、セルに生成テキストやユーザー提供テキストを使う場合は、同じ文字を処理してください。

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

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

保存場所

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

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

ルール

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

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

実行の最後に、結果を引き渡す前に、ログに事実が記録されているか確認します。アクティブなワークスペースのセッションディレクトリから、この実行のトランスクリプトを読みます。Cursor では、システムプロンプトで指定された agent-transcripts/ ディレクトリです。Claude Code では ~/.claude/projects/<slug>/（ワークスペースのパスで、英数字以外の各文字を「-」に置き換えたもの）です。Pi では ~/.pi/agent/sessions/--<slug>--/ です。Codex では、最初の行の payload.cwd がワークスペースのパスと一致する ~/.codex/sessions/ 内のファイルです。すべてのプロジェクトのディレクトリを対象にグロブ検索してはいけません。無関係なプライベートチャットまで読み込んでしまいます。この実行の行を、実際に起きたことと照合します。各まとまりは、この実行の start 行のいずれか、またはこの実行でログを作成した場合は最初の行から始まり、別の実行の次の start 行で終わります。

• すべての行が実際の判断またはアクションに対応しているか確認します。
• 各行の根拠をたどれること、また、その根拠が記載内容を裏付けていることを確認します。
• 作業に影響したものの記録されていない分岐、方針転換、断念したアプローチがあれば、それは抜けです。追加します。

ストーリーではなく、ログを修正します。監査では、行を編集したり削除したりしてはいけません。行に実際の判断もアクションも記録されていない場合や、記載内容または根拠が誤っている場合は、実際に起きたことと、たどれるポインターを記した行を追加し、その行に置き換えます。この監査では、この実行のまとまり以外の行は確認しません。この実行の作業から、範囲外の行の誤りが判明した場合は、誤った判断と同様に置き換えます。

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

結果を引き渡す前に、作業を行ったモデルとは異なるモデルファミリーのサブエージェントを起動します。自己レビューで代用してはいけません。サブエージェントは監査トレイルと実行のトランスクリプトを読み、ユーザーが注意すべき点を指摘します。作業をやり直すのではなく、最適でない点やリスクのある点を確認します。poteto-mode スキルの「Subagents」セクションに従って、各サブエージェントに適した推論レベルと、fast または standard の速度を選びます。

• 記録された判断のうち、根拠が弱い、または根拠がないもの。
• 検証手順が省略されている、またはトランスクリプトに証拠がないのに実施したと記録されているもの。
• 後から見るとリスクがある選択（時期尚早、スコープの逸脱、症状の取り繕い）。
• ユーザーがざっと目を通しただけでは見落としそうな抜け。

トレイルを作成した実行では、すべての返信の末尾に「Attention」セクションを付けます。まずレビュー担当者のモデル名を独立した行に記載します（reviewed by <model>）。次に、該当する行または箇所を明示して、各指摘を列挙します。「No flags」も有効な値です。モデル名は省略できません。

トレイルのレビュー

上から順に読み、根拠へのポインターをたどり、抜き取りで確認します。GitHub では、コミット済みの TSV が表として表示されます。column -s$'\t' -t decisions.tsv を実行すると、ターミナルで整形表示できます。

このスキルの作成

他のスキルでは、監査トレイルの形式を独自に定めず、ここに委ねます。スキル名で参照し、形式の定義はここに任せます。列を繰り返し記載してはいけません。