Deploy Guardian — Pre-Deployment Verification
Version: 1.1.0 | Author: Shadows Company | License: MIT
WHEN TO TRIGGER
- - Before deploying to production or staging
- User says "deploy check", "ready to deploy?", "pre-deploy", "deploy guardian"
- Before creating a release tag
- Before merging a major PR
WHEN NOT TO TRIGGER
- - Local development iterations
- Draft PRs or WIP branches
- Exploratory prototyping with no deployment intent
PREREQUISITES
This skill requires git on PATH. Gates 2-4 auto-detect and run only the toolchain present in the project:
| Toolchain | Required for | Detection |
|---|
| INLINECODE1 / INLINECODE2 | Node.js projects | INLINECODE3 exists |
| INLINECODE4 / INLINECODE5 |
Python projects |
setup.py,
pyproject.toml, or
requirements.txt exists |
|
cargo | Rust projects |
Cargo.toml exists |
|
docker | Containerized builds |
Dockerfile exists |
The agent MUST check which toolchain is available before running commands. Skip any gate sub-step whose toolchain is absent — do NOT fail the gate for missing optional toolchains.
PROTOCOL — 6 GATES
Each gate must PASS before proceeding. One FAIL = deployment blocked.
Gate 1 — GIT STATUS
CODEBLOCK0
Verify:
- - [ ] Working tree is clean (no uncommitted changes)
- [ ] On the correct branch (main/release/deploy)
- [ ] Branch is up to date with remote (
git rev-parse HEAD == git rev-parse @{u}) - [ ] No merge conflicts pending
Gate 2 — TESTS
Detect the project type and run ONLY the matching test runner:
CODEBLOCK1
Verify:
- - [ ] All tests pass (zero failures)
- [ ] No skipped critical tests
- [ ] Exit code is 0
Note: This executes project test scripts, which run code from the repository. Only run in trusted repositories or sandboxed environments.
Gate 3 — TYPE CHECK & LINT
Auto-detect and run ONLY the matching toolchain:
CODEBLOCK2
Verify:
- - [ ] Zero type errors
- [ ] Zero lint errors (warnings acceptable)
- [ ] SKIP if no type checker / linter is configured (not a failure)
Gate 4 — BUILD
Auto-detect and run ONLY the matching build system:
CODEBLOCK3
Verify:
- - [ ] Build completes with exit code 0
- [ ] Output artifacts generated in expected location
- [ ] SKIP if no build system detected (not a failure)
Note: Build commands execute project scripts. Same sandboxing considerations as Gate 2 apply.
Gate 5 — SECRETS SCAN
CODEBLOCK4
Verify:
- - [ ] No secrets pattern in recent commits
- [ ] Zero
.env files tracked by git - [ ]
.gitignore covers at least 3 secret patterns - [ ] No
.pem, .key, .p12 files tracked
Limitations: This grep-based scan catches common patterns but is not a substitute for dedicated secret scanners (gitleaks, trufflehog, detect-secrets). For production environments, consider running a dedicated scanner as an additional step.
Warning: Command output may display matched secret-like patterns in the terminal. Run this gate in a secure terminal session where output is not logged to shared systems.
Gate 6 — ENVIRONMENT VALIDATION
Run concrete automated checks for the target environment:
CODEBLOCK5
Verify:
- - [ ]
.env.example or equivalent documentation exists - [ ] No unapplied migrations in queue
- [ ] Target URL responds (if
$DEPLOY_URL is set) - [ ] Docker config valid (if applicable)
- [ ] SKIP individual checks when not applicable (not a failure)
SECURITY CONSIDERATIONS
- 1. Code execution: Gates 2-4 execute project scripts (
npm test, npm run build, cargo test). These commands run arbitrary code from the repository. Only run this skill on repositories you trust, or execute within a sandboxed environment (Docker container, CI/CD pipeline, OpenClaw sandbox mode).
- 2. Secret exposure: Gate 5 scans diffs for secret patterns. Matched patterns are displayed in terminal output. Ensure your terminal session is not logged to shared monitoring systems.
- 3. Network access: Gate 6 optionally makes outbound HTTP requests (via
curl) only if $DEPLOY_URL is explicitly set. No other network access is required.
- 4. No persistence: This skill does not modify any configuration files, install packages, store credentials, or make changes outside the terminal session. It is read-only except for the build artifacts produced by Gate 4.
- 5. Sandboxing recommendation: For maximum safety, run deploy-guardian inside a CI/CD pipeline or a sandboxed agent environment rather than directly on a developer workstation.
OUTPUT FORMAT
CODEBLOCK6
RULES
- 1. All gates must pass — no exceptions, no overrides
- Secrets gate is non-negotiable — one leaked secret = full stop
- Auto-detect toolchain — never run commands for absent toolchains
- SKIP is not FAIL — absent toolchains produce SKIP, not FAIL
- Test failures block deployment — even flaky tests must be investigated
- Document blockers — always explain WHY with file:line references
- Never auto-deploy — always wait for explicit user confirmation
- Trusted repos only — warn user if running on an unfamiliar repository
Published by Shadows Company — "We work in the shadows to serve the Light."
部署守护者 — 预部署验证
版本: 1.1.0 | 作者: Shadows Company | 许可证: MIT
触发时机
- - 部署到生产环境或预发布环境之前
- 用户说部署检查、准备部署?、预部署、部署守护者
- 创建发布标签之前
- 合并重要拉取请求之前
不触发时机
- - 本地开发迭代
- 草稿拉取请求或进行中分支
- 无部署意图的探索性原型开发
前置条件
此技能要求git在系统路径中。关卡2-4会自动检测并仅运行项目中存在的工具链:
| 工具链 | 适用项目 | 检测方式 |
|---|
| npm/npx | Node.js项目 | 存在package.json |
| python/python3 |
Python项目 | 存在setup.py、pyproject.toml或requirements.txt |
| cargo | Rust项目 | 存在Cargo.toml |
| docker | 容器化构建 | 存在Dockerfile |
代理在运行命令前必须检查可用的工具链。跳过任何缺少工具链的关卡子步骤——不要因缺少可选工具链而导致关卡失败。
协议 — 6道关卡
每道关卡必须通过后才能继续。一次失败 = 阻止部署。
关卡1 — GIT状态
bash
git status
git log --oneline -5
git remote update --prune 2>/dev/null && git status -uno
验证:
- - [ ] 工作区干净(无未提交更改)
- [ ] 在正确的分支上(main/release/deploy)
- [ ] 分支与远程同步(git rev-parse HEAD == git rev-parse @{u})
- [ ] 无待处理的合并冲突
关卡2 — 测试
检测项目类型并仅运行匹配的测试运行器:
bash
自动检测:仅运行第一个匹配的运行器
if [ -f package.json ]; then
npm test 2>&1
elif [ -f pyproject.toml ] || [ -f setup.py ] || [ -f requirements.txt ]; then
python -m pytest -v 2>&1 || python3 -m pytest -v 2>&1
elif [ -f Cargo.toml ]; then
cargo test 2>&1
else
echo 跳过:未找到可识别的测试运行器
fi
验证:
- - [ ] 所有测试通过(零失败)
- [ ] 无跳过的关键测试
- [ ] 退出码为0
注意:此步骤执行项目测试脚本,会运行仓库中的代码。仅在受信任的仓库或沙盒环境中运行。
关卡3 — 类型检查与代码检查
自动检测并仅运行匹配的工具链:
bash
TypeScript(如果存在tsconfig.json)
[ -f tsconfig.json ] && npx tsc --noEmit 2>&1
Python(如果存在.py文件)
[ -f pyproject.toml ] && python -m ruff check . 2>&1
ESLint(如果存在.eslintrc*)
ls .eslintrc
eslint.config. 2>/dev/null && npx eslint . 2>&1
验证:
- - [ ] 零类型错误
- [ ] 零代码检查错误(警告可接受)
- [ ] 如果未配置类型检查器/代码检查器则跳过(不视为失败)
关卡4 — 构建
自动检测并仅运行匹配的构建系统:
bash
if [ -f package.json ] && grep -q build package.json; then
npm run build 2>&1
elif [ -f Dockerfile ]; then
docker build --dry-run . 2>&1
elif [ -f Cargo.toml ]; then
cargo build --release 2>&1
else
echo 跳过:未检测到构建步骤
fi
验证:
- - [ ] 构建完成且退出码为0
- [ ] 输出工件生成在预期位置
- [ ] 如果未检测到构建系统则跳过(不视为失败)
注意:构建命令执行项目脚本。与关卡2相同的沙盒注意事项适用。
关卡5 — 密钥扫描
bash
检查最近提交中泄露的密钥(最近5个)
git diff HEAD~5..HEAD -- . :!
.lock :!.sum | grep -inE (api[
-]?key|secret|token|password|private[-]?key)\s
[:=]\s[\][^\]{8,} || echo 通过:未检测到密钥模式
检查未提交到git的.env文件
git ls-files | grep -E \.env$|\.env\.\w+ | head -10
检查.gitignore是否包含密钥模式
if [ -f .gitignore ]; then
COVERAGE=$(grep -cE \.env|secret|credential|\.pem|\.key .gitignore)
echo Gitignore密钥覆盖率:$COVERAGE 个模式
fi
验证:
- - [ ] 最近提交中无密钥模式
- [ ] git跟踪的.env文件为零
- [ ] .gitignore覆盖至少3个密钥模式
- [ ] 无.pem、.key、.p12文件被跟踪
局限性:此基于grep的扫描可捕获常见模式,但不能替代专用密钥扫描器(gitleaks、trufflehog、detect-secrets)。对于生产环境,建议将专用扫描器作为额外步骤运行。
警告:命令输出可能会在终端中显示匹配的密钥类模式。请在安全的终端会话中运行此关卡,确保输出不会记录到共享系统。
关卡6 — 环境验证
对目标环境运行具体的自动化检查:
bash
检查所需环境变量是否已文档化
if [ -f .env.example ]; then
echo 通过:.env.example存在(记录了$(wc -l < .env.example)个变量)
else
echo 警告:无.env.example——所需变量未文档化
fi
检查待处理的数据库迁移(常见框架)
[ -d migrations ] && ls -1t migrations/ | head -3
[ -d alembic/versions ] && ls -1t alembic/versions/ | head -3
检查SSL证书有效性(如果curl可用)
if command -v curl &>/dev/null && [ -n $DEPLOY_URL ]; then
curl -sI --max-time 5 $DEPLOY_URL | head -5
fi
检查Docker健康状态(如适用)
[ -f docker-compose.yml ] && docker compose config --quiet 2>&1 && echo 通过:docker-compose配置有效
验证:
- - [ ] 存在.env.example或等效文档
- [ ] 队列中无未应用的迁移
- [ ] 目标URL响应(如果设置了$DEPLOY_URL)
- [ ] Docker配置有效(如适用)
- [ ] 不适用时跳过单项检查(不视为失败)
安全注意事项
- 1. 代码执行:关卡2-4执行项目脚本(npm test、npm run build、cargo test)。这些命令运行仓库中的任意代码。仅在您信任的仓库上运行此技能,或在沙盒环境(Docker容器、CI/CD流水线、OpenClaw沙盒模式)中执行。
- 2. 密钥暴露:关卡5扫描差异中的密钥模式。匹配的模式会显示在终端输出中。确保您的终端会话不会记录到共享监控系统。
- 3. 网络访问:关卡6仅在明确设置$DEPLOY_URL时可选地发起出站HTTP请求(通过curl)。不需要其他网络访问。
- 4. 无持久化:此技能不会修改任何配置文件、安装包、存储凭据或在终端会话之外进行更改。除关卡4产生的构建工件外,它是只读的。
- 5. 沙盒建议:为获得最大安全性,请在CI/CD流水线或沙盒代理环境中运行deploy-guardian,而不是直接在开发者工作站上运行。
输出格式
markdown
部署守护者报告
日期:[YYYY-MM-DD HH:MM]
分支:[分支名称]
提交:[短SHA]
目标:[生产环境/预发布环境]
工具链:[检测到:node/python/rust/docker]
关卡结果
| # | 关卡 | 状态 | 详情 |
|---|
| 1 | Git状态 | 通过/失败 | [干净、正确分支、已同步] |
| 2 |
测试 | 通过/失败/跳过 | [X通过、Y失败,或跳过原因] |
| 3 | 类型检查与代码检查 | 通过/