用途：审计 JavaScript/TypeScript Web 应用（尤其 Next.js）的滥用与限流面，问清楚必要的策略问题，再把批准的策略写成根目录 RATE_LIMITS.md 契约并实施。
流程分两步。第一步审计：先读仓库说明（如 AGENTS.md、CLAUDE.md）与已有的 RATE_LIMITS.md；按状态路由——无 spec 则开始审计，needs-spec-review 只展示草案，approved 仅当当前提示明确说明是“全新实施 agent”时才实施，needs-implementation-review 展示验证证据后停止，complete 视为审计或修订请求。审计需阅读 references/detection-playbook.md，检查请求与触发工作的面、认证、外部服务、高成本操作、持久化、部署运行时和现有 limiter，列出候选限流点（保护什么、谁能触发、成本/滥用方式、现有身份与后端、置信度与待决问题）并排序；不得仅因路由公开就建议限流。面试人类时一次一问，用产品语言提问，给出基于仓库证据的推荐默认值及一句理由，只问会实质影响保护、体验、运营风险或验证的问题，不替人类选算法或供应商。随后读 references/spec-template.md，创建或更新唯一的根级 RATE_LIMITS.md，为每个 limiter 设稳定 ID，明确身份、算法、额度与突发、豁免、后端、故障行为、被拦响应与恢复、可观测性与验证，并设 status: needs-spec-review；此时不得改动应用代码、依赖、schema、凭据与部署配置。只有人类明确批准整份当前契约、且 Open questions 为空，才能改为 approved 并记录版本、批准人与时间。
第二步实施：读 references/provider-routing.md，选一个与现有技术栈匹配的主执行后端或平台控制，改动依赖/schema/平台配置前核实官方文档。必须交给全新子 agent，提示中明确其为已批准契约的实施者，携带 RATE_LIMITS.md、仓库说明和代码库；主机无法创建子 agent 时，停止并请人类另开新会话，不得退回规划上下文实施。实施前需确认 approved、approved_revision 匹配、批准元数据齐全、评审记录覆盖该版本且无待决问题，否则回到第一步。创建账号、数据库、凭据、OAuth 授权或部署密钥仍需行动时人工确认。若仓库现实使已批准决策不安全或不可行，回退为 needs-spec-review 并清除过期批准信息，不得静默替换。验证按 spec 批准的深度：Simple 复用现有检查并做聚焦冒烟验证（放行、拦截、恢复）；Thorough 扩展自动化测试并做安全冒烟。契约规定畸形请求不消耗额度时，须在准入前校验字段与类型。不得仅为限流引入测试框架，无法运行的检查要如实记录。最后更新 spec 为 needs-implementation-review，展示 diff、验证证据、偏差与剩余操作步骤，除人类明确要求外，在合并、部署、发布或公告前停止；只有明确最终批准才改为 complete。适用场景为现有 Web 应用的限流治理与策略落地。限制：具体限流算法、供应商与额度需在审计中确定，资料未提供默认值；浏览器指纹仅作高级可选且需明确批准，不得作为唯一保护，不得用原始 API key 作标识。