Claude Codeへの長い指示を、チャット欄ではなく tmp/*.md に置くようになった

AIへの指示をどこに書くか。この一見単純なことが、実は Prompt Engineering の捉え方を変えた。長い依頼を今はチャット欄に直接打たず、tmp ディレクトリの Markdown ファイルに先に書き、読み返してから渡すようにしている。大した工夫ではないのだが、この運用を始めてから、プロンプトの見方が変わった。「魔法の一文を探す作業」ではなく、「曖昧な仕事を構造化する作業」だと思うようになったのだ。

チャット欄に直接書かない理由は5つある。第一に、長い依頼には構造が必要で、見出しと表で階層を作れるのはテキストエディタの方が効率的だ。第二に、渡す前に一度読み返すことで、矛盾した指示やまだ決めていないことが見つかる。これが一番効いた。チャット欄だと書いた瞬間に送ってしまい、途中で気づいたことを直しにくい。第三に、修正箇所を一つのファイルとして見直す方が、会話の流れの中で言い直すより見やすい。第四に、Non-goals（やらないこと）を指示書に書いておくと、そこを越えるときにAIが聞いてくる。会話の流れの中の注意書きは後半で忘れられる。第五に「ここで一度止まる」という指示が書ける。これが意外と大きい効果を生む。

例えば「8本の記事を書く」という仕事でも、いきなり8本は書かない。まず調査ファイルを1つ作成して、そこで一度確認する。こうすることで、調査の前提が違ったまま全体を書き進める失敗を防げる。実際、この方法で「開発履歴が複数のリポジトリに分かれていて、公開リポジトリには部分的にしか無い」という重要な発見が調査段階で出てきた。ここを知らずに書き始めていたら、全部書き直しになっていた。会話は基本的に「最後まで進む」方向に働くため、チャットの往復では「ここで止まる」という指示は書きにくい。

注意が必要な落とし穴が2つある。第一に、tmp ディレクトリは Git で追跡されないので、そこで決めたことは消える。決定が生まれたら、Issue や ADR など追跡される場所へ移す必要がある。古い記述は読めば違和感があるが、書かれなかったことは読んでも気づけない。第二に、指示書の書式がそのまま実装に漏れることがある。Markdown のプレーンテキストに箇条書きの記号として - を置いていたら、それが CSS でそのまま再現されてしまった。指示書では「これは構造を示しているだけで、見た目は任せる」と「ここは見たままに作ってほしい」を明確に分ける必要がある。結局これは、どの層に安全性を置くかという問題だ。最も手前で寿命の短い層である tmp 指示書から生まれた決定は、上位の層へ昇格してから捨てる。この片付けまでが一連の仕事になる。