x-report-it

name	x-report-it
description	報告相手に推測をさせない報告を組み立てる。結論を先に置き、完了を待たずに早く返し、 相手が抱く疑問に先回りして答える。報告だけで結論を出せない場合は相談を足す。 作業結果やステータスを報告するとき、ブロッカーや判断待ちが起きたとき、 チームや上長やSlackなどへの報告や共有の文面を整えたいときは、 明示的に指示されなくても必ずこのスキルを使う。 「報告して」「報告文を書いて」「共有文を作って」「ステータスを伝えて」 「Slackに投げる文面を作って」「PRの説明を書いて」「上長に報告したい」 「進捗を伝えて」「ブロッカーを共有したい」「相談したい」「判断を仰ぎたい」 のように使う。
allowed-tools	["Read","AskUserQuestion"]

report-it

ゴール

報告相手が、推測なしでそのまま行動・判断・安心できる状態にします。事実が正しくても、相手が「結局どうなったのか」「次に何をすべきか」「これは自分が動く話か」と推測しなければならない報告は、ゴールに届いていません。報告を読んだ相手が、判断のために追加で質問しなければならない状態も同様です。完了していること自体はゴールではありません。

用語の区別

相手を取り違えると情報を整理できなくなるため、次の語を使い分けます。

語	指す相手	扱い
報告相手	報告や相談を読む人。デフォルトはユーザーです。指定があればレビュアー・他職種・プロジェクトリーダーなどの第三者です	文面の宛先です
ユーザー	このスキルを動かしている人。Claudeが事実を確認する相手です	確認の宛先です
相談	報告相手に判断や知識を求めることです	報告の本文に含めます
確認	推測できない事実をユーザーに問うことです	報告の本文に混ぜません

報告相手が第三者の場合は、相談を相手へ、確認をユーザーへ、はっきり分けます。報告相手がユーザーの場合は宛先が1つなので、判断を仰ぐことも事実を確かめることも同じ相手へまとめます。

報告相手を決める

前提となる知識・情報量・語彙を相手に合わせるため、まず宛先を決めます。

起動時の判定

スキル名だけで呼び出された場合（/report-itなど）は、報告相手と報告内容をユーザーに確認します。

文章で呼び出された場合は、述語から報告相手を判定します。

述語の形	判定	理由
「報告して」「まとめて」	ユーザー宛て	Claudeに対する指示であり、ユーザー自身への報告を求めています
「報告したい」「共有したい」	第三者宛て	ユーザーが自分自身に報告したいとは言わないため、報告先は第三者です
「Slackに投げる文面を作って」「PRの説明を書いて」	第三者宛て	出力先が第三者向けです

判定できない場合は推測せずユーザーに確認します。

第三者モードへの切り替え

次のどちらかがある場合は第三者に切り替えます（以下、第三者モード）。

• ユーザーが宛先の人物を指定しています（レビュアー・他職種・プロジェクトリーダーなど）
• 出力先が第三者向けとわかります（Slackでの共有、PRの説明文など）
• 述語から第三者宛てと判定しています（上の表を参照）

ユーザーが報告相手の場合

Claude Codeで使うため相手が実装者であることは明確で、理解度も会話の履歴から読み取れます。改めて質問せず、履歴から前提や語彙を判断します。確認は、履歴からも判断できない事実に限ります。

第三者モードで相手を見極める

報告相手がユーザーの場合はこのセクションを飛ばします。第三者の場合だけ実行します。

報告相手が人物として確定していなければ、候補（指名された人、作業を引き継ぐ担当者、機能のPM、承認の権限を持つ上長、共有先のチームなど）を挙げてユーザーに確認します。確定したら、相手の像を次の3点で特定します。確定できない点は推測せずユーザーに確認します。

• 役割や役職を確認します。役職から前提となる知識を決めつけません。たとえばPMでも、元エンジニアであればフロントエンドかバックエンドかで通じる前提が変わります
• 責任の範囲が開発寄りかビジネス寄りかを確認します。技術的な判断は開発寄りの相手、優先度や仕様の範囲の判断はビジネス寄りの相手が答えられます。責任の範囲の外を尋ねても適切に答えてもらえません
• この報告の内容をどこまで把握・理解しているかを確認します。背景を把握しているか、関連する判断への関与の有無、専門的な用語の通じる度合いを見ます

相談や質問は相手の責任の範囲の内側に収めます。範囲の外の判断が必要な場合は、相手に押しつけず、誰に尋ねるべきかをユーザーに確認します。

報告を組み立てる

報告相手の負担を減らすため、次の3点を守ります。

• 結論を冒頭に置き、経緯や調査過程は後ろに回します。結論とは、報告相手が自らの責任を果たすために知りたい・理解したい情報への回答です。結果やネクストアクションがそれに当たることが多いですが、相手の責任に照らして別の情報が先に要る場合はそちらを優先します
• 完了を待たず「いま分かっていること」と「次の一手」を早く出します。「まだ分かりません」も次の一手を添えれば結論になり、「確認します」も早く返せば報告になります
• 相手が抱きそうな疑問に先回りして本文で答えます

書く前に次の6つを頭のなかで埋めます。すべてを本文に出す必要はありません。埋められない欄が、相手に推測させてしまう箇所になります。

観点	確認する問い
ゴール	最終的にどんな状態になればよいか。決めたいことは何か
問題	何が起きて、あるべき状態とどう違うか
情報	状況がわかる参考となる情報（ログ・差分・リンク・スクリーンショット）はあるか
現状	分かっていること・調べていること・やったことは何か
施策	いま考えている方法やとった対応は何か
課題	何が分かれば、何が決まれば前に進められるか

出力のテンプレート

【結論】報告相手が自らの責任を果たすために知りたい情報への回答を1〜2文で。ここだけ読めば要点がわかる
【ネクストアクション】誰が・いつまでに・何をするか。自分が動くなら宣言し、相手に動いてほしいなら明示する
【詳細】結論の根拠や経緯。読み飛ばしても困らない補足を簡潔に
【参考】ログ・差分・リンクなど（任意）

「URLにあるように」「詳細はリンク先を参照」のように、外部の参照先を読まないと要点が分からない書き方は避けます。リンクやログは結論の裏付けとして【参考】に置き、本文だけで完結させます。

軽い報告は結論とネクストアクションの順だけ守れば十分です。相手の次の行動を本文から一意に読み取れるかを、出す前に確かめます。

報告に相談を足す

先に報告を組み立て、自分では結論を出せないと分かった場合に相談を足します。次の場合に足します。

• 自分では決められない判断や選択肢があります
• 報告相手の知識や判断がないと前に進めません

相談の内容は次の6つで整理します。施策は仮説、課題は何が分かれば解消するかに寄せます。

観点	整理する問い
ゴール	解決して決めたいこと・実現したいことは何か
問題	何ができなくて、あるべき状態とどう違うか
情報	問題がわかる参考となる情報（画像・リンク・差分）はあるか
現状	知っていること・調べたこと・理解したことは何か
施策	解決しそうな方法の仮説はあるか
課題	どんな情報や判断があれば疑問は解消しそうか

相談のテンプレート

報告の後ろに足します。

【相談したいこと】報告相手に判断や知識を求める点を1文で
【選択肢・仮説】考えうる案と、それぞれの見立て（自分はどれがよさそうか）
【判断の材料】相手が判断するのに要る情報を、推測させず手元にそろえる
【これが分かれば進める】ブロッカーになっている課題を1点に絞って明示する

丸投げにせず、自分の仮説と、何が分かれば進めるかまでを示します。選択肢を出す場合は、相手が選ぶだけで済むよう各案のトレードオフを添えます。報告相手が第三者の場合は、相談を相手の責任の範囲の内側に収めます。

出す前に整える

報告相手の像（前提となる知識・理解度）に照らし、次の8つの視点で文面を調整します。

視点	調整すること
前提	相手の理解度に合わせ、前提になる知識や情報をそろえます
範囲	どこまでの話で、何がゴールかを先に伝えます
構成	相手が理解しやすい順番、つまり結論から並べます
比喩	相手が知っていることで例え、全体像をイメージで渡します
情報量	相手が処理しきれる量に絞り、なくても伝わる文を削ります
スピード	要点から詳細へ段階的に渡します
語彙	相手に合わせた分かりやすい言葉を選びます
ケア	必要なら「この理解で合っているか」と確認の問いを添えます

日本語の校正は伝わりやすさに直結します。報告でとくに効くのは以下の6点です。

• 誇張表現を使わず、事実と程度で書きます
• 主語が不明な受動態を避け、誰がやるかを明示します
• 「多い」「高い」のような抽象的な形容を定量的に書きます
• 同一の対象には同一の用語を使い、言い換えません
• 見出しや前置きで同じ内容を繰り返さず、一度で伝えます
• です・ます調でそろえます

ユーザーへの確認

推測で埋めると報告の品質が落ちる事実は、ユーザーに確認してから報告を出します。報告相手が誰か、その責任の範囲、理解度、欠けている事実などが該当します。

例

報告の例（進行中タスク）

整理されていない報告の例は「ログイン周りを調べていて、気になる箇所がいくつかあるので、もう少し見てみます」です。結論とネクストアクションがなく、相手に「いつ終わるのか」「自分は何をすべきか」を推測させています。

整理された報告の例です。

【結論】ログイン不具合の原因を特定したので修正します。refreshTokenの期限切れを検知する処理が不足しており、再発行が動いていませんでした。
【ネクストアクション】14時までに修正のプルリクエストを出します。トークン再発行のロジック変更のみなので、該当箇所の正当性を確認するレビューを本日17時までにお願いします。それ以外の対応は不要です。
【詳細】refreshTokenの期限切れを確認する処理がなかったため、期限が切れたことを検知できず、再発行処理が実行されていませんでした。

相談を足す例（判断が要る場合）

整理されていない相談の例は「状態管理どうしましょう」です。仮説も判断の材料もなく、相手にすべて考えさせています。

整理された報告と相談の例です。

【結論】状態管理の方針が決まれば着手できます。実装は調査済みで、どちらでも対応できます。本日15時までに方針をいただければ、明日中にプルリクエストを出せます。
【相談したいこと】状態管理にZustandとJotaiのどちらを採用するか。
【選択肢・仮説】既存がZustand中心のため、統一を優先するならZustandです。一方で今回はatom単位の再描画の制御が要るため、最適性ではJotaiが素直です。自分はJotai寄りに見ています。
【判断の材料】対象画面は1秒あたり約20回再描画されます。既存のZustandストアは3つです。
【これが分かれば進める】「既存への統一」と「今回の最適性」のどちらを優先するかが決まれば、すぐに着手します。

最終チェック

出す前に次を確かめます。どれか1つでも怪しければ、相手に推測をさせている箇所なので、出す前に解消します。

• 結論が、報告相手の責任を果たすうえで知りたい情報に答えているか
• 結論・詳細・ネクストアクションまで含めて、相手が判断のために追加で質問する必要がないか
• 報告相手の次の行動を一意に読み取れるか
• 完了を待たず、いま出せる情報を早く出しているか
• 自分で決められない点を、仮説と判断の材料を添えて相談に回せているか
• 報告相手が第三者の場合、相談を相手の責任の範囲の内側に収めているか
• 推測の精度が低い事実をユーザーに確認したか
• 報告相手の前提・情報量・語彙に合っているか