Dryrun

効果

計画段階で「本当にこれでいける？」を 最小コストで検証 する。頭の中の設計と現実のギャップを、本実装の前に発見する。

Plan だけでは見えない問題がある。かといって全部作ってから「ダメだった」は痛すぎる。Dryrun はその間を取る。

2つのモード

Code Dryrun（従来）

最小の使い捨てコードで技術的な検証を行う。「この API は想定通り動くか」「この構成でコンテナが起動するか」。

Dialog Dryrun（新）

Agent 間の対話フローや連携設計をシミュレートして、役割分担の穴を見つける。コードを書かずに「この Agent にこう頼んだら、何が返ってくるか」を想定する。

適用条件

Code Dryrun:

• 未知の技術・API を使う前
• 複雑な依存関係がある実装の前
• 「たぶん動くはず」に確信が持てないとき

Dialog Dryrun:

• 新しい Agent / しもべの設計時
• Agent 間の連携フローを設計するとき
• 「この Agent にこう頼んだら、ちゃんと動くか」が不明なとき
• 既存の Agent の改善ポイントを探すとき

共通:

• 計画の分岐点（このアプローチで行くか迷っている）

手順

1. 検証したいことを1つに絞る

Code: 「この API は想定通りのレスポンスを返すか」 Dialog: 「この Agent にレビューを頼んだら、不明点を聞き返してくれるか」

2. 最小コストで試す

Code: 使い捨ての検証コード。完璧さは不要。 Dialog: 実際のシナリオを想定して対話を脳内シミュレート。「エリス → harness: こう頼む → harness はこう動く → ここで穴がある」

3. 結果を判断に使う

• 動いた/流れた → 本実装/本運用に進む（自信を持って）
• 問題が見つかった → 原因を特定。設計を修正してから進む
• 想定外の発見 → 計画に反映（これが一番価値がある）

組み合わせ

カード	シナジー
Dev-Flow	計画→実装の間に Dryrun を挟む判断ポイントがある
Devil / Devil Gate	Dryrun の結果を Devil で検証 → 本実装の品質が上がる
Reflect	Dryrun で得た「想定外の発見」を知識DB に蓄積
Ctx	Dialog Dryrun の結果を ctx に記録 → 次のセッションで改善を継続

---

「…考えるだけじゃ見えないものがある。手を動かしなさい、ただし最小限で。対話を想像しなさい、ただし具体的に」 — Eris

このカードを常用したくなったら → そのまま SKILL.md に変換できる。効果=概要、適用条件=発動トリガー、手順=手順セクション。