brief
特性：$ARGUMENTS
首先进行基础信息收集（静默执行）
- 阅读此仓库的 CLAUDE.md 和该项目的记忆条目。浏览该功能所涉及的路由、配置和邮件模板。规格文档应引用真实的文件路径和现有字段。
- 仅当某个决定会改变范围时，才进行询问。使用 AskUserQuestion 一次只问一个问题，并提供推荐选项，最多不超过 3 个问题。其余内容均作为待定问题中的假设列出。
范围制定规则
- MVP 是指在现有字段和组件基础上构建的常规最小化产品。“像任何电商一样”意味着标准流程，而非平台。
- 绝不添加未要求的功能、设置、管理页面或分析功能。将它们列在非目标中。
- 合作伙伴或 API 功能：“API key”通常指环境中的租户 ID，而非开发者门户。
- 尊重 CLAUDE.md/记忆文件中的项目约束（例如“不允许更改 schema”）。标记任何可能违反约束的内容。
模板
# <特性>: brief
**问题：** 一两句话，描述用户的痛点，而非解决方案。
**目标用户：** 谁，以及如果已知的话有多少人（引用数据来源或查询条件）。
**MVP：** 3–6 个要点，每个都可交付且可观察。
**非目标：** 当前明确不做的事情。
**验收标准**
1. Given <状态>, When <操作>, Then <可观察结果>.
2. ……（每个标准都可通过 flow-check、smoke 测试或单元测试进行验证）
**影响范围：** 路由 · 表/字段（优先使用现有字段） · 邮件 · 环境变量/密钥 · 第三方
**风险：** 资金、法律/GDPR、投递能力、SEO（noindex/canonical）、国际化
**待定问题：** 编号列出的问题；每个问题附带我的默认答案（如果未被回答）
输出
- 默认在聊天中输出。仅在用户要求时写入
docs/briefs/<slug>.md。 - 一句开场白（“简要内容如下：N 个验收标准，M 个待定问题”），然后是简要内容。之后不附加任何内容。
退出标准
- 每条验收标准都是可观察的，并且对应一项检查（flow-check 步骤、smoke 测试期望或测试用例）。
- MVP 中不包含未被要求或非严格必需的内容。
- 每条待定问题都有默认答案，以便无需等待即可开始构建。