Report

---
name: report
description: business-os への不具合の報告・改善の提案・Skill の追加や削除の提案を、事業データを検査した下書きにまとめ、人が中身を確かめて承認してから、business-os のリポジトリに Issue として送る。business-os の困りごとや要望を開発者に伝えたいときに使う。
disable-model-invocation: true
---

# /report

## 何をするか

business-os のリポジトリ（公開）に、Issue として報告や提案を送る。Issue は公開されるので、事業データを混ぜないことを最優先にする。

- 下書きは、決まったスクリプト（`scripts/report.ts`）が作る。スクリプトは事業データの型・固有名詞の辞書（`.leak-dict.json`）・利用者の名前を検査し、
  1 件でも見つかれば下書きを作らない。辞書が無い・読めない・語が 1 つも無いときも作らない
- 下書きは sandbox の一時フォルダにファイルとして書く。company の中には書かない
- 送るのは、人がファイルを開いて中身を確かめ、承認した後だけ。承認した後に中身が変わっていれば送らない
- 送る手段は、公式の GitHub MCP サーバーの `issue_write` が接続されていればそれを使う。無ければ、入力済みの Issue 作成の URL を示し、人がブラウザで送る
- `gh issue create` は使わない（sandbox の中の `gh` は認証情報を読めない）
- 安全装置の不具合（`/check` の「防衛の発火」の fail）は、公開の Issue にせず、非公開の経路（GitHub の Security の報告）を案内する

## 何を読むか

1. `${CLAUDE_SKILL_DIR}/../../templates/skill-conventions.md`（共通規約。最初に必ず読む）
2. `${CLAUDE_SKILL_DIR}/../../scripts/lib/report-forms.ts`（報告の種類ごとのフォームの項目。`id` と `label`）
3. 不具合の報告のときは、直近の `/check` のレポート（`docs/operations/reviews/check-*.md`）の fail / warn の行

## 手順

1. 質問 1 を聞く。答えから報告の種類（`bug-report` / `improvement` / `skill-add` / `skill-remove`）を決める
2. 質問 2 を聞く。答えから、選んだ種類のフォームの項目の値と、Issue の題を CC がまとめる
   - 会社名・事業名・人名・取引先名・金額は「事業 A」「CEO」「取引先 B」「数十万円」のように置き換えて書く
   - フォームの必須の項目（`label` に「（任意）」が無いもの）が埋まらなければ、項目ごとに質問 3 を聞く
   - 選択肢の項目（`skill-add` の `category`、`skill-remove` の `reason` と `action`）は、フォームの選択肢の文言のどれかで書く
3. 不具合の報告のときは質問 4 を聞き、答えを `run-mode` に書く。直近の `/check` のレポートがあれば、fail / warn の行を `check` に書く。
   環境の情報（版、OS、Node、設定の差）はスクリプトが足すので、CC は書かない
4. 下書きを作る。company のルートで、次を Bash ツールで実行する（JSON は引用符付きのヒアドキュメントで渡す）

   ```bash
   node "${CLAUDE_SKILL_DIR}/../../scripts/report.ts" draft --company . <<'REPORT_JSON'
   {"kind": "<種類>", "title": "<題>", "fields": {"<id>": "<値>"}}
   REPORT_JSON
   ```

   - 終了コード 0：出力の `file`（下書きの場所）と `sha256`（要約値）を控えて、手順 5 へ
   - 終了コード 1：スクリプトが止めた理由（見つかった行と種類）を示す。事業データらしいものなら質問 5 を聞いて置き換え、手順 4 をやり直す。
     辞書が無い・読めない・語が 1 つも無いなら、`/onboard` で辞書を作り直すか、会社の呼び名や事業名を辞書に足すよう案内して終える
   - 終了コード 3：安全装置の不具合なので、公開の Issue にしない。示された非公開の報告の URL を案内して終える
   - スクリプトの検査を飛ばす、下書きを CC が手で書く、ということはしない
5. 質問 6 を聞く。下書きのファイルの場所を示し、人に開いて中身を確かめてもらう
   - 「直してから送る」：人がファイルを直したと言ったら、`node "${CLAUDE_SKILL_DIR}/../../scripts/report.ts" inspect --company . --file <下書き>` を実行し、
     新しい `sha256` を控えて、質問 6 をもう一度聞く（終了コード 1 と 3 の扱いは手順 4 と同じ）
   - 「送らない」：下書きのファイルを消して、手順 8 へ
6. 「送る」と答えたら、送る直前に確かめる：`node "${CLAUDE_SKILL_DIR}/../../scripts/report.ts" verify --company . --file <下書き> --sha256 <控えた要約値>`
   - 終了コード 0 以外：送らない。理由を示し、手順 5 に戻る
   - 終了コード 0：出力の `owner`・`repo`・`title`・`body`・`url`・`omitted` を使う。`title` と `body` を CC が書き換えない
7. 送る
   - 接続されている道具に、名前が `__issue_write` で終わり、引数に `owner`・`repo`・`method`・`title`・`body` を持つもの（公式の GitHub MCP サーバー）があれば、
     `method: "create"` と verify の出力の `owner`・`repo`・`title`・`body` で呼ぶ。ラベルは渡さない（種類のラベルは business-os のリポジトリの側で付く）。
     作られた Issue の URL を示す
   - 無ければ、verify の出力の `url` を示し、「ブラウザで中身を確かめてから送信してください」と伝える。
     `omitted` に項目があれば、その項目は URL に入らなかったので、下書きのファイルから写して貼るよう伝える
   - ほかの名前の GitHub の道具（claude.ai のコネクタなど）は、名前と引数を確かめていないので使わず、URL を示す
8. 送ったら、または送らないと決めたら、下書きのファイルを消す（`rm -- <下書き>`）
   - URL を示した経路で `omitted` に項目があるときは、人がブラウザで送信を終えたと言うまで消さない（人が下書きから貼るため）。
     ほかの質問への答えを、送信を終えた合図と読まない

## 何を書くか

- 下書きのファイル（sandbox の一時フォルダ。送った後か送らないと決めた後に消す）
- 日報への実行記録（例：`- 16:10 /report — 改善の提案を送った`。題や本文は写さない）

## 人に何を聞くか

表の番号の順に聞く。聞き方は共通規約の「人への質問」に従う。

| 番号 | 見出し | 質問文 | 答えの形 | 選択肢 | 聞くとき |
|---|---|---|---|---|---|
| 1 | 報告の種類 | business-os に何を伝えますか。 | 選択肢（単一） | 不具合の報告 / 改善の提案 / Skill の追加の提案 / Skill の削除・統合の提案 | 常に |
| 2 | 伝えたいこと | 伝えたいことを、あなたの言葉で教えてください。会社名・事業名・人名・金額は「事業 A」「CEO」のように置き換えてください。 | 自由記述 | — | 常に |
| 3 | 足りない項目 | 「<項目の label>」を教えてください。 | 自由記述 | — | フォームの必須の項目が質問 2 の答えから埋まらないとき（項目ごと） |
| 4 | 動かし方 | 問題が起きたとき、Claude Code をどう動かしていましたか。 | 選択肢（単一） | 対話モード（ふだんの画面） / claude -p やスケジュール起動 | 不具合の報告のとき |
| 5 | 置き換え | 下書きに、事業データや個人の情報らしいものが見つかりました（<行と種類>）。何に置き換えますか。 | 自由記述 | — | 下書きのスクリプトが事業データらしいもので止めたとき |
| 6 | 送信の承認 | 下書きのファイル（<下書きの場所>）を開いて、中身を確かめてください。このファイルの中身で Issue を送ってよいですか。 | 選択肢（単一） | 送る / 直してから送る / 送らない | 下書きができたとき（直した後にもう一度） |
| 7 | コミット | 書いたファイルをコミットしてよいですか。 | 選択肢（単一） | コミットする / しない | 最後（ファイルを書いたとき） |

## 完了条件

- 送ったのは、人が質問 6 で「送る」と答え、verify が終了コード 0 を返した下書きだけである
- 事業データの検査に引っかかった下書き、安全装置の不具合の報告は、公開の Issue として送っていない
- 下書きのファイルが消えている
- 日報に実行記録が 1 行ある