task-brief

タスク概要

依頼が簡潔すぎることは、エージェントの出力が平凡になる最大の原因です。エージェントは成果物、対象読者、制約を推測するため、ユーザーがその読み違いに気づくのは作業が終わってからです。このスキルでは、エージェントに短いタスク概要を作成して提示させてから実行することで、その気づきを可能な限り早い段階、つまり作業開始前に移します。ユーザーがよりよいプロンプトを書く必要はありません。構成を整えるのはエージェントです。

実行する場合 — しない場合

実行する場合：

• ユーザーが明示的に依頼した場合（「まず概要をまとめて」「始める前に理解したか確認して」など）、または
• タスクが相応の規模で、複数の手順や複数の文書を伴う場合、あるいは他の人が読む成果物（メモ、レポート、ダッシュボード、複数文書の一括作成など）を作る場合で、依頼が簡潔または曖昧なため、妥当な解釈が二通りあれば成果物が異なるとき。

省略する場合（そのままタスクを実行）：簡単な事実確認、単一手順の編集、すぐに着手できるほど明確な依頼。些細な依頼に概要を作るのは品質向上ではなく手間です。相応の対応をすることも、このスキルの一部です。迷ったときは、概要全体を作るより、「これは X と解釈して進めます。違っていればお知らせください」と一行で言い直すほうが適切です。

概要

次の形式で、簡潔に、平易なビジネス文書の言葉でまとめて提示します。

**Task brief — [short task name]**
- **Goal** — what "done" looks like: the deliverable, its format, its audience,
  and the test it must pass.
- **Context** — everything known that bears on the task: the inputs/files
  provided, relevant background from the conversation or memory, the entities /
  period / parties involved, what already exists.
- **Constraints** — what to avoid and the guardrails: task-specific limits
  (scope, exclusions, deadline, tone) plus whichever standing rules materially
  bite this task (see below).
- **Assumptions** — anything filled in without asking, flagged so the user can
  correct it with one word.
- **Tooling** — the installed skill(s) or tool(s) that will do the work.

まとめ方

1. 質問する前に情報を抽出します。 依頼内容、これまでの会話、提供されたファイル、メモリをまず確認します。すでに確認できる情報をユーザーに尋ねてはいけません。
2. 出力を左右することだけを尋ねます。 不明点ごとに、答えが異なれば成果物も変わるかを確認します。変わるなら質問します。質問は最大2～3問とし、利用できる場合は構造化された質問ツールを使い、なければチャットで短い番号付きリストにします。変わらない場合は、妥当な既定値を補い、前提に記載します。タスクの前に質問攻めにしてはいけません。
3. 常設の制約を反映します。確認は求めません。 どの組織にも、すべての業務に適用されるルールがあります。該当するものだけを制約に自動で記載します。まずホスト環境を確認し、システムプロンプト、組織の指示、CLAUDE.md / エージェントファイル、原則やスタイルに関する文書を参照します。何も定められていない場合は、次の既定値を適用します。出力は助言ではなく、人が確認するための草案とします。事実を決して捏造せず、質問するか、未記入箇所であることを明確に示します。綴り、日付、通貨の表記は組織のスタイルに統一します。機密データはローカルに留めます。外部ツールに渡す前に個人や組織が特定されないようにします。実行の境界を守り、明示的な許可がない限り、準備までに留めて、送信・投稿・支払い・提出・署名はしません。
4. 使用するツールを選定します。 実際にインストールされているもの（スキル、コネクター、スクリプト）を調べ、タスクを実行できる最も具体的なものを明記します。より適した機能があってもインストールされていない場合は、参考情報として伝えます。ユーザーが利用できないものを概要の前提にしてはいけません。適したものが何もなければ、その旨を伝え、汎用機能で進めます。
5. 動作モードとの互換性を事前確認します。****ツールの項目をまとめる際に、選定したスキルが現在の環境で実際に利用できるかを確認します。Python ヘルパー、認証情報、ネットワークアクセス、プラットフォームの制限などを確認します。スキルに環境で利用できないものが必要な場合は、「この方法には X が必要ですが、ここでは利用できません。代替手段は Y です」のように概要で明示します。モード上の問題が作業の途中ではなく、開始前に分かるようにします。
6. 確認を得てから実行します。 概要を提示し、実行の承認または修正を待ちます。「進めて」の一言で十分です。確認はざっと目を通すだけで、書式を埋める作業ではありません。その後、概要に沿って作業します。
7. 最後に成果を照合します。 成果物を渡す際に、出力を目標の項目と照らし合わせ、「完了」のどの部分が満たされ、どの部分が未完了かを明確に伝えます。実行していない確認を実施したと主張してはいけません。

作業例（架空）

ユーザー：「木曜日の電話会議に向けて、Northwind のアカウント番号に関する資料をまとめて」

エージェントはフォルダーを確認し（northwind-q2-summary.xlsx を見つけます）、次に2つの質問をします。対象者（社内チームかクライアントか）と形式（1ページのダッシュボードか要点メモか）です。そして、次の資料を作成します。

**Task brief — Northwind Q2 numbers for Thursday's call**
- **Goal** — a one-page dashboard (PDF via browser print) of the Northwind
  account's Q2 numbers, for the internal team call on Thu 12 Mar; done = the
  reader sees revenue vs budget, pipeline and overdue items at a glance.
- **Context** — source: northwind-q2-summary.xlsx (this folder); Q1 comparison
  available in the same file; internal audience per your answer.
- **Constraints** — internal draft, not for client distribution; figures traced
  to the source file, none invented; consistent currency and date formats.
- **Assumptions** — "numbers" = the account KPIs, not the contract terms (say
  if you want those in).
- **Tooling** — the installed dashboard/visualisation skill; spreadsheet read
  via the local data engine.

ユーザーが「進めて。契約更新も追加して」と返信します。修正は1つで、作業の後ではなく、始める前に把握できました。

原則

• 助言ではなく下書き — ブリーフと、それを枠組みとして作成する成果物は、人が確認するための下書きであり、専門的な助言ではありません。
• 決して捏造しない — ユーザーが補足しない情報の不足は、もっともらしい推測で埋めず、注意事項として明記するか、空欄のまま見えるようにします。
• 相応の負担にする — ブリーフにかかる負担は、それによって防げる誤解より小さくなければなりません。些細な依頼では省略します。
• 誠実さと適切な調整 — Goal の行を基準に最後まで確認し、達成したことと未完了のことを明確に報告します。
• 確認の機会にこそ価値がある — 作業開始前に誤解を修正すれば、ほとんど負担はありません。同じ修正でも、成果物の提出後ではタスク全体にかかるコストが発生します。

データの取り扱い

ブリーフには、クライアント、取引相手、または個人に関する背景情報が引用されることがよくあります。ブリーフはチャットとローカルの作業フォルダー内だけに置きます。外部ツールやサードパーティ製ツールにブリーフを送信してはいけません。タスクの手順で外部サービスにデータを送る必要がある場合は、まず機密データの識別情報を削除し、データの外部送信についてユーザーに確認してください。このスキル自体は、ネットワーク、スクリプト、認証情報を必要としません。

注意点

1. 質問疲れ — 最初に2～3個を超える質問をすると、ユーザーは回答をやめてしまいます。残りは注意事項として明記してください。
2. 読み取れることを質問する — すでにフォルダーや会話にある情報について質問すると、ブリーフ全体への信頼が損なわれます。
3. 一般的な制約での水増し — 毎回のブリーフに恒常的なルールをすべて列挙すると、重要なルールが埋もれてしまいます。このタスクに影響するルールだけを含めてください。
4. 最後の確認を省略する — Goal の行が「完了」の基準です。それに照らして確認せずに成果物を提出すると、ブリーフが無駄になります。
5. ツールへの依存 — ユーザーが持っていないツールを計画に含めてはいけません。インストールされていない機能は、参考情報として扱ってください。

フィードバックの記録

このスキルに修正や改善の提案がありますか？構造化したメモにまとめてください。スキル名、実施したこと、期待した結果と実際の結果、重大度、提案を記載し、プレーンテキストファイルに保存して、ユーザーに渡して整理してもらいます。手動で行い、保存先は固定しません。依頼があれば、対応範囲内で修正します。これにより、改善に関する情報がチャット内で消えてしまわず、継続してスキルの作成者に届きます。

検証チェックリスト

• 重要なタスクであることを確認した（または明示的な呼び出しがあった）。些細な依頼ではない。
• 質問する前に、依頼、会話、ファイル、メモリーを確認した。
• 質問は最大2～3個で、どれも出力を変える内容だった。
• 恒常的なルールは、質問するのではなく、ホスト環境または既定値から取り込んだ。
• 割り当てられたスキルを、環境がサポートしているか事前に確認した。
• 作業を始める前にブリーフを提示し、ユーザーの確認を得た。
• 出力を Goal の行に照らして確認し、達成したことと未完了のことを報告した。

要件

• なし — 推論のみで動作するスキルです。Python、ネットワーク、認証情報は不要です。このファイルを読み取れるエージェント環境であれば実行できます。