プロジェクト指示ビルダー

毎リクエストで支払うトークンに見合う指示ファイルを書きます。

プロジェクト指示にはチームの働き方が書かれます。ファイルはブラウザー内で組み立てられ、送信されません。

長いセッションでの費用を見る

プロジェクト指示ビルダー について

プロジェクト指示ファイルはセッションのたびに冒頭で読まれます。つまりファイルが存在するかぎり、その一行一行がすべてのリクエストで支払われます。この一点だけで、何を書くべきで何を書くべきでないかが決まります。コードを読めば分かること——言語、フレームワーク、ディレクトリ構成——は、すでにそれが見えている読み手に言い直しているだけです。書く価値があるのは逆のものです。オプションが要るテストコマンド、ビルドを壊す Node のバージョン、新しく来た人なら取り違える慣習、すでに誰かの午後を一つ奪ったこと。このビルダーはその区分に沿って構成され、ファイルの費用を見積もり、リポジトリに自分自身のことを語っている行を指摘します。

機能

• 白紙ではなく、何を書くべきかで導かれる節
• 進行中のトークン見積り — 一度きりではなく毎リクエストの費用
• コードがすでに示していることを繰り返す行を指摘
• 何も変えない空虚な訓辞を指摘
• 流し読みされる大きさに達したら警告
• 刈り込むための見出しが無い場合に注記
• 空の節は白紙で書き出さず省略
• CLAUDE.md として保存

プロジェクト指示ビルダー の使い方

1. プロジェクト名を書きます
2. 自明でないことを言える節だけを埋めます
3. 増えていくトークン見積りに目を配ります
4. 警告を読み、ファイルを保存します

例

入力

This project is a React app.

出力

Warning: the language and framework are visible from the manifest

一行ごとの試金石。読み手は十秒でこれを調べられるか？

よくあるエラーとトラブルシューティング

• ファイルが大きすぎると指摘される。 — たまにしか関係しないものは、必要なときに読める別文書へ移してください。指示ファイルは常に真であることのためのものです。
• 残したい行が「調べれば分かる」と指摘された。 — 本当に効いているなら無視してください。この確認は「読み手はどのみち分かるのでは」と問い直す促しであって、規則ではありません。
• 指示を足しても何も変わらない。 — 具体的で検証できる指示のほうがはるかによく効きます。「きれいなコードを書く」より「components/ui のプリミティブを使う」です。
• CLAUDE.md にすべきか、別名にすべきか。 — 中身は同じです。お使いのツールが読む名前で保存してください。構成と、何を入れるかの節度は変わりません。

よくある質問

指示ファイルには実際のところ何を書くべきですか。

コードからは分からず、放っておけば取り違えられることです。オプションが要るコマンド、ビルドを壊すバージョン、どの単一ファイルにも現れない慣習、そして明示的な禁止事項。それ以外は、すでに読める読み手への言い直しです。

どのくらいの長さが適切ですか。

まだ読まれる程度に短く。見積りは入力しながら表示されます。数千トークンを超えたら、どの行が本当に常に関係するかを問う価値があります。残りは必要時に読む文書に置けます。

なぜ「きれいなコードを書く」が指摘されるのですか。

何も変えないからです。一般的な訓辞は毎リクエストでトークンを費やしながら判断の根拠を与えません。具体的な慣習——ロジックをどこに置くか、どのプリミティブを使うか——は根拠になります。

毎リクエストで支払うことは重要ですか。

まさにそれが刈り込む理由です。一ページの指示は一度なら小さな費用ですが、数千リクエストでは相応の額になります。だから見積りは隠さず本文の横に置いてあります。

認証情報を書いてもよいですか。

いけません。セッションごとに文脈へ読み込まれ、たいていリポジトリに入ります。認証情報は環境に置き、指示で触れる必要があるなら名前で参照してください。

関連ツール

• スキルビルダー — SKILL.md を作成し、frontmatter を入力しながら検証します。
• サブエージェントビルダー — ツールとモデルを指定してサブエージェント定義ファイルを作ります。
• スラッシュコマンドビルダー — 引数とツール許可リストを備えた独自コマンドを作ります。
• コンテキストウィンドウ設計 — ウィンドウをプロンプト、ツール、履歴、応答に配分します。
• プロンプトキャッシュ設計 — キャッシュできる接頭辞が最長になるようブロックを並べ替えます。
• システムプロンプトリンター — 矛盾、効かない指示、未置換のプレースホルダーを見つけます。

AI・エージェントの他のツール

• スキルビルダー — SKILL.md を作成し、frontmatter を入力しながら検証します。
• スキルリンター — SKILL.md を貼り付け、タスクに一致しない理由を確かめます。
• サブエージェントビルダー — ツールとモデルを指定してサブエージェント定義ファイルを作ります。
• スラッシュコマンドビルダー — 引数とツール許可リストを備えた独自コマンドを作ります。
• プラグインマニフェスト — plugin.json を生成し、前提となるフォルダ構成を確認します。
• フックビルダー — settings.json のフックを作り、発火しないマッチャーを見つけます。
• 権限ルールテスター — 許可・確認・拒否のルールを実際のコマンドで試します。
• MCP サーバー設定 — stdio、HTTP、SSE 向けの MCP サーバー設定を生成します。
• MCP ツールスキーマ — ツールを定義し、strict モードを検証した JSON Schema を得ます。
• ツールスキーマ検証 — 定義を貼り付け、拒否される理由や誤呼び出しの原因を調べます。
• プロンプトテンプレート展開 — 一つのプロンプトを行の表に展開し、欠けている値を確認します。
• システムプロンプトリンター — 矛盾、効かない指示、未置換のプレースホルダーを見つけます。
• プロンプト差分 — 二つの版を単語単位で比較し、トークン差も表示します。
• Few-shot 例ビルダー — 入出力の組をタグ付き、JSON、会話形式の例に変換します。
• XML プロンプト構成 — 内容が外に漏れないタグでプロンプトの各節を囲みます。
• JSONL ビューア・検証 — JSONL ファイルを行単位で読み、絞り込み、検証します。
• 会話ログ変換 — メッセージ配列を読みやすい記録に変換し、元にも戻します。
• 学習データ検証 — 学習を途中で止めるエラーがないか chat 形式の JSONL を調べます。
• SSE ストリームビューア — 生のストリーミング応答から本文、ツール呼び出し、使用量を取り出します。
• コンテキストウィンドウ設計 — ウィンドウをプロンプト、ツール、履歴、応答に配分します。
• プロンプトキャッシュ設計 — キャッシュできる接頭辞が最長になるようブロックを並べ替えます。
• テキスト分割 — 実際の切れ目で分かれる重なり付きのチャンクに文書を分けます。
• エージェントループ費用 — 再送される履歴とキャッシュを含めてターンごとに費用を見積もります。
• バッチリクエストビルダー — 行の表をバッチ処理に変換し、各リクエストに一意の ID を付けます。

AI・エージェントのツールをすべて見る · すべてのツール