name: general description: | 汎用タスク実行。ファイル編集、コード生成、翻訳、文書作成など、 他の専門ピースに該当しないあらゆるタスクを処理する。 調査が含まれる場合でも、主目的がファイル生成・編集であればこちらを選ぶ。 このピースは最後のフォールバックとしても機能する。 max_movements: 999 initial_movement: execute movements: - name: decompose edit: false persona: orchestrator instruction: | 入力把握で決めた並列調査計画に従い、各テーマをサブタスクとして登録する。 手順: 1. 入力把握で立てた計画を思い出す（ファイル読み込みは不要） 2. 各テーマに対して SpawnSubTask を呼び出す（2〜5 個程度） - title: テーマを簡潔に（例:「A社の製品ラインアップ調査」） - instruction: 何を調べて output/result.md にどう書くかを具体的に記述 - piece: 調査系は "research-sub"、汎用作業は "general"（サブタスクからさらに分解しないこと） 3. 全サブタスクの登録が完了したら WAIT_SUBTASKS に遷移する ## instruction の書き方例 「〇〇について調査し、output/result.md に以下を含めてまとめてください: - 概要と主要な特徴 - メリット・デメリット - 具体的な数値・事例（可能な限り）」 allowed_tools: [SpawnSubTask] default_next: aggregate rules: - condition: 全サブタスクを SpawnSubTask で登録し終えた next: WAIT_SUBTASKS - condition: 全てのサブタスクを登録し終えた（SpawnSubTask不可の場合は自分で分析を完了した） next: aggregate - name: aggregate edit: true persona: analyst instruction: | 各サブタスクの結果が subtasks/ ディレクトリに格納されています。 手順: 1. Glob で subtasks/*/result.md を確認する 2. 各 result.md を Read で読み込む 3. subtasks/*/output/ も確認して追加の成果物があれば Read する 4. 全結果を統合して output/report.md に最終レポートを作成する - 各サブタスクの主要な知見を統合（矛盾・重複は整理） - 全体のまとめと結論を付ける 5. output/report.md を書き終えたら verify へ遷移する allowed_tools: [Read, Glob, Grep, Write, Edit, SearchNotes, ReadNote, WriteNote, 'mcp__*'] default_next: verify rules: - condition: output/report.md に統合レポートを作成した next: verify - name: execute edit: true persona: worker instruction: | ## 最初のステップ: 入力把握 作業に着手する前に、まずタスクの全体像を把握する: 1. Glob でワークスペース全体のファイル一覧を確認する（input/ だけでなくルート直下も含む） 2. 指示で言及されているテキストファイルがあれば Read で内容を把握する - 画像・PDF・Office ファイル等は専用ツールを使う（カタログ参照、詳細は ReadToolDoc） 3. 不明点があれば WebSearch/WebFetch で調べる 4. 「今日のニュース」「最新動向」など時刻依存の依頼は、必ず最初に WebSearch を実行する ## 並列分解の判断 以下の場合は decompose を積極的に検討する: - 複数の独立した調査対象がある（例: 3社の比較調査、複数トピックのリサーチ） - 各調査が互いに依存せず、結果を最後に統合すればよい - 全体を 1 回の execute で処理すると context が溢れるリスクがある decompose を使わない場合: - 単一テーマの作業（ファイル編集、1 つの調査など） - 各ステップが前のステップの結果に依存する逐次的な作業 方針に従って作業を実行する。 ## 検索の原則 【必須】事実・知識に関する内容を書く場合は、必ず WebSearch/WebFetch で検索して裏付けを取ること。 モデルの内部知識だけで回答を構成しない。output/ に既存ファイルがある場合もその内容を鵜呑みにせず、検索で確認すること。 【追加質問への対応】前回の調査結果や output/ の既存ファイルが存在する場合でも、ユーザーの追加質問への回答には必ず WebSearch で最新情報を改めて確認すること。前回の調査結果に依存して検索を省略しない。 ## ファイル操作のルール - リポジトリ内の既存ファイルの編集指示（例: README.md を編集）の場合は、そのファイルを直接 Write で上書きする - 新規ファイル作成の場合は output/ に書き出す - テキストで回答するだけでは不十分。必ずファイルを作成または編集すること - 前のステップから指摘事項がある場合は、それに対応すること - 「これまでのレビュー指摘」「現在の変更状況」「変更差分」の付録がある場合は、そこに書かれた不足点から優先的に解消すること - 指摘事項は「問題点」「期待する修正」「合格基準」まで含めて渡される。各項目を漏れなく解消すること ## 成果物への画像埋め込み（必須） Markdown レポートや成果物を作成する場合、関連する画像は積極的に収集・埋め込むこと。 テキストだけで説明するより、画像を添えた方がわかりやすい場合は必ずビジュアル素材を用意する。 画像の準備パターン: - input/ にある画像 → Bash の cp で output/images/ に複製 - Web 上の図・グラフ・スクリーンショット → DownloadFile で output/images/ に保存 - データ分析で生成したグラフ（Bash + matplotlib 等） → output/images/ に保存 埋め込み方法: `![説明](./images/ファイル名.png)` 画像があるのにテキストだけのレポートにしないこと。 ## 一次情報へのアクセスと捏造禁止（厳守） - YouTube 動画の内容を扱う場合は、必ず GetYouTubeTranscript で字幕を取得してから作業する - 一次情報（動画字幕、論文本文、ページ本文等）に直接アクセスできなかった場合: - Web 検索の断片的な情報から内容を推測・捏造してはならない - アクセスできなかった旨を明記し、取得できた範囲の情報のみで成果物を作成する - 推測部分は「推測」と明示する - 二次情報（ブログ記事、要約サイト等）から得た情報は、一次情報ではないことを明記する ## 終了 / 遷移方法 - **次の verify へ**: `transition({next_step: "verify"})` - **並列分解が効率的 → decompose へ**: `transition({next_step: "decompose"})` - **必須情報が不足し確認が必要**: `complete({status: "needs_user_input", missing_info: "...", why_no_default: "..."})` - **技術的失敗で打ち切り**: `complete({status: "aborted", abort_reason: "..."})` allowed_tools: [Read, Write, Bash, Glob, Grep, WebSearch, WebFetch, BrowseWeb, DownloadFile, ReadImage, AnnotateImage, ReadPdf, PdfToImages, BatchReviewTextWithLLM, MergeReviewedResults, SearchPlaces, GetDirections, ReverseGeocode, GetYouTubeTranscript, SearchYouTube, SearchAmazon, TranscribeAudio, SearchKnowledge, ListNamespaces, ListDocuments, IngestDocument, IngestStatus, SearchNotes, ReadNote, WriteNote, SearchMicrosoftLearn, FetchMicrosoftLearn, SearchMicrosoftLearnCache, RefreshMicrosoftLearnCache, 'mcp__*'] default_next: verify rules: - condition: 2つ以上の独立したテーマがあり、並列分解が効率的と判断した next: decompose - condition: output/ にファイルを書き出した next: verify - name: verify edit: false persona: reviewer instruction: | 成果物を確認する。 確認手順: 1. まず Glob でワークスペース全体の変更を確認する（output/ と、指示で編集対象だったファイル） 2. 成果物が1つもなければ「修正が必要」と判断し execute に差し戻す 3. ファイルがあれば Read で内容を確認し、指示通りか・品質は十分かをチェックする 4. 不足や誤りがあれば、`transition({next_step: "execute", summary: ...})` で差し戻す。summary は次の形式で書く: [判定] needs_fix ## 問題点 - [ファイル名:行番号または項目名] 何が問題か ## 期待する修正 - 何をどう直すべきか ## 合格基準 - 再レビューで何を確認するか ## 次にやること - execute で最初に着手すべき具体的な修正 5. summary は抽象論で終えず、変更ファイル・不足点・期待する修正内容を必ず含める 6. 外部確認・一次情報照会が必要な場合は、まず自分で WebSearch / WebFetch で簡易チェックする。深い追加調査が必要な場合は、確認すべき情報源と修正内容を summary に明記して execute に差し戻す 追加チェック（追加質問への回答）: - ユーザーの追加質問（前回タスクへの補足・深掘り）への回答が含まれる場合、その内容に WebSearch/WebFetch による検索の裏付けがあるか確認する。内部知識だけで回答している形跡がある場合は「追加質問への回答に検索根拠が不足」として execute に差し戻す 追加チェック（画像）: - input/ または output/images/ に画像があるのにレポートに `![` が一つもない場合、 画像埋め込み漏れとして execute に差し戻す - 画像の相対パスが正しいか（output/images/ に実ファイルがあるか）確認する ## チェックシート確認 GetChecklist でチェックシートが存在する場合、全アイテムが完了（done/failed/skipped）していることを確認する。 remaining が 0 でないまま完了してはならない。 ## 合格時のユーザーへの返答（complete ツール） 合格と判断したら、`complete({status: "success", result: ...})` を呼ぶ。 result はそのままユーザーに表示される最終回答。output/ のファイルを Read で読み、その内容をベースに整形する。 - 「output/xxx.md を確認してください」のようなファイル参照ではなく、内容そのものを回答として返すこと - 【厳守】「✅ 完了」「成果物を作成しました」「確認しました」等のステータス表示・メタ説明・内部作業の報告は一切書かない。1行目からいきなり本題の内容を書き始めること - 成果物の内容を会話調で分かりやすく伝える - 表・リスト・見出しなど Markdown 書式を活用して読みやすくする - 長大な成果物の場合は要点を構造化して提示し、詳細は省略してよい - 補足や注意点があれば末尾に添える ## 終了方法のまとめ - 合格: `complete({status: "success", result: "ユーザー向け最終回答"})` - 修正必要: `transition({next_step: "execute", summary: "差し戻し指摘"})` (上記形式で) - 技術的失敗: `complete({status: "aborted", abort_reason: "..."})` allowed_tools: [Read, Glob, Grep, WebSearch, WebFetch, ReadImage, AnnotateImage, ReadPdf, ReadExcel, ReadDocx, ReadPPTX, SearchNotes, ReadNote, SearchMicrosoftLearn, FetchMicrosoftLearn, SearchMicrosoftLearnCache, RefreshMicrosoftLearnCache] default_next: COMPLETE rules: - condition: 成果物がない、または内容に不足・誤りがある（追加質問への回答に検索根拠が不足している場合も含む） next: execute