name: data-process description: | CSV, JSON, TSV, SQL などの構造化データファイルの加工・集計・変換・フィルタリング。 選ぶべき場合: 入力が構造化データファイルで、プログラム的な処理が必要 選ぶべきでない場合: Excel/Word/PDFなどのOffice系ファイル操作、Web調査が主目的 triggers: keywords: ["CSV", "TSV", "JSON", "JSONL", "SQL", "フィルタ", "クレンジング", "ETL"] max_movements: 999 initial_movement: process movements: - name: process edit: true persona: data-engineer instruction: | ## 最初のステップ: 入力データの把握 加工に着手する前に、まずデータの構造を把握する: 1. Glob でワークスペース全体のファイル一覧を確認する(input/ だけでなくルート直下も含む) 2. 入力データファイルを Read や Bash で確認し、構造・件数・データ型を把握する 3. 指示に基づいて処理方針を立てる ## 処理手段の選択 **SQLite を使う場面**: - 複数テーブルの JOIN や GROUP BY が必要 - フィルタリング条件が複雑(WHERE 句で表現できる) - 集計結果を別ファイルに export したい(SELECT INTO / `.output`) - CSV を直接インポートして SQL で操作したい **Bash + python3 を使う場面**: - 数値計算・統計処理(平均・標準偏差・パーセンタイル等) - JSON/JSONL のネスト構造を展開・変換する - 行列変換・pivot・reshape など SQL では扱いにくい変換 - 複数ファイルをまとめて処理するスクリプトを書く **jq / awk を使う場面**: - JSON のフィールド抽出・変換(jq) - テキスト系の列操作・集計(awk) - 軽量な前処理パイプライン ツールの詳細な使い方は ReadToolDoc({ name: "ツール名" }) で確認できる。 ## 出力形式の選択基準 - **CSV**: 数値・表形式データ。後続の集計・可視化ツールへの受け渡し - **JSON / JSONL**: ネスト構造あり、または行単位のストリーム処理向け - **Markdown 表**: レポートやサマリーに埋め込む場合。行数が多い場合は上位N件に絞る ## スキャン PDF / 画像データの場合 レシートや帳票など画像由来のデータを扱う場合: - テキスト PDF → ReadPdf で直接読む - スキャン PDF / 画像 → PdfToImages でページ画像化し、ReadImage で内容を読み取る ## 実行 方針に従いデータを加工・集計する。結果を output/ にファイルとして書き出す。 前のステップから指摘事項がある場合は、それに優先して対応すること。 ## 終了 / 遷移方法 - **次の report へ**: `transition({next_step: "report"})` - **処理対象が特定できずユーザー確認が必要**: `complete({status: "needs_user_input", missing_info: "...", why_no_default: "..."})` - **データが壊れている / 読み取れない / エラー発生で打ち切り**: `complete({status: "aborted", abort_reason: "..."})` allowed_tools: [Read, Write, Bash, Glob, Grep, SQLite, WebSearch, WebFetch, DownloadFile, ReadExcel, ReadDocx, ReadPdf, ReadPPTX, SplitExcelSheets, PdfToImages, ReadImage, AnnotateImage, TranscribeAudio, SearchKnowledge, ListNamespaces, ListDocuments, ReadToolDoc, 'mcp__*'] default_next: report rules: - condition: output/ に結果を書き出した next: report - name: report edit: true persona: reporter instruction: | 処理結果を元にレポートを作成し output/ にファイルとして書き出す。 表を含め、分かりやすくまとめる。 必ず Write ツールで output/ にレポートファイルを作成すること。 allowed_tools: [Read, Write, Bash, Glob, Grep, ReadImage, AnnotateImage, ReadPdf, ReadExcel, 'mcp__*'] default_next: verify rules: - condition: output/ にレポートを書き出した next: verify - name: verify edit: false persona: reviewer instruction: | output/ の成果物を確認する。 確認手順: 1. まず Glob で output/ 内のファイル一覧を確認する 2. output/ にファイルが1つもなければ「修正が必要」と判断し process に差し戻す 3. ファイルがあれば Read で内容を確認し、指示通りか・品質は十分かをチェックする 4. 不足や誤りがあれば、`transition({next_step: "process", summary: ...})` で差し戻す。summary は次の形式で書く: [判定] needs_fix ## 問題点 - [ファイル名:行番号または項目名] 何が問題か ## 期待する修正 - 何をどう直すべきか ## 合格基準 - 再レビューで何を確認するか ## 次にやること - process で最初に着手すべき具体的な修正 5. summary は抽象論で終えず、変更ファイル・不足点・期待する修正内容を必ず含める ## チェックシート確認 GetChecklist でチェックシートが存在する場合、全アイテムが完了(done/failed/skipped)していることを確認する。 remaining が 0 でないまま完了してはならない。 ## 合格時のユーザーへの返答(complete ツール) output/ の内容で合格と判断したら、`complete({status: "success", result: ...})` を呼ぶ。 result はそのままユーザーに表示される最終回答。output/ のファイルを Read で読み、その内容をベースに整形する。 - 「output/xxx.md を確認してください」のようなファイル参照ではなく、内容そのものを回答として返すこと - 【厳守】「✅ 完了」「処理結果を作成しました」「確認しました」等のステータス表示・メタ説明・内部作業の報告は一切書かない。1行目からいきなり本題の内容を書き始めること - 処理結果の要点を会話調で分かりやすく伝える - 表・リスト・見出しなど Markdown 書式を活用して読みやすくする - 長大な結果の場合は要点を構造化して提示し、詳細は省略してよい ## 終了方法のまとめ - 合格: `complete({status: "success", result: "ユーザー向け最終回答"})` - 修正必要: `transition({next_step: "process", summary: "差し戻し指摘"})` (上記形式で) - 技術的失敗: `complete({status: "aborted", abort_reason: "..."})` allowed_tools: [Read, Glob, Grep, ReadPdf, ReadImage, AnnotateImage, ReadExcel] default_next: COMPLETE rules: - condition: output/ にファイルがない、または内容に不足・誤りがある next: process