技能介绍

要解决什么问题

注册、登录或联系表单一旦被脚本批量提交，轻则垃圾数据，重则撞库与滥用。Cloudflare Turnstile 能在前端收集人机验证令牌，但端到端仍要处理：在 Cloudflare 创建 Widget、为 cf-turnstile-response 配置服务端校验、避免在浏览器里直接调用 siteverify，以及把现有提交逻辑与校验结果对齐。手工对照 developers.cloudflare.com/turnstile 逐项改代码，很容易漏域名、漏 Worker 密钥或改坏原有表单处理。

技能如何工作

本技能把「set up Turnstile」收敛为多步向导：Agent 调用 scripts/ 下脚本处理确定性逻辑（API、重试与错误分支），自身负责读仓库、确认不可逆步骤与前端改动。

典型流程包括：

鉴权与范围：auth-probe.sh 检查 API Token 是否具备 Account.Turnstile:Edit 与 Account.Workers Scripts:Edit（wrangler login 的 OAuth 范围通常不够）。
域名与插入点：默认包含 localhost / 127.0.0.1，并从 package.json、wrangler.toml、README 等推断生产域名；扫描框架后给出表单插入候选并让你确认。
后端契约：创建 managed Widget 后部署托管 siteverify Worker；校验路径固定为 浏览器 → 你的 Worker → Cloudflare siteverify，不把 secret 写入磁盘。
前端契约：gate，don't replace——在 success === true 之后再执行原有 submit 处理，不替你改邮件、数据库或支付。
收尾：validate.sh 跑通后才报成功；可选将技能持久化到 .claude/skills/turnstile-spin/。

若已有 sitekey，可走恢复流程：用 fetch-secret.sh 拉元数据，跳过新建 Widget，从 Worker 部署继续；扫描到 reCAPTCHA / hCaptcha 时会给出迁移替换说明。

适用边界与注意点

硬边界：不处理仅 Workers/Pages/R2 且未提及 Turnstile 的任务；不编写自定义 Worker 功能；不碰表单持久化、OAuth、支付；不做大规模前端重构。
Pre-clearance：clearance_level !== no_clearance 时 siteverify 可能非必需，技能会按文档说明退出或让你确认。
安全：Turnstile secret 仅经 stdin 交给 wrangler secret put；覆写文件前需展示 diff；Token 勿长期留在对话记录中。