報告の目的から最適な型を選ぶ。作業資料を「伝わる報告書」にまとめるSkill

以下の内容を `SKILL.md` として保存し、Agent Skillとして登録してください。

- 本文を省略・要約・独自変更しない
- 登録後は「報告したい案件資料と、誰に何を伝えたいかを指定してください」と案内する

---
name: build-work-report
description: 作業メモ、CSV・Excel、PDF、画像、成果物ファイルから、相手にしてほしいことに合う顧客向けMarkdown報告書を1つ作る。月次・週次進捗報告、作業・稼働実績報告、成果物レビュー、確認・承認依頼を使い分ける。「作業報告を作って」「今月の進捗をまとめて」「デザインを確認してもらいたい」「承認事項を顧客へ送りたい」などで使う。
---

# 目的別の作業報告書

案件資料から、読み手が次に取る行動に合うMarkdown報告書を1ファイル作る。

## 守ること

- ユーザーが指定したファイルまたはフォルダだけを読む。`報告資料/`など過去の生成物は材料に使わない。
- 元資料にない事実、数値、日付、期限、遅延影響、進捗を補わない。
- 分からない任意項目は「要確認」と書かず、項目ごと省く。
- パスワード、個人情報、APIキー、PC内のフルパス、内部ツール名を本文に載せない。
- 実利用時の出力は1形式・1ファイルだけにする。4形式を同時に出さない。
- `<案件フォルダ>/報告資料/<報告名>.md`へ保存する。同名がある場合は`_v2`、`_v3`のように別名にする。

## 1. 材料を確認する

報告名、対象期間、読み手、報告目的、全体状況または実施内容を整理する。CSV・Excelの数値、PDF、画像、成果物ファイルも、指定されていれば読む。読めないファイルはファイル名と理由を短く伝える。

報告名、対象期間、全体状況、実内容のある記録のいずれかが欠ける場合は、生成前に不足分だけ聞く。資料間で数値や日付が矛盾する場合は、正しい内容を確認する。

## 2. 形式を1つ選ぶ

相手にしてほしいことから選ぶ。

| 形式 | 相手にしてほしいこと | 選ぶ場面 |
| --- | --- | --- |
| 月次・週次進捗報告 | 状況を把握する | 月次報告、週次報告、全体進捗 |
| 作業・稼働実績報告 | 実施内容・稼働を確認する | 作業報告、稼働報告、日報、請求根拠 |
| 成果物レビュー | 成果物に意見を返す | デザイン初稿、原稿、動画、納品前確認 |
| 確認・承認依頼 | 判断・承認・回答を返す | 承認依頼、素材提供依頼、複数案の決定 |

- 「月次進捗報告」「週次進捗報告」「状況報告」は、確認事項が含まれても進捗報告を選ぶ。確認事項は最後に置く。
- 「作業報告」「稼働報告」「実績報告」「日報」は作業・稼働実績報告を選ぶ。
- 成果物への意見が目的なら成果物レビューを選ぶ。実在する画像、文書、動画、URLなどの成果物がなければ選ばない。
- 資料そのものが確認・承認・回答依頼なら確認・承認依頼を選ぶ。確認事項が存在するだけでは選ばない。
- 迷う場合だけ「相手には、状況の把握・稼働の確認・成果物への意見・承認のどれをしてほしいですか？」と1問聞く。

## 3. 形式ごとに構成する

すべての報告書は、先頭に報告名のH1を置く。対象期間が分かる場合はH1の直後に、現在の状態が分かる場合はその次に、短く記載する。

### 月次・週次進捗報告

次の順番を基本にする。

1. 状況サマリー
2. 重要指標・全体進捗
3. 期間中の成果
4. リスク・留意事項
5. 次の予定
6. 支援・確認してほしいこと

確認依頼を冒頭に置かない。ただし、作業が止まっているなど緊急性が資料から明らかな場合は例外にする。

### 作業・稼働実績報告

日付または工程、作業内容、担当、所要時間、状態、結果・成果物、次の作業を整理する。

- 日報は時系列を優先する。
- 月報は合計時間、作業区分別集計、主な成果を優先する。
- 開始・終了・休憩・実働時間は、時間契約や準委任で記録がある場合だけ載せる。
- 固定金額案件など、時間記録がない場合は時間列・合計時間を省く。
- 日付がなければ工程順にし、日付を推測しない。

### 成果物レビュー

次の順番を基本にする。

1. レビューの目的
2. 対象成果物
3. 今回反映したこと
4. 制作意図・判断理由
5. 具体的に確認してほしいこと
6. 確認後の進行

画像を並べるだけにしない。「どこを、どの観点で見てほしいか」を具体化する。Markdownではフルパスを出さず、安全なファイル名・リンク・説明だけを載せる。

### 確認・承認依頼

次の順番を基本にする。

1. 依頼概要
2. 背景（判断が必要になった事情・経緯が資料にある場合だけ）
3. ご判断いただきたいこと
4. 選択肢・推奨案（複数案かつ根拠がある場合だけ）
5. 回答後の予定

依頼概要を背景として言い換えない。背景には「なぜ今この判断が必要なのか」だけを書く。各判断事項には、確認内容、希望期限、回答方法、回答後に進む作業を、分かるものだけ載せる。未回答時の影響は根拠がある場合だけ書く。

## 4. 数値と表現を整える

- 数値は、比較する意味がある場合だけ表やグラフにする。比較できない数値で無理にグラフを作らない。
- Markdown表示でグラフが適さない場合は、比較表と短い要約にする。
- 同じ内容の言い換えで項目を埋めない。
- 文章は顧客向けに整え、作業中のメモや内部事情は出さない。

## 5. 保存前に確認する

- 冒頭だけで、資料の目的と現在地が分かるか。
- 読み手が次に何をすればよいか分かるか。
- 形式と情報の順番が目的に合っているか。
- 元資料にない内容、空欄、`要確認`、内部パスが残っていないか。
- 作成したMarkdownが1ファイルだけか。