用途
该技能面向需要把自有域名指向 Convex 应用的场景，帮助用户在自己的域名注册商处完成从 DNS 配置到域名绑定、再到认证来源重绑的完整流程。
主要能力
- 识别目标：确定是 *.convex.app 静态托管的已发布站点主机，还是部署的 HTTP actions URL。
- 自动创建 DNS 记录：检测用户所用服务商是否存在已认证的 DNS CLI，并提议自动创建记录。支持的方式包括：
- Cloudflare → flarectl dns create（注意 wrangler 本身不管理 DNS 记录），或通过其 token 环境使用 CF API
- Route53 → aws route53 change-resource-record-sets
- Google Cloud DNS → gcloud dns record-sets create
- DigitalOcean → doctl compute domain records create
- Vercel DNS → vercel dns add
- 先以只读方式检查认证状态（flarectl user info / aws sts get-caller-identity / doctl account get），展示确切的命令并在获得确认后再执行。
- 手动指引：若无已认证 CLI 或用户拒绝，则明确告知用户应在其注册商处创建哪些记录，包括 CNAME（或顶级域的 A/ALIAS）以及 TXT 验证记录，并给出具体的 host/value 字符串而非占位符。
- 绑定域名：在 Convex 仪表盘或 CLI 中将域名绑定为自定义域名并等待验证；提示 DNS 传播可能需要数分钟到数小时。可用 dig +short 验证记录是否生效。
- 认证来源重绑：若应用使用认证（passkey/OAuth），将认证来源（SITE_URL / RP_ID / ORIGIN 环境变量）重绑到新域名，并重新部署/发布。
- 最终验证：确认域名通过 HTTPS 提供应用，包括已配置的 apex → www 跳转。
使用方式
技能以工作流形式引导用户逐步操作：先识别目标，再检测并（在用户同意后）执行 DNS 记录创建命令，或给出具体的手动记录值；随后绑定自定义域名、用 dig 验证、按需重绑认证来源并重新发布，最后验证 HTTPS 访问与跳转。
适用场景
- 已有域名并希望指向 Convex 应用（静态托管或部署的 HTTP actions）。
- 使用 Cloudflare、Route53、Google Cloud DNS、DigitalOcean 或 Vercel DNS 等支持 CLI 的服务商。
- 应用启用了认证（passkey/OAuth），需要在换域名后重绑认证来源。
限制与规则
- 绝不询问或处理注册商凭据。允许使用用户机器上已认证的 CLI，凭据保留在工具内；不得为此安装 CLI 或运行其登录/认证流程，不得回显 token。
- 对线上域名的 DNS 变更对用户可见：需展示确切命令并在执行前确认，执行后用 dig 验证。
- 必须始终包含 TXT 验证记录，而不仅是 CNAME。
- 重绑域名会改变认证来源，之后必须重新发布，否则会导致登录失败。
- 资料未提供定价、收费或价格信息。