work-report

作業ツリーのルートに、レビュー担当者や新しいセッション向けの「作業レポート」WORK-REPORT.md を作成します。差分からは分からない内容を記載してください。作業ツリーごとに1つ作成し、実行のたびに上書きして、常に現在の状態を示すようにします。ディレクトリの種類（Git 管理下かどうか、worktree かどうか）、作業の形態（コミット、未コミットの編集、複数リポジトリにまたがる変更、エディター設定など）は問いません。

手順は順番に実行してください。書き込み不可能なパスの場合に限り、処理を中断します。git がない場合、リポジトリがない場合、何も変更しないセッションの場合も、有効なレポートを作成してください。

頼まれる前に書かない

自動起動（ユーザーが作業の完了を示したものの、レポートを指定していない場合）：一文で提案し、承認を待ちます。提案に Step 2 の質問を含められるよう、既存のレポートを先に読んでもかまいません。明示的な指示（/work-report、「作業レポートを書いて」）は承認とみなします。

「作業」の範囲 ＝ このチャットセッション

このセッションで行ったことをレポートしてください。git diff や git log から推測してはいけません。Git にはすでに記録されており、後から再構成しても意図が失われるためです。呼び出し時に渡された自由記述のメモは、重点を定めるために使います（そのトピックを各セクションの先頭に置きます）が、対象範囲を狭めるものではありません。

記述の粒度 — 各項目の長さを揃える

目的とその箇条書き：1〜2文。リスト項目：1文（必要なら括弧書きを追加）。段落は書かず、読者が流し読みできるようにします。

Step 1 — レポートの場所を特定する

<root>/WORK-REPORT.md。<root> は git rev-parse --show-toplevel で取得し、Git 管理下にない場合は現在のディレクトリを使います。

Step 2 — 既存のレポートを読み、内容を引き継ぐ

既存のレポート（別のエージェントが作成した可能性もあります）は、別の作業に関するものかもしれません。レポートの Goal がこのセッションと明らかに無関係な場合、またはレポートのセッション ID とブランチの両方が現在のものと異なる場合は、ユーザーに確認します。セッション ID が一致すれば、ブランチの確認は不要です。同じセッション内で複数のブランチに作業を展開することがあるためです。別の作業のレポートは、意図的な引き継ぎであることがよくあります。新たに始めると何が失われるかを明示してください：「WORK-REPORT.md は別の作業（CSV エクスポートに再試行を追加、ブランチ feat/export-retry）のものかもしれません。内容を引き継ぎますか、それとも新しいレポートを始めて、未完了のフォローアップ2件と [ignored] 項目1件を破棄しますか？」自動起動の場合は、これを一文の提案に含めます。「新しく始める」と言われたら、このセッションの内容だけで作成し、この手順の残りをスキップします。

それ以外の場合は、再生成せずに引き継ぎます。タグを変更せずに Problem → Solution と Abandoned の項目を維持し、このセッションで範囲が広がった場合は Goal を広げ、引き継いだフォローアップをすべて処理します（セッションを再開するたびにレポートが膨らまないよう、不要な項目は削除します）。

引き継いだフォローアップ	記載先
方針変更、別案の採用、または差分から分からない確認（パイプライン実行の調査、メール送信、コンソールフラグの切り替えなど）の後に完了した	Problem → Solution
完了し、実施内容を差分から確認できる	削除し、記録を残さない
評価の結果、却下した	[considered] タグを付けて Abandoned
ユーザー、またはユーザーが定めたルール（Step 4、Abandoned）によって不採用になった	[ignored] タグを付けて Abandoned
未完了	原文のまま残す
古くなった、または目的が変わった	削除し、記録を残さない

Step 3 — .gitignore への追加を提案する（リポジトリでの初回のみ）

Git 管理下にない場合、または Step 2 でレポートが見つかった場合（初回かどうかの判定。断られた後に再度尋ねないため）を除きます。Step 1 の <root> を使って grep -qxF '/WORK-REPORT.md' <root>/.gitignore を実行します。該当する場合は何も言いません。なければ、レポートは通常ブランチの差分から除外するローカル成果物であることを伝え、追加するかどうかを尋ねてから、どちらの場合も Step 4 に進みます。承認されたら、末尾に改行がない場合は改行を追加して、<root>/.gitignore に追記します。

# Work report (work-report skill) - git add -f to commit it
/WORK-REPORT.md

先頭のスラッシュは残してください。これにより作業ツリーのルートだけが対象になり、同名のファイルが下位のディレクトリにあっても無視されず、すべての worktree が引き続き対象になります。

Step 4 — レポートを作成する

差分から分からないことだけを記載します。意図、判断理由、検証、次の手順が対象です。コミットや変更ファイルを繰り返し記載してはいけません。成果物（PR／Issue の URL、ファイルパス、ADR）を参照し、内容を貼り付けないでください。API キー、パスワード、トークン、認証情報、個人情報（PII）の値を再掲してはいけません。存在することと、その場所だけを記載してください（他のエージェントもレポートを読み、コミットする可能性があります）。 ヘッダー - # Work report をそのまま記載し、その後に識別子の行を2行、各行に事実を1つずつ記載します。決して1行にまとめないでください。branch = 作業を開始したブランチです。新しいレポートでは現在のブランチを記載し、レポートを拡張する場合は変更せず引き継ぎます。session id = 最後に書き込んだ人です。読み手はこれらの行と、以下のフォールバック値を grep します。

# Work report

- **branch:** <on a new report git branch --show-current, `(detached)` on a detached head, `(no git)` outside a repo or with git unavailable>
- **session id:** <printenv CLAUDE_CODE_SESSION_ID, or `unknown` if unset>

その後、以下の ## 見出しを順番どおりに5つ記載します。各見出しは必ず含め、内容が空の場合はその下に - none を記載します。

• Goal - この作業で達成しようとしたことです。

• Problem → Solution - 番号付きリストです。次の場合に項目を記載します。最初の試みが失敗して方針を変更した場合、有効な選択肢が2つ以上ある実質的な分岐を選んだ場合、またはレポートにすでに記載されていたフォローアップが（誰が行ったか、このセッションで行ったかを問わず）完了し、その完了が差分からは確認できない、あるいは完了自体が分岐を伴うものだった場合です。この作業を妨げていた問題と機能したアプローチ、または分岐とその理由を記録します。この条件に該当しない完了済みのフォローアップは、Follow-ups に残すだけです。差分、PR、CI からは確認できない検証（プロキシを停止した状態で再試行の経路をクリックして確認した、パイプラインの実行を調査したなど）は、検証対象の Solution に含めます。検証した作業に該当する項目がない場合は、確認作業自体を独立した項目にします（Problem = 確認が必要だったこと、Solution = 確認方法と結果）。テストが成功したというだけでは項目になりません。大きな修正の一部であっても、方針を変更した箇所ごとに独立した項目を記載し、失敗した試みも [tried] として Abandoned に記載します。項目の形式：

  1.
      - **Problem:** description
      - **Solution:** description
  

• Follow-ups - 次のセッションまたはレビュー担当者が引き継ぐ内容を、フラットなリストにして、それぞれにタグを付けます。

  • [question] - 未解決の判断事項または不明点を、質問の形で記載します。
  • [action] - 具体的な作業を命令形で記載します。動作すると考えられているものの、まだ実際に試していない場合は、結論を出すための確認を明記した [action] にします。担当者がいなくてもかまいません。

  以下は記載しません。

  • すでに見送ると決まったギャップ（許容済みのリスク、対象外のプラットフォーム）：Abandoned に [considered] として記載します。ユーザー、またはユーザーが定めたルールによって却下された場合は [ignored] とします。
  • リリースに関する作業（コミット、プッシュ、PR、マージ、タグ付け、リリース）：セッションが未コミットで終了する場合でも、これらはユーザーが行うことです。
  • スキルやスラッシュコマンドの実行：ツールではなく、結果を記載します（[action] Add regression tests for the retry path）。たとえば、[action] Run /test-writer とは記載しません。

• Suggested skills - 結果のみを記載したフォローアップの手段です。[action] 項目の進行に役立つ場合に限り、/skill - 進行するフォローアップ の形式でスキルを記載します。

• Abandoned - 次のエージェントが再検討する必要のない内容、つまり取りやめたアプローチや、引き継いだ後に却下されたフォローアップです。番号付きで、理由を添えた1文で記載します。

  1. [tried] implemented or attempted, then reverted - why it was backed out
  2. [considered] evaluated and rejected without building it - why it was rejected
  3. [ignored] dismissed by the user or a rule the user set - the user's reason, "user's call", or the rule and its source
  

[ignored] = ユーザーによる却下です。後続の実行では、以下の再開確認に該当する場合を除き、再度提案したり、タグを付け直したり、提示したりしません。ユーザーの権限に基づく必要があり、次の3つの方法のいずれかで示されます。

• 直接の指示：このセッションで明示的に却下された場合（「無視して」「Safari のケースは飛ばして」「対応しなくていい」など）。
• このセッションでユーザーが述べた、または確認したルール（「ブロッカーのみ修正する」などのレビュー基準）、あるいはリポジトリの指示ファイル（AGENTS.md、CONTRIBUTING.md）に記載されたルールを、その項目に適用した場合。ルールとその出典を示します。- user's bar "blockers only" における非ブロッカー（このセッション）、またはファイルパスのように記載します。項目ごとに1件記載します。
• 既存のレポートから引き継いだ場合。

出典を示せないルール、ユーザーが確認していないスキルのデフォルト、または独自の却下は、理由とともに [considered] とします。沈黙、回答のない [question]、または先送り（「今はやらない」「後で」）の場合は、Follow-ups に残します。チケットまたはドキュメントにすでに記録されている先送りは、項目を記載しません。ユーザーの理由やルールを捏造してはいけません。

ユーザーがその作業を再度依頼するか、ルールを変更または撤回した場合、ユーザーは [ignored] を解除します。後者の場合、そのルールを根拠としているすべての項目が解除されます。再開確認：このセッションの不具合または失敗が、[ignored] 項目と根本原因または失敗シナリオを共有している場合、その項目を残し、[question] Does <defect> reopen [ignored] <item>? を追加します。判断するのはユーザーです。

例：

# Work report

- **branch:** feat/export-retry
- **session id:** 3f1c9a2e-7b44-4d0e-9c1a-5e8f2b6d7a10

## Goal

Make the CSV export survive a dropped connection by retrying failed chunk uploads.

## Problem → Solution

1.
    - **Problem:** Retrying the whole export duplicated rows already written.
    - **Solution:** Retry per chunk with an idempotency key; verified by killing the proxy mid-export and diffing the output.

## Follow-ups

- [question] Should the retry limit be configurable per tenant?
- [action] Add regression tests for the chunk retry path.

## Suggested skills

- /test-writer - Add regression tests for the chunk retry path.

## Abandoned

1. [tried] Exponential backoff in the HTTP client - it retried non-idempotent POSTs elsewhere in the app.
2. [considered] Streaming the export over websockets - too large a change for the bug.
3. [ignored] Safari download filename encoding - user's call.

ステップ 5 - ファイルを書き込み、報告する

<root>/WORK-REPORT.md に書き込み、パスと 1 行の要約を返信し、再確認が必要な項目には [question] と名前を付けます。Git によって無視されている場合 （ステップ 3）、PR のレビュアーが意図的に git add -f WORK-REPORT.md を実行する必要があることを記載します。