report-poc-to-requester · git:20261022.fe0c55e · 2026-10-22 · sha256 feb68d8aef44b84e

report-poc-to-requester git:20261022.fe0c55eA

Immutable. This exact content never changes and is served at /api/v1/blob/feb68d8aef44b84e.

---
name: report-poc-to-requester
description: "Use when the user asks to turn a finished or paused PoC / validation into a report for the requester: 依頼主向けレポート, 検証結果のご報告, 依頼元への返信, コピペできる報告文, summary-for-requester, 試したこと・結果・サマリ・証跡のフルパス. Builds a paste-ready report with conclusion first, results per item, remaining work, cleanup and cost, and the full paths of the evidence. Does not run or re-run validation."
disable-model-invocation: true
argument-hint: "対象の検証フォルダー(省略時は会話の主題の検証)と、宛先の想定や強調したい点"
license: CC BY-NC-SA 4.0
metadata:
  author: aktsmm
---

# Report PoC To Requester

PoC の結果を、依頼主へそのまま貼れる報告文に整える。検証の実行や追試はしない。材料は対象検証の成果物と今回の会話だけ。

## When to Use

- 「依頼主向けのレポートを書いて」「検証結果のご報告」「コピペできる形で」「summary-for-requester」「試したこと・結果・サマリ・証跡のフルパス」
- 検証が一区切りし、依頼元へ返す文面(メール・チャット・フォーム)が要るとき
- 使わない: 検証の実行・追試、顧客向けスライド・資料の作成、メール送信(貼るのは本人)

## 入力

- 引数: 対象の検証フォルダーと補足(宛先の想定、強調したい点)。省略時は会話の主題の検証。候補が複数・不明なら確認する。
- 読む: 結果レポート(判定の正本)、状態・証跡の記録ファイル(status・run・evidence の件数)、計画(変更経緯・追加項目)、手順書、作業メモ(あれば最新状況・訂正)、証跡一覧。非公開の台帳・未加工原本は存在確認だけで、中身は読まず転記しない。
- 結果レポートが作業メモや最新の会話より古いときは、新しい根拠を採用し、食い違いをチャットで指摘する。

## Workflow

1. 対象と宛先を決める。結果レポートが無ければ止めて、先に作成を提案する。
2. 事実を集める。件数・日付・ID は記録ファイルなどから機械的に読み、手計算や記憶で書かない。判定語は結果レポートの Verified / Failed / Unverified に合わせる。
3. [references/report-template.md](references/report-template.md) の構成で書く。結論を先に置き、各主張に「何を・どの環境で・何回試したか」を付ける。
4. 下の「書き方の制約」を満たす。
5. 対象フォルダの `summary-for-requester.md` に保存する。既存があれば読んで差分だけ更新し、同じ材料で増やさない。保存後に検証する(下)。
6. チャットに、本文を1つのコードブロックで出し、直後に証跡のフルパスを示す(出力)。

## 書き方の制約(省略しない)

- 否定結果(できない・出ない)は「段階(呼ぶ・読む・書く等)×環境×試した種別・回数」に分ける。1回・1種別の観測は「試した範囲では」と限定し、「できなかった」と一括で断定しない。
- 実測・本人の申告・仮説・未確認を区別する。検証用環境の反映遅れなど環境の注意は前提に書き、未達を製品の制約と断定しない。
- 本文に入れない: 実ID(テナント・サブスクリプション・リソース)、秘密値、個人のメールアドレス、ローカル絶対パス、差し込み欄(`<…>`)、コードフェンス。
- 費用は「概算」と「未計測」を区別し、課金が続く資源は名前と日額を書く。作成物は「作ったもの・手動保持・削除はご指示後」と残存を明記する。
- 本人の業務アカウントなど実環境を使った場合は、変更の有無(作成なし等)と後片付けを書く。
- 画面証跡に業務名・通知などが写るものがあれば、外部共有前の確認を注記する。
- 送信・投稿・commit はしない。

## 出力

1. 報告文: 1つのコードブロック(`text`)。差し込み欄のない完成形。
2. 証跡のフルパス(文面の外。実在確認済み、ドライブ文字から): 結果レポート・手順書・計画・作業メモ・証跡一覧・記録ファイル・証跡画像フォルダー・構成図・成果物・非公開台帳・未加工原本。加えて、主な主張ごとの画像ファイル名を表で示す。絶対パスはチャットにだけ書き、保存ファイルには入れない。
3. 保存先、注意点(古い記述、写り込み)、未決事項を短く。

## 検証

- 保存した文面を検査する: `python scripts/check_summary.py <summary.md> --evidence-record <記録ファイル.json>`。禁止パターン(絶対パス・メール・GUID・フェンス・差し込み欄)と、「画面証跡N枚」が記録ファイルの `evidence` 件数と一致するかを確認する(`--evidence-record` は任意)。終了コード 0 だけを合格とする。
- 判定語・日付・件数を結果レポートと記録ファイルに照合し、示す証跡ファイルは実在を確認する。
- 実行中のワークスペースに常設の報告ルール(課金確認など)があれば、別途従う。

## Key References

| File | Use |
| ---- | --- |
| [references/report-template.md](references/report-template.md) | 報告文の構成と文の作り方、チャットでの証跡の示し方 |
| `scripts/check_summary.py` | 保存した報告文の禁止パターンと証跡件数の検査(読み取り専用) |