Communityライティング&編集github.com

Barncore/prompting-agents

別のAIが実行するテキストを作成します。サブエージェントのプロンプト、別のセッション用のプロンプト、ハンドオフ、外部AIへのメッセージ、自律実行用のブリーフ、スキルやCLAUDE.mdの作成・改善時、または読み手のモデルと努力レベルの選択時に使用します。プロンプトの説明には使用しません。

prompting-agents とは?

このスキルは、別のAI(サブエージェント、別セッション、外部AIなど)が実行するためのテキストを作成・改善するための体系的なフレームワークを提供します。読み手のAIはあなたのコンテキストを持たないことを前提とし、最終状態とその理由を明示することで、AIが自律的に経路を計画できるようにします。コアとなる原則として、タスクから導出可能な情報は記述せず(ライン・テスト)、プロンプトは自己完結型にし、理由を肯定的に記述し、禁止事項よりも目標行動を中心に据えます。また、プロンプトの構造は意図、終了状態、ハード制約、チェックポイント、自由条項、レシートの6要素で構成され、順序が重要な場合にのみチェックリストを使用します。Claude CodeやCoderなどのAIエージェントプラットフォームで使用することを想定しており、スキルの作成時にはAnthropicの`skill-creator`も参照します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Barncore/prompting-agents/tree/HEAD

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

エージェントへのプロンプティング

読み手は有能なモデルですが、あなたのコンテキストは一切持っていません。最終的に何が成立していなければならないか、その理由を述べ、経路の計画は読み手に任せましょう。モデルが計画できる作業のために書かれた経路は、たとえ誤ったステップが含まれていても忠実に辿られます。パッケージング(ブリーフ、ハンドオフ、スキル)は異なりますが、書き方は変わりません。

コア

何を書くか。ラインテスト:「読み手はこれをタスクと訓練から導出できるか?」導出できない事実(調べられない情報、ユーザーの慣習、契約、ハード制約、完了条件)は残します。計画可能な作業のための経路はテストに合格するので削除します。条件のチェックリストは終了状態であり、ステップのチェックリストは経路です。

自己完結型。新しいセッションはプロンプトとディスクだけを読みます。すべてのメッセージは、変更が適用された完全な現在のルールセットを保持します(「以前と同じで、加えてこれらの変更」ではありません)。すべてのドキュメントは、依存する各定常ルールを再述します(「親ドキュメントに従う」ではありません)。

理由は肯定的に述べる。モデルは理由から一般化するため、各ルールには独自の理由を添えます(「段落ごとに1行の連続線、なぜならチャットボックスは改行を意図されたものとして扱うから」)。目標とする振る舞いを述べ、禁止事項は文脈に引きずり込んで利用しやすくするため、ハードなガードレールとしてのみ、肯定的な目標と対にして使用します。プレッシャー言語(MUST、CRITICAL、大文字)は現在のモデルで過剰にトリガーされるため、「Xを使うのは…の場合」と書きましょう。

主要な単語は一箇所に、ノーオペレーションは禁止。モデルがすでに保持している単語(「レシート」「戦場の霧」「タイトループ」)はフレーズより優れ、ユーザー自身の用語はその両方に優ります。各意味は一箇所に存在します。読み手がデフォルトで従う文は、何も言っていないのと同じです。その文を削除しましょう。文中の単語を削るのではありません。

プロンプトの構造

  1. 意図 — より大きな目標、誰のためか、出力が何を可能にするか。モデルはこれを、プロンプトがカバーしない微細な判断に費やします。
  2. 終了状態 — 完了時に何が存在するか、その特性、ユーザーができるようになること。確認可能かつ網羅的であること。「変更されたすべてのファイルが説明されている」は、「変更リストを作成する」では要求されないような詳細な作業を強制します。成果物の形式はここに記述します。それはプロパティであり、手順ではありません。
  3. ハード制約 — 絶対に破れないもの:読み取り専用ソース、予算、用語、来歴。ユーザーが明示した制約をそのまま記述します。自分の経済性のデフォルトは使用しません。
  4. チェックポイント — 規範が依然として属する唯一の場所:人間のために一時停止するタイミング(破壊的または不可逆的なアクション、本当のスコープ変更、人間だけが持つ入力)と、スコープ外のもの。
  5. 自由条項 — 再構成と異議申し立ての許可。曖昧な場合は、定型的な判断を下して前提を明示します。後で問題を防げる可能性がある場合(実質的に異なる作業につながる解釈、取り消しにコストがかかる選択など)は質問します。ユーザーはそのような質問を歓迎します。無人実行では、質問は安全なデフォルトを適用した判断となり、作業は続行されます。
  6. レシート — すべてのブリーフに含めます。完了を報告する前に、各主張をこのセッションの成果物と照合して監査し、検証できなかったものは率直に述べます。これにより、架空のステータス報告はほぼ排除されます。

順序付けられたステップは、順序が重要な場合(移行、安全プロトコル)や、ステップをスキップすると失敗となる場合にのみ使用します。その場合、読み手がコピーしてチェックするチェックリストは散文よりも優れています。

送信前に

番号付きの手順を終了状態の文にできないか? 残っているすべての行は、制約、チェックポイント、検証ルール、または成果物の仕様か? 読み手が、ユーザーが述べていない理由で停止、遅延、またはスコープを削減できる文はないか? 読み手がこの会話に参加していなければ、それに基づいて行動できない文はないか?

関連資料

  • モデル化できる読み手へのワンショットメッセージ(サブエージェントディスパッチ、別セッション用プロンプト、ハンドオフ、外部AIへのメッセージ)→ references/briefs.md
  • 無人実行のためのブリーフ、そのチェックポイントメモと判断、クローズウィンドウ下での順序付け → references/autonomous-runs.md
  • 耐久性のある文書(スキル、CLAUDE.md、リファレンス文書)、およびスキルビルドをAnthropicの skill-creator に委ねるタイミング → references/skills-and-docs.md
  • 読み手のモデルや努力レベルの選択、OpusではなくHaikuやFable向けの作成 → references/models.md

関連スキル