$ man context-wiki/agent-mode

エージェントモードはデフォルトの実行モードだ。Claude がファイルを読み、コードを書き、ターミナルコマンドを実行し、新しいファイルを作成し、既存のファイルを修正し、機能をエンドツーエンドで構築する。実際に仕事が片付くモードだ。Joe Rhew はこれを「オンボーディングが必要なチームメイト」と表現した。これは正しいメンタルモデルだ。プロダクト、ペルソナ、メッセージングのコンテキストなしに新入社員を GTM オペレーションに放り込むことはしないだろう。エージェントも同じだ。エージェントモードのアウトプットの質は、実行開始前に提供するコンテキストに完全に依存する。

パターン

エージェントモードの各セッションを、新しいチームメイトのオンボーディングだと考える。何を知る必要があるか？プロダクト（何を誰に売っているか）。ボイス（どうコミュニケーションするか）。ワークフロー（どう業務が回るか）。制約（何を避けるか、どのフォーマットに従うか）。オンボーディングをスキップすれば、エージェントは仮定を立てる。当たるものもある。多くは外れる。最悪なのは、エージェントモードの仮定が自信に満ちて見えることだ。アウトプットの読み心地はいい。ただ、現実と合っていないだけだ。コンテキストを先に投入する。エージェントに推測ではなく、知識に基づいて実行させる。

プロのコツ

複雑なタスクでプランモードをスキップすると、エージェントモードは突き進んで仮定を立てる。代替案を評価せずにアプローチを選ぶ。類似ファイルの存在を確認せずに新しいファイルを作る。動くがアーキテクチャに合わないコードを書く。先に計画していれば、エージェントモードはきれいに実行する。計画に従う。正しい場所に正しいファイルを作る。すでに確立されたパターンを使う。計画は時間の無駄ではない。エージェントモードを効果的にするコンテキストだ。

アンチパターン

曖昧な指示を出して具体的なアウトプットを期待する。「サイトの見た目を良くして」はアクション不可能だ。「ヒーローセクションの背景をダークにし、見出しのフォントサイズを 3rem に増やし、2rem のパディングを追加して」はアクション可能だ。 変更を求める前に関連ファイルを読み込まない。Claude に既存のコードパターンと合わせてほしいなら、まず既存のコードを読ませること。 エージェントモードをアウトプットを確認せずに長時間走らせる。主要なステップごとにレビューする。早めに軌道修正する。ステップ 1 での小さな誤解が、ステップ 10 までに大きな問題に膨れ上がる。