---
name: create-html-report
description: >
分析・比較・調査結果・進捗・計画を、意思決定しやすい自己完結 HTML レポートとして生成する。
「HTML レポート作って」「レポートにまとめて」「比較を可視化」「グラフで見せて」「ガントチャート作って」
「ダッシュボード風にまとめて」「見やすくまとめて」で使用。
データと伝えたい関係に応じて KPI・表・bar・line・scatter・heatmap・waterfall・donut・radar・gantt
から適切な表現を選び、アクセシブル・レスポンシブ・印刷対応の単一 HTML ファイルを生成する。
model: sonnet
user-invocable: true
argument-hint: "<レポートの目的・対象・データ/ファイル> [--interactive] [--output ]"
tools: [Bash, Read, Write]
---
# create-html-report
$ARGUMENTS をもとに、分析結果を「読むだけで要点が分かり、必要なら詳細まで確認できる」自己完結 HTML レポートへ変換する。
最終成果物は原則として単一 `.html` ファイルとする。
## 使い方
引数でレポート化したい内容(比較対象・データ・目的)を渡す。引数が曖昧な場合は Step 1 でユーザーに確認する。
- 出力先はユーザー指定がなければ `_/reports/.html`
- `--interactive` 指定時、または静的表示では扱いにくい大量データの場合のみ inline JavaScript を許可する
- `--output ` で出力先を明示指定できる
## Core contract
必ず以下を満たす。
1. **Insight first** — グラフを作ること自体を目的にしない。最重要な結論・変化・リスク・意思決定材料を先に特定し、その理解を助ける可視化だけを使う。
2. **Do not invent data** — 不明な値・日付・割合・単位・ステータスを推測で補完しない。欠損は欠損として扱う。必要な仮定を置く場合はレポート内に明示する。
3. **Self-contained** — 外部 CDN・外部 font・外部 JavaScript library・外部 stylesheet・外部画像へ依存しない。CSS・SVG・必要な JavaScript は HTML 内に含める。データ出典への通常の `` は外部依存とみなさない。ページロード時に外部通信してはならない。
4. **Accessible by default** — 色だけに情報を依存させない。グラフの主要な内容は文章または表でも確認できるようにする。キーボード・screen reader・dark mode・拡大表示を考慮する。
5. **Progressive enhancement** — 主要な結論とデータは JavaScript なしでも読めるようにする。インタラクションは理解を補助する場合だけ追加する。
6. **Deterministic rendering** — SVG 座標計算・escaping・テーマ・基本コンポーネントは bundled renderer に任せる。Claude が毎回同じ SVG boilerplate を手作業で再実装しない。
## フロー
### Step 1: Context と入力データを把握する
会話・引数・指定ファイル・既存データから以下を特定する。
- レポートの目的、想定読者、意思決定したいこと
- 対象・期間、指標と単位、データソース
- 比較対象、スケジュール・依存関係、不確実性・欠損値
会話や既存データから十分推定できる場合は質問しない。情報不足でも有用な部分レポートを作れる場合は、勝手に値を補完せず「制約・不足情報」として明示して進める。正しいレポートを作れないほど目的・入力が曖昧な場合だけ最小限の確認を行う。
### Step 2: narrative を設計する
HTML を書く前に内部的に次を整理する。
- 最も重要な 1 メッセージ、3〜5 個の key findings
- 意思決定・推奨事項、findings を裏付けるデータ、詳細確認用の情報
情報階層は原則次の順序にする。
1. Title / scope
2. Executive summary
3. KPI / key findings
4. Decision / recommendation(該当する場合)
5. Main visual analysis
6. Schedule / risks / dependencies(該当する場合)
7. Detailed data
8. Methodology / assumptions
9. Sources / generated metadata
すべてを1画面のダッシュボードへ押し込まない。重要情報を上に置き、詳細は下へ続ける。
### Step 3: データの「関係」から chart type を選ぶ
renderer が対応する chart type は `bar` / `line` / `scatter` / `heatmap` / `waterfall` / `donut` / `radar` / `gantt` の8種のみ。chart type ありきで選ばず、伝えたい関係から選定する。
| 伝えたい関係 | chart type | 補足 |
|---|---|---|
| カテゴリ間の大きさ・順位比較 | `bar` | 横棒推奨、0起点の軸 |
| 時系列の傾向・推移 | `line` | 欠損は gap として表現、架空補完しない |
| 2変数の相関 | `scatter` | 相関の説明は annotation で補足 |
| 期間ごとの量・時間×カテゴリの分布 | `heatmap` | 連続値は知覚的に均一な配色を使う |
| 増減への寄与・累積変化 | `waterfall` | 開始値・終了値・差分を明示 |
| part-to-whole(構成比) | `donut` | 6分割以下、正確な値は表を併記 |
| 多変量プロフィール | `radar` | デフォルトにしない(下記参照) |
| タスクの期間・依存関係・milestone | `gantt` | 依存が密な場合は表を併記 |
上記に当てはまらない関係(分布・before/after・多系列比較等)は、対応 chart type への安易な代替を避け、data table での表現を優先する。無理に非対応の chart type を模して自作 SVG を追加しない。
Radar chart はデフォルトにしない。多軸プロフィールの「形」を俯瞰すること自体に価値があり、軸が少数で同一スケールへ正当に正規化できる場合だけ使用する。
#### Chart anti-patterns
原則として以下を避ける。
- 3D chart、gauge / speedometer、不要な gradient・過剰な shadow
- dual-axis chart、10系列以上を重ねた line chart、大量 slice の donut
- 装飾目的だけの chart、比較目的なのに baseline が不統一な chart
- 面積や色だけで厳密比較させる chart
### Step 4: gantt / schedule を使う場合
開始日・終了日・milestone・依存関係のある計画には `gantt` を優先する。gantt は次を満たす。
- 左側に task / workstream 名、横軸に実日付、week / month 等の適切な tick
- phase ごとの grouping、milestone は diamond 等 bar 以外の形で表示
- progress がある場合は planned bar 上へ progress を重ねる
- current date が期間内にある場合は today line を表示
- status は色だけでなく文字・pattern・symbol でも区別
- dependency arrow が密集する場合は無理に描画せず dependency table を併記
- mobile では潰さず `.chart-wrap` で横スクロール可能にする
- SVG と同じ task / start / end / status / progress を表でも確認可能にする
日付が不明な task に架空の日付を与えない。
### Step 5: report spec を作成する
HTML を直接組み立てる前に、renderer が扱える中間 report spec(JSON)を作る。仕様は [references/report-spec.md](references/report-spec.md) を参照する。
report spec には最低限以下を持たせる。
- metadata、title / subtitle、scope、executive summary、findings
- sections、chart definitions、tables、annotations、assumptions、sources
各 chart definition には最低限以下を含める。
- chart type(上記8種のいずれか)、semantic title、takeaway、units
- series、labels、raw numeric/date data、source、accessibility summary
計算済み SVG 座標を report spec に保存しない。座標計算は renderer の責務とする。project 内の成果物として残す必要がなければ一時ファイルとして扱う。
### Step 6: renderer で HTML を生成する
まず必須 CLI の `python3` の存在を確認する。
```bash
command -v python3 >/dev/null || echo "python3 が見つからない"
```
未導入の場合は処理を中止し、導入方法を案内する(macOS: `brew install python3`。その他の環境: 各環境の公式セットアップ手順または環境管理者に確認する。導入後に再実行。権限昇格を要するコマンドは案内しない)。
```bash
python3 "${CLAUDE_SKILL_DIR}/scripts/render_report.py" \
--spec "" \
--output ""
```
ユーザー指定がなければ出力先は `_/reports/.html`。必要なら先に出力ディレクトリを作る。
renderer は Python 標準ライブラリのみで動作する設計とし、外部 package installation を前提にしない。詳細は [references/report-design.md](references/report-design.md) を参照する。
## HTML information design
### Page shell
必須: `` / `` / `` / viewport meta / descriptive `` / `` / `` / semantic `` / `