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
    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 → Read で直接読む
      - スキャン PDF / 画像 → PdfToImages でページ画像化し、ReadImage で内容を読み取る

      ## 実行

      方針に従いデータを加工・集計する。結果を output/ にファイルとして書き出す。
      前のステップから指摘事項がある場合は、それに優先して対応すること。

      ## 終了 / 遷移方法
      - **次の report へ**: `transition({next_step: "report"})`
      - **処理対象が特定できずユーザー確認が必要**: `complete({status: "needs_user_input", missing_info: "...", why_no_default: "..."})`
      - **データが壊れている / 読み取れない / エラー発生で打ち切り**: `complete({status: "aborted", abort_reason: "..."})`
    default_next: report
    rules:
      - condition: output/ に結果を書き出した
        next: report

  - name: report
    persona: reporter
    instruction: |
      処理結果を元にレポートを作成し output/ にファイルとして書き出す。
      表を含め、分かりやすくまとめる。
      必ず Write ツールで output/ にレポートファイルを作成すること。

    default_next: verify
    rules:
      - condition: output/ にレポートを書き出した
        next: verify

  - name: verify
    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: "..."})`
    default_next: COMPLETE
    rules:
      - condition: output/ にファイルがない、または内容に不足・誤りがある
        next: process
