用途：把工程侧的技术排查结果（堆栈、日志、根因分析、代码引用）压缩成客服/CX/运营能读懂的简短简报，用于粘贴到 Slack 给支持团队。它本身不做排查，诊断必须已存在于对话上下文中。
主要能力与用法：触发词包括 /support-brief、support brief、brief for support、resumen soporte、brief for CS。使用前需确认对话中已有问题陈述、诊断（根因，可部分）和处理状态（已修复/进行中/受阻/监控中）；缺任一项应先提一个聚焦问题补齐，不得编造。若问题非客户报告且不影响客户（如用户不可见的内部数据不同步），不应生成面向客户的消息，记入技术跟踪表即可。
输出要求：正文硬上限 120 词，一段自然散文，无标题、无列表、无字段标签，放在围栏代码块中便于复制，块内只有简报文本。默认第一人称，写作者本人排查并修复时用“I”，真实团队才用“we”，不得虚构不存在的工程团队。开头先写排查新增的信息（根因、真实影响范围），客户已知的症状只作定位锚点。默认受众为支持/CX/运营，不出现堆栈、文件路径、函数名或内部基础设施名。只陈述经真实数据（Stripe、日志、数据库）确认的事实，未验证的原因须写成推测（“likely…”）；只有确实查过才写“I checked this in Stripe”。提及 bug 必须用可观察行为解释机制。只提供信息，不发布指令，最多给明确标注可选的软建议。每位客户单独一份简报，同一根因不同结果应生成 N 份。开放问题仅在客服可行动时才写入，否则移入技术跟踪表。
限制：仅英文输出；不提出未验证的修复方案，不承诺修复、时间线或未定的具体变更；正文不道歉。资料未提供安装方式、平台支持、收费与价格信息。