返回 Skills 目录
安装难度
低
维护状态
人工精选
兼容范围
静态站与 Cloudflare Pages 发布路径；内容更新与上线回归
最后验证
2026-04-03
Key signals
适合谁：适合需要频繁发布内容更新、同时又不想让发布验证停留在口头确认的站点维护者与编辑。
权限模型：优先本地构建、部署状态查看和线上只读核查；涉及生产发布时应保留单独确认与明确目标环境。
安全说明：以构建、只读核查和证据留存为主；真正的生产写操作应单独确认并保留发布记录。
Why this skill
先判断它值不值得装，再讨论怎么装。
它解决的不是“怎么更快发出去”，而是“怎么证明这次真的发到了线上，而且关键页面没有掉”。
Selection fit
这个 Skill 适合什么样的工作流
在内容站、文档站或静态站发布前后，把 build、deploy 和线上验证串成可回看的最小闭环。
适合谁
适合需要频繁发布内容更新、同时又不想让发布验证停留在口头确认的站点维护者与编辑。
权限模型
优先本地构建、部署状态查看和线上只读核查；涉及生产发布时应保留单独确认与明确目标环境。
兼容范围
静态站与 Cloudflare Pages 发布路径；内容更新与上线回归
维护状态
人工精选
Dependencies
启用前先满足这些前提
如果前提不满足，这个 Skill 就算装上了，输出也会不稳定或不安全。
需要先有固定的 build、lint 和部署命令，而不是每次临时拼接发布步骤。
需要明确哪些页面或路由属于上线后的最小抽查范围，例如首页、目录页、新增详情页和关键入口。
需要保留发布结果、时间和校验结论，避免过一会儿就说不清到底有没有成功上线。
Install flow
推荐安装与首跑顺序
先把范围收紧，再逐步放开能力，不要上来就给满权限。
先固定本地自查顺序，例如 lint、build 和必要的静态产物检查。
再定义发布后的线上抽查清单，只保留最能暴露问题的关键页面与状态码核查。
把每次发布的命令、结果和验证结论写进可审计日志，而不是停留在聊天里。
最后才把它纳入日常内容发布节奏，形成“改完 → 自查 → 发布 → 线上复核”的稳定闭环。
Success checks
装好之后至少要确认这三件事
真正可收录的 Skill，不是偶尔跑通，而是可重复、可解释、可停下来。
发布后能快速证明新增页面、关键入口和生产域名都已返回正确结果，而不是只看构建通过。
出现 404、旧内容未刷新或部署延迟时，能定位是本地构建、发布链路还是 CDN 生效问题。
回看日志时，能明确知道哪次发布做了什么、是否成功，以及线上验证覆盖了哪些页面。
Boundaries
这些边界如果说不清，就不该继续扩权
平台的目录页必须同时告诉用户它不能做什么，避免“能跑”掩盖风险。
不能把“构建通过”误当成“生产已完成更新”。
不适合包装成无人监督的自动发布默认值，尤其在生产写操作存在影响时。
如果关键页面抽查范围说不清，它就只是形式化 checklist，不足以支撑可信发布。
Related showcase
这个 Skill 更适合放进哪些 Showcase 路径里
技能详情页不只回答“能装吗”，也要帮助用户判断它更适合什么成果页和复刻路径。