maestro/pieces/general.yaml
oss-sync b1292e34b2
Some checks failed
CI / build-and-test (push) Has been cancelled
sync: update from private repo (edc775f2)
2026-07-06 01:04:12 +00:00

169 lines
12 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

name: general
description: |
汎用タスク実行。ファイル編集、コード生成、翻訳、文書作成など、
他の専門ピースに該当しないあらゆるタスクを処理する。
調査が含まれる場合でも、主目的がファイル生成・編集であればこちらを選ぶ。
このピースは最後のフォールバックとしても機能する。
max_movements: 999
initial_movement: execute
movements:
- name: delegate_research
persona: orchestrator
instruction: |
入力把握で立てた分割調査計画に従い、各テーマを delegate で1件ずつ直列に
深掘りさせ、最後に統合レポートにまとめる。重い調査は各サブに任せ、
自分の文脈は軽く保つ。
手順:
1. 入力把握で立てた調査テーマを思い出す2〜5 個程度)。各テーマに上から
1 始まりの連番を振る1, 2, 3 ...)。
2. 各テーマについて delegate を1回ずつ呼ぶ1件ずつ順番に・直列
delegate の prompt には必ず次を自己完結で書く(サブは独立した文脈で動くため、
このタスク全体の背景・目的を要約して渡す):
- 調べる/作業するテーマと目的・背景
- 「WebSearch / WebFetch / 一次情報で裏を取る。モデルの内部知識だけで書かない」指示
- 「概要・主要な特徴・数値や事例・まとめと考察 の構成で
output/research/theme-{連番}.md に Write せよ。関連する画像・グラフは
output/images/ に保存し Markdown で埋め込め」指示
- 「完了したら 3〜5 行の要約だけを返せ。本文は返さずファイルに書け」
- 「あなたは末端の担当。delegate / SpawnSubTask は呼ぶな」
各サブの戻り値(短い要約)だけが手元に残る。本文はファイルにある。
3. Glob で output/research/*.md の件数を確認する。
4. 各サブの要約とファイルを基に統合レポートを output/report.md に Write する:
- 各テーマの主要な知見を統合(矛盾・重複は整理)
- 比較・対照が必要なら表形式で整理
- 全体のまとめと結論を付ける
- 各テーマの詳細へ相対リンク [theme-{連番}](./research/theme-{連番}.md) で繋ぐ
5. output/report.md を書き終えたら verify へ遷移する
default_next: verify
rules:
- condition: output/report.md に統合レポートを作成した
next: verify
- name: execute
persona: worker
instruction: |
## 最初のステップ: 入力把握
作業に着手する前に、まずタスクの全体像を把握する:
1. Glob でワークスペース全体のファイル一覧を確認するinput/ だけでなくルート直下も含む)
2. 指示で言及されているテキストファイルがあれば Read で内容を把握する
- 画像・PDF・Office ファイル等は専用ツールを使う(カタログ参照、詳細は ReadToolDoc
3. 不明点があれば WebSearch/WebFetch で調べる
4. 「今日のニュース」「最新動向」など時刻依存の依頼は、必ず最初に WebSearch を実行する
## 分割調査の判断delegate_research
以下の場合は delegate_research を積極的に検討する:
- 複数の独立した調査対象がある(例: 3社の比較調査、複数トピックのリサーチ
- 各調査が互いに依存せず、結果を最後に統合すればよい
- 全体を 1 回の execute で処理すると context が溢れるリスクがある
delegate_research では各テーマを delegate に1件ずつ任せ、本文はファイルに書かせて
自分の文脈を軽く保つ。直列実行)
delegate_research を使わない場合:
- 単一テーマの作業ファイル編集、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"})`
- **分割調査が効率的 → delegate_research へ**: `transition({next_step: "delegate_research"})`
- **必須情報が不足し確認が必要**: `complete({status: "needs_user_input", missing_info: "...", why_no_default: "..."})`
- **技術的失敗で打ち切り**: `complete({status: "aborted", abort_reason: "..."})`
default_next: verify
rules:
- condition: 2つ以上の独立したテーマがあり、分割して delegate に任せるのが効率的と判断した
next: delegate_research
- condition: output/ にファイルを書き出した
next: verify
- name: verify
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: "..."})`
default_next: COMPLETE
rules:
- condition: 成果物がない、または内容に不足・誤りがある(追加質問への回答に検索根拠が不足している場合も含む)
next: execute