用途：把“我们需要一个候补名单”转化为真实的产品承诺、合适的系统边界和可构建的交付计划。资料强调：兴趣名单、公平服务顺序、流量闸门与预约是不同事物，不应由精美落地页默认决定语义。
适用时机：设计、评审、实现或比较早访问、产品发布需求、稀缺商品、预约、会员、活动、Beta 计划或高流量准入门户时加载。不适用于单独文案、视觉、SEO 或无障碍（应使用前端/内容技能）；通用 API、数据库、邮件、安全或支付实现由对应专业技能负责；实时等候室供应商或队列数据存储需查其官方文档；独立 CRM 迁移或邮件短信活动由对应集成技能负责。本技能提供候补名单专属契约与失败模式，不替代供应商运维手册或法律建议。
主要能力：1）先写承诺：明确加入含义、是否有任何保证、推进事件、联系方式验证要求与授权范围、上线必备条件，并记录假设。2）选择一种主模式：兴趣名单、验证式早访问队列、推荐优先、虚拟等候室、预约补位、分配/抽签/预订、无头嵌入式 API，资料给出各模式系统记录、默认做法与主要陷阱。3）定义状态机与数据契约：如 submitted→verification_pending→active→invited→claimed，等候室用 identified→queued→admitted→consumed；区分邮件与电话通道各自的验证状态。4）构建正常请求路径：页面→服务端端点→校验/规范化→滥用防护→持久化写入→入队通知→通用响应。5）使排名与准入真实：FIFO 原子分配到达键；推荐覆盖需不可猜、可撤销的码，仅计合格下游条目并防自荐。
使用方式与默认栈：新营销候补名单默认用一张静态 HTML 页、Alpine.js（CSP 构建）、Vite 打包、自定义 CSS、Vercel Node.js 运行时上的 TypeScript API 函数、托管 Neon Postgres；Twilio Verify 验证码用于邮件（配合 SendGrid）与可选短信；CRM 通过服务端运行时配置可选。构建或部署前需阅读 references/default-stack.md 等参考文件，用 templates/campaign-brief.md 作为通俗语言入口，不让营销人员选择框架或数据库模式。
限制与注意：本技能可创建部署和发送消息，实施前需确认目标、范围和回滚路径；只读发现可无需确认。不得把模拟表单描述为正在收集真实注册。原子性、幂等键、双重确认、退订与抑制、投递事件处理等需按资料执行；未测量的延迟如“低于200毫秒”不应承诺。资料未提供具体收费、价格与效果数据。