Hainrixz/all-deploy

all-deploy 是做什么的？

检测、审计并将项目部署到合适的主机，采用确认的预览→生产流程。其独特价值在于检测→审计→路由到正确的CLI，而不是封装CLI。

配置（编辑以下行以更改默认行为）

CONFIRMATION_MODE: ask_at_start
  # ask_at_start（默认）：技能在每次云端部署开始时询问是否全自动或逐步执行。
  # full_auto：跳过问题。审计→预览→生产，生产前有5秒ESC窗口。
  # always_ask：跳过问题。生产前需要明确"yes"确认。
VISUAL_VERIFY: false           # true → 通过chrome-bridge-automation截图预览（仅前端）
ALLOW_DIRTY_TREE: false        # true → 跳过"HEAD是干净的"审计检查

默认的ask_at_start适用于独立作者和社区用户——模式选择移至运行时。仅当将技能封装在无法交互回答问题的自动化中时，才固定为full_auto或always_ask。

硬性规则（绝不违反——这是安全契约）

1. 绝不绕过或削弱审计。 在full_auto模式下，审计是用户意图与生产基础设施之间的唯一关卡。如果某项检查无法运行，这本身就是阻止原因，而非跳过理由。
2. 在成功预览并通过2xx/3xx健康检查之前，绝不部署到生产环境。 预览→摘要→生产。没有绿色预览就没有生产。（某些静态目标没有预览环境——GitHub Pages、浏览器上传。此时绿色工件是对确切发布目录本地运行python3 -m http.server，以相同方式健康检查。关卡仍然强制；仅服务位置发生变化。）
3. 绝不提交、打印或记录密钥。 如果在跟踪文件中发现密钥，则停止并引导用户作为单独批准的步骤进行删除和重写历史。密钥值绝不显示在摘要、日志或提交消息中。
4. 绝不自动安装或自动验证第三方CLI。 向用户提供带有!前缀的命令（例如! vercel login、! railway login）。
5. 绝不将目标CLI包装在隐藏标志的自定义脚本中。 引用文件记录用户可阅读和验证的真实命令。
6. 在未先显示差异时，绝不修改代码使审计通过而不显示差异。 .gitignore、.env.example、Dockerfile脚手架、端口绑定修复——所有更改在应用前均需展示和批准。
7. 绝不从脏工作树部署，除非设置了ALLOW_DIRTY_TREE: true。未提交的更改会复杂化回滚。
8. 尊重"等待"。 在预览和生产之间，任何用户表示犹豫的话语（wait/hold/stop/not yet/abort）都会干净地中止生产步骤。

两种模式

从一开始根据用户措辞决定：

• 云端部署（默认）——以下阶段0到6。触发词："deploy"、"ship"、"push to prod"、"get it online"、"/all-deploy"。
• 本地运行——阶段0、1、2，然后本地运行步骤。触发词："run it locally"、"corre esto localmente"、"/all-deploy local"、"just run it"或--local。

项目类别（在云端部署内决定，非第三种模式）

云端部署涵盖两种形态，类别自动检测——从不询问：

• app（默认）——带运行时、启动命令和端口的服务。
• static——网站：主机复制到CDN的文件文件夹。无服务器、无端口、无运行时。在以下阶段0.0中分类。阶段0、2、3.2、4、4.5、5和6会变化；阅读references/static-sites.md了解完整调整集。

在本地运行模式下，执行范围审计——仅检查跟踪文件中的密钥、启动命令存在性和合理端口绑定。跳过：git远程、干净HEAD、npm audit/pip-audit、.env.example完整性以及环境变量交付（无远程可交付）。然后在前台执行检测到的启动命令（npm run dev / uvicorn main:app --reload --host 0.0.0.0 --port $PORT / docker compose up等），通过Monitor流式输出。如果用户还希望公开本地服务器，则链接到references/targets/cloudflared-tunnel.md。本文档其他部分涉及云端部署。

云端部署工作流程

模式选择（在ask_at_start模式下，阶段0之前运行）

解析本次运行的生效CONFIRMATION_MODE：

1. 如果用户的调用包含显式模式标记，则采用该标记并跳过问题：

   • full_auto触发词："auto"、"full auto"、"auto deploy"、"deploy auto"、"/all-deploy auto"、"yolo"。
   • always_ask触发词："step"、"step by step"、"one at a time"、"confirm each step"、"paso a paso"、"/all-deploy step"。

2. 否则，如果上方配置块中CONFIRMATION_MODE固定为full_auto或always_ask，则使用该值并跳过问题。

3. 否则（ask_at_start，默认），在阶段0运行前询问用户一次：

   "开始之前——我该如何运行部署？

   1. 全自动——我按顺序运行审计→预览→生产发布。生产在5秒ESC窗口后触发。 2. 逐步进行——我在审计、预览和生产之间停下来等待您确认。

   回复'auto'或'step'。"

所选模式仅限定本次运行——未来的调用将再次询问（除非用户通过触发词明确选择，或配置块被固定）。

在任何时候"wait"、"stop"、"hold"仍会在两种模式下中止生产步骤（硬性规则8）。区别在于生产命令运行前是否有5秒ESC窗口（full_auto）或需要明确"yes"的暂停（always_ask）。

阶段0.0——项目类别（首先运行，先于先决条件）

如果存在HTML文件——在根目录或dist/、_site/、public/、build/、out/、site/中——且根目录中不存在package.json、pyproject.toml、requirements.txt、Pipfile、Dockerfile、docker-compose.yml、Procfile、go.mod、Gemfile，则设置PROJECT_CLASS: static。否则为PROJECT_CLASS: app。

清单测试确保同时具有index.html的Vite/Next/Astro仓库走应用管道。如果为static，则立即阅读references/static-sites.md；其阶段表控制以下所有内容。

这特意在阶段0之前运行。之前先检查先决条件会导致在不需要git远程的HTML文件夹因缺少git远程而退回。

阶段0——先决条件（与目标无关）

按顺序检查。每次失败都会以!命令停止并提示用户。

1. Git仓库。 运行git rev-parse --is-inside-work-tree。如果不是仓库，则停止，除非模式为run locally（不要求git）或PROJECT_CLASS: static——静态站点可以从普通文件夹部署。说明没有仓库并继续；决定在阶段3.2中做出。未经提示绝不运行git init。
2. Git远程（仅云端部署）。运行git remote -v。如果未配置远程，则停止，除非目标将是docker-vps（可在无远程情况下部署），或PROJECT_CLASS: static且目标不是GitHub Pages或Render——Cloudflare Pages直接上传和Netlify Drop根本不需要仓库。此第二条款在阶段3后重新评估。
3. 语言边界。 v1支持Node和Python。如果主要语言是Go、Rust、Ruby、Elixir、Bun或Deno，则退出并显示："v1仅检测Node/Python生态系统。直接运行目标CLI（vercel、railway、flyctl、docker）。该语言支持计划在v2中。" 当PROJECT_CLASS: static时不适用——HTML/CSS/JS始终在范围内，无论是否有构建步骤。

目标CLI认证在阶段3.5（下方）检查，在选择目标之后。

阶段0.5——权限提示播种（仅首次运行）

告知用户："在此项目上运行fewer-permission-prompts技能一次，以使用部署白名单播种.claude/settings.json——否则每个步骤都会提示。" 仅提示。此处从不编辑用户设置。

阶段1——检测

阅读references/project-types.md（技能相对路径——Claude会针对已安装的技能目录解析）了解完整指纹表。检查：

• 包管理器和清单： package.json、pnpm-lock.yaml、yarn.lock、package-lock.json、bun.lockb、pyproject.toml、requirements.txt、poetry.lock、uv.lock、Pipfile。
• 框架信号： next.config.*、vite.config.*、astro.config.*、remix.config.*、nuxt.config.*、svelte.config.*、app/与pages/、main.py包含FastAPI()、Flask()、app = FastAPI()、server.py、根目录的index.html。
• 运行时版本： .nvmrc、.node-version、package.json中的engines、.python-version、pyproject.toml中的python_version。如果选择了长时间运行的目标且未固定运行时，审计会阻止。
• 数据库/有状态依赖： 导入sqlalchemy、psycopg、prisma、mongoose、redis、ioredis、sqlmodel。如果找到，则显示*"此服务需要数据库——在生产前准备一个"*，并附上Railway引用中的Railway附加命令。
• 端口和启动命令： uvicorn、gunicorn、next start、node server.js、python -m ...。检查0.0.0.0绑定和$PORT使用。仅本地主机绑定会阻止长时间运行的目标。
• 单仓库： pnpm-workspace.yaml、turbo.json、nx.json、lerna.json或根package.json中的"workspaces"→枚举包并询问要部署哪个。不猜测。
• 库/CLI（非Web部署）： Node信号——package.json中存在bin:字段或（存在files:数组且无scripts.start且无HTTP框架导入如express、fastify、hono、next、koa）。Python信号——pyproject.toml中存在[project.scripts]/console_scripts且声明的脚本或导入中无uvicorn/gunicorn/flask/fastapi。不单独使用main:作为库信号——几乎所有Node Web应用也设置了main:。干净退出："这看起来像一个包——/all-deploy针对Web服务，而非npm/PyPI发布。"
• 现有部署配置： vercel.json、railway.toml、fly.toml、Dockerfile、render.yaml——尊重、审计，未经明确询问不重新生成。
• 现有项目链接： .vercel/project.json→重用该Vercel项目ID。railway.toml包含project字段→重用。重新部署是常见情况；新项目需要明确"开始新项目"。

当PROJECT_CLASS: static时， 跳过框架/运行时/端口/数据库/单仓库指纹检测。仅检测三件事：发布目录（包含index.html的文件夹——.、dist/、_site/、public/、build/、out/、site/）、是否存在构建步骤以及是否存在git仓库。发布目录表在references/static-sites.md中；弄错是导致在线站点在/处返回404的最常见原因。

输出：一个分类块和一个候选目标排名列表，每个带有一行理由。查看references/project-types.md了解完整目标排名规则。

阶段2——审计（严格，阻止性）

运行与此技能捆绑的审计脚本（scripts/audit.py）针对当前项目目录。Claude在加载时解析技能路径——调用如下所示：

python3 <SKILL_DIR>/scripts/audit.py <project-path>

当PROJECT_CLASS: static时：

python3 <SKILL_DIR>/scripts/audit.py <project-path> --profile static --publish-dir <dir> [--target <name>]

这会跳过每个假定依赖树、启动命令、端口或git远程的检查——这些会在普通HTML文件夹上产生错误的致命错误——而是运行scripts/static_check.py。当选择的目标是GitHub Pages时传递--target github-pages：它是唯一真正需要远程的静态目标，也是唯一。nojekyll和根相对路径重要的目标。检查列表在references/static-sites.md中。

其中<SKILL_DIR>是技能安装位置（通常是~/.claude/skills/all-deploy/），<project-path>通常是.。脚本检查references/audit-checklist.md中的每个项目：跟踪文件中的密钥、.gitignore覆盖率、锁文件一致性、.env.example完整性（通过scripts/env_extract.py）、构建/启动脚本存在性、端口绑定、干净HEAD、git远程匹配、npm audit --production --audit-level=high或pip-audit。

任何失败都会停止。对于每个问题，以差异形式显示修复（如适用），并在应用前等待用户确认。自动模式不会绕过审计。

Git历史密钥扫描由用户运行，而非自动。在审计输出中，显示：trufflehog git file://.或git log -p -S 'sk_' -S 'AKIA' -S 'ghp_'作为单独步骤。技能从不重写git历史。

阶段3——目标选择

展示阶段1中的排名候选目标，每行附理由。用户选择或接受顶部选择并回复"ok"。仅现在加载目标引用：

• references/targets/vercel.md——Next、Vite、Astro、Remix、Nuxt、SvelteKit、静态
• references/targets/railway.md——FastAPI、Flask、Express、Python工作进程、MCP HTTP、Claude Agent SDK
• references/targets/docker-vps.md——任何Dockerfile、有状态工作负载、自托管
• references/targets/cloudflared-tunnel.md——暴露本地开发、快速演示
• references/targets/cloudflare-pages.md——静态站点；任何人在付费时的默认选择
• references/targets/netlify.md——需要表单的静态站点；拖放
• references/targets/github-pages.md——已在GitHub上的作品集、文档、演示
• references/targets/render.md——静态站点、低流量

对于PROJECT_CLASS: static，在展示候选目标之前阅读references/static-hosting.md。它包含比较、免费层限制和商业使用矩阵——以及实际决定排名的问题："是否有人在此页面关联下获得报酬？" 如果是，则移除Vercel Hobby（*"接收付款以创建、更新或托管站点"*根据其公平使用条款属于商业用途）以及通常GitHub Pages。

此外，对于PROJECT_CLASS: static，此处再次检查git远程的状态以完成第二阶段（静默git远程）。如果目标（现在已知）需要git远程且不存在，则停止并提供命令。如果目标是Cloudflare Pages或Netlify，则告知用户可以走直接上传路径，不需要git。如果用户之前被告知不需要git（阶段0，第2条），则现在根据所选目标更新该消息。

阶段3.5——认证（目标特定）

对于所选目标，检查目标CLI是否已认证。如果未认证，则停止并显示命令：! vercel login、! railway login等。仅在用户运行命令后才继续。

阶段4——配置

对于所选目标，生成或更新必要的部署配置文件（如vercel.json、railway.toml、Dockerfile、.github/workflows/deploy.yml）。这些文件是目标引用中记录的。每个配置文件作为一个差异展示给用户进行批准。

当PROJECT_CLASS: static时， 跳过运行时/框架配置。仅配置发布目录和可能的构建命令。

阶段4.5——构建

如果存在构建步骤，则运行它。对于PROJECT_CLASS: static，构建命令在package.json或检测到的框架中定义。输出发布目录。

阶段5——预览

将发布目录部署到预览URL。对于大多数目标，这是通过目标CLI的命令。对于静态站点，这可能是本地预览或使用目标CLI的预览功能。

对于PROJECT_CLASS: static且目标具有预览环境（Cloudflare Pages、Netlify、Vercel），使用目标CLI的预览功能。如果没有预览环境（GitHub Pages、Render直接上传），则运行本地服务器：python3 -m http.server <port> --directory <publish-dir>并通过Monitor使其可访问。然后显示VISUAL_VERIFY选项。

运行健康检查：对预览URL发送curl -o /dev/null -s -w "%{http_code}" <preview-url>。如果返回2xx或3xx，则继续。否则，显示错误并停止。

阶段5.5——摘要

在预览成功后，显示包含以下内容的摘要：

• 项目类型
• 检测到的框架/运行时
• 构建状态
• 预览URL
• 目标
• 任何配置更改
• 密钥扫描状态

在always_ask模式下，在此停止并询问是否继续到生产。在full_auto模式下，显示5秒倒计时窗口以允许用户按ESC停止。

阶段6——生产

运行目标CLI的生产部署命令。在成功后，显示生产URL。

本地运行工作流程

阶段0——先决条件（范围版本）

仅检查：

1. Git仓库——跳过（不要求）
2. Git远程——跳过（无远程）
3. 语言边界——跳过（仅本地）

阶段1——检测（范围版本）

检测启动命令和端口绑定。不检测数据库、单仓库或库/CLI。

阶段2——审计（范围版本）

运行范围审计：仅检查跟踪文件中的密钥、启动命令存在性和合理端口绑定。跳过：git远程、干净HEAD、npm audit/pip-audit、.env.example完整性以及环境变量交付。

本地运行步骤

在前台执行检测到的启动命令，通过Monitor流式输出。如果用户希望暴露本地服务器，则链接到references/targets/cloudflared-tunnel.md。

引用

此技能附带以下引用文件，存储在技能目录中：

• references/project-types.md——完整指纹表
• references/audit-checklist.md——审计检查完整列表
• references/static-sites.md——静态站点处理详细说明
• references/static-hosting.md——静态主机比较
• references/targets/vercel.md——Vercel部署指南
• references/targets/railway.md——Railway部署指南
• references/targets/docker-vps.md——Docker VPS部署指南
• references/targets/cloudflared-tunnel.md——Cloudflared隧道指南
• references/targets/cloudflare-pages.md——Cloudflare Pages指南
• references/targets/netlify.md——Netlify指南
• references/targets/github-pages.md——GitHub Pages指南
• references/targets/render.md——Render指南
• scripts/audit.py——审计脚本
• scripts/static_check.py——静态站点审计脚本
• scripts/env_extract.py——环境变量提取脚本