96 lines
5.8 KiB
YAML
96 lines
5.8 KiB
YAML
name: brainstorming
|
||
description: |
|
||
複数の視点から並列にアイデアや選択肢を検討し、推奨方針を導き出す。
|
||
選ぶべき場合: 「どうすべきか」「どの方針が良いか」を多角的に検討する必要がある
|
||
選ぶべきでない場合: 答えが調査で明確になるタスク、具体的な成果物の作成が主目的
|
||
max_movements: 999
|
||
initial_movement: delegate_research
|
||
|
||
triggers:
|
||
keywords:
|
||
- brainstorming
|
||
- ブレスト
|
||
- ブレインストーミング
|
||
- 方針検討
|
||
- アイデア出し
|
||
|
||
movements:
|
||
- name: delegate_research
|
||
persona: facilitator
|
||
instruction: |
|
||
課題を複数の視点に分解し、各視点を delegate で1件ずつ直列に検討させ、
|
||
最後に推奨方針へ統合する。重い検討は各サブに任せ、自分の文脈は軽く保つ。
|
||
|
||
手順:
|
||
1. タスクの指示を注意深く読み、検討すべき視点や切り口を 2〜5 個に分解する。
|
||
- 例: 技術的実現性、コスト/リソース、ユーザーへの影響、リスク、長期的な拡張性
|
||
各視点に上から 1 始まりの連番を振る（1, 2, 3 ...）。
|
||
2. 各視点について delegate を1回ずつ呼ぶ（1件ずつ順番に・直列）。
|
||
delegate の prompt には必ず次を自己完結で書く（サブは独立した文脈で動くため、
|
||
このタスク全体の背景・目的を要約して渡す）:
|
||
- 検討する視点（分析レンズ）と、課題の目的・背景
|
||
- 「この視点で分析し、結論と根拠を出す。WebSearch / WebFetch / 一次情報で
|
||
裏を取り、モデルの内部知識だけで書かない」指示
|
||
- 「結論・根拠・メリット/デメリット・リスクの構成で
|
||
output/research/perspective-{連番}.md に Write せよ」指示
|
||
- 「完了したら 3〜5 行の要約だけを返せ。本文は返さずファイルに書け」
|
||
- 「あなたは末端の担当。delegate / SpawnSubTask は呼ぶな」
|
||
各視点が異なる分析レンズを持つよう明確に指定する。
|
||
各サブの戻り値（短い要約）だけが手元に残る。本文はファイルにある。
|
||
3. Glob で output/research/*.md の件数を確認する。
|
||
4. 各サブの要約とファイルを基に推奨方針を output/recommendation.md に Write する:
|
||
- 各視点からの主要な発見
|
||
- 共通点・相違点・トレードオフの整理
|
||
- 推奨アプローチとその根拠
|
||
- リスクと緩和策
|
||
- 各視点の詳細へ相対リンク [perspective-{連番}](./research/perspective-{連番}.md) で繋ぐ
|
||
5. output/recommendation.md を書き終えたら verify へ遷移する
|
||
default_next: verify
|
||
rules:
|
||
- condition: "output/recommendation.md に推奨方針をまとめた"
|
||
next: verify
|
||
|
||
- name: verify
|
||
persona: reviewer
|
||
instruction: |
|
||
output/ の成果物を確認する。
|
||
|
||
確認手順:
|
||
1. まず Glob で output/ 内のファイル一覧を確認する
|
||
2. output/recommendation.md がなければ「修正が必要」と判断し delegate_research に差し戻す
|
||
3. ファイルがあれば Read で内容を確認し、各視点の分析が含まれているか・推奨方針が論理的かをチェックする
|
||
4. 不足や誤りがあれば、`transition({next_step: "delegate_research", summary: ...})` で差し戻す。summary は次の形式で書く:
|
||
[判定] needs_fix
|
||
## 問題点
|
||
- [ファイル名:行番号または項目名] 何が問題か
|
||
## 期待する修正
|
||
- 何をどう直すべきか
|
||
## 合格基準
|
||
- 再レビューで何を確認するか
|
||
## 次にやること
|
||
- delegate_research で最初に着手すべき具体的な修正
|
||
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: "delegate_research", summary: "差し戻し指摘"})` (上記形式で)
|
||
- 技術的失敗: `complete({status: "aborted", abort_reason: "..."})`
|
||
# default_next is the engine-internal fallback (context overflow / ASK
|
||
# limit / SpawnSubTask unavailable). Not exposed to the LLM.
|
||
default_next: COMPLETE
|
||
rules:
|
||
- condition: output/ にファイルがない、または内容に不足がある
|
||
next: delegate_research
|