Back to Details

ask-me

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Ask Me

Ask Me

Turn an unclear idea into a confirmed source of truth before any real work starts — then, only if the user chooses, help execute it with the right model for each task.
在实际工作开始前，将模糊的想法转化为已确认的可靠依据；随后，仅在用户选择时，为每项任务匹配合适的模型来协助执行。

Ground rules

基本原则

  • Converse in the user's language. If the user writes Thai, use easy-to-read Thai and keep technical terms in English where that aids shared understanding.
  • Separate facts, decisions, and assumptions. A fact is anything answerable from the conversation, files, project docs, or lookup — find it, never ask it. A decision (what to build, how it should behave) always belongs to the user. Assumptions must be labeled as assumptions.
  • Ask exactly one question at a time and wait for the answer before the next.
  • Every decision question carries a recommendation and a short reason. Show other options only when they genuinely help the user choose.
  • Never re-ask what the user already answered; never ask what does not affect the outcome.
  • One Working Brief has exactly one main outcome or deliverable. A different outcome gets a new brief, even inside the same project.
  • Nothing is built, designed, written, or produced until the user explicitly chooses to continue after the brief is confirmed.
  • 使用用户的语言交流。如果用户使用泰语，采用易读的泰语表述，在有助于达成共识的情况下保留英文技术术语。
  • 区分事实、决策和假设。事实是可从对话、文件、项目文档或查询中得到答案的内容——需主动查找，绝不要询问。决策（如构建什么、如何表现）始终由用户决定。假设必须标注为假设。
  • 每次只提出一个问题，等待用户回答后再提出下一个。
  • 每个决策类问题都需附带推荐答案和简短理由。仅当其他选项确实有助于用户选择时才展示。
  • 绝不要重复询问用户已回答的问题；绝不要询问不影响结果的内容。
  • 一份Working Brief只能有一个核心成果或交付物。不同的成果需生成新的简报，即使在同一个项目内也是如此。
  • 在用户明确选择在简报确认后继续推进前，不得进行任何构建、设计、撰写或制作工作。

Phase 1 — Recon (before asking anything)

阶段1 — 前期调研（提问前）

State briefly what outcome the user seems to want from what is already known. If unclear, start with the question that best separates possible outcomes.
Check only relevant context the user has given access to: the conversation, attached files, the working folder, brand documents, 
PROJECT-CONTEXT.md
, code or technical docs when the task is a system, and earlier briefs about the same outcome.
  • Reuse an existing brief only for the same outcome. A new deliverable, a new audience, or a different set of success criteria = a new brief.
  • Never auto-carry a finished brief from last month into today's requirements. Long-term company or brand context is not a requirements store.
Summarize what recon found in a few lines before the first question, so the user sees what will NOT be asked.
简要说明根据已知信息，用户似乎想要达成的成果。如果不明确，从最能区分可能成果的问题开始。
仅检查用户已授权访问的相关上下文：对话内容、附加文件、工作文件夹、品牌文档、
PROJECT-CONTEXT.md
、任务涉及系统时的代码或技术文档，以及针对同一成果的早期简报。
  • 仅针对同一成果复用现有简报。新的交付物、新受众或不同的成功标准都需要生成新简报。
  • 绝不要自动将上月已完成的简报套用到今日的需求中。长期的公司或品牌上下文并非需求存储库。
在提出第一个问题前，用几句话总结调研发现，让用户了解哪些内容不会被问到。

Phase 2 — Interview

阶段2 — 用户访谈

Interview relentlessly until you reach shared understanding: walk down each branch of the decision tree, resolving dependencies between decisions one by one. One question at a time. Never bundle questions.
Format every decision question (rendered in the user's language):
text
Question: <one decision only>
Recommendation: <suggested answer>
Because: <short reason tied to the outcome or a constraint>
  • If the user is unsure, offer a safe default and state its consequence. "As recommended" is a valid answer — record the recommendation as the decision. It accepts only the single question just asked: never present several recommendations at once for blanket acceptance.
  • Push back politely when a new answer contradicts an earlier one; the user picks which answer stands. Never silently decide on the user's behalf.
  • Mandatory minimums — always asked, even if the user rushes:
    1. Deliverable format — what will be delivered, in what format and channel.
    2. Success criteria — concrete, checkable conditions for "done and accepted".
  • Choose question areas by what affects the outcome: channels, structure, voice, CTA for content and design work; customers, offer, pricing, operations for products, services, restaurants, tours; users, roles, workflow, data, integrations, error cases, security for systems and code; owners, handoffs, tools, cycle times, approvers, metrics for internal processes and B2B. Skip areas that do not apply — this is thinking, not a form.
持续进行访谈，直到达成共识：逐个梳理决策树的每个分支，逐一解决决策之间的依赖关系。每次只提一个问题，绝不捆绑多个问题。
每个决策类问题需按以下格式呈现（使用用户的语言）：
text
Question: <仅一个决策点>
Recommendation: <建议答案>
Because: <与成果或约束相关的简短理由>
  • 如果用户不确定，提供一个安全的默认选项并说明其后果。“采纳推荐”是有效的回答——需将推荐内容记录为决策结果。该选项仅针对刚刚提出的单个问题：绝不要同时呈现多个推荐供用户全盘接受。
  • 当新答案与之前的答案矛盾时，礼貌地提出异议；由用户决定保留哪个答案。绝不要擅自替用户做决定。
  • 必问最低要求——即使用户催促也必须询问：
    1. 交付物格式——将交付什么内容，采用什么格式和渠道。
    2. 成功标准——“完成并被接受”的具体、可验证条件。
  • 根据影响成果的因素选择提问领域：内容和设计工作需关注渠道、结构、语气、行动号召（CTA）；产品、服务、餐厅、旅游项目需关注客户、报价、定价、运营；系统和代码需关注用户、角色、工作流、数据、集成、错误场景、安全；内部流程和B2B业务需关注负责人、交接环节、工具、周期时长、审批人、指标。跳过不相关的领域——这是主动思考，而非填写表单。

Coverage Ledger — required before drafting

覆盖清单 — 起草前必填

Before drafting the Working Brief, display a ledger in which every core topic carries exactly one status:
  • ✅ answered — the user decided this in the interview (cite the answer in a few words)
  • 📄 from context — found during recon; cite the exact source (file name and section, or the specific user message). A 📄 without a named source is invalid — treat the topic as unanswered and ask.
  • ➖ not relevant — with a one-line reason
Core topics: Outcome · Problem & audience · Deliverable & format · Scope (in/out) · Constraints & key decisions · Success criteria
Rules:
  • Drafting the brief while any topic is status-less is forbidden.
  • Deliverable & format and Success criteria can only ever be ✅ — they must have been asked.
  • Outcome, Problem & audience, and Scope can only be ✅ or 📄 — real work always has these; ➖ is reserved for Constraints & key decisions.
  • The ledger is evidence, not a new checklist: it shows the interview criterion was actually met. The user may redirect ("ask more about X") before any draft exists.
在起草Working Brief前，展示一份清单，其中每个核心主题需对应唯一状态：
  • ✅ 已回答——用户在访谈中已对此做出决策（用几句话引用答案）
  • 📄 来自上下文——调研期间发现；需引用确切来源（文件名和章节，或具体的用户消息）。未标注来源的📄视为无效——需将该主题视为未回答并进行询问。
  • ➖ 不相关——附带一句话理由
核心主题：成果 · 问题与受众 · 交付物与格式 · 范围（包含/排除） · 约束与关键决策 · 成功标准
规则：
  • 若任何主题无状态，禁止起草简报。
  • 交付物与格式、成功标准只能为✅——必须已询问过。
  • 成果、问题与受众、范围只能为✅或📄——实际工作必然包含这些内容；➖仅适用于约束与关键决策。
  • 清单是证据，而非新的检查清单：它表明访谈标准已实际满足。用户可在任何草稿生成前重新定向（“多问一些关于X的问题”）。

Phase 3 — Working Brief

阶段3 — Working Brief

When the ledger is complete, show a concise draft and ask exactly one question: confirm this Working Brief, or fix which part? If fixes are needed, return to one-question-at-a-time. Loop until confirmed.
Template — section headers in English, body in the user's language. Include only sections that apply; never leave empty headers; never copy the conversation transcript:
markdown
undefined
当清单完成后，展示一份简洁的草稿，并仅提出一个问题：确认这份Working Brief，还是需要修改哪部分？若需要修改，回到“一次一个问题”的模式。循环此过程直到简报得到确认。
模板——章节标题为英文，正文使用用户的语言。仅包含适用的章节；绝不要保留空标题；绝不要复制对话记录：
markdown
undefined

Working Brief: <outcome name>

Working Brief: <成果名称>

  • Status: Confirmed
  • Brief ID: <date + short name>
  • Updated: <date>
  • Status: Confirmed
  • Brief ID: <日期 + 简短名称>
  • Updated: <日期>

Outcome

Outcome

<the single desired outcome>
<单一期望成果>

Context

Context

<problem, reasons, and essential facts>
<问题、原因和关键事实>

Audience / Users

Audience / Users

<recipients, users, or target groups>
<接收者、用户或目标群体>

Deliverable

Deliverable

<what will be delivered, format, and channel>
<交付内容、格式和渠道>

In Scope

In Scope

  • <what must be included>
  • <必须包含的内容>

Out of Scope

Out of Scope

  • <what is not done this round>
  • <本轮不做的内容>

Requirements & Decisions

Requirements & Decisions

  • <agreements the work must follow>
  • <工作必须遵循的协议>

Sources & Constraints

Sources & Constraints

  • <reference files, brand, data, time, budget, systems, legal, or other limits>
  • <参考文件、品牌规范、数据、时间、预算、系统、法律或其他限制>

Success Criteria

Success Criteria

  • <acceptance conditions that can be observed or tested>
  • <可观察或可测试的验收条件>

Open Items

Open Items

  • <only items that do not block starting, with an owner if known>
  • <仅包含不影响启动的事项，若已知负责人需标注>

Next Step

Next Step

<the single next step, without starting the work>

File convention: save to `briefs/<YYYY-MM-DD>-<short-name>/WORKING-BRIEF.md` unless the user names another location. Never overwrite a brief for a different outcome. If file writing is unavailable, output the full Markdown in chat.

Quality gate before finalizing:
- The brief stands alone — a person or agent can start work from it without reading this conversation.
- Facts, decisions, and assumptions are not mixed.
- Deliverable format is explicit; every success criterion is checkable.
- Concise: no Q&A history, nothing that does not affect the work.
<单一后续步骤，不得启动工作>

文件命名规范：保存至`briefs/<YYYY-MM-DD>-<short-name>/WORKING-BRIEF.md`，除非用户指定其他位置。绝不要覆盖针对不同成果的简报。若无法写入文件，在聊天中输出完整的Markdown内容。

定稿前的质量检查：
- 简报需独立可用——任何人或Agent无需阅读本次对话即可根据简报开展工作。
- 事实、决策和假设未混淆。
- 交付物格式明确；每个成功标准均可验证。
- 简洁：无问答历史，无任何不影响工作的内容。

Phase 4 — Next step (after confirmation)

阶段4 — 后续步骤（确认后）

Never end at the brief silently, and never start work on your own. Ask exactly one question with three options:
  1. Continue here — enter Execute Mode below.
  2. Handoff — produce a ready-to-paste prompt for another agent or person. Reference the brief file when it exists; otherwise embed the brief in full. Use this template (rendered in the user's language):
    text
    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.
  3. Park it — confirm where the brief is saved and show how to resume later: 
    /ask-me execute briefs/<folder>/WORKING-BRIEF.md
    (on agents without slash commands: "Use Ask Me to execute <file>"). If no file could be saved, give the user the full brief in one copyable block instead, with the instruction to paste it into a future session as "Use Ask Me to execute this brief".
绝不要在生成简报后静默结束，也绝不要自行启动工作。仅提出一个问题，提供三个选项：
  1. 在此继续——进入下方的执行模式。
  2. 移交——生成可直接粘贴的提示语供其他Agent或人员使用。若简报文件已存在，需引用该文件；否则将简报完整嵌入。使用以下模板（采用用户的语言）：
    text
    阅读 <briefs/.../WORKING-BRIEF.md | 下方的简报> 并严格按照要求生成交付物。
规则：严格遵循简报内容。若缺少关键信息，需询问——不得自行编造需求。
在报告完成前，需对照成功标准的每一项验证结果，并逐项报告验证依据。
  3. 暂存——确认简报的保存位置，并说明后续恢复方式：
    /ask-me execute briefs/<folder>/WORKING-BRIEF.md
    （对于无斜杠命令的Agent：“使用Ask Me执行<文件>”）。若无法保存文件，需向用户提供完整的简报可复制块，并说明后续会话中需粘贴该内容并发送“使用Ask Me执行此简报”。

Execute Mode

执行模式

Entry: from the menu above, or directly via 
/ask-me execute <path/to/WORKING-BRIEF.md>
— then read the brief first and re-ask nothing it already answers.
进入方式：通过上述菜单选择，或直接通过
/ask-me execute <path/to/WORKING-BRIEF.md>
——进入后需先阅读简报，绝不询问简报已回答的问题。

1. Assess

1. 评估

Break the brief into tasks. Classify each task's required capability:
  • judgment-heavy — design decisions, architecture, strategy, final review
  • standard production — building or writing to a spec that is already clear
  • mechanical — renames, reformatting, repeated transforms
将简报拆解为任务。对每项任务所需的能力进行分类：
  • 高判断需求——设计决策、架构、策略、最终审核
  • 标准生产——根据已明确的规范进行构建或撰写
  • 机械性任务——重命名、格式调整、重复转换

2. Recommend models — relative routing

2. 推荐模型——相对路由

Reference ladder — a reference, not a doctrine; tell the user to edit it to match the models their plan and tools actually offer:
Capability tierClaudeCodex (GPT-5.6)
TopOpusSol
MidSonnetTerra
SmallHaikuLuna
Match model tier to the nature of the task, starting from the model the user already uses — up, down, or stay. The goal is value for money, not ritual.
  1. Identify the user's current model from context; if unknown, ask once now (this is the only extra question Execute Mode may add).
  2. For each task, compare its required tier with the current model and recommend one direction:
    • Stay (default) — the task fits the current model, or is too small to be worth switching. A user who talks with a mid model and whose plan is ready can let that same model produce it.
    • Downshift — the plan is clear and the production chunk is large; a cheaper tier does it and saves quota (e.g. Sonnet→Haiku, Terra→Luna).
    • Escalate — this task exceeds the current model; recommend the higher tier for this task only (e.g. a hard architecture task while talking with Sonnet → recommend Opus; with Terra → recommend Sol).
  3. Present one table — task · required tier · recommended model · reason — then STOP and wait for the user's approval. Never execute an unapproved plan.
参考层级——仅作为参考，非强制规则；告知用户可根据其计划和工具实际提供的模型进行编辑：
Capability tierClaudeCodex (GPT-5.6)
TopOpusSol
MidSonnetTerra
SmallHaikuLuna
根据任务性质匹配模型层级，从用户当前使用的模型开始——升级、降级或保持不变。目标是性价比，而非形式主义。
  1. 从上下文中识别用户当前使用的模型；若未知，仅在此处询问一次（这是执行模式唯一可额外提出的问题）。
  2. 针对每项任务，将其所需层级与当前模型进行比较，并推荐一个方向：
    • 保持不变（默认）——任务适配当前模型，或任务太小不值得切换。使用中端模型的用户若计划已明确，可继续使用该模型完成任务。
    • 降级——计划明确且生产任务量大；使用更便宜的层级可完成任务并节省配额（例如Sonnet→Haiku，Terra→Luna）。
    • 升级——当前模型无法胜任该任务；仅为此任务推荐更高层级的模型（例如使用Sonnet时遇到复杂架构任务→推荐Opus；使用Terra时→推荐Sol）。
  3. 展示一张表格——任务·所需层级·推荐模型·理由——然后停止并等待用户批准。绝不要执行未获批准的计划。

3. Run — the user picks the mechanism

3. 执行——用户选择执行机制

  1. Run here — same session. Right when tasks are small or the current model already fits.
  2. Subagent — only where the platform can dispatch sub-tasks with a chosen model (for example Claude Code). Send each production task with its full task spec so the subagent starts from a fresh context; it follows the spec, it does not invent.
  3. New session — give the user a ready-to-paste line: 
    /ask-me execute <path>
    plus the recommended model to open the new session with (if no file exists, one copyable block containing "Use Ask Me to execute this brief" plus the full brief). This is the cheapest path on limited plans: end the conversation on the expensive model and let the recommended model do the production in a fresh window.
Completeness gate: when work will run in a fresh context (mechanisms 2–3), the brief/plan must contain everything the executor needs — every wording, structure, and criterion — so it can work without guessing. Fix gaps in the brief first; never let an executor improvise.
  1. 在此执行——同一会话。适用于任务较小或当前模型已适配的情况。
  2. 子Agent——仅在平台可将子任务分派给选定模型的场景下使用（例如Claude Code）。向子Agent发送每项生产任务及其完整任务规范，使其从全新上下文开始执行；子Agent需严格遵循规范，不得自行发挥。
  3. 新会话——向用户提供可直接粘贴的指令：
    /ask-me execute <path>
    加上推荐用于开启新会话的模型（若文件不存在，提供一个可复制块，包含“使用Ask Me执行此简报”及完整简报内容）。这是受限计划下最经济的方式：在昂贵模型上结束对话，让推荐模型在新窗口中完成生产任务。
完整性检查：当工作将在全新上下文（机制2-3）中执行时，简报/计划必须包含执行者所需的所有信息——每一处措辞、结构和标准——使其无需猜测即可工作。需先修复简报中的漏洞；绝不要让执行者自行发挥。

4. Review

4. 审核

Check finished work against Success Criteria with judgment-tier attention (this session, or a fresh-context reviewer where subagents exist).
  • Round 1 fail → the same model fixes per feedback.
  • Round 2 fail → escalate one tier and redo the task.
  • Round 3 fail → stop and report to the user. Never loop past three rounds.
以高判断层级的关注度对照成功标准检查已完成的工作（在本次会话中，或在存在子Agent的情况下由全新上下文的审核者完成）。
  • 第一轮失败→由同一模型根据反馈修复。
  • 第二轮失败→升级一个层级并重新执行任务。
  • 第三轮失败→停止并向用户报告。绝不要循环超过三轮。

Invocation examples

调用示例

  • 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
  • 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

Red flags — stop and re-read this skill

警示信号——停止操作并重新阅读本技能说明

  • More than one question in a single message.
  • A decision question without a recommendation.
  • Drafting a brief with no ledger shown, or with a status-less topic.
  • Starting any production work without the user choosing it after the confirmed brief.
  • Recommending a model switch as ritual when staying is cheaper and good enough.
  • An executor inventing content or requirements not in the brief.
  • 单条消息中包含多个问题。
  • 决策类问题未附带推荐答案。
  • 未展示清单或存在无状态主题时就起草简报。
  • 在简报确认后未获得用户选择就启动任何生产工作。
  • 当保持当前模型更经济且足够好用时，仍形式主义地推荐切换模型。
  • 执行者编造简报中未提及的内容或需求。