show-me-your-work

作業内容を記録する

正本となるログを1つ保管します。

形式

1つのTSVファイルに、判断1件につき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原則スキル）。

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

実行の最後、引き継ぎの前に、ログの内容が事実と一致しているか確認します。アクティブなワークスペースのagent-transcripts/ディレクトリにある、この実行のトランスクリプトを読みます（システムプロンプトにパスが記載されています）。~/.cursor/projects/*/を対象にワイルドカード検索してはいけません。無関係なプライベートチャットまで読み込んでしまいます。この実行の各行を、実際に起きたことと照合します。この実行の行のまとまりは、この実行のstart行、またはこの実行がログを作成した場合は最初の行から始まり、別の実行の次のstart行で終わります。

• 各行が実際の判断または操作に対応していることを確認します。
• 各行の根拠が参照可能で、記載内容を裏付けていることを確認します。
• 作業に影響した分岐、方針転換、断念したアプローチが記録されていない場合は、記録漏れです。追加してください。

修正するのはログであり、実際に起きたことではありません。監査では行を編集したり削除したりしません。実際の判断や操作を記録していない行、または主張や根拠に誤りがある行があれば、実際に起きたことと参照可能な根拠を記載した行を追加し、以前の行に取って代わるようにします。この監査では、この実行の範囲外の行は確認しません。この実行で行った作業から、範囲外の行に誤りがあるとわかった場合も、誤った判断と同様に新しい行で置き換えます。

作業記録のクロスモデルレビュー

引き継ぐ前に、作業を行ったモデルとは異なるモデルファミリーのサブエージェントを起動してください。自己レビューで代用することはできません。サブエージェントは監査記録と実行時のトランスクリプトを読み、ユーザーが注意すべき点を指摘します。作業をやり直すのではなく、最適でない点やリスクのある点を確認します。

• 記録された判断の根拠が弱い、または根拠がない。
• トランスクリプトで裏付けられていない、未実施または実施済みと主張されている検証手順。
• 後から見るとリスクがあるように思える選択（時期尚早、スコープの拡大、症状の取り繕い）。
• 流し読みではユーザーが見落としそうな点。

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

作業記録のレビュー

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

このスキルの作成

ほかのスキルでは独自の作業記録を作るのではなく、ここに作業記録を引き継ぎます。名前で参照し、形式はこのスキルに任せてください。列を重複して記載しないでください。