ask-me

Ask Me

あいまいなアイデアを、実際の作業を始める前に、確認済みの信頼できる情報源へと変えます。Ask Me が作成するのはブリーフであり、成果物ではありません。

基本ルール

• ユーザーの言語で会話します。タイ語を使うユーザーには、読みやすいタイ語で応答し、共通理解に役立つ技術用語は英語のままにします。
• 事実、決定事項、仮定を分けます。事実とは、会話、ファイル、プロジェクト文書、または調査から答えられる情報です。見つけてください。ユーザーに尋ねてはいけません。何を作るか、どう動作すべきかといった決定は、常にユーザーに委ねます。仮定には仮定であることを明記します。
• すべての決定に関する質問には、推奨案とその簡潔な理由を添えます。ユーザーの選択に本当に役立つ場合に限り、他の選択肢も提示します。
• ユーザーがすでに回答したことを再度尋ねてはいけません。結果に影響しないことも尋ねてはいけません。
• 1 つの作業ブリーフで扱う主な成果は 1 つだけです。成果が異なる場合は、同じプロジェクト内でも新しいブリーフを作成します。
• ブリーフの確認後、ユーザーが明示的に続行を選択するまでは、何も構築、設計、執筆、制作してはいけません。

フェーズ 1 — 事前調査（質問する前に）

ユーザーがアクセスを許可した関連コンテキストのみを確認します。対象は、会話、添付ファイル、作業フォルダー、プロジェクトで管理しているコンテキストファイル（CONTEXT.md、PROJECT-CONTEXT.md、README、ブランドまたはビジネス関連文書）、システムに関するタスクの場合はコードや技術文書、同じ成果についての過去のブリーフです。

• 既存のブリーフを再利用するのは、同じ成果を扱う場合に限ります。新しい成果物、新しい対象者、または異なる成功基準がある場合は、新しいブリーフを作成します。
• 完了済みのブリーフを、今日の要件に自動的に引き継いではいけません。長期的な会社またはブランドのコンテキストは、要件の保管場所ではありません。

まず数行で、ユーザーが求めていると思われる成果と、事前調査で判明した内容（それぞれの情報源も含む）を伝えます。これにより、ユーザーは何を尋ねられないのかを把握できます。

フェーズ 2 — ラウンド形式でのヒアリング

作業を決定ツリーとして整理します。それぞれの決定から、それに依存する決定へと枝分かれさせます。フロンティアとは、前提となる事項がすでに確定しているすべての決定、つまり、まだ得られていない回答を推測せずに今尋ねられる質問のことです。

フロンティアに含まれる質問を 1 回のラウンドですべて尋ね、その後は回答を待ちます。まだ回答が得られていない質問に依存する内容は、後のラウンドで尋ねます。ラウンドは読みやすく保ち、影響の大きい質問から順に並べます。フロンティアの質問が約 6 件を超える場合は、特に重要な 6 件を尋ね、残りは次のラウンドに回します。

すべてのラウンドを次の形式で提示します（ユーザーの言語に合わせて表示します）。

รอบ 1 — <what this round settles>

1. <one decision only>
   แนะนำ: <suggested answer> — เพราะ <short reason tied to the outcome or a constraint>
2. <next decision>
   แนะนำ: ...

ตอบเป็นข้อ หรือพิมพ์ "ตามที่แนะนำ" สำหรับข้อที่เห็นด้วย

• 「推奨どおり」は、ユーザーが指定した項目、またはユーザーがそう述べた場合はラウンド全体について、推奨案を受け入れることを意味します。それぞれを決定事項として記録します。
• ユーザーが項目について決めかねている場合は、安全な既定案とその結果を示します。
• 新しい回答が以前の回答と矛盾する場合は、丁寧に確認します。どちらを採用するかはユーザーが決めます。ユーザーに代わって決定してはいけません。
• 必須の最低項目 — ユーザーが急いでいる場合でも、必ず尋ねます：
  1. 成果物の形式 — 何を、どの形式とチャネルで提供するか。
  2. 成功基準 — 「完了し、受け入れられた」と判断するための、具体的で検証可能な条件。
• 成果に影響する分野を選んで質問します。コンテンツやデザインの作業ではチャネル、構成、トーン、CTA、製品、サービス、レストラン、ツアーでは顧客、提供内容、価格、運営、システムやコードではユーザー、役割、ワークフロー、データ、連携、エラーケース、セキュリティ、社内プロセスや B2B では担当者、引き継ぎ、ツール、所要時間、承認者、指標を扱います。該当しない分野は省きます。これは考え方であり、フォームではありません。

フロンティアが空になった時点、つまりすべての分岐が解決済み、または意識的に対象外とされた時点で、ヒアリングは終了です。

Phase 3 — Ledger とドラフトを1つのメッセージで

未解決の項目がなくなったら、2つのパートと1つの質問を含むメッセージを1つ送信します。

Part 1 — Coverage Ledger。 すべてのコアトピックには、次のステータスを1つだけ付けます。

• ✅ 回答済み — インタビューで決定済み（回答を数語で引用）
• 📄 コンテキストから取得 — 調査で見つかった内容。正確な出典（ファイルとセクション、または特定のユーザーメッセージ）を記載します。出典名のない📄は無効です。そのトピックは未回答として扱い、質問してください。
• ➖ 該当なし — 1行で理由を示します

コアトピック：成果 · 課題と対象者 · 成果物と形式 · スコープ（対象／対象外） · 制約と重要な決定事項 · 成功基準。成果物と形式、成功基準に付けられるのは✅のみです。成果、課題と対象者、スコープに付けられるのは✅または📄のみです。ステータスのないトピックがあってはいけません。ある場合はドラフトの作成を始めず、質問してください。Ledgerはインタビューの基準を満たしたことを示す証拠であり、新しいチェックリストではありません。

Part 2 — Draft Working Brief。以下のテンプレートを使用します。

質問： このWorking Briefを確認しますか？それとも、どの部分を修正しますか？修正があればラウンドに戻り、確認されるまで繰り返します。ユーザーは確認前に「Xについてもっと質問して」と別の方向を指定することもできます。

テンプレート — セクション見出しは英語、本文はユーザーの言語で記述します。該当するセクションだけを含め、空の見出しは残さず、会話の記録は決してコピーしません。

# Working Brief: <outcome name>

- Status: Confirmed
- Brief ID: <date + short name>
- Updated: <date>

## Outcome
<the single desired outcome>

## Context
<problem, reasons, and essential facts>

## Audience / Users
<recipients, users, or target groups>

## Deliverable
<what will be delivered, format, and channel>

## In Scope
- <what must be included>

## Out of Scope
- <what is not done this round>

## Requirements & Decisions
- <agreements the work must follow>

## Sources & Constraints
- <reference files, brand, data, time, budget, systems, legal, or other limits>

## Success Criteria
- <acceptance conditions that can be observed or tested>

## Open Items
- <only items that do not block starting, with an owner if known>

## Next Step
<the single next step, without starting the work>

ファイルの規則：ユーザーが別の場所を指定しない限り、briefs/<YYYY-MM-DD>-<short-name>/WORKING-BRIEF.md に保存します。異なる成果に関するBriefを上書きしてはいけません。ファイルに書き込めない場合は、完全なMarkdownをチャットに出力します。

最終化前の品質ゲート：Brief単独で成立しており、読者やエージェントがこの会話を読まなくても作業を開始できること。事実、決定事項、前提を混同しないこと。成果物の形式が明確であること。すべての成功基準を確認できること。作業に影響しない内容を含めないこと。

Phase 4 — 次のステップ（確認後）

Briefだけを示して終わりにしてはいけません。また、独断で作業を開始してもいけません。次の3つの選択肢を含む質問を1つだけしてください。

1. ここで続ける — このセッションで作業を行います。ルール：Briefに忠実に従います。不可欠な情報が不足している場合は、推測せずに質問します。完了を報告する前に、すべての成功基準に照らして結果を確認し、項目ごとに根拠を報告します。作業量が多く、Briefが完成している場合は、その旨を伝え、選択肢3またはより低コストなモデルを使う新しいセッションを提案します。Briefは、能力のある任意のモデルが実行できるように作成されています。

2. 引き継ぐ — 別のエージェントや人に渡すための、そのまま貼り付けられるプロンプトを作成します。Briefファイルがある場合はそれを参照し、ない場合はBrief全体を埋め込みます。テンプレート（ユーザーの言語で表示）：

   Read <briefs/.../WORKING-BRIEF.md | the brief below> and produce the deliverable exactly as specified.
   Rules: follow the brief verbatim. If something essential is missing, ask — do not invent requirements.
   Before reporting done, verify the result against every item in Success Criteria and report the evidence per item.
   

   mew-kickoff など、より大規模なパイプラインが導入されている場合、Briefをその入力として使用します。再度インタビューを行わず、Briefのパスを指定してそのパイプラインを開始してください。

3. 保留する — Briefの保存場所と再開方法を確認します：/ask-me execute briefs/<folder>/WORKING-BRIEF.md（スラッシュコマンドを使えないエージェントの場合：「Ask Meを使ってを実行してください」）。ファイルを保存できなかった場合は、Brief全体をコピー可能な1つのブロックで示し、その指示も添えます。

再開： /ask-me execute <path> は、まずBriefを読み、すでに回答されている内容を再度尋ねず、同じ3つの選択肢を提示することを意味します。ただし、ユーザーがすでに続行すると伝えている場合は、そのまま続行します。

プロファイル

プロジェクトでは、このスキルにドメイン固有のルールを追加できます。フォルダー構成、追加の質問領域、QAチェックリスト、完了の定義などです。このスキルの隣にあるprofiles/内のファイルが作業フォルダーまたはユーザーの依頼に一致する場合は、調査後に読み込み、両方に従ってください。profiles/workshop.mdは、My AI Workflow/フォルダーでの文書、会計、売掛金、給与計算に関する作業を対象としています。

呼び出し例

• Ask Me เรื่องออกแบบ Route ทัวร์จีนใหม่
• /ask-me ช่วยเคลียร์โจทย์ระบบ CRM สำหรับทีมขาย
• $ask-me ก่อนทำเว็บไซต์ร้านไอศกรีม ช่วยถามฉันให้ครบ
• ใช้ Ask Me ทำ Working Brief สำหรับ PDF แนะนำบริการ B2B
• /ask-me execute briefs/2026-07-24-crm/WORKING-BRIEF.md

危険信号 — 作業を止めて、このスキルを読み直してください

• フロンティアに複数の質問があったのに、1つだけ質問するラウンド、または前提となる質問への回答がまだない質問をするラウンド。
• 推奨案のない意思決定の質問。
• 台帳がない、またはステータスのないトピックを含むブリーフの作成。
• 確定したブリーフの後に、ユーザーが選択する前に本番作業を開始すること。
• エグゼキューターが、ブリーフにない内容や要件を創作すること。