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` | 保存した報告文の禁止パターンと証跡件数の検査(読み取り専用) |