gui-report

name

gui-report

description

データファイル(JSON/CSV/TSV/JSONL/YAML/Excel等)を渡されてユーザーが「レポートにして」「レポート作って」「サマリー作って」などと曖昧に依頼したときの**振り分け窓口**。 データ構造を見て `drilldown-report` (階層+クロスフィルタ) と `timeseries-report` (時系列+期間選択) のどちらが適切かを **自動判定** して、 該当 skill の手順に従ってインタラクティブHTMLレポート (GUI 操作可能、 ペラ1) を生成する。 ユーザーが skill 名を明示している (例「ドリルダウンレポートにして」「時系列レポートにして」) 場合はこの振り分けは要らないが、 起動してしまっても判定して該当 skill に流せばよい。 markdownレポートやWordドキュメント・PDFなど **GUI操作の不要な** 出力を明示的に求められた場合はこの skill ではなく、 該当ジャンルの skill を使うこと。

gui-report (振り分け)

「レポートにして」 という曖昧な依頼の入口。 データを見て、 適切なレポート skill に振り分ける。

$ARGUMENTSでこの項目はこう表したい等の要件が渡っている場合は考慮する

ワークフロー

1. 入力ファイルの種別と構造を把握
   • 拡張子 + head / jq 'type' / wc -l などで規模感を見る
   • JSON/JSONL なら最初の数件を jq '.[0]' 等で覗き、 列構成を確認
2. 判定ルール (下記) で該当 skill を選択
3. 選んだ skill (drilldown-report / timeseries-report) の SKILL.md を読み、 その手順に従って assets/template.html のプレースホルダ置換まで行う
4. 完了報告には「<選んだskill> で生成しました」 と明記。 出力ファイルパスは file:/// と file://wsl.localhost/Ubuntu/... の両方で

判定ルール

下記を 上から順に判定、 最初にマッチしたものを採用する。 Auto モードでは即実行。 ユーザーから「迷ったら聞いて」 と指示があるか、 どれにも当てはまらないときだけ確認を取る。

1. timeseries-report を選ぶ条件

• 各レコードに 日付/時刻フィールドが1つ あり (date, ts, timestamp, created_at など)
• レコードが 時系列に並ぶフラットな構造 (1日1レコード, 1時間1レコード, など)
• カテゴリ列が0個または1個 だけ。 数値カラムが中心
• 個別レコードの テキスト に意味が薄い (= 個別を読みに行く価値が低い)
• 例: 通信データ使用量, 体重・歩数, 日次KPI, 株価, アクセス数の日次集計, センサー値

2. drilldown-report を選ぶ条件

• カテゴリ列が2つ以上 ある (例 repository × workflow × job, account × category × vendor)
• 個別レコードに テキストや状態 (メッセージ・URL・ID・タイトルなど) があり、 それを読みに行きたい
• データが 粒度別に集計できる (カテゴリ別→詳細別→個別の流れで掘れる)
• 例: GitHub Actions annotation, アクセスログ (掘り下げ目的), Issue/PR一覧, テスト失敗ログ, Sentry エラー, 取引履歴

3. どちらでもないとき

• 完全にフラットで集計軸が1つもない (例 名簿) → 件数 30 行未満なら markdown のテーブルで十分。 ユーザーに「単純なテーブル(markdown)でいい?」 と確認 or 自動で markdown 出力
• 1行1ドキュメント (記事・メモ) → レポートではなく要約タスク。 別 skill or 直接の要約で対応
• 5万行超の超大量データ → ペラ1HTMLが重くなる。 サンプリング or 集計してからにする旨を提示

迷うパターン (両方の特性を持つ)

• 例: 「日付 + リポジトリ + アクション」 のように時系列でもカテゴリ階層でもある
• → ユーザーの目的次第。 「期間で絞って推移を見たい」 なら timeseries、 「カテゴリを掘り下げて個別を読みたい」 なら drilldown
• 自動判定では 個別レコードに読み物的テキストがあるか を最終判定材料にする (= ある → drilldown)

判定の例

データ	判定	理由
[{date, distance, caught, pokestops}] (Pokemon Go日次)	timeseries	日次フラット、 数値中心、 個別行に読み物なし
[{date, used, buy, expired}] (povo)	timeseries	同上
[{date, weight, steps, sleep_h}] (健康記録)	timeseries	同上
[{repo, workflow, job, level, message, url}] (Actions annotation)	drilldown	カテゴリ3つ + メッセージ
[{ts, status, path, user, ms, ua}] (アクセスログ)	drilldown	カテゴリ複数 + path/UA を読む
[{date, vendor, category, amount, memo}] (取引履歴)	drilldown	カテゴリ + memo を読む
[{date, temperature}] (気温の単独記録)	timeseries	1指標のみ

完了報告フォーマット

<選んだ skill> で <出力ファイル名> を生成した。

判定理由: <短い説明、 例「日次フラット+数値中心のため timeseries-report を選択」>
<選んだ skill 固有の構成サマリ>

ファイルパス:
- file:///<絶対パス>
- file://wsl.localhost/Ubuntu/<絶対パス>

設計の背景

• 3つに分けた狙い: ユーザーが skill 名を覚えていなくても「レポートにして」 1発で動く入口を作りつつ、 個別 skill は description で「何が得意か」 を明示してメンテしやすくしている
• 判定材料をテキスト性で切る: 数値だけのデータは時系列の方が情報密度が高く、 読み物テキストがあるデータはドリルダウンの方が探索しやすい。 完全に独立した基準ではないが、 多くの実データでこの分け方が効く
• 重複振り分けは避ける: 個別 skill に「明示的に依頼されたとき」 と書いてあるのは、 ユーザーが「ドリルダウンで」 と指定したときに gui-report を経由せず直接動くようにするため