mcpField
S
show-me-your-work

show-me-your-work

github.com/mariusflorescuエージェントワークフロー12100 回インストール4 日前に更新
リポジトリ

show-me-your-work について

決定、理由、根拠、結果を簡潔な追記専用 TSV に記録するスキルです。会話とログの照合監査や、独立した記録レビューの手順も示します。

主な機能

  1. 01単一の TSV 決定ログ
  2. 02決定とチェックポイントの記録
  3. 03追記専用の修正ルール
  4. 04会話に基づくログ監査
  5. 05記録の独立レビュー

活用シーン

  1. 01プロジェクトの決定と検証結果の記録
  2. 02ログと実際の作業の照合
  3. 03引き継ぎ前の根拠とリスクの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mariusflorescu/pstack-t3 --skill show-me-your-work

インストール後、Claude Code で/show-me-your-workを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
decision-log-template.tsv
scripts/
log.sh

詳細

作業内容を示す

太字またはバッククォートで示されたスキル名、あるいは /<name> として実行されるスキル名は、このスキルのディレクトリの隣にある ../<name>/SKILL.md ファイルを指します。接頭辞なしで示された原則名は、../principle-<name>/SKILL.md を指します。そのファイルを読み、従ってください。pstack スキルのほとんどはユーザー専用であるため、スキルツールでは読み込めません。すべての delegate_task 呼び出しには、../poteto-mode/SKILL.md の Subagents セクションにあるデフォルト設定が適用されます。

正本となるログを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 となります。後のターンでログに戻る実行では、別の実行がそれ以降に追記していないか確認するため、まずログの末尾の行を読みます。start 行には、この実行が記録していない先行行の ts の範囲を記載し、根拠にはこの実行を特定できる情報(スレッド ID など)を記載します。フェーズ start は、それ以外の用途には使いません。

保存場所

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

レビュー担当者が結果を信頼できるよう履歴を確認する必要があるほど大規模な作業の場合に限り、コミットしてください。

ルール

  • 追記のみとします。誤った判断は、新しい行を追加して置き換えます。履歴を編集または削除してはいけません。
  • 手作業で一度限りの方法を使うより、コミット済みのスクリプトが生成した根拠を優先してください(encode-lessons-in-structure の原則スキル)。

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

実行の最後に、結果を引き渡す前に、ログが事実を伝えているか確認します。この実行のスレッドを t3_thread_read(view: "activity" を指定し、hasMore が false になるまで nextPosition をたどり、itemId と textOffset を使って切り詰められた項目を復元します)で読みます。実行時の最初のユーザープロンプトを指定して t3_thread_search を実行し、スレッドの ID を見つけます。別のプロジェクトの projectId は渡さないでください。無関係なプライベートチャットが読み込まれます。この実行の行を、実際に起きたことと照らし合わせます。各まとまりは、この実行の start 行のいずれか、またはこの実行でログを作成した場合は最初の行から始まり、別の実行の次の start 行で終わります。

  • 各行が実際の判断またはアクションに対応していることを確認します。
  • 各行の根拠が解決可能で、その行の主張を裏付けていることを確認します。
  • 作業に影響したものの記録されていない分岐、方針転換、中断したアプローチがあれば、それは記録漏れです。追加してください。

修正するのはログであり、ストーリーではありません。監査では、行の編集や削除は行いません。行が実際の判断もアクションも記録していない場合、または主張や根拠が誤っている場合は、実際に起きたことと、解決可能なポインターを示す行を追加して、その行を置き換えます。この監査の対象は、この実行のまとまり以外の行には及びません。ただし、この実行の作業から他の行の誤りが判明した場合は、誤った判断と同様に、その行を置き換えてください。

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

引き渡す前に、作業を行ったモデルとは異なるモデルファミリーから、orchestrator_capabilities を参照して選んだモデルで delegate_task の子タスクを起動し、タイトルを Trail reviewer にします。依頼にはログの絶対パスとこの実行のスレッド ID を含め、「読み取り専用:確認のみ、書き込み禁止、git コマンド禁止」と「委任禁止」と記載します。サブエージェントは監査証跡と実行のトランスクリプト(view: "activity" を指定した t3_thread_read を使い、hasMore が false になるまで nextPosition をたどり、itemId と textOffset を使って切り詰められた項目を復元します)を読み、ユーザーが注意すべき点を指摘します。作業をやり直すのではなく、最適でない点やリスクを探します。サブエージェントごとの推論レベルと fast または standard の速度は、「poteto-mode」スキルの Subagents セクションに従って選びます。

  • 根拠が弱い、または存在しない判断の記録。
  • 検証手順が省かれている、またはトランスクリプトに証拠がないのに実施済みとされている箇所。
  • 後から見るとリスクがある選択(時期尚早な対応、スコープの拡大、症状の取り繕い)。
  • ざっと読むだけではユーザーが見落としそうな記録漏れ。

作業記録を生成した実行の回答はすべて、「Attention」セクションで終えます。最初の行にレビュー担当モデルを記載します(reviewed by <model>)。続けて、特定の行や箇所を示しながら指摘事項を列挙します。「指摘なし」も有効な値ですが、モデル名は省略できません。

作業記録のレビュー

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

このスキルの構成

ほかのスキルは監査証跡を独自に作成するのではなく、ここに委ねます。列を再掲せず、このスキルの名前を参照してください。

コメント