boris-prompts

Boris スタイルのプロンプトライター

Boris（Anthropic の Claude Code の開発者）が「Pro Tips & Tricks」の講演で共有した手法を使って、あらゆる LLM や AI アシスタント向けの高品質なプロンプトを作成します。

このスキルが存在するのは、ほとんどのユーザーが、長すぎて細かく指示しすぎているうえ、本当に重要な要素（フィードバックループ、計画のステップ、適切な手がかり）が欠けたプロンプトを書くためです。Boris の手法はこれを逆転させます。プロンプトは短く保ち、モデルに探索させ、自分の作業を確認する手段を与え、繰り返し使うコンテキストは貼り直すのではなくファイルに保存します。原則は Claude Code 向けに開発されましたが、最新のあらゆる LLM（ChatGPT、Gemini、Cursor など）に応用できます。

使用するタイミング

次のいずれかに当てはまる場合、このスキルを呼び出してください。

• ユーザーが、あらゆる LLM や AI アシスタント向けのプロンプトの作成または改善を明示的に依頼した場合。
• ユーザーが自然言語でタスクを説明していて、次にプロンプトとして表現するのが妥当な場合。
• ユーザーが長いプロンプトを貼り付けて、うまく機能しない理由を尋ねたり、短縮または改良を依頼したりした場合。
• ユーザーが「どう表現すればいいですか」や「[モデル] に……を頼むには、どんな聞き方がよいですか」と尋ねた場合。

次の用途では呼び出さないでください。マーケティングコピーの作成、ユーザー向け UI テキストの作成、画像生成モデル向けプロンプトの作成。このスキルは、LLM や AI エージェントに向けた指示プロンプト専用です。

対象モデル — 汎用のアドバイスと Claude Code 固有のアドバイス

作成を始める前に、ユーザーが何に対するプロンプトを書こうとしているかを特定してください。

• Claude Code：すべてのツールキットが使えます — CLAUDE.md、@file 参照、スラッシュコマンド、commit, push, PR の省略表現、自然言語によるプランモード。
• Claude（claude.ai、API）：ほとんどの原則が当てはまりますが、@file や CLAUDE.md は使えません。永続的なコンテキストにはシステムプロンプトや Projects を使ってください。
• ChatGPT / Gemini / その他のチャット LLM：汎用の原則（簡潔さ、計画を先に立てること、フィードバックループ、冗長な説明を避けること）が当てはまります。CLAUDE.md は、そのモデルに相当する機能（Custom Instructions、システムプロンプト、Projects、Gems など）に置き換えてください。「コードベースを探索する」パターンは、モデルがそのためのツールを使える場合に限り機能します。
• Cursor / Windsurf / Copilot Chat：エディターに統合されており、@file（構文は異なります）、プロジェクト単位のルールファイル、計画を先に立てる方法が使えます。
• エージェントフレームワーク（自律型ツール）：監督なしで実行されるため、フィードバックループを重視してください。

対象が文脈から明らかでなく、プロンプトの内容に大きく影響する場合は、質問してください。

基本原則（優先順位順）

これらは Boris の講演から直接得られたものです。プロンプトを作成または評価するときは、この順序で適用してください。

1. 長いものより短いもの

通常、2 文に収まるプロンプトは、画面いっぱいに長いプロンプトよりもうまく機能します。理由は見た目ではありません。長いプロンプトはコンテキストウィンドウを消費し、Claude がすでに知っていることを繰り返し、解決策の幅を狭めすぎるためです。5 行を超えて書いている場合は、その半分を代わりに CLAUDE.md に入れられないか検討してください。

2. 「まず計画を立てる」は、最も費用対効果の高い追加事項

簡単ではないほとんどのプロンプトを、最も確実に改善できる方法は、次のような指示を付け加えることです。

「コードを書く前に、計画を立てて承認を求めてください。」

これは、モデルが指示されれば計画を立てる能力に優れており、悪い結果の多くが計画のステップを省くことで生じるためです。プランモード、特別なフラグ、システムプロンプトは必要ありません。平易な言葉で指示するだけで十分です。

3. 詳細をすべて指定せず、Claude に探索させる

既存のコードベースが関係するタスクでは、通常、解決策全体を説明するのではなく、適切な調査の出発点（「X の実装方法を確認してください」「この関数に 15 個の引数がある理由を git の履歴で調べてください」など）を Claude に示すべきです。Claude はパターンや類似コードを見つけるのが得意です。コードベースにすでに含まれている内容を改めて説明するのは無駄です。

4. フィードバックループは詳細な指示に勝ります

成果物を検証できる場合（UI がモックと一致する、テストに合格する、lint が通る、スクリーンショットが似ているなど）、プロンプトでは各手順をすべて指示するのではなく、Claude に検証方法を示すべきです。次のパターンです。

「X を実行してください。その後、[テストの実行／スクリーンショットの撮影／lint の実行] を行ってください。[成功基準] を満たすまで繰り返してください。」

モデルが正解をもとに自ら修正できるため、通常は数段落にわたる仕様書よりも効果的です。

5. 永続的なコンテキストはプロンプトではなくファイルや設定に記述する

同じアーキテクチャのメモ、スタイルルール、よく使うコマンドを毎回プロンプトに貼り付けているなら、それらは対象の永続的なコンテキスト機能に記述すべきです。

• Claude Code：./CLAUDE.md（プロジェクト用）、./CLAUDE.local.md（個人用）、~/.claude/CLAUDE.md（グローバル）、ネストされた CLAUDE.md（サブディレクトリ用）。
• Claude.ai：Projects、システムプロンプト。
• ChatGPT：Custom Instructions、Projects、システムプロンプト。
• Gemini：Gems、システム指示。
• Cursor / Windsurf：.cursorrules / .windsurfrules、プロジェクトごとのルール。
• API の使用：システムプロンプト、固定コンテキストブロック。

プロンプトでは背景ではなく、このタスク固有の内容を扱うべきです。

ワークフロー

ステップ 1 — 情報が十分かどうか判断する

プロンプトを書く前に、次の 4 つの質問に答えられる必要があります。不明な点があれば、作業を止めてユーザーに確認してください。

質問	重要な理由	変更される内容
このプロンプトの対象となるモデル／アシスタントはどれですか？（Claude Code、Claude.ai、ChatGPT、Cursor、Gemini など）	利用可能なモデル固有の機能（@file、CLAUDE.md、Projects など）が決まります	用語と参照先
成果物は何ですか？（Q&A／小規模な編集／新機能／バグ修正／リファクタリング／デバッグ／コーディング以外のタスク）	使用するテンプレートが決まります	テンプレートの選択
アシスタントは出力を自分で検証できますか？（テスト、スクリーンショット、lint、ビルド、ユーザーによる手動確認）	反復ループを追加するかどうかが決まります	「X を実行して繰り返す」という行
これは一度限りの作業ですか、それともアシスタントが先に計画を立てるべきですか？	単純な Q&A 以外のほとんどのタスクでは計画が役立ちます	「まず計画を立てる」という行
アシスタントが参照すべき既存のファイル、パターン、永続的なコンテキストファイル（CLAUDE.md、.cursorrules など）はありますか？	ファイル参照や「X の仕組みを確認する」という指示を追加するかどうかが決まります	コンテキストの参照先

ステップ 2 — 不明な点があれば、確認の質問を 1～3 個する

AskUserQuestion ツールを使います。質問は最大 3 個までです。それ以上質問すると、ユーザーは尋問されていると感じ、スキルのメリット（時間の節約）が失われます。

実際に不明な点に応じて、以下のメニューから質問を選びます。コンテキストからすでにわかっていることは質問しないでください。

対象のモデル／アシスタントが不明で、回答に影響する場合：

• 質問：「このプロンプトはどのアシスタント向けですか？」
• 選択肢：Claude Code（CLI）／Claude.ai（ウェブ／デスクトップ）／ChatGPT／Cursor または Windsurf／その他（指定してください）

成果物が不明な場合：

• 質問：「Claude に何をしてほしいですか？」
• 選択肢：コードに関する質問に回答する／小さな編集を行う／新機能を作る／バグを修正する／既存のコードをリファクタリングする

検証方法が不明な場合：

• 質問：「試行のたびに Claude に自分の作業を確認させられますか？」
• 選択肢：はい — テストがあります／はい — 視覚的に確認します（スクリーンショットを比較します）／はい — CLI／ビルド／リンターで確認できます／いいえ — 自分で確認します

作業範囲が不明な場合：

• 質問：「このタスクの規模はおおよそどのくらいですか？」
• 選択肢：1～2 行／数個のファイル／モジュール全体または機能全体／わかりません — Claude に調べてもらいたいです

計画の希望が不明な場合（成果物が小さな編集またはそれ以上の場合にのみ質問）：

• 質問：「Claude に最初に計画を提案させますか、それともすぐに試させますか？」
• 選択肢：まず計画を立ててから承認する／すぐに試してもらい、必要に応じて軌道修正する／計画のみ — まだコードは変更しない

コードベースの手がかりが不明な場合：

• 質問：「Claude が最初に確認すべき既存のファイルやパターンはありますか？」
• 選択肢：はい — @-メンションで指定します／git の履歴を確認する／類似機能を探す — Claude が見つけられます／いいえ、新規開発です

ステップ 3 — テンプレートを選んで内容を記入する

以下のテンプレートから、最も近いものを選びます。これらは Boris が日々の作業で使っているパターンを反映しています。

テンプレート A — コードベースに関する Q&A

[Question]. Look through git history if it helps.

例：

• Why does parseConfig take 12 arguments? Look through git history.
• How is the RateLimiter class actually used? Show me real call sites, not just text matches.
• What did I ship this week? Use my git username from the log.

テンプレート B — 小さな編集（1 ファイル、変更内容が明確）

[Task]. Make the change, then [verify].

例：

• Rename the env var DB_URL to DATABASE_URL everywhere it's used. After changing files, run the test suite.
• Add a "Cancel" button next to "Save" in @components/UserForm.tsx. Match the existing button styles.

テンプレート C — 中規模の編集、計画を先に立てる

[Task]. Make a plan and run it by me before writing code.

例：

• Replace the in-memory rate limiter with Redis. Plan first, then ask before changing files.
• The auth middleware is leaking session tokens in logs — fix it. Make a plan first.

テンプレート D — フィードバックループを使った構築／UI 作業

[Task]. Use [feedback tool] to check after each change. Iterate until [success criterion].

例：

• Implement the dark theme to match @design/dark-mock.png. Use puppeteer to screenshot the page, diff against the mock, iterate until visually close.
• Build the /pricing page from @design/pricing.fig export. Screenshot at desktop + mobile widths after each change. Iterate until both match.
• Make the failing tests in @tests/checkout.test.ts pass. Run the test suite after each change.

テンプレート E — 大きな機能、調査してから計画

[Feature]. First explore the codebase to find similar patterns. Then make a plan and ask for approval. After implementing, run [verification].

例：

• Add an audit log for all admin actions. First look at how existing logging works in the codebase, then propose a plan, ask before writing code. Once implemented, run the test suite.

テンプレート F — Git／GitHub の操作

commit, push, PR

この文言をそのまま使います。Claude は git log を読んでプロジェクトのコミット形式を確認し、必要であればブランチを作成してプッシュし、PR を作成します。細かく指定しすぎないでください。

テンプレート G — バグ修正（症状ではなく根本原因）

[Bug description, including how to reproduce]. Find the root cause, don't just patch the symptom. Make a plan first.

Step 4 — 追加の強化要素を加える（該当する場合）

こうした小さな追加要素は、手間以上の効果を発揮します。

追加する内容	使用するタイミング
@path/to/file.ts	特定のファイルがタスクの基準となる場合。
Look through git history	既存のコードの「理由」が重要な場合。
Don't change [X]	明確に変更してはいけない範囲を示したい場合（何を変更するかを肯定的に指定するより効果的です）。

Step 5 — 出力

ユーザーに次の2つを返します。

1. 最終的なプロンプト。コピーして使えるよう、フェンス付きコードブロックに入れます。
2. 1行の補足。プロンプトをこのように構成した理由（適用した原則を1～2個）を説明します。

該当する場合は、簡単なヒントを追加します。

• プロンプト内で同じアーキテクチャやスタイルに関する情報が2回以上参照されている場合は、それらをCLAUDE.mdに移すことを提案します。
• ユーザーが似たプロンプトを何度も作成しようとしている場合は、/slash-commandの作成を提案します。

出力例

以下は、このスキルが生成する内容の例です。プロンプトが短く、説明が1文であることに注目してください。

例1 — ユーザーの入力が具体的だった場合

ユーザー：「Claude CodeにExpressアプリへJWT認証を追加してほしい。テストもあります。」

スキルの出力：

Add JWT auth to the Express app. Look at how existing middleware is structured first, then make a plan and run it by me. After implementing, run the test suite and iterate until it passes.

テストスイートで検証できるため、テンプレートE（中規模の機能、調査＋計画＋フィードバックループ）を使用しています。

例2 — ユーザーの入力が曖昧で、スキルが質問した場合

ユーザー：「ClaudeにCSSを修正してもらうためのプロンプトを考えて」

スキルの質問：

• 「CSSのどこに問題がありますか？」— 選択肢：レイアウトが崩れている／色が間違っている／レスポンシブ表示の問題／分からない — Claudeに原因を調べてもらう
• 「Claudeは結果を視覚的に確認できますか？」— 選択肢：はい、スクリーンショットを撮る／はい、自分で目視する／ビジュアルリグレッションテストがある

ユーザーが回答した後（例：「モバイルでレイアウトが崩れる」＋「はい、スクリーンショットを撮る」）：

The mobile layout on @pages/Home.tsx is broken. Screenshot it at 375px wide using puppeteer, find what's off, fix it, and re-screenshot. Iterate until the layout looks right.

puppeteerを使えばClaudeが自分で結果を検証できるため、テンプレートD（フィードバックループ）を使用しています。

例3 — 既存のプロンプトの改善を依頼された場合

ユーザー：アーキテクチャの詳細やスタイルのルールが大量に含まれた、30行のプロンプトを貼り付ける

スキルの応答：再利用可能なコンテキスト（アーキテクチャ、スタイル、共通コマンド）に当たる部分を特定し、プロンプト自体はタスクに集中させたまま、CLAUDE.mdに移すことを提案します。

Implement the payment retry logic described in @docs/retry-spec.md. Plan first, ask before writing code, then run the test suite.

元のプロンプトは30行で、そのうち25行はCLAUDE.mdに記載すべき、繰り返されていたアーキテクチャやスタイルの情報でした。タスク固有の部分だけを残しました。

アンチパターン（避けること）

• 丁寧すぎる前置き（「どうか、～を手伝っていただけませんか」など）。コンテキストを無駄にするだけで、モデルには関係ありません。直接的な動詞を使ってください。
• すべてのプロンプトに同じアーキテクチャやスタイルに関するメモを貼り付けること。CLAUDE.mdに一度だけ記載してください。
• 検証手段があるタスクに、長い手順を列挙すること。代わりに検証手段を伝えて、モデルに反復してもらいましょう。
• 3,000行規模の機能を一度に作ろうとすること。まず計画を立ててレビューし、その後段階的に実装するよう依頼してください。
• ユーザーの時間を節約するために、200行の「完璧なプロンプト」を生成すること。このスキルの目的は、プロンプトを短くすることです。出力がユーザーの質問より長いなら、やり方を間違えています。

このスキルが引き継ぐべき場合

このスキルはプロンプトを作成するものであり、実行はしません。プロンプトを作成した後は、次のようにします。

• 通常、ユーザー自身がプロンプトをClaude Codeにコピーします。
• ユーザーが「今すぐ実行して」と依頼した場合、それは別のタスクになるため、このスキルの作業は終了です。